Vlákno názorů k článku IPv6 Mýty a skutečnost, díl IV. - Podpora autokonfigurace od Filip Jirsák - Vy jste ale psal o „obrovských ztrátách na...

Vy jste ale psal o „obrovských ztrátách na rychlosti“. Jak zvětšení paketu o hlavičku jiného protokolu způsobí obrovskou ztrátu rychlosti? Ostatně na to zabalení paketu do jiného paketu se taky můžete dívat jako na prodloužení hlavičky.

My se bavíme o IPv4 paketu. Součástí dat IPv4 paketu je například zdrojový a cílový port TCP paketu. Takže běžný NAT, který mění zdrojový port TCP paketu, mění data IPv4 paketu. Shodou okolností je zdrojový port v IPv4 paketu uložen zrovna v tom místě, kam vy byste chtěl ukládat rozšířenou cílovou adresu.

Data IPv4 paketu mění většina NATů, váš určitě také – porty protokolu TCP jsou uloženy v datech IPv4 paketu, takže pokud NAT mění port, musí změnit data paketu.

6to4 tunel je IPv6 paket zabalený do IPv4 paketu a routovaný klasickým IPv4 routováním. Žádné obrovské ztráty na rychlosti se tedy nekonají. Nevím, co si mám představit pod plynulým přechodem, ale síť dostupná přes 6to4 je normálně dostupná z IPv6. U vašeho protokolu také neexistuje plynulý přechod do normálního provozu, protože by se provoz tuneloval skrze IPv4 už navždy.

Víte, váš problém je, že jste jen praktik. Váš rozhled končí někde u malejch firemních sítí s pár počítači. Vaše řešení, která používáte vycházejí z toho, co je na trhu. Což vůbec neznamená, že to děláte špatně, a asi i lépe než teoretici.

V případě IPv6, a návrhu protokolů obecně, nestačí být ale jen praktik. Kdybyste byl trochu teoretik, tak byste ale věděl, že vaše IPv4 extension je jen lehce modifikovaný source routing, a sám byste si odpověděl, proč to nemůže obecně fungovat, ačkoliv pro vaše řešené problémy by to bylo dostačující, což se vám vytrvale snaží pan Jirsák.

Co se vám na argumentaci IPv6 tunelem nezdá? Je to přesně to, co požadujete – propojení dvou bodů používajících nový protokol skrze infrastrukturu IPv4. Rozdíl je jen ve způsobu implementace – IPv6 tunel je daleko robustnější řešení, než to vaše.

Nevadí to, pokud se vám podaří tu novou infrastrukturu dostatečně oddělit od staré. S IPv6 je to zařízeno přirozeně, vy byste tu zpětnou nekompatibilitu musel zajišťovat nějak uměle a složitě. Výsledek by tedy byl stejný – dva nekompatibilní protokoly, ovšem ten váš je náročnější na zpracování i konfiguraci. Což ovšem není žádná novinka.

Jen pro upřesnění. Pilsfree není vhodný příklad překupníka konektivity. Sice nemá vlastní AS používá IP adresy z rozsahu NFX, ale zároveň je jedním ze zakladatelů NFX a generuje zhruba polovinu provozu a platí zhruba polovinu nákladů celého NFX. Takže je zákazníkem sdružení ve kterém má zároveň silné slovo. Rozhodně se nejedná o pozici jako má běžný malý ISP vs velký prodejce konektivity.

V tom, že je to na místě dat, je právě problém. Protože data IPv4 paketu se mohou při průchodu sítí měnit – dělá to třeba NAT.

IPsec je schválený a povolený, když nefunguje, mohou řešit. Otevření TLS kanálu není schválené, nelajzne si z nich nikdo otevřít. Jen taková blbost, když potřebujete mezi dvěma LAN segmenty povolit FTP přenos, tak je to tu akce od října, završená minulý týden, než se to odsouhlasilo a nastavilo. A když mezitím se ukázalo, že třeba mezi těmi LAN segmenty za určitýck podmínek fungoval ping a neměl, tak si to admini šeredně odskákali. Takhle fungují velké firmy.
A co se TLS týče, tak jsem už musel řešit na mnoha místech řadu lahůdek. Včetně toho, že TLS povoleno, ale jen na servery, které předkládaly certifikát podepsaný některými cerifikačními autoritami, co si místní dali na whitelist, jinak se to blokovalo (takže žádný selfsigned certifikát na svém HTTPS/SSTP serveru, ale třeba oid Verisignu už OK). Další oblíbený případ je, že HTTPS ano, ale opravdu pro web, pokud spojení trvá déle a má chrakter tunelu, tak opět ustřižen...
Tohle jsou samozřejmě úlitby L7-firewallové, pokud se do toho přidají úlitby NATové, s kteýrmi obecně VPN protokoly mívají problém, tak opravdu nemám univerzální jendoduché řešení, co bych strčil cesťákovi do ruky a měl jistotu, že bude fungovat odkudkoliv. Pokud by mi IPv6 odboural aspoň ty NATové, co tvoří minimálně polovinu komplikací, tak to jen uvítám.

