Proč řešit nedostatek IPv4 adres složitě?

14.2.2010 15:34 | Přečteno: 2705× | Linux | poslední úprava: 14.2.2010 15:35

Tak mě dneska napadlo, proč se řeši nedostatek IPv4 adres tak složitým a nepochopitelným mechanizmem jako je IPv6. Proč to nejde jednodušeji.

Dneska mě napadlo řešení, které by nebylo vůbec špatné. Proč se prostě nepřidá na začátek, nebo konec stávajících IPv4 adres, další číslice, s tím, že stávající IP adresy by na tomto místě měly třeba 0? Tím by se přece zvětšil počet dostupných adres a stavělo by se přitom na již zavedeném řešení, místo vymýšlení něčeho nového a neprověřeného.

Nebo to je něco naprosto hloupého? Přikládám anketku:

       

Anketa

Komentáře

[trekker.dk]

Přesně to IPv6 dělá, akorát nepřidává jednu číslici, ale 12. Přidání jedné číslice by znamenalo úplně stejné problémy, ale za pár let by se muselo řešit totéž znova.

[Luk]

IPv6 toho dělá poněkud víc. Jenže říkat, že je to špatně, není až tak na místě (ne všechno je samozřejmě dokonalé, ale to je na jinou diskusi) - protože když už se to předělává, tak ať se toho vyřeší co nejvíc najednou.

[vencour]

Nedávno byla celkem zajímavá diskuse na Lupě ... o tom, že jakákoliv změna IPv4 toho přinese více, než se zdá, než laik čeká.

[Grunt]

Přesně. Z toho důvodu tu máme něco jako verze protokolu. Pokud ne kvůli nedostatku adres, tak jednou by to stejně muselo přijít ať se to líbí nebo nelíbí komu chce. Ten adresní rozsah už jen jen taková třešnička na dortu. Podobné nabastlování je cesta do pekel. A jako odstrašující příklad slouží třeba architektura x86. To je přesně ten případ, kdy se člověk neubrání tomu Tak takto teda ne.

[Ondrej 'SanTiago' Zajicek]

A jako odstrašující příklad slouží třeba architektura x86

A IPv6 slouzi jako odstrasujici priklad pro opacny pristup ('navrhneme to vsechno znova, ciste a bez ohledu na soucasny stav a moznosti prechodu').

[Käyttäjä 11133]

Jako možnosti přechodu plnohodnotně postačuje dual stack provoz.

[Ondrej 'SanTiago' Zajicek]

Myslim, ze soucasny stav (globalniho) prechodu na IPv6 toto tvrzeni uspesne vyvraci.

Navrh IPv6 je sice v poradku z hlediska sitarky-inzenyrskyho, ale pokud se na to clovek podiva z hlediska 'herne-teoretickeho', tak je mu jasne, proc soucasne nasazeni IPv6 je presne v tom stavu v jakem je.

[Grunt]

ale pokud se na to clovek podiva z hlediska 'herne-teoretickeho', tak je mu jasne, proc soucasne nasazeni IPv6 je presne v tom stavu v jakem je.

Jen ať si to zrekapitulujeme: A to je teda proč?

[Jendа]

Já měl za to, že kravaťáci.

[Käyttäjä 11133]

Ne kravaťáci ne, peníze, jako vždycky. :)

[xkucf03]

Částečně i ne-kravaťáci, kteří mají dobré znalosti IPv4 a bojí se, že by přišli o svoje výsadní postavení – nebo by se museli učit něco nového, což je neba, protože k machrování na BFU stačí znát z hlavy pár IPv4 adres a jsou z nich polobozi.

[Ruža Becelin]

Mluvis z vlastni zkusenosti?

Hlava je rychlejsi jak ruka. Spousta lidi, co konfiguruje site, ma v hlave "nakreslenou" sit, znaji adresy routeru, masky, neblizsi DNS atd. Je proste fakt, ze IPV4 je lehci k zapamatovani nez IPV6, jestli budes litat po klientech s tuzkou a papirem, tak moc efektivni nebudes

Nemam nic proti nasazeni IPV6, ale jak tady nekteri uvedli, zatim neni poptavka, prechod bude dost stat a penize na takovy projekt se hledaji tezko, pokud "business" nevidi prioy zisk, apod.
Plus dalsi problemy:
* Vykon IPV6 - se zapnutym IPV6 ma sit prokazatelne horsi vlastnosti (nepatral jsem proc), bohuzel to vede k tomu, ze se objevuje cim dal vic clanku s doporucenim IPV6 vypnout.
* Bezpecnost - jakkoli IPV6 zlepsuje bezpecnost na papire, zatim nejsou prakticke zkusenosti (botnety, wormy, hacking) - duvod je ten, ze IPV6 neni pro gangy zatim dostatecne atraktivni, takze se neni na cem ucit.
* Firewall - IPTables vs. IP6Tables apod. - proc musim psat pravidla 2x?

Ptal jsem se na IPV6 u nas, odpoved znela, ze IPV4 staci, rekl bych, ze tohle bude obecny nazor. Nikdo si nechce pridelavat praci s IPV6, protoze to stoji cas, a cas jsou penize.

[vencour]

Napadá mne jedinej hlavní důvod, proč IPv6 vyhraje. Za dobu, co se IPv4 používá, se hodně změnilo, dobastlilo se tam dost věcí. Proto ten současnej stav s IPv6 nelze brát jako konečný.

[Martin Mareš]

Vykon IPV6 - se zapnutym IPV6 ma sit prokazatelne horsi vlastnosti (nepatral jsem proc), bohuzel to vede k tomu, ze se objevuje cim dal vic clanku s doporucenim IPV6 vypnout.

Dohady. Nějaká konkrétní čísla by nebyla?

[Luk]

Já vím jen o tom, že se systém (přesněji DNS resolver) nejdřív dotazuje na AAAA záznam (i když k tomu použije IPv4) a teprve následně na A záznam, čímž vzniká určitá prodleva.

[petr_p]

Což se dá klidně vypnout nebo otočit. Pouze otázka výchozí konfigurace. Až bude IPv6 převažovat, budeme tvrdit, že dotazování se na neexistující záznam A zdržuje, a tudíž IPv4 snižuje výkon?

Naopak z mých měření linuxové implementace vyplývá, že třeba ICMPv6 Echo Request je vyřízen rychleji než ICMPv4.

[Luk]

Což se dá klidně vypnout nebo otočit. Pouze otázka výchozí konfigurace.

Ale samozřejmě. Jen říkám, že jediný případ "zhoršené funkce", který jsem zaznamenal, je právě toto.

[Grunt]

Spousta lidi, co konfiguruje site, ma v hlave "nakreslenou" sit, znaji adresy routeru, masky, neblizsi DNS atd. Je proste fakt, ze IPV4 je lehci k zapamatovani nez IPV6, jestli budes litat po klientech s tuzkou a papirem, tak moc efektivni nebudes

Ti schopnější z nás jsou schopni si udělat nějaký systém. Ti línější jsou alespoň schopni si nějaký systém zakoupit. A ti líní a neschopní jsou vždy schopní si alespoň najít nějakou výmluvu proč to nejde-

Nemam nic proti nasazeni IPV6, ale jak tady nekteri uvedli, zatim neni poptavka, prechod bude dost stat a penize na takovy projekt se hledaji tezko, pokud "business" nevidi prioy zisk, apod.

A proto nemám rád, když se business plete do věcí ve kterých nemá co dělat. Jde o změnu interního protokolu. Tak jaká proboha nabídka, poptávka a nebo business. Ve spoustě odvětví, k takovému nahrazování novějšími protokoly probíhá neustále a není potřeba do toho plést žádný business. Proč zrovna v případě internetu jo?

Vykon IPV6 - se zapnutym IPV6 ma sit prokazatelne horsi vlastnosti (nepatral jsem proc), bohuzel to vede k tomu, ze se objevuje cim dal vic clanku s doporucenim IPV6 vypnout.

K tomu by ml být jaký důvod krom toho, že by tomu nerozuměly ASICy?

Bezpecnost - jakkoli IPV6 zlepsuje bezpecnost na papire, zatim nejsou prakticke zkusenosti (botnety, wormy, hacking) - duvod je ten, ze IPV6 neni pro gangy zatim dostatecne atraktivni, takze se neni na cem ucit.

Čtenář CHIPu nebo PR manažer?

[Ruža Becelin]

Ach jo.

Ti schopnější z nás jsou schopni si udělat nějaký systém. Ti línější jsou alespoň schopni si nějaký systém zakoupit. A ti líní a neschopní jsou vždy schopní si alespoň najít nějakou výmluvu proč to nejde-

Cetls vubec, na co reagujes?

A proto nemám rád, když se "business" plete do věcí ve kterých nemá co dělat. Jde o změnu interního protokolu. Tak jaká proboha nabídka, poptávka a nebo "business". Ve spoustě odvětví, k takovému nahrazování novějšími protokoly probíhá neustále a není potřeba do toho plést žádný "business". Proč zrovna v případě internetu jo?

