Názory k článku IPv6 Mýty a skutečnost: díl III. - podpora end-to-end služeb

Kdyz Vas tak ctu, tak se divim, ze jste pred lety nezustal u NetBEUI a IPX.

Osobne si myslim, ze zrovna u techto scenaru se z pohledu vnitrniho fungovani nebo styku s beznym internetem zavedenim ipv6 nic podstatneho nemeni.

Akorat admin bude muset udelat to co udelal pred lety kdyz zavadel IP - tj. neco si o tom precist a pak to nastavit. Ale chapu, ze to je pro nekoho prilis mnoho prace.

A pak to nastavit. Krásné.
Méně krásné je to, že "to nastavit" bude třeba taky znamenat vyhodit celou část nějaké technické infrastruktury a nahradit komplet novou.
Typicky starší systém IP kamer, nebo nějakou telemetrii. Včetně na míru šité (nebo upravené) aplikace.
Takže to vaše ironické příliš mnoho práce je najednou reálné příliš mnoho peněz.
Já IPv6 neodmítám. Jenom rostu z názorů, že je to chce jenom trochu studia a trochu nastavování. A případně nějakou novou krabičku, co stejně moc nestojí.

No dyt, bavime se o IPv6 a precislovani a jako jeden z problemu autor uvadi, ze lidi lezou na srv pomoci IP, coz bych v pripade IPv6 opravdu chtel videt. Teda ne ze by to neslo, kdyz si z konfigurace stanice vysaju prefix a protoze vim, ze trebas router ma ::1 ... ale daleko rychlejsi a pohodlnejsi mi prijde napsat ssh gw.

podle me to autor myslel stejne jako vy - ze nekdo datluje ipv4 adresu, ale u ipv6 uz to moc nepujde.

Asi takhle, dostal sem se shodou okolnosti k administraci site, kde bylo temer vse nakonfigurovano na IP (v4 samo). A samozrejme se neustale a opakovane resily potize kdyz nastala nutnost nejakou sluzbu presunout jinam, precislovat server ...

Takze sem si dal tu praci a vse prekonfiguroval na DNS, udelal desitky aliasu aby kazda sluzba bezici na stejnem stroji mela svuj (pro pripad ze by ji bylo treba presunout). Uz se to nekollikrat vyplatilo. Byvaly admin neustale plkal neco o tom ze "a co kdyz prestane fungovat DNS", coz se jeste nestalo (nekolik let), navic v siti bezi 3.

BTW: Externi dodavatel si za nepritomnosti ITka nenainstaluje v zadny rozumny siti nic.

Třeba je to zadáno v nějakém konfiguračním souboru jiné aplikace. Protože v době zprovozňování nebyl ještě záznam v DNS, nebo tak něco. Třeba DNS pro LAN vůbec nemáte a nějaký multicast DNS je jan další vrstva, co se může rozbít. IP se dnes používá třeba i v průmyslu na field-automation úrovni, a tito lidé jsou zvyklí přemýšlet trochu jinak. Použije se to řešení, které nepřináší komplikace a je nejjednodušší možné - protože je menší šance, že se něco rozbije a diagnostika je také jednodušší.

Stav spojení si ta krabička stejně musí udržovat, protože zpravidla tam nezávisle na NAPTu chcemi i stateful firewall. A to bez connection trackingu asi nepůjde...

to pak ale není NAT krabička, ale stateful firewall :-)

Chtělo by to ještě konfiguraci DNS definovat tak, stačilo poeditovat jeden prefix a rázem by se změnily stovky IPv6 adres, kde ten prefix byl použit

Myslite neco jako je v bindu $ORIGIN

To je implementační otázka u konkrétního nameserveru. Nikde není dáno, kde má mít NS uložené informace - jestli v bind-style souborech, v SQL databázi, nebo v LDAPu. A pro stovky IP adres není problém ani přegenerovat ty obyčejné soubory nějakým skriptem. Že by se to v blízkém čase nějak standardizovalo, to bych nečekal.

Co se týče záložních linek bez BGP, tak ještě existuje řešení v podobě IP mobility. Stačí, aby ISP provozoval domácího agenta a stroje z připojené sítě se do něj registrovaly.

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.

