Kdy se IPv6 dostane ke koncovým uživatelům? (diskuse)

[Bedňa]

Kto to vyžaduje a má na výber si vyberie podľa preferencií. Toš veľakrát na výber nemáš a 99% ľudí to nerieši. Existuje aj NatTraversing takže sa dokážeš dostať aj na svetlo božie cez NAT.

No a ruku na srdce, ty by si investoval milióny Eur aby si dodal niekomu službu ktorú nikto nepožaduje?

[Miriam]

Znáš teorii her? Pokud má dojít k radikální změně na jinou rovnováhu, musí existovat výhoda, kterou ji razantně vykompenzuješ. Co většinu lidí táhne k IPv6? Obávám se, že kromě propagandy CZNICu, který by měl dělat něco úplně jiného, praktická výhoda neexistuje. Jiné technologie řeší situaci IPv4 evolučně - příkladem je NAT. Nevidím nikoho, kdo by v tom měl zájem (on i ten skype pro BFU bude stejně potřeba i na IPv4), prostě IPv6 je typický příklad zbytečně přetechnizovaného řešení nestojícího za nic. Druhým příkladem je Linux.

[Hans1024]

Pry "klamani zakaznika . A kde je definovano co je "pripojeni k internetu"?

Z pohledu spravce site / poskytovatele se mi to zda jednoznacne: "Proc bych si pridelaval praci, za kterou mi prakticky nikdo nezaplati, ani nepodekuje a jeste si tim zhorsim bezpecnost site."

Muj hruby odhad je takovy, ze si musis pockat jeste 20 let. Pokud bys to chtel urychlit, musis zaridit, aby nefungovalo porno pres IPv4. Taky je mozne, ze se to urychli tim, ze to socialisti daji do zakona...

[pavlix]

zhorsim bezpecnost site.

Nesmysl, odkazovaná přednáška není o sítích ISP, ale o koncových sítích a to především tvrdě omezovaných korporátních sítích.

[Hans1024]

Prednaska se sice ISP moc netyka, ale myslim, ze s rozsirenim IPv6 souvisi. A z podstaty veci je logicke, ze kdyz budu provozovat 2 protokoly, mam vsude cca 2x vic moznych utocnych vektoru. A taky NATy, ac se to puristum nelibi, jednoznacne zvysuji bezpecnost koncoveho zakaznika.

[pavlix]

A taky NATy, ac se to puristum nelibi, jednoznacne zvysuji bezpecnost koncoveho zakaznika.

Jednoznačně určitě ne.

[SAM:]

Seš vedle jak ta jedle. Ať NAT dělá cokoliv, klidně ať ti uvaří kafe, ale určitě nezvyšuje bezpečnost sítě ani koncového uživatele. NAT je zlo, které nemělo nikdy vzniknout a snahy o implementaci NATu v IPv6 jsou totální fail. IPv4 se měla odpískat už před 15ti lety, kdy bylo jasné, že adresy prostě stačit nebudou, a neprodlužovat IPv4 experiment (V. Cerf) technologiemi jako je NAT nebo CIDR.

Bohužel za posledních 20 let jsme si na NAT tak zvykli, že už si nedokážeme představit žít a fungovat bez něj. V tom je ten problém. Internet byl založen na možnosti transparentního neomezeného spojení end-user vs. end-user. To jde s NATem dost těžko a tak pálíme spoustu energie na vývoj mechanismů, jak NAT překročit. Jediným řešením je IPv6 - kdo se bojí nesmí do lesa :)

[Hans1024]

Kdyz jsem mluvil o "puristech", presne tohle jsem mel na mysli. Jo, ja chapu ze NAT je hack, a ze takhle to vubec nebylo navrzene, ale cely linuxovy ekosystem je plny "nesystemovych" hacku. A predesignovany IPv6 bych nenazval nejakym idealem cistoty. Bohuzel, svet neni idealni, a znam lidi s neaktualizovanyma woknama, kteri by s verejnou IP uz vesele slouzili nejakemu botnetu. A ne, NAT nezabrani ovladnuti takoveho stroje, ale zvysi potrebne usili, a znacne snizi pravdepodobnost.

[pavlix]

A ne, NAT nezabrani ovladnuti takoveho stroje, ale zvysi potrebne usili, a znacne snizi pravdepodobnost.

Možná tak statisticky v obecném měřítku, ale to podle mě nemá pro konkrétní opatření zásadní význam. Problém je v tom, že v diskuzi padlo, že NAT jednoznačně zvýší bezpečnost (každého) koncového zákazníka a to je bohapustá lež, na kterou jsi se bohužel nechal nachytat i ty.

Teoretický i praktický bezpečnostní přínos NATu je nutné posuzovat inteligentně a dle okolností, nikoli na základě ideologie a v přespříliš obecné rovině.

[Hans1024]

No, asi jsem blbe volil slova, ale chtel jsem rict, ze podle me je pocet situaci, kde to bezpecnost snizi zanedbatelny vzhledem k poctu situaci, kde to bezpecnost zvysi.

[pavlix]

1) Podle mě je zanedbatelná samotná myšlenka, že budu toto téma posuzovat dle počtu situací.

2) Z mého osobního pohledu jsou rovněž zanedbatelné sitauce, kdy bych navrhnul použít NAT za účelem zabezpečení sítě. Jediné, co mi reálně stojí za úvahu je neodstraňovat bezhlavě NAT tam, kde je, v případě, že není zajištěno odpovídající zabezpečení na jiné úrovni.

3) Obávám se, že když se na situaci člověk podívá s trochou netechinckého nadhledu, tak NAT ve skutečnosti bezpečnost drasticky snižuje tím, že lidé uvěří pověrám, které kolem něj kolují, a na jejich základě bezpečnost zanedbají.

4) Bezpečnost podle mě nelze smysluplně dělat hladovým algoritmem, tedy že učiníme každý krok, který vyhodnotíme jako bezpečnost zvyšující a vyvarujeme se každého kroku, který vyhodnotíme jako bezpečnost snižující. Výsledek takovéhoto počínání je do jisté míry náhodný a především zcela neauditovatelný.

Tady na Abclinuxu bývá zvykem vymyslet nějaký hodně pitomý příměr, tak to taky zkusím. Podobně jednoznačně zvyšuje bezpečnost zakoupení pepřového spreje. Podobně jistě můžeme zanedbat případy, kdy zakoupení pepřového spreje bezpečnost snižuje. Na druhou stranu pokud člověk nerozumí zabezpečení pomocí pepřového spreje, tak si ho třeba taky vystaví na poličce a při pohledu na něj se cítí velice bezpečně. Ovšem ke dveřím, na procházky i do auta chodí úplně stejně nechráněn jako předtím. Přes údajně bezpečný NAT pak spuští exáče z pornostránek.

[Hans1024]

Jediné, co mi reálně stojí za úvahu je neodstraňovat bezhlavě NAT tam, kde je, v případě, že není zajištěno odpovídající zabezpečení na jiné úrovni.

O to mi vpodstate jde. Masivnim nasazovanim IPv6 se odstrani obrovske mnozstvi NATu.

NAT ve skutečnosti bezpečnost drasticky snižuje tím, že lidé uvěří pověrám, které kolem něj kolují, a na jejich základě bezpečnost zanedbají.

Ja bych rekl, ze vetsina koncovych zakazniku nema tuseni co to je NAT, takze zadnym poveram neuveri

Výsledek takovéhoto počínání je do jisté míry náhodný a především zcela neauditovatelný.

Na mou spravovanych systemech bych takovy postup taky nezvolil, ale z pochopitelnych duvodu ISP, stejne jako vetsina jinych komercnich subjektu, hledaji spise lokalni optimum, protoze na ceste ke globalnimu optimu je prilis velky odpor ze strany uzivatelu.

Přes údajně bezpečný NAT pak spuští exáče z pornostránek.

Ano, ten klicovy problem je chovani uzivatelu. Ale ja si v tomhle opravdu nedelam velke nadeje. Diky tomu, jak je tezke zmenit chovani uzivatelu, vznikly takove humusy jako antiviry, ktere rovnou predpokladaji, ze uzivatele spousti exace z pornostranek. Nelibi se mi to a na svem systemu bych nikdy tak retardovany pristup k zabezpeceni nezvolil. Ale faktem je, ze nejake masove viry tem lidem ten antivirak odchyti a kdybych ze dne na den smazal vsechny antiviraky z kazdeho kompu po celem svete, tak bych tomu stavu nepomohl.

[Hans1024]

kdybych ze dne na den smazal vsechny antiviraky z kazdeho kompu po celem svete, tak bych tomu stavu nepomohl.

I kdyz z dlouhodobeho hlediska by se to pak asi zlepsilo, a stejne tak u odstraneni NATu.

[pavlix]

To souhlasím. Ale na druhou stranu bych zachoval zabezpečení proti uživateli na úrovni systému, tedy něco jako antivirák, akorátže striktní místo kombinace známých hrozeb a heuristiky. Člověk by neměl používat kód sebraný z nedůvěryhodných zdrojů ve stejném bezpečnostním kontextu jako kód aplikací spravujících jeho uživatelská data.

[pavlix]

O to mi vpodstate jde. Masivnim nasazovanim IPv6 se odstrani obrovske mnozstvi NATu.

To si vůbec nerozumíme. Mluvil jsem o akci v duchu toho, že přijdu do firmy, zjistím, že mají stroje na veřejných IPv4 adresách za NATem, tak ten NAT jako projev nebezpečného entuziasmu vypnu. On je to ostatně taky jediný případ, kdy NAT zvyšuje bezpečnost, protože zapnutí NATu u privátních adres cestu ke stroji naopak otevírá.

Masivní nasazování globálních adres (třeba IPv6, když je to teď tak populární) s sebou nese mnohem zajímavější problémy a rizika a mělo by být dobře připravené a promyšlené. Že to tak často není, je trochu jiný typ problému, než o kterém se tady bavíme.

Ja bych rekl, ze vetsina koncovych zakazniku nema tuseni co to je NAT, takze zadnym poveram neuveri

To ovšem na věci vůbec nic nemění, neznalost uživatelů bezpečnosti nemusí vždy pomoct.

Diky tomu, jak je tezke zmenit chovani uzivatelu, vznikly takove humusy jako antiviry, ktere rovnou predpokladaji, ze uzivatele spousti exace z pornostranek.

Jenže zkušenost říká, že je tento předpoklad platný a bezpečnost běžného uživatelského systému by měla být řešena s ohledem na to, že u něj sedí člověk, který je z hlediska bezpečného chování „debil“. Nejde to samozřejmě řešit pouze technickými prostředky ale jsou docela podstatnou součástí toho řešení. A vůbec se nemusí jednat o nějaký hloupý antivirus.

Ale faktem je, ze nejake masove viry tem lidem ten antivirak odchyti a kdybych ze dne na den smazal vsechny antiviraky z kazdeho kompu po celem svete, tak bych tomu stavu nepomohl.

Vidím to podobně jako kdybys vypnul všechny NATy.

[SAM:]

Nejsem purista - NAT provozuji, tam kde je potřeba a nepokládám ho za bezpečnostní prvek. Znám hodně uživatelů s libovolnými Windows, kteří úspěšně sloužili botnetu, přestože byli za NATem. Uvědom si, že infekce většinou přijde přes browser, flash nebo něco takového. A odhalit, který uživatel to je, když jich je za tím natem několik stovek je pak pakárna.

[xkucf03]

A taky NATy, ac se to puristum nelibi, jednoznacne zvysuji bezpecnost koncoveho zakaznika.

Zajímavá otázka. Když se zamyslíš a půjdeš trochu dál, podíváš se, jaké má NAT dopady, tak je to přesně naopak. Uživatelé se spolu nemohou spojit na přímo, musí využívat služeb různých prostředníků, kteří často narušují důvěrnost přenášených informací nebo můžou uživatele odříznout od komunikace; nezřídka nutí uživatele instalovat proprietární (škodlivý) software. Asi nejznámější příklad: Skype.

[Hans1024]

Vzdycky je nejaky prostrednik, u P2P je akorat na jine vrstve. Kryptografii lze zabranit prostrednikovi, aby tu duveryhodnost narusil. Nemyslim si, ze nedostatek verejnych IP adres je duvodem nerozsireni svobodnych sifrovanych alternativ komunikacniho SW. Myslim si, ze vetsine lidi je to proste jedno, nebo to nejsou schopni vysvetlit tem, se kterymi chteji komunikovat a kterym je to jedno.

[Bystroushaak]

O2 afaik dává IPv6/64 ke všem novým xDSL od 2012.

[tom62]

Nejen k novým, i stávající zákazníci nakonec IPv6 (i když o něco později) dostali. U některých modemů to ale znamenalo nutnost aktualizace firmware.

[Pravák Bob]

