Názory k článku
Teredo: IPv6 kdekoli

By me celkem zajimalo, na kolika ruznych linkach to autor testil a co je podle nej "zoufale pomala komunikace". Na me lince napr teredo dosahovalo vpohode na max linky a latence byla prijatelnych 100ms (proti 30 na Ipv4).

S tunelem co mam ted je to samozrejme cca o 50% lepsi.

V mém případě ping z domácí sítě (O2 ADSL) na univerzitní server (CESNET) nativně po IPv4 potřeboval 16 ms, po IPv6 přes Teredo 240 ms. Samozřejmě velmi záleží na tom, kde se v síti nachází odesilatel, cíl a Teredo relay mezi nimi - čím dál je od optimální trasy, tím větší bude rozdíl.

Do článku se bohužel vloudila podstatná nepřesnost, a to v odstavci popisujícím komunikaci s nativním IPv6. Věta "Provede to tak, že pošle IPv6 ping (ICMPv6 echo) na svou vlastní Teredo adresu přes svůj Teredo server..." je v příkrém rozporu se skutečností (RFC 4380 3.4).
Teredo klient totiž neposílá ICMPv6 echo (ping) sám sobě, nýbrž cílovému IPv6 stroji, se kterým se snaží navázat komunikaci. Tento ping je zabalen do UDP a poslán přes Teredo server, tam je vybalen a přes IPv6 pokračuje k cíli (v6 stroji). Cílový stroj odpoví na normální IPv6 ping, od něj se tedy vrací v6 echo reply na Teredo adresu klienta. Ta je běžnými routovacími mechanismy nasměrována ve v6 síti k routeru propagujícímu Teredo prefix (tedy Teredo relayi). Relay paket zařadí do fronty a pošle přes Teredo server klientovi bublinu (prázdný paket), server bublinu přepošle klientovi, který z ní přečte IPv4 adresu a port relaye. Na tuto adresu pošle klient také bublinu, čímž prorazí zevnitř díru ve svém NATu. Jakmile relay tuto bublinu obdrží, vyřadí čekající ICMPv6 echo reply z fronty a pošle v UDP na IPv4 adresu klienta (z níž přišla odpovědní bublina). Tím končí ustavování spojení, protože od této chvíle relay i klient znají své IPv4 adresy, přes něž probíhá další komunikace.

Podstatný závěr z toho je, že relay je vybíráno IPv6 routováním ve směru od cílového v6 stroje, je tedy nejblíže cílovému stroji (ve v6 síti). Poloha Teredo serveru nemá na výběr relaye pražádný vliv.

Omlouvám se za chybu, máte pravdu, echo se posílá cílovému stroji.

Vzhledem k tomu, že dokud bude existovat malá ale nezanedbatelná skupina potencionálních konzumentů obsahu IPV4 only, bude většina zdrojů tlačena udržovat IPV4 kompatibilitu a tím pádem nebude žádný tlak na konzumenty obsahu aby přešli na IPV6. Ano máte pravdu paskvil ala dualstack tady s námi bude "přirozeně" možná ještě padesát let se všemi nagativními důsledky.

Možná by pomohlo, kdybyste popsal, jak to tedy kompatibilně udělat.

Nevymýšlet novoty a založit to na extenzi vyčleněného rozsahu IPV4 adres. V IPV4 hlavičkách je dostatek místa na extenzi a stará infrastruktura IPV4 síě pak může pakety směrovat zcela nativně do IPVxyz sítě s rozšířeným adresováním. Změny jsou pak nutné prakticky pouze na straně OS.

Jo, jasne, a routery za miliony si preprogramuje kazdej sam ...

Takže router, který by té <i>IPv6 extenzi</i> nerozuměl, by to chápal jako normální IPv4 paket a poslal by to někam do tramtárie. Prví router poi cestě, který by těm extenzím rozuměl, by zjistil, že je to vlastně IPv6, a poslal zpět správným směrem – a zase by to narazilo na ten router, který by tomu nerozuměl. A tak stále dokola, dokud by nevypršel TTL a paket by nebyl zahozen. To by se dalo vyřešit odděleným routováním IPv4 a IPv4 s IPv6 extenzemi – ale to už by bylo dnešní IPv6, akorát s nešikovným formátem hlavičky paketu.

No a nehlede na vykon, protoze je asi celkem rozdil mrknout na IP a poslat paket na prislusny rozhrani vs mrknout na IP, zjistit, jestli neni nahodou z extraburt rozsahu, kdyz jo, tak jeste cumet do hlavicky ... pocitam zhorseni latenci tak 100x.

Ani ne, tak to není - prostě by se obrovský kus rozšířeného prostoru nalézal za jednou IPv4 adresou. Tam už by všechny směrovače tomu rozšíření rozuměly. Ty co by nerozuměly by to pouze doručily k tomu hraničnímu směrovači. V tomto smyslu by to patrně fungovalo.

Problém by byl ovšem v implementaci na koncových stanicích, protože ty stanice by nemohly zahazovat to rozšíření, kterému nerozumí, což by patrně dělaly. Takže se opět dostáváme do situace, kdy musíme vyměnit jeden IPv4 stack za jiný IPv4 stack a tedy jsme v horší situaci než s IPv6, protože tam máme dva stacky vedle sebe (IPv4 a IPv6) a nemáme na dvou různých počítačích dva různé IPv4 stacky.

Takže buď by se celý IPv6 provoz routoval přes jednu (nebo několik) normálních IPv4 adres, takže by to byl gigantický NAT – ovšem nevím, kdo a jak by ho provozoval. Nebo by ty IPv4 adresy jako brána do IPv6 routoval každý ISP na nejbližší bránu – to je ale princip dnešních IPv6 tunelů. Jinými slovy, rozumná a prakticky použitelná implementace „zpětně kompatibilního IPv6“ vede na IPv6 v podobě, v jaké jej dnes známe.

A možná by opět pomohlo, kdybyste si nastudoval mechanismy transparentního přechodu mezi těmito protokoly a vykašlal se na nadávání proti nekompatibilitě a planými výkřiky na adresu "egoistů".
Člověk hledá způsob, lenoch hledá důvod...

Pozor, ze článku nevyplývá jedna podstatná záležitost, která činí Teredo na windows v podstatě nepoužitelným. Windows Vista a výše to mají tak pitomě udělané, že pokud k tomu není aplikace uzpůsobená, tak se Teredo nepoužije, takže reálně si po zadání ipv6.google.com do browseru na ipv6 google přes Teredo nedostanete ani náhodou, to bohužel platí pro veškerý IPv6 svět.

To máte pravdu, ale o to tady podle mě vůbec nejde. Jsem uživatel na IPv4 konektivitě s novými Windows 7 s implicitně zapnutou IPv6 access technologií, která propíchne každý IPv4 NAT ale je mi to k ničemu, na žádnou IPv6 adresu se nedostanu bez nějakého příšerného nastavování. Jak jsem v těch odkazovaných hlodech napsal - tohle MS podle mě nezvládl, 1:0 pro Linux distribuce.

Stačí do cmd zadat tyto příkazy:

netsh interface teredo set state enterpriseclient teredo.remlab.net

reg add HKLM\SYSTEM\Cu­rrentControlSet\Ser­vices\Dnscache\Pa­rameters /v AddrConfigControl /t REG_DWORD /d 0