Vlákno názorů k článku IPv6 Mýty a skutečnost, díl I. - Jak jsme na tom od ondra.novacisko.cz - Obrovskou chybu se tvůrci dopustili úplně na začátku...

Našel jsem option 19 - Address Extensions
Vede to sem: http://tools.ietf.org/html/draft-ullmann-ipv7-03

Teď popisujete IPv4 s options, nebo IPv6? Co se týče nutnosti aktualizovat, je to stejné, akorát IPv6 je mnohem snáz a rychleji routovatelné, než ten váš návrh.

Zapomněl jste také odpovědět na otázku, kdy se to naposledy dalo udělat.

Protože můj návrh je routovatelný s IPv4 routery bez nutnosti číst options, můj návrh se routuje stejně rychle, jako obyčejná IPv4. Drobná komplikace bude jen na bráně ISP

„Drobná komplikace“ znamená několikanásobně náročnější zpracování. Vypadá to, že si představujete, že internet je nějaká hierarchická struktura, kde každý ISP má jednu bránu, kterou je připojen k internetu. Tak to ale není.

Ten váš návrh znamená jen konvzervaci současného stavu NATů, jenom byste přidal možnost adresace strojů za jedním NATem. To by ale současný problém nevyřešilo.

A jaký jiný současný problém IPv6 řeší?

Jinak ISP může mít víc rozhraní se stejnou IPv4 adresou. Já vím, že to je kacířská myšlenka, ale zhlediska směrování není problém v duplicitně rozhraních, pokud jsou identická. Pokud má vnější svět přístup do vnitřní sítě stejný bez ohledu, z jakého směru požadavek jde, pak není problém nasměrovat pakety na nejblížší rozhraní mající danou adresu. Na vnitřní síti samozřejmě budou mít ta rozhraní brán různé adresy.

Pokud to znamená zásah do routovacích algoritmů, tak je to jen softwarová záležitost a opět, uplatní se jen tam, kde to je potřeba se zachováním zpětné kompatibility.

Řeší fragmentaci adresního prostoru a nárůst routovacích tabulek.

Nevím, co byste chtěl řešit více rozhraními se stejnou IP adresou, ale dobře to ilustruje váš chybný pohled na věc. ISP nepotřebuje routovat každou IP adresu zvlášť, on potřebuje routovat co největší blok adres najednou.

Pokud to znamená zásah do routovacích algoritmů, tak je to jen softwarová záležitost
Nesmíte si pořád routování představovat jako linuxové pécéčko se dvěma kartami a routováním pár Mbit/s. Ono je potřeba umět routovat taky kapánek větší provoz – a tam zásah do routovacích algoritmů je hardwarová záležitost, a když už tedy ten hardware musím vyměnit za nový, chci, aby ten nový byl co nejlevnější, měl nízkou spotřebu a byl rychlý. Tedy aby měl co nejméně práce, a ne že bude muset každý paket osmkrát obrátit sem a tam než zjistí, co s ním má vlastně dělat.

Routování je softwarová záležitost.

Routování si představuju jednoduše. Přijde paket, kouknu do tabulky a vyběhne na mě číslo určující jakým kabelem mám paket poslat dál. Co je na tom komplikovaného?

Fragmentace adresového prostoru a velikosti routovacích tabulek? IPv4 může routovat 32bitové adresy, v praxi maximálne 24. IPv6 routuje 64bitové adresy. Za sebe bych řekl, že 64 > 24, a tedy že routovací tabulky IPv6 budou mnohonásobě větší.

Jo, routování je softwarová záležitost tak maximálně na PC.

A i to routování v IPv4 si představujete jako hurvínek válku. Co třeba source routing? Zpracování dodatečných hlaviček pro routing?

Co se týká fragmentace adresového prostoru, tak se obávám, že jste nepochopil podstatu. Nezáleží na velikosti jednoho záznamu, ale na množství záznamů. A tam IPv4 kvůli adresové roztříštěnosti jednoznačně vede. Ani největší routery dneška nedokáží zpracovávat víc jak 1M záznamů v routovacích tabulkách. A to je to rozhodně méně než 2^24

Na vašem PC je routování softwarová záležitost. Na páteřních sítích je to hardwarová záležitost, jinak byste se nedočkal.

Ta tabulka ovšem nemá pro každou IP adresu jeden řádek, ale IP adresy se tam seskupují do větších celků, aby bylo vůbec proveditelné takovou tabulku někam uložit a v rozumném čase v ní něco najít. Podstatná tedy není délka adresy, ale to, aby tím jedním kabelem vedlo co nejméně různých bloků adres. Takže to, co vám v IPv6 vyřeší jeden routovací záznam, to musíte v IPv4 vyřešit větším množstvím záznamů, které zohlední které různé pidisítě se routují jinudy.

No nevím, pořád je to hledání nekratší cesty a stavět to na současné hierarchické organizace, kdy "kdo není v NIXU, neexistuje" a "provideři jsou klienti jiních providerů, kteří jsou připojení do NIXu." je krátkozraké. Stejně se ukládáním delších prefixů nevyhnete. Nebo za cenu nižší propustnosti.

Upřímě, kdekdo si tady stěžuje, že překupování rozsahů IPv4 způsobí fragmentaci, ale nemyslím si, že existuje algoritmus, který by dokázal přidělovat adresy s ohledem na budoucí topologii sítě. Takže ta fragmentace tam bude taky.

Právě že to není stavěno na hierarchickou síť, hierarchii vyžaduje ten váš NAT.

Fragmentace tam z vámi uváděného důvodu nebude. IPv6 adres je dost, takže když se změní topologie sítě, starý rozsah se přestane používat a požádá se o nový. Nebude důvod držet se za každou cenu toho starého, protože nový už bych nemusel dostat.

Dobrá schíza. Na jedné straně možnost změna adresy při změně topologie (závislost na DNS?), na druhé straně požadavek na zachování adresy u mobilních zařízení, které topologii dynamicky narušují každým okamžikem. Vidím to bledě.

