Omezení IPv6 tunelu HE

[Lenin POWER!]

Santiago ma pravdu, tohle je presne ta pointa. Vsichni si nastavi pokud maji dual stack na border routeru odchozi IPv6->IPv4 6to4 a je po problemech.

Navic tunel je SPOF. V sitarine je nejlepsi byt co mozna nejvic nezavisly a ne zavistet s IP6 konektivitou na tom jak se u HE vyspi.

[Reklama]

[Někdo]

Santiago ma pravdu, tohle je presne ta pointa. Vsichni si nastavi pokud maji dual stack na border routeru odchozi IPv6->IPv4 6to4 a je po problemech.

Kdyby to tak fungovalo, bylo by to super. Ale v praxi to tak bohužel nefunguje, proto to super není. Hlavní průšvih je že nemáte jak všechny ostatní ISP donutit aby to dělali tak jak by se vám líbilo.

Navic tunel je SPOF. V sitarine je nejlepsi byt co mozna nejvic nezavisly a ne zavistet s IP6 konektivitou na tom jak se u HE vyspi.

To je obecná nevýhoda všech tunelů - samozřejmě že nativní IP6 je lepší, ale když není tak holt tunel...

[Lenin POWER!]

To si nastavi na border routeru ZAKAZNIK, ne ISP. Pokud ISP zvladne routovat IP6 ve svy siti tak uz ma davno IP6 nativne.

[Někdo]

To si nastavi na border routeru ZAKAZNIK, ne ISP.

Předpokládám že jde o situaci kdy ten zákazník nemá nativní IP6 konektivitu a na svém border routeru (s patřičnou veřejnou IP4 adresou) nakonfiguruje 6to4 gw. Pak pořád zůstává problém s tím, jak se IP6 routuje k němu - tím svým nastavením totiž ovlivní jen jak se IP6 routuje od něj. Konkrétně je problém jak IP6 servery v internetu se kterými chce zákazník komunikovat najdou spolehlivou 6to4 gw která zajistí převod IP6->IP4 pro posílání odpovědí k zákazníkovi (potom už pakety běží přes IP4 až na border router zákazníka, který zajistí převod IP4->IP6 a routování do vnitřní sítě zákazníka).

[brk]

Takže nic, HE je v pohodě. Blbý odhad. Další vytuhnutí a když jsem sáhl po mobilu na mojí WiFině ve stejné síti, tak nebezi.cz běží. Něco se mi rozbilo na stanici.

[Reklama]

[Santiago]

No ale kde máte záruku že správce AS protistrany (nebo jeho upstream provider) bude provozovat dostatečně kvalitní 6to4 gw?

Provoz privatni 6to4 gateway neni nic, co by bylo 'kvalitni' ci 'nekvalitni', nema smysl se na to koukat, jak by slo provoz databaze nebo webserveru.  Je to v podstate jedna routa v routovaci tabulce, ktera se od bezneho forwardingu lisi tim, ze se paket obali jeste jednou hlavickou (samozrejme, pokud ma nekdo routery, ktere mu prosty forwarding delaji v hardware, ale 6to4 zapouzdeni v hardware nezvladnou, tak musi provozovat dostatecne dimenzovany softwarovy router jako 6to4 branu).

Problem je s 6to4 gatewayema tretich stran je primarne v tom, ze v podstate poskytuji zahranicni konektivitu zdarma, takze jsou svym zpusobem dotovani provozovatelem a ten nema zadnou primou motivaci zajistit dostatecne dimenzovani. Oproti tomu brana pro vlastni potrebu je z hlediska site bezny IPv4 provoz, na ktery je sit dimenzovana tak jako tak. 

Prostě je to totálně bez záruky, takže nestabilita takového asymetrického řešení jako je 6to4 je hlavní problém - někdy funguje perfektně a někdy naprosto hrozně.

Tady je videt, jak tvuj zaver ohledne 6to4 je zatizen atribucni chybou - problem pri komunikaci mezi nativnim IPv6 a 6to4 automaticky prisuzujes na stranu 6to4. Daleko vystiznejsi je ale rict, ze ani nativni IPv6 neni vsespasne - pokud ma nekdo nativni IPv6 od ISP, ktery zanedba svou 6to4 branu, tak mu spatne funguje komunikace do 6to4 siti.

