Vlákno názorů k článku IPv6 Mýty a skutečnost, díl VIII. - Přechodové mechanizmy od Sob - 1) Mapovany adresy ve Windows podporovany jsou, i...
-
Sob (neregistrovaný)
1) Mapovany adresy ve Windows podporovany jsou, i kdyz az od NT6. Staci pres setsockopt() vypnout IPV6_V6ONLY. Ve starsich verzich nebyly proste proto, ze oba protokoly byly implementovany jako uplne nezavisly, takze prehazovat (mapovat) pripojeni dost dobre neslo.
2) Hromada problemu s prioritou protokolu by odpadla, kdyby aplikace nevymyslely zadny vlastni genialni reseni a jednoduse pouzivaly getaddrinfo(). Staci zavolat, a pak postupne zkouset jednu adresu po druhy, dokud se pripojeni nepodari. To je ostatne rozumna vec i bez IPv6, protoze tradicni pristup, kdy server ma sice deset adres, ale klient to vzda hned jak se nepodari pripojit k prvni, je docela trapnej. ;) Windows navic inteligentne seradi adresy podle toho, jakou konektivitu maji k dispozici. Takze napr. nehrozi, aby se primarne zkouselo pripojeni pres IPv6, kdyz ma klient jen Teredo.
3) Prechodovym mechanismum fandim, hlavne 6to4. Diky nemu mam IPv6 uz skoro deset let. Kdybych mel cekat na ISP, nez zavede nativni, tak nemam nic doted, protoze neverim, ze by se snazil i jen o chlup vic nez ted. Vzdyt prece tech volnych IPv4 adres bylo porad tolik a vycerpani v nedohlednu...
4) Naopak mi vubec neni sympaticky DNS64. NAT64 v pohode, k tomu to smeruje, ze az zustane par IPv4-only zpatecniku, tak aby se k nim dalo dostat. Ale vymysleni neexistujich adres je cunarna. Kdyz uz neco takovyho delat, tak radsi primo v OS a namapovat IPv4 do nejakyho konkretniho, vsude stejnyho prefixu, kterej si ISP na hranici svy site odchyti a zNAT64uje.
-
ondra.novacisko.cz (neregistrovaný)
Postupně zkoušet připojení je hoooodně na dlouho. Tož už doporučuju to pustit paralelně a sebrat první připojení, které se ozve. Ani nejsou potřeba thready, stačí asynchroní connect a pak select a zbytek descriptorů pozavírat. Jo nevýhodou je, že to vyrobí docela solidní trafic u serveru, ale to není moje starost :-D
Né dobře, aspoň tedy vzít dva seznamy IPv4 a IPv6 a ty zkoušet postupně paralelně (tedy vždy jedno spojení v rámci stacku, a tedy maximálně dva connecty současně)
-
1) S mapováním adres máte pravdu. Novější verze Windows (Vista, 7) již mapované adresy podporují, viz. http://msdn.microsoft.com/en-us/library/bb513665%28v=vs.85%29.aspx
2) S tím by až tak problém nebyl. Řada aplikací se takto chová. Problémem je dostatečně rychlá identifikace, že cíl je daným protokolem (či obecně na dané IP adrese) nedotupný. Pokud jsou pakety zahozeny firewallem aniž by byla vegenerována ICPM zpráva anebo pakety někde mizí vlivem chyby v routingu, tak je třeba počkat na timeout. Poblémem se zabýva právě draft draft-ietf-v6ops-happy-eyeballs-01 (http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-01), který věc řeší současným navazováním více spojení. Související prezentace je k dispozici na http://tools.ietf.org/agenda/80/slides/v6ops-21.pptx .
3) Co se týče 6to4 tak vás asi nepotěším. Do budoucna s touto technologii příliš počítat nelze, nicméně do té doby snad už bude většina ISP podporovat nativní IPv6, takže problém bude bezpředmětný.
4) Namapování IPv4 vždy do stejného prefixu vyžaduje podporu na všech klientských systémech, takže zde vidím jistý problém v masovém rozšíření. Jinak souhlasím, že myšlenka to není uplně špatná akorát tady měla být tak před 10 lety, aby současné systémy již tuto techniku podporovaly. Jinak v samotném NAT64 je hned několik, na první pohled ne zcela zřejmých, záludností. Jak například řešit fragmentaci, překlad kompletního ICMP na ICMPv6 atd. Pozitivní je, že již existují implementace (Ecdysis, Juniper, ci pozůstatek NAT-PT na zařízeních CISCO), takže technologie se asi bude docela využívat. Mnohé diskuse tomu nasvědčují.
-
Sob (neregistrovaný)
2) Bohuzel ne uplne vsechny aplikace to tak delaji. Opravdu se najdou takovy, ktery zkusi IPv6 a v pripade neuspechu uz na IPv4 kaslou. A rozdil mezi (velmi) otravnym zdrzenim a kompletnim selhanim je zasadni. Ale do budoucna by se to melo zlepsovat. Jak se postupne zacne brat IPv6 jako bezna vec a ne jen takova hracka bokem, tak se pak temer vzdy chyti hned prvni adresa.
3) Je to prechodovej mechanismus, od zacatku se pocita s tim, ze casem zmizi. Sice bych zatim s jeho rusenim zbytecne nespechal, ale ono to nebude tak zhavy, par let urcite jeste vydrzi.
4) Trosku vic jsem se zacetl a ono uz to existuje, prefix 64:ff9b::/96 (RFC 6052, sekce 2.1). I kdyz to neni tak uplne ono, protoze ISP muze pouzit prefix vlastni, a tak na to nejde spolihat. Coz je skoda, protoze mi prijde, ze snadna detekce takovych prekladanych adres, ktery nejsou plnohodnotny IPv6, by vubec nebyla spatna.
ČLÁNKY DO MAILU