O2 bohužel neumí na jedné DSL přípojce zároveň IPv6 a pevnou IPv4 adresu. Oficiální vyjádření podpory.

IMHO jen proto že ve formuláři mají jen jedno políčko kde se to dá vyplnit...

[pavlix]

Co vím, tak O2 zaváděla IPv6 mimojiné proto, aby postupem času přestala dávat veřejné IPv4 adresy, natož pevné. Políčko ve formuláři není příčina, nýbrž součást implementace této strategie.

[Luboš Doležel (Doli)]

Už se tak nějaký rok děje. Všichni noví zákazníci jsou za CGN (bohužel i někteří trollové na Abc; proto ještě nedošlo na IP bany).

Osobně doporučuju odejít k T-Mobile xDSL, tam dostane každý zákazník jak IPv6 (/56!), tak veřejnou IPv4.

[elenril]

+1, ta /56 je moc hezká. Jen škoda že k tomu není reverzní DNS, takže to člověk např. na email server moc nepoužije.

[pavlix]

Přeposílat přes virtuál na vpsfree.

[Sten]

Reverz k tomu je možný, když zaplatíte za pevný blok. Jinak není, protože se ten blok po každém restartu modemu může měnit.

[elenril]

To se mi nějak nezdá, moje adresy (v4 i v6) jsou explicitně napsané ve smlouvě, takže by měly být pevné (a za ten skoro rok co je mám se neměnily). A nic extra jsem za to neplatil.

[Luboš Doležel (Doli)]

Taky mám ten pocit, že T-Mobile je v tomto ohledu nadstandardně solidní.

[Sten]

To máte Profi ADSL? Ale pokud máte pevné adresy, tak můžete na infolince požádat o delegaci reverzu.

[elenril]

Mám úplně normální VDSL pro běžné lidi. I v ceníku se píše

Nedílnou součástí služby je přidělení IP adresního prostoru. V ceně služby Internet ADSL/VDSL je přidělení jedné veřejné IPv4 adresy a veřejného statického rozsahu IPv6 o velikosti /56

Na podporu jsem volal, říkali mi že reverzní DNS se pro běžné smrtelníky vůbec nedělá.

[Sten]

Zajímavé, ceníkové informace ale budou nejpřesnější. Asi v té informaci, co mám, měli na mysli, že to je jen pro Profi ADSL.

[Luboš Doležel (Doli)]

To se mi nezdá. To by si pak žádný nový zákazník nemohl pořídit veřejnou IPv4 adresu.

[Bystroushaak]

O2 bohužel neumí na jedné DSL přípojce zároveň IPv6 a pevnou IPv4 adresu. Oficiální vyjádření podpory.

Vzhledem k tomu, že rok a půl zpátky jsem dělal firemní podporu korporátů, tak prostě vím, že to není pravda.

Oficiální vyjádření podpory.

To jako že to máš černé na bílém v podobě dopisu, který je podepsaný vedoucí oddělení? Pokud ne, tak to není oficiální vyjádření.

IMHO jen proto že ve formuláři mají jen jedno políčko kde se to dá vyplnit...

Lol. Tak možná obchoďačky.

[Pravák Bob]

Vzhledem k tomu, že rok a půl zpátky jsem dělal firemní podporu korporátů...

Prací na korporátní podpoře O2 bych se nechlubil, zrovna dneska jsem tam volal.

To jako že to máš černé na bílém v podobě dopisu, který je podepsaný vedoucí oddělení?

Pardon, mám vyjádření z 31. 10. 2013 od člověka s funkcí Internal Account Manager. Jestli to je dostačující, netuším.

Lol. Tak možná obchoďačky.

To s tím políčkem ve formuláři byl vtip...

[Bystroushaak]

Prací na korporátní podpoře O2 bych se nechlubil, zrovna dneska jsem tam volal.

Rozhodně se tím nechci chlubit, protože to byla pěkně nahovno práce v mnoha ohledech. Což je taky důvod, proč jsem odešel.

Jinak oddělení, kde jsem pracoval už dnes ani neexistuje. Všechno se to od té doby několikrát sloučilo, rozloučilo, odloučilo, změlnilo a preskupilo, že bych se ani nedivil, kdyby korporáti dneska volali k úplně stejným lidem, jako běžní zákazníci.

Pardon, mám vyjádření z 31. 10. 2013 od člověka s funkcí Internal Account Manager. Jestli to je dostačující, netuším.

Je to písemně s podpisem?

To s tím políčkem ve formuláři byl vtip...

To by ses ještě divil. Když IPv6 zavedli, tak neupravili interní aplikace, takže tam opravdu nebylo nic, kam by to mohli napsat, nehledě na to, že z 4 hodinového školení si většina lidí neodnesla vůbec nic, takže to pak podle toho vypadalo.

[Lord Vetinari]

A pak samozřejmě, IPv6 by mohlo zničit biznis mnoha firmám, protože v okamžiku kdy by každé zařízení mělo veřejnou adresu, by už nikdo nepotřeboval služby typu Skype, různé webové úschovny apod. Takže vlastně se dostáváme k tomu, že zavedení IPv6 do běžné praxe u koncových uživatelů je vlastně silně nežádoucí z obchodního hlediska.

To je perla na urovni komentara chemika,ze nikto nebude chodit na benzinove stanice, ved benzin si dokaze kazdy uvarit doma sam.

[Sten]

A přitom se z přesně tohoto důvodu do benzínu přes padesát let lil (patentovaný) tetraethyl olova místo ethanolu.

[frdrx]

Dneska se jako antidetonační přísada používá ferrocen.

[Petr Tomášek]

A pak samozřejmě, IPv6 by mohlo zničit biznis mnoha firmám, protože v okamžiku kdy by každé zařízení mělo veřejnou adresu, by už nikdo nepotřeboval služby typu Skype, různé webové úschovny apod. Takže vlastně se dostáváme k tomu, že zavedení IPv6 do běžné praxe u koncových uživatelů je vlastně silně nežádoucí z obchodního hlediska.

Naopak. S IPv6 bude daleko jednodussi sledovat jednotlive uzivatele (ani Privacy Extension proti tomu prilis nepomohou), takze prinejmensim firmy jako Google/Facebook/Apple/Microsoft se budou snazit protlacit IPv6 co nejdriv. Kdyby nebylo IPv6 tak zprasene, tak uz by ho byvali protlacili davno...

[Luboš Doležel (Doli)]

ani Privacy Extension proti tomu prilis nepomohou

To se mi nezdá.

Nejvíc mě ale udivuje, že češti "velikáni" jako idnes.cz, lidovky.cz nebo ihned.cz IPv6 nemají. U serverhostingů je to dnes už snad samozřejmost.

[cezz]

(ani Privacy Extension proti tomu prilis nepomohou)

Mozes to nejak rozviest? Mne sa zda, ze Privacy Extension prinasa zhruba rovnaku anonymitu ako IPv4 NAT:

• IPv6 prefix je verejny - to je zhruba alternativa verejnej IPv4 adresy
• nahodne vygenerovana cast IPv6 adresy sa pravidelne meni, takze rovnako ako za IPv4 NAT si s odstupom casu nevies (len na zaklade adresy) spojit rozne requesty, resp. nemas istotu ze ide o ten isty stroj.

[MP]

Jak je resen druhy bod v pripade, ze druha strana autorizuje klienta prave pomoci IP adresy?

[Sten]

Kromě toho, že to je velmi hloupý a velmi snadno obejitelný způsob autorizace? Tak třeba že se použije jen prefix.

[pavlix]

Používá se jako doplňková ochrana nebo jako negativní autorizace (IP ban).

[MP]

Jaky prefix? Jak treba na FW, ktery ridi pristup do VPN tunelu pres IP adresy bude fungovat pristup klienta, kdyz bude mit Privacy Extension?

    inet6 2a01:f123:1234:5bd0:21f1:f624:d2b8:3702/64 scope global temporary dynamic 
       valid_lft 86314sec preferred_lft 2914sec
    inet6 2a01:f123:1234:5bd0:222:15ff:fe64:42bd/64 scope global dynamic 
       valid_lft 86314sec preferred_lft 86314sec

[pavlix]

Prefix /64 má stejnou vypovídací hodnotu jako jedna natovaná IPv4 adresa, takže třeba ten.

[Sten]

Akceptuje vše od 2a01:f123:1234:5bd0::/64

[MP]

Coz mi ve chvili, kdy identifikace klienta jest tvorena druhou pulkou IP6 asi tezko pomuze, ne? A na potvoru ta druha pulka se meni skrz PE.

[Sten]

Pokud něco identifikuje klienta podle IP adresy, tak je to špatně navržené.

[MP]

A jak asi funguji iptables? Firewall v ASA? ACL v switchich? Nebo snad chcete rict, ze je nutny mit celou sit pod certifikatama, aby se dali identifikovat klienti? Vcetne voip,switchu a ja nevim jakych vsech zarizeni s IP adresou?

[cezz]

Ak nutne potrebujes identifikovat na zaklade IP adresy (teda na zaklade informacie, ktora sa prenasa nesifrovana.. ale povedzme ze ti to nevadi) tak proste vypnes PE na danom zariadeni a mas. Alternativne ak to klientska aplikacia podporuje, povies jej aby pri spojeni pouzivala staticku IP namiesto docasnej.

Inak kazdy normalny firewall vie robit filtrovanie na zaklade prefixu jak na IPv4 tak na IPv6. Cize co pisem vyssie je mozno pripad riesenia konkretnej serverovej aplikacie, ktora robi identifikaciu na zaklade IP ale nevie prefix.

[Sten]

iptables i Cisco ASA umí filtrovat prefixy.

Klienty v lokální síti lze identifikovat podle MAC adres. Nicméně i v tomto případě vidím takovou identifikaci vhodnou tak maximálně pro debugging problémů. Snad všechny switche i VoIP telefony podporují autentizaci alespoň jménem a heslem, pokud už rovnou neumí SNMP s klíči.

[xkucf03]

Není to chyba, jako hrubý filtr je to dobré řešení. Pokud víš, že se někam připojuješ jen z práce, z domova a ze školy, tak ti stačí povolit tři IP adresy (nebo tři rozsahy) a odfiltruješ tím většinu útočníků nebo prudičů. Pro připojení odjinud se dá přidat VPN nebo stroj se SSH fungující jako brána.

U IPv4 je více uživatelů schovaných za jednou IP adresou (NAT). U IPv6 je víc uživatelů schovaných za jedním rozsahem (PE). Ta vypovídací hodnota je srovnatelná a v tomhle směru to IMHO vyjde nastejno. V čem vidí odpůrci IPv6 rozdíl? Já tam vidím naopak výhodu v tom, že když chci, můžu se spojit na přímo s konkrétním zařízením a nemusím používat nějaké pochybné metody na obcházení NATu. A když se na přímo spojovat nechci, tak si to zakážu na firewallu.

[Sten]

IP adresa se dá celkem snadno podvrhnout. Možná to většinu slovníkových útoků odfiltruje, ale pokud vás takové útoky vůbec ohrožují, tak vám ten filtr nejspíš stejně nepomůže (ty útoky mohou jít i třeba ze zavirovaného počítače připojeného do té školní sítě). Naopak, pokud škola či práce změní IP rozsah nebo se chcete připojit z hotelu na druhé straně oceánu, protože ta záložní metoda připojení třeba už nefunguje, protože ji nikdo nezkoušel.

Filtr na IP adresy je security through obscurity. Doporučuji mít odevšud z vnější sítě stejný způsob připojení, takže máte otestované, že funguje, i když ho budete potřebovat z jiného místa. Všechny modernější systémy včetně mobilů VPN umí automaticky připojovat a spravovat.

[pavlix]

Pomůže to úplně stejně jako identifikovat klienta s IPv4 NAT adresou.

[Ondrej 'SanTiago' Zajicek]

Neni mi jasne, co vlastne potrebujes. Pokud potrebujes identifikovat pocitace ve vlastni siti, tak proste pouzij DHCPv6, zakaz SLAAC a adresy se ti menit nebudou. Pokud potrebujes identifikovat externi klienty pripojujici se pres Internet, tak prakticky je identifikace pomoci /64 prefixu stejne dobra (nebo lepsi) jako identifikace pomoci jedne IPv4 adresy.

[pavlix]

To lze řešit úplně stejně jako s NATem. Tak jako se za IPv4 NAT adresou skrývá více klientů, tak se i za IPv6 64-bit prefixem skrývá více klientů. Spolehlivost autorizace zůstává stejná.

[Petr Tomášek]