Z ekonomického nadhledu autor popsal situaci, ve které vznikají podnikatelské příležitosti. Existuje poptávka po řešení multihomingu pro malé firmy a domácnosti u protokolu IPv6. Určitě lze vymyslet vhodné technické řešení. Sice neexistuje standard, ale to není překážkou.

Dokáži si představit skupinu několika techniků, kteří navrhnou a implementují řešení nad IPv6 pro nějakou vhodnou a levnou "čínskou" krabičku. Když budou mít schopného obchodníka, tak zanedlouho mohou svoji krabičku (své krabičky) nabízet a prodávat u zákazníků různých ISP zaměřených na malé firmy a domácnosti. Zájem bude i v zahraničí.

Uzivatele se uz naucili pouzivat 8.8.8.8 jako public DNS od Googlu, nepodcenovat :)

Ja jsem presvedcenej, ze milovnici NATu se nakonec taky dockaji. Kdo chce kam... Nakonec i ja ho trosku chci, i kdyz ne na bezny pouzivani, ale jako nastroj na nejaky "spinavy triky" by se treba nekdy hodit mohl.

Jde jen o to, aby to nebylo prilis brzo, aby se plnohodnotna a nicim nezkriplena konektivita stihla prosadit jako vseobecne uznavanej standard. Kdyby byl NAT v IPv6 uz dneska, tak ho pulka vyrobcu levnych krabicek a podobne uvazujicich poskytovatelu zavede jako jedinej standard a svetly zitrky pujdou do haje. On bohate staci ten napad s defaultnim blokovanim vseho prichoziho.

Téměř jistě se objeví. Ne na běžné použití. Ale např. mobilní operátor vám dá s určitým tarifem 1 IPv6 adresu na pptp, a o nějaké delegaci prefixu se vůbec nebude bavit. A příležitostně budu potřebovat konektivitu nasdílet do notebooku, a v notebooku do několika VMWare virt. strojů. Co pak?

Pak by se NAT hodil. Ale pokud by nebyl ani NAT ani zadny lepsi reseni, tak bych asi zkusil aplikace ukecat na SOCKS. Na zakladni pouziti by to mohlo stacit.

V prumyslu se vyskytuji zarizeni, ktera DNS neumi. (Je pravda, ze takova zarizeni neumi ani IPv6.)

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í".

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.

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).

Tak pochopitelně VPN je nejčastější způsob, jak se k takovým věcem přistupuje. Ale viděl jsem to i tak, že se to řešilo firewallem se dvěma pravidly - povol příchozí spojení z jedné konkrétní IP adresy a všechno ostatní zahoď.
Píšu o tom, že nějak zvenku se tam dostat potřeba je - že to (většinou) nejsou systémy odříznuté od světa.

No asi takhle. Obvykle to je pres VPN ze dvou duvodu: [1] vetsi bezpecnost, [2] nedostatek verejnych adres. Predstavte si, ze mate nekde ve strojovne 10 krabicek a chcete se k nim z dalky dostat. (Je levnejsi a rychlejsi prenastavit nejaky parametr odkukoliv po internetu nez kvuli tomu jet pres pul republiky tam a zpatky). Zatim jediny zakaznik, ktery nasim krabickam bez problemu pridelil verejne IP adresy, byla jedna vysoka skola.

To je jen důsledek toho, že zakládat distribuci CDN na DNS je totální zhovadilost.

Bohužel jinak to v IPv4 asi nejde. Má IPv6 něco lepšího?

Ale jde to jinak i na IPv4. Treba anycastem.

Jednoduchá otázka k NPT - nezabije to transportní mód IPsec? Jak se s tím hodlají tvůrci NPT vypořádat?

Tak uz jsem to konecne precetl cele i s diskuzi a dekuji za clanek.

Mapovani prefixu mi pro domaci sit nebo malou firmu prijde pomerne elegantni. Spise me udivuje informace v clanku, ze tato myslenka byla poprve publikovana az v roce 2008. Utvrzuje me to v moji teorii, ze se neco zacne dit, az IPv4 adresy skutecne dojdou.

Tak si čtu tady tu diskuzi a nestačím se divit. Můžete mi vysvětlit co budou dělat organizace kterým za rok či dva ISP řekne: "Sorry, ale pro váš nový server nemáme veřejnou IP. Máte sice dobrý nápad na novou službu, ale strčte si ji za klobouk."
Spousta lidí včetně "admin ." tady tvrdí jak je IPv6 hrozné. Ano má mouchy, nepopírám ale všechno se časem vyřeší. V lidské povaze je nechat vše na poslední chvíli a s IPv6 to není jinak. Přechod na IPv4 s maskou taky nebyl určitě bez problému a lidi i organizace museli pořizovat nové zařízení protože to staré masku nedokázalo použít.