Takže tam kde nebude funkční 6to4 gw tak mají klienti prostě smůlu? V tu chvíli by 6to4 bylo mrtvé, protože by ho klienti přestali používat (protože by se nedostali všude). Svým způsobem je to vlastně dobré řešení, ale nejsem si jistý že to bylo takhle myšlené.

Pokud mi upstream nedoda routu pro 2002::/16, tak je to zavazny problem s upstreamem, ktery by si mel dany AS poresit.  Pokud by mi upstream nedodal prefix HE.NET, tak bych se z meho AS take nedostal do site HE.NET (a zakaznici HE.NET by se take nedostali vsude). Pokud by mi upstream nedodal prefix UPC, tak by ty same potize meli zakaznici UPC. A urcite existuji i nativni IPv6 prefixy, ktere jsou daleko mene vyznamne nez prefix 2002::/16 co do poctu komunikujicich.

[Někdo]

No ale kde máte záruku že správce AS protistrany (nebo jeho upstream provider) bude provozovat dostatečně kvalitní 6to4 gw?

Provoz privatni 6to4 gateway neni nic, co by bylo 'kvalitni' ci 'nekvalitni', nema smysl se na to koukat, jak by slo provoz databaze nebo webserveru.  Je to v podstate jedna routa v routovaci tabulce, ktera se od bezneho forwardingu lisi tim, ze se paket obali jeste jednou hlavickou (samozrejme, pokud ma nekdo routery, ktere mu prosty forwarding delaji v hardware, ale 6to4 zapouzdeni v hardware nezvladnou, tak musi provozovat dostatecne dimenzovany softwarovy router jako 6to4 branu).

Odpověděl sis sám - vidíš že to vždy není "jedna routa v routovací tabulce". Například když má ISP drahé routery (třeba i v HA zapojení) u kterých si šetří CPU na důležitější věci než je nějaké 6to4, s radostí se na nějaké speciální řešení pro 6to4 vykašle.

Problem je s 6to4 gatewayema tretich stran je primarne v tom, ze v podstate poskytuji zahranicni konektivitu zdarma, takze jsou svym zpusobem dotovani provozovatelem a ten nema zadnou primou motivaci zajistit dostatecne dimenzovani. Oproti tomu brana pro vlastni potrebu je z hlediska site bezny IPv4 provoz, na ktery je sit dimenzovana tak jako tak. 

Další argumenty proč se spousta ISP na provoz 6to4 gw vykašle, takže utopické teoretické řešení kdy každý ISP má kvalitní 6to4 gw (dostupností i výkonem) se prostě nepotkává s realitou.

Prostě je to totálně bez záruky, takže nestabilita takového asymetrického řešení jako je 6to4 je hlavní problém - někdy funguje perfektně a někdy naprosto hrozně.

Tady je videt, jak tvuj zaver ohledne 6to4 je zatizen atribucni chybou - problem pri komunikaci mezi nativnim IPv6 a 6to4 automaticky prisuzujes na stranu 6to4. Daleko vystiznejsi je ale rict, ze ani nativni IPv6 neni vsespasne - pokud ma nekdo nativni IPv6 od ISP, ktery zanedba svou 6to4 branu, tak mu spatne funguje komunikace do 6to4 siti.

K nativnímu IPv6 nemusí ISP nic řešit, prostě použije kvalitní routery (které stejně má pro IPv4) a je to. U 6to4 se toho dá pokazit mnohem více, proto jsem přesvědčený že je naprosto legitimní předpokládat že ve většině případů je to právě špatně fungující 6to4 gw která může za problémy. Některé z argumentů viz výše - ISP prostě nejsou nijak motivováni k provozu kvalitních 6to4 gw, je to pro ně pouze zbytečná zátěž.

Takže tam kde nebude funkční 6to4 gw tak mají klienti prostě smůlu? V tu chvíli by 6to4 bylo mrtvé, protože by ho klienti přestali používat (protože by se nedostali všude). Svým způsobem je to vlastně dobré řešení, ale nejsem si jistý že to bylo takhle myšlené.