Jo a jak často se to, prosímtě, mění? 1x za den? 1x za hodinu? To je takový problém dát na stránku kód, který jednou za 10s pingne s příslušnou cookie server velkého bratra? Pokud bude velký bratr vědět, jak často se "neveřejná" část adresy bude měnit, tak na základě statistiky z toho bude moci zjistit, jestli se jedná o jeden stroj nebo víc. A stačí, aby se v rámci té periody, co zůstane suffix stejný člověk jednou "profláknul" a hnedle jsou identifikovatelné i ostatní přístupy.

Ne, prostě mě nepřesvědíš, není nad poctivý NAT...

[H0ax]

tak v době, kdy na tebe prakticky všechno napráská browser, a to si můžeš mazat cache atd. jak chceš, mi přijde zbytečné řešit rádoby anonymitu stylem ipv6 vs. nat

[Petr Tomášek]

cookies se dají povypínat, existují rozšíření, které snižují pravděpodobnost/přesnost identifikace např. blokováním trackerů a javascriptů, tak proč si ji nějakým dementním IPv6 uměle zase zvyšovat?

[xkucf03]

privoxy

[kralyk z abclinuxu]

Zajímavé, ale jak si to poradí s https?

[xkucf03]

Nic moc. Ale dovedu si představit podobnou proxy, pomocí které bys vlastně dělal MITM útok sám na sebe – v prohlížeči by pak stačilo mít jedinou CA a ta proxy by se starala o kontrolu certifikátů¹ a směrem k prohlížeči to posílala podepsané/zašifrované tím svým certifikátem. A zároveň by to mohlo filtrovat reklamy, šmírovací skripty a obrázky a další malware. Případně by to mohlo některé stránky/služby úplně přetvořit – např. místo YouTube a dalších by ti to poslalo jednoduchou XHTML stránku s webm/mp4/ogv videem.

P.S. sakra, zase další projekt, na který bych si měl najít čas

_{[1] což mne vlastně na tuhle myšlenku před časem přivedlo – chtěl bych mít stejná pravidla pro kontrolu certifikátů ve všech prohlížečích nebo obecně klientech a chtěl bych si je nastavovat přesně podle svého}

[pavlix]

Ale dovedu si představit podobnou proxy, pomocí které bys vlastně dělal MITM útok sám na sebe

Ve firemní praxi se tímto realizuje centrální proxy se svoji vlastní politikou certifikátů.

[xkucf03]

To bych zrovna nepovažoval za „sám na sebe“.

[pavlix]

To záleží na úhlu pohledu. Je to MITM výhradně na firemní počítače, technicky vzato na počítače bezmezně důvěřující firemní certifikační autoritě.

[Sten]

A jak ten NAT zařídí, že ta cookie nebude pingat server velkého bratra?

[Petr Tomášek]

V browseru zakážu cookies a pak velký bratr nedokáže zařízení rozpoznat od ostatních za NATEm. S IPv6 je to holt jeden faktor v rovnici, který mu umožňuje zpřesnit identifikaci (nikde jsem netvrdil, že se jedná o faktor jediný).

[trekker.dk]

Jednou za čas koukám do logů webserveru a zatím to vychází, že se každý rok podíl IPv6 přístupů zvyšuje tak o 1 procentní bod. Nic moc, ale aspoň něco.

[perteus]

momentalne mam konecne modem, ktery podporuje IPv6 od t-mobile. Zkusil jsem a po dvou dnech jsem musel ipv6 ve windows a na linuxu co bezi doma zakazat, nebot s tim byly problemy. Nenacital se treba seznam, nebo to dlouho nacitalo. Urcite to bude prkotina a az budu mit cas tak urcite doresim. Ma michodem nekdo zkusenost s OpenDNS IPv6? Maji to zatim jako SandBox, ale treba byl u me problem s DNS od TM a tohle by mohlo pomoci.

A nebo, to je problem na strane serveru a pak si ja muzu hrat jak chci, ale kdyz si admini neoptimalizuji servery pro beh na IPv6 ma koncovy zakaznik smulu. A tak se proste IPv6 vypne a ve statistikach kvuli tomu je stale IPv4, protoze to koncovemu zakaznikovi funguje. To je jen muj laicky pocit.

[trekker.dk]

kdyz si admini neoptimalizuji servery pro beh na IPv6 ma koncovy zakaznik smulu

Co to je optimalizace serveru pro běh na IPv6?

Jinak špatně fungující IPv6 dost často řeší prohlížeče, AFAIK třeba takový Firefox, když se během necelé vteřiny nepřipojí na IPv6 adresu, automaticky přejde na IPv4.

[kralyk z abclinuxu]

Nenacital se treba seznam, nebo to dlouho nacitalo.

Kéž bych dostal € vždycky, když tohle od někoho slyšim...

[bigBRAMBOR]

no prave, roste to tak pomalu, a spousta velkych firem porad ipv6 nepodporuje, takze se dá očekávat ze to umre a nahradí se to nejakou hnusnou ojebávkou ktera jeste prodlouzi život IPv4.

[Sten]

U Googlu se to každý rok přibližně zdvojnásobí.

[TM]

Fanatičtí radikálové mně samozřejmě budou nadávat, ale je myslím jasné, proč je praktické přijetí IPv6 tak vlažné.
Navržené je to velmi komplikovaně se snahou dělat vše jinak než dříve - a to za jakoukoliv cenu. Přínosy těch řešení jsou většinou diskutabilní. Ta celková deviantnost je vidět už třeba i v tom, jakým způsobem se přidělují adresy. Proč má třeba koncový zákazník mít nesmyslný prefix /64 a proč vlastně není oficiálně podporovaná možnost to rozdělit na menší subsítě? Jsou opravdu nezbytné local-link adresy? Proč není navrženo a implementováno plnohodnotné DHCP? Proč je vnucováno odvozování IP adres od MAC? Proč je zápis IP adres takový, aby byl vlastně nezapamatovatelný? Atd...
Prakticky vše tam je při migraci problematické, stojí to spoustu času a nervů.

[Luboš Doležel (Doli)]

Samozřejmě se mýlíte. Oficiální možnost používat menší podsítě existuje, stejně tak jako používat DHCPv6. Jenže ono je snazší a rychlejší používat právě ty automaticky dopočítané adresy.

Jsou opravdu nezbytné local-link adresy?

Link-local adresy jsou velký přínos. Ale když je nechcete, tak si jich prostě nevšímejte.

Proč je zápis IP adres takový, aby byl vlastně nezapamatovatelný?

A jak byste to chtěl zapisovat?

Prakticky vše tam je při migraci problematické, stojí to spoustu času a nervů.

IPv6 jsem nasazoval už několikrát, i jsem portoval aplikace a bylo to zcela bez problémů. Ba co víc, byla to větší pohoda než s IPv4.

[TM]

Tak to mně asi něco uniklo. Samozřejmě, že /64 síť můžete rozdrobit na menší(např. pokud budete vše nastavovat staticky), ale nikdo vám nezaručí, že s tím pak nebudou problémy pokud vám statická konfigurace nebude později vyhovovat.
DHCPv6 přece není plnohodnotná náhrada DHCP na v4 sítích.
Pokud vím, o obou těch věcech se vedly léta spory.
Co se týče zápisu - uznávám, že je to subjektivní - ale já si prostě lépe pamatuju dekadická čísla, oddělená tečkou, bez vynechávání nul. Proč 128 bitů, když s tím pak plýtvám jako šílenec a kdejaký hejhula má vlastně přiděleno 2^64 adres, které nikdy v historii vesmíru nebudou využity? Chápu, že to souvisí s MAC, ale proč vlastně odvozovat IP adresy zařízení na síti od jejich MAC a pak vymýšlet berličky kvůli soukromí apod.?

Přeme se ale myslím zbytečně. IPv6 tady je a těžko si lze představit, že jej nahradí něco rozumnějšího - na to už není čas ani zdroje. Je to ale samozřejmě škoda, že jej tenkrát navrhovali lidé odtržení od praxe.

[Luboš Doležel (Doli)]

DHCPv6 přece není plnohodnotná náhrada DHCP na v4 sítích.

Je tam komplikace s výchozí bránou. Zkusil jsem experimentálně zkombinovat radvd a dhcpd6, kdy radvd propaguje lokální prefix (/64) a globální prefix (/96) spolu s AdvManagedFlag on a také AdvAutonomous off u toho /96 bloku. dhcp6 pak přidělovalo adresy v rozsahu toho /96 bloku a chodilo to, aspoň s Windows jako klientem.

Výchozí brána na klientovi byla klasicky link-local adresa, takže problém s výchozí bránou je asi podobnou kombinací SLAAC a DHCPv6 "vyřešený".

Android DHCPv6 neumí, tam to takhle nešlo.

Pokud vím, o obou těch věcech se vedly léta spory.

To je pravda. Já považuju SLAAC za super věc, ale nechápu, proč by měla být povinnost to používat.

Chápu, že to souvisí s MAC, ale proč vlastně odvozovat IP adresy zařízení na síti od jejich MAC a pak vymýšlet berličky kvůli soukromí apod.?

A do toho ještě skutečnost, že u DHCPv6 se namísto MAC adres používá DUID, jehož vypovídací hodnota je podobná /dev/random.

[paul2no]

Stejně by mě zajímalo, proč je DHCPv6 takové jaké je, a navíc jak píšete že třeba Android ho vůbec nepodporuje. Když je autokonfigurace, tak výsledné adresy jsou odvozené od MAC adres a není v tom žádný systém. U DHCP(v4) vidím právě výhodu v tom, že IP adresy je možné (na základě MAC) přidělovat zařízením systematicky podle nějakého plánu. S IPv6 aby si pomalu i v domácí síti člověk zprovoznil lokální DNS server.

[Luboš Doležel (Doli)]

Když je autokonfigurace, tak výsledné adresy jsou odvozené od MAC adres a není v tom žádný systém.

Výhody to samozřejmě má. Vyměním prefix u lokální adresy a vím, jakou globální adresu ten stroj má.

S IPv6 aby si pomalu i v domácí síti člověk zprovoznil lokální DNS server.

mDNS stačí, žádný server pak nepotřebujete. Linuxové distribuce to asi stejně instalují by default. (Adresa pak má tvar názevPC.local)

[pavlix]

Fedora má by default v Avahi vypnuté IPv6 a glibc/nss-mdns neumí link-local adresy.

[Sten]

třeba Android ho vůbec nepodporuje

Protože nemusí.

Když je autokonfigurace, tak výsledné adresy jsou odvozené od MAC adres a není v tom žádný systém

Když je autokonfigurace, tak výsledné adresy mohou být odvozeny víceméně libovolně (jen několik bitů je pevně daných podle způsobu odvození). Systém je v tom víceméně stejný jako při dynamickém přidělování adres s DHCPv4.

U DHCP(v4) vidím právě výhodu v tom, že IP adresy je možné (na základě MAC) přidělovat zařízením systematicky podle nějakého plánu

Pro většinu sítí v tom nevidím žádnou výhodu (nejčastější použití DHCPv4 je hlavně k tomu, aby bránilo kolizím, které u IPv6 SLAAC díky 64-bitovému poolu nehrozí) a pro zbytek je IMO lepší statická konfigurace, ale pokud to opravdu chcete, tak DHCPv6 tohle umí taky.

S IPv6 aby si pomalu i v domácí síti člověk zprovoznil lokální DNS server.

Proč?

[kralyk z abclinuxu]

Liší se SLAAC a DHCPv6 nějak principielně? Mně přijde, že to je jiná implementace víceméně téhož...

[pavlix]

Principiálně liší v tom, že DHCP je založené na jediném kontraktu (dvou v případě dualstacku) s danou platností, pod který spadá veškerá konfigurace, zatímco router discovery je jen snůška náhodných údajů, každý může být z jiného zdroje a každý má vlastní časovou platnost. Z hlediska provozu i bezpečnosti je router discovery zcela nevhodný koncept, zatímco DHCP trpí pouze dílčími problémy a v základu je to přesně to, co potřebuješ.

[Michal Kubeček]

Podstatné rozdíly jsou dva. Za prvé: DHCPv6 je stavová konfigurace, tj. musí tam být nějaký server, který přiděluje adresy a pamatuje si, komu co a na jak dlouho přidělil; SLAAC je bezstavový model, kde router jen oznámí společné parametry a adresu si koncová stanice de facto přiřadí sama. Bezstavový model je podstatně jednodušší na implementaci i na zdroje, ale moc se nehodí, pokud potřebujete implementovat nějaké politiky apod. Druhý rozdíl je v tom, že DHCPv6 umožňuje předat víc informací, takže je možná i varianta, že základní konfigurace (adresa a gateway) se nastaví podle RA a o zbytek si stanice řekne DHCP serveru; abych pravdu řekl, moc smyslu v tom nevidím, ale možné to je.

[pavlix]

Bezstavový model je podstatně jednodušší na implementaci i na zdroje

Přesto byl problém ho korektně definovat a implementovat.

