Vlákno názorů k článku IPv6 Mýty a skutečnost, díl I. - Jak jsme na tom od gilhad - Az muj zakaznik bude pozadovat IPv6 kvuli bonusovym...

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.

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.

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.

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

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.

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.

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.

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.

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.

konečně rozumné slovo :-)

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

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?

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

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

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…

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.

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

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

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

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.

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.

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

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

:-)

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

pardon, 4G IPv4 adres, preklep.

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.

A take na loopbacky. Takze /32...

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

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.

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

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)

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?

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.

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.

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

Je ho potřeba konfrontovat s modrou smrtí?

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.

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

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! :-)

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

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

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

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

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

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.

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

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

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.

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)

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.

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.

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.

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

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?

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

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

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

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

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

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

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í :-)

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

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.

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í :-)

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

Don't feed the troll

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?

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

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

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

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.

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ý :-(.

„(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

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.

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

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

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.

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

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

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.

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.

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

Ano, je to protokol treti vrstvy, ale ta netmaska /64 byla navrhovana s ohledem na to, ze druhou vrstvou je nejcasteji ethernet (na POS jaksi potreba neni)... Alespon to tak vzdycky kazdy zduvodnoval.
Krome toho, na jinych L2 technologiich si nikdo na autokonfiguraci bud prilis nehraje, nebo, ac se to nezda, je to zase de facto ethernet (802.11 apod.) a delsi identifikatory, nez 48 bitu, se prakticky nevyskytuji.

IPv6 adres je hodne, ale pokud s nimi budeme plytvat, muzeme za par let zjistit, ze jich neni *zas tak* moc. A EUI-48 take existuje...

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.

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.

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)

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.

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.

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

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.

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

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

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

Co vím, tak celý standard je jen o tom, že se něco vymudrovalo. Praxe posléze začala ukazovat, že tam jsou velké problémy.

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

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?

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

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

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

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.

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.

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

Nevidel bych problem ani v CAT3 :D

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

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

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

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.

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

Tak neco takoveho zkuste postavit... pokud mozno na HW :) Na papire se mudruje dobre... horsi je to prevest do bezneho zivota.

Bohužel ještě nikdo nepřišel na to, jak rozšířit adresový prostor a současně zachovat zpětnou kompatibilitu. Ale můžete se u IETF, Cisca, Juniperu nebo někoho dalšího přihlásit se svým geniálním nápadem, tam totiž pracují ti teoretici, kteří nemají s praxí nic společného.

Nesmyslne proc? Argument s MAC adresou je - ehm, zvlastni. IPv6 je protokol treti vrstvy, na druhe vrstve muze byt jakekoliv medium a ne zrovna ethernet (se 48bit MAC), kupodivu... :)) EUI64 neni zdaleka jen pro ethernet...
A potreba curat proti vetru od tebe dnes uz neprekvapi nikoho... :)

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.

Milý ondra.novacisko.cz,
přesně takhle jsem já již před řadou let tady argumentoval, že IPv6 je pragmatický nesmysl, neboť nerespektuje vývoj a skutečnosti v IPV4-Internetu. A všichni teoretici na mě uštěkali přesně jako nyní.
IPv6 je ukázka upachtěného protokolu bez zásadní myšlenky na kompatibilitu s IPv4. Proto se nemůže 15 let prosadit a moc by mě zajímalo, jak to jsou schopni jeho obhájci vyvrátit. Poukazování na to, že implementátoři a správci jsou přihlouplí, když nerozvíjí IPv6, právě ukazuje na to, jak nevhodně je IPv6 navrženo, protože průměrní lidé ho nejsou schopni pochopit a zrealizovat. Ale právě na těchto lidech stojí rozvoj celého Internetu, což si pár zaslepených teoretiků při návrhu IPv6 zapomnělo uvědomit. Hlavně že oni si připadají daleko chytřejší než ostatní - akorát že jim nikdo nechce nebo není schopen jejich výtvory zrealizovat.

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

No tohle je softwarový problém. Protože aktualizace prohlížeče a operačního systému si uživatelé zvládnou vyřešit sami.

Seznam.cz asi bude mít ještě dlouho veřejnou adresu "bez options". Uživatelé, kteří budou mít starý systém budou používat starou IPv4 a ISP je bude routovat přes NAT. Uživatelé s novým systémem bude routovat přes router co umí options. Uživatel bude moci otevřít port na své lokální síti adresované v poli options, ale to už bude vyžadovat, aby protistrana měla novější operační systém. Tady vidím jednoznačnou motivaci, kdy uživatel bude nucen aktualizovat.

Pro BFU může příslušný ISP zřídit informační stránku s informací, co ma BFU udělat, aby se na svou pornostránku dostal (které budou prvními na tomhle systému)

Porovnat číslo na pevné pozici v paketu s nějakou tabulkou je docela jednoduchá úloha, která se dá dobře implementovat na hardwarové úrovni. Řešit nějaké posouvání čísel a jejich přepisování a hledání té správné délky, to je mnohem náročnější operace.

Kdy naposledy bylo tolik volných IPv4 adres, že byste je mohl takhle rozdat ISP tak, aby routovací tabulky nenabobtnaly na několikanásobné velikosti? Jak byste prakticky řešil komunikaci? Třeba v případě, že jde o staršího klienta (třeba starší verze prohlížeče), který o nějakých číslech počítače v options nemá vůbec tušení – uživatel napíše do prohlížeče www.seznam.cz, počítač se zeptá na A záznam, dostane IPv4 adresu, podle té se doroutuje až na hranici sítě ISP, tam se zjistí, že není vyplněno options, tak se zpátky pošle ICMP zpráva "sorry, nedostupné". A klient musí jít a vyměnit své zařízení za nové, které rozumí té options. No jo, ale když už bude měnit to zařízení, to už se ta změna protokolu dá udělat rovnou pořádně, ne? Tak, aby to nepřekáželo dalších padesát let.