To je asi tak vsechno, co s tim udelas.

K tomu by ml být jaký důvod krom toho, že by tomu nerozuměly ASICy?

Vic Luk o kousek vys.

Čtenář CHIPu nebo PR manažer?

Ani jedno. Rypani misto argumentu? Nebo jeden z obhajcu "IPV6 za kazdou cenu"?

[Grunt]

Cetls vubec, na co reagujes?

Ano četl a reakce na:

Hlava je rychlejsi jak ruka. Spousta lidi, co konfiguruje site, ma v hlave "nakreslenou" sit, znaji adresy routeru, masky, neblizsi DNS atd. Je proste fakt, ze IPV4 je lehci k zapamatovani nez IPV6, jestli budes litat po klientech s tuzkou a papirem, tak moc efektivni nebudes

je taková, že to zefektivním nějakým systémem tak aby si nikdo žádnou adresu nikdo pamatovat nemusel, ale aby se všechno zpracovalo automaticky a dalo se pak třeba už jen pracovat s doménovým jménem. Prostě a jednoduše, to že se špatně pamatuje pro mě není argument proč se vehementně držet IPv4. Je to jako nepoužívat mobilní telefon z toho důvodu, že telefonní čísla na pevnou se lépe pamatují a nikam si je nemusím psát.

Vic Luk o kousek vys.

Jako delší odezva DNS? To není ani výmluva a ani vtip. Když už nic, tak se to dá vyřešit keší nebo vlastnoručně nastaveným BINDem.

Ani jedno. Rypani misto argumentu?

Změní se protokol na jedné ze síťových vrstev. Proč by to proboha hned mělo být bezpečnější nebo já nevím jaké? Je to je jako argumentovat pro TCP místo UDP, protože je bezpečnější nebo nějaká podobná kravina.

Nebo jeden z obhajcu "IPV6 za kazdou cenu"?

Neobhajuji ho za každou cenu. Ale rád už by se s ním konečně někde setkal.

[Ruža Becelin]

Mit system, kde je vsechno automatizovane, proti tomu nic nemam. Jenze tohle je od reality zatim hodne vzdalene a kdyz budu sedet u zakaznika, snazit si pingnout na branu, tak holt tu IP adresu mit nekde musim.

Delsi odezva DNS problem neni, spis mam pocit, ze se system pokouzi spojit pres IPV6 predtim, nez zkusi IPV4. Coz je sice v poradku a (v budoucnu) by to tak funogvat melo, ale ne dneska.

Zmena protokolu je sakra dulezita vec z hlediska bezpecnosti. Nemyslel jsem bezpecnost IPV6 obecne, ale situaci ted. Pochybuji, ze nekdo poradne otestoval ruzne typy utoku, navic hlavicka se da modifikovat stejne jako u IPV4. Serou se s tim jak dlouho a porad to neni dotazene - TO je hlavni problem. Je mi nekde jestli bude mit moje lednicka IPV6 adresu a bude dostupna z internetu, ale neni mi jedno ze si tu lednicku nezabezpecim kvuli diram v protokolu. Proto je potreba brat nasazeni IPV6 zodpovedne - jestlize se udela hura akce s masovym prechodem na IPV6, tak prvni botnet, co po tomhle bude umet chodit, udela takovou paseku ,ze se budeme divit vsichni.

Taky bych se rad setkal s IPV6 masove. S odladenym IPV6 bez destkych nemoci. Taky s fungujicim prekladem adres, protoze pamatovat si IPV6 adresy po mne nikdo chtit nemuze...

Ja si nemyslim, ze si nejak oponujem, puvodne jsem totiz reagoval na tohle:

Částečně i ne-kravaťáci, kteří mají dobré znalosti IPv4 a bojí se, že by přišli o svoje výsadní postavení – nebo by se museli učit něco nového, což je neba, protože k machrování na BFU stačí znát z hlavy pár IPv4 adres a jsou z nich polobozi.

a ne na to, ze bych mermomoci obhajoval IPV4...

[petr_p]

snazit si pingnout na branu, tak holt tu IP adresu mit nekde musim

Pamatovat si ff02::2 je fakt strašně těžké.

[Ruža Becelin]

Hmm, to vypada dobre, otazka je, jestli to taky tak dobre funguje...

[Käyttäjä 11133]

Na sítích s podporou milticastu ano.

[petr_p]

Vzhledem k tomu, že to je link scope multicast a routery jej musí umět z definice (protože na tom závisí ostatní služby), tak na tom není snad ani co zkazit.

Zábavnější je oťukávat adresy sítě, čímž lze mapovat strukturu zapojení routerů. Čekám ale, že CISCO a jemu podobní brzy udělají všechny povinnosti volitelné a ve výchozím nastavení vypnuté, aby mohli ukazovat, jak myslí na bezpečnost.

[Grunt]

Mit system, kde je vsechno automatizovane, proti tomu nic nemam. Jenze tohle je od reality zatim hodne vzdalene

Já neříkám všechno, ale DHCP nebo databáze je očividně pro někoho novinka. Viz třeba ISPAdmin. Existují i lidé co to provozují a nemají ponětí co je to IP adresa.

a kdyz budu sedet u zakaznika, snazit si pingnout na branu, tak holt tu IP adresu mit nekde musim.

ping brana.poskytovatel.…?

Zmena protokolu je sakra dulezita vec z hlediska bezpecnosti. Nemyslel jsem bezpecnost IPV6 obecne, ale situaci ted. Pochybuji, ze nekdo poradne otestoval ruzne typy utoku, navic hlavicka se da modifikovat stejne jako u IPV4. Serou se s tim jak dlouho a porad to neni dotazene - TO je hlavni problem.

IPsec.

Je mi nekde jestli bude mit moje lednicka IPV6 adresu a bude dostupna z internetu, ale neni mi jedno ze si tu lednicku nezabezpecim kvuli diram v protokolu. Proto je potreba brat nasazeni IPV6 zodpovedne - jestlize se udela hura akce s masovym prechodem na IPV6, tak prvni botnet, co po tomhle bude umet chodit, udela takovou paseku ,ze se budeme divit vsichni.

Jó to takový NAT, ten ty zařízení od internetu odstíní… – nesnaží se mi to tady doufám někdo nacpat, že?

Ja si nemyslim, ze si nejak oponujem, puvodne jsem totiz reagoval na tohle:

Částečně i ne-kravaťáci, kteří mají dobré znalosti IPv4 a bojí se, že by přišli o svoje výsadní postavení – nebo by se museli učit něco nového, což je neba, protože k machrování na BFU stačí znát z hlavy pár IPv4 adres a jsou z nich polobozi.

A já zas mám pocit, že si oponujeme, protože v tom já s Frantou plně souhlasím.

a ne na to, ze bych mermomoci obhajoval IPV4...

Já se také nesnažím obhajovat mermomocí IPv6. Já jen nesnáším ten přístup k problému v případě jeho nasazení. Proto oponuji.

[Ruža Becelin]

"Jó to takový NAT, ten ty zařízení od internetu odstíní…" – nesnaží se mi to tady doufám někdo nacpat, že?

O NATu jsem nemluvil. Mluvil jsem o dirach v protokolu.

A já zas mám pocit, že si oponujeme, protože v tom já s Frantou plně souhlasím.

To ja ne, protoze Franta si castecne oponuje sam:

A) Částečně i ne-kravaťáci, kteří mají dobré znalosti IPv4 a bojí se, že by přišli o svoje výsadní postavení - kdo zna dobre IPV4, nebu mit problemy se naucit IPV6, tudiz se nemusi bat o svoje "vysadni postaveni", at uz je tim mysleno cokoli.

B) nebo by se museli učit něco nového, což je neba, protože k machrování na BFU stačí znát z hlavy pár IPv4 adres a jsou z nich polobozi. - viz A), pokud se naucili IPV4, nebudou mit problemy se ucit IPV6 a takovi nemaji potrebu machorvat se znalosti par IP.

Já jen nesnáším ten přístup k problému v případě jeho nasazení. Proto oponuji.

Proc se IPV6 nenasazuje hromadne viz nize v diskuzi. Co se problemu pri nasazeni tyce, uvidime, jak bude praxe (tj. na co se pri navrhu zapomnelo).

[Shadow]

A proto nemám rád, když se "business" plete do věcí ve kterých nemá co dělat. Jde o změnu interního protokolu. Tak jaká proboha nabídka, poptávka a nebo "business". Ve spoustě odvětví, k takovému nahrazování novějšími protokoly probíhá neustále a není potřeba do toho plést žádný "business". Proč zrovna v případě internetu jo?

Protože se jedná o investici, u které čistě logicky vedení zajímá, jak se budou vynaložené prostředky podílet na zisku a s jakou pravděpodobností. A pokud se jedná o spoustu vynaložených prostředků, aniž by za nimi byl zisk či nějaká reálná konkurenční výhoda, pak má daný návrh smůlu.