základní konfigurace (adresa a gateway) se nastaví podle RA a o zbytek si stanice řekne DHCP serveru; abych pravdu řekl, moc smyslu v tom nevidím, ale možné to je.

V tuto chvíli je to spíše nutné.

[Michal Kubeček]

Myslel jsem tím spíš to, že v tom kombinovaném řešení nevidím moc výhod oproti tomu, když si přes DHCP řeknu rovnou o všechno. Ale asi ano, pořád tam zůstává ta výhoda, že si server nemusí vést evidenci leases (nebo aspoň ne pro všechny stanice).

Ono se obecně dá těžko odhadnout, co se v praxi bude používat a jak. Dřív jsem si třeba myslel, že fragmentace u IPv6 má být naprosto okrajovou záležitostí, které je žádoucí se pokud možno vyhnout - než jsem zjistil, že pro jednoho z našich zákazníků je posílání (obrovského množství) 3KB UDP datagramů přes IPv6 denním chlebem.

[pavlix]

Myslel jsem tím spíš to, že v tom kombinovaném řešení nevidím moc výhod oproti tomu, když si přes DHCP řeknu rovnou o všechno.

Ani já ne.

Ale asi ano, pořád tam zůstává ta výhoda, že si server nemusí vést evidenci leases (nebo aspoň ne pro všechny stanice).

Popravdě nevidím jako reálnou výhodu ani to.

[Sten]

Myslel jsem tím spíš to, že v tom kombinovaném řešení nevidím moc výhod oproti tomu, když si přes DHCP řeknu rovnou o všechno. Ale asi ano, pořád tam zůstává ta výhoda, že si server nemusí vést evidenci leases (nebo aspoň ne pro všechny stanice).

To je přesně ten důvod, proč to existuje. Můžete tak třeba mít několik DHCP serverů na různých částech sítě, které spolu nekomunikují. Stejně tak se nic nerozbije, i pokud DHCP server (což je typicky třeba modem) restartujete.

Dřív jsem si třeba myslel, že fragmentace u IPv6 má být naprosto okrajovou záležitostí, které je žádoucí se pokud možno vyhnout - než jsem zjistil, že pro jednoho z našich zákazníků je posílání (obrovského množství) 3KB UDP datagramů přes IPv6 denním chlebem.

Fragmentaci není nutné se vyhýbat (IPv6 dokonce definuje minimální MTU 1 280 bajtů, ale minimální podporovaná délka paketů je 1 500 bajtů, takže fragmentace je už přímo tady), IPv6 to ale řeší tak, že fragmentují jen koncové body, ne mezilehlé routery, což občas vedlo k velkém množství velmi malých fragmentů (např. pokud jeden router měl MTU 1 500 bajtů, další 1 480 a další 1 460).

[Ondrej Santiago Zajicek]

Par poznamek:

V prve rade ke treba odlisit mechanismus SLAAC (RFC 4862) od samotneho mechanismu RS/RA (RFC 4861).

Mechanismus RS/RA distrubuuje informaci o on-link prefixech a (implicitne) o defaultni routeru a tyto informace se autokonfiguruji v hostech. SLAAC je mechanismus, jak na zaklade RS/RA provest autokonfiguraci IP adresy na hostech.

Zatimco SLAAC je nepovinny a je mozne ho nahradit konfiguraci IP adresy dle DHCP serveru, tak AFAIK informace o on-link prefixech a defaultni brane se takto nepredavaji a je treba k tomu vyuzit RS/RA. Tedy je povinne, aby router posilal RA a host je zpracovaval.

Duvodu je nekolik. V prve rade je to odlisny mechanismus urceni on-link prefixu na IPv6. Zatimco na IPv4 se to urci podle prefixu pridelene adresy, tak na IPv6 je to nezavisly mechanismus, ktery vyuziva mimo jine informace z RA. Je tedy mozne, aby host mel IP adresu z jednoho prefixu a informaci o tom, ze dalsi tri prefixy jsou na danem interface on-link.

Dalsi duvod je reseni redundance defaultniho routeru bez triku jako sdileni IP adresy.

V principu by tyto informace mohl poskytovat i DHCP server, ale neni to dobry napad - napr. CE router muze okamzite prestat propagovat sam sebe jako defaultni router v okamziku, kdy mu spadne uplink. To by se pres spolecny DHCP server propagovalo podstatne sloziteji.

[pavlix]

Duvodu je nekolik. V prve rade je to odlisny mechanismus urceni on-link prefixu na IPv6. Zatimco na IPv4 se to urci podle prefixu pridelene adresy, tak na IPv6 je to nezavisly mechanismus, ktery vyuziva mimo jine informace z RA.

Taková informace by mohla stejně dobře být poskytována pomocí DHCP.

V principu by tyto informace mohl poskytovat i DHCP server, ale neni to dobry napad

To si nemyslím.

napr. CE router muze okamzite prestat propagovat sam sebe jako defaultni router v okamziku, kdy mu spadne uplink. To by se pres spolecny DHCP server propagovalo podstatne sloziteji.

Není vůbec nutné používat společný DHCP server a případně by nebyl problém toto implementovat jako součást DHCP relay, pokud chceme společný DHCP server používat. Osobně mi to připadá jako pouze zdánlivá výhoda, která neospravedlňuje použití jinak ve všech ohledech horšího a navíc chybně specifikovaného protokolu.

[Sten]

Není vůbec nutné používat společný DHCP server a případně by nebyl problém toto implementovat jako součást DHCP relay, pokud chceme společný DHCP server používat.

To by ale znamenalo, že leasy musí být velmi krátké. Platnost RA u multihomed systémů je často nastavená třeba jen na desítky sekund, zatímco platnost IP adres je typicky v řádech hodin.

[pavlix]

To by ale znamenalo, že leasy musí být velmi krátké.

Non sequitur.

Platnost RA u multihomed systémů je často nastavená třeba jen na desítky sekund, zatímco platnost IP adres je typicky v řádech hodin.

Myšlenka krásná, ale používá se to vůbec někde mimo laboratoř?

[Sten]

Myšlenka krásná, ale používá se to vůbec někde mimo laboratoř?

Více různých RA ano, ale nevím o tom, jestli tam používají stavové DHCPv6 nebo SLAAC.

[Ondrej Santiago Zajicek]

Multihomed systemy me prijdou jako problematicky use case, daleko jednodussi use case je proste l2 sit v ramci vetsi organizace, ktera ma kvuli redundanci dva routery do zbytku site. Tam je taky treba mit RA s velmi kratkou platnosti.

Krom toho, kdybys tam mel DHCP server spolecny temto dvema (ci vice) routerum, tak tam mas zas dalsi centralni prvek. Mohl bys mit dva DHCP servery, kazdy na kazdem routeru, s tim, ze host si ziska lease od kazdeho z nich jenom pro ucely propagace default gateway. Ale to uz jsme dost daleko od konceptu DHCP.

[pavlix]

Nicméně to pořád ještě neříká, zda bylo lepší koncept DHCP rozšířit nebo vytvořit nový protokol. V každém případě by ten nový protokol mohl být trochu lepší kvality.

[Ondrej Santiago Zajicek]

Taková informace by mohla stejně dobře být poskytována pomocí DHCP.

Zatimco host se uci on-link prefixy z RA od vsech routeru na siti, v pripade, ze by to dostaval od jednoho DHCP serveru (se kterym ma vztah), pak by se ta data musela distribuovat od routeru na DHCP server.

Není vůbec nutné používat společný DHCP server a případně by nebyl problém toto implementovat jako součást DHCP relay, pokud chceme společný DHCP server používat.

Spolecnym DHCP serverem jsem nemyslel DHCP server spolecny pro vice siti, ale situaci, kdy by vice routeru na jedne siti propagovalo informace na jeden DHCP server, ktery by je pak announcoval hostum. Namisto stavajici situace s RA, kdy to routery announcuji primo hostum.

Nicmene pripklad s DHCP serverem spolecnym vice sitim je dalsi case, kdy se hodi mit per-link specificke informace (jako IP adresy ci brana) konfigurovane z jineho zdroje nez DHCP.

Osobně mi to připadá jako pouze zdánlivá výhoda, která neospravedlňuje použití jinak ve všech ohledech horšího a navíc chybně specifikovaného protokolu.

V cem je chybne specifikovany? Me ta specifikace prijde jako vicemene primocara a jasna.

[Sten]

Hlavním důvodem je to, že bez RA klient neví, jak je síť řešená (SLAAC, stavové či bezstavové DHCP či jiná metoda v budoucnu) nebo jestli vůbec má globální adresy

[Sten]

DHCPv6 je stavová konfigurace, tj. musí tam být nějaký server, který přiděluje adresy a pamatuje si, komu co a na jak dlouho přidělil

Pouze pokud je to stavový DHCPv6. Existuje i bezstavový, o kterém se sám zmiňujete dále.

Bezstavový model je podstatně jednodušší na implementaci i na zdroje, ale moc se nehodí, pokud potřebujete implementovat nějaké politiky apod.

SEND

základní konfigurace (adresa a gateway) se nastaví podle RA a o zbytek si stanice řekne DHCP serveru; abych pravdu řekl, moc smyslu v tom nevidím, ale možné to je.

A přitom je to mnohem používanější způsob DHCPv6.

[Sten]

Samozřejmě se mýlíte. Oficiální možnost používat menší podsítě existuje, stejně tak jako používat DHCPv6. Jenže ono je snazší a rychlejší používat právě ty automaticky dopočítané adresy.

Nikoliv. Klienti by to sice měli umět, ale vy byste to neměl pro normálně přidělované adresy (2000::/3) používat. Viz RFC 4291:

All Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field

Navíc protože byste to neměl používat, tak třeba routery to mohou odmítat a Mikrotik to tak i dělá. Podle RFC 7421 to je možný výklad RFC:

Router implementors might interpret IETF specifications such as RFC6164 and RFC7136 as indicating that prefixes between /65 and /126 (inclusive) for unicast packets on-the-wire are invalid

Kromě těchto problémů v sítích s prefixem nad /64 nefunguje třeba ani multicast (RFC 3306 a RFC 3956).

[Luboš Doležel (Doli)]

Tak to je docela na prd. Kor když tu máme ISP jako O2, co člověku strčí jeden /64 a nazdar.

[Sten]

O2 to takhle dělá v rozporu s RFC 6177 (it should be easy for an end site to obtain address space to number multiple subnets) a 7368 (Customer Premises Equipment should consider the lack of sufficient address space to be an error condition, rather than using prefixes longer than /64 internally). Bohužel je to ale moc nezajímá, takže řešení je pouze protestovat peněženkou a zvolit jejich konkurenci, která příslušná RFC dodržuje.

[pavlix]

Problém je v tom, že pokud člověk znalý sítí používá O2, zpravidla to samo o sobě značí absenci nebo horší dosažitelnost konkurence.

[Sten]

Kde je O2 ADSL, tam je i T-Mobile ADSL

[pavlix]

Tak aspoň že tak. Otázka je potom, kolik z toho provozuje O2 a jestli nakonec člověku nebudou způsobovat problém obě firmy.

[Ondrej Santiago Zajicek]

Ta zminka v RFC 6177 je pouze vagni doporuceni, RFC 6177 sam rika o odstavec vyse: "anything of length /64 or shorter works from a standards perspective". Takovehle operacni zalezitosti jsou vicemene mimo kompetence IETF, spise je to zalezitost adresni policy RIRu a jednotlivych ISP.

Druhou zminovanou citaci RFC 7368 neobsahuje. Ta citace me pripomela pozadavek z RFC 7084:

"The IPv6 CE router MUST be prepared to accept a delegated prefix size different from what is given in the hint. If the delegated prefix is too small to address all of its interfaces, the IPv6 CE router SHOULD log a system management error."

To je ale standard pro CE routery, zminujici co ma router delat, kdyz nedostane, co v DHCP pozadoval, ten O2 v principu porusovat nemuze (ledaze by dodavalo i vlastni CE routery). Tva citace 'CPE should consider the lack of ...' ma velmi podobny vyznam.

[Sten]

To dohromady říká, že /64 stačí jako základní alokace, ale klient by měl mít možnost snadno získat kratší prefix.

Nebyla to přímo citace RFC 7368, ale shrnutí z RFC 7421, co RFC 7368 požaduje. Konkrétní citace z RFC 7368 by byla tato:

Rather than attempt to contrive a method for a homenet to operate in a constrained manner when faced with insufficient prefixes, such as the use of subnet prefixes longer than /64 (which would break stateless address autoconfiguration [RFC4862]), the use of NPTv6, or falling back to bridging across potentially very different media, it is recommended that the receiving router instead enters an error state and issues appropriate warnings.

[Bystroushaak]

