Proč je IPv6 blbost (diskuse)

[thingie]

V téhle zemi katastrofálně selhalo základní školství.

Vidíme to, když se diskutuje o jakýchkoliv základních znalostech, ať už z oblasti matematiky, přírodních věd, nebo i společenských. Lidi jsou absolutně mimo. 2^128 není jenom tak o trochu víc než 2^32. Je to číslo, které je někde naprosto dokonale jinde… Jenže škola nedala lidem aspoň tu základní ideu. Jak se to nedá snadno srovnat lineárně (vždyť je to jenom čtyřikrát víc), tak konec.

No. A co se týče těch VPN a tak, tohle ipv6 poměrně slušně řeší taky, takže i tady vidím nedostatky, i když to asi na ZŠ úplně nepatří.

[snajpa]

O kvalitě školství se dohadovat nebudu, to máš pravdu.

Jestli tím chceš naznačit, že nepoznám velikost rozdílu mezi 2^32 a 2^128, tak bych řekl, že jsi mimo. Stejně jako jsi úplně mimo, protože jsi nepochopil základní myšlenku toho, co píšu. Já říkám, že každej konečnej adresní prostor (pokud není maximální velikost adresy někde v terabajtech) bude za nějakou dobu limitující.

Nebo mi s určitostí dokážeš říct, že rychlost obsazování volných IPv6 zůstane +- stejná, jako je teď ta s IPv4?

[hms]

The number of atoms in the entire observable universe is estimated to be within the range of 10^78 to 10^82.

[Josef Kufner]

Pro srovnání: 2^128 je přibližně 10^38.

[thingie]

No, já nevím, ale povedlo se ti akorát ukázat, že mimo nejsem. Víš kolik adres by měla terabajty dlouhá adresa? Dokážeš takové omezení srovnat s konečnou velikostí vesmíru?

No, a pak je tu samozřejmě inženýrská část. Jenom to prodloužení adresy na ten zdánlivě směšný čtyřnásobek přináší četné problémy (všeho je najednou víc a je to větší, a ne jen tak, ale mnohem větší), máš aspoň představou jaké úplně nové třídy problémů by přinesla libovolně dlouhá adresa?

[snajpa]

Dokážeš takové omezení srovnat s konečnou velikostí vesmíru?

A pozor, on už to někdo dokázal?

jaké úplně nové třídy problémů by přinesla libovolně dlouhá adresa?

Já v tom docela problém nevidím. Ty jo? Kde?

[thingie]

Já se ani neodvažuju hádat jaké všechny problémy by to nakonec přineslo (Konečně, když je to IPv6 tak triviální rozšíření akorát, proč je takový problém ho všude zavést…)

[snajpa]

Protože není kompatibilní s IPv4.

[SPM]

LOL! Doporučuju přestat v užívání omamných látek :)

[jiri.one]

Nechapu proc by mel nekdo prestat s uzivanim omamnych latek jen proto, ze vyjadruje svuj vlastni nazor a zamysli se nad urcitou problematikou nebo tematem. Naopak si myslim, ze pokud snajpu k jeho nazorum a flameovym vystrelkum vedly omamne latky, tak by nebylo od veci si nejakou takovou latku vzit take. Pak bude takovych blogu mnohem "houšť" a bude vetsi "prča" :). A ja bych teto prilezitosti rad vyuzil a chci se zeptat: snajpo, co to beres za "matroš"? A bud prosim konkretnejsi, chci stejny model ).

[snajpa]

Aktuálně akorát kofein.

[SPM]

Představa vytvoření nového protokolu s dynamickou velikostí adresy a zároveň kompatibilního s IPv4, tj aby to všude bez problémů hned fungovalo mi přijde hodně nereálná... aneb proč teda na to někdo nepřišel, když by to bylo tak super? :)

[Ondrej 'SanTiago' Zajicek]

Me prijde realna - stacilo by do IPv4 pridat rozsirujici polozku do hlavicky, ktera by obsahovala posloupnost IPv4 adres a v paketu by se pri pruchodu 'hranicnim' routerem prohazovali se skutecnou zdrojovou adresou. Obdobne pro cilovou adresu (tam by se adresy jen doplnovaly). Hranicni routery by pak oddelovaly 'nezavisle svety' IPv4 rozsahu. Aplikace by pak mohla pouzivala socket, ktery by celou tu posloupnost IP adres reprezentoval jako jednu dlouhou adresu. Tim by se zajistila plna end-to-end konektivita.

Tohle reseni by bylo vice-mene kompatibilni s IPv4 (stacilo by mit zmeny v koncovem software a zmeny na hranicnich routerech, ty by navic slo vymenovat prubezne). Akorat by to mozna narazilo na limit, ktery je v IPv4 pro velikost rozsirujicich polozek v hlavicce.

[SPM]

Pořád tam nevidim tu velkou výhodu oproti současné IPv6 - pořád musíš předělat ten software a povyměňovat routovací hardware - jinak ti to obousměrně neprojde.

[Ondrej 'SanTiago' Zajicek]

Predelat koncovy software neni problem - to je tu uz aspon 5 let pripravene a IPv6 porad nikde.

Tohle ma vyhodu v tom, ze jedine, co je treba menit, jsou hranicni routery a i ty staci menit postupne. Pokud napriklad nejaky ISP by takovy router nasadil a skryl za nej sve uzivatele, tak tito uzivatele mohou obousmerne komunikovat s kazdym, kdo ma aktualizovany koncovy software, bez ohledu na to, zda jeho ISP take aktualizoval hranicni router.

[SPM]

No to bych řek, že je ten problém největší, pač tohle jsou typicky ty hodně drahý věci, který se musí koupit nový a musí to na nich být odladěné (což i u IPv6 se dnes ještě na lecčem zdá jako problém). A ve chvíli, kdy se povyměňují hraniční routery, tak už je to vlastně jedno, jsme tam kde s IPv6. To že u IPv6 se musí ještě "vyměnit" ty krabičky typu ADSL router u zákazníků je víceméně jedno - stejně to z většiny jsou softwarový bazmeky s linuxem, takže stačí vyměnit sw na nich. Vyměňování hraničních routerů postupně nějak nechápu - buď je na to připraven a funguje to anebo není a pak je pro něj ten nový zbytek nedosažitelný.

[Ondrej 'SanTiago' Zajicek]

Vyměňování hraničních routerů postupně nějak nechápu - buď je na to připraven a funguje to anebo není a pak je pro něj ten nový zbytek nedosažitelný.

To je prave ten klicovy rozdil. V tomto schematu je mozne provadet vymenu hranicnich router postupne (protoze takove pakety se pro stare sitove prvky tvari jako normalni IPv4 pakety) a pritom funguje end-to-end konektivita (pokud koncove stroje jsou updatovane).

[SPM]

Dobře, řekněme, že starý router když zvenku dostane paket, tak ho doručí. Ale když mu aktualizované PC zevnitř odešle něco, co má destination už jako novou adresu, tak s ní nebude umět pracovat... resp. pošle to někam úplně jinam, když veme IPv4 adresu a nepřičte k ní ten přidanej zbytek...

[Ondrej 'SanTiago' Zajicek]

Jiste, posle to na tu cast nove adresy, ktera je ve stare adrese. Coz bude adresa noveho hranicniho routeru (pod ktery cil spada), tam ji stara sit doruci a novy hranicni router provede rosadu s adresama a paket preposle smerem k cili.

[SPM]

Ale tohle přesně funguje do chvíle, kdy počet ISP zůstane konstantní... Ve chvíli, kdy vznikne nový ISP, který už nemůže dostat adresu z původních 2^32, tak má jaksi smůlu, protože ho ty staré routery nemají jak najít... Ano; většina dnešních IPv4 adres bude zbytečná a půjdou použít jinak, ale dost pochybuju o tom, že se zákazníci přečíslujou do nových rozsahů a staré se vrátí...

[Ondrej 'SanTiago' Zajicek]

To je pravda, ale takovy system by umoznil (na urovni RIR) vcas zablokovat registraci novych IP tem ISP, ktere uz nejake adresy maji, takze by jich zbylo dost pro nove ISP.

[pht]

Pokud napriklad nejaky ISP by takovy router nasadil a skryl za nej sve uzivatele, tak tito uzivatele mohou obousmerne komunikovat s kazdym, kdo ma aktualizovany koncovy software, bez ohledu na to, zda jeho ISP take aktualizoval hranicni router.

Takhle fungujou ip in ip tunely, speciálně ipv6 in ipv4...

[Ondrej 'SanTiago' Zajicek]