Jinak, nebýt toho ošklivého "businessu", který se plete do rozhodování o vynaložení prostředků, tak ta společnost již nejspíše neexistuje (bankrot). Výjimkou mohou být do jisté míry neziskovky a státní podniky, které operují s pevným rozpočtem a nemusí dosahovat zisku, aby přežili.

[Grunt]

Jenomže když takto bude uvažovat každý, tak ty adresy skutečně jednou dojdou. A co pak? Nikdo nebude mít strategickou výhodu z přechodu a adresy nebudou. Tak se začne ještě s masivnějším NATováním? To je přece zadarmo. No tak to 3× hurá. Prostě jednou za čas je potřeba v jakémkoliv odvětví techniky s přechodem na novější zařízení/protokol/formát a každý by si na něco takového měl držet rezervu. Sice to není konkurenční výhoda pro nikoho, ale v důsledku pokud se do toho pustí všichni je to výhoda pro všechny. A nebo už se zapomnělo jak to bývalo třeba s peerováním na počátcích internetu?

[Shadow]

Jaká strategická výhoda z přechodu? IPv6-only dneska (skoro) nikdo není, zatímco drtivá většina přistupuje přes IPv4 a ještě dlouho přistupovat bude. To není strategická výhoda, to je investice do infrastruktury, která něco přinese až daleko v budoucnu.

Pro firmy je finančně výhodnější začít se zajímat o IPv6, až to bude akutní, resp. až budou na IPv6 zákazníci, co nebudou moci přijít přes IPv4, nebo až kriticky stoupnou ceny za IPv4 adresy.

Peníze, které teď investuji do prodeje, mi přinesou v bezprostředně následujících obdobích zisk. Peníze, které teď investuji do infrastruktury, mě připraví o peníze, které mohu investovat do prodeje.

Nehledě na to, že IPv6-ready zařízení by měly být dražší a přechod na IPv6 stejně ještě nejméně roky potrvá - ta zařízení bude nejspíše možné v budoucnu koupit levněji, ale také nové. Když ta zařízení koupím teď, tak vyhodím spoustu peněz, ale ona mi budou ležet téměř ladem, nevyužívané (s výjimkou několika málo jedinců, kdo ví jestli), a budou stárnout a ztrácet svou hodnotu.

[Shadow]

Jinak, prosím, nechápejte mne špatně - já vaše pocity sdílím - také bych byl rád, kdyby všichni přešli hned nebo v nejbližší budoucnosti. Jen se vám pokouším přiblížit uvažování a pohled manažerů.

Bohužel se obávám, že "kdyby takle uvažoval každý" je záležitost typická pro lidi obecně. Dát se dohromady a udělat něco, co nás bude teď stát úsilí a prostředky, abychom předešli nějakému budoucímu problémovému stavu, je nesmírně těžké, a v mnoha situacích musí dojít opravdu ke krizi, aby se něco začalo dít. A asi na to dojde i v případě IPv6.

Potěším vás alespoň tím, že má osobní infrastruktura je nyní IPv6 ready (a to i za cenu tunelu, protože můj ISP IPv6 samozřejmě nepodporuje). Moje VPS a její služby jsou také dostupné přes IPv6.

[Grunt]

Tak kravaťáci jsou samozřejmě příčina všeho zla na zemi, ale ještě teda i mimo ně samotné.

[Ondrej 'SanTiago' Zajicek]

Protoze soucasny stav je v Nashove rovnovaze - zadny ISP neziska (vyznamnou) vyhodu z nasazeni IPv6. Prakticky neexistuje problem, ktery by ISP mohl vyresit tim, ze (sam) nasadi IPv6. Existuje sice globalni optimum (nebo alespon globalne vyhodnejsi rovnovaha) - situace, kdy vsichni nasadi IPv6, ale to neni dosazitelne ze soucasneho stavu hraci, ktere maji '(kvazi)hladove strategie'.

[Grunt]

zadny ISP neziska (vyznamnou) vyhodu z nasazeni IPv6.

A to je myslím celý kámen úrazu. Nasazení IPv6 je interní systémovou záležitostí ve které ISP hrají roli koncových bodů. Tato záležitost se jich nikdy neměla týkat a měli o tom rozhodnou pověřené autority(IANA,…). Tak to prostě dopadá, když se do věci vloží politika.

[Käyttäjä 11133]

A jak to přesně měly ty autority rozhodnout? Přikázat jak to s oblibou dělá EU? Říct jim, že pokud nenasadí do určitého dne IPv6 tak jim seberou jejich IPv4 rozsahy? Nebo jak přesně si to představuješ?

[trekker.dk]

Říct jim, že pokud nenasadí do určitého dne IPv6 tak jim seberou jejich IPv4 rozsahy?

Musíš uznat, že jako motivace by to fungovalo...

[Käyttäjä 11133]

To asi ano, ale nemění to nic na tom, že by to byla hloupost a vydírání.

[Grunt]

ale nemění to nic na tom, že by to byla hloupost a vydírání.

Když všechny ostatní metody (jako nazpívání katastrofických songů) na líné administrátory nezabírá?

[petr_p]

Pak už jen zbývá masivní letáková kampaň.

[Grunt]

Nebo balík smažených kuřat ke každé IPv6 adrese navíc.

[Käyttäjä 11133]

Jenže ono to není o administrátorech, alespoň ne ve velkých společnostech. :) Je to jako vždy o penězích.

[Grunt]

To je mi jasné. Kdo by chtěl měnit novou drahou krabičku co vyšla na 100 000,- za ještě novější a ještě dražší. Ale jak už jsem řekl. Někdy prostě potřeba aby si technické oddělení pořádně duplo, protože v mnoha případech není problém obměňovat vozový park (a to ještě u firmy, která nemá s dopravou nic společného) půlrok co půlrok, ale jak se dostane na obměnu technického vybavení, tak je to neřešitelnější problém než globální oteplování? To je prostě směšné.

[Käyttäjä 11133]

No tak to počkat.. krabičky jsou skoro zadarmo, troufnu si tvrdit, že všechno co je na naší produkční síti umí IPv6. A i kdyby nebylo, tak vyměnit HW je to nejlevnější :) Jenže... nejdřív se musí vytvořit projekt, potom se musí udělat projektový plán včetně back-out plánu, co když to neklapne, vyškolit zaměstnanci, ocertifikovat zaměstnanci a provést samotná implementace, hodiny a hodiny práce specialistů... Do toho nikdo nepůjde, dokud si nějaký velký zákazník neřekne že to chce a až si o to řekne (a zaplatí), tak to do měsíce bude.

A 100 000... ehm 100 000 nejspíš nestojí snad ani ten nejlevnější Nexus :)

[Grunt]

Jenže... nejdřív se musí vytvořit projekt, potom se musí udělat projektový plán včetně back-out plánu, co když to neklapne, vyškolit zaměstnanci, ocertifikovat zaměstnanci a provést samotná implementace, hodiny a hodiny práce specialistů... Do toho nikdo nepůjde, dokud si nějaký velký zákazník neřekne že to chce a až si o to řekne (a zaplatí), tak to do měsíce bude.

Aha. Takže nakonec jsme došli k tomu, že tím problémem si ty.

[Käyttäjä 11133]

Aha. Takže nakonec jsme došli k tomu, že tím problémem si ty.

No já těžko, všechny sítě které mám pod správou jsou buďto IPv6 kompatibilní, nebo nemají s IP protokolem nic společného (FC SAN :) ).

[xkucf03]

Ale administrátoři si docela často dokáží vydupat nákup drahých a zbytečných hraček. Tak proč to neudělají s IPv6, které na rozdíl od jiných věcí zbytečné není?

[Jendа]

Co nepřidělením dalších IPv4 adres? Stejně tak za rok a půl už přidělovat nebudou moci, nebude co.

[xkucf03]

A nebo nasazením tržních cen – prostě se ty poslední adresy budou dražit, kdo dá víc. Cena se bude šplhat nahoru, až lidem začne docházet, že IPv6 má smysl. Pak se IPv6 rozšíří a po IPv4 už neštěkne ani pes a cena těch úplně posledních pár IPv4 adres zase spadne.

[Grunt]

Jak se tady už zmínil Ondřej, tak členové RIR jsou sami ISP, takže si o tom vlastně rozhodují sami a asi by bylo docela bláhové, kdyby si to sami zpoplatnili.

[Ondrej 'SanTiago' Zajicek]

Oni adresy zpoplatnene maji (clenske poplatky se plati take podle poctu pridelenych adres), ale ne na trznim principu.

[Ondrej 'SanTiago' Zajicek]

A nebo nasazením tržních cen – prostě se ty poslední adresy budou dražit, kdo dá víc

Tohle na veci moc nezmeni - pastnu sem rovnou jeden komentar, ktery jsem psal pred nekolika dny pod zpravu o dochazeni IPv4 adres:

Kdyz se mluvi o tom, ze IPv4 adresy dojdou, tak se to tyka toho, kdy dojdou adresy RIRum (mezinarodnim instuticim jako RIPE, ktere ty adresy prideluji LIRum (ISP)). LIRove maji vlasni pool adres, ktery prideluji svym zakaznikum, a maji lepsi moznost (a ekonomickou motivaci) tlacit na sve zakazniky, aby nejake adresy vratili.