Zachování adresy mobilních zařízení se ovšem neřeší změnou routování na páteřních sítích. To zachování adresy by bylo klidně možné implementovat i nad IPv4 – jenže je to poněkud zbytečné, když ta mobilní zařízení nemají veřejnou IP adresu. Nějaká ta komunikace navíc, když si chcete sesynchronizovat kontakty v mobilu, ničemu nevadí. Ale když se routuje provoz YouTube, to musí odsejpat. Na DNS jsme závislí dávno – třeba bez vyvažování zátěže realizovaného i pomocí DNS by Google negoogloval.

Jak vidno, o routovani vite prd, protoze velke routery maji zakladni routovani zadratovano do HW. To ze se tam nasledne daji nastavit SW pravidla, je vedlejsi, protoze pravidla resi vyjimky, kterych neni mnoho a tudiz nijak zvlast nezatezuji CPU.

Uvedomte si, ze to "kouknu do tabulky" musite delat pro miliony paketu za sekundu. Velke routery maji rychle pameti ktere jsou svym rozsahem primo dimenzovane na IPv4 nebo ty novejsi uz i na IPv6 (= neztraci vykon, IPv6 lze na nekterych starsich resit SW cestou, ale za cenu 1/10 vykonu)

A opet, dalsi neznalost, IPv4 klidne muze routovat jednu konkretni IP, jenze cim vic je prostor fragmentovan, tim vic zaznamu v te tabulce musi router prohledat, nez najde spravny smer. A IPv4 je fragmentovan prave kvuli nedostatku adres - nelze pridelit /16 s dostatecnou rezervou pro danou lokalitu do budoucna => prideluje se trebas /20, coz znamena, ze ve finale ma lokalita nekolik prefixu a pro kazdy musi byt zaznam v routovaci tabulce, pricemz pri dostatecnem dimenzovani predem by stacil zaznam jediny. Proto na prvni pohled prehnane pridelovani ohromnych prefixu na IPv6. Je totiz dost pravdepodobne, ze providerovi takovy prefix bude stacit navzdy.

Zadrátovanou? To znamená, že třeba je tam zadrátováno, že prefix 7.0.0.0/8 jde vždycky na interface já nebo 4?

prefix /16 znamená 65536 adres. Nemám představu, kolik mají routery interfaců, ale pokud by jich měli méně než 256, stačí mi 64KB paměti. To je opravdu náročné.

prefix /24 znamená 16mil adress. I tam si vystačím s 16MB. Hustý

prefix /32 by znamenal mít 4GB paměti.

To jsou kupecké počty. Netuším, jak dlouhý záznam musí v tabulce být, ale statická tabulka by přesně takhle mohla vypadat. Říkáte rychlé paměti, dobře, to nejspíš zvedne cenu. Na druhou stranu, tabulka bude nejspíš po většinu času R/O, takže bezkolizní přístup je jednodušší.

Neučte mě to, zabývám se programováním, dokážu si to představit.

Chápu, že náročný může být protokol pro sestavování tech tabulek, který neustále vyhodnocuje provoz na síti a hledá rychlejší cesty. Ale ten může fungovat vedle bez zatěžování vlastního routování.

Casto jsou ty specializovane cipy programovatelna hradlova pole, takze novy firmware do nich nejake ty nove funkce dostat umi, na druhou stranu je treba rici, ze to mnozstvi implementovatelnych funkci neni diky omezenim vyplyvajicim z architektury toho hradloveho pole neomezene (co se neda udelat temi hradly, co v tom hradlovem poli jsou, to udelat zkratka nejde -- a je jich pochopitelne jen omezeny pocet).

No osobně mi IPv6 přijde tak 10x složitější, než IPv4, takže chápu, proč nové routery jsou násobně dražší a žerou větší výkon a víc topí :-)

Neni slozitejsi. V nekterych ohledech je dokonce jednodussi. Nicmene to nesouvisi s architekturou smerovacu ani trochu.

"No osobně mi IPv6 přijde tak 10x složitější, než IPv4"

To ale není chyba IPv6, ale vaše.

"žerou větší výkon a víc topí :-)"

Nějaký zdroj?

možná se zabýváte programováním, ale to je jako byste chtěl kombajnérovi radit jak jezdit s kombajnem, když vy jezdíte s jeřábem.

I velké routery mají paměť maximálně na 1M záznamů v routovacích tabulkách. Navíc se dost často nepoužívá klasická RAM, ale TCAM, která vám vyplivne výsledek během jednoho taktu procesoru.

A vy si zkuste vypočítat, jaký algoritmus pro vyhledávání byste musel použít, abyste dokázal vytáhnout z takové tabulky 400 milionů správných záznamů za sekundu - tj. vytáhněte jeden záznam za 10 taktů procesoru.

Protokol pro vyhledávání nejlepších cest je to nejmenší, to zvládne každý procesor s prstem v nose. Je to záležitost control plane, ale ten největší problém je v data plane, kam se ty správně vypočítané cesty překopírovávají.

Hledání ve statické tabulce má složitost 1. Nezáleží na počtu záznamů. Technologie existuje, takže je to jen otázka ceny.

Jinak i v obchodu s IPv4 si dokážu představit výměnu rozsahů. Pokud ISP dostane přidělený rozsah 123.1.0/17 následně 123.15.0/17 a následně, nevidím důvod, proč by si ho nemohl vyměnit za 123.1.128/17 a získat 123.1/16. Na obchod s adresami ještě dojde a bude se řešit přesně takto. Když lze měnit prefixy v IPv6, lze to dělat i u IPv4.

jestli myslíte vyhledávání v TCAM, která má opravdu složitost 1, tak tam jste bohužel omezen technickými možnostmi konstrukce CAM pamětí. Pokud myslíte vyhledávání pomocí hashovacích funkcí, tak to taky není tak triviální. Pokud myslíte, že vyrobíte pevnou tabulku, tak si uvědomte, že musíte vyhledat podle nejdelší netmasky. Ukažte mi ten algoritmus, ať se můžeme bavit konkrétně.

No a s tím vyměňováním sítí - to jste pěkný vtipálek. Jak chcete přinutit všechny uživatele, aby si přečíslovali svoje sítě jenom proto, aby ubyl jeden záznam někde v BGP tabulkách? Jste opravdu spadl z višně.