Jenom jestli to neřešíte jako v IT Crowds. Telefon nezvedají a volajícímu automat pouze přehraje "Zkuste to vypnout a znova zapnout.".

Dobre, tak ne uplne presne to stejny, 6to4 bali jeden protokol do druhyho, zatimco tohle by jen prilepilo rozsirenou adresu do hlavicky. Ale z pohledu prenosu po stary siti, ktera stejne pochopi jen starou adresu a zbytku paketu nerozumi, v tom zadnej zasadni rozdil nevidim.

Máte pravdu, není. 6to4 komunikaci vám nezlikviduje kdejaké standardní IPv4 zařízení po cestě.

A neni to nahodou presne to, co dela 6to4 (pokud pomineme propojeni s nativnim IPv6)? Tedy mam dve ruzny site na dvou ruznych mistech, ke kazdy mam jen jednu verejnou IPv4 adresu a aniz by kdokoliv dalsi musel neco udelat, tak za kazdou muzu schovat dokonce 2^80 zarizeni s neomezenou end-to-end komunikaci.
Jedinej problem je, pokud nemam verejnou IPv4 adresu, pak to nepujde. Ale na tom si uplne stejne vylame zuby i to navrhovany lepsi reseni, nebo snad ne?

Na letišti asi ne. V těch firmách, pokud by byly na IPv6 a já měl IPv6 komunikující klienty a spojení až domů do firmy, tak se dostanu IPsecem ven bez problému k nám do firmy. Aktuálně nedostanou, protože jejich NAT bedna to przní.
Měli snahu to nastavit, aby to fungovalo, ale nedařilo se. Což znám celkem dobře i ČR, kde existují provideři, od kterých zkrátka IPsec přes NAT nefunguje a sami udávjaí, že jejich NAT bedna to przní a neví co s tím, připlattě si za veřejnou IP.

NAT nemá smysl řešit

Ve vaší teorii možná. V praxi se ovšem NAT vyskytuje. Vaše řešení by tedy bylo možné použít jenom tam, kde je zaručeno, že cestou žádný NAT (ani nic podobného) není – nevím, jak byste to zařídil.

To můžeme s IPv6 tunelem taky. Ovšem ten váš protokol bychom mohli zavést až v okamžiku, kdy v obou sítích nebudeme mít žádný router, který nerozumí tomu novému protokolu. To je IPv6 víc zpětně kompatibilní, než to vaše řešení – IPv6 můžete začít nasazovat teď hned paralelně vedle IPv4, s vaším protokolem byste musel čekat, až se vyměníte všechny routery v síti.

Vždyť jsem to psal. Takže zpětná kompatibilita žádná. Jakmile se paket ocitne v síti s novými zařízeními, nesmí se dostat na staré zařízení. Pořád tady ale hrozí to riziko, že se omylem provoz nového protokolu bude routovat přes staré zařízení, čímž ten provoz půjde do háje. To se u IPv6 stát nemůže.

aha a kolipa bajtíků musí porovnávat router při routerování IPV6 ?

Pokud chcete zvětšit adresní prostor, nezbývá než zvětšit adresu. Rozdíl je ale v tom, jak rychle ji dokážu porovnávat.

NO jistě by se našel někde ve standardní hlavičce IPV4 protokolu jeden významový bit

Tak ho najděte…

Takže žádné tragické zpomalení se nekoná...že ?

Koná. Místo jednoho porovnání jich musíte udělat několik, navíc ještě ve dvou variantách umístění v paketu. A všechno to má být implementováno hardwarově.

No a při přechodu na IPV6 to není nutné ?

Je. Já jsem netvrdil, že je váš návrh v tomto ohledu horší než IPv6, v tomto případě je jenom stejně špatný.

z tohoto je jasně vidět že tento princip nechcete pochopit...

Nikoli, z toho je vidět, že vy jste se nezkusil ani zamyslet nad tím, jak by to v praxi fungovalo. Protože:

i "nové" pakety projdou starou sítí

Neprojdou. NAT je přesměruje někam úplně jinam, staré zařízení je zacyklí. „Nové“ pakety projdou některými částmi staré sítě, když budete mít štěstí. Takže nejen, že to nebude fungovat správně, ale navíc prakticky nebude možné zjistit, kde je chyba – protože to nebude fungovat, i když všechna zařízení budou fungovat správně.

budou prostě směrovány stadnradními starými metodami až do té chvíle kdy vstoupí do nového zařízení...ale to dé doby právě mohou být směrovány "postaru" a to je ta kompatibilita s původním systémem

Dobře. Takže paket vstoupil do nového zařízení X, tam se podle rozšířené adresy zjistí, kam má být směrován dál. Pošle se tou linkou, na druhém konci ovšem bude staré zařízení Y. To podle cílové IP adresy zjistí, že má být paket směrován na zařízení X. Můžete si vybrat – buď zjistí, že odtud ten paket právě přišel, že je tedy někde chyba, a zahodí ho. Nebo ho pošle šupem zpátky. Tak jako tak, k cíli ten paket nikdy nedorazí.

Fungovalo by to jedině v případě, kdy by paket – jakmile jednou vstoupí do nového zařízení – nikdy nesměl opustit novou infrastrukturu, mohl by být předáván jenom mezi novými zařízeními. Tím ale máte opět kompatibilitu v tahu. Navíc je to jen záležitost konfigurace, ve které snadno může nastat chyba – s novým protokolem (IPv6) se vám ale nemůže stát, že se paket kvůli chybné konfiguraci dostane do IPv4 infrastruktury a tam se bude pohybovat dál.

(samozřejmě ne NATem i když možná by to přepisování cílové adresy nemuselo tolik vadit ale to nechme být)

No pokud vám nevadí, že se paket doručí někomu úplně jinému, tak nemá smysl se s vámi bavit o síťových protokolech. Tak si prostě představte, že se vám cílová adresa omylem přepisuje na 127.0.0.1, což vám přece nevadí, vytáhněte si síťový kabel z počítače, a budete spokojen.

NO jistě by se našel někde ve standardní hlavičce IPV4 protokolu jeden významový bit, který by mohl rozlišit novou adresu od staré.

navrhuju významový bit v položce Version Number :-)

ad 1) a 2) Takže místo porovnání 4 bajtů by router musel porovnat 4 a 4 bajty adresy (zdrojové a cílové) a podle ní rozhodnout, zda nejde o nový protokol. Pak porovnat 4 bajty cílové adresy, načíst délku hlavičky, podle ní určit umístění další části adresy (bajt 20 nebo 24) a tu pak porovnat s routovací tabulkou. To nebude stejně rychlé.

Navíc byste musel vyměnit veškerou infrastrukturu, která se nyní dívá i dovnitř paketu. Třeba tolik oblíbený NAT by vám najednou začal přepisovat část cílové adresy – stačí jediné zařízení v cestě, které by nerozumělo novému IPv4, a budou se dít věci.

ad 3) V návrhu je použít prázdné bloky, každý LIR by tedy nejspíš dostal svou část. Pokud by dnes každý LIR měl jeden blok, znamenalo by to tedy nárůst routovacích tabulek na dvojnásobek. Ve skutečnosti mají těch bloků více, ale i tak by to byl dost výrazný narůst. Současné přidělené adresy nejde pro nový protokol využít, protože nějak musíte identifikovat, že jde o ten nový protokol – chápal jsem to tak, že by to bylo právě podle příslušnosti adresy k onomu dříve prázdnému bloku.

ad 4) Takže opět by byla nutná podpora nového protokolu v celé infrastruktuře ISP. Pokud bude v síti jediný router, který protokol nebude znát, nepodívá se na rozšířenou adresu a podle cílové adresy pošle paket zpět na „bránu“ – takže by se paket zacyklil.

Když to shrnu – rozhodování o směrování by bylo náročnější na výkon, routovací tabulky by se výrazně zvětšily, to jsou oproti IPv6 nevýhody. Shodně s IPv6 by bylo nutné pro podporu nového protokolu vyměnit veškerou infrastrukturu. Oproti IPv6, jehož provoz není souběhem IPv4 rušen, by ten váš protokol byl navíc velmi náchylný k tomu, že ho stará zařízení budou poškozovat. Ve výsledku má tedy váš návrh všechny nevýhody IPv6, podstatné nevýhody navíc a žádnou výhodu. Už chápete, proč se vybralo menší zlo a vytvořil se nový protokol?