Jo a ještě jedna věc. Když je IPv6 taková hrůza, tak proč jste nenapsal svůj návrh RFC na nový protokol? Když by byl alespoň trochu kompatibilní a dával smysl, tak by jste ho určitě prosadil.

Pakdej keám připojenej k síti už přeci MÁ svůj jedinečný hw identifikátor v podobě MAC adresy. Ergo mi uniká nutnost definovat vedle toho IPv6 adresy, chápu změnu protokolu kvůli adresování atp. ale nechápu, proč by adresy měly být přidělovány, když by mohly být použity stávající MAC???

Protože MAC adresy nejsou agregovatelné a málokterý směrovač dokáže udržet v paměti 2^46 záznamů.

2^48 :-) Ale to na tom moc nemění ...

1 bit je U/M a druhý G/L.
A přesně tedy 2^46-1

Tvurci se nijak netaji tim, ze nektery veci proste fungovat nemusi:

"Although NPTv6 compares favorably to NAT44 in several ways, it does not eliminate all of the achitectural problems associated with IPv4 NAT, as described in [RFC2993]. NPTv6 involves modifying IP headers in transit, so it is not compatible with security mechanisms, such as the IPsec Authentication Header, that provide integrity protection for the IP header. NPTv6 may interfere with the use of application protocols that transmit IP addresses in the application-specific portion of the IP packet."

Jinymi slovy, moc vysoko bych z toho radosti neskakal.

Můžete mi vysvětlit co budou dělat organizace kterým za rok či dva ISP řekne: "Sorry, ale pro váš nový server nemáme veřejnou IP. Máte sice dobrý nápad na novou službu, ale strčte si ji za klobouk."

V ČR za rok či dva těžko. Až přijde fakt takový tlak na nedostatek adres v datacentrech, tak i provozovatel přejde na model "kdo dá víc". A bude i konkurence mezi datacentry, a nikdo nebude chtít být první, který nemá IPv4 adresy... Už teď zpravidla platíte dle velikosti přiděleného bloku. Až bude tento zdroj vzácnější, bude se platit víc. Není to dobré, a jedině, že by RIPE nějak zasáhl a odebíral. Jinak podle mě v tomto segmentu IPv4 adresy nedojdou nikdy. Bude stoupat tlak na jejich efektivnější využití, bude se více šetřit, a pak se to snad zlomí, a díky obecnému rozšíření IPv6 začnou "staré" adresy být dostupnější, už nebudou potřeba.

Za 2 roky si nikdo nebude moci dovolit rozjet zajímavou službu jako IPv6-only. Protože hromada klientů v6 mít ještě nebude, tím jsem si jist.

Dobry den,

predem bych Vam rad podekoval za velmi kvalitni serii clanku. Ze vsech IPv6-related textu jsou zdaleka nejprinosnejsi a nejstrizlivejsi.

V clanku jste nastinil nekolik metod pro lokalni adresaci, vetsina z nich, prirozene, tezi z predpokladu, ze typicke IPv6 rozhrani bude mit mnoho adres. Chtel jsem se zeptat, jestli je napr. na Windows mozne zaridit to, aby jedno rozhrani ziskalo dve adresy z RA (EUI-64 a nahodnou) + jeste napr. z DHCP v domene, ktere ji prideli ULA adresu na zaklade ULA.
Pripadne modifikace dotazu - je obecne mozne dosahnout toho, ze rozhrani nastavim jednu pevnou adresu a zaroven bude rozhrani prijimat dalsi adresy z RA/DHCP?

Moje netsh-fu je na toto prilis kratke, obavam se.

Predem diky za odpoved!

Zdravím, principy konfigurace koncových zařízení bude popsáno v příštím díle.

Navíc ne všechny zařízení připojené do Internetu musí MAC adresu mít. Jsou i jiné technologie než ethernet.

proč celý? Voni se taky neměněj DNS záznamy po čelém světě pokaždé kdž si zresetuješ ADSL modem a operátor mu vrazí novou dynamicky přidělovanou adresu. Tak nějak jsem to myslel. Jako náhrada IP v DHCP MAC adresou, otázka je jestli by to pomohlo.

Autoři se o zpětnou kompatibilitu pokusili a zjistili, že by takové řešení bylo řádově dražší a komplikovanější, než zavedení nového nekompatibilního protokolu. Co na takhle jednoduché věci pořád nechápete? Stačí si uvědomit požadavky – zvětšení adresního prostoru, snížení jeho fragmentace, cílová adresa uložená souvisle na pevné pozici v paketu. Třetí požadavek se vylučuje s IPv4, druhý požadavek by se s IPv4 dal vyřešit jedině změnou globální struktury internetu – místo peer-to-peer sítě by se z něj musela udělat hierarchická struktura, protože by velké sítě (třeba celá síť velkého ISP) byly schované za obdobou dnešního NATu. A to ještě kdo ví, zda by na to stačily volné IPv4 adresy, nebo jestli by nebylo nutné nějaké velké bloky již přidělených IPv4 adres „znárodnit“.

Opravdu je to takhle jednoduché, opravdu stačí jenom se zamyslet nad tím, co by znamenala zpětná kompatibilita s IPv4. Že se nad tím nezamyslíte na poprvé, no, dejme tomu, někdo rychleji píše, než přemýšlí. Ale psát to stále dokola a trvat na tom, že se nad tím v žádném případě nezamyslíte, to nechápu.

prostě MAC adresy nejsou agregovatelné, takže libovolný směrovač, který má minimálně tři rozhraní by musel mít seznam všech MAC adres, aby věděl, kam ten paket poslat. Ale samozřejmě by byla možnost použít locally administred MAC adresy, tak aby se přidělovaly agregovatelně. Pak byste ovšem musel patrně řešit třeba dynamické přidělování MAC adres :-)

O DCOM nemluve? http://en.wikipedia.org/wiki/OLE_for_process_control - je asi určeno kam jinam, než do průmyslu? A používá se. Krom jiného i proto, že jde o určité sjednocení těch starších protokolů nad RS485 a jinými field-bus systémy.

A HTTP a FTP taky v průmyslu nejsou neznámé a "fuj" věci. Ono průmysl není jen ta nejnižší úroveň automatizace. Dnes je to propojeno s řízením výroby, plánováním atd. V průmyslu je naprosto primární ekonomika celé akce a technologie, takže když se hodí HTTP, protože stačí vzít jakýkoliv notebook a můžu s tím pracovat (debugging, konfigurace), a je to v dané situaci podstatné měřítko, tak se použije i to HTTP.

Vyhybam se tomu. S OPC par zkusenosti mam a prestoze to je radoby standard pro vymenu dat, tak v praxi jsem z toho takovy rozpacity. Ale treba mate lepsi zkusenost. Ty starsi protokoly maji tu vyhodu, ze jsou takove ... pruhlednejsi?

Ja to HTTP a FTP nezatracuju, ono si to sve uplatneni najde (tak asi pro tu konfiguraci nebo prehrani firmware, i kdyz uz jsem si zkusil stvorit i online vycitani dat pres HTTP, ale principialne to byla tak trochu onanie). Jen jsem se snazil predchozimu adminovi rozsirit obzory o sve zkusenosti.

A jaký je rozdíl mezi tímto řešením a současným NATem? Připomeňme, že dynamické přidělování IP adres je vyřešené.

A proč musí dojít k "přečíslování" ? ...
V čem je problém pokud budou na servery nasazeny obě adresy, pak "o víkendu" dojde ke snížení priority původního routeru a pokud vše bude šlapat podle očekávání teprve odstřihnete starou cestu?
Nebo u IPv4 standardně měníte poskytovatele ze dne na den?

S vetsi siti vam posledni dvojcisli nemusi stacit... :) Drive ci pozdeji se clovek dostane do stavu, kdy spravovanych zarizeni je tolik, ze radeji spoleha na DNS. Bezny franta uzivatel navic nic jineho nez DNS beztak nepouziva... zeptejte se uzivatelu, zda znaji IPv4 adresu 77.75.72.3 ...seznam.cz znat jiste budou :-)

Me by zajimalo, co Vam z pohledu male firmy nevyhoje.

no, a sám dělám chyby - je to PAT/NAPT krabička.

Čistý NAT (bez překladu portů), jak je popsán na začátku, je vždy možný pouze 1:1. Koncové stanice totiž musí být schopny jednoznačně identifikovat datový tok. V případě, že by se překládaly 2 vnitřní IP adresy na jednu vnější a shodou okolností by si oba dva vnitřní počítače zvolili source port vyšší vrstvy stejně a přistupovali ke stejnému serveru (což může být celkem běžné), tak by došlo na straně přijímacího serveru k chaosu. (připouštím, že mohou existovat aplikace, kterým by to nevadilo, jenomže takové aplikace pak nepotřebují hlavičku vyšší vrstvy)

NAT byl opravdu původně zamýšlen pouze jako aplikace překladu 1:1, která měla sloužit k dočasnému řešení při přeadresování sítě při přepojení k jinému poskytovateli.

PAT a NAPT jsou pak úplně jiné technologie, pro které si NAT krabička musí udržovat stav spojení a s tím spojené komplikace.

do A záznamů se žádný ORIGIN asi zapsat nedá. Jedině, že by to umělo nějakou substituci typu

server IN AAAA $PREFIX::1

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

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.

Musím přiznat, že jsem se ještě nesetkal s kamerovým nebo telemetrickým systémem, u kterého by bylo žádoucí, aby byl přímo přístupný z internetu. Obvykle je to dost omezené nějakým přístupem přes VPN nebo omezené čistě na interní použití.

a ještě přesněji tedy I(ndividual)/G(rou­p) a 2^46.

(Ajtik podle definice jednoho kolegy: V pondeli si neco rozesere, do ctvrtka dava do kupy, aby v patek mohl vypravet, jak celej tyden makal.)

Proc maly pocitac? Protoze me nebavi resit, jakou malou krabicku a jakou formu VPN. Nedejbuh, abych jeste resil s ajtikem, jestli dana forma VPN projde jeho siti. Na pocitac si muzu nainstalovat v pripade potreby jeste jine aplikace. U technologie, jejiz prikon je ve stovkach kilowatt nema cenu resit spotrebu jedne krabicky. Navic prvnich nekolik mesicu, nez se ajtik rozhejbe, tak mame nekde schovanou krabicku pro mobilni pripojeni s antenou a pristupujeme pres ni.

Jak říkám, moc toho na tom ten počet nemění. Už vidím, že jak děláš tabulky zarovnané na 46 bitů :-)

Ale byla by to zajímavá představa, jak se přepočítává celý internet hned po tom, co si vyměním síťovku.

Radši o tom začněte nejdřív přemýšlet. Velice brzy totiž dojdete k tomu, že pokračovat dál s IPv4 by bylo příliš nákladné a neefektivní, a to nejlevnější a nejefektivnější, co se dá udělat, je vytvořit nový protokol. Pak už je celkem jedno, zda to bude IPv6, nebo trochu jiné IPv6.

Podstatný. Rohodně by se ušetřily miliony hodin administrátorů sítí za nesmyslné de* bility při konfiguraci sítě. Ono by totiž skutečně stačilo připíchnout ethernetovou kartu a MAC addr do sítě.

No to právě že jen v některých případech, kdy na koncové IP (MAC addr) běží služba, která má být dostupná "z venku" z internetu. Ve všech ostatních případech, kdy se NATuje na 192.168.x.y. nebo 10.0.x.y by se mohly opustit IP adresy a měrovat přímo na MAC ADDR. Čistě teoreticky by se na jednu IP adresu dalo pověsit třeba 254 dalších směrovačů a na každém z nich by mohl viset počet koncových zařízení kolik by reálné obhospodařit via MAC. V podstatě takové dva NATy za sebou s tím, že poslední level by netvořilo 254 síťovek (class C) ale libovolný počet mac adress (který by to uneslo). Tak jako natujete do lokální sítě na 254 kompů, tak by to snad šlu udělat přímo třeba na několik tisíc MAC. Výhoda je zřejmá - žádný admin by nemusel řešit nějaké IP v lokálních strojích ani dynamické přidělování. Prostě ten směrovač na MAC adresy by si každého připojeného zařízení všiml a věděl o něm. Beztak se tam mac adresa přenáší v každým paketu :) Samozřejmě otázkou je, kolik IP adres by se tím dalo ušetřit, ale rozhodně by se dalo ušetřit hodně administrátorské práce.

Autore, chtel bych videt uzivatele, ktery pristupuje ke sluzbe pomoci IPv6 adresy ... tohle plati mozna pro IPv4.

Nikoli, autor o tom mluvi v souvislosti s precislovanim site = u IPv4 si "musite" zapamatovat novou IP, u IPv6 si nebudete pamatovat ani tu puvodni, takze stejne budete pouzivat jmeno => problem zmeny IP neexistuje.

> 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?

Já tedy o síťových protokolech nemám moc velký přehled, ale řekl bych že tyto problémy měly být popsány a vyřešeny už během definice nového protokolu.
Pokud by se s tím dopředu počítalo, tak by mohla např. fungovat krabička typu NAT/DNS proxy, která by zachytila požadavek z IPV4 vnitřní sítě na IPV6 vnější server, provoz ven by šel po IPV6 a krabička by s vnitřním zařízením komunikovala pouze po IPV4. Může teď něco takového fungovat?
Moje představa jak mohl vypadat IPV6:
IPV6 mohl být rozšířený V4, v hlavičce by navíc byla definována volitelná délka adresy klidně třeba až do 128 nebo 256 byte, zleva by to prostě doplnily nuly. Nové routery by se hw. rozšíříly o zpracování delších adres, jinak by byly kompatibilní, software by se jen upravil o delší adresy. Bylo by snadnější vytvoření různých přechodových krabiček. Vznikly by jen nové třídy rozsahů které se mohly postupně uvolňovat.
Rozsahy adres by se daly přidělovat nejen pro Zemi ale i pro okolní planety, družice atd pěkně strukturovaně.
Nové služby by se na to mohly nabalovat podobně jako se to teď lepí u IPV6.
Ještě k NATu, nelíbí se mi aby IP adresy z mé vnitřní sítě byly dostupné 1:1, raději to opět schovám za NAT a pokud budu chtít něco zpřístupnit zvenku tak namapuji port. Doufám že se časem taková možnost objeví. Jinak přinejhorším to mapování prefixů, ale to asi je pracnější, u NATu se starám jen o služby které chci zpřístupnit zvenku, ostatní je automaticky.
(Vím že NAT není firewall.)

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".

Píše se to všude: přechod na IPv6 není záležitost roku nebo dvou či pěti, takže výměna infrastruktury se odehraje přirozenou cestou. Právě kvůli unikátním kouskům jako jsou IP kamery (ale hlavně tiskové servery, potažmo síťové tiskárny) bude třeba dlouho provozovat IPv4; navíc ony ty kamery či měřicí systémy přímý přístup z Internetu obvykle nepotřebují.

Tím se myslí sítě za NATem - stačí si pamatovat poslední dvojčíslí místo blázince ten.nejdulezi­tejsi.server.fir­ma.TLD. Bonus je že v napsat IP je i rychlejší.

Bohužel, snadno zapamatovatelné adresy s IPv6 končí :(

Autor nemluvil o problému uživatele že bude muset někam datlovat IPv6, ale o tom, že při změně ISP bude muset administrátor přečíslovat všechny stroje. U klientských systémů které používají buď autokonfiguraci nebo DHCP je to naprosto bez problémů. Ale při představě, že bych měl například během víkendu přečíslovat celou síť (všechny statické adresy) tak mi vyskakujou pupínky i na prdeli.

S tímto lze pouze souhlasit. Ještě bych k tomu dodal, že možnosti připojení těchto firem závisí na tom, co si vymyslí jejich ISP. Pokud ten nebude poskytovat IPv6, tak se ho ta firma mít nebude, pokud vynecháme pochybné možnosti tunelování. Pokud se ISP rozhodne poskytovat pouze IPv6 (nyní by byl sebevrah, ale za 5-10 roků to může být realita), tak se mu malé firmy (a domácnosti) přizpůsobí.

Existuje skupina malých firem, která se již nyní musí IPv6 zabývat. To jsou takové, které poskytují služby či vyrábějí výrobky spojené s TCP/IP (např. tvorba webů, výroba měřících přístrojů připojovaných na síť, ...). Pokud nebudou podporovat IPv6, bude to u některých zakázek bráno jako konkurenční nevýhoda.

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í?

Já jsem reagoval na příspěvek, ze kterého jsem nabyl pocit, že to pisatel vidí příliš snadno.
Ale jinak ty různé IP kamery a telemetrické systémy přístup z internetu velmi často potřebují zcela nezbytně.

Jak se opovažujete tak znevažovat význam ip6

Starý Roubíček už několik let chce mít na zahradě u každého úlu a holubníku webkameru. Přístupnou samo z Internetu přes IP6.
Novákovic trpí tím, že musí používat NAT. Okolik problémů by bylo míň pokud by jejich lednice, pračka, sekačka a záchod měla svou i6 adresu. Mimo i paní Nováková se svěrovala, že stidí před kamarádkama že ješte nezprovoznila eftýpko se všema díly Mňam pryma šlichta pod ip6

Svobodovi od vedle jsou zklámáni, že ta půjčka co si vzali od té hodné paní na ten levný router je nanic. Jejich intelektuální TV TnTCz.Ru totiž na Ip6 není. A oni tak neuvidí zpravy s hubou od ucha k uchu a pouliční voříškem, v hádé kvalitě a jak to řikali v technickém magazínu Plesk.

Stará Blažková si také stěžovala , že připojovat se do práce pomocí IP6 by také bylo snažší. A jako uklízečka by měla vyšší produktivitu práce.

Čelenové hnutí Newton Age přicházejí s teoryjí, že rok 2012 přežijeme jen pokud přejdeme jen na IP6 . Protože jeho jasný a jednoznačně čitelný popis je mozné vyčíst v Mayských textech.

Tedy chápejte, že ip6 je v zájmu nás všech a čeká nás jen sociální a ekonomický rozkvět.

Nevytvoří a nezastaví.
IPv6 je dnes už prakticky industry standard - i takové zařízení, jako čtečka Kindle 3 jede přes IPv6.

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

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

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.

Ř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.

BETACAM byla jedna za 3 možností a vyhrála ta nejhorší. Jenže IPv6 nemá alternativu. Klidně to ignorujte, asi bez toho ještě dost dlouho vydržíte, ale kvůli tomu přece nějaká ta miliarda Číňanů nebude bez veřejných IP adres.
A než zase začnete tvrdit, jak ten NAPT to všechno vyřeší, tak si zkuste jednu úlohu pro menší firmu: máte pobočku, která se připojuje k serveru v "centrále" (to je tam, kde je ten SBS a 5 počítačů). Jasně, VPN (PPTP/GRE), NAPT krabičkou to projde. A teď v pobočce zkuste takto připojit ještě jeden počítač. Ono to nejde, že?

Psychiatři už taky poděkovali a odešli? :-)

Mimochodem, všiml jste si, že jsem dnes to prokleté číslo nikde nezmínil? Zobněte si ještě jednu pilulku, snad se to zlepší.

Uvazujete jako typicky ajtik. Ne, ty krabicky nemaji webove rozhranni. A rozhodne se jejich komunikace neomezuje na jeden TCP nebo UDP port. V nasem pripade byva vyhodnejsi, nez neco resit s linym ajtikem, schovat nekam mezi krabicky maly pocitac s OpenVPN, od ajtika si nechat prostrcit tenhle jeden port (obvykle mu toto nastaveni trva nekolik mesicu) a v nasi siti krabicek si potom vzdalene muzeme delat, co chceme. Internet zdaleka neni jenom http://www.seznam.cz

Proto take ctu tento serial, abych se dozvedel, jake zmeny me s nastupem IPv6 ocekavaji. A jak to tak sleduju, tak jeste nejaky cas nase krabicky preziji s IPv4 jeste hodne dlouho.

Koukam, ze my dva se spolu asi nedomluvime, takze Vam i sobe preju, abychom na sebe nenarazili v praxi. Byla by to ztrata casu. A mezi tim se muzete za domaci ukol zamyslet, proc by nejake prumyslove zarizeni melo umet pro prumysl tak neprakticke protokoly jako HTTP nebo FTP (o DCOM nemluve), kdyz muzou pouzit nejaky vlastni protokol staveny jim primo na miru. (I kdyz s tim "stavenim na miru" to je v praxi spis tak, ze se vezme nejaky starsi protokol pouzivany na RS232/422/485 a nejak se zabali do UDP, pri trose onanie do TCP.)

Já myslím, že jste ten svůj příspěvek mohl ukončit hned za první čárkou, ušetřili bychom všichni zbytečnou energii :-)

Nepodceňujte uživatele, jsou schopni dělat i absurdnější věci... :-)