No normální vyhledávání má složitost 1. Pokud máte různě dlouhé prefixy, lze všechny zarovnat na nějakou optímální délku a záznamy pro kratší prefixy duplikovat. A těch pár, co jsou delší pak řešit jako výjimku, třeba tak, že tabulka je úrovňovaná. Například (netuším, jak je to udělaný, ale jak bych to dělal já) pokud mám většinu záznamů s prefixem do 16 a pár záznamů 18, kouknu podle 16bitů do tabulky co má 65536 záznamů. Tam kde se mapují ty 18bitové prefixy najdu odkaz na další tabulku, kde podle zbývajícíh dvou bitů najdu 4 záznamy.

Naopak prefix /14 vložím do tabulky 4 stejné záznamy pro všechny kombinaci zbývajícíh bitů

Výměna sítí předpokládá, že ISP domluví (nikoliv donutí). Narážíte ale na jiný problém a to že IPv4 neumí přidělovat adresy dynamicky. Ale to není problém protokolu samotného, ale neexistence přidružené technologie, která je zahrnuta v IPv6, ale mohla by fungovat samostatně.

(upřímě, vždycky mě naštve, že ve veřejné Wifi síti nemají ani DHCP, když ho má kdejaká krabička s anténkou).

Můžete mi říct, které normální vyhledávání má složitost 1?

InterfaceDef interfaces[256];
unsigned char routingTable[65536];

InterfaceDef &lookup(Prefix16 &prefix} {
  return interfaces[routingTable[prefix]];
}

Jo, pán je teoretik :-) To jste mohl říct rovnou a nemuseli jsme dál pokračovat

- v současnosti je v BGP tabulkách >300 000 záznamů, tj. jsou tam sítě rozhodně delší než /16, pokud chcete složitost O(1), tak musíte počítat se sítěmi alespoň /24, tj. routingTable[16777216­]. Protože pokud jinak uděláte odskok do menší tabulky a tam budete vyhledávat, tak dostanete složitost třeba O(1+log2(256))
- toto rozhodování nemůžete dělat centrálně ale decentralizovaně, většinou pro každou kartu v routeru zvlášť.

Spočítejte si jenom množství spotřebované paměti pro router s 256 interfacy a pak pokračujte v mudrování.

Už jsem to udělal nahoře. ale udělám to ještě jednou:
/16 = 64KB
/17 = 128KB
/18 = 256KB
/19 = 512KB
/20 = 1MB
/21 = 2MB
/22 = 4MB
/23 = 8MB
/24 = 16MB

Dvoúrovňové hledání má také konstantní složitost. V první úrovni mohu hledatr /16, a pokud k záznamu napíšu počet dalších bitů, vyjde mi délka tabulku v druhé úrovni, kde hledám taky konstantní složitosti. Je pravdou, že v tom případě bych asi záznam nemohl být jednobajtový, ale třeba 4 bajtový (/16 = 256KB), ale zas bych měl víc možností. Klidně Vám to napíšu jako aplikaci v C++. Chcete?

A take na loopbacky. Takze /32...

Vy jste případ. Nechcete své rozumy poslat Ciscu nebo Juniperu? Jistě vám zaplatí milióny. Nebo vám nedochází, že ta cena za takové řešení může být vyšší než nasazení IPv6? Véte kolik teď stojí páteřní routery pro Tier 1 hráče? A do IPv6 se nastrkalo tolik peněz, že alternativa se vymýšlet natož nasazovat určitě nebude. S tím se smiřte, je to to jediné co s tím můžete udělat. Teda kromě odpojení :-)

Nikoli může. Cena za takové řešení by byla o dost vyšší, než IPv6 řešení, a platila by se do té doby, než by se z IPv4-s-komplikacemi přešlo na IPv6. Když se řešilo, co s nedostatkem adres a rostoucí fragmentací v IPv4, odpovědní lidé to naštěstí dobře věděli, proto zvolili jednodušší a levnější řešení – tedy nový protokol, pojmenovaný pak IPv6.

Naiva si myslí, že IPv6 vyřeší nějakou fragmentaci :-D

Pokud se nebudou ručně rozsahy defragmentovat, tak fragmentace hrozí i na IPv6. To je základní pravidlo jakéhokoliv systému rozdělování velkého bloku na malé kousky. Můžeš dostat větší kus, nebo dva malé, záleží na tom, jak si o ně řekneš. Nikdo ti nezaručí, že ty dva malé kousky půjdou pak spojit do jednoho velkého. A nepomůže tomu ani to, že zjemním dělení, nebo že si od začátku budu dělat rezervu, kdyby náhodou každý chtěl ještě kousek. IPv6 adresy dojdou, zaručeně. A dojdou stejně rychle, jako IPv4 adresy. Dokud jich bude hodně, objeví se způsoby, jak s nimi plejtvat, a až začnou docházet, narazíme na fragmentaci.

Vtip je v tom, že s IPv6 si každý požádá o dostatečně velký rozsah, aby nemusel za chvíli žádat znova (existuje spousta nástrojů, jak to zařídit – třeba poplatek za jednu žádost). Navíc teď se přiděluje jenom menší část adresního prostoru IPv6, takže pokud by se ukázalo, že strategie přidělování je špatná, může se zvolit jiná strategie a začne se rozdělovat další část adresního prostoru – se zachováním protokolu IPv6, takže nebude nutné měnit infrastrukturu.

IPv6 adresami se bude plýtvat. Ale uvědomte si, kolik jich je – pokud vezmu celý adresní prostor, připadá na jeden mikrometr zemského povrchu přes 600 miliard IPv6 adres. Já bych tedy na to, že dojdou za 25 let, nesázel.

Ono se něco takového časem určitě objeví, až skutečně dojdou adresy

- přidá se nové options do paketu (ADREXT)
- přidá se položka do SOCKADDR možnost toto ADREXT nastavit
- upraví se existující NAT, který umožní vytvořit spojení s počítáčem vnitřní síti podle adresy v ADREXT a přepíše adresu příjemce podle ADREXT... a odebere ji z options.
- do DNS se přidá možnost zadávat rozšířené adresy, třeba takto 77.74.72.76.10­.0.1.20 (DestAddr: 77.74.72.76, ADREXT: 10.0.1.20)

Počítač vnitřní síti může mít klasické IPv4 rozhraní.