To HTTPS bloklé jsem psal já. A osobně s ním teď poslední 2 týdny bojuji v Rusku, na letištích SSL/TLS verze bloklé (šlo obejít změnou portu), posedávám po několik hodně velkých firmách a opět vše TLS/SSL bloklé, ale inteligentně, Hlídají to na L7, takže pokud si domluvím přehození TLS na jiný, neTLS port, tak to nepustí (ani DNS tunel nefunguje).
Po dotazu na adminy co to znamená, tak šifrované verze mají povolen jen jejich počítače (důvěryhodné). Návštěvním má smůlu. Respketive pro ten účel mají povolen IPsec, tak prý jeďte přes to. Ale ouha, ten jejich NAT do toho hrabe a způdsobí, že IPsec transport nefunguje, server nepozná korektně NAT protistranu (IPsec tunel to utojí, takže jejich IPsecové řešení s tím funguje, ale normální L2TP/IPsec klient z Windows ne a je jedno, zda server proti tomu zkusím nechat dát Windows/Linux/ROS). Takže takto mi třeba NATy aktuálně překáží...
A tu situaci, že mém aktuálně klienty v Číně, kde mají jen IPv6 konektivitu, musím řešit také (tam mi samozřejmě aktuálně stačí, abych přes IPv6 udělal tunel do firmy a tím protuneloval IPv4, takže nemiusím překlápět firmu na IPv6 celou, al emusím s tím nějak počítat).

Obvinovat CT a CTU samozrejme muzes, ale lepsi je se na to podivat z druhe strany -- diky jejich neschopnosti zde vzniklo nove, prosperujici odvetvi a mame moderni a v mezinarodnim srovnani pomerne konkurenceschopnou infrastrukturu. Pokud se podivas treba do Rakouska, kde ma inkumbent s ADSL velmi silne postaveni, do konkurencni infrastruktury se prakticky neinvestuje a srovnas to s CR, tak CR je na tom velmi dobre. A muzeme za to podekovat omezenosti a nenazranosti par smejdu, z nichz jeden se, vzpominam-li si spravne, chtel nekdy v roce 1994 dokonce veset, coz je na tom to nejzabavnejsi :-)

já bych to asi spíš rozdělil podle toho, jestli mají vlastní IP prostor a nebo používají IP prostor svého upstream providera. Existence vlastního IP prostoru není závislá na vlastním čísle AS.

Ti co mají vlastní IP prostor jsou ISP, ti co nemají jsou přeprodávači/pře­kupníci. Osobně bych to nevnímal nějak pejorativně. Nicméně jsou závislí na svém upstramovi a nejsou tedy plnohodnotní ISP.

Je v civilisovaném světě ojedinělé, že firma připojující např. 5000 domácností nemá vlastní AS a tedy není "pravý" ISP? Např. takové o.s. Pilsfree má přes 14k připojených členů, a vlastní AS pokud vím nemají (snad se nepletu, mají společný v NFX). Pak je to tedy překupník? Já to chápu, ale jak takovou firmu nazývat? Vždyť takoví v ČR mají možná 30 % podíl na připojení domácností.