Ano, a kdyby IPv6 bylo navrhnuto jen trochu jinak, tak by take bylo podobne jednoduche ho zavest.

[zde]

> nejaky ISP by takovy router nasadil a skryl za nej sve uzivatele, tak tito uzivatele mohou obousmerne komunikovat s kazdym, kdo ma aktualizovany koncovy software, bez ohledu na to, zda jeho ISP take aktualizoval hranicni router.

A kdyby IPv4 bylo navrhnuto jen o trosicku chytreji, a odchozi packety by kopirovaly IP options ze SYN packetu, tak by se (alespon na strane serveru) nic aktualizovat nemuselo.

[snajpa]

Tak teď nevím, kdo z nás dvou fetuje víc. Kde jsem něco takovýho řekl?

[SPM]

No řekl si že zavádění IPv6 je problémové kvůli tomu, že není kompatibilní s IPv4. Odvodil jsem si tedy, že aby se ti to líbilo, tak potřebuješ něco s neomezenou velikostí adresy a kompatibilní s IPv4.

[Grunt]

Hej, ale to už si nedělej srandu ani ze mě.

[ja]

Pre nematematikov - IPv6 rozsah oproti IPv4 je vacsi skoro:

80 000 000 000 000 000 000 000 000 000 NASOBNE

IPv4 = cca 4,3 x 10⁹

IPv6 = cca 3,4 x 10³⁸

[vencour]

A navíc vzhledem k navrhované stabilnější stuktuře ip paketu by mělo být rychlejší onen paket procpat dál.

[snajpa]

A tím dokazuješ co?

[Jendа]

Jenže každému joudovi se přiděluje /64, v případě, že by mohl mít vlastní síť, tak /48 a ISP /32. A čtyři miliardy ISP už snad není tak nepředstavitelně vysoké číslo.

[thingie]

Já bych řekl, že i docela je.

[Jendа]

Podobně nepředstavitelné jako 4 miliardy počítačů v 60./70. letech?

[thingie]

Nojo. Představit se dá leccos. Ale počítat s takovým scénářem je asi jako stavět v Praze ochranné zdi proti třísetmetrové tsunami. Opět, představit si to dokážu, ale… i kdyby se to stalo, asi bych měl jiné problémy.

[pavlix]

Když mi poslal ilfirin odkaz, čekal jsem nějakou aspoň trochu seriózní polemiku, vzhledem k tomu, že tě (autora) už trochu znám.

Takže... vyjdu z několika věcí, co píšeš:

1) zřejmě ti nevyhovuje IPv4, protože má příliš malý adresní rozsah

2) nevyhovuje ti IPv6 z totožného důvodu... dobře, dalo by se polemizovat o tom, jestli stačí mít řádově biliony registrovaných zákazníků na zemi, která má pouze miliardy lidí (intergalaktické sítě nechme stranou)... pro každého řádově desetitisíce vlastních podsítí... a v nich prakticky neomezené množství počítačů (více než je možné v LAN udržovat, abych vše podložil jasným argumentem)

3) dokonce ti nevyhovuje koncept konečné adresy obecně, protože chceš řešení, které je libovolně škálovatelné... to je moc hezké, ale za jakou cenu? a proč ti nestačí řešení škálovatelné nade všechna očekávání

Z toho jasně vyplývá, že jediné tobě vyhovující řešení je řešení s nekonečným adresovým prostorem. Tak zkus najít ostatní lidi, kteří by taky dali přednost adresám proměnné délky, založte si na to nějakou mezinárodní organizaci... a dostaňte to do konkurenceschopné podoby....

Ale já osobně se nepřipojím, mě stačí prostor velikosti 2^128 bohatě, s prostorem 2^32 spokojený nejsem.

[Michal Kubeček]

Ono se stačí podívat na to, jak dlouho už trvá přechod na IPv6 (a jak dlouho ještě trvat bude). Nemohu si pomoci, ale mám z toho neodbytný pocit, že kdyby se místo IPv6 mělo zavádět něco tak komplikovaného, jako navrhuje kolega, pak by dokončení přechodu byl úkol pro naše vnuky. V lepším případě…

[Aleš Janda]

Přesně tak. Říci o něčem, že když se to zvětší z 2^32 na 2^128, že je to málo, to chce notnou dávku otrlosti. Bohatě by stačilo 2^64 adres, minimálně pro dalších 100 nebo 200 let.

Zrovna jsem si spočítal, kolik těch IPv6 adres vlastně je: Kdyby existoval miniaturní router, který by zabíral plochu 1x1 mikrometr, a těmito routery by se pokryla celá plocha Země, tak by bylo dost IPv6 adres na to, aby každý z routerů simuloval 150 celých dnešních Internetů.

Takže pokud nechcete IPv6 adresu přidělit každému atomu ve vesmíru, je jich opravdu dostatek

[=^..^= AmigaPower®]

. .. ...oops!

[pht]

Bohužel u IPv6 k tomu existuje dost silné protitvrzení. Adresní prostor je neuvěřitelně děravý. Jedna celá síť zabere prefix /64* a zákazníci u kterých se předpokládá vnitřní struktura, mají rovnou /48. Představte si, že každou IPv4 namapujete na jeden /48 blok; zjistíte, že můžete rozdat jen cca 60000x více bloků než teď. Samozřejmě tento předpoklad je trochu zcestný, ale na druhou stranu bude dost velká neefektivita i v prostoru alokovaném pro ISP a navíc velké části IPv6 prostoru jsou rezervovány pro další využití. Takže ten rozdíl tam je, ale není zdaleka tak astronomický jak by se předpokládalo a srovnání s nějakým počtem atomů je úplně mimo.

(*) rationale vedoucí k tomuto uspořádání jsem úplně nepochopil

[Michal Kubeček]

navíc velké části IPv6 prostoru jsou rezervovány pro další využití

Jaké? Co si vzpomínám, je to jeden /8 (méně než půl procenta) a dva (teď už vlastně jen jeden) /10 (necelé promile). Pak je samozřejmě rezervováno všechno mimo 2000::/3, ale to jen v duchu "zatím do toho nebudem sahat, necháme si to na později".

[pht]

Pak je samozřejmě rezervováno všechno mimo 2000::/3

No, dyť jo.

[thingie]

„zatím do toho nebudem sahat, necháme si to na později“

To mi přijde jako relativně dobrý popis „rezervace pro další využití“

[Michal Kubeček]

Bohatě by stačilo 2^64 adres, minimálně pro dalších 100 nebo 200 let.

Ono jich vzhledem k tomu, že nejmenší delegovatelný rozsah je /64, de facto zhruba těch 2^64 (krát malá multiplikativní konstanta) je.

[Ondrej 'SanTiago' Zajicek]

Hmm, vetsina kritiky, kterou jsem na IPv6 cetl, byla myslena v opacnem duchu - misto aby jenom zvetsili rozsah adres a udelali par drobnych oprav (jako treba tu upravu kontrolnich souctu), tak se na to zacala nabalovat spousta zmen a featur [1], ktere v podstate nebyly potreba.

[1] http://en.wikipedia.org/wiki/Second-system_effect

[[exa]]

naprosto souhlasim a diky za odkaz na clanek.

Jeste pridam trochu k puvodnimu prispevku do diskuze o "radikalnim" rozdilu mezi 32bity a 128 bity: Jasne ze kdyz to clovek vezme exponencialne, tak toho je enormni kupa. Nicmene plytvani ktere zname ze zacatku IPv4 ma podobne nasledky (a oblibeny "hod prefixem" ma dopad opravdu exponencialni). Nejsem ipv6 expert, ale uz moje drobne pozorovani poukazuje na zajimavy smer vyvoje:

- ze 128 bitu se zcela zbytecne zahazuje prvnich 16 bit na oznaceni "typu site" (2001:.. a pod), zbyva nam 112bit.

- adresa se obcas bezne postfixuje MAC adresou pocitace (48bit), zbyva nam 64bit. To je jednoduse odstranitelne, ale predpokladam nejhorsi prubeh.

- bezne se prideluji /64 rozsahy jednotlivcum, na coz sice ether-postfix nema vliv, ale spolu se 128 bity zbyva jen 48bit adresy

- vetsi organizace dostavaji /48 rozsahy, kdyz od toho odejmeme prefix typu site, jsme (uz!) u /32 problemu ipv4.

- dukazy dalsiho plytvani neznam, ale jak tak pozoruju ipv6 nadsence, myslim ze se v pohode najde dalsi.

[Ondrej 'SanTiago' Zajicek]