Provoz sítě IPv4-ADREXT v IPv4.
Pakety po starém protokolu nemají Options: ADREXT
Pakety v novém protokolu mají vždy Options: ADREXT
Pokud odesílatel má ADREXT a posílá paket přes NAT který to neumí, dochází ke klasickému překladu adres a portů. NAT by měl options zachovat.
Pokud odesílate má ADREXT a posílá paket pres NAT, který to umí, NAT přeloží poze SRCADR, aby umožnil routování paketu po IPv4 a odpověď došla zpět na NAT.
Pokud příjemce neumí ADREXT, používá jen IPv4 adresu
Pokud příjemce umí ADREXT, použije rozšířenou adresu. Pokud náhodou leží na veřejném uzlu (nebo v DMZ), bude ADREXT rovno nule, což je adresa samotného uzlu.
Při zpětném překladu z veřejné IP do lokální se ADREXT přepisuje do DESTADR a nastavuje na nulu, protože v rámci lokální sítě je takový počítač sám sobě uzlem.

Gratuluji, vymyslel jste něco, co je ještě mnohem komplikovanější než nasadit IPv6 :-))

Změnit pár struktur a jednu drobnou technologii vs zmenit celou infrastrukturu from scratch? Nejsem si jist, jestli můj návrh je tak komplikovaný jako bezproblémový přechod na plnohodnotné IPv6.

Jen se podívejte, kolik RFC bylo o IPv6 napsáno. Já svůj návrh vecpal do příspěvku na lupě.

Jenomže jste jaksi opominul praktické důsledky:

- všechny programy musíte znovu přeložit
- máte od všech programů zdrojáky?
- musíte upravit DNS - už to samo o sobě znamená všude implementovat znovu všechny resolvery

Když se začnete dívat víc do hloubky, tak se vám najednou vynoří problémy, které jste předtím nějak "přehlédl"

Vy jste vměstnal svoji úpravu IPv4 do jednoho příspěvku. Já dokážu vměstnat IPv6 do jedné věty: Rozšíříme adresový prostor na 128bitů. To je vše.

- všechny programy musíte znovu přeložit
to IPv6 taky, navíc, tam dokonce musím i ty, které bych tady nemusel. To že mohu v síti IPv6 dál fungovat na IPv4 je dáno podmínkou dualstacku.

- musíte upravit DNS
Nemusím, současné služby zůstanou nezměneny, přidají se jen záznamy u služeb, na které už nevystačily normální adresy. U IPv6 musím všechny záznamy a ještě pořád nemám jistotu, že se ke mě klient dovolá

Rozdíl mezi mým návrhem a IPv6 je tím, že IPv6 vyžaduje hromadné nasazení, zatímco můj návrh umožňuje postupný přechod. Ten největší argument: nepoužívají to uživatelé => není motivace pro ISP => není motivace vytvářet služby => nepoužívají to uživatelé, to je nekonečný cyklus, který se bude jen velmi obtížně překonávat... je to dáno nutností hromadného nasazení.

Dokonce už vznik článku "rychle zaveďme IPv6, než nám to nařídí stát" jasně dokazuje, v čem je problém. A bojím se, že nakonec někdo přijde a vydá na to zákon, protože bude mít pocit, že trh selhal. Jenže trh neselhal, jen nasazení IPv6 je tak komplikované, že je levnější hackovat současnou technologii. Že to je přirozený vývoj, zatímco celý humbuk kolem IPv6 je uměle nafouknutá bublina. Teď když došly IPv4 adresy se zase o tom mluví. Ale bude následovat pár let, kdy to ještě bude takhle pomalinku hnít.

Při vší úctě - proč se sám shazujete?! Celou dobu se tady bavíme o tom, že v IPv6 _nejde_ jen o zvětšení adresního prostoru a že podle některých ta ostatní vylepšení nestojí za námahu!
Což nás přivádí k těm ostatním bodům - platí přece pro IPv6 úplně stejně!
Sorry že křičím, ale zdá se mi, že to berete nějak moc "politicky"...

Jeden křičí, že je IPv6 jediná cesta, jak překonat došlé adresy, druhý křičí že nejde jen o zvětšení prostoru. Lidi dohodněte se! Já vím, že IPv6 přináší tisíce a jedno vylepšení navíc, ale v tom je ten největší problém, prostě se bude hůře prosazovat. Zvedá to cenu toho HW a tím snižuje ochotu ISP do toho investovat.

Jeden křičí, že je IPv6 jediná cesta, jak překonat došlé adresy, druhý křičí že nejde jen o zvětšení prostoru.
To se přece vzájemně vůbec nevylučuje.

Já vím, že IPv6 přináší tisíce a jedno vylepšení navíc, ale v tom je ten největší problém, prostě se bude hůře prosazovat. Zvedá to cenu toho HW a tím snižuje ochotu ISP do toho investovat.
Můžete uvést příklad alespoň jednoho takového vylepšení, které někdo musí povinně implementovat a zvyšuje to cenu HW? Dnešní krabička u koncového zákazníka musí umět routovat IPv4, filtrovat, DHCP a NAT. Nová krabička u zákazníka musí umět routovat IPv6, filtrovat a získání a přidělení IPv6 adresy, plus dnes by ještě měla umět vše, co IPv4 krabička. Kde tam vidíte co navíc?

No vidím tam navíc IPv6 :-) A pokud tam je navíc IPv6, vidím tam navíc DHCP a NAT a minimální možnost využít existující technologie v krabičce na nový protokol. Takže tam nakonec bude 2x stack, 2x Firewall, 1x NAT, 2x DHCP (no dobře, to druhé se jmenuje oznamování směrovače)

takže nic, co by zvedalo cenu HW, protože síťový stack, přidělování adres i firewal budou muset být v té krabičce vždy, ať už bude implementovat jakýkoli protokol. A dvakrát to tam bude muset být do té doby, než se z IPv4 přejde zcela na něco nového.

všechny ostatní věci jsou totiž ve srovnání s rozšířením adresového prostoru marginální. Samozřejmě, že se můžeme bavit o autokonfiguraci, fragmentaci pouze end-to-end, podpoře mobility, multihomingu, anycastu, ale to jsou z mého pohledu celkem drobnosti.

IPv6 by totiž vůbec nikoho nezajímala, kdyby nám adresy nedocházely. IPv6 je třetí vrstva ISO/OSI modelu a uživatele zajímá tak maximálně ta sedmá.