O2 by ti na požádání mělo dát /56 či /48. Alespoň nám to říkali na školení. Problém asi bude to vysvětlit někomu z obchodního, kde je slušná šance, že vůbec nebudou vědět o čem je řeč.

[Sten]

Proč má třeba koncový zákazník mít nesmyslný prefix /64?

Koncový zákazník má mít dle RFC 6177 možnost získat alespoň /56 (/48 podle staršího RFC 3177), pokud o to požádá. Bohužel ne všichni ISP tohle dodržují.

proč vlastně není oficiálně podporovaná možnost to rozdělit na menší subsítě?

Protože celá filosofie IPv6 je založena na sítích, ne na jednotlivých stanicích. Z toho důvodu dělí adresu na prefix (síť) a interface ID. Pro všechny normálně přidělované adresy (2000::/3) je v RFC 4291 definováno, že prefix má 64 bitů a interface ID druhých 64 bitů. (Mimochodem jeden z původních návrhů IPng byl založen stejně jako IPv4 na jednotlivých stanicích a používal 64bitové adresy. Až později se při řešení problémů, kdy se něco týká mezisíťového a kdy lokálního provozu, přišlo s rozšířením na 128 bitů a definitivním rozdělením těchto dvou.)

Jsou opravdu nezbytné local-link adresy?

Ano, jsou nezbytné pro SLAAC a lokální multicast (třeba hledání routerů či DHCP serverů).

Proč není navrženo a implementováno plnohodnotné DHCP?

Plnohodnotné DHCP navrženo i implementováno je, ale preferované řešení pro domácí uživatele je SLAAC.

Proč je vnucováno odvozování IP adres od MAC?

Protože na fyzické vrstvě musí být v lokální síti unikátní, takže v odvozených adresách nemohou vzniknout kolize. Nicméně tohle se týká jen link-local adres, pro globální adresy (při zapnutém SLAAC) klient EUI/MAC používat nemusí.

Proč je zápis IP adres takový, aby byl vlastně nezapamatovatelný?

Protože 128-bitové číslo si pravděpodobně stejně nezapamatujete, ať má jakýkoliv zápis.

[pavlix]

Protože 128-bitové číslo si pravděpodobně stejně nezapamatujete, ať má jakýkoliv zápis.

Moje zkušenost je taková, že si pamatuju IPv4 a IPv6 adresy úplně stejně. Přidělený prefix si člověk při práci s jednou sítí velmi brzy zapamatuje a zbytek se u strojů, kde má smysl si to pamatovat, dá přidělovat úplně stejně.

[xkucf03]

Proč je zápis IP adres takový, aby byl vlastně nezapamatovatelný?

Jestli jsou tam tečky nebo dvojtečky je celkem jedno – důležitý je počet bajtů. Např. v mém případě si u IPv6 stačí pamatovat šest bajtů a zbytek už je na mě, jak si rozdělím (klidně souvislá řada čísel). Ale u IPv4 si musím pamatovat tři bajty pro IP adresy přidělené v první vlně a jiné tři bajty pro později přidělené adresy. Zbytek je opět souvislá řada, jen si nemůžu vybírat a je v tom prostoru dost těsno. Navíc si musím pamatovat, do které skupiny, který stroj patří.

Ve výsledku si nepamatuji ani IPv6 ani IPv4 adresy (od toho mám DNS), takže je to vlastně jedno. Jen si občas při prohlížení logu řeknu: tahle adresa je mi povědomá, ta bude asi moje (platí pro IPv4 i IPv6), ale abych měl jistotu, tak si to stejně musím přeložit. Nejsem prostě síťař, který by každý den obcházel klientská zařízení a bouchal do nich IP adresy z hlavy

[tom62]

Nedávno jsem se snažil si IPv6 nastavit. Mám doma VDSL modem (mám O2) v režimu bridge, PPPoE spojení vytváří server s Debianem. Tento pak má veřejnou IPv4 adresu a také je mu přidělena IPv6 (u O2 bych, pokud vím, měl mít /64). Ze serveru se přes IPv6 s okolím spojím. Nastavit to tak, aby IPv6 adresy z příslušného rozsahu měly i PC na místní síti a mohly IPv6 používat, se mi ani po delším čtení nejrůznějších návodů zatím nepodařilo. Vzdal jsem to s tím, že IPv6 vlastně zatím nepotřebuji, tak proč s tím ztrácet další čas.

Dříve jsem měl router s DD-WRT nebo Tomato firmwarem (zkoušel jsem oba) a ani na jednom IPv6 spolehlivě nefungovalo. Občas se to chytlo, občas ne.

[Luboš Doležel (Doli)]

Stačí povolit forwarding u IPv6 (net.ipv6.conf.all.forwarding) a nastavit radvd. Mám velmi podobný setup (PPPoE na serveru), akorát mám IPv6 přes he.net. Do zahraničí to má dokonce pozitivní dopad na latenci, jelikož zahraniční konektivita O2 je špatný vtip.

[tom62]

A můžete mi prosím pomoci, jak nastavit radvd v případě, že prefix předem neznám a mění se (respektive může měnit)? Našel jsem tohle, nicméně i po spuštění wide-dhcpv6-client si radvd stěžuje, že no auto-selected prefix on interface br0, disabling advertisements.

[pavlix]

Není lepší na toto použít hotové řešení v podobě OpenWRT? To je osvědčené, odzkoušené a odpovídá standardům. A mimochodem radvd nepoužívá a řekl bych, že je to dobré rozhodnutí.

[tom62]

Netvrdím, že nebylo. Nicméně před nedávnem mi přestal fungovat zmiňovaný router s DD-WRT a před objednáním nového jsem došel k tomu, že vše, co dělal, by měl zvládnout HP MicroServer s Debianem, který mi tu stejně celý den běží.

[pavlix]

Neměl by být až takový problém si to OpenWRT (co se týče síťové konfigurace) přenést i do toho Debianu. Ale i při stavění řešení „od nuly“ je potřeba uvážit, zda je radvd vhodným řešením. Mně tak nepřipadá, já ho považuju spíše za démonka pro testování klientů než cokoli jiného.

[Luboš Doležel (Doli)]

Jediné řešení, které mě napadá, je na br0 automaticky nastavit adresu podle toho, co je přiřazeno na ppp0 od ISP. Pak by měl fungovat i automatický výběr prefixu pro radvd na br0.

[Luboš Doležel (Doli)]

Ah, viz níže. Nenapadlo mě, že se tam ještě musí použít DHCP.

[pavlix]

Neděste mě, možná brzo budu muset přejít na O2 ADSL a vůbec z toho nemám radost. Pohorším si úplně ve všech parametrech a ještě jim za to budu cpát peníze do chřtánu.

[Luboš Doležel (Doli)]

Jdi raději k T-Mobile. Ten to sice jen přeprodává od O2, ale noví zákazníci tam stále mají veřejné IPv4 adresy a pak celý /56 blok pro IPv6.

[pavlix]

Ale co ostatní parametry? Uvažoval jsem i o tom, že bych veškerý traffic tuneloval k jinému ISP a pak by mi byly adresy dost jedno.

[Luboš Doležel (Doli)]

Ostatní parametry jsou taky u T-Mobile stejný (cena a rychlost). T-Mobile je možná lepší v tom, že máš stejnou cenu i bez závazku (akorát nemáš modem zadarmo nebo tak něco) - ale nejsem si 100% jistý.

Dřív si hodně lidí stěžovalo na nižší rychlost u T-Mobile, ale zdá se, že to je teď stejné jako u O2.

[Ondrej Santiago Zajicek]

No, domaci hranicni router (v tvem pripade ten server) by se mel chovat takto:

1) pomoci DHCP si na uplinku vyzadat prefix

2) ten nastavit na downlink rozhrani

3) na downlink rozhrani ho propagovat pomoci RA

Pokud to nefunguje, je dobre vedet, ktery z techto kroku selze. Prvni dva by mel snad zajistit DHCP klient (a nebo staticka konfigurace). Druhy muze zajistit radvd, ale ten minimalne ve starsich verzich vyzadoval explicitni konfiguraci propagovaneho prefixu. Nebo je mozne pouzit BIRD, ten umi posilat RA s tim, ze propagovane prefixy odvodi z aktualniho stavu/konfigurace sitoveho rozhrani.

[neklan]

O IPv6 se nezajímám, protože je to věc, kterou nikdo nechce, ale i z toho mála co vím se mi IPv6 nelíbí.

fe90::21c:65ff:ef16:ecac - to má být jako co? to, co budu zadávat do nepředstavitelně zalagovaném draxu na serveru někde v tramtarii několikrát? to je to, co budu kontrolovat znak po znaku jestli je vyplněno dobře a bez překlepů?

V každý diskusi o IPv6 už od jeho počátku přijde někdo normální a zeptá se proč třeba nějak evolučně nerozšířit IPv4 jako třeba přidat pár bitů do adresy místo 172.16.254.1 by bylo 172.16.254.1.10 každá současná IPv4 adresa by se stala adresním rozsahem atd... vždy se roztrhne pytel s autistickejma matfyzákama, kteří ho setřou jakej je ignorant, že tahle to prostě nejde a jak je to celé uplně blbé.

Přitom od samotného začátku musel být vždy alespoň jeden takový "blbec", který se na to zaptal, bylo mu vysvětleno, že je blbec a on se rozhodl, že se IPv6 zabývat nebude. Nikdo si nepoložil zcela logickou otázku, jestli na těch dotazech něco není, byla to asi chyba.

Co se tedy stalo bylo naprosto logické, IPv6 nic nikomu nepřináší akorát komplikace, velké změny, problémy a hlavně náklady, náklady, náklady. Domácím zákazníkům je nějaký IPv6 uplně buřt, facebook zchecknou klidně i za NATem, torrenty v pasivním režimu taky tak nějak jedou a pro hračičky se dá veřejná IP za kilo měsíčně a máme dokonce zisk za pronájem abstraktího čísla, které jsme dostali přidělené zdarma. A teď chci vidět jak někdo přijde s IPv6 řešením a vytlačí mě z trhu, on bude mít dvojité náklady, protože IPv4 bude muset udržovat tak jako tak, nebude mít kilo z pronajímání veřejných IP, zato hromadu starostí s podporou polofunkčního IPv6 a přitom nebude schopen poskytnout nic reálně obchodovatelného a relevatního pro zákazníka navíc.GLHF

Výsledkem je tedy postupný vznik komoditního trhu s IP adresami, protože světe div se, naprostá většina lidí je ochotná zaplatit peníze navíc jenom za to, aby se IPv6 nemuseli zabývat. To samo o sobě je nejlepší zhodnocení "kvalit" IPv6. V nejbližších minimálně pěti letech nemá IPv6 reálnou šanci se prosadit, IPv4 adresy neustále "docházejí" už aspoň deset let, ale adres je stále dost. Sice už je má někdo přidělené, ale trh si poradí a optimalizuje jejich užití tím jak jejich cena poroste.

Kolik lidí na světě potřebuje veřejnou IP natolik, že za ní zaplatí? Podle mě moc ne. A tak situace bude dál fungovat tak, jako doposud. IPv4 budou ať už v šedé zóně, nebo podle mě brzy naprosto bez okolků obchodovány jako komodita, facebookaři budou mít NAT a IPv6 ostrouhá. Minimálně 5 let se bude tedy pořád jenom žvanit o tom, že IPv6 je super a jak IPv4 "zase" dovházejí, jinak se nestane naprosto nic.

[Bystroushaak]

+1

fe90::21c:65ff:ef16:ecac - to má být jako co? to, co budu zadávat do nepředstavitelně zalagovaném draxu na serveru někde v tramtarii několikrát?

Představ si ještě, jaká sranda je to diktovat po telefonu, specificky pak ještě někomu, kdo vůbec netuší co to je.

[pavlix]

A vzhledem k tomu, že je to link-local adresa, tak navíc někomu, komu bude úplně k hovnu. Jinak samotná MAC adresa se po telefonu diktuje běžně při zřízení konektivity nebo výměně zařízení.

[pavlix]

Překlep v čísle nepočítaje.

[Luboš Doležel (Doli)]

V každý diskusi o IPv6 už od jeho počátku přijde někdo normální a zeptá se proč třeba nějak evolučně nerozšířit IPv4 jako třeba přidat pár bitů do adresy místo 172.16.254.1 by bylo 172.16.254.1.10 každá současná IPv4 adresa by se stala adresním rozsahem atd... vždy se roztrhne pytel s autistickejma matfyzákama, kteří ho setřou jakej je ignorant, že tahle to prostě nejde a jak je to celé uplně blbé.

Jenže to je úplná pravda, jste ignorant. Zjednodušeně řečeno, přidáním bitů do IPv4 adresy vzniklo právě IPv6. Do hlavičky IPv4 nemůžete jen tak přidat bity navíc a tvářit se, že to je pořád IPv4.