Takze az dojdou adresy RIRum, tak nedojde k nicemu dramatickemu, skokovemu, pouze se svet dostane do dlouhodobe agonie, kdy LIRove namisto ziskani dalsich adres od RIRu budou tlacit na sve zakazniky k co nejuspornejsimu vyuziti adres. Pravdepodobne zacnou rovnou poskytovat konektivitu i velkym zakaznikum na privatnich adresach a za kazdou verejnou adresu budou chtit velky poplatek. Stavajicim zakaznikum, kteri na to nebudou chtit pristoupit, proste vypovi smlouvu (cimz ziskaji zpet jim pridelene adresy).

Cena pripojeni s verejnou adresou poroste vysoko tak, aby snizila poptavku po takovem pripojeni na miru, v jake budou dostupne verejne adresy. Takze adresy skutecne jen tak nedojdou. Ta cena muze vyrust dost vysoko, ale stezi natolik, aby se provozovatelum normalnich, na bezne uzivatele cilenych, sluzeb vyplatilo udelat je radsi IPv6-only a tim se omezit na par promile beznych uzivatelu s IPv6 konektivitou.

[David Jaša]

Další fáze pak nastane tehdy, když i přes tato superúsporná opatření nebude možné připojovat nové servery na IPv4, pak bude nepodpora IPv6 dost velká konkurenční nevýhoda. Uvidíme tak za dva až tři roky. ;)

[zulu]

Četl jsi to, na co jsi regoval?

[pavlix]

Mně jeho příspěvek smysl dává :). I když je fakt, že mi dávají smysl tvrzení obou, i když mají své třecí plochy.

[David Jaša]

Četl, proč? Prostě si nemyslím, že výše popisovaný stav bude trvat věčně. Nejdéle do doby, než se začne Internet masivně rozšiřovat po Indii a Indonésii. Čína je podle mě poslední velká oblast, která se do NATy nafouknutého IPv4 vejde.

[Grunt]

S tim příkazem se sice shodneme, no na druhou stranu alespoň nějaký podobný přístup bych ocenil. Co třeba prostě pohrozit, že 5% IPv4 adres bude drženo jako nutná rezerva (jak to dělají třeba exty) pro nejnutnější případy nouze a když se dosáhne takového stavu, tak nech si ISP shánějí adresy kde jenom chtějí? Takové prohlášení by určitě nezůstalo bez odezvy.

[Grunt]

Takové prohlášení by určitě nezůstalo bez odezvy.

Resp. by to dopadlo jako cukrem u nás před vstupem do EU a jenom by se tím uspíšil pád IPv4 (Kua., tady kujeme konspirace…za to určitě půjdeme do vězení) a zrychlilo nasazování jiného (a neříkám, že zrovna IPv6, klidně i něčeho jiného vhodnějšího pokud něco takového existuje) řešení.

[Ondrej 'SanTiago' Zajicek]

Tato záležitost se jich nikdy neměla týkat a měli o tom rozhodnou pověřené autority

No prechod na IPv6 by se jich vzdycky nejak tykal. Tyto mezinarodni organizace ale nemaji zadnou exekutivni moc a jejich veskera moc vychazi z toho, ze je ostatni respektuji, protoze to je pro vsechny vyhodne. Z takove pozice tezko mohou naridit razovy prechod. Nicmene mohly by motivovat.

V prve rade se mel protokol navrhnout tak, aby jednotlivy ISP mohl resit nedostatek svych IPv4 adres prechodem na IPv6. Kdyz uz se to nestalo, meli RIR organizace (jako treba RIPE) modifikovat podminky tak, aby takovy tlak na ISP vytvorily (napr. pro prideleni novych IPv4 adres by musel ISP ukazat, ze pocitace se stavajicimi IPv4 adresami jsou dostupne i pres IPv6). Je ale otazka, zda RIRove by byly schopni vyvinout i jen takovy tlak (preci jenom to jsou clenske orgranizace, a o jejich pravidlech rozhoduji ISP hlasovanim).

Kdyz vsechny tyto moznosti selhali, tak uz ted zbyva asi jenom zasah ze strany statu. Pokud by vyznamna statni moc (USA ci EU) naridila napr. ze koncove domaci pripojky na IPv4 mohou mit rychlost nejvys 1 Mbps (a postupne podle toho, jak se vyviji trh, snizovat), tak by nejspis zmenila pravidla hry tak, aby pro ISP bylo vyhodne nasazovat IPv6 kvuli tlaku zakazniku.

[Jendа]

V prve rade se mel protokol navrhnout tak, aby jednotlivy ISP mohl resit nedostatek svych IPv4 adres prechodem na IPv6.

Jak přesně to myslíš?

Kdyz vsechny tyto moznosti selhali, tak uz ted zbyva asi jenom zasah ze strany statu. Pokud by vyznamna statni moc (USA ci EU) naridila napr. ze koncove domaci pripojky na IPv4 mohou mit rychlost nejvys 1 Mbps (a postupne podle toho, jak se vyviji trh, snizovat), tak by nejspis zmenila pravidla hry tak, aby pro ISP bylo vyhodne nasazovat IPv6 kvuli tlaku zakazniku.

No to bych je asi uškrtil.

[Ondrej 'SanTiago' Zajicek]

Jak přesně to myslíš?

Moznosti je mnoho. Asi nejjednodussi pro vysvetleni je ta, ze by se v podstate pouzilo stavajici IPv6, ale s tim, ze by IPv6 a IPv4 stacky v koncovych zarizenich byly provazane a 6to4 mechanismus by byl standardni chovani pro koncove zarizeni, ktere ma pouze IPv4 adresu a chce komunikovat se zarizenim s (6to4) IPv6 adresou (to oznacim jako IPv6-ready). A naopak koncove zarizeni s pouze IPv6 adresou by pri snaze o komunikaci s IPv4 adresou pouzilo nejakou kanonickou IPv6 adresu v ramci 6to4 rozsahu odpovidajicimu dane IPv4 adrese. I pro nativni IPv6 konektivitu by se pouzivaly (alespon do doby, nez by vsichni presli) pouze 6to4 adresy. Prechod by tedy mel tri faze:

1) samovolna obmena koncovych zarizeni (uzivatelske PC, servery) na koncova zarizeni, ktera jsou IPv6-ready. Tohle v podstate uz probehlo, s koncovymi zarizenimi neni problem.

2) V okamziku, kdy by prevazna vetsina koncovych zarizeni (v celem Internetu) byla IPv6-ready, tak jednotlivi ISP nezavisle mohou preklopit svou sit z IPv4 na IPv6 (ani nemusi udrzovat dualni provoz), jejich IPv6-only uzivatele budou moci bez problemu komunikovat s IPv6-ready uzivateli pripojenymi k IPv4-only ISP. Tahle faze by byla spojena s omezenim pridelovani novych IPv4 adres, v podstate by pouze novi ISP dostali jeden /24 rozsah, aby ho pouzili na 6to4 IPv6 adresy.

3) V okamziku, kdy by prevazna vetsina ISP presla na nativni IPv6, mohlo by se zacit pridelovat ostatni (ne-6to4) IPv6 adresy.

Nicmene tenhle postup by se musel prosazovat od zacatku, dnes uz asi neni situace, kdy by slo zacit prechod resit touhle cestou.

[pht]

Tohle nějak nechápu.

6to4 mechanismus by byl standardni chovani pro koncove zarizeni, ktere ma pouze IPv4 adresu a chce komunikovat se zarizenim s (6to4) IPv6 adresou (to oznacim jako IPv6-ready)

Pokud by v4 zařízení bylo schopno nějak detekovat, že se bude bavit s v6 zařízením, tak proč by probůh k tomu mělo používat 6to4, když už může zrovna jet na v6?

A naopak koncove zarizeni s pouze IPv6 adresou by pri snaze o komunikaci s IPv4 adresou pouzilo nejakou kanonickou IPv6 adresu v ramci 6to4 rozsahu odpovidajicimu dane IPv4 adrese.

Uvědomte si, že přechod z v4 na v6 není jen o adresách. Je to změna spousty dalšího chování.

BTW už jen s těmi adresami je problém. To, co jste právě vymyslel, je něco jako NAT-PT. Už jen s nomálním NATem je dost problémů, a přidáním překladu na úplně jiné adresy se to jen zhorší.

[Ondrej 'SanTiago' Zajicek]

tak proč by probůh k tomu mělo používat 6to4, když už může zrovna jet na v6?

Protoze nema IPv6 konektivitu, ale jen IPv4 konektivitu.

Uvědomte si, že přechod z v4 na v6 není jen o adresách. Je to změna spousty dalšího chování.

Coz by se resilo bud tim, ze by se protokol navrhl tak, aby tam vyznamne odchylky v chovani nebyly, nebo by se nedelal preklad, ale delalo by se automaticke tunelovani (6to4 / '4to6').

[pht]

Protoze nema IPv6 konektivitu, ale jen IPv4 konektivitu.