Jak tady můžete číst: co mi přechod na IPv6 přinese? No, když zakonzervujeme internet v současné podobě, tak mu IPv6 nepřinese vůbec nic. Problém je v tom, že internet v současné podobě zakonzervovat nemůžeme.

„Změnit pár struktur“ rovná se vyhodit zařízení za miliony (které ty struktury mají vypálené v hardwaru) a nahradit je novými. Kdo v takové chvíli chce ta nová zařízení komplikovat a zdražovat složitým způsobem zpracování paketu?

a) nemáte pravdu. Protože můj návrh používal dál IPv4 a u systému, kde nebylo třeba přecházet ze sítě do podsítě by se fungovalo postaru (návrh zněl dát ADREXT do options, což většina krabiček zvládne transparentně)

b) IPv6 tohle nepotřebuje?

IPv6 tohle potřebuje, stejně jako váš návrh. Takže HW musíte vyměnit v obou případech. Rozdíl je v tom, že hardware pro IPv6 může být mnohem jednodušší.

To si nemyslím, navíc u IPv6 musíte vyměnit všechno do poslední krabičky. Já jsem se tomu chtěl vyhnout.

Vyhnout se tomu ale nejde. Kdo nevymění krabičku, nedostane se na nový internet. Takže jde jenom o to, jak drahé ty krabičky budou.

Není potřeba vyměnit všechny krabičky. Předpokládám, že budu provozovat IPv4 uvnitř sítě minimálně dalších 10 roků a to i v době, kdy nebudu mít IPv4 připojení ven.

V případě většiny technologických prvků (kamery, přístupový systém, tel. ústředny, ...) nepotřebuji, aby byly dostupné přímo z Internetu, takže je nemusím měnit. A pokud z nich budu potřebovat přistupovat ven mimo svoji síť, tak použiji proxy či NAT64.
Pro správu z domova již nyní používám VPNku, takže ani zde nebude v budoucnosti problém - pouze při případném upgradu VPNky musím dávat pozor na to, aby uměla tunelovat i IPv4.

"Ono se něco takového časem určitě objeví, až skutečně dojdou adresy"

Adresy už došli. A obávám se, že se nic kromě IPv6 neobjeví. A důvod:
Všichni do IPv6 už vložili tolik finančních prostředků, že zahodit IPv6 a začít s něčím novým je holý nesmysl.

U zmíněných firem pracují výborní kodéři, ale každý nový systém potřebuje měkolik jednoduchých chytrých myšlenek, které může udělat jen pár lidí. (Já je nazývám ideovým křížem systému.) Prý se na nich nemůže podílet více než 7 lidí, protože jinak nedokáží spolu udržet všechny souvislosti. A přesně to se při návrhu IPv6 nestalo, proto 15 let se tento "vlak" nemůže pořádně rozjet.
Je samozřejmě otázka, zda právě tahle situace s IPv6 nebude konečně stropem v dalším rozvoji celosvětového Internetu. Já si klidně dovedu představit, že Čína by si mohla udělat svou IPv4-síť, kde by používala již jinde ve světě přidělené adresy. A navíc by tím krásně zpřístupnila celosvětový Internet jen tam, kde by to bylo dovolené.

vy budete muset při přechodu na IPv6 měnit kabeláž? IPv6 pakety přes Cat5e neprojdou? :-)

Nevidel bych problem ani v CAT3 :D

Tak pan "Admin ." ma mozna specialni kabelaz, ktera IPv6 packety filtruje, co my muzeme vedet...

Tak hlavním smyslem je lépe sledovat pohyb uživatelů... pokud bude mít každý jednoznačnou IP adresu :-)

A pak si o tom něco přečetli a zjistili, že existují Privacy Extensions.

a můžu se zeptat jak budu přijímat digitální televizi na svém analogovém televizoru bez jakékoliv investice? Prosím poraďte.

No a digitální televize taky nepotřebuje změnu infrastruktury? Žádná nová zařízení na vysílačích?

Don't feed the troll

Až Vám provider sebere veřejné IPv4 adresy a strčí Vás za váš oblíbený NAT, tak celá vaše VPN a OWA Vám bude na dvě věci. Kapišto?

Ty adresy totiž nejsou vaše víte? A dokonce ani providera. A proč by to dělal? No možná neudělá, když zaplatíte.

Já jsem nevyhrožoval, jen popsal pravděpodobný scenář za pár let a tak aby to pochopili i Natvrdlíci. No alespoň, že uznáváte, že IPV6 bude potřeba :-)

Já osobně netvrdil, že přejít máte všude už včera :-) Vy jste, ale IPv6 tvrdošíjně úplně odmítal. A ne, jeden hráč na Internet opravdu s ničím jiným přijít nemůže. Zbyl by mu jen ostrůvek pro pláč :-) Alternativa prostě není a nebude. Implementace IPv6 už je prostě moc daleko.

To mi připadá argumentaci z Otce prasátek:

Zuzanka: Tohle byla poslední chvíle
Smrt: VŽDYCKY JE ČAS NA DALŠÍ POSLEDNÍ CHVÍLI

Ano z jeho pohledu to tak vypadá :-) Navrhuji provést AškEnte a zeptat se ho na IPv6 :-)

Smrťova IP adresa je: DEAD::1
:-)

Tak bohužel:

[root@server ~]# ping6 DEAD::1
PING DEAD::1(dead::1) 56 data bytes
From 2001:4860::1 icmp_seq=0 Destination unreachable: No route

Možná před tím provést ten rituál, ale okolo čeho mám nakreslit ten kruh? :-)

Ne nakreslit, natáhnout TokenRing okolo sálového počítače :-)

Ah tak! Nějaké MAU bych tu snad i splašil, ale sálový počítač? Bude muset stačit zaprášená 286. A to by bylo, aby se Smrť nezachvěl, až tam uvidí běžící Windows 7! :-)

Je ho potřeba konfrontovat s modrou smrtí?

... Až Vám provider sebere veřejné IPv4 adresy a strčí Vás za váš oblíbený NAT

Tak nebude problém za nějaký poplatek si tu IPv4 adresu u něj koupit. Bude ji pro mě mít, protože jiní zákazníci ten poplatek nebudou ochotni dát. V nejhorším této příležitosti rád využije jiný provider.