Rozdíl je jen v tom, že u IPv6 se těch bitů přidalo víc (když už musí vznikat nekompatibilní protokol), takže je pak výhodnější adresu zapisovat hexadecimálně.

Řešením pro obtížný přepis adresy je používání (m)DNS. Nebo můžete diktovat jen MAC adresu a člověk na druhé straně může zbytek nechat dopočítat.

Výsledkem je tedy postupný vznik komoditního trhu s IP adresami, protože světe div se, naprostá většina lidí je ochotná zaplatit peníze navíc jenom za to, aby se IPv6 nemuseli zabývat.

Ne. Jsou ochotní za ně platit kvůli problému chicken-egg. ISP kupují IPv4 adresy, jelikož ne vše je dostupné přes IPv6. Poskytovatelé obsahu kupují IPv4 adresy, protože ne všichni uživatelé mají IPv6.

[kralyk z abclinuxu]

V každý diskusi o IPv6 už od jeho počátku přijde někdo normální a zeptá se proč třeba nějak evolučně nerozšířit IPv4 jako třeba přidat pár bitů do adresy místo 172.16.254.1 by bylo 172.16.254.1.10 každá současná IPv4 adresa by se stala adresním rozsahem atd...

No jasný, nebo by se mohly začít používat vyšší čísla jako třeba 824.0.0.1 a byl by problém vyřešen. Protože IPv6 všechno řeší složitě čistě z plezíru, že... OMG.

Teď vážně: Místo IPv6 klidně bejvalo mohlo být navrženo nějaké zpětně kompatibilní rozšíření IPv4, jenže tím bys narazil na úplně stejné problémy - stejně by všichni museli investovat do podpory rozšíření a situace by byla úplně stejná, akorát by ten protokol byl zprasenej.

[neklan]

Ano mám ten pocit, že IPv6 všechno řeší složitě čistě z plezíru.

Řeší neexistující problém = že IPv4 adres není dostatek

Volí nevhodný postup = revoluce namísto evoluce

Řešení je komplikované = ošklivé adresy human unfriendly adresy, problémy s dhcp, podivná autokonfigurace a určitě by se toho našlo víc

Stačí regulační poplatek pár dolarů na ip adresu a najednou jich bude dost. Kdo nerozdává adresy jako ožralej milionář bude mít marginální výdaj, kdo drží zbytečně statisíce adres a k ničemu je nepotřebuje se chytne za nos. To je nejlepší a nejlevnější řešení, které se de facto děje už nyní spontáně v rámci šedé zóny a právní rámec na sebe podle mě nemusí nechat dlouho čekat.

[kralyk z abclinuxu]

Jak si představuješ evoluční řešení by mě opravdu zajímalo.

Stačí regulační poplatek pár dolarů na ip adresu a najednou jich bude dost.

To je hodně naivní názor.

Velké korporace si klidně zaplatí tisíce $ za fůru IP adres, úplě stejně jako třeba za domény. Na druhou stranu obyčejní uživatelé jako třeba já ten poplatek pocítí mnohem víc. V důsledku nemam možnost si připojit zařízení k internetu aniž bych za to platil. Opravu nevim, proč bych měl platit horentní částky za jednu blbou IP adresu jen pro to, že nějakej šmudla se bojí hexa čísla. Sic transit gloria mundi.

[Heron]

Jenže tohle přináší problémy, které musí zaplatit někdo další, případně všichni ostatní.

S IP adresami nemůžete obchodovat po jedné, nejmenší BGP rozsah je (afaik) /24, pro celou IPv4 by to znamenalo 16mil položek v routovacích tabulkách. Některý routery nezvládají ani půl milionu. A vy to ještě chcete ztřicetinásobit.

Tohle je mimochodem také odpověď na vaši otázku, proč je ip adresa tak dlouhá (a to jak ipv4 (4mld., což se zavádělo v době, kdy na síti bylo tak 100 strojů, tak ipv6 dnes, kdy jsou miliardy strojů). Čím delší adresa, tím lépe se dá rozsekat do stromu a tím méně routovacích záznamů je potřeba.

Nasazování IPv6 odkrylo jeden fakt, že většina lidí vůbec neví, jak vlastně sítě fungují, proč tak fungují a na základě svých chabých znalostí vymýšlejí řešení, které je mnohem horší nebo úplně nefunkční. Včetně toho vašeho.

[Ondrej 'SanTiago' Zajicek]

nejmenší BGP rozsah je (afaik) /24

Striktne vzato BGP muze pracovat s jakymikoliv prefixy, ale prakticky vam jakykoliv delsi prefix (tedy kratsi rozsah) nez /24 ostatni ISP odfiltruji.

[neklan]

Každé řešení bude něco stát, otázka je které bude nakonec zvoleno. Jestli to bude výkonější router nebo jiný protokol nerozhodujeme nejspíš ani jeden v míře dosatečné na to ovlivnit celosvětové trendy. Stejně tak je jedno jestli a jak moc rozumím sítím.

Adresy se nedají obchodovat po jedné? Například Franta od vedle má jednu adresu koupenou, pronajatou, půjčenou - no prostě je teď na nějakou dobu jeho a má ji napsanou ve smlouvě. Oh wait, I just Did!

Nějaká vyhynulá zebra a položky někde na routeru nejsou v tomhle vůbec postatné. To je technická záležitost, technikovi prostě dáte zadání a on bude dělat to co se po něm chce, dokud se nenajde někdo levnější. Dost malých ISP má klienty v jedné síti, /24 subnet je nějakých 250+- použitelných adres. Tak si ISP pronajme/koupí 250 adres a ty pak bude pronajímat zákzníkům. Hotel taky není vždycky plný až po střechu a každý host nemusí být zaznamenaný na katastru nemovitostí nebo zařizovat přechodné bydliště (Protože by to bylo náročné), ale světe div se taky to funguje. Když se zákazník přestěhuje do humpolce, tak si logicky nebude moci vzít sebou svojí IP adresu = rozhovor na 30 sekund: Přenést adresu nejde, v novém místě dostanete novou od poskytovatele, s tím se domluvte a zařiďte se podle toho. Hotovo šmitec, jasný jak facka i poslednímu Jardovi od městských služeb.

A vy technycy tady na mě s BGP a 128-pokojovym adresování, zaprvý nevím co to je, zadruhý mě to uráží a už vůbec mě to nezajímá. Já mám internety vysokorychlostní od Pepy za tři kila měsíčně a pohoda, děcka na tom sediou skoro pořád, takže mám klid u kopané.

A to se bavíme to tom 00.prd procenta lidí, kteří vůbec veřejnou adresu chtějí, mají a potřebují, ostatním je to naprosto šumák a co dostanou to budou mít a hotovo, dokud pujde facebook tak o nich neuslyšíte. Zatímco na IPv6 se nepodívají ani na Idnes a "nebude jim fungovat internet".

Veřejných IPv4 adres je něco přes 4 miliardy a jsem přesvědčen, že je to pro naší planetu dostatek, protože naprostá většina lidí a zařízení nikdy žádnou veřejnou adresu potřebovat nebude. A aby bylo z celýho světa vidět kolik mám v chlaďáku braníků přes internet of things si klidně nechám ujít a když o to jó bude zájem, tak se to zmákne i přes IPv4 NAT port forwarding apod. Snažím se oponovat tvrzení, že IPv6 je jediným možným a nejlepším řešením. Provoz přes IPv6 se za poslední rok zvedl z 3.2 na 6.5 procent nebo tak nějak? Víte o kolik rostl trh s IPv4 adresami?

[Michal Kubeček]

Hotovo šmitec, jasný jak facka i poslednímu Jardovi od městských služeb.

Jistě. Čím méně toho člověk o problematice ví, tím je mu všechno jasnější.

[pavlix]

Bit a pokoj nemají zrovna moc společného.

[Heron]

Adresy se nedají obchodovat po jedné? Například Franta od vedle má jednu adresu koupenou, pronajatou, půjčenou - no prostě je teď na nějakou dobu jeho a má ji napsanou ve smlouvě. Oh wait, I just Did!

No, to je sice hezké, pravděpodobně je to udělané tak, že se mu to na tu "jeho" veřejnou překládá někde na posledním routeru toho ISP a ve vnitřní síti má nějakou lokální. Což je taky moc příjemné. Hodně dobře se potom řeší, když dva takový klienti chtějí komunikovat mezi sebou.

Rozhodně ten ISP tu jednu adresu neprodá nějakému jinému ISP v Austrálii. Takže to obchodování je značně omezené.

Tak si ISP pronajme/koupí 250 adres a ty pak bude pronajímat zákzníkům

Nekoupí, nepronajme. Došly.

a potřebují

Tohle je asi největší důkaz naprosté neznalosti toho, jak fungují sítě. Adresu, nejlépe globálně adresovatelnou, potřebuje každý uzel. Rozlišování na potřebují a nepotřebují je největší zvěrstvo. To klidně mohou ISP poskytovat pouze spojení na proxy server a bude to fungovat úplně stejně. Takový uzel stejně není připojen na internet.

A vy technycy tady na mě s BGP a 128-pokojovym adresování, zaprvý nevím co to je, zadruhý mě to uráží a už vůbec mě to nezajímá. Já mám internety vysokorychlostní od Pepy za tři kila měsíčně a pohoda, děcka na tom sediou skoro pořád, takže mám klid u kopané.

Jo jo, přesně tak. Vůbec nevíte jak to funguje, ale budete do toho kafrat.

A aby bylo z celýho světa vidět kolik mám v chlaďáku braníků přes internet of things si klidně nechám ujít a když o to jó bude zájem, tak se to zmákne i přes IPv4 NAT port forwarding apod.

Tohle je přesně důkaz toho, že ipv4 adresy došly a že je potřeba přejít na jiné adresní schéma. Port forwarding je zneužívání čísel portů (což je vyhrazeno pro služby) na "rozšíření" adres (každá ip se tak může tvářit, že je to vlastně 65tis dalších adres). Jo jo, úžasné řešení.

[Ondrej 'SanTiago' Zajicek]

Nekoupí, nepronajme. Došly.

To, ze dosly, znamena akorat to, ze LIR (ISP) jiz nedostane pridelene nove od RIRa (RIPE a pod.), ale stale je muze sehnat (pronajmout) prefixy od jinych LIRu a dost mozna vznikne i oficielni moznost pridelene prefixy prevadet za kompenzaci (tedy defacto prodat).

[neklan]

když dva takový klienti chtějí komunikovat mezi sebou

Jenže oni nechtejí, nepotřebují a ani nevědí, že by měli. Honza nahraje fotku na facebook nebo uloz.to a Jarda si to odtamtud stahne. To je realita, model chování, use case řikejte tomu jak chcete, ale prostě to tak je, dělá se to tak, moje matka v důchodu to tak dělá, stejnak jako synovec na základce to tak dělá. Takto se internet používá. Budete je obcházet po jednom se Strážným RFC a přesvědčovat je, že jsou uplně blbý, dělají to špatně a měli by to dělat jinak, protože je to proti filosofii... čeho vlastně nebo koho.

Budou s IPv6 internety levnější? Jestli ne, tak asi smolík.

Nekoupí, nepronajme. Došly.

Nedošli, je jich dost. Jen je potřeba je lépe rozdělit na základě úplně jiných pravidel než se dělo doposud. Akorát se nebudou přidělovat zadarmo nějakou "autoritou", ale budete je "nakupovat u telekomu". Podle stejné logiky došli pozemky v čechách už pár set let dozadu. Další zdarma už nebudou. Kupodivu svět stojí dál.

Adresu, nejlépe globálně adresovatelnou, potřebuje každý uzel

Nevím jestli každý uzel musí mít adresu nebo ne, par miliard uzlu by mělo pro tuhle planetu stačit a basta, žádný zbytečný rozmazlování tý verbeže líný ajťácký. Kolik je potřeba uzlů na milion domácích koncových uživatelů?

je zneužívání čísel portů

Jednou jsou to moje porty, tak si do nich budu strkat, co budu chtít a jestli budu chtít mít na portu 54786 forwarding na vzdálené ovládání intezity análního kolíku, tak ho tam mít budu i kdybyste se na hlavu stavěl. Do toho nikomu nic není do mejch portů, do mejch análních kolíků, do prdele.

Jo jo, přesně tak. Vůbec nevíte jak to funguje, ale budete do toho kafrat.

Asi nerozumíte nadsázce a snaze Vás přiblížit bežné realitě dramatickou formou. Nezlobím se za to na vás. Pokud máte pocit, že tu teď se vši vážností řešíme budoucnost IPv6, dobereme se rozumného výsledku, který potom dokážeme celosvětově prosadit, tak je to vtip na vtip. Odtržení od reality u vás pozoruji značné. například to, že nejde dost dobře routovat rozsah pod /24 použijete jako argument, že nejde obchodovat s IP adresami. Já bych vám ukázal, co všechno se dá prodat a to, že to prodat fyzicky nebo technicky nejde je drobnost, jde prodat i to, co vůbec neexistuje. Marketing se pohybuje naprosto mimo hranice aristotelovké logiky.

[pavlix]

Jenže oni nechtejí, nepotřebují a ani nevědí, že by měli. Honza nahraje fotku na facebook nebo uloz.to a Jarda si to odtamtud stahne. To je realita, model chování, use case řikejte tomu jak chcete, ale prostě to tak je, dělá se to tak, moje matka v důchodu to tak dělá, stejnak jako synovec na základce to tak dělá.

A koho to zajímá, jak Honza používá internet?

[Ondrej 'SanTiago' Zajicek]

Honza nahraje fotku na facebook nebo uloz.to a Jarda si to odtamtud stahne.

No, az mu ulozto nahlasi 'Z teto IP adresy se jiz stahuje, pockejte', protoze jeho ISP ho spolu z dalsima dvema stovkama schoval za jednu verejnou IP adresu, tak uvidi, ze je nekde problem.

Jednou jsou to moje porty, tak si do nich budu strkat, co budu chtít a jestli budu chtít mít na portu 54786 forwarding na vzdálené ovládání intezity análního kolíku, tak ho tam mít budu i kdybyste se na hlavu stavěl.

Pokud budes kvuli nedostatku IP adres schovan za NAT na strane poskytovatele (tak, jak to dnes delaji mikroISP), tak si ani ten port forwarding sam nenastavis.

[kralyk z abclinuxu]

Nedošli, je jich dost. Jen je potřeba je lépe rozdělit na základě úplně jiných pravidel než se dělo doposud. Akorát se nebudou přidělovat zadarmo nějakou "autoritou", ale budete je "nakupovat u telekomu".

Proč? Proč bych měl nakupovat u telekomů něco, čeho můžu mít s IPv6 zdarma kvanta? Telekomy už tak ždímaj lidi na všem možný a ty bys jim jetě nahrával do krámu? Ty budeš asi telekom, že? Jedinej důvod, kterej jsi zatím uvedl, je, že nejsi schopen si zapamatovat IPv6 adresu, což sorry, ale to je tvůj problém.

[neklan]

Myslím, že už jsem pochopil hlavný důvod nedorozumění. Vy se bavíte o tom, jak by to mělo být podle vás správně a dobře a já se snažim bavit sarkastickou formou o tom, jak to podle mě asi tak bude.

Váš pohled na formu správného přístupu k problému rozdání všech adres stromových autorit pro USA a Evropu nebudu nijak rozporovat, asi máte na toto lepší znalosti než já - Já například mám všude IPv6 vypnuté. Je mi jasné, že je to teď asi jediná cesta, jak se posunout dál, přes všechny nedostatky jeho nedostatky a moje obavy, které z velké části pramení ze současného (nadcházejícího) období koexistence IPv4 a IPv6.

Ohledně IPv6 pro koncové zákazníky, nemá smysl se v nejbližších pár letech vzrušovat. Velcí hráči, kteří mají podle mě největší vliv na rozšíření, mají svoje jisté, menší hráči budou NATovat, jako doposud. Budou šméčka s IPs, dokud to nepřeroste únosnou mez, tak s tím IPv6 nic neudělá. Velcí telco hráči jsou v hodně státech evropy regulovaní státem a na popud státní regulace může IPv6 časem projít, to bych si dokázal představit. Např. pro začátek tím, že zakážu nazývat "připojení k internetu" IPv4 za NATem pomocí nějakého usnesení rvhp nebo tak něco. Samoregulací si to nedovedu představit, možná je to možné, ale nevím jak. Ti, co vlastní nejvíce IP adres, tak v podstatě vlastní současný internet, resp. jeho podíl. A zadarmo se ho vzdávat dobrovolně nebudou, to bych se divil. Konspirace ohledně vlivu Skype, uložišť a tak podobně nevyznávám, ale na druhou stranu je pravda, že umožnění komunikace všech se všemi po internetu by bylo obrovským krokem demokratizace sítě. Sdílení souborů po chatu by běželo všem a vždy a šifrovaně. V poslední dekádě se internet proměnil hodně, směrem k demokratizaci však podle mě nespěje.

[kralyk z abclinuxu]

No, já osobně například BGP moc do hloubky taky nerozumim. Mně ani tak nejde o to, jak by to mělo být správně, já bych prostě chtěl veřejnou IP adresu (nebo lépe blok) a aby tu možnost měli pokud možno i ostatní, aby se s tím mohlo počítat při psaní webových služeb, software, apod. Tohohle se s IPv4 nedočkám. Tudíž jsem pro IPv6, to je celý

Že to reálně nebude zítra ani pozítří, to je mi jasný... (Ale už mam aspoň tunel od CZ.NIC když už nic jinýho).

[kralyk z abclinuxu]

9/11 trolling.

[Mrkva]

Jojo, stacilo by povolit aby v IP adrese nebyly cisla jen 0-255 ale slo to do 999, pak se ta IP adresa ani nebude muset prodlouzit :)