Asi je otázka, čemu říkáte malý ISP. /48 dostává koncový zákazník. ISP je standardně LIR, který dostane /32. (http://www.ripe.net/ripe/docs/ripe-512#lir)

to je jako házet hrách na zeď. Už jsme mu to tady psali tisíckrát a nic. Pod dalším článkem o IPv6 to tu bude znovu a pořád dokola.

malý ISP dostane /32.

Jiste, me taky doma funguje cokoli co si usmyslim, umim si to nastavit, narozdil od tech milionu BFU, kteri neustale po netu resi jak to udelat a proc jim to ci ono nefunguje. Ostatne na nejmenovanem ceske trackeru poklesla frekvence techno dotazu po zprovozneni IPv6 na cca 1/5.

Nikoli, je to naprosto to same, mozna v ponekud vetsim meritku, ale jde o totez. Navic IPX se dalo vpohode pres IP tunelovat a taky se to bezne delalo.

Řekl bych, že jsem to pochopil, a na rozdíl od vás to vidím v souvislostech. Ale klidně vám to shrnu do jednoduchých otázek – pokud je problém v chápání opravdu na mé straně, nebude pro vás problém na ně odpovědět.

• Dokážete u vašeho protokolu zajistit pevné umístění všech informací potřebných pro směrování (všech částí adresy) na pevném místě v paketu (např. 4 bajty od offsetu 16)?
• Pokud ne, jak dokážete rozhodnout o směrování paketu stejně rychle a na stejně výkonném zařízení v případě dynamického umístění adresy v porovnání s fixním umístěním adresy?
• Jak zajistíte přidělení potřebných IPv4 adres tak, aby nedošlo k výraznému nárůstu routovacích tabulek?
• Jakým protokolem a s jakými adresami se bude komunikovat uvnitř sítě ISP? Budou počítače uvnitř sítě mezi sebou komunikovat přímo, nebo přes NAT ISP

Mimochodem, jaka je aktualne v CR situace pri pridelovani IPv6 prefixu malym ISP od LIRu? Jaka delka prefixu se prideluje?

LIR a velky ISP predpokladam dostanou cely /32, ale co ostatni, mate nejakou presnejsi informaci?

Mate pravdu, nejdrive jsem to pocital s /40, pak jsem si jeste chtel overit presna cisla a spatne si precetl na RIPE odstavec 5.3. LIR-to-ISP allocation, kde se o /48 mluvi, ale jako o end site...

Na váš námět principu, jak by bylo možné rozšířit adresní prostor IPv4, vám bylo už několikrát vysvětleno, že vaše řešení by bylo několikanásobně složitější a dražší, než IPv6, a nic by to nepřineslo (stejně každý, kdo by chtěl komunikovat novým způsobem, by musel aktualizovat software nebo i hardware).

To, že zde bude existovat souběh obou protokolů, je od začátku zřejmé a od začátku se s tím počítá. Teoretik by řekl, že nejlepší by bylo udělat změnu jedním velkým třeskem – praktici vědí, že je to nemožné a o nic takového se nesnaží.

Tak schvalne, kde dostanu dnes IPv4 pro svuj AS ? Aha, nikde.

> Nove site proste budou IPv6 only, protoze ISP jednoduse nedostane zadne IPv4 adresy ktere by mohl pouzit. Tudiz ty stare budou muset nejakym zpusobem tak jako tak implementovat bud IPv6 nebo nejake konverzni rozhrani.

Nebude tam konverzní rozhraní, ale dualstack a IPv4 NAT. Protože tak je to nejjednodušší. A ISP bude doufat, že velká část provozu se přeleje na IPv6, aby ta NAT krabice nebyla moc drahá (nemá-li ji vyřešenou už dnes jinak a levněji). A na ISP, co bude v6-only si minimálně v ČR budeme muset počkat víc než 10 let.

> Az si za 5, mozna 10 let budete chtit zridit hosting, tak dostane jen IPv6 a nazdar.

Pouze za předpokladu rozšíření IPv6 konektivity k > 95 % lidí ze zájmové skupiny (dejme tomu BFU). A tady bych si nebyl jist ani těmi 10 lety. A vsadil bych se, že i za 10 let v datacentrech IPv4 budou k mání. Jen cena vzroste, třeba k 500 Kč / měsíc a jednu IPv4. Bude-li se v6 rozšiřovat, stávající projekty ztratí motivaci tolik platit za v4 adresy a budou je "vracet". Tady téměř jistě bude fungovat trh (v rámci jednoho DC, ale i mezi DC - nikdo nebude chtít být první, pro kterého je IPv4 no-way, ani za hodně peněz).

Sory, ale vy nejste praktik, vy ste placal.

Domacnosti = p2p = potreba byt "aktiv" = potreba mit verejnou IP => reseni je IPv6. Kdyby nic jineho tak toto staci.

Domacnosti + male firmy = VoIP = potreba mit verejne IP (jinak se telefon s telefonem nespoji a opet se to resi pres ruzne zhuverilosti) => opet to resi IPv6.

Dale plkate z cesty, protoze existuji obousmerne konverze v4 to v6 i naopak, staci to zprovoznit trebas na GW, tudiz ciste IPv6 sit muze komunikovat s IPv4 siti a naopak, je ovsem daleko jednodusi na siti s IPv4 pridat IPv6. Nove site proste budou IPv6 only, protoze ISP jednoduse nedostane zadne IPv4 adresy ktere by mohl pouzit. Tudiz ty stare budou muset nejakym zpusobem tak jako tak implementovat bud IPv6 nebo nejake konverzni rozhrani.
Az si za 5, mozna 10 let budete chtit zridit hosting, tak dostane jen IPv6 a nazdar.

/48 je alokace pro zakaznika, nikoli pro ISP.

jj, nehlede na to, ze jeste hodne dlouho po te co se bezne pouzival IP protokol se zaroven na stejne siti pouzivalo i IPX (doom po siti po nicem jinym nejel ...).

.... Dále mi nikdo nedokázal prakticky předvést, jak si připojím do té malé IPV6 sítě bez zlého NAPTu tu vytouženou mikrovlnku a ona bude okamžitě end-to-end dostupná odkudkoliv ze světa....

Jednoduše: zastrčím mikrovlnku do ethernetové zásuvky, ta z RA získá prefix a dopočítá si svůj EUI-64, čímž mu vznikne jeho globální adresa. Pokud bude chtít být dostupný z venku nějakým rozumným způsobem tak použije dynamický DNS update, aby se jmenovala třeba mikrovlnka.u.mne­.doma.cz. A pak dám do prohlížeče http://mikrovlnka.u.mne.doma.cz/

Co je na tom proboha, po takové sérii článků na téma autokonfigurace, nepochopitelného?

Dobře, vypadá to, že nejsme ve většině věcí ve sporu, spíše se na stejné problémy díváme z jiných úhlů. Takže alespoň jednotlivé komentáře.

• Za jakési pokusy o "zpětnou kompatibilitu" se dá považovat mapování IPv4 adres do IPv6 rozsahu. Bitová kompatibilita na úrovni navržené IPv6 hlavičky není, a asi ani nebyla možná, teď už s ní každopádně nic nenaděláme.
• Pokud z důvodu kompatibility vezmeme v úvahu, že by se použily nealokované bloky z class E přímo (předpokládám, že je to to, co jste myslel) a vyřešíme směrování, viz výše tady v diskuzi, pak máme při zachování současné konzumace 2 bloky /8 za měsíc (vycházím z dnešní zprávičky, i když teď je to dáno i tím, že si každý chce nasyslit) cca 8 měsíců k dobru. Pokud by zájem v Asii opadl, což je nepravděpodobné, tak dejme tomu rok a půl. To asi příliš nepomůže. K využití IP options jsem se vyjádřil.
• S náklady a přechodem je to začarovaný kruh, dokud se IPv6 nerozšíří, tak se nepřejde, dokud se nepřejde, tak se nerozšíří...
  Zatím to ani nevypadá, že by se někdo z mobilních pracovníků ocitl v IPv6-only síti.
  Návštěva ale bude podle všeho stejně na samostatném segmentu s patřičným omezením ve FW, nebo je necháváte přistupovat do firemní infrastruktury?
  Ono kdyby vše fungovalo jak má a implementovala se správná RFC, tak by ti mobilní pracovníci mohli být přes MIPv6 přímo ve firemní síti a zvenku by nemuselo být nic přístupné. V podstatě se asi jedná o nomadické uživatele, že?
• Fakticky tady bude dual-stack trvat tak dlouho, dokud ho bude zapotřebí. Přirovnal bych to ke koexistenci IP a IPX na stejné síti. Na několik desítek let to nevidím, předpokládám, že mimo specifických sítí se odporoučí rychleji, ale nic nebrání tomu, aby se někde dál používal ještě za 40 let, předpokádám, že IPX také ještě někde běží.
  Narozdíl od DVB-T tady asi nikdo nevyhlásí, že 1.6.2016 bude proveden IPv4 switchoff a všechno se bude přenášet v IPv6. I když si dovedu takovou akci od některých (nad)vlád představit.
• K té mikrovlnce, předpokládám, že když už to bude zařízení, které bude IPv6 podporovat (jen doufám, že nebude připojena přes b/g/n WiFi, to by asi výrobce vyhořel), tak bude mimo IPv6 obsahovat i FW se zákazem příchozích spojení a konfigurovat půjde v továrním nastavení jen z lokálního segmentu s tím, že prvotní autentizace bude přes kód, zobrazený na displayi. Pak už půjde nastavit, odkud bude přístupná a pro co, něco jako Bluetooth párování nebo WPS u dnešních WiFi routerů...
• Hamachi je zrovna příkladem služby, která kašle na alokace, ale to dělá i T-mobile CZ a všichni, kdo využívali nealokované 1.0.0.0/8. Hamachi navíc využívá i alokované, ale na Internetu nepřístupné 5.0.0.0/8, ale co když se tyto sítě na Internetu objeví, a jeho klienti budou muset využít serveru v některé z těchto sítí.

Že cesta bude trnitá a implementátoři v různých OS ji ještě více komplikují, to je bohužel pravda. Vývoj okolo IPv6 také v některých oblastech před několika lety utichl/zpomalil se, prostě je to špatně načasováno. Očekávalo se, že už bude několik let IPv6 nasazeno, ale nikdo se do něj nepouštěl, protože se masivně rozšířil NAT a tak zájem upadl. Ony ze začátku byly i nějaké vlastnosti, které se vymyslely pro IPv6, ale velice rychle byly "backportovány" i do IPv4, často prakticky v okamžiku vydání RFC pro IPv6, viz IPSec.

A ještě na závěr - já osobně vidím v tuto chvíli největší problém v připojení malé domácí sítě s několika počítači přes "tu krabičku za 1500, co tu leží na stole", pokud nebude poskytovatel automaticky delegovat subnet přes DHCPv6: ta "krabička" možná sice půjde přepnout do režimu bridge pouze pro IPv6, ale pak tam zase nebude fungovat firewall.

Tak oprava, uz si to ani neumim po sobe precits - /48 dostane 2 bajty pro podsite, /56 1 bajt pro podsite. Puvodne jsem to pocital pro /40, ale typicka alokace je /48, to jsem sice opravil, ale uz neprepsal.

No zabránit jim v tom potenciálně nemůže nikdo, kromě zdravého rozumu. Spíše dají na celý segment /64 a Vy budete sdílet adresní prostor se sousedem a okolím a možná to uměle omezí kvůli účtování na 1 zákazník = 1 adresa. Tento přístup nevyřeší ale žádný protokol.

Když si uvědomíte, že poskytovatel od LIRa dostane prefix /48, tak vlastně dostává obdobu /8 v IPv4. Který český poskytovatel má tolik zákazníků, že by mu to nestačilo? Zatím to vypadá, že nikdo delší prefix ani nepotřeboval. I s /56 máte pořád regulerních ~ 64 tisíc stanic.

K vašemu nápadu s "nekonečnou délkou adresy" - praxe ukazuje, že cokoliv s dynamickou délkou v protokolu je špatné (více práce na CPU, horší realizace v HW), právě proto je nakonec IPv6 16 bajtů (overkill), i když půlku nám rovnou sebere autokonfigurace.

Trochu odlehčení, kdy dojdou IPv6 adresy (i když principielně špatné pro ten konkrétní případ):
http://xkcd.com/865/

Můj úplně první příspěvek byl o tom, že IPv6 má jeden zásadní problém a to zasahuje úplně do všeho. Nejde tedy jen o změnu adresace, ale mění se právě veci, které s adresací až tak nesouvisí. Třeba autokonfigurace, nepodporad DHCP (trvání na RA), nebo úplné zavržení NATu (symetrický NAT, čili pouhý překlad adres nebo prefixu smysl jistě má).

Smiřuji se s tím, že IPv6 přijde, i když asi nejspíš ne v této podobě, ale základ určitě zůstane.

U IPv6 mi vadí hlavně v současné době nedořešené poskytování adres. Kdo mi zaručí, že mi ISP nedá jednu IPv6 adresu a další si zákazníku zaplať. Ještě donedávna takto fungovaly tunely a funguje takhle i Teredo, aniž by k tomu byl nějaký důvod (posledních 48 bitů jsou víceméně volitelné, že se na ně mapuje lokální adresa a port nemá technický význam).

Pokud by IPv6 bylo jen o rozšíření adresového prostoru při zachování všech současných technologií, super, nemám problém. Pokud by akademici uměli navrhnout rozšíření tak, aby umožňovalo teoreticky nekonečně dlouhou síťovou adresu, bylo by to ještě lepší, protože by tím vzali snahy ISP rejžovat na zákazanících. Každý zákazník by si mohl dodat další bajt do své adresy a pak by teprve nebyly potřeba NATy.
Bohužel to tak není, takže nakonec nám IPv6 adresy opět dojdou. Kdo zabrání velkým ISP zabrat si pro sebe půlku IPv6 rozsahu s tím, že je budou poskytovat koncovým zákazníkům po jednom?

Navíc by taková adresa mohla být kratší, protože by neobsahovala potřebné rezervy pro případ, že by nějakým ISP došly adresy. zase by si jednoduše přidaly další bajt do prefixu. Takhle se nám velikost hlavičky pro IP adresy z původních 8 bajtů zvětšuje na 32 bajtů a pořád si myslím, že je škoda plýtvat pásmo na servisní informace. Pořád ještě máme rámce délky 1500bajtů a hlavičky se nám začínají dost nafukovat

Dobrá tedy,
zatím jste nesklouzl do příliš velkých invektiv, takže Vám ještě odpovím. Budu reagovat obecně na návrhy, které tady zazněly (házím to sem a ne pod Vaši odpověď, protože odpověď je dost dlouhá a vznikla by tam uprostřed nepěkná nudle).

1. Spousta lidí není ze současné podoby IPv6 a zejména její implementace nadšená, ale uvědomují si, že jde o výsledek jakéhosi konsensu a některé části se budou vylepšovat v okamžiku, kdy se objeví další problémy.
   
   Já sám nejsem nadšený z některých částí, zejména autokonfigurace a SOHO oblasti, ale jsem v tomto ohledu pragmatik. Vy jste příkladem zarytého odpůrce a nemá smysl Vás přesvědčovat, problémem je, že ale šíříte FUD mezi ostatními, a představujete si, že všichni, kdo nesdílí Váš názor musí nutně při vyslovení IPv6 skákat radostí do stropu a volat Haleluja.
2. Zavádění jakékoliv novinky znamená nové investice a vývoj v oblasti se neustále zrychluje. Tato "novinka" je tady dostatečně dlouho, ale nebyl o ni příliš velký zájem. V oblastech, kde už je nějakou dobu nasazena se už problémy snad odlaďují/odladily.
3. RFC se doplňují novými, některá se úplně ruší, apod. V případě IPv6 už se to stalo několikrát (kdo si dnes ještě pamatuje A6 a DNAME). Vývoj IPv6 může sice ukázat některé slepé uličky, které v době jeho vymýšlení vypadaly lákavě, ale vývoj takového alternativního protokolu by trval určitě min. kolem 3-5 let do nasazení.
4. Pokud bychom chtěli využít stávajícího IPv4 a doplnit ho o nějaké změny, bude to zasahovat do protokolů ostatních vrstev.
   • Starší návrhy, které zde zazněly v diskuzích od Vás a Vašich kolegů měly ten problém, že zřejmě nepůjde kvůli hloupým routerům zachovat č. verze na 4, ale bude nutno vytvořit jiné. Tím pádem bude asi vhodné změnit i ID protokolu v rámcích 2. vrstvy. Zvládnou to stávající směrovače bez výrazných zásahu do firmware?
   • IP options se nehodí, protože se jedná o strukturu proměnné délky a jejich pořadí na rozdíl od IPv6 Extension headers není zaručeno. Proto musíte procházet jejich celý blok, zkoumat je. Dalším problémem je jejich proměnná délka. Těch faktorů je více, ale tohle je asi hlavní důvod, proč nejsou zpracovány v HW.
   • Dále budou nutné změny v DNS. Kvůli kompatibilitě s legacy systémy to vidím buď na novou rodinu adres (místo IN), nebo reálněji na jiný typ záznamu. Opět Vás čeká standardizace.
   • Podpora v operačních systémech - vzpomeňte si, jak dlouho trvalo implementovat do koncových zařízení IPv6.
   • Podpora na síťových prvcích (neříkám, že u všech Vašich návrhů je nutno podporovat na úplně všech prvcích, ale bude to nezanedbatelné množství). Stačí si vzpomenout, jaké problémy dělalo kdysi, když se začal používat subnet zero a někým jiným zde již zmíněný CIDR. A to se neměnila podoba samotné adresy.
   • Podpora v programovacích jazycích - když už se musely překopat POSIXové sokety na IPv6, jsou sice struktury navrženy flexibilněji a šlo by to za cenu přidání dalších protokolů, ale bylo by stejně nutno doplnit podporu nového návrhu formou dalších tříd do všech edicí Javy, .NET, ... A hlavně přepsat stávající SW, aby s tím dokázal pracovat.

Ve výsledku bude dlouho trvat, než to dostanete do provozuschopného stavu a za pár let problémy převáží.

Ono obecně si hodně lidí neuvědomuje, že:

1. Co za IPv6 považují je spíše špička ledovce.
2. Spousta věcí je standardizována, ale není dostatečně podporována zařízeními nebo koncovými systémy (viz IPv6 mobilita, AH, ESP, ...). Předpokládám, že se povídání o některých z nich dočkáme v dalších částech tohoto seriálu.
3. Jádro standardu IPv6 (adresace, směrování, dělení adres) je vlastně jednoduché a do něj se už příliš zasahovat nebude. U zbytku (včetně přiřazování adres, apod.) je otázkou, jestli nebudou ještě některé věci předělány a doplněny do zařízení "za běhu" (jako např. ten nešťastný NAT pro SOHO).