Hlavní navigace

Praktické problémy s IPv6, část první

18. 10. 2010 8:59 (aktualizováno) Ondřej Caletka

Mám dojem, že poslední dobou sílí mediální kampaň proti IPv6. Na Rootovi (zde) a Lupě (1, 2) se objevují články, které se více či méně fundovaně snaží naznačit, že až dojdou IPv4 adresy, nasadíme další a další NATy a Internet bude fungovat jako dřív. A v tuto chvíli přicházím já se svou troškou do mlýna. Tímto příspěvkem bych rád poukázal na konkrétní problémy, se kterými se dřív či později setká každý, kdo se rozhodne IPv6 nasadit.

Méněcenné IPv6 adresy

Ve skutečnosti nebylo nutné s nasazením IPv6 čekat až na pověstný den, kdy zemřely směrovače. Díky přechodovým mechanizmům, jakými je Teredo, nebo (zejména) 6to4 by bylo bývalo možné,  abychom si po IPv6 povídali leta před tím, než se z toho stane nutnost. Obě jmenované přechodové technologie umožňují přímou komunikaci koncových bodů bez prostředníka; toho potřebují jen pro spojení s nativním IPv6 světem. V ideálním stavu už měl veškerý IPv4 obsah i svou 6to4 IPv6 adresu, protože zde platí ekvivalence:

Mám veřejnou IPv4 adresu <⇒ Mám k dispozici IPv6 prefix 2002:IPAD:RESA::/48

Protože jde o překlad bezestavový a oproti např. NAT naprosto triviální, nebyl by problém implementovat jej do každé krabičky která provádí NAT. V takovém ideálním světě by ani nebylo potřeba vyvíjet mnohem složitější technologii Teredo (která za pomoci velikého úsilí dokáže získat jednu IPv6 adresu z jakékoli neveřejné IPv4 adresy), ani různé obezličky typu Universal Plug&Play. Prostě by aplikace, potřebující propíchnout NAT, přešly na IPv6.

A teď zpátky do reality. Všichni poskytovatelé obsahu, kteří již dnes poskytují obsah po IPv6, zveřejňují pouze tzv. nativní IPv6 adresu. To znamená, že osvícení klienti, kteří si rozchodili Teredo, či 6to4, přistupují přes prostředníka (jednoho takového nedávno spustil CZ NIC), který má z principu omezené kapacity a ve smluvním vztahu Klient – ISP nebo ISP – Server je třetí stranou, bez odpovědnosti.  V případě 6to4 je navíc typicky různý prostředník pro každý směr provozu, což ještě víc ztěžuje případné hledání závad.

Dá se tedy říci, že 6to4 nefunguje ze stejného důvodu, proč nefunguje nativní IPv6 – poskytovatelé obsahu nemají zájem. A tak jsou adresní rozsahy 2002::/16 a 2001::/32 tak trochu méněcenné oproti nativním IPv6 adresám.

Tunelování zabíjí IPv6

Pokud chceme být opravdu IPv6 ready, a přitom náš ISP je lama, můžeme si zařídit statický tunel s klasickou „nativní“ IPv6 adresou, takže nikdo na první pohled nepozná, že náš IPv6 provoz je celý směřován kudysi přes tramtárii, kde když už nic, tak alespoň nabere nějakých 30ms zpoždění a to je ten lepší případ.

Problém je, že takových IPv6 ready klientů s lamáckými ISP je až příliš mnoho. Když se sejdou dva sousedi z jednoho paneláku, kteří by si rádi napřímo popovídali pomocí nějakého VoIP protokolu, mají na výběr buď IPv6, nebo všeliké pracné „propichování“ NATu. No a protože jsou to lidé osvícení, použijí IPv6. Jenomže každý má natažený tunel do jiné tramtárie, takže se nám RTT vyšplhá přes 200ms, zatímco po IPv4, pokud se povede NAT propíchnout, máme RTT do 50ms. A to se na u VoIP celkem jasně pozná.

Jiní dva sousedé si budou chtít poslat nejnovější HD film: „Jaktože to najednou jde jen 20kB/s, když to vždycky šlo 200kB/s ?“ – „Nojo nasadili jsme IPv6, a druhý konec tunelu je (zase) přetížen. Stačí vypnout IPv6, a pojedeme zase plnou rychlostí“

Můžeme tedy parafrázovat známou hlášku, že IPv6 je sice delší, ale zato mnohem horší cesta.

Konec první části

Kdybych chtěl sepsat vše, co mám k IPv6 na srdci, byl by příspěvek příliš dlouhý. Proto jsem se rozhodl pro  „seriálovou“ formu. V příští části se pokusím rozebrat problémy nasazení IPv6 z pohledu druhé strany:

  • Automatická konfigurace a DHCPv6
  • Nechtěné Man-in-the-Middle útoky
  • Ochrana soukromí vs. odpovědnost za obsah

Sdílet