[Michal Kubeček]

No a IPv6 jde právě ještě dál a povoluje i písmena. :-)

[Ondrej 'SanTiago' Zajicek]

To je nejlepší a nejlevnější řešení, které se de facto děje už nyní spontáně v rámci šedé zóny a právní rámec na sebe podle mě nemusí nechat dlouho čekat.

Ono se da argumentovat presne opacne - to, ze se IPv4 adresy rozdavali (pro LIRy) za pakatel, umoznovalo udrzovat status quo. Zatimco domacnosti a mikroISP s adresama setrili a meli NATy kde to jde, tak LIRove meli adresy skoro zadarmo, mohli tedy kazdemu zakaznikovi pridelit aspon jednu IP adresu a nemeli motivaci se situaci moc delat.

Dnes uz LIRove dalsi prefixy nedostanou, sve stavajici mohou preprodavat na sedem trhu, a tak koukaji, jak pripojovat zakazniky bez alokace verejnych adres. A protoze pouzivani stateful NAT je v takovem meritku podstatne problematictejsi nez stateless technologii, tak to dnes vypada, ze nejlepsi reseni bude bude pouzit nekterou z technologii na bazi A+P pro IPv4 v kombinaci s IPv6 tranzitni siti - npapr. MAP ci 4rd.

Uzivatel dostane pridelen rozsah portu na verejne IPv4 adrese, ktery muze pouzivat pro svuj IPv4 provoz, a jeho domaci router udela pro IPv4 provoz NAT do tohoto rozsahu a nasledne to zabali ci prelozi do IPv6 paketu a ten posle ISP. Ten to na hranici ze sve site ven bezestavove vybali/prelozi do regulerniho IPv4 provozu. Obdobne zpet. Sekundarni dusledek je pak nasazeni nativniho IPv6 v siti ISP i pro uzivatele.

[Sten]

O IPv6 se nezajímám, protože je to věc, kterou nikdo nechce, ale i z toho mála co vím se mi IPv6 nelíbí.

Samozřejmě, nikdo to nechce, proto firmy jako Cisco, IBM, Microsoft, Google, Nokia či Huawei do toho investovaly několik desítek let vývoje a miliony dolarů a firmy jako T-Mobile, Verizon a UPC to nasazují

V každý diskusi o IPv6 už od jeho počátku přijde někdo normální a zeptá se proč třeba nějak evolučně nerozšířit IPv4 jako třeba přidat pár bitů do adresy místo 172.16.254.1 by bylo 172.16.254.1.10 každá současná IPv4 adresa by se stala adresním rozsahem atd... vždy se roztrhne pytel s autistickejma matfyzákama, kteří ho setřou jakej je ignorant, že tahle to prostě nejde a jak je to celé uplně blbé.

Hlavní důvod, proč se to kompletně změnilo, je, že by každá změna IP adres stejně znamenala kompletní výměnu všech zařízení a přepsání tuny software, který s delšími adresami prostě nepočítal, tak proč to rovnou neudělat i jinak a lépe.

Přitom od samotného začátku musel být vždy alespoň jeden takový "blbec", který se na to zaptal, bylo mu vysvětleno, že je blbec a on se rozhodl, že se IPv6 zabývat nebude. Nikdo si nepoložil zcela logickou otázku, jestli na těch dotazech něco není, byla to asi chyba.

Tihle lidé se začali rojit asi tak deset let poté, co IPv6 již existovalo, testovalo se, ladilo a fungovalo. Většinou jde o lidi, kteří o IPv6 ví málo.

Co se tedy stalo bylo naprosto logické, IPv6 nic nikomu nepřináší akorát komplikace, velké změny, problémy a hlavně náklady, náklady, náklady.

Tohle by udělala každá změna IP protokolu.

Domácím zákazníkům je nějaký IPv6 uplně buřt, facebook zchecknou klidně i za NATem, torrenty v pasivním režimu taky tak nějak jedou a pro hračičky se dá veřejná IP za kilo měsíčně a máme dokonce zisk za pronájem abstraktího čísla, které jsme dostali přidělené zdarma.

Torrenty tak nějak jedou. Nebo taky tak nějak nejedou, pokud jsou za dvojitým či symetrickým NATem. To samé třeba WebRTC či SIP.

A teď chci vidět jak někdo přijde s IPv6 řešením a vytlačí mě z trhu, on bude mít dvojité náklady, protože IPv4 bude muset udržovat tak jako tak, nebude mít kilo z pronajímání veřejných IP, zato hromadu starostí s podporou polofunkčního IPv6 a přitom nebude schopen poskytnout nic reálně obchodovatelného a relevatního pro zákazníka navíc.

Nebude. IPv4 není už u domácích uživatelů potřeba. T-Mobile US provozuje IPv6-only síť s 464XLAT a není to nijak polofunkční. Na rozdíl od vás ale nebude muset shánět nedostatkové adresy, za které už bude muset platit.

Výsledkem je tedy postupný vznik komoditního trhu s IP adresami, protože světe div se, naprostá většina lidí je ochotná zaplatit peníze navíc jenom za to, aby se IPv6 nemuseli zabývat.

Většina lidí je ochotna zaplatit za cokoliv, aby nemusela něco měnit. Tohle by se týkalo jakéhokoliv nového IP protokolu.

V nejbližších minimálně pěti letech nemá IPv6 reálnou šanci se prosadit

IPv6 pokrývá momentálně přes 7 % provozu a každý rok se jeho podíl zdvojnásobuje.

IPv4 adresy neustále "docházejí" už aspoň deset let

IPv4 adresy na mnoha místech již došly. V roce 2011 došly v Asii, v roce 2012 v Evropě a letos v Americe.

Minimálně 5 let se bude tedy pořád jenom žvanit o tom, že IPv6 je super a jak IPv4 "zase" dovházejí, jinak se nestane naprosto nic.

Samozřejmě. Proto IPv6 nabízí už i u české ADSL a mnoho firem přechází na 464XLAT a definitivně opouští IPv4 adresy u domácích uživatelů.

[Michal Kubeček]

Samozřejmě, nikdo to nechce, proto firmy jako Cisco, IBM, Microsoft, Google, Nokia či Huawei do toho investovaly několik desítek let vývoje a miliony dolarů a firmy jako T-Mobile, Verizon a UPC to nasazují

A podle bugů, co mi procházejí rukama, to nasazují opravdu ve velkém.

Nejvíc mne ovšem dostává mantra "IPv6 stojí za prd, protože ho navrhovali akademici odtržení od praxe." Stačí si uvědomit, že ten protokol vznikal začátkem 90. let, kdy právě "akademici" byli víceméně jediní, kdo měl s Internetem nějaké netriviální praktické zkušenosti. (Pro ilustraci: ještě Windows 95 neměly defaultně zapnutou podporu IPv4.) Na dalším vývoji se pak už samozřejmě podílely i firmy z oboru. Kacířská myšlenka: možná že kdyby Internet zůstal převážně akademickým o pár let déle, stihlo se přejít na IPv6 ještě před jeho komercionalizací a dneska jsme měli klid.

[neklan]

Pokud se po mnoha letech mediálmí masáže, poplašných zpráv (Ne, IPv4 adresy opravdu nedošly a ještě dlouho nedojdou, pouze už nedostane každý neomezené množství zadarmo.) a bambiliónech investic pohybujeme lehce nad poměrem homosexuálů, je podle mě naopak na místě otázka, kde je chyba než srdnaté vychvalování nějakých jednotek procent převlékáním je do trička s nápisem "úspěch".