To plytvani neni zas tak enormni. Urcite se nezahacuje prvnich 16 bitu, prevazna cast z nich bude slouzit jako soucast adresy. Kvuli pevnemu /64 pro site je vcelku jedno, kolik kdo bude mit zarizeni (vypinacu svetel s IP adresou) adres a staci pocitat kolik subjektu bude chtit sit provozovat. Bezna domacnost ci mala firma si vystaci s /64 a vetsi firma dostane /48. Takze stale je o dost radu vic takovych prefixu nez vsech domacnosti a firem.

[pht]

Bezna domacnost ci mala firma si vystaci s /64

Ne, ten prostor by se správně už neměl dělit, a nemůžeme předpokládat, že do budoucna bude stále větší počet zařízení pořád na jedné L2 síti.

[thingie]

Proč bychom nemohli? Jsou lidé, kteří už dneska staví i relativně rozsáhlé L2 sítě. A IP router mezi ledničkou a PC? Nemyslím.

[Ondrej 'SanTiago' Zajicek]

nemůžeme předpokládat, že do budoucna bude stále větší počet zařízení pořád na jedné L2 síti.

Proc ne? Da se cekat, ze nove sitove technologie pujde 'sbridgovat' k ethernetu (kdyz ne primo, tak aspon pomoci nejakych triku). A pokud by nekomu nestacilo STP, je mozne prijit s OSPF-like protokolem pro bridge.

[petr_p]

Triků? Asi jako WiFi a Ethernet? Ne děkuji.

Navíc praxe ukazuje, že mnohá jednoúčelová zařízení lze zabezpečit jedině přes filtrující router. Vysněme si domácnost, kde poskytovatel předá domácnosti ethernetovou přípojku. Domácnost si pořídí televizi, mobilní telefon (VoIP), pracovní stanici, datové úložiště, tiskárnu. Tohle všechno nastrká do switche, přijde návštěva s mobilem a bude si chtít zavolat nebo se nám vloupat do televize? Fakt bych rád viděl oddělené směrování. Nebo myslíte, že všechna zařízení budou umět IPsec?

[thingie]

Nevím, je pravda, že moc těhle krámů jsem neviděl, ale prakticky mi spíš přijde, že oddělit je do jiné sítě routerem je zpravidla znamená oddělit tak, že se k nim nedostane ani ten kdo by měl, a jsou k ničemu A konečně. Kde je tam ten problém to na L2 zabezpečit. Že se to nedělá…

[Ondrej 'SanTiago' Zajicek]

Co se tyce bezpecnosti, tak tady si myslim, ze jedine rozumne reseni je mit bezpecnost na aplikacni vrstve. Napr. u toho datoveho uloziste prihlaseni a pristupova prava (SFTP).

[pht]

To bude k ničemu, pokud útočník využije buffer overflow v přihlašovacím mechanizmu.

[pht]

Pro začátek je to neefektivní a nebezpečné.

Da se cekat, ze nove sitove technologie pujde 'sbridgovat' k ethernetu (kdyz ne primo, tak aspon pomoci nejakych triku).

S tímhle postojem se můžete rovnou na celé IP (hlavně na to 'I') vykašlat a prohlásit celý svět za jeden velký ethernet segment. MAC adresy jsou umikátní a 64b tak co.

[Ondrej 'SanTiago' Zajicek]

Pro začátek je to neefektivní

Proc by to melo byt nejak zasadne neefektivni? 'routovani' MAC adres se nejak zasadne principielne nelisi od routovani IP adres. Akorat IP adresy jsou hierarchicke a daji se agregovat, zatimco MAC adresy ne. Pokud mas sit do velikosti kdy agregovat neni treba, tak je to OK.

Pokud je neco na tom neefektivni, tak akorat distribuce broadcastu/multicastu tam, kam je netreba.

A ten limit, od ktere velikosti je treba nasazovat agregaci, se v case vyviji a roste rychleji, nez pocet zarizeni v ethernetovych segmentech. :–)

S tímhle postojem se můžete rovnou na celé IP (hlavně na to 'I') vykašlat a prohlásit celý svět za jeden velký ethernet segment.

Ten uz je tak veliky, ze agregace je nezbytna. Dalsi hledisko je take politicke - odlisne routovani v ramci AS a mezi ruznymi AS.

[pht]

'routovani' MAC adres se nejak zasadne principielne nelisi od routovani IP adres.

Až na to, že to tam bylo doděláno později, a spousta funkcionality chybí.

Routovat můžete i individuální IP, pokud chcete.

Pokud je neco na tom neefektivni, tak akorat distribuce broadcastu/multicastu tam, kam je netreba.

Ano a nezapomeňte že broadcast domény by měly být zachovány. Tím si omezujete možnosti filtrování.

[Michal Kubeček]

vím, že jsem to teď hodně zjednodušil, ale ostatní novinky IPv6 jsou "nepodstatné"

…

Další věc, která mě na protokolech IP obecně vytáčí, je svázanost adres s fyzickým místem na světě.

Takže podpora mobilních adres je nepodstatná, ale problém, který se snaží řešit, je naprosto zásadní?

[snajpa]

Typický příklad totálního překroucení. Vezmu dvě věty z celku, které se mi hodí, dám je k sobě, jak se mi hodí, a hned to vyzní líp!

Ostatní novinky IPv6 jsou k ničemu, když se zopakujou hlavní chyby v4

[Ondrej 'SanTiago' Zajicek]

Nechápu. Dynamická velikost adresy a dynamické (opravdu dynamické, BGP není) routování nikomu nic neříká?

Co se tyce dynamicke velikosti adresy, to je IMHO naprosta zbytecnost, zvlaste pak s ohledem na implementacni komplikace, ktere by to prineslo. 128 bitu je, samo o sobe, dost.

Dynamicke routovani bez agregace v siti velikosti Internetu je utopie (alespon bez dalsich zasadnich zmen v systemu adresace). Pro orientaci par dat - soucasne globalni routovaci tabulky maji cca 300k zaznamu a zabiraji cca 30 MB (v BIRDovi, v Quazze pres 100 MB, jestli si dobre pamatuju). Tezko rict, kolik by to bylo bez agregace, ale myslim, ze tisickrat tolik je podhodnoceny odhad.

A uz v soucasne dobe si ISP stezuji na jejich velikost (protoze musi platit drahe upgrady hranicnich routeru).

Nehlede na to, ze to v podstate neni potreba - problemy, ktere to resi, se daji mnohem jednoduseji resit jinymi zpusoby pri zachovani agregace.

[vencour]

Děkuju za tuten zápisek. Jak pozoruju, nic lepšího k mání není a v dohledné době nebude (IPv6.

Nemáte ponětí, jak jsou na tom různé komerční servery, IBM, SUN, HP apod., jak dlouho (zda vůbec) jsou už pro IPv6 ready?

Čili když už sféra desktopů a domácností je jakž takž technicky připravená, jak to vypadá na druhé straně?

[xavier]

Někde jsem viděl porovnání, že IPv6 nabízí víc adres pro každou planetu ve vesmíru než IPv4 pro Zemi. Skoro to vypadá jakoby autoři počítali s připojením mimozemských civilizací :).

I kdyby ty adresy někdy došli(myslím, že ne nebo se toho aspoň nedožiju), tak se prostě zavede další protokol. Řekl bych, že je lepší jednodušší protokol, který je teoreticky nedostačující, než nějaká složitá věc, která třeba vůbec nebude potřeba.

[Filip]

Hlavně kdyby se každá IPv6 adresa přidělila zařízení velikosti mobilu a ty zařízení se položily na sebe, tak se gravitačně zhroutí v černou díru.

Také nevidím potřebu pro dynamickou délku IP adresy.

[Josef Kufner]

Ta myšlenka o proměnné délce adresy je celkem hezká. V podstatě by to umožnilo podobnou zpětnou kompatibilitu jako UTF8 vs. ASCII.

Problém je v tom, že tahle zpětná kompatibilita je v Internetu úplně na nic (i staří se musí umět připojit k novým) a ve vývoji jen na obtíž.

[vencour]

Výkon potřebuje pravidelnost, ne proměnlivou velikost paketu a částí. Sekat cvičky a ne se s každym paketem mazat.

[snajpa]

Tam, kde potřebuješ výkon (páteř), nasadíš ASIC, případně do serverů není problém dělat chipy s off-load podporou (jako se to děje oboje dneska u IP).

[vencour]

Proto píšu o tom, že IPv6 má výhodu oproti IPv4 ve zpracování, kvůli ASICům.

[Grunt]

Proč je IPv6 blbost?

Protože si

[Grunt]