Proč by "všem sebrali IPv4"? Oni na tom budou chtít vydělat. Co nejvíc. Mnohem pravděpodobnější je, že poplatek za adresu bude třeba 200 Kč, 400 Kč, 600 Kč / měsíc. Až se najde nějaký rovnovážný stav. Když se půlka lidí s domácím ADSL veřejné IPv4 vzdá, protože pro ně bude moc drahá, tak pro firmy za klidně 500 Kč / měsíc bude adres dost ještě 20 let.

Každý druhý lokální ISP má naalokováno tolik IPv4 adres, že při nějakém očekávaném růstu mají adres dost taky na 20 let. A to často dokonce ani za veřejnou IPv4 nechtějí peníze navíc. Jen by-default dávají domácí uživatele za NAT. Jo, je to asi síťové zlo, ale je tu taky ekonomická realita.

Uz se tesim, az zacne RIPE odebirat IPv4 adresy vsem kteri se je pokousi prodavat, to bude teprve prdel.

Účtuje se to třeba jako administrativní poplatek spojený s evidencí přidělené adresy. Jo, a vy fakt věříte, že k tomu dojde?

obecně IPv6 opravdu stávajícím uživatelům nic nepřináší. Myslím tak, že nikdo netvrdí, že něco přináší.

Důležité je, že na své zprovoznění čekají asi další 3 miliardy různých zařízení, která chtějí být k internetu připojena.

Jak budete z domova spravovat síť svého zákazníka, když ani jeden z vás nebude mít veřejnou IP adresu? (v budoucnosti se prostě stane, že zákazník opravdu takovou adresu nedostane)

tak pokud se rád škrábete sousedovou levou nohou za svým pravým uchem, tak proč ne.

Rád to třeba nedělám, ale je to tak nejlevnější, a nikdo mi nic dražšího nezaplatí. Síťové ideály se střetávají s ekonomickou realitou.

ano, všechno je to o penězích. A udržování toho vašeho řešení je patrně dražší než zavedení IPv6.

Přijde správce sítě k Bohu a ptá se: Bože, proč jsi mne nezachránil, když docházely IP adresy?
Bůh: když docházely adresy poprvé, poslal jsem ti CIDR. Ale ty jsi nic nevnímal. Když docházely IP adresy podruhé, seslal jsem ti NAT, to už ti opravdu teklo do bot, ale stále jsi nic nedělal. Pak došly IP adresy potřetí. A ty jsi také nic neudělal. Proč se tedy divíš?

:-)

tak to jste nepochopil. Usilovné lpění na IPv4 a čekání na zázrak je otázka slepé víry :-)

konečně rozumné slovo :-)

IPv6 v dohledné době přinese normálnímu uživateli to, že bude moci s ostatními přes internet zadarmo telefonovat bez nějakých pochybných programů a prostředníků (jejichž síť se tu a tam na pár hodin rozpadne), že se odkudkoli dostane k dokumentům a fotkám, které má doma na počítači, že mu technická podpora nebo kamarád pomůže s počítačem rovnou na dálku přes internet, že si informace v mobilu bude pohodlně on-line editovat ze svého počítače nebo že si z mobilu do svého počítače pohodlně stáhne fotky. Dneska to sice může přes nějaké prostředníky a registrace dělat také, ale je to zbytečně složité, a ještě složitější pro autora takového programu – musí zajistit a zaplatit i tu zprostředkova­telskou službu.

No a už si Skype vsimnul, ze některé sítě jsou komplet IPv6 schopné provozu? Nebo pořád budu z Brna do Prahy telefonovat přes Oslo, jenom proto, že tam někde byl volný node s veřejnou IPv4 adresou.

Myslíte, že Skype bude chtít sám sebe zahubit? Proč by se Skype zabýval IPv6, když to znamená jeho konec?

To je chyba úvahy. Kdyby teď přišel s podporou IPv6, tak má strejčka a jestě mu to vylepší kvalitu spojení. Naopak, až se objeví software schopné hovorů a videokonference přes IPv6, bude pro Skype příliš pozdě.

Jak jsem si už vyzkoušel, z hlediska aplikace je přechod na IPv6 hračka. Pokud to hoši mají v objektech, určitě jim postačí nahradit objekt s "IPAddr" na "IP6Addr" a vnitřnosti síťového engine upraví tak, aby ve výsledku se vytvářel IPv6 socket a zbytek je stejný.

Vy jste asi nikdy nepracoval s enterprise softwarovým systémem, že? Ano, stačí nahradit třídu za třídu. A pak najít všechny zdroje ke všemu a doufat, že všechny sedm let staré zdrojáky půjdou přeložit současným kompilátorem. A že všechny 3rd party libraries taky umějí IPv6, protože upgrade na novou 3rd party je kompletní nový projekt. A modlit se, aby se nerozhodila interoperabilita s COBOLovými komponentami. A pak provést kompletní otestování celého systému aplikací, vyřešit deployment a vymyslet, jak tu aplikaci přepnout bez odstávky. A celou dobu tiše doufat, že v miliónech řádek zdrojového kódu je jen málo míst, která fungovala jen náhodou a při změně čehokoliv se rozsypou.

A pak se uživatel s bájnou IPv6 konektivitou připojil přes CPE nakonfigurované dle rfc6092, připojil se na WiFi v hotelu nebo na Eduroam ve škole, kde z mnoha důvodů příchozí spojení jsou zablokována. A nic s tím neudělá. A seznal, že bez prostředníků si ˇ(nebo jemu) stejně nezavolá. A přes Skype jo. A seznal, že aby měl doma pořád zapnutý počítač proto, že jednou za měsíc potřebuje jeden dokument nebo fotku, je stejně trochu luxus. To fakt není IPv6 killer-use-case.

Kde berete tu jistotu, že ta příchozí spojení budou blokována i nadále? Provozovatel sítě, který zakáže věc, která je jinak normálně dostupná a ničemu nevadí, asi moc dlouho provozovatelem nebude.

To, že vy jste v životě neslyšel o technologii wake-on-lan, ještě neznamená, že taková technologie neexistuje.