Takže jste vymyslel SIT tunely - které se používají už cca 10 let, od začátku ipv6.

by se nedelal preklad, ale delalo by se automaticke tunelovani (6to4 / '4to6')

To samozřejmě možné je a není to nic proti ničemu, akorát že předtím jste hovořil o komunikaci ipv4 zařízení s ipv6 zařízením, a tam překládat musíte a dostáváte se do problémů.

by se protokol navrhl tak, aby tam vyznamne odchylky v chovani nebyly

To se děje v rámci ipv4 celou dobu, ale už jen změna velikosti adresy, kterou přináší ipv6 je významná odchylka. Pak jsou tam ještě další významné odchylky, a asi mi dáte za pravdu, že než "přecházet" na každou zvlášť, je jednodušší to udělat naráz.

[Ondrej 'SanTiago' Zajicek]

Takže jste vymyslel SIT tunely - které se používají už cca 10 let, od začátku ipv6.

Samozrejme, ze se jedna o SIT tunel. To, co v mem navrhu bylo dulo dulezite, je to, ze takove chovani by bylo defaultni/povinne pro kazdeho IPv6 ready hosta s pouze IPv4 adresou.

akorát že předtím jste hovořil o komunikaci ipv4 zařízení s ipv6 zařízením, a tam překládat musíte

Ne, mohlo by se delat variantu 6to4 tunelu, ktery by vybaloval/zabaloval smerovac na prechodu mezi IPv6-only a IPv4-only siti.

[pht]

To, co v mem navrhu bylo dulo dulezite, je to, ze takove chovani by bylo defaultni/povinne pro kazdeho IPv6 ready hosta s pouze IPv4 adresou.

A proč? Pokud chce někdo mít tuto možnost, může si takový tunel zařídit. S věcmi typu teredo je to dokonce i BFU friendly.

Problém není v tom, že jsou jednotlivé části ipv6 sítě izolované*, ale v tom, že není dost velká motivace k přechodu na v6. Tím, že uděláte tunel povinnej, tuto motivaci nedodáte.

*A vlastně to je často problém jen posledního uzlu, jelikož páteřní infrastruktura obvykle ipv6 zvládá.

Ne, mohlo by se delat variantu 6to4 tunelu, ktery by vybaloval/zabaloval smerovac na prechodu mezi IPv6-only a IPv4-only siti.

To je dost jedno, jestli ten překlad bude dělat směrovač po cestě, nebo cílová stanice. Pořád tam bude a z toho se nevykecáte.

Pokud si myslíte, že ano tak si vemte si příklad: já mám ssh klienta na ipv6 síti a připojuju se na ipv4 ssh server. Dejte mi aspoň v pseudokódu nějakou sekvenci volání API operačního systému, které by proběhlo na obou stranách.

[Ondrej 'SanTiago' Zajicek]

A proč? ... ale v tom, že není dost velká motivace k přechodu na v6. Tím, že uděláte tunel povinnej, tuto motivaci nedodáte.

V ramci cele sady zmen, ktere jsem navrhl v puvodnim prispevku, ano. ISP ma motivaci zaridit funkcni sluzbu pro sve uzivatele. Coz v soucasne dobe znamena provozovat IPv4 sit. To musi udelat vzdy, a pripadny provoz IPv6 mu prakticky nic neprinese. Pri tech zminovanych zmenach v nasazovani IPv6 by funkcni sluzbu pro uzivatele mohl realizovat take provozovanim ciste IPv6 site. Pokud by ISP mel treba nedostatek adres a RIPE by nechtelo / delalo obstrukce s pridelovanim dalsich, mohlo by pro ISP byt vyhodnejsi proste svou sit prepnout na IPv6 a na IPv4 se vykaslat (nebo ji provozovat jen pro stavajici klienty a nove pripojovat na IPv6). V soucasne dobe musi problem s IPv4 vyresit tak jako tak.

To je dost jedno, jestli ten překlad bude dělat směrovač po cestě, nebo cílová stanice. Pořád tam bude a z toho se nevykecáte.

Je rozdil mezi prekladem a tunelovanim.

Dejte mi aspoň v pseudokódu nějakou sekvenci volání API operačního systému, které by proběhlo na obou stranách.

1) ssh klient z DNS zjisti IPv4 adresu serveru. Budto pouzije klasicky IPv4 socket, nebo pouzije IPv6 socket a zavola connect() na adresu 0::IPv4_addr.

2) V obou pripadech OS v pripade, ze nema IPv4 konektivitu, vygeneruje IPv6 paket (otvirajici IPv6 spojeni) na adresu 2002:IPv4_addr::1 a posle ho smerovaci

3) smerovac ho preda dal po IPv6 siti az dorazi na hranici mezi IPv6-only a IPv4-only siti. Tam se na 6to4 brane zabali do 6to4 tunelu (zdrojova adresa brany, cilova podle IPv6 adresy) a posle se po IPv4 siti.

4) paket dorazi do cile (SSH server) a tam uspeje nejaky listen(). Pokud ten listen() byl na IPv6 socket, tak je vracena skutecna zdrojova IPv6 adresa, jinak je vracena IPv4 adresa 6to4 brany.

Takze cele spojeni mezi koncovymi stranami bude IPv6, castecne pojede v 6to4 tunelu, a jedina emulace IPv4 bude pro aplikace, ktere pouzivaji IPv4 sockety. Tomu se aplikace budou moci snadno vyhnout tim, ze budou pouzivat IPv6 sockety.

[pht]

mohlo by pro ISP byt vyhodnejsi proste svou sit prepnout na IPv6 a na IPv4 se vykaslat

To můžete jako ISP udělat i dnes. Vaši klienti budou mít přístup pouze k ipv6 službám. Bude ve Vašem zájmu nastavit si SIT tunel na nějakou v6 páteř, aby to mělo nějaký smysl. Povinnost mít tunel v tomto případě nepomůže vůbec ničemu.

Je rozdil mezi prekladem a tunelovanim.

Ano to je, ale pochopte, že pro zajištění plynulé konektivity mezi v4 a v6 lze použít pouze překlad a to navíc 1:N, už jen proto, že neexistuje 1:1 mapování.

Takze cele spojeni mezi koncovymi stranami bude IPv6, castecne pojede v 6to4 tunelu, a jedina emulace IPv4 bude pro aplikace, ktere pouzivaji IPv4 sockety.

Ano a to je ten kámen úrazu. Těch aplikací je momentálně většina a ta emulace bude fungovat stejně jako se teď "emuluje" přístup z privátních ipv4 rozsahů - NATováním. A máme to tady zpátky, maškaráda, hole punching, přepisování protokolu, nedostupnost v6 služeb z v4 zařízení (podobně jako se "nedostanete" na 192.168.x - nebo máte nějaký nápad?), bezpečnostní problémy, ale tentokrát to vše ještě v horším, protože se nezaměňuje v4 za v4, ale v4 za v6.

Tomu se aplikace budou moci snadno vyhnout tim, ze budou pouzivat IPv6 sockety.

Tady lze říci jen "GOTO 10", neboli jsme na začátku, tuhle situaci řeší už léta SIT sunely.

[Ondrej 'SanTiago' Zajicek]

To můžete jako ISP udělat i dnes. Vaši klienti budou mít přístup pouze k ipv6 službám.

No prave. Tudiz jim prakticky nic nebude fungovat. V mem navrhu by meli pristup i k IPv4 sluzbam, tudiz by jim prakticky vsechno fungovalo. A to je zasadni rozdil.

Ano a to je ten kámen úrazu. Těch aplikací je momentálně většina a ta emulace bude fungovat stejně jako se teď "emuluje" přístup z privátních ipv4 rozsahů - NATováním

Ne, je zde nekolik klicovych faktu:

1) aplikace se strejne prepisovali a prizpusobit aplikace na IPv6 byl ten nejmensi problem pri prechodu na IPv6. Nehlede na to, ze znacna cast aplikaci by si vystacila i s IPv4 sockety (bezne klient/server) a zadne prizpusobeni by nepotrebovaly.

2) U bezneho NATu se preklad provadi na sitovem zarizeni nekde uvnitr site, v mem navrhu se pseudoNAT provadi na koncovem zarizeni na urovni socketoveho rozhrani. Coz cely problem zasadne zjednodusi. A cely se da obejit proste tak, ze aplikace pouzije jine rozhrani (IPv6 socket).

nedostupnost v6 služeb z v4 zařízení

To by podle zminovaneho planu nenastalo. IPv4 zarizeni je bud 'stare' IPv4 zarizeni (bez jakekoliv podpory IPv6), nebo IPv6-ready zarizeni, ktere ma pouze IPv4 konektivitu. V prvni pripad se vyskytuje jen v prvni fazi prechodu, IPv6-only site az v druhe fazi prechodu. Druhy pripad nema problem s navazanim spojeni na IPv6 sluzbu.

[pht]

V mem navrhu by meli pristup i k IPv4 sluzbam, tudiz by jim prakticky vsechno fungovalo. A to je zasadni rozdil.