Ne, a teď vážně. Je víc než možné, že na světě ještě ani není tolik zařízení co by se vlezlo do rozsahu IPv4. Pokud si už ovšem někdy navrhoval síť, tak už asi víš jak je to se segmentovaním subsítí. Maska může pojmout mocninu dvou prvků a od toho si musíš odečíst adresu sítě a broadcast. Takže ti u každého segmentu vypadnou dvě krajní podsítě. Ono se sice může zdát, že Céčkový rozsah o 256 uzlech je třeba pro malou sítěčku s pár uzly naprosto dostačující, jenomže jakmile začneš takto segmentovat a dělat si v stíti pořádek, tak zjistíš, že i tento téměř nevyčerpatelný prostor se začíná smrskávat víc a víc a i když nemáš třeba ani polovinu zařízení co by se do toho rozsahu vlezla, tak začínají problémy pokud máš síť moc naporcovanou. A teď si vem tak obří síť jako internet. Multicasty, vyhrazené adresy, routery (kolik procent ze všech adres můžou zabírat routery které ho udržují v chodu?), nutnost rozsegmentovat svět kvůli BPG tabulkám a snazší administraci, atd. Je dost možné, že kdyby se segmenty dnešního internetu správně uspořádaly (každý by měl takový rozsah, který opravdu potřebuje), tak je víc než možné, že počet adres z IPv4 by stačil bohatě. Jenomže je to podobné jako když se alokuje paměť v počítači a ta začíná docházet. Operační systém se pak pouští do defragmentace a začínají se dít všelijaké psí kusy. A nebo problém počtu hrobníků co kope hrob. S IP adresami to nevidím jinak. Čim větší prostor na kterém je možno operovat, tím lépe. Je pravda že s rozumným návrhem přidělování adres by se mělo počítat už od počátku vzniku Internetu číslo 6, s tím souhlasím. Ale že IPv6 potřeba není, tak s tím už ne. Je potřeba už jenom protože je to upgrade a inovace samotného protokolu, který už je jinak víc než 40 let starý. Je to jako s přechodem na x86_64 z i386. Nepřechází se kvůli nějakým blbým 64-bitům, ale prostě protože je to nová architektura, která čistí nějaký bordel a nedostatky návrhu předchozího a přidává některé pěkné funkce, které se do návrhu protokolu předchozího nevešly. IMHO časem zase bude potřeba provést upgrade z IPv6 na něco vyššího a třeba ani ne z důvodu, že nebude stačit počet adres, ale jednoduše protože bude koncepčně zastaralý. Třeba to nebude zítra, ale za 100 let, ale takto se tomu bránit je blbost. Toť můj pohled na věc.

Dynamická velikost adresy a dynamické (opravdu dynamické, BGP není) routování nikomu nic neříká?

Dříve, na telefoniích linkách(snad Frame Relay?) se používaly tzv. virtuální okruhy. Když bylo potřeby vysílat do nějaké cílové stanice, tak se nejdříve pomocí signalizace sestavil mezi nody nějaký okruh, ten dostal číslo a jednotlivé pakety pak nesly jako identifikaci právě číslo tohoto okruhu. Když přenos skončil, tak se zase okruh zrecykloval a jeho číslo dostal třeba někdo jiný. Takže strach, že by se jednotlivé i vymakanější techniky neznaly si zas dělat nemusíš. Pokud vím, tak jednoznačná IP adresa jako identifikátor byla v DARPě vybrána jednak právě kvůli té odolnosti(což z dnešní povahou komerčního internetu většinou padlo…kam až vede víc jak jedna linka, když nepočítám samotné jádro internetu) a jednak protože bylo potřeba kvůli tehdejším routerům, což byly většinou nějaké jednoduché a pomalé čipy, co nejvíce zjednodušit právě algoritmus směřování (což s dnešními super-výkonnými routery pomalu v podobě špičkových počítačů padlo také – i když nějaká dynamická adresa nebo jiná potvora by asi byla i na dnešní mašiny časově furt dost náročná).

[Grunt]

Úplně naspodu něco málo k těm okruhům.

[Jendа]

ale prostě protože je to nová architektura, která čistí nějaký bordel a nedostatky návrhu předchozího

Řekl bych, že zrovna ve zmiňovaném případě, kdy se drží zpětná kompatibilita s 8086, nejde o čištění moc mluvit.

[Grunt]

Pokrok v mezích zákona je furt lepší než nic. Ale jinak mi mluvíš z duše. Být po mém, tak se tady nehašteříme o bity, ale o ARMy a MIPSy (a podobnou chátru). x86 mě neskutečně sere.

[Jendа]

IMHO časem zase bude potřeba provést upgrade z IPv6 na něco vyššího a třeba ani ne z důvodu, že nebude stačit počet adres, ale jednoduše protože bude koncepčně zastaralý. Třeba to nebude zítra, ale za 100 let, ale takto se tomu bránit je blbost. Toť můj pohled na věc.

Dokud budou světu vládnout managoři, tak se jen tak jen z důvodu nějaké koncepční zastaralosti nic měnit nebude. Podívej se, jaká je situace nyní, když nás mimo „koncepční zaostalost“ tlačí mnohem akutnější Nedostatek.

[Grunt]

Ale i to jednou praskne. Je vždycky potřeba jen nahodit ten správný hype. Někdo prostě musí udělat ten první krok. Pak se můžou ostatní na následné vlně pominout. Až zas nějaký chytrý ekonom spočítá co se točí v IPv6 sféře peněz, to teprve uvidíš ty fofry. Zatím to tak vždycky bylo, tak věřím, že tomu tak i bude.

[Jendа]

co se točí v IPv6 sféře peněz

Já právě žádné nevidím. Resp. proč by mělo třeba UPC (home ISP) nebo Forpsi (z pohledu hostera/housera) teď zavádět IPv6?

[kralyk z abclinuxu]

Hint: "Je vždycky potřeba jen nahodit ten správný hype." a taky "Až zas nějaký chytrý ekonom spočítá..."

[Grunt]

Resp. proč by mělo třeba UPC (home ISP) nebo Forpsi (z pohledu hostera/housera) teď zavádět IPv6?

Tak oni asi ne. Ale všelijací znalci Shellu(CISCO,Mikrotici,…) a budovatelé zlatých krabiček si určitě rádi najdou záminku pro své zákazníky i když to ve skutečnosti vůbec potřeba nebude pokud se v tom začnou točit nějaké peníze. Úplně stejně jako ke teď šílenství se značkou HD, tak si myslím, že někdy v budoucnu nastane podobné šílenství v jiné sféře právě se značkou IPv6, IP-Next generation nebo něčím podobným. A kdo ví, třeba se to přenese i do domácí sféry podobně jako třeba standardy 802.11a/b/c/d/…/z.

[Jendа]

Tag img má parametr height. Případně na té Wikipedii bude určitě ten obrázek i v menším rozlišení.

[Grunt]

Ale nekecej, fakt? Co je i 50% moc? Mám přístě zmenšit ještě víc?

[Jendа]

Příloha:

• lama.png (701066 bytů)

Zvláštní, mně to Firefox vůbec neškáluje.

[Grunt]

Příloha:

• lamča.png (345596 bytů)

Protože nakonec ta lama ještě asi budu já. Height totiž neznamená velikost.

[Jendа]

Moment. Proč mi to nezmenší na polovinu šířky okna nebo příspěvku?

[Grunt]

Vždyť říkám, že atribut height asi nebude to pravé ořechové a W3C validní nebo tak něco. Přiznávám, že jsem to tady někde jen okoukal.

[Michal Kubeček]

Protože height je výška, ne šířka. Ale podle specifikací by "50%" mělo znamenat 50 procent přirozené výšky, takže tam asi bude ještě nějaký problém.

[Michal Kubeček]

Zvláštní, tak čistě empiricky Firefox (3.6pre) atribut height zcela ignoruje a obrázek přeškáluje podle width (je-li přítomen) se zachováním poměru stran. To ale platí jen při použití procent, zadá-li se velikost v pixelech, funguje height jak má.

[Grunt]

Tip: It is a good practice to specify both the height and width attributes for an image. If these attributes are set, the space required for the image is reserved when the page is loaded. However, without these attributes, the browser does not know the size of the image, and cannot reserve the appropriate space to it. The effect will be that the page layout will change during loading (while the images load).^[1]

Zrovna se pářu s hrůzou zvanou libjpeg, takže můžu jenom potvrdit.

[Michal Kubeček]

Ano, je lepší specifikovat oboje. Ale chování Firefoxu je jednak nesmyslné, jednak odporuje specifikaci. Navíc dokonce i v případě, že uvedu šířku i výšku, je výška ignorována, pokud je uvedena v procentech. Tj. např, při použití <img ... width="60%" height="30%"> bude šířka i výška 60 procent přirozené.

[Grunt]

Tak třeba Bug? Teda ale až tak? Toho by si snad někdo všiml, ne? Háček musí být někde jinde, protože FF3.5.něco se nechová jinak.

[Michal Kubeček]

Ani bych se nedivil, kdyby si toho nikdo nevšiml. Nastavení velikosti pomocí atributů elementu img se používá prakticky jen s udáním velikosti v pixelech a když už někdo náhodou použije procenta, stejně zadá obě hodnoty stejné.

[Grunt]

To není možné. Vždyť už v dobách FrontPage a IE6 se pomalu neškálovalo/neprasilo (i když je pravda, že ty weby také podle toho vypadaly a že nějaké nesouhlasné velikosti obrázků byly asi tak minimum) jinak.

a když už někdo náhodou použije procenta, stejně zadá obě hodnoty stejné

Já jsem teda z ImageMagicku zvyklí na jiné chování. Proč se taky zbytečně opakovat, že?

[thingie]

Mne nenapadá jediný případ, kdy bych tohle chtěl udělat. Zadat velikost img v pixelech je rozumné, protože to načítání a vyhrazení místa, takže se to dělá, a je to častá rada. Stejně tak je občas i relativně smysluplné jednoduše zmenšit obrázek přes ta procenta, jako náhled, nebo tak, ale zadávat různá čísla pro velikost a šířku a tak to deformovat? Kdo by to dělal.

[Grunt]

ale zadávat různá čísla pro velikost a šířku a tak to deformovat?

Proto se bavím o chování ImageMagicku. Tam se to defaultně bere jako čtverec, který se bude zmenšovat, takže druhý rozměr je tam docela k ničemu. A když se zadává velikost v procentech, tak také jenom jednou. Když už je potřeba změnit i poměr, tak se v ImageMagicku za rozměry musí šoupnout ještě vykřičník(který ještě ke všemu BASH interpretuje), protože je to považováno fest za prasárnu. By mě ani ve snu nenapadlo, že se to někde může chovat jinak.

relativně smysluplné jednoduše zmenšit obrázek přes ta procenta

Ale fuj.

[Michal Kubeček]

Curiouser and curiouser…

Cvičně jsem zkusil další prohlížeče. Konqueror použije šířku 30 procent a výšku nechá původní. Opera zmenší oba rozměry na 30 procent. Skoro se bojím pustit windowsový virtuál, abych se podíval, co vymysleli autoři MSIE. :-)

[Jendа]

Jak řeší nedostatek adres profíci

[Grunt]

LOL, no bohudík:

Expires: January 1, 2010

[pavlix]

Hehe, na každym síťovym školení říkám, že používáme 32-bitové adresy pro IP(v4), 48-bitové adresy pro TCP/UDP (na IPv4), 128-bit pro IPv6, 144-bit pro TCP/UDP na IPv6....

Teďka mě napadlo, že jsem mohl ještě uvést 64-bit a 80-bit pro ipip (případně IPsec) tunely :).

Tak proč to nevyřešit na aplikační úrovni taky tak :D. Ať je v tom pořádnej bordel.

[kralyk z abclinuxu]

Jen bych poznamenal, že zpětná kompatibilita je většinou cesta do pekel.
Podívej se, kam jsme se dostali s platformou x86 kvůli 'zpětné kompatibilitě'.

On se veme IPv4 packet, na něj se nabalí kus balastu, na ten balast se zas něco nabalí, no a takhle se to bude nabalovat... Ne, to chce něco trochu víc from scratch, jako třeba IPv6.
Akorát se musej lidi a korporace prostě nakopat do řiti a přinutit IPv6 nasadit, jinak se nikam nedostanem

[vencour]

Dotaz na autora: knížku Pavla Satrapy o IPv6 jste četl, zdejší články o IPv6 jste přečet a PROTO kritizujete nebo o IPv6 znáte věci jen z titulků oněch článků a proto z neznalosti kritizujete?

[snajpa]

Něco málo o IPv6 mám načtené (zmíněnou knížku), mám ho na serverech a přes HE tunel občas i na notebooku.

128 bitů může a nemusí být dostatek, o tom se dohadovat nechci, jde mi jenom o princip, proč opakovat stejnou chybu znovu.

V rodině protokolů IPv6 teoretická podpora pro mobilitu bez změny adresy je, stejně jako byla v rodině v4, jenže nikdo to neimplementuje. Tak proto tvrdím, že by tahle vlastnost měla existovat už jako přímá součást protokolu, ne jako rozšíření nebo variace.

[Heron]

Jak by jsi to navrhl lépe?

Z hlediska jednoduchosti routování se pevná délka adresy hodí. V tomto bylo IPv4 navrženo geniálně, stačí pouze logické operace (což je děsně rychlé). Teď se tento koncept vzal, zvolila se delší adresa (jak dlouhá by měla být aby to bylo "nekonečno"?) a přidaly se docela fajn vlastnosti.

Jak by jsi chtěl rychle routovat s adresami bez omezení délky?

[petr_p]

V IPv4 je mobilita zrovna tak jako IPsec dodatečně naroubovaná z IPv6. A nikdo ji tam nepoužívá ze stejného důvodu, jako proč domácí krabičky „switchujou“ mezi WiFi a Ethernetem – protože widlákům by nefugnovala ikonka My Neighborhood.

[pht]

Tak ono by imho toho nefungovalo víc, např bonjour a kamarádi.

[pavlix]

I bonjour se dá vcelku triviálně routovat, když se chce.

[pavlix]

Ad mobilita... moje řeč, zrovna jsem to chtěl napsat...

snajpo... neznalost neomlouvá, mobilita na IPv4 pokud vím nebyla, aspoň ne v době její specifikace pro IPv6. Tudíž patří mezi ty nové (zbytečné) vlastnosti.

S těmi widláky a My Neighborhood akorát úplně nesouhlasím... pokud vím, tak to při troše šikovnosti routovat jde a naopak by se to dalo napsat jako speciální vlastnost na krabici a zvýšit cenu.

[Grunt]

protože widlákům by nefugnovala ikonka My Neighborhood.

Na tu stačí WINS server (Samba ho implementuje) a je po problému.

[pavlix]

Nechce se mi to zkoumat, ale podle mě by to mělo jít jednodušeji... někde na netu byly návody. Pokud si dobře vzpomínám, tak v podstatě stačilo identifikovat ty broadcasty a přeposlat je do ostatních sítí.

[Grunt]

Přeposílat broadcasty? Ale dej pokoj. Jako neříkám, že by to nešlo, ale nač si s nima zasírat ne jednu podsíť ale komplet celou síť? WINS nepotřebuje tolik refreshů od každého a ještě má lepší odezvu.

[Ondrej 'SanTiago' Zajicek]

A opravdu k tomu WINS pomuze? Pokud vim, tak WINS pomaha akorat k prekladu NetBIOS jmen na IP adresy, ale pro samotne hledani sousedu neslouzi.

[Grunt]

Však jo. WINS si to drží v databázi a pro prohledávání pak není potřeba dělat rozruch na síti, ale pošle se požadavek na server a ten do dotazaztele vyprázdní celou svoji databázi, ne? Je to obdoba DNS. To je jedno. Prostě WINS a nebo jak už pavlix řekl, přeposílání broadcastů. Rozhodně to není argument proti routování.

[pavlix]

+1... ve spojení "widlákům by nefungovalo" jsem si představil domácí/sousedskou windows síť o čtyřech počítačích a jednom routeru :), proto mě napadly spíš ty broadcasty.

[petr_p]

Což řeší jen NetBEUI jména. Obecný problém (stejně jako s Bonjour) je v tom, že takové služby jsou definované jako link scope. Psát proxy pro každý protokol nikdo nebude.

Vyřešit by se to dalo přechodem na site scope multicast, což by hraniční router zvládl jednoduchým packetovým filtrem a vnitřní uzly by prostě ověřovaly AH.

Vzhledem k tomu, že IPv4 broadcastové služby se stejně budou muset předělat, protože IPv6 broadcast nemá, tak to vidím jako schůdné řešení.

[Michal Kubeček]

IPv6 sice formálně nemá broadcast, ale de facto se jen zahrnul pod multicast jako speciální případ. Jinak ale souhlasím, že čím méně služeb bude používat broadcast, tím lépe.

[pavlix]

Pokud vím, tak na všecky současné jmenné služby (v praxi se dá uvažovat tak maximálně o třech) je k dispozici zmíněná proxy, kterou "nikdo psát nebude".

A nejen to, ty služby jsou obvykle jednoduchý multicast, na každém routeru stačí zadat, jestli se má ten multicast přenášet nebo ne (popřípadě mezi kterými sítěmi ano a mezi kterými ne.

Takže na to není ani ta proxy potřeba.

Pokud vím, tak od site scope se ve standardizaci spíš upouští... a podle mě je to dobře.

Zrovna Bonjour je aplikace pro multicast-DNS (mimojiné), který lze triviálně routovat site-scope jenom tím, že všecky routery kromě hraničních to pustí do všech sítí. To funguje jak na IPv4, tak na IPv6 úplně stejně a nemusí se ani použít jiná multicast adresa než dosud.

[petr_p]

Za prvé je opruz provozovat nějaké démony zrovna na krabičkách za pětistovku, za druhé nejde jen o běžné protokoly, ale o desítky proprietárních protokolů všelijakých her, kecálků, konfigurátorů a podobně.

Site scope multicast ale potřeba je. Prostě proto, aby se nebil globální multicast s lokálními službami. Že zmizel site scope unicast je dobře (akorát jsem musel přečíslovat jednu historickou síť).

[pavlix]

Nevím, jestli mám na tvůj příspěvek reagovat jinak, než napsat, ať si přečteš ještě jednou ten můj. Ale dobře.

1) Já mluvím o zhruba trojici protokolů, které jsou používané na různých operačních systémech pro objevování okolních služeb a které fungují na bázi multicast (případně broadcast, rozdíly jsou minimální).

Ty mluvíš o desítkách proprietárních protokolů a přitom jsi neuvedl ani jeden, kde by to bylo potřeba a nestačil by třeba multicast-DNS.

2) Ty mluvíš o tom, že site-scope multicast je potřeba... to jsem nikdy nevyvracel.

Já psal, že zavádět speciální site-scope multicast potřeba není, protože (například /nezneužívat, jen například/ pro multicast DNS) existují speciální multicast adresy, které je možné vybrat a triviálně routovat po celé multicast doméně.

Tato multicast doména se nemusí shodovat s klasickým ethernetovým segmentem, který funguje jako broadcast doména a tudíž je libovolně konfigurovatelný... což znamená, že podle přání správce může být nakonfigurován i jako site-local.

Z toho jednoznačně vyplývá, že k tomu není potřeba zavádět speciální site-local sémantiku, která původně byla do IPv6 zahrnuta, ale *upouští* se od ní.

--

Ještě poznámka... někdy je lepší tvořit síť o více ethernetových segmentech pomocí krabiček za tisícovku místo za pětistovku, nebo klidně i za víc, pokud to znamená, že ta síť bude fungovat podle představ. Zaškrtávátko "routovat multicast DNS (pro neznalé: pokud zaškrtnete toto tlačítko, bude fungovat vyhledávání služeb mezi sítěmi)" je něco, co je pro tvůrce krabičky prakticky zadarmo a je dané opravdu jen poptávkou.

[petr_p]

Desítky proprietárních protokolů: Konkrétní vám neřeknu, protože se v daných oblastech nepohybuji, ale setkal jsem s hrami (často rychlý přepis z IPX na IPv4), kde funkce najdi/informuj všechny hráče byla implementována přes vlastní protokol nad IP broadcastem. To samé různé doplňky typu Teamspeak. Ale je možné, že dneska po nich neštěkne ani pes, protože výrobci her přešli na unicast řízený herními servery, na kterém se lépe vydělává. Další, co jsem viděl, byl jakýsi tiskový server, který bylo možné nakonfigurovat jedině příšernou aplikací, která broadcastem pořvávala, dokud se server neozval. Opět je možné, že podobné manýry už nejsou v módě a používá se něco „standardizovaného“, třeba mDNS.

Zavádění speciálního site scope multicastu. Asi jsme se nepochopili. V IPv6 na něj je již vyhrazen prefix ff05::/16. Některé protokoly (DNS, DHCP) mají zaregistrovanou adresu. Pak existuje něco, čemu IANA říká variable scope multicast (ff0X::/16), kde existuje velká řada registrovaných adres (třeba NTP).

Já jsem tedy nevolal po zavádění „speciálního“ multicastu. Jen chci, aby se nerušil u multicastu status site scope. Tedy aby bylo jasné, které adresy jsou site scope a které global scope. Chápu, že představa globálního multicastu vyvolává v některých lidech hrůzu, ale osobně doufám, že se ho jednou dožiji.

Když zůstane zachován site scope multicast, není nutné řešit nějaké proxy. Prostě se v lokální síti nechá směrovat multicast a na hraničním routeru se zařízne. Globální se nechá proudit.

Rozumíme si?

[pavlix]

Doufám, že nebude potřeba víc než nějaký mDNS-like protokol, nebo v nejhorším několik takových, pokud se všichni neshodnou. K tomu by mohly dopomoct fungující implementace v routerech, programátoři pak budou dávat přednost řešení, které funguje obecněji (nebo pro to budou aspoň mít dobrý argument).

Jinak díky za konkrétní příklady, všecko to jsou typické usecases pro mDNS-like protokol.

No... určitě jsme se špatně pochopili, protože popisujeme v podstatě dva různé pohledy.

Když jsem se díval konkrétně na DHCPv6, tak to vypadá, že site-local multicast se použije jenom v případě, že existuje link-local relay, který tu site-local adresu sdělí klientovi jako adresu DHCP serveru. Takže je to velmi specifický případ něčeho, co už je samo o sobě velmi specifický případ automatické konfigurace, neboli:

a) klient se zeptá (pokud nechce čekat) na informace o routeru... dozví se (router advertisement), že autokonfigurace bude stataful (DHCP) a ne pro IPv6 typická stateless (nastav si sám) b) klient se zeptá na DHCP server (přes link-local adresu) a DHCP relay agent (ne server) mu odpoví, že DHCP server je na té dané site-local adrese (výchozí chování dhcp relay, může říct i jinou adresu, třeba unicast). c) teprv teď se použije multicast adresa

Vypadá to, že pro určité schéma (centrální DHCP server, multicast-enabled routery předávající si informace routovacím protokolem, defaultní nastavení DHCP relay agentů /pravděpodobně součást routerů/) má tenhle způsob práce i smysl. Líbí se mi to, ale chtěl bych to vidět fungovat v praxi a ne jenom na papíře.

V tomle případě sice neřešíme proxy, ale musíme mít aplikaci názvem DHCP relay, tedy kus za kus.

--

DNS jsem v registru nenašel *vůbec* a to v žádné kategorii. Pokud jsem se přehlédl, prosím nasměrovat.

--

To že je aplikace zaregistrovaná ve variable-scope, ještě neznamená, že opravdu používá (ať už na papíře nebo v praxi) zrovna site-local.

--

mDNS je registrované jako variable-scope, ale používá pouze link-local. Takže máme dvě řešení, jak to rozšířit.

1) Ve všech klientských aplikacích začít najednou používat site-local místo link-local. Hezké, čisté a zpětně *ne*kompatibilní řešení. A v případě, že se nedá na hranici sítě pozor, tak možná i nebezpečné.

2) Přeposílat link-local mDNS pakety mezi sítěmi, protože víme, že chceme vyhledávat na všech těch sítích. Bezpečné, protože sami víme, mezi kterými linky přeposílat, funguje bez změny software už teď, změna se týká jen routeru a jedná se jen o přeposílání paketů.

3) Řešení a la DHCPv6, tedy pomocí speciální aplikace na routeru, podobné DHCP relay. Ta bude obsahovat informaci, že existuje site-local konfigurace... a noví klienti se budou umět zeptat i site-local... IMO paskvil

4) Aplikační relay... to existuje a funguje, ale dělá prakticky to samé, co to přeposílání paketů.

5) Nějaká kombinace předchozího

--

Až moc jsem se soustředil na oblíbené mDNS, které ale není zatím nijak solidně uznávané, ač v praxi na Applu a Linuxu používané. Jiné protokoly budou mít podobné problémy, jako například odlišení hraničního a interního routeru kvůli bezpečnosti... ale detaily neznám.

--

Takže jo... site-local prefixy IPv6 adres by mohly být na tohle užitečné... ale nevím o tom, že by se takové řešení používalo a nebo bylo aspoň na dobré cestě.

To ještě nevím, jestli si rozumíme :) nebo spíš nevím, jestli oboustranně.

[pavlix]

Grrr, příště až budu mít takovouhle slinu, tak to radši hodím rovnou do nového blogpostu.

[pavlix]

Na ten "site scope unicast" radši budu reagovat zvlášť... že byl zrušen, není pravda. Jen se pro číslování lokálních sítí zvolilo jiné schéma, které umožňuje jejich dodatečné spojení.

Nový standard se mi na 90% líbí... ale obvykle ho používám na testování stejným způsobem jako ten starý. Dělám to tak, že náhodnou část nevymýšlím, ale vyplním nulama.

Tím sice autorům standardu kazím jejich původní záměr v adresování, ale vzhledem k tomu, že je to moje vlastní síť a nezpůsobí to kolizi s Internetem, tak mi to opravdu vrásky nedělá :). Hlavně, že je to jednodušší pro účely testování.

V produkční síti bych si asi práci s (částečně) náhodným prefixem dal, je to skvělý nápad.

[ZeXx86]

Proc vam vadi tolik IPv6, kdyz se situace opakuje uz nekolik krat a to i v dobe IPv4, kdy se prechazelo ze starsich protokolu - nebylo to sice v takovem meritku. IPv6 je rozhodne lepsi nez abychom se vsichni skryvali za NATem a internet ztracel svou funkcnost. IPv6 oddali nedostatek IP adres na dost dlouhou dobu a myslim ze se ji tady nikdo z nas nedozije. IPv6 je skoro stejne narocne na zpracovani jako IPv4 prave kvuli odstraneni kontrolniho souctu (pouze z hlavicky IP), IP hlavicka je s verzi 6 konstatne velika narozdil od verze 4 a to prinasi dalsi zrychleni. Pokud jste takovy chytrak, vymyslete lepsi protokol, standardizujte a uvedte do provozu, nikdo vam v tom nebrani. Bohuzel nastup IPv6 uz s nejvetsi pravdepodobnosti nezvratite.

[pavlix]

Pokud vím, tak v době IPv4 nebylo potřeba z ničeho (masově) přecházet... všecky předchozí protokoly byly nasazené experimentálně a v malém měřítku.

[Zdenek]

Ten pohled nastineny autorem chapu. Jedna se o perfekcionisticke abstraktni videni. Urcite by se dal jiz dnes vymyslet super neomezeny protokol, ktery nebude nutne menit ani v roce 20 000, ale v realnem svete jsme omezeni soucasnym stavem urovne techniky a proto se musi zjednodusovat ("sestoupit na zem"), aby se veci dali prakticky pouzivat. Jinak bysme i v IT skoncili jako dusevni onnanisti z jisteho oboru fyziky. Ti nadhernou matematickou abstrakci obsahnou a vysvetli temer vsechno, ale prakticky vysledek (nebo alespon overitelny predpoklad) jejich usili je stale v nedohlednu.

[zelial]

Mit protokol, ktery nam bude stacit na veky veku, amen. Krasna predstava, skoda, ze se nic takoveho vymyslet neda. Dokonaly protokol budes navrhovat nekonecne dlouho. Viz taky http://en.wikipedia.org/wiki/Overengineering

A treba konkretne ta dynamicka delka adresy jde proti filozofii IPv6, kde se zjednodusuje a optimalizuje, jak to jen jde: zadne checksumy, fixni hlavicka se zarovnanim poli, zadna fragmentace po ceste,...

[xm]

Tak se podívejme na počty:

počet IPv4 adres = 4.3 * 10^9

počet IPv6 adres = 3.4 * 10^38 počet 64-bit prefixů = 1.8 * 10^19 počet 48-bit prefixů = 2.8 * 10^14

počet hvězd v naší Galaxii = 2 * 10^11 počet hvězd v celém vesmíru = 3 až 7 * 10^22

Takže si to shrňme. Dejme tomu, že kolem každé hvězdy naší Galaxie by obíhala 1 obyvatelná planeta a na každé této planetě by bylo okolo 10 miliard bytostí (naprosto zcestný předpoklad, protože jen zlomek hvězd má planetární systém a z tohoto zlomku jen další velice nepatrný zlomek může být obyvatelný). To činí 2e11 * 1e9 = 2e20 bytostí, tedy jen cca 10x tolik než je 64-bitových prefixů.

Můžeme dejme tomu předpokládat, že navíc dojde k bouřlivému rozvoji nanotechnologií. Lidské tělo je složeno z cca 5e13 buněk. To je cca 370 000 krát méně než je adres v 64-bitovém prefixu (který každá bytost dostane). Tedy každý má dostatek IPv6 adres i kdyby byl doslova zasypán nanoboty a každý z těchto nanobotů měl unikátní IPv6 adresu

Pořád si ještě myslíš, že IPv6 adresy mohou někdy dojít?

[xm]

Eh, chybicka se vbloudila, v tom vypoctu sem pouzil 1e9 bytosti na planetu, nikoliv 10e9. Dobre, 64-bit prefixu je tedy 100x mene. Pokud bych ovsem byl realistictejsi co se odhadu poctu obyvatelnych planet tyce, bude jich naopak o mnoho radu vice

[Marek Bernát]

Ono je to aj tak úplne zcestné, pretože internet je o komunikácii a tá nemôže prebiehať rýchlejšie ako rýchlosťou svetla, ergo nemá zmysel vo väčšej oblasti ako jedna slnečná sústava Čím chcem povedať, že reálne je 128 bitov pre našu planétu ďaleko ďaleko viac, než by bolo nutné; už vďaka 64 bitom by sa nikto (vrátane nanorobotov) najbližších 100 rokov nemusel sťažovať

[Jendа]

Doufám, že za 70 let bude existovat lidstvo v nematrix/neotrocké/nepravěké formě , AbcLinuxu a tato diskuze. Záložkuji (nebo radši stahuji na disk) a nad hrobem se sejdem a posoudíme .

[thingie]

Já doufám, že nebude existovat vůbec, takže na tuhle diskusi kašlu, a za tejden o ní nebudu vědět. :-P

[xm]

Nikdy neříkej nikdy. Stačilo by vybudovat síť umělých červích děr, ty obecná relativita umožňuje Pravda je tu ten detail, že bys podle dnešních výpočtů na jejich stabilizaci potřeboval negativní energii ekvivalentní záporné hmotnosti Jupitara, ale můžou se později objevit nějaké okliky jak to obejít Myslím že už jsem někde na arXivu četl paper, který energetickou náročnost přehodnocoval na nižší a že na stabilizaci by mohl stačit Casimirův jev.

Nebo se ukáže jako správný kandidát na teorii všeho Heimova teorie a pak bychom měli instantní hyperprostor včetně nadsvětelného cestování ani bys nemrknul

M-teorie (konkrétně nějaké brane-world modely) by zas hypoteticky mohla poskytovat nástroj k warpování časoprostoru (v OTR smyslu Alcubierrovy warpové metriky) a tudíž další prostředek k FTL, o tom jsem také jeden zajímavý paper četl (myslím že byl prezentován na AIAA).

Zkrátka já jsem v tomhle věčný optimista FTL ještě nemusí nutně znamenat časové paradoxy (i když může), porušení kauzality může zabránit Hawkingův teorém chronologické ochrany nebo může být naopak platný Novikovův princip sebekonzistence. Možná je i varianta, že kauzalitu bez problémů porušit lze (viz Cramerova retrokauzalita a transakční interpretace kvantové mechaniky).

[Marek Bernát]

Je to len môj pocit, alebo si z fyziky vyberáš len tie najfantastickejšie znejúce teórie, bez ohľadu na ich vedeckú hodnotu? Väčšina toho, čo píšeš je IMHO úplná blbosť a buď je to vylúčené už z princípu teoreticky, alebo je to vylúčené praktickou realizáciou. Pripadáš mi ako snílek, ktorý sa snaží ohnúť fyziku k obrazu svojmu Vlastne, to robí do istej miery praktický každý, kto nie fyzik. Všetci ešte stále aspoň v skryte duše veria, že relativita ani kvantovka poriadne nefungujú a určite existujú všetky tie nadsvetelné rýchlosti, hyperpriestory a pozitrónové mozgy o ktorých sa píše v každej druhej scifi knižke Holt, musím ťa sklamať, nature is a bitch, neriadi sa tým, jak si to ľudia želajú Vždy je samozrejme možné, že objavíme niečo nové, ničmenej, už máme stovky rokov presných pozorovaní a na nich vybudovaných teórií, ktoré sa nedajú len tak hodiť do koša, vieme? Zo súčasne platných teórií žiadnu červiu dieru nepostavíš (nehovoriac už vôbec o tom, či je pre človeka vôbec principiálne možné v jej okolí prežiť). No, a nič iné ako súčasné teórie nie je veda, ale len neoverená hypotéza a má to rovnakú hodnotu ako scifi spred 60 rokov

[Marek Bernát]

 

...a má to rovnakú hodnotu ako scifi spred 60 rokov

Čím samozrejme nechcem povedať, že scifi spred 60 rokov je nekvalitné, bože chráň Len toľko, že je to z 99% fi a z 1% sci, prinajlepšom

 

[xm]

Všechno co jsem uváděl jsou reálné vědecké teorie, žádná pseudověda. A zrovna třeba M-teorie je (jestli jsem z jiných diskuzí vypozoroval správně) jedním z tvých oblíbenců

Faktem prostě je, že FTL žádná ze současných vědeckých teorií přímo nevylučuju a já nevidím důvod proč být pesimistický. Nebude to zítra, ani v blízké budoucnosti, ale jsem pevně přesvědčen, že lidstvo jednou nadsvětelně cestovat bude. Říkej si tomu třeba víra nebo "přání otcem myšlenky", to je mi jedno :-P

[Marek Bernát]

Všetko, čo si spomínal, vrátane strún, sú neoverené hypotézy, nič viac, nič menej. Neodvažoval by som sa nazývať teórie nepodložené experimentom vedou. Áno struny sú v istom zmysle najpriamejšie zobecnenie súčasných teórií a vyplatí sa im venovať už čisto z matematického hľadiska, ale to je tak všetko.

FTL vylučujú všetky súčasné _vedecké_ teórie. Ešte raz: máme 100 rokov presných experimentov o tom, že Lorentzova symetria je presnou symetriou vesmíru na všetkých škálach. Červie diery ti neumožňujú cestovať rýchlejšie ako rýchlosťou svetla. Umožňujú len ísť inou cestou, než tou bežnou. Rovnako ako z Prahy do Austrálie nemusíš ísť lietadlom, ale môžeš tam ísť cez stred Zeme. A keď tú Zem dostatočne sploštíš, tak si tam hneď. Problém je, že mi nie je jasné, ako chceš vytvoriť spojenie medzi bodom A a od neho veľmi vzdialeným bodom B, len za pomocou lokálnej fyziky (a všetky zatiaľ známe zákony sú čisto lokálne) v bode A. Ten príklad s Prahou a Austráliou v našom vesmíre nefunguje, pretože náš vesmír je prakticky dokonale plochý. Nežijeme na brutálne zakrivenej variete, kde by bolo možné, aby sa dve veľmi vzdialené miesta (v zmysle metriky na variete) k sebe dostatočne priblížili (v zmysle ambientnej metriky po vložení tej variety do nejakej väčšej). Ergo, červie diery nie sú to pravé orechové. A iný rozumný spôsob rýchleho cestovania si nenavrhol. Ergo, je to čisto tvoja viera, nie veda.

[xm]

Nepoučuj mě prosím o absolutnosti rychlosti světla, speciální teorii relativity mám nastudovanou velmi dobře, děkuji. Když se mluví o FTL cestování, nikdo si dnes naivně nepředstavuje, že prostě poletí standardní cestou rychleji než c. Vždy se mluví o způsobech jak rychlost světla "obejít" (tzn. aby v lokálním rámci překročena nebyla).

V tom příspěvku jsem uvedl 3 způsoby, nikoliv jediný. 2 z nich jsou v souladu s obecnou teorií relativiti (červí díry a Alcubierrova warpová metrika). Třetí možnost (hyperprostor vyplývající z Heimovy teorie) záleží na tom, zda se Heimova teorie ukáže jako správná či nikoliv (osobně tomu moc nevěřím, ale možné a lákavé to stále je a pořád je to jediná teorie, co předpověděla hmotnosti elementárních částic).

Btw. pro existenci červí díry není potřeba, aby byl náš vesmír přirozeně zakřivený. Nejdříve si o tom něco nastuduj (doporučuji papery od fyziků Morrise, Thornea a Vissera, případně i něco od Cramera).

[Marek Bernát]

Keď sa hovorí o FTL, tak obvykle je to v kruhoch ľudí, čo videli fyziku z rýchliku, tak sorry, že som sa unáhlil. Len proste na mňa robíš dojem človeka, ktorý sa o fyziku zaujíma hlavne z pohľadu sci-fi. Tak nech vieme, na čom sme: si fyzik? Ja som napr. zatiaľ len študent, ale za fyzika sa vcelku považujem

Červie diery bola jediná zaujímavá možnosť. Heimova teória je hypotéza a nie veda, na základe ktorej by sa dali rozumné predpovede. Mimoto, jediná predpoveď, čo som zatiaľ z nej mal možnosť vidieť, sú hmotností častíc, ktoré približne súhlasia s pozorovaním, ale na ďalších desatiných miestach, to už nefunguje. Bohužiaľ nie je jasné, či je to vada teórie, alebo len aproximácia hodnôt, ktoré tá teória dáva. Celkovo som však skôr pesimistický. Čo sa týka toho Alcubierra, tak to tiež nevyzerá moc realisticky kvôli zápornej energii. A v okamihu, keď si zavoláš na pomocou kvantovku, tak máš problém s kvantovou gravitáciou, o ktorej dnes nevieme s istotou nič. Proste, všetky tri možnosti vyzerajú dosť mimo a ak už aj fungujú teoreticky (čo je IMHO len prípad červých dier), tak nefungujú prakticky.

Tak o tom počujem prvý raz. Ak nemyslíš primordiálne červie diery (ktoré sú pre našu diskusiu irelevantné), tak ich musíš nejako vytvoriť, tj. spojiť nelokálne dve miesta variety (ktorá je plochá a teda vzdialené body sú od seba skutočne ďaleko aj v zmysle ambientného priestoru). Nepoznam žiadny mechanizmus, ktorý niečo takéto umožňuje a aj keby existoval, tak by to bolo proti všetkej fyzike, ktorú poznám. Poprosím o nejaký článok, nech si môžem overiť, o čo ide.

[Habo]

No nie tak celkom lebo keby sa pouzili cervie diery a kable by sa natahali cez ne da sa vzdialenost vyrazne skratit ale aj tak si myslim ze IPv6 je dostatocne aspon na niekolko tisicroci (ani ludia sa nemozu prilis rychlo rozmnozovat...)

[xm]

Z toho mého původního příspěvku IMHO jasně vyplývá, že i kdybychom získali nějakou možnost nadsvětelné komunikace, bude IPv6 dostatečné né na několik tisíc let, ale aspoň několik milionů let A pokud nadsvětelná komunikace nikdy možná nebude, troufám si říct, že až do konce života Vesmíru (což s největší pravděpodobností bude pomalá tepelná smrt).

[xm]

Btw. myslím samozřejmě dostatečné jen z hlediska počtu unikátních adres, nikoliv z jiných technických hledisek. IPv6 bude zcela jistě nahrazeno mnohem dříve než za 1000 let, protože se určitě s novými technologiemi vyrojí nové požadavky na síťový protokol (takové které dnes nikdo nemůže předvídat).

[Marek Bernát]

Ok, vytvor si jednu takú doma a daj vedieť postup, nech ich aj my ostatní môžeme používať

[Marek Bernát]

Len ma prakvapuje, že sa ešte neozval Jardík so svojím 32 bit sux! Asi kvôli tomu, že má len 64 bit a sám je mocou IPv6 zahanbený

[Program]

Tak jsem se neplánovaně dostal k tomuto článku a i když nevím, jestli má smysl ještě odpovídat, nemůžu si pomoct. Autor je totálně, ale naprosto uplně a neskutečně mimo a to mimo bych umocnil na min. 128. Většina věcí tu již byla zmíněna, ale opravdu bych ještě jednou opakoval, že autor asi neví, kolik je 2^128. Dál bych podotkl, že autor asi dostatečně nepochopil, že adresování neslouží jen pro odlišení zařízení, ale taky pro jejich nalezení! Kdyby se používalo dynamické adresování, jak popisuje autor mohli bychom možná stahovat rychlostí i v řádech kB/s (a i to by bylo možná sci-fi, to už by dřív doletěl holub, než přišel paket) a úplně nejlepší by to bylo skombinovat s autorovým skvělým nápadem neprovázanosti fyzického umístění s adresou. Kdyby jste si dal dohromady veškerou paměť (jakoukoli) na Zemi, tak by vám nestačila na jeden router!

Prosím zamyslete se dříve (a lépe si něco i nastudujte), než napíšete takovou snůžku blábolů.