Vemte si příklad analogie s telefoními čísly, ty už se za můj život měnili několikrát, nikoho nenapadlo, že se bude na telefonu vytáčet 654asd4sda654asd6a5s4dasd6as5(např.), meziměsto od ledna samozřejmě s předvolbou f47s:4sd5d:sad4(např.), změnili se čísla z 02/545551 na 222584756 (např.), ale to bylo pro architekty internetu málo cool matrix hackerspace.

Samozřejmě je mi jasné, že nelze jen tak přidat bity do IPv4 a tvářit se, že to je pořád IPv4. Je mi uplně jedno, že adresa, kterou jsem poslal byla nějaka link-local, protože pro příklad je to naprosto dostačující a výborně ilustrující.

A hned se tu pár kokůtků chytlo a neodolalo si kopnout, že jsem ignorant a pod. Ať se v životě daří lépe než doposud, to jim přeji já.

Když někomu ukážete IPv6 adresu, první na co se zeptá je, proč je to tak dlouhé a složité. A na to je samozřejmě jednoduchá odpověď: "Aby každý vocas mohl mít dostatek adres pro všechny atomy na zeměkouli - a to je kúl, ty ignoratská nulo." Hodně lidí tato odpověď neuspokojí, neboť nedává smysl ani po faktické straánce.

[pavlix]

Chybné informace propojené s nesmyslnými přirovnáními a nadávkami. Co tím chtěl básník říci?

[neklan]

To asi nepochopíš

[pavlix]

Zřejmě.

[chrono]

Telefónnych čísel (pri zachovaní dĺžky) môže byť oveľa viac ako IP4 adries. ;)

[Sten]

Pokud se po mnoha letech mediálmí masáže, poplašných zpráv (Ne, IPv4 adresy opravdu nedošly a ještě dlouho nedojdou, pouze už nedostane každý neomezené množství zadarmo.) a bambiliónech investic pohybujeme lehce nad poměrem homosexuálů, je podle mě naopak na místě otázka, kde je chyba než srdnaté vychvalování nějakých jednotek procent převlékáním je do trička s nápisem "úspěch".

IPv4 adresy došly. LIRové (ISP) nedostanou už ani jednu.

Ten hlavní důvod, proč IPv6 stále není tolik rozšířené, je, že se hodně dlouho testovalo a ladilo, aby nebylo nutné jej za pár let zase měnit. A během toho málokdo chtěl kupovat HW pro masové nasazení za miliony, který možná bude umět jen vlastnosti, které reálně úplně nefungují (ostatně spousta přechodových mechanismů je dost nová). Fáze testování byla završena World IPv6 Day v roce 2011. World IPv6 Launch (= IPv6 je oficiálně připraveno pro masové nasazování) byl až v roce 2012.

IPv4 bylo definováno v roce 1978, ale masově používat se začalo až v roce 1983, a tak „brzy“ to navíc bylo jen proto, že přechod byl pro všechny povinný. Pak se následujících dvacet let dolaďovalo „za chodu“.

Protože jde o exponenciálu, tak 7 % dnes znamená přes 50 % za tři roky

Vemte si příklad analogie s telefoními čísly, ty už se za můj život měnili několikrát, nikoho nenapadlo, že se bude na telefonu vytáčet 654asd4sda654asd6a5s4dasd6as5(např.), meziměsto od ledna samozřejmě s předvolbou f47s:4sd5d:sad4(např.), změnili se čísla z 02/545551 na 222584756 (např.), ale to bylo pro architekty internetu málo cool matrix hackerspace.

Přečíslování neměnilo technologii vytáčení. Když se změní IPv4 adresa vašeho modemu, nemění se tím nijak technologie, kterou k vám pakety cestují. (Pro srovnání: DTMF dosáhlo většinového podílu až více než dvacet let po svém uvedení.) Až se změní, možná opravdu budete vytáčet s předvolbou f47s:4sd5d:sad4.

Když někomu ukážete IPv6 adresu, první na co se zeptá je, proč je to tak dlouhé a složité. A na to je samozřejmě jednoduchá odpověď: "Aby každý vocas mohl mít dostatek adres pro všechny atomy na zeměkouli - a to je kúl, ty ignoratská nulo." Hodně lidí tato odpověď neuspokojí, neboť nedává smysl ani po faktické straánce.

To je odpověď na způsob, že českých telefonních čísel je miliarda, protože každý přeci budeme u sebe nosit desítky mobilních telefonů. Tohle přirovnání se seriózně používá tak maximálně pro představu, kolik těch čísel vlastně je, ne proč jich je tolik.

Těch adres (či telefonních čísel) je tolik, protože velké množství se snáze rozděluje do spojitých bloků. U IPv6 to znamená např. jednodušší routovací tabulky. Druhý důvod je ten, že ta délka je mocnina dvojky, což jsou čísla, se kterými počítače umí pracovat nejlépe, a tohle byla nejkratší, se kterou většina v IETF souhlasila jako dostatečně pohodlnou. Původně měl nový protokol (tehdy zvaný SIPP či IPng) mít základní délku 64 bitů (o jednu mocninu víc než IPv4), ale počítalo se s tzv. „cluster addressingem“ a jednotlivé stanice pak měly být adresovány dalšími 64 bity (tohle se navíc mohlo opakovat). Tenhle způsob adresace je sice nevyčerpatelný, ale byl velmi složitý a byla obava, jak to půjde rozumně používat či implementovat v routerech, proto byl zjednodušen na pevně dlouhou, 128bitovou (následující mocnina po 64) adresu a z clusteru se stal prefix.

[Sten]

fe90::21c:65ff:ef16:ecac - to má být jako co? to, co budu zadávat do nepředstavitelně zalagovaném draxu na serveru někde v tramtarii několikrát? to je to, co budu kontrolovat znak po znaku jestli je vyplněno dobře a bez překlepů?

Místo do IPv4 investujte raději do operačního systému, který podporuje copy&paste.

[pavlix]

s/normální/problematiky neznalý/

[Andrej]

Jsem koncový zákazník, IPv6 mám a tuhle dávnou minulost už naštěstí řešit nemusím.

[Petr Tomášek]

Jsem koncový zákazník a sračku IPv6 naštěstí nemám a řešit nemusím.

[kyknos]

Jsem koncovy zakaznik a je mi to u zadku, hlavne ze to funguje.

[kralyk z abclinuxu]

Není potřeba se rozčilovat. Za pár let stejně budeš asimilován do IPv6 master race ať chceš nebo ne, tak nač si zvyšovat krevní tlak :p

[Michal Kubeček]

FYI

[Sten]

Trochu mě překvapuje, že to tam ještě není, Debian i Ubuntu už to tak mají poměrně dlouho.

[Michal Kubeček]

IMHO dost možná právě proto, že distribuce většinou mají svou vlastní konfiguraci, takže tu defaultní z mainline používá jen málokdo.

[petr_p]

Já bych spíš uvítal možnost vypnout IPv4 se současně zapnutým IPv6.

[pavlix]

Asi tak, to by byla legrace, člověk by viděl, co všechno nefunguje.

[Michal Kubeček]

Obávám se, že aby tohle bylo možné, vyžadovalo by to nejdřív hodně práce na reorganizaci kódu.

[Václav "Darm" Novák]

Zrovna pomáhám známému rozchodit port forward kvůli hře LoL a co nenajdu…

If the above steps did not help, please disable IPv6. The League of Legends client is designed to work with IPv4.

Kdyby jim to na IPv6 jen nejelo… Ale oni ještě doporučují vypnout ten protokol úplně :/

[Ondrej 'SanTiago' Zajicek]

Mimochodem, nevite nekdo, zda IPv6 explicitne specifikuje weak nebo strong host model?

Linuxova implementace IPv4 odpovida weak modelu, zatimco implementace IPv6 zrejme odpovida strong modelu. V IPv6 standardech jsem k tomu nic moc nenasel, akorat zminku v RFC 7084 (Basic Requirements for IPv6 Customer Edge Routers):

   WAA-9:   As a router, the IPv6 CE router MUST follow the weak host
            (Weak End System) model [RFC1122]. ...

Tady se pozaduje, aby se domaci routery chovaly dle weak host modelu.

Linuxove routery tedy asi nemohou splnovat RFC 7084 pozadavky pro domaci hranicni routery.

[Michal Kubeček]

Linuxova implementace IPv4 odpovida weak modelu, zatimco implementace IPv6 zrejme odpovida strong modelu.

Proč myslíte? Teď jsem to zkusil a chová se to stejně jako IPv4: přijímá i pakety s cílovou adresou přiřazenou na jiném rozhraní. Pokud chcete, aby to tak nebylo, můžete si to zakázat třeba netfilterem.

[Ondrej 'SanTiago' Zajicek]

Protoze jsem to zkousel vcera a nechovalo se to stejne. Mel jsem node A s dvema rozhranimi A0 a A1 a node B pripojeny na A1, tak mi node A neodpovidal na NS pakety zaslane nodem B dotazujici se na adresu na rozhrani A0.

Je mozne, ze kdybych nejdrive zkusil komunikaci z A do B se zdrojovou adresou z A0, tak by si B ulozil tuto adresu do neighbor cache a pri naslednem pokusu o komunikaci z B do A by NS pakety neposilal, poslal by rovnou datovy paket a ten by byl prijat. To by vedlo k 'falesne weak' vysledku.

[petr_p]

Jaký scope měly postižené adresy? Pokud se bavíme o link scope, tak nedává smysl, aby je stroj přenášel mezi rozhraními, které mohou být na různých linkách.

[Ondrej Santiago Zajicek]

Jednalo se o globalni adresy.

[petr_p]

Není to tím, že duplicate address detection se musí dělat i pro globální adresy a Linux ho dělá jen na rozhraní, kde je adresa přiřazena? Bez úspěšného DAD se adresa nesmí použít, takže se ani nesmí použít v odpovědi na NS.

[Ondrej Santiago Zajicek]

Ono tam je tech potizi vic - napr. uz jen to, ze interface musi byt prihlasen do konkretni multicastove skupiny aby mu dany NS paket dorazil. Takze pro takovou podporu weak modelu by musel byt kazdy interface prihlasen do vsech multicast skupin podle vsech IPv6 adres na danem node.

[Michal Kubeček]

Aha, já zkoušel něco trochu jiného: situaci, kdy se ten paket už ke mně dostane (např. proto, že pro příslušný rozsah je na mne nastavená routa. V případě, že přijde na nějaké rozhraní NS pro adresu nastavenou na jiném, Linux opravdu neodpoví. Ale budu se asi muset podívat do kódu, abych mohl říct, jestli je to tak schválně (asi ano) a proč.

[Sten]

Na takové požadavky asi nebude posílat NDP, že ta adresa patří jemu, takže ten paket nenajde, komu má být doručen. Docela bych se divil, kdyby tahle situace v IPv4 fungovala.

[Ondrej Santiago Zajicek]

Pokud reagujes na pripad 'V případě, že přijde na nějaké rozhraní NS pro adresu nastavenou na jiném, Linux opravdu neodpoví.' tak to na IPv4 v Linuxu funguje - tam Linux AFAIK odpovida na ARP vcelku bez ohledu na to, kteremu rozhrani je ta adresa prirazena.

[Sten]

IPv6 nepředepisuje žádný host model, s výjimkou link-local adres, které mají strong host model.

Situaci v Linuxu popisuje RFC 6419:

For incoming packets, Linux checks if the destination address matches one of the addresses assigned to its interfaces and then processes the packet according the configured host model. By default, Linux implements the weak host model [RFC1122] on both IPv4 and IPv6. However, Linux can also be configured to support the strong host model.

[Ondrej Santiago Zajicek]

Je pravda, ze kdyz odhlednu od NDP, tak z hlediska ostatnich kriterii (napr. zpusobu, jak se vyhledava v routing table) Linux IPv6 spis odpovida weak modelu. Tusite nekdo, co RFC 6419 mysli tim, ze lze Linux nakonfigurovat na strong host model, tedy jak to udelat?

[Sten]

Firewall a nastavení ARP v /proc/sys/net by mělo stačit

[Ondrej Santiago Zajicek]

Tak uz mam taky doma nativni IPv6 konektivitu. Poskytovatel PODA. Podporu IPv6 maji dobre utajenou, na predavacim protokolu ji neuvadeji, dozvedel jsem se o ni vlastne nahodou. Nejdrive jsem je pozadal o dodani parametru konfigurace (DHCPv6 nemaji), ty byly nedostatecne a spojovaci linka vypadala, jako by tam zadna IPv6 brana ani nebyla. Po nekolika mailech s podporou se situace vyresila (meli to rozbite) a ted vse funguje bez potizi.

Deleguji /62 prefix, z nej navic prvni /64 vykousnou na spojovaci linku, takze se daji pouzit jen 3 site. Kupodivu latence je pres IPv6 vyrazne nizsi nez pres IPv4, na IPv4 to nejspis jde pres nejake zpomalovadlo.