IPv6 kromě velikosti adres řeší ještě něco dalšího, ale kdo vás nutí to používat?

jenomže když už uděláte i tak drobný zásah, jak popisujete, tak se dostanete do úplně stejné situace jako s IPv6. Jistou dobu budete muset běžet současně obě verze. A zkuste to udělat nějak rozumně. Budete muset vyměnit protokolové stacky na všech připojených počítačích, atd. Prostě jste na tom stejně jako s IPv6.

Pletete, tak například IP adresa by se dala rozsat jen ISP a číslo počítače v podsíti by se dalo hodit třeba do options.

IPv6 řeší kromě adres i routování, oznamování cest, autokonfiguraci, broadcast a multicacast, hledání nejbližšího a podobně, což se dneska dá docílit i jinak a funguje to.

Zlaté pravidlo platí, pokud to funguje, tak se v tom nehrabat.

Ad dynamická délka adresy. totiž ono o to velké routování jde. Síť nikdy nebude každý s každým, ale nějaká hierarchická úroveň tam bude. Pokud si velké routery budou všímat například prvních 4 čísel, nepotřebují vědět, že paket obsahuje další upřesnění v rámci podsítě. Organizace od ISP k uživateli a jeho pěti domácím počítačům pak bude umožňovat právě další čísla v adrese. ISP si třeba vezme další tři, podle počtu zákazníků, a uživatel si přidá jedno, nebo dvě, nebo taky pět, podle svých potřeb.

Podle délky adresy by se pak poznalo, do které podsítě se paket má vydat. Při průchodu sítí se pak adresa přijemce upravuje podle aktuální podsítě a adresa odesílatele se doplňuje tak, aby jednoznačně identifikovala zdrojovou podsíť aktuální síti. Nevím, ale jestliže současné routery zvládnou implementovat složitosti IPv6, nějaké šoupání s čísly v rámci nemůže být problém.

Myslel jsem zvyklosti na každé úrovni. Mění se třeba zápis adresy, která propadne až do aplikační úrovně (jiné znaky než tečky a čísla). mění se způsop přidělování adresy, způsob oznamování cest a směrovačů, způsob překladu adresy na linkové vrstvě. Změny jsou na všech úrovních. A to je ta komplikace.

Ano, presne totez bys mi rikal v roce 1992, kdybych oznacoval za neefektivni classful routing :-)

Mimochodem, pouzivani /64 je ponekud nesmyslne, kdyz mac adresa ma 48 bitu. Nepovazuji za nezbytne vedet, ze IPv6 adresa byla pridelena pomoci EUI-64 (ono to ani neni spolehlive, protoze IPv6 adresu, ktera jako pridelena by EUI-64 vypada, mohu nakonfigurovat i staticky), cili /80 mi prijde jako vyrazne logictejsi i efektivnejsi rozsah pro takove ucely. Cili ja mam pro RFC ignoranty pochopeni, dokonce lze rici, ze i jiste sympatie... ;-)

A co vas nuti to takto vnimat? Pokud se podivate na IPv6 velmi zjednodusenou optikou, tak se adresni prostor proste jen zvetsil z 32 na 128 bitu. A nejen to, pro sitove spravce prinasi dalsi zjednoduseni v podobe ujednoceni sitove masky - zjednodusene receno naopak odpada dumani nad tim, zda je na subnetu /30, /28, /26, /24... vsude s IPv6 mate mit /64, tedy pokud nejste RFC ignorant... :-)

Dynamicka delka adresy se velmi slozite implementuje v praxi. Ted opravdu nemam na mysli nejake softwarove routery (aka krabicky u lidi doma), ale velke platformy routujici desitky-stovky gigabit... kde se pouziva ponekud jinych technologii.

Muzete mi rict, se kterym soucasnym HW neni IPv6 kompatibilni? :-) A ze IPv6 neni kompatibilni s ISO/OSI? V tom pripade si dovoluji prohlasit, ze ISO/OSI model vubec nechapete. Realita je takova, ze vyssi i nizsi vrstvy jsou nedotceny, jedine co se meni je treti - sitova - vrstva.

Vy jste, jak se tak dívám, chytřejší než celé IETF. Nejste taky náhodou nějaký managor?

Mohl byste napsat, co jsou to ty „všechny cíle“, vedle zvětšení adresního prostoru? A alespoň jedno z těch tisíce a jednoho řešení, jak se to dalo udělat lépe, když máte po světě miliardy zařízení, které umí jen současné IPv4 a máte rozebránu většinu adresního prostoru IPv4? Já si totiž myslím, že když vezmete v úvahu realitu, nakonec stejně dojdete k něčemu velmi podobnému IPv6. Ale možná se pletu…

Obrovskou chybu se tvůrci dopustili úplně na začátku a to snahou vyřešit všechny cíle v jednom balíku (all-in-one). To nikdy nefunguje. Kdyby šlo jen o množství adres, dokázal bych si představit 1000 a 1 alternativní řešeních. Od prostého zvětšení prostoru na zápis adresy, až po nějakou formu relatovního adresování s dynamickou délkou adresy, ve kterém by adresy nikdy (!) nedošly.

Bohužel, výsledkem je "úplně jiný protokol" nejen nekompatibilní se současným HW architekturou, ale i s typickými zvyklosti na všech vrstvách ISO OSI. Nedivte se, že existuje taková neochota. Rozběhat služby na IPv6, tak aby to fungovalo všem, i těm, kde IPv6 protokol je "zapnut", ale nefunguje, kde provideři neimplementují všechny aspekty toho velkého all-in-one balíčku, to stojí hodně úsilí a prostředků