Vlákno názorů k článku IPv6 Mýty a skutečnost: díl III. - podpora end-to-end služeb od Montreal the Real - Už vám odpověděl VS, ale taky se přidám. Tenhle...

Už vám odpověděl VS, ale taky se přidám.
Tenhle přístup nikam nevede. To bych mohl váš názor parafrázovat takto:
Kdyby jedna skupina dělala práci jak má (síťaři), tak jiná skupina (programátoři) nemusí vymýšlet nejrůznější hovadiny (vše přes port 80).

Dvojité VPN a případně OSPF přes něj je samozřejmě řešení do centra, kde mám nějakou nasmlouvanou službu s jejichž poskytovatelem se na tomto řešení můžu domluvit a patřičně nakonfigurovat

Ne. Tohle jde právě použít, když mám 2 levná připojení (ADSL, CATV/Wifi). K tomu si za 400 Kč měsíčně někde pronajmu slušný virtuální server v datacentru, na kterém zakončím ty VPN. S nikým nemusím naprosto nic domlouvat.

ale nikdo dneska není tak bohatý, aby měl dva různé veřejné IPv4 prefixy

2 různé veřejné IPv4 prefixy nejsou problém, jsou podstatně levnější než vlastní AS a PI blok a ISP, který se se mnou bude bavit o BGP. Přesto to tak nikdo neřeší. Protože není podpora na mnoha úrovních (aplikace, OS, HW zařízení typu VoIP ústředny / IP telefonů). Že mají všechny počítače pro komunikaci v LAN 2 adresy, to je taky opruz, třeba při nastavování firewallu/qos + ten problém se zmenou adres při změně ISP.

Kdyby byly v pr.... Je nutné se smířit s tím, že ekonomická realita (a částečně diletantství) přivedla internet a související IT oblasti do stavu, kdy se používají pragmatická řešení, a mohou to být z jiného úhlu pohledu příšerné bastly. Nejúspěšnější věci jsou bastly, dnes musí jet everything-over-http(s), hrozné.

Váš nápad je hezký, bohužel nejde jen o aplikace, ale i konfigurace routování a firewallů v LAN, podporu ze strany majoritních desktop OS (chci vidět, jak na Win XP dostanete přes DHCP 2 veřejné adresy a nějaká pravidla, jak s nimi zacházet). A 10 let je málo. Tady trvá kontinuita nějakého vývoje delší dobu. A z ekonomických důvodů se prostě aktuální konfigurace obvykle mění po malých kompatibilních krocích a drží se stejná, dokud to jde a vyplatí se to.

Máme i aplikace nad TCP/IP, co jsou o dost starší než 10 let. A nikdo je předělávat nebude, protože "fungují".

Ne, jen ukazuji, že kdyby jedna skupina dělala práci jak má (programátoři), kde je to pro ně asi o 50 řádků kódu více, než prehistorické socket, bind, open, tak jiná skupina (sítaři) nemusí vymýšlet nejrůznější hovadiny.

a jen alikace na klientském počítači musí být napsána tak, jak se už asi 10 let doporučuje (v posix notaci)
=======
vy jste regulerni blazen nebo nejaky fundamentalista, hodne stesti, az tohle budete chtit po ERP a podobnych firmach

Dvojité VPN a případně OSPF přes něj je samozřejmě řešení do centra, kde mám nějakou nasmlouvanou službu s jejichž poskytovatelem se na tomto řešení můžu domluvit a patřičně nakonfigurovat. Není to řešneí pro obecný přístup k Internetu.
Toto obecné řešení samozřejmě existuje a je úplně stejné pro IPv4 i IPv6. Je jen otázka, zda chci, aby v případě selhání jedné konektivity to pokračovalo bez výpadku nebo může to chcípnout s navázat nové spojení (jak předvádí NAT ke dvoum ISP).
Pro IPv6 to vypadá tak, že mám do sítě posílané dva prefixy od různých ISP , klienti mají dvě IP adresy a jen alikace na klientském počítači musí být napsána tak, jak se už asi 10 let doporučuje (v posix notaci) - getaddrinfo()-bind()-while() {connect()}. Takto udělané otvírání spojení je automaticky multihomed pro odchozí spojení, pokud mám víc odchozích adres a i pokud protistrna má víc adres třeba v DNS, ve smyčce se najde průchozí cesta. Když spojení chcípne, tak to zopakuji a najdu cestu jinou.
Pokud potřebuji, aby se mi spojení nerozpadlo při výpadku jedné konektivity, tak používám místo TCP/UDP pro přenos SCTP v multihome nastavení, které si ustanoví spojení s protistranou vícero cestami a při chcípnutí jedné pokračuje druhou a řeší si to protokol sám a ne aplikace.
Pro IPv4 to funguje úplně stejně (ale nikdo dneska není tak bohatý, aby měl dva různé veřejné IPv4 prefixy, tak to řeší NATem).
Kdyby tohle progrmaátoři dodržovali, tak odchozí multihoming funguje od "přírody".

Proboha, čínští výrobce sekají ty krabičky pro vnitřní trh dávno s podporou IPv6! Kdyby to nedělali, tak jdou na popraviště za nenaplňování státem definovaného zájmu.
Že mimo dávají skoro to stejné bez IPv6 je plus pro ně, rádi pak prodají novou s IPv6.

Řeší se dvojicí VPN do datacentra... Ale není to tak low-cost řešení, jako NAT. Není to ani tak administrativně náročné a drahé jako vlastní AS.

A ano, žádná nativní podpora pro multihoming bez BGP u IPv4 není. Je to prostě aplikace "klasického" NATu, a ten tu byl dříve než v roce 2000.

> Podpora multihomingu bez BGP se u IPv4 začala objevovat okolo roku 2000 a rozmohla se okolo roku 2005.

A on se multihoming bez BGP v IPv4 resi i nejak jinak nez NATem?

Změna ISP v LAN složitější než 1 segment je obvykle problém i v IPv4 - stačí, pokud máte v DMZ počítače s veřejnou adresou. Konkrétně toto přečíslování udělám v IPv6 snadněji, protože počítače mohou mít po přechodnou dobu adresy od obou ISP.

Podpora multihomingu bez BGP se u IPv4 začala objevovat okolo roku 2000 a rozmohla se okolo roku 2005. To je víc než 20 roků od návrhu IPv4 (ten je ze září 1981, letos oslavíme krásných 30 roků).

Větší podíl IPv6 lze očekávat za několik roků. Lze ho používat již nyní, ale za cenu různých omezení. Některá byla zmíněna v dnešním článku.

...A kdy a proč se stane, že nebude zbytí?

Až jejich čínští obchodní patrneři nebudou mít IPv4 adresu? :-)

Takže. Změna ISP v LAN složitější než 1 segment a s potřebou složitějších FW pravidel = opruz a problém. Multihoming bez dohody s ISP na BGP peeringu (na ADSL za 400 Kč se o tom s vámi jistě budou bavit) = problém, po 15 letech stále ve fázi návrhu a snů, navrhovaná řešení polovičatá nebo nesrovnatelně komplikovanější oproti IPv4, je-li prostě cílem, aby si lidé z firmy mohli otevřít vnější web při výpadku primární linky...

Dnes si každý trouba může koupit dual-wan router, do kterého připojím přes eth 2 libovolné konektivity s DHCP, na LAN připojím počítače, a bez jakékoliv konfigrace to základním způsobem funguje (!). Jaký přesně by měl být výchozí config takového zařízení pro IPv6?

No, střední firmy se do IPv6 na LAN taky jen tak nepohrnou, dokud fakt nebude zbytí. A kdy a proč se stane, že nebude zbytí?