Tím se celej váš přínos efektivně zmenšuje na fungující spojení v4 a v6. Věřte mi, že se o to pokusilo mnoho chytrých hlav - ale zatím to nějak nejde. Pokud si myslíte, že to můžete změnit, proč to nezkusíte?

aplikace se strejne prepisovali a prizpusobit aplikace na IPv6 byl ten nejmensi problem pri prechodu na IPv6.

Můžete to tvrzení nějak podpořit? Já si myslím, že náročnost přepsání aplikace bude přímo úměrné tomu, jak využívá síťová volání. A nedovolil bych si tvrdit, že všechny patří do kategorie "nejmenší problém".

Nehlede na to, ze znacna cast aplikaci by si vystacila i s IPv4 sockety (bezne klient/server) a zadne prizpusobeni by nepotrebovaly.

V tom případě budou při přístupu z v6 sítě potřebovat "vidět" v4 adresu. Ergo maškaráda.

U bezneho NATu se preklad provadi na sitovem zarizeni nekde uvnitr site, v mem navrhu se pseudoNAT provadi na koncovem zarizeni na urovni socketoveho rozhrani. Coz cely problem zasadne zjednodusi.

V čem se to zjednoduší?

A cely se da obejit proste tak, ze aplikace pouzije jine rozhrani (IPv6 socket).

Ano, my víme, že když se aplikace přepíše na ipv6, tak bude umět ipv6, takže k tomu už není co dodat. Tady ale řešíme problém, kde aplikace použije ipv4 socket.

IPv4 zarizeni je bud 'stare' IPv4 zarizeni (bez jakekoliv podpory IPv6)

Ano, ergo bude mít problém s aktivním připojením na ipv6 stroje, i kdybyste pasivní (odpovědi) řešil nějakým NATem. A jestli zase řeknete, že v tom případě se musí použít ipv6 socket, tak to řeknu učitelce a už s Váma nehraju.

[Ondrej 'SanTiago' Zajicek]

Pokud si myslíte, že to můžete změnit, proč to nezkusíte?

Jak uz jsem psal - ted uz se s tim asi neda nic moc delat. Proto si take nemyslim, ze to mohu zmenit. Tyhle moznosti byly v dobe, kdyz se IPv6 navrhovalo. Dnes uz se z toho muzeme akorat tak poucit pro priste.

V tom případě budou při přístupu z v6 sítě potřebovat "vidět" v4 adresu. Ergo maškaráda.

Ano, coz je ovsem minimalni problem. A pri srovnani se soucasnym stavem (kdy se proste takove aplikace vubec nespoji) je to lepsi stav.

plikace se strejne prepisovali a prizpusobit aplikace na IPv6 byl ten nejmensi problem pri prechodu na IPv6.

Můžete to tvrzení nějak podpořit?

No, statistiky v rukavu nemam, ale staci se podivat, kolik programu IPv6 nepodoporuje (a nelze je vymenit za ekvivalent s podporou IPv6). Osobne takovy neznam. Prechod na IPv6 na strane OS a uzivatelskeho software uspesne probehl jiz pred nejakou dobou. Ale koncove stroje dostupne pres IPv6 jsou stale nekde na 1 %. Prechod na strane koncoveho software problem nebyl, proto ho tento navrh neresil.

U bezneho NATu se preklad provadi na sitovem zarizeni nekde uvnitr site, v mem navrhu se pseudoNAT provadi na koncovem zarizeni na urovni socketoveho rozhrani. Coz cely problem zasadne zjednodusi.

V čem se to zjednoduší?

No hlavni problem s NATem je v tom, ze se o nem nedaji udelat zadne rozumne predpoklady, v zavislosti na implementaci se chova ruzne, detekovat se da jenom experimentalne a neda se z pohledu aplikace rozumne kontrolovat.

Prevazna vetsina problemu s NATy by neexistovala, kdyby se vcas se chovani NATu standardizovalo, vcetne rozsireni ICMP pouzivane pro koordinaci mezi NATem a NATovanym strojem. (Tohle jde snadno zaridit, pokud NAT dela vsechno jde snadno zaridit, pokud je NAT delany na koncovem zarizeni a ne nekde v siti.)

Pak by se aplikace mohly bez problemu snadno prizpusobit existenci NATu a vsechno by fungovalo, jako by ani zadne NATy nebyly. (PTP) Aplikace se NATu prizpusobuji i ted (protoze ty, ktere by to nedelaly, by byly v realnem svete nepouzitelne, ale kvuli vyse zminenym komplikacim je to tezke a nespolehlive.

Tady ale řešíme problém, kde aplikace použije ipv4 socket

Coz je ale problem, ktery v mem puvodnim navrhu nevznikal (pokud tedy budu brat 'IPv6-ready host' jako host, ktery ma nejen IPv6 podporu v OS, ale take IPv6 podporu v tech aplikacich, kde na tom zalezi (tedy typicky v PTP aplikacich)). Protoze tam se IPv6-only site zavadeli az v druhe fazi, kdy uz prevazna vetsina koncovych zarizeni bylo IPv6-ready.

[pht]

Jak uz jsem psal - ted uz se s tim asi neda nic moc delat. Proto si take nemyslim, ze to mohu zmenit. Tyhle moznosti byly v dobe, kdyz se IPv6 navrhovalo.

Pokud plánujete cestu zpět časem, tak raději popoleťte ještě o pár desetiletí dřív a rovnou jim řekněte, ať dají do do ipv4 nejméně 256b adresy.

Žerty stranou, myslím, že bude lepší se soustředit na možnosti co máme teď, než rozvíjet hypotézy coby kdyby.

A pri srovnani se soucasnym stavem (kdy se proste takove aplikace vubec nespoji) je to lepsi stav.

To říkáte Vy, spousta lidí říká opak. Je to otázka nejen přístupu ale i dlouhodobého prospěchu verzus okamžitého prospěchu. Chceme se přechodem zatěžovat teď a pak to mít v suchu, nebo chceme teď udělat hax a pak mít "legacy"?

No, statistiky v rukavu nemam, ale staci se podivat, kolik programu IPv6 nepodoporuje (a nelze je vymenit za ekvivalent s podporou IPv6). Osobne takovy neznam. Prechod na IPv6 na strane OS a uzivatelskeho software uspesne probehl jiz pred nejakou dobou.

Pravděpodobně vidíte jen svobodný software a to ještě jen ten který má Vaše distribuce na PC (takzvaný divoký software). Ten bude z hecu podporovat třeba protokol přenosu na mars a zpět. IT infrastruktura ale stojí na kontrolovaném software, ať už svobodném nebo nesvobodném. Implementace, nasazení a testování ipv6 v tomto prostředí stojí peníze a čas.

Windows vista byly první s zabudovanou podporou ipv6, ale masové rozšíření, respektive přijetí, zaznamenaly až windows 7, které jsou staré asi půl roku. Dodavatelé dalšího SW pravděpodobně ještě s adaptací ani nezačali. Takže opravdu proběhl úspěšně již dávno?

Prechod na strane koncoveho software problem nebyl, proto ho tento navrh neresil.

Ten problém tu ale je. Třeba není nějak technicky náročný, ale je náročný v jiných ohledech, viz výše. Pokud ho ignorujete/neřešíte, stavíte Váš návrh mimo realitu.

Prevazna vetsina problemu s NATy by neexistovala, kdyby se vcas se chovani NATu standardizovalo, vcetne rozsireni ICMP pouzivane pro koordinaci mezi NATem a NATovanym strojem. (Tohle jde snadno zaridit, pokud NAT dela vsechno jde snadno zaridit, pokud je NAT delany na koncovem zarizeni a ne nekde v siti.)

Zato by se objevila jistě jiná množina problémů, včetně bezpečnostních. Aplikace by musely přizpůsobit nějakému NAT-API; zdá se mi, že by to bylo podobné, jako byste mezi třetí a čtvrtou vrstvu stacku dal ještě tři a půltou s vlastníma adresama. Přepsat aplikaci na takové API je stejně náročné, jako ho přepsat na podporu nového protokolu.

Problém NATu (a CIDRu) je přesně ten, že byl myšlen jako "here and now" oprava, zatímco se "v budoucnu" vymyslí něco lepšího. Teď, když jsme v budoucnu, tak místo abychom měli něco lepšího, máme pořád ten blbej NAT a ještě se najdou lidi, kteří by ho "here and now" znásobili do úplně nové dimenze.

[Ondrej 'SanTiago' Zajicek]

Prechod na strane koncoveho software problem nebyl, proto ho tento navrh neresil.

Ten problém tu ale je. Třeba není nějak technicky náročný, ale je náročný v jiných ohledech, viz výše. Pokud ho ignorujete/neřešíte, stavíte Váš návrh mimo realitu.

Muj navrh ignoroval/neresil pouze problem prechodu koncoveho software. Standardni navrh IPv6 ignoruje/neresi problemy prechodu na IPv6 na vsech frontach.

Aplikace by musely přizpůsobit nějakému NAT-API;

Zatimco v soucasne dobe se musi prizpusobovat hromade ad-hoc nespolehlivych obezlicek, ktere NAT castecne obchazi.

[pht]

Muj navrh ignoroval/neresil pouze problem prechodu koncoveho software. Standardni navrh IPv6 ignoruje/neresi problemy prechodu na IPv6 na vsech frontach.

Můžeme zas filozofovat, jestli je lepší neřešit nic, než řešit něco napůl, respektive Vy jste snad i dokonce předpokládal, ale to je jedno. Podstatné je, že Váš i "standardní" návrh mají stejný problém (jeden z mnoha) - nedostatek podpory v software ;)