Pokud mi upstream nedoda routu pro 2002::/16, tak je to zavazny problem s upstreamem, ktery by si mel dany AS poresit.  Pokud by mi upstream nedodal prefix HE.NET, tak bych se z meho AS take nedostal do site HE.NET (a zakaznici HE.NET by se take nedostali vsude). Pokud by mi upstream nedodal prefix UPC, tak by ty same potize meli zakaznici UPC. A urcite existuji i nativni IPv6 prefixy, ktere jsou daleko mene vyznamne nez prefix 2002::/16 co do poctu komunikujicich.

Umazal jsi svou větu "IMHO by se prefix 2002::/16 nemel propagovat skrz peeringove linky, tim by bylo po problemu." na kterou jsem reagoval. Nejspíš to bylo myšlené v kombinaci s tím že každý ISP má mít svou 6to4 gw která bude umět zpracovávat 2002::/16, což je ale utopie.

[Santiago]

Problem je s 6to4 gatewayema tretich stran je primarne v tom, ze v podstate poskytuji zahranicni konektivitu zdarma, takze jsou svym zpusobem dotovani provozovatelem a ten nema zadnou primou motivaci zajistit dostatecne dimenzovani. Oproti tomu brana pro vlastni potrebu je z hlediska site bezny IPv4 provoz, na ktery je sit dimenzovana tak jako tak. 

Další argumenty proč se spousta ISP na provoz 6to4 gw vykašle, takže utopické teoretické řešení kdy každý ISP má kvalitní 6to4 gw (dostupností i výkonem) se prostě nepotkává s realitou.

Tenhle argument se tyka pouze provozu 6to4 bran tretich stran, tedy nikoliv te, kterou by si AS delal sam, nebo kterou by vyuzival od sveho upstream providera.

Tady je videt, jak tvuj zaver ohledne 6to4 je zatizen atribucni chybou - problem pri komunikaci mezi nativnim IPv6 a 6to4 automaticky prisuzujes na stranu 6to4. Daleko vystiznejsi je ale rict, ze ani nativni IPv6 neni vsespasne - pokud ma nekdo nativni IPv6 od ISP, ktery zanedba svou 6to4 branu, tak mu spatne funguje komunikace do 6to4 siti.

Některé z argumentů viz výše - ISP prostě nejsou nijak motivováni k provozu kvalitních 6to4 gw, je to pro ně pouze zbytečná zátěž.

Neni motivace pouze k provozu verejnych 6to4 gw. Motivace k provozu privatnich 6to4 gw pro svuj odchozi provoz do 2002::/16 existuje, pokud ho prave nesabotuji ti, kteri jsou ochotni verejnou gw (ve smeru IPv6->IPv4, tedy prefix 2002::/16) propagovat skrz peering.

Pokud mi upstream nedoda routu pro 2002::/16, tak je to zavazny problem s upstreamem, ktery by si mel dany AS poresit.  Pokud by mi upstream nedodal prefix HE.NET, tak bych se z meho AS take nedostal do site HE.NET (a zakaznici HE.NET by se take nedostali vsude). Pokud by mi upstream nedodal prefix UPC, tak by ty same potize meli zakaznici UPC. A urcite existuji i nativni IPv6 prefixy, ktere jsou daleko mene vyznamne nez prefix 2002::/16 co do poctu komunikujicich.

Umazal jsi svou větu "IMHO by se prefix 2002::/16 nemel propagovat skrz peeringove linky, tim by bylo po problemu." na kterou jsem reagoval. Nejspíš to bylo myšlené v kombinaci s tím že každý ISP má mít svou 6to4 gw která bude umět zpracovávat 2002::/16, což je ale utopie.

Je vhodne rozlisovat peering a upstream. Argument byl takovy, ze ISP by mel but vyuzivat svou 6to4 branu, nebo pouzit routu na 2002::/16, kterou dostane od upstreamu. Nemel by pouzivat ty od peeru (a protoze to je pro nej vyhodnejsi, tak ten argument je spis naopak -> nepropagovat 2002::/16 peerum. Ale nevim, jestli to v praxi vubec nekdo dela.)