Ono nejde o provozovatele site. Velkou cast techto zarizeni si kupuji a instaluji sami koncovi uzivatele. A pokud tato zarizeni budou defaultne prodavana s aktivovanym firewallem pro prichozi spojeni (jak uz to vypada z ruznych naznaku), tak to v prevazne vetsine pripadu tak zustane nastavene (uzivatele tomu povetsinou nerozumi a instaluji to zpusobem zapoji-funguje).

Jistotu? Nebude to všude. Ale mnohde stále ano. Protože ty důvody, které provozovatel sítě pro takový setup má, s IPv6 nepominou.

Jistě, že normální ISP si to nedovolí. Ale mluvím zejména o případech, kdy se obvykle zdarma připojuji do nějaké cizí sítě, které nabízí v daném místě a čase nejlepší konektivitu (rychlost, latence), ale má jistá omezení. A nejsem v pozici, abych mohl provozovateli diktovat, jak to má fungovat. Jde-li o službu popsaného typu (WiFi v hotelu, restauraci, na letišti, ve škole) pak provozovatel na tomhle fakt neskončí. A ta věc se zakazuje např. jako nejjednodušší a celkem funkční metoda omezení extrémního vytížení sítě P2P aplikacemi. Na té univerzitě to musí být fakt dementi, když mi na WiFi dají veřejnou IPv4 a zakáží věc, které je normálně dostupná a ničemu nevadí.

Pravda, využít na toto wake-on-lan mě nenapadlo. Ale nemusíte hned usuzovat, že jsem o něm v životě neslyšel. Stejně ale. Pro kolik procent uživatelů toto je významný use-case?

Ty důvody pominou. Dnes se navazování komunikace z venku zakazuje, protože ji nedokážete kontrolovat. Běžná dostupnost koncových zařízení z internetu to změní. Zřízení se připojí do sítě a do DNS publikuje IP adresu a porty, na kterých jsou nějaké služby – na portu XY očekává příchozí VoIP spojení atd. Spolu s tou registrací není problém povolit komunikaci i na firewallu.

Už teď se prodávají mediální servery, NAS servery nebo set-top-boxy, ke kterým se dá přistupovat z internetu. Proč by to někdo řešil, když by po to nebyla žádná poptávka? Za pár let to bud úplně normální a lidi se budou divit,jak mohl být někdy internet tak omezený, že dovoloval navazovat komunikaci jen jedním směrem.

Dnes se navazování komunikace z venku zakazuje, protože ji nedokážete kontrolovat

Nejen proto. Tohle je jeden z mnoha důvodů.

Zřízení se připojí do sítě a do DNS publikuje IP adresu a porty, na kterých jsou nějaké služby

Odkaz na nějaký standardní mechanismus, co tohle řeší a je implementován v použitelné podobě? Vím jen o UPNP, a to jsem na moc místech funkční neviděl.

Vy mi tady předkládáte případy ala NAS nebo set-top-box, ale tam nejsme ve sporu. Já celou dobu mluvím o tom, že dnes lidé s notebooky nevyuživají jen domácí sítě, kde rozhodují o konfiguraci a poskytovateli služeb. Ne nevýznamná část uživatelů se někdy pohybuje v prostředí, jak jsem naznačil výše. Tam sice lze udělat všechno, co píšete, ale správce sítě to z nějakého důvodu dnes nepovoluje. A přidání IPv6 to má řešit? Jde o určitý security mechanismus, a i když ho možná odsoudíte jako nesmyslný, obrovské množství lidí, kteří rozhodují o konfiguraci konkrétních sítí, toho názoru evidentně nejsou.

Potom, co jsem se seznámil z důvody, proč jsou příchozí spojení blokována na našem univerzitním Eduroam, rozhodně nejsem přesvědčen, že s přidáním IPv6 tyto zmizí. Že si bude moci endpoint publikovat k firewallu, co chce mít dovnitř otevřené, o to administrátor právě nestojí.

Uvidíme, jak se to vyvine. Ale já takový optimista jako vy nejsem. A neočekávám, že IPv6 ty hromady administrátorů přesvědčí změnit jejich zvyklosti v tomto směru.

V prostředí, o kterých píšete, si klientské zařízení (třeba obil) požádá o registraci portu pro VoIP, SOAP a Torrent. Správce bude mít nastavena taková pravidla, že první dvě registrace projdou, třetí se zamítne. To je jedna varianta. Druhá varianta je, že zakáže vše, a klient to bude tunelovat přes VPN apod. Rozumný administrátor si logicky vybere tu první variantu, protože pak má nad komunikací mnohem větší kontrolu, může zakázat ty služby, které mu síť přetěžují apod. Administrátor, který provoz blokuje jen tak, bezdůvodně, si zvolí druhou variantu, a brzy bude spokojen, protože v síti nebude mít jediného uživatele.

Aplikace a mechanismy využívající IPv6 a otevřeného internetu budou postupně vznikat, jak se bude IPv6 rozšiřovat mezi lidi – do teď nebyl důvod tohle řešit, protože spousta zařízení je za NATem.

Az na to, ze jemu to jedno neni protoze to vecne nefuguje.

Asi ste poslednich 10 let encet zadny diskusni fora nebo nebyl na netu, Denne se na milionech strankach resi, proc uzivateli nefunguje to ci ono (libovolna sitova sluzba, od VoIP, pres p2p po hry a dalsi) a vzdy je navine NAT. Je celkem jedno jestli si to blbe nastavil uzivatel nebo jestli mu to blbe nastavil ISP ... vzdy je NAT pricinou toho, ze neco nefunguje uzivatelsky privetive = nestaci to zapojit s spustit.

Je videt, ze moc zakazniku nemate .... pri vasich nazorech a nejspis i vedomostech a sluzbach, se neni co divit.

A nebojte se, oni vas zakaznici do IPv6 dotlaci, a nebo skoncite uplne. Ono by trebas stacilo, aby WoW preslo na IPv6, klidne i nepovine s tim, ze kdo pojede po IPv6 dostane bonusovej mec. A hnedle by se ozvalo par milionu zakazniku co pozaduje IPv6 a vcera bylo pozde.

Az muj zakaznik bude pozadovat IPv6 kvuli bonusovym mecum ve wow na tech stovkach pocitacu, co mu spravuju, tak se tim zacnu zabyvat.
Realisticky to prijde na radu nedlouho pote, co voda zacne tect do kopce a peceni holubi sami letat do ust.