Zatimco v soucasne dobe se musi prizpusobovat hromade ad-hoc nespolehlivych obezlicek, ktere NAT castecne obchazi.

NAT by měl jít na smetiště dějin. Buďme rádi, pokud se to podaří. Tím, že ho budeme zavádět jako povinnou součást IP, se to nestane.

[tomasgn]

Kdyz vsechny tyto moznosti selhali, tak uz ted zbyva asi jenom zasah ze strany statu. Pokud by vyznamna statni moc (USA ci EU) naridila

proboha, neprivolavej to! vzdyt na co stat nebo EU (a obecne jakykoliv urednik) sahne, to zkurvi. to radeji IPv4 for ever, nez uredne narizene IPv6!

[Grunt]

Pozdě.

[mkoubik]

ale pokud se na to clovek podiva z hlediska 'herne-teoretickeho', tak je mu jasne, proc soucasne nasazeni IPv6 je presne v tom stavu v jakem je.

Jen ať si to zrekapitulujeme: A to je teda proč?

Nashova rovnováha?

[mkoubik]

Aha, pozdě.

[Grunt]

Jak všechno znova? Koncept je už pomalu půl století furt stejný, jen se vyházeli ze starého protokolu jedny zbytečnosti, které nikdo nepoužíval a přidali se jiné, které také nikdo používat nebude. Nebavíme se tady spíš o problémech s kompatibilitou?

[trekker.dk]

Ok, tak jsem to trochu zjednodušil.

[Grunt]

Jsem jediný kdo ten návrh naprosto nechápe? Kam by se ta nula jako měla přidat?

[Vantomas]

chapu to tak, ze ipv4 adresa by misto 32bitu mela treba 33bitu, coz je stejne nesmysl, protoze i tak se zavede nekompatibilni bordel do protokolu a bude potreba vymenit vsechny zarizeni, aby se domluvili s celym internetem.

[Grunt]

Já to zas pochopil tak, že autor chtěl rozšířit rozsah jedné číslice IP adresy z 0 - 255 na 0 - 1000.

[vlastikroot]

Jako v uplinku

[vencour]

Když číslici, tak asi oktet, tedy na 40 bitů.

[Grunt]

A původní pole se dostane na svoji pozici jak? Se tam natlačí heverem? Jediná možnost by bylo dobastlit něco do volitelných položek, ale to už jsme přesně u toho Tak takto teda ne o němž jsem se zmiňoval výše.

[Michal Kubeček]

IMHO je problém v tom, že autor zápisku nechápe IPv4 adresu jako 32-bitové pole v jakési struktuře s pevnou velikostí položek, ale jako řetězec tvaru "11.22.33.44", takže mu připadá naprosto přirozené a triviální takovou adresu přejmenovat na "0.11.22.33.44" a začít přidělovat nové adresy, kde místo té nuly bude něco jiného.

[Grunt]

Též jsem nabyl podobného dojmu, jen jsem se to neodvážil říct nahlas.

[abc]

A třeba v hlavičce paketu tu delší adresu nacpu kam? (http://en.wikipedia.org/wiki/IPv4#Header) Stejně bych to, co mám musel nekompatibilně překopat, tak proč to rovnou nedělaqt pořádně. ;)

[Grunt]

Místo TOSka. Stejně ho nikdo nepoužívá:

Tak studenti, dnes si budeme povídat o IP protokolu. … IP protokol pozůstává ze dvou adres. Zdrojové a cílové. Zdrojová adresa začíná na offsetu 96, pokračuje v poli DS na offset 8, kde ho zabírá jen jednu polovinu (druhá polovina je cílová adresa), protože v roce 2011 nějaký ťulpas neměl nic jiného na práci než vymýšlet cipoviny a protože banda administrátorů tehdejšího internetu byla banda líná a nechtělo se jim vstávat z vyhřáté pohovky a dále pokračuje ve volitelném záhlaví, protože v roce 2018 se na lenosti té bandy nic nezměnilo a ťulpasů co vymýšlejí cipoviny bylo po světě pořád dost. … A jako domácí cvičení si uděláme implementaci tohoto protokolu aby jsme si procvičili práci s takovou adresou – programování(/bastlení) zdar!

[Grunt]

I když předpokládám, že to tak nejspíš také brzo bude, protože je to pár dnů zpět, co jsem viděl v televizi nějakou sci-fi, kde v budoucnosti trackovali adresu 917.154.21.246. a sci-fi zatím nikdy nelhalo.

[Stevko]

Vo filmoch aj serialoch sa vzdy pouziva nejaka nelegalna adresa, aby to nerobilo problemy. V nejakom filme bolo uvedene telefonne cislo na "boha", ktore ale bolo pouzivane, a stastnej majitelke prislusneho cisla pribudli telefonaty.

[vlastikroot]

To bych si nechal líbit

[Kvakor]

Nejspíš se jedná o film Božský Bruce, kde číslo na Boha nezačínalo obvyklým trojčíslím 555, ale skutečným číslem 776-2323, které sice v místě natáčení bylo volné, ale v jiných státech bylo použité, včetně jednoho kosterla v Severní Karolíně, jehož pastor se perverzní shodou okolností jmenoval Bruce .

Pozdější verze filmu, včetně televizní a DVD verze, byly upraveny a číslo v nich je 555-0123.

[Michal Kubeček]

Podle toho "před pár dny" bych tipoval spíš díl CSI Las Vegas vysílaný ve čtvrtek 11.2. Tam jsem si nějaké "adresy" začínající trojciferným číslem s devítkou na začátku také všiml.

[Grunt]

Česnek? Hodně vitamínu D? Takovou paměť obdivuji, protože to asi opravdu byla CSI (jen si nejsem jistý jestli Las Vegas, protože na podobné kopance pod vlivem jsou odborníci v Miami).

[Michal Kubeček]

Pokud CSI, tak určitě Las Vegas, protože to je jediná série, kterou sleduju. New York mne nějak nezaujal a od Miami mne odpudila postava Horatia a jeho nesnášenlivost ke komukoli trochu odlišnému. Ale jak už jsem napsal, vzpomněl jsem si hlavně proto, že jsem si té adresy taky všimnul.

[abc]

Nejen problem lenosti a bastlení ťulpasů, ale stejně by taková změna byla nekompatibilní se vším, co dnes běhá, takže bych to musel přepsat stejně jako to bylo potřeba pro IPv6, kde už to navíc máme hotové. ;)

[Grunt]

Proč by to bylo nekompatibilní? TOS se dnes většinou ignoruje stejně jako nové neznámé volitelné položky. Jen by se teda nedalo dostat z IPv4 na IPv4⁺.

[Grunt]

Jen by se teda nedalo dostat z IPv4 na IPv4⁺.

Aha vlastně. Už mi to došlo. Pak teda ale padají jakékoliv návrhy o rozšiřování IPv4 přes cokoliv. Legacy IPv4 by je prostě neměli jak adresovat.

[vlastikroot]

Je potřeba prosadit ipv6, cokoliv jinýho je prasení A ani tady nepiš, jak bys cpal zbytek IP do TOS, jinak někomu jebne a pude to implementovat ...

[Grunt]

A ani tady nepiš, jak bys cpal zbytek IP do TOS, jinak někomu jebne a pude to implementovat ...

Ono by něco takového ani nemělo smysl. Z koncových zařízení s IP₊ by se sice na zařízení na Legacy IPv4 v pohodě dalo dostat, ale IPv4 klienti by se neměli jak na IPv4₊ doadresovat(nějaké překladové či proxy jednotky nechme stranou). První myšlenka co mě napadla: Tak s servery/housingy a podobnou verbeží na Legacy IP a klienty/ISP a další takovou verbeží na rozšířenou verzi, jenomže hned poté mě trklo, že rozšíření se sice na ty legacy naadresují, ale ti už jim nebudou mít jak data(stránky, z.B.) poslat zpět, protože se jich nedoadresují(jakoukoliv rozšířenou funkci nebo pole ignorují). Takže ať se rozšíří IPv4 jakkoliv, tak se ze staré sítě nebude dostat na tu novou, jen opačně. Jenomže něco takového už tu přeci dávno máme (IPv6 může zpětně na IPv4 adresovat), takže proč znova vymýšlet kolo?

[xkucf03]

Ještě by všichni mohli přejít na TOR a místo IP adres by se používalo něco jako duskgytldkxiuqc6.onion

[mkoubik]

A TOR bude na síťový vrstvě používat co?

[xkucf03]

Klidně zaNATovanou IPv4. Já vím, byla by to obrovská režie a navíc by se spoustě lidem nelíbila ta anonymita.

[pht]

TOR zas tak moc anonymní není.

[Shadow]

Mohl byste to trošku rozvést?

[Vašek Lorenc]

Možná tohle -- Low-Cost Traffic Analysis of Tor (pdf, Steven J. Murdoch, George Danezis). Ale nejsem autorem té původní poznámky, tak netuším, co měl na mysli on.

[pht]

viz např. tato prezentace

[Michal Kubeček]

Kéž by ho ignoranti aspoň ignorovali. Bohužel existují i takoví, kteří natvrdo zahazují pakety, které nemají v nejnižším bitu tohoto pole nulu…

[Grunt]

K takové zrůdnosti je jaký důvod, jiný než stav nepříčetný?

[Michal Kubeček]

Důvodem je nepochopení. V původní specifikaci IP protokolu (RFC 791) i novějším RFC 1349 je tento bit označen jako "must be zero". No a někteří správci routerů a autoři software nepochopili, že to znamená "rezervováno pro budoucí rozšíření, která budou počítat s tím, že kdo jim nerozumí, dá tam nulu" a vyložili si to jako "když tam není nula, tak je to určitě nějaká čertovina". Takže pokud někdo používá ECN (Explicit Congestion Notification, RFC 3168), do sítí za takto nakonfigurovaným routerem se nedostane. Dřív tím trpíval třeba web t-zones, ale tam už to opravili.

[xvasek]

...tak tím se spojily všechny dílky skládačky a už je mi jasné, proč takovou věc dělal D-link ADSL modem. (Původní rébus zněl: "Proč přes něj nefunguje SSH ani když se změní port?", což se dalo na rozumných systémech po troše Googlení řešit netfilterem, který umí ToS vynulovat. Napřed jsem myslel, že je to chyba, a ona to byla vlastnost...)

[Grunt]

Co mi to jen…

[Michal Kubeček]

Mně taky. :-)

[Michal Kubeček]

Trochu víc je k tomu např. tady. Tehdy to byl celkem velký problém, dnes už je takových routerů naštěstí relativně málo. Jinak netfilter umožňuje ECN vypínat i selektivně - vynulováním příslušných bitů v hlavičce pro vybrané pakety.

[vencour]

A jak budete řešit voip bez TOS?

[Grunt]

Stejně jako to řeší 99% internetu dnes. Nijak a zapnu si Skype. (morbidní humor, že?)

[Jendа]

A jak se liší výhody/nevýhody tvého návrhu od výhod/nevýhod IPv6? Zpětně kompatibilní to stejně nebude, tak můžeme rovnou zavést něco lepšího, ne?

[filbar]

Že IPv6 je na rozdíl od IPv4 nepochopitelné.

[Grunt]

V čem jako? Je pravda, že samo to do hlavy nenaleze, ale…

[Luboš Doležel (Doli)]

Je to úplně stejně logické jako IPv4...

[vlastikroot]

Mě přijde nepochopitelná spíš ta IPv4, s koupu NATů, všelijakýma rozsahama naprosto nelogicky pasujícíma do adresy (protože dec reprezentace bytu) maskama podsítě z toho vycházejících ... z IPv6 mi stačí jen připojit a víc chápat nemusim (autokonfigurace), nějaký adresy bran, routovací tabulky ... IPv6 je stejná jak IPv4, jakorát má víc bytů v adrese a z toho vyplývající zbavení se problémů.

[Grunt]

IMHO je spíš problém v tom, že ať je IPv4 se všemi těmi NATy a maškarádami nelogické, tak už se prostě lidi naučili kam kliknout a nic nového se jim učit nechce. Něco jako když by se měl posadit klasický jednoruký Widlák za jiné GUI. Přitom pro čerstvé maso může být pochopení IPv6 klidně ještě jednodušší.

[Luk]

Na IPv6 jsou složitější k pochopení jen ty různé berličky, které umožňují obcházet to, že zásadní část Internetu zatím nativní IPv6 neumí. Z pohledu tvůrce aplikace (ať už klientské nebo serverové) je to v podstatě úplně stejné pro oba protokoly, pro administrátora taktéž. Jediný problém by nastal tam, kde by se přímo používaly číselné adresy, protože pamatovat si adresy IPv6 je poněkud těžší.

[Grunt]

Jediný problém by nastal tam, kde by se přímo používaly číselné adresy, protože pamatovat si adresy IPv6 je poněkud těžší.

Konečně důvod si pořádně nastavit Binda a nakoupit si papír a tužku.

[Luk]

nakoupit si papír a tužku

[pht]

pamatovat si adresy IPv6 je poněkud těžší.

Hlavně když se neustále mění.

[pavlix]

Pokud si jejich neustálé měnění zapnete (někdy je fajn nezamlčet klíčovou informaci... a vtip označit smajlíkem místo samotné tečky).

[Ivan]

Ono to neni tezke jenom pro pro adminy ale i pro programatory, kteri programuji routery. Jeste si pamatuju problemy se zavadenim multicastu. Nejaky zasr* super-router od Nortelu mel umet routovat multicast v ASICu, ale stacilo pridat nejaky bit do nejake hlavicky a vsechno slo pres CPU( PPC 400MHz) a do desti minut se router restartoval. A podobne je u IPv6 a Cisca. Nejake krabice je garantovano ze zvladne x milionu tiku za sekundu. Pro vhodnoceni routovaci tabulky IPv4 potrebuje router 4 tiky a pro IPv6 rekneme 6. Takze s nasazenim IPv6 do provozu ztratite nekolik procent z propustnosti. Ale opravdu verite, ze tomu tak presne bude? Kdyz to vlastne jeste zadny velky ISP nenasadil a neotestoval? Pokud na jednom routeru kombinujete vice funkci najednou tak je tezke najit spravnou verzi IOSu i bez IPv6. Podle me proste nikdo neveri ze se da nasazeni IPv6 otestovat "nanecisto" a nikdo si nechce rozvrtat stabilni produkcni sit kvuli experimentum s novym protokolem.

[pavlix]

Nebudu autorovi postu tady jednotlivě vysvětlovat, proč je to co napsal nesmysl... to už tu bylo několikrát.

Základní věcí je to, že je potřeba zvětšit adresní prostor. A při té příležitosti se hodí vyčistit, zjednodušit a vyladit protokol.

Při hrabání se RFCčkama člověk zjistí, že počet obezliček se při přechodu rapidně snižuje. Jako příklad za všechny, IPv6 už se *oficialne* vzdalo počítání TTL po vteřinách zaokrouhlených nahoru.

Kdo nemá čas na čtení RFC, můžete se těšit na nějaký ten článeček, co se zatím připravuje :).

[trekker.dk]

IPv6 už se *oficialne* vzdalo počítání TTL po vteřinách zaokrouhlených nahoru.

TTL má u IPv4 něco společného s časem?

[Michal Kubeček]

Oficiálně ano, viz RFC 791. Ostatně, ta zkratka znamená Time To Live… V praxi ale nejspíš neexistuje implementace IP protokolu, která by s TTL nakládala přesně podle této specifikace.

[pavlix]

Tos nevěděl, co :). Je to čas ve vteřinách, ale po krocích zaokrouhlovaný nahoru. Implementace předpokládají, že to do tý vteřiny stihnou, tak inkrementujou po jedný, takže v podstatě nic neporušujou (pokud to teda stihnou).

[trekker.dk]

To teda ne. Teda že je to Time To Live, to jsem věděl, ale že je to myšleno jako skutečný čas, to mě fakt nenapadlo.

[pht]

Původně měl router snižovat podle skutečně stráveného času, ale nejméně o 1, v praxi ale snižuje každý o 1. Díky tomu funguje traceroute.

[pavlix]

Díky tomu funguje traceroute.

Někdy.

[Michal Kubeček]

Původní idea byla, že TTL má zajistit dvě věci: za prvé že po určité době od odeslání (kterou si navíc může odesílatel zvolit) už paket nikde nebude bloudit, ale bude buď doručen nebo odeslán; za druhé že když někde z nějakého důvodu vznikne routovací smyčka, nebudou po ní pakety kroužit do nekonečna a časem ji nezahltí úplně (proto je tam ten požadavek "vždy aspoň o jednu"). Časem se ukázalo, že přístup "vždy právě o jednu" stačí k zajištění druhého požadavku a že ten první není tak důležitý, jak se původně myslelo.

Mimochodem, tak původní specifikace není navržena moc prakticky, protože místo striktního požadavku zaokrouhlení nahoru je tam pouze "vždy aspoň o jednu", takže je korektní třeba 1.49 s zaokrouhlit na jednu. Tím pádem vlastně ani o horní odhad nejde. A samozřejmě by se při striktním výkladu podle RFC 791 stala praktická realizace RFC 1149 poněkud problematickou. :-)

[pavlix]

Koukám, že jsem si to ještě trochu zjednodušil :).