Kdybyste si přečetl můj komentář, dočetl byste se tam, že uživatelům jsou prostředníci jedno do té doby, dokud ta síť funguje. A taky že jde především o vývojáře – aplikaci pro P2P telefonování, pro sdílení souborů, pro on-line ovládání mobilního telefonu, dokáže napsat kde kdo. Jenže zaplatit k tomu infrastrukturu zprostředkovatelů, na to už je potřeba pořádná investice, je potřeba z něčeho platit provoz atd.

Zrovna ten váš problém s voláním z mobilu by nějaká taková aplikace mohla řešit – když budete volat na mobil kolegy či na pevnou od zaměstnavatele, telefonát přepojí přes WiFi a VoIP. Jenže k tomu je potřeba umět se na ten cílový telefon nějak jednoduše přes IP připojit…

Kolik velkých výpadků měla síť Skype za poslední dva roky?

IPv6 je potřeba k tomu abyste mohl snadno navázat komunikaci s cílovým telefonem. Dneska se taková aplikace nerozšíří, pokud není schopná poradit si s NATem. A aby si s ním poradila, musí buď autor zaplatit infrastrukturu zprostředkovatelů, nebo se ta aplikace musí složitě konfigurovat.

Ony se ty svody na spouste mist kvuli digitalu menily stejne, protoze puvodni byly ladeny na jine frekvence a 30let stara kabelaz taky uz ma nejlepsi leta za sebou.

Zpetna kompatibilita neexistuje, kdyby to slo, tak to tak nekdo udela. Flakat kamkoli cokoli do paketu je hovadina, kterou muze vymyslet jen totalni hlupak ktery o routovani netusi ani zbla. Naopak, zpetna kompatibilita je prokleti, na ktery dojede x86. Aktualne to vypada ze ji tezce prevalcuje ARM.

A proto existuje moudry rozhodnuti, ze nerozfofrujeme najednou celej IPv6 rozsah, ale pouze 2000::/3 a zbytek zustane jako rezerva, kdyby se pozdeji ukazalo, ze napr. ty lokalni /64 nebyly uplne nejlepsi napad. Pokud se neco takovyho za sto let stane, tak taky nebude uplne nejjednodussi s tim neco delat, kdyz bude vsechno s /64 pocitat. Ale porad by to melo byt snadnejsi nez dneska s prechodem z IPv4.

Ta jednotna netmaska je navrzena i kvuli celkovemu zjednoduseni administrace. Jinak si nemyslim, ze se svymi /80 na spojovackach spasis svet... nebo dokonce sit sveho zamestnavatele ;) Jen v jedne /48 mas tech spojovacek 65536... a tech /48 bloku mas 65536. Vynasobit tyhle cisla myslim zvladnes... schvalne zkus spocitat, kdy ti dojde /32 ve tve siti. A kdyz si vsimnes, RIPE dnes dela pridely tak, abys mohl dostat minimalne jednu dalsi /32 bezprostredne nasledujici po te, kterou mas dnes... proste se bavime o uplne jinych cislech.

Jeste zajimavejsi je do poctu vztahnout pocet obyvatel na zemi... to je teprve zajimave srovnani, pokud se bavime o tom, kolik IPv4 a IPv6 adres je k dispozici na jednoho obyvatele zemekoule :-) Docela me zajima tva analyza na tema kdy podle tebe dojdou a proc...

Hlavně není důvod adresovat spojovačky jinak než link local. Takže máš adres neomezeně a můžes své Global Aggregatable soustředit tam kde mají své opodstatnění, tedy na koncové VLAN a zařízení.

Pomíjím zmínku o /32. Ne každý je ISP...

tech /48 bloku sice je v /32 tech 65536, ale uvedom si, ze nemohu celou /32 pouzit jen na spojovacky, neco musi zbyt i na zakaznicke alokace, tedy /48. Jiste, mohu tu alokaci zvetsit, jenze pak uz je ve 2000::/3 misto zase na mene alokaci (budeme-li mit vsichni /31, bude jich polovina, budeme-li mit vsichni /30, pak ctvrtina atd.) Momentalne se za kazdou /32 alokaci nechava sedm dalsich volnych, takze realne je misto na 2^26 takovych alokaci, coz je nejakych 66 milionu. Muze to byt dost, dnes. Pred dvaceti lety se lidem take zdalo, ze 2G IPv4 adres je dost. Ale co az kazdy residencni a mobilni zakaznik bude chtit tu pro nej urcenou /56, aby tam mel dostatecny prostor pro vice svych /64 subnetu? (typicky uzivatel bude mit patrne pevne pripojeni a k nemu jeste nejmene jedno mobilni, spise se da cekat, ze ke kazde aktivovane simkarte bude /56 a tech simkaret ma mnoho lidi vice nez jednu).

Nedam ti analyzu, kdy podle mne dojdou. To totiz nemuzeme vedet, nemuzeme vedet, jake se v budoucnu objevi aplikace a jak budou ty adresy vyuzivat. A proto je rozumne se k tem adresam uz dnes chovat hospodarne.

pardon, 4G IPv4 adres, preklep.

a pozorujete nějaké problémy, když teď přispíváte přes IPv6?

Tady ne, tady sedím na páteři. Doma ano. Veškerý obsah, co nabízí IPv6 konektivitu je pomalý, protože to musím tunelovat (přestože stejný obsah běží i po IPv4 rychle). Takže to mám vypnuté.

(upřímě, nejsem moc šťastnej, že někdo zná adresu mého počítače)

Tak si zmente mac adresu sitovky nebo si nastavte IPv6 adresu staticky nejakou jinou, nez tu, kterou vygeneruje EUI...

Ať udělám cokoliv, pořád to bude adresa mého počítače :-)

privacy extensions?

„(upřímě, nejsem moc šťastnej, že někdo zná adresu mého počítače)“

A jakpak to vadí? Mně je to celkem fuk, dokonce už mám i DNS záznam - ee.hrach.eu

Jo a kdybyste se divili, proč je v hlavičce komentáře můj IPv4 ISP, tak je to proto, že jsem si nastavil preferenci IPv4, protože tunel bývá přes den přetížený :-(.