Dotaz: Děravost IPv6 prostoru

[Czlovek]

Koukal jsem trochu na principy fungování IPv6 ale nerozumím jedné věci. IPv6 má velikost svého prostoru 2^128. Do tolika normální člověk neumí ani počítat. Jenže nechápu proč je 99 % tohohle prostoru už kvůli návrhu odsouzeno zůstat navždy nevyužitých a nevyužitelných - neboli proč se proboha musí každému Frantovi přidělovat 2^64 veřejných adres. Přitom 2^128 je dost na to aby to do budoucna stačilo na adresaci v rámci celého intergalaktického internetu, kdyby se s tím hospodařilo rozumně a už nikdy by nebylo potřeba vymýšlet nic dalšího, už by nebyly problémy s přechodem na něco jiného (však se podívejte jak (ne)jde přechod na IPv6). Takhle naši vnuci budou muset řešit to samé co se teď řeší s IPv4. Zbytečně.

Odpovědi

[Sten]

Normální člověk nezvládne počítat ani do 2⁶⁴. To číslo je tak obrovské, že pokud kolonizujeme i Mars, Měsíc, Venuši a Europu, tak pořád to bude jedna síť na 40 mm² (pro představu: pokud by každý bydlel v minibytě o 4 m² a ignorujeme všechny přístupové chodby, pak je takových sítí dost pro 10 000 pater). Nezapomeňte, že kolonizací nové planety se nová plocha pouze přičte, zatímco přidáním bitů se množství adres se násobí.

Celý systém TCP/IP je pro mezigalaktický internet stejně nepoužitelný. Rychlost světla je značně omezená.

[Sten]

Pardon, s Venuší je to 64 mm². Naši vnuci si budou moci polepšit a mít byty o 6,4 m²

[Šangala]

Už na zemi bude problém s nanoboty.

Pro mezigalktický internet se bude využívat zakřivení prostoru a další rozměry, takže mu rychlost světla postačí.

[Filip Jirsák]

Díky tomu, že je ten prostor tak obrovský, vzala se z něj teď malá část, a z té se bude přidělovat vámi popsaným způsobem. Který je navíc jen doporučením, a někteří čeští ISP i IPv6 adresami šetří a dávají koncovým uživatelům méně adres. Ten současný způsob přidělování vznikl tak, aby za prvé každé zařízení mělo svou IPv6 adresu odvozenou automaticky z MAC adresy, aby nebylo nutné řešit přidělování IP adres, a za druhé aby si každý mohl přidělený rozsah rozdělit na podsítě. Zbytek IPv6 prostoru zůstává rezervovaný pro budoucí použití, takže když se v budoucnosti ukáže, že současný systém přidělování je špatně, může se změnit. Je to prozíravější řešení, než se tvářit, že teď víme všechno a víme, jak bude potřeba v budoucnosti s adresním prostorem zacházet. S tvrzeními "už nikdy by nebylo potřeba" je potřeba zacházet opatrně, IPv4 také nevzniklo se záměrem, že to bude hrozná prča, až IPv4 adresy dojdou.

[Jendа]

a za druhé aby si každý mohl přidělený rozsah rozdělit na podsítě

Když dostanu /64, tak už si to na podsítě rozdělit nemůžu, a to ani kdybych nechtěl používat SLAAC, ne?

[Filip Jirsák]

Pokud jsou v plánu podsítě, měl by dnes dotyčný dostat spíš /48. Ale předpokládám, že se budou na podsítě dělit i /64, protože dnes má pár podsítí každá domácnost (minimálně LAN a WiFi) - takže nebude na podsítě potřeba /16, ale třeba /4 nebo /6 se hodí. Podle standardu tomu snad nic nebrání, problém by mohl být, pokud by nějaké zařízení neumělo delší prefixy v routovacích tabulkách. Nevím teď z hlavy, zda je ve standardu požadavek jenom na /64 nebo na libovolný prefix sítě, ale nemyslím si, že by se taková zařízení masově vyskytovala. Zvlášť když budou ISP na IPv6 adresách šetřit. Koneckonců je jedno, jak si svou síť rozdělím, důležité je, aby se dlouhé prefixy nevyskytovaly v globálních routovacích tabulkách.

[Ondrej Santiago Zajicek]

protože dnes má pár podsítí každá domácnost (minimálně LAN a WiF)

V mnoha domacnostech tvori lan a wifi jednu podsit (z hlediska sitove vrstvy).

[Filip Jirsák]

Což by ale být nemělo, protože zařízení v těch dvou sítích se nedokážou kontaktovat přímo, mimo router (resp. v dané roli spíš bridge).

[paul2no]

No, když mám jak LAN tak WLAN jako jednu síť, tak nefunguje ten "router" spíš jako switch?

[JMP]

myslím, že izolace WiFi klientů APčka se musí extra nastavit, jinak je to normální linková vrstva stejně jako připojení kabelem...

tedy klienti se vzájemně vidí

[Ondrej Santiago Zajicek]

Jsou propojene zarizenim fungujicim jako bridge [*], takze to je v poradku. Na urovni linkove vrstvy muze kazde zarizeni s kazdym komunikovat, takze pro sitovou vrstvu to je jedna sit.

[*] Technicky vzato to neni jen obycejny bridge, nebot 802.3 a 802.11 se trochu lisi na linkove vrstve, ale ty rozdily maji minimum praktickych dopadu a muzeme je zanedbat.

[Filip Jirsák]

Technicky je to v pořádku, odpovídá to standardům. Bridge přesně k tomuhle slouží – ale já pořád bridge považuju za nouzové řešení. Podle mne to není úplně v pořádku koncepčně, jsou to dvě fyzicky odlišné sítě, veškerý provoz mezi nimi musí jít přes jedno zařízení – podle mne je správné, aby tím zařízením byl router. Už jenom proto, že WiFi zpravidla sahá i ven z bytu nebo baráku a může se k ní pokoušet připojit kdokoli, zatímco připojit se přes LAN zpravidla znamená dostat se ke kabelu uvnitř bytu nebo baráku. Ale je to samozřejmě jen můj názor, někdo jiný má třeba zase raději bridge než routery a považuje za správné mít vše v jedné síti.

[Michal Kubeček]

Podle mne to není úplně v pořádku koncepčně, jsou to dvě fyzicky odlišné sítě, veškerý provoz mezi nimi musí jít přes jedno zařízení – podle mne je správné, aby tím zařízením byl router.

Pokud bychom tento argument považovali za dostatečný, můžeme prohlásit za špatný jakýkoli bridge a v podstatě jakýkoli ethernet používající více samostatných switchů. Pokud by "fyzicky odlišné" mělo znamenat různou fyzickou implementaci, tak co třeba bridge použitý pro zpřístupnění xen/KVM hosta?

Už jenom proto, že WiFi zpravidla sahá i ven z bytu nebo baráku a může se k ní pokoušet připojit kdokoli, zatímco připojit se přes LAN zpravidla znamená dostat se ke kabelu uvnitř bytu nebo baráku.

To už je samozřejmě jiná, ale to je věc konkrétního správce, jak si stanoví pravidla (a jak má tu wi-fi zabezpečenou).

[Filip Jirsák]

Já také jakýkoli bridge za špatný považuju… Uznávám ale, že existují případy, kdy je bridge nejlepší řešení, zejména k obejití nedostatku nějakého zařízení. Uvedený příklad s virtuálním počítačem, kdy nemá každý virtuální stroj svou síťovou kartu, je jedním z nich. Více switchů je něco jiného – switch je jen zdokonalený hub, který pokud si je jist, že nějaký paket stačí poslat na jeden port, neobtěžuje tím ostatní porty. Ale jak už jsem psal, je to jenom můj osobní pohled na věc, a nevadí mi, že se na to někdo dívá jinak. Podle mne spolu mají počítače v jedné síti umět komunikovat na linkové vrstvě přímo, mezi různými sítěmi se pak komunikuje přes router. Bridge je takový hybrid, vyvolává dojem, že zařízení komunikují přímo, ale přitom je tam skrytá nějaká logika. A vedle toho zase může být switch s VLANy, ten mi nevadí. Nemám to jednoduché

[Michal Kubeček]

Více switchů je něco jiného – switch je jen zdokonalený hub, který pokud si je jist, že nějaký paket stačí poslat na jeden port, neobtěžuje tím ostatní porty.

Switch a bridge jsou jen dva různé názvy pro stejnou funkci.

[Op]

Takže L2 zařízení které spojuje bezdrátovou síť s drátovou nazýváte switchem?

[Michal Kubeček]

Jak ho budu nazývat je jedno, podstatné je co dělá. A podstata je ta, že princip fungování toho, čemu je zvykem říkat switch, a toho, čemu je zvykem říkat bridge, je úplně stejný.

[Ondrej Santiago Zajicek]

Z hlediska tradicniho OSI modelu je hub odlisne zarizeni od switche, nebot hub pracuje na fyzicke vrste, zatimco switch (stejne jako bridge) na linkove vrstve. Naopak bridge a switch je z tohoto pohledu shodny, Jinak ty pojmy nejsou o moc ostreji vymezene, aby se dalo rici, ze tohle je bridge a ne switch ci naopak, i kdyz je pravda ze neformalne bych switch chapal jako uzsi pojem pro konkretni kategorii hardware, zatimco bridge je obecny pojem pro libovolny prvek propojujici site na linkove vrstve.

[Filip Jirsák]

S tím, že bridge propojuje sítě, by myslím většina lidí souhlasila. O switchi by na druhou stranu málokdo řekl, že propojuje sítě, spíš že propojuje jednotlivá zařízení do jedné sítě. Stejně je to jen akademická debata – můžeme do toho zatáhnout ještě L3 switche a řešit, kdy je switch bridge a kdy router To, co se prodává jako „WiFi routery“, většinou pracuje minimálně na L4, umožňuje to např. na firewallu filtrovat provoz mezi LAN a WiFi.

[Michal Kubeček]

Než se do toho začnete ještě víc zamotávat, zkuste si ujasnit, jaká je primární funkce switche a bridge. Pokud tam vidíte nějaký principiální rozdíl, tak nám jej, prosím, sdělte. To, že je možné, aby takový bridge/switch disponoval i dalšími funkcemi, jako jsou VLAN nebo filtrace paketů podle hlaviček vyšších vrstev, v tom nehraje roli. To opět umějí jak zařízení označovaná jako "switch", tak zařízení označovaná jako "bridge".

[Filip Jirsák]

Primární funkce switche je podle mne umožnit komunikovat každému zařízení v síti s každým jiným zařízením v síti. Switch je jenom jedna z možných implementací, další je hub nebo fyzické propojení každého zařízení s každým. Primární funkcí bridge je propojit dvě sítě, které by jinak byly oddělené, tak, aby to pro zařízení v obou sítích vypadalo pokud možno tak, že jsou v jedné síti spolu se zařízeními z té druhé sítě. Liší se to například tím, že při komunikaci dvojic zařízení A s B a C s D se ty dvě komunikace navzájem neovlivňují (v ideálním případě), protože komunikují přímo mezi sebou. Pokud A a C budou v jedné síti a B a D v druhé síti a ty sítě budou propojené bridgem, ty dvě komunikace se ovlivňují, protože jdou přes společný prvek a dělí se o jeho kapacitu. Oba typy zařízení mohou mít další funkce, implementována klidně mohou být podobně nebo stejně. Rozdíl je v tom, zda je to zařízení v centru jedné sítě, nebo zda propojuje dvě jinak samostatné sítě. Ostatně z toho pocházejí i názvy těch zařízení.

[BFU]

Mám bezdrátový SOHO router, ke kterému jspu připojeny počítače A, B, C a D. Všechny jsou u mě v baráku, je to tzv. jedna síť. Počítače A a B jsou připojeny kabelem k routeru, počítače C a D jsou připojeny bezdrátově. Bez toho routeru se počítač A nespojí a počítačem B, C ani D. A tak to je i ve všech dalších kombinacích. Prostě bez toho routeru nedají ani ránu.

Jakou získám výhodu, když si očísluji každou z fyzických sítí zvlášť?

[Michal Kubeček]

Liší se to například tím, že při komunikaci dvojic zařízení A s B a C s D se ty dvě komunikace navzájem neovlivňují (v ideálním případě), protože komunikují přímo mezi sebou. Pokud A a C budou v jedné síti a B a D v druhé síti a ty sítě budou propojené bridgem, ty dvě komunikace se ovlivňují, protože jdou přes společný prvek a dělí se o jeho kapacitu.

V tom ale žádný rozdíl není, oboje platí jak pro switch, tak pro bridge (pochopitelně - je to totiž totéž).

Rozdíl je v tom, zda je to zařízení v centru jedné sítě, nebo zda propojuje dvě jinak samostatné sítě.

Jak se to pozná? Jak se prinicipiálně liší "jedna síť v jejímž centru je X" a "dvě jinak samostatné sítě propojené X", ať už si za X dosadíte switch nebo bridge?

[Filip Jirsák]

Rozdíl je vidět třeba na mapě sítě. Tady je jedna síť, každý barák může komunikovat s každým, prostě se jen na křižovatce "přeswitchne" na tu správnou cestu. Tady jsou dvě sítě, jedna na severozápadním pobřeží, druhá na jihovýchodním. Pokud chce kdokoli z jednoho pobřeží komunikovat s kýmkoli z druhého pobřeží, musí přes jeden most, "bridge", který ty dvě sítě spojuje. Ve světě počítačů může být implementace obojího třeba stejná. Pořád to ale jsou dvě různé funkce, pořád je rozdíl v tom, jestli se na něco dívám jako na jednu síť nebo na dvě propojené sítě.

[Michal Kubeček]

Pokud chce kdokoli z jednoho pobřeží komunikovat s kýmkoli z druhého pobřeží, musí přes jeden most, "bridge", který ty dvě sítě spojuje.

Bridge také nemusíte mít jenom jeden. Třeba u toho příkladu s xen DomU je celkem běžné, že každý interface má svůj bridge. A stejně tak může mít bridge víc než dva porty.

pořád je rozdíl v tom, jestli se na něco dívám jako na jednu síť nebo na dvě propojené sítě.

Jinak řečeno: na úplně stejně fungující síť se můžete dívat dvěma různými způsoby a podle toho ten prvek označit dvěma různými termíny, ale z funkčního hlediska je to úplně totéž.

[Filip Jirsák]

Spíš se na síť nebo sítě dívám jedním nebo druhým způsobem, podle toho vybírám a nazývám zařízení, a podle toho tu síť/sítě buduju. Když budu chtít propojit dvě sítě do jedné, asi mezi ně nebudu dávat 32portový switch. A když budu chtít propojit několik počítačů do jedné sítě, asi nebudu mezi každé dva počítače dávat bridge. (Ano, bridge může mít víc než dva porty, ale jeho název evidentně vznikl od těch dvou portů a to je to, co si pod tím člověk nejprve představí.)

[Michal Kubeček]

Když budu chtít propojit dvě sítě do jedné, asi mezi ně nebudu dávat 32portový switch. A když budu chtít propojit několik počítačů do jedné sítě, asi nebudu mezi každé dva počítače dávat bridge.

To, že počet portů zařízení volíte podle toho, kolik jich potřebujete, a to, že topologii se snažíte volit co nejjednodušší, nijak nesouvisí s otázkou, jestli je mezi funkcí bridge a switche nějaký principiální rozdíl (které se stále nápadněji vyhýbáte).

a to je to, co si pod tím člověk nejprve představí

A to je celý problém. Já se nebavím o tom, co vy si představujete. Já se bavím o tom, jak ta zařízení fungují.

[Filip Jirsák]

Já se zase nebavím o tom, jak ta zařízení technicky fungují, ale o tom, jaký mají účel. Ten technický způsob fungování se může docela snadno změnit...

[Michal Kubeček]

I účel je naprosto stejný: propojit několik ethernetových segmentů do jedné broadcast domény, aniž by se jednalo o kolizní doménu. Co napíšete na krabici a do marketingových materiálů, to je otázka pro obchodníky, z technického hlediska v tom rozdíl není. Možná jsem naivní, ale myslím, že tohle je stále ještě fórum pro technicky zaměřené uživatele.

[Filip Jirsák]

Mne by nikdy nenapadlo nazývat síťovou kartu „ethernetovým segmentem“. Topologie sítě je také technické hledisko. A zrovna u SOHO routerů je trochu nesmysl bavit se o tom, jaký přesně teoretický prvek sítě to zařízení představuje, když ta zařízení jsou switch, router a bridge v jednom a záleží jen na konfiguraci, jak se to bude chovat. Pro vás switch a router, ať už switch na WiFi znamená a přepíná cokoli.

[Michal Kubeček]

Mne by nikdy nenapadlo nazývat síťovou kartu „ethernetovým segmentem“.

Mne také ne. Ale jak to souvisí s příspěvkem, na který odpovídáte?

[Filip Jirsák]

Podle mne switch slouží k propojení několika síťových zařízení (např. síťových karet) do jednoho ethernetového segmentu. Ale pokud pro vás switch propojuje ethernetové segmenty, pak asi to síťové zařízení musí být ethernetový segment, ne?

[Michal Kubeček]

Ne. Ethernetový segment je část sítě, ne zařízení. U dnešního čistě přepínaného ethernetu ten pojem degraduje na dvojici rozhraní propojených UTP kabelem. U sdíleného odpovídal kolizní doméně.

[Filip Jirsák]

Takže funkcí switche je propojit několik dvojic rozhraní propojených UTP kabelem do jedné broadcast domény. Jestli dovolíte, já budu nadále používat switche k propojení několika zařízení do jedné sítě, a budu jim i nadále říkat switche, ne bridge.

[Michal Kubeček]

Rozhodnout se, který z těch dvou ekvivalentních pojmů se rozhodnete používat, je samozřejmě vaším právem a já ho nemíním zpochybňovat.

[lertimir]

To že je to jen věc pojmenování je vidět i například z toho, jak se v mnohých firmách či VŠ, které byly zasíťovány někdy v 90 letech a mají z dnešního pohledu na kancelář málo přípojek, připojují další zařízení pomocí SOHO switchů. Pro ten hlavní switch v racku to dopadne tak, že na konkrétním drátu, má ne jednu, ale nějaký balík MAC adres. Viděl jsem i zařízení, kde tam hodili starý 100M hub, tím pádem ke rack switchi chodily i packety, které vůbec nepotřebovaly k rozhraní přijít, switch tedy plně vypadal jako bridge. Primární smysl obou je snížit kolizní doménu pro packety a tím zvýšit propustnost. U switche ve fullduplexu je to snížení na nulu, ale nemusí být.

síťový segment

[lertimir]

Jenže u pojmů nemůžete ignorovat jejich vznik, vývoj a historii. V době sběrnicového 10M Ethernetu na prodlužování dosahu segmentu se požíval repeater a bridge. Totožně funkcionální zařízení v UTP je hub a switch.

[Filip Jirsák]

To už je samozřejmě jiná, ale to je věc konkrétního správce, jak si stanoví pravidla (a jak má tu wi-fi zabezpečenou).

Zcela nový rozměr to dostává, když zařízení se zapnutým Wi-Fi Sense ochotně sdělí heslo k síti všem kontaktům. Zabezpečení privátním klíčem (ten doufám Wi-Fi Sence nesdílí) není v domácích sítích zrovna běžné, a podle mne většina lidí nepovažuje svou domácí síť za veřejnou a nechová se tak k ní. Ale pokud někdo chce, aby na jeho tiskárně mohl tisknout kdokoli, kdo jde zrovna kolem po ulici, ať si poslouží…

[Vantomas]

Hm, jenže když to bude routovaný, tak se rozbijou ty autodiscovery protokoly, ty DLNA nesmysly a tak všechny ty věci co si duchaří nad broadcastama, max. multicastama v jedné L2. Jak jenom krabičkářům trvalo dlouho než se tyhle věci naučili používat a dostali to do stavu, že to začíná fungovat out-of-box a teď jim to celé zkomplikovat, že jim sebereme L2 vrstvu!

A taky je problém v tom, že routování je výpočetně náročnější než bridge, takže pak při kopírování z počítače přes kabel na počítač přes wifi lze očekávat na prd výsledky. Ano, dneska ty routery sice už mají více výkonu než dříve, ale protože je stále cena tlačena dolu, tak nelze očekávat revoluci a zázraky.

[pavlix]

Hm, jenže když to bude routovaný, tak se rozbijou ty autodiscovery protokoly

Jirsáka bych si vůbec nevšímal. Člověk chce mít doma jednu síť, bez ohledu na to, co k ní připojí po wifi a co po drátě. Ta síť má tudíž mít jeden IP rozsah pro každou použitou verzi protokolu a vše má fungovat úplně stejně jako by to bylo vše zadrátované. Druhá síť má smysl jen pokud je její účel nějak odlišný od té první, například když člověk doma provozuje malou serverovnu nebo nějaké experimentální sítě.

A taky je problém v tom, že routování je výpočetně náročnější než bridge

Nevěřím, že poznáš rozdíl mezi routingem a bridgem u linuxového routeru.

[Sten]

Nevěřím, že poznáš rozdíl mezi routingem a bridgem u linuxového routeru.

Tak docela velký rozdíl je v tom, že bridge u IPv4 nemusí u každého paketu přepočítávat checksum.

[pavlix]

Chci model routeru a čísla ;). Ne, já vím, že to kvůli mě nikdo měřit nebude, ale fakt si nemyslím, že by dneska běžný router stíhal wifi uroutovat měřitelně pomaleji než ubridgovat, natož znatelně.

[Sten]

OK, beru, že na WiFi se to nepozná

[pavlix]

No dobře, na wifi se to nepozná a na kabelu je to sporné. Ale popravdě řečeno, pokud by mě trápil drobný rozdíl na kabelu, dal bych před soft bridgem přednost switchi, tedy když už tak už.

[lertimir]

To se ale bavíme o 100M. Pokud chci na drátu 1G tak routing je nereálný v domácích podmínkách.

[pavlix]

Pokud chci na drátu 1G tak routing je nereálný v domácích podmínkách.

Nejsem si vědom podmínek, kdy by byl routing nereálný a soft bridging reálný, ty packety prochází pokud vím úplně stejným stackem.

[ebik]

A je vlastně soft bridging na 1G reálný? Spousta linuxových routerů má "hardwarovou akcerelaci" (ať už to znamená cokoli). Navíc tyto routery mají typicky LAN porty propojené hw switchem, s tím, že jeden port tohoto switche je zapojen do procesoru. Router pak může routovat mezi WAN (separátní port) a LAN (port toho switche), ale nemůže ovlivnit tok mezi jednotlivými porty LAN. (Možná to je právě ta inzerovaná hw akcelerace...)

[Michal Kubeček]

Někdy i může, viz DSA driver. Ale je to poměrně čerstvá záležitost.

[pavlix]

A je vlastně soft bridging na 1G reálný?

Není o nic méně reálný než soft routing ;).

[lertimir]

Nerozepsal jsem to moc. Myslel jsem tím, že pokud budu mít domácí drátovou síť na 1G propojenou switchem tak je to v ceně do 1k se SOHO 8 portovým switchem. Kolik musím mít, abych měl zařízení, které mě tech cca 80-100MB/s protáhne přes routing?

[Ondrej Santiago Zajicek]

2 kKc za Ubiquiti Edgerouter Lite (pokud si vystacis se tremi porty a hardwarove akcelerovanym routingem). Nebo bezne moderni PC bez potizi uroutuje gigabit pri rozumne velkych packetech.

[pavlix]

Myslel jsem tím, že pokud budu mít domácí drátovou síť na 1G propojenou switchem

Při srovnání routingu a soft bridgingu je switch jaksi mimo kontext. Nicméně Ondrova odpověď dává vědět o tom, že zásadní rozdíl už dlouho nedělá bridging versus routing, ale software versus hardware.

[Jimmy]

Aby byl rozdíl výraznější, tak něco trochu staršího HW: http://routerboard.com/RB433L Bridging 64 byte - 63.8 Mbps Routing 64 byte - 52.1 Mbps

Když se nastaví nějaké filtrování, tak mohou být nepříjemně velké rozdíly i na dnešním HW.

[pavlix]

Aby byl rozdíl výraznější, tak něco trochu staršího HW: http://routerboard.com/RB433L Bridging 64 byte - 63.8 Mbps Routing 64 byte - 52.1 Mbps

Starší hardware, malé pakety, rozdíly kolem 20%, dejme tomu. Jenom bych se ještě ujistil, že se jedná o software bridging a ne switching.

Když se nastaví nějaké filtrování, tak mohou být nepříjemně velké rozdíly i na dnešním HW.

O filtrování nebyla řeč, navíc lze stejně dobře provádět u bridge jako u routingu, takže mi není jasné, proč to sem taháš.

[lertimir]

V mnoha případech máš pravdu, nicméně ještě se dá uvažovat o modelu "domácí" a "hosté". Což provozuji. Hosté jsou kamarádi mých dětí, kteří občas příjdou s notebooky na "party".

[pavlix]

Dokonce uvažuju o třech skupinách já, domácí+hosté a sousedé ;), první dvě skupiny mám ale sloučené třeba i kvůli tiskárně.

[pavlix]

Abych byl přesný, kvůli autodiscovery tiskárny.

[pavlix]

Mimochodem, díky soft bridgování, podpoře vlan switchů a virtuálních wlan v OpenWRT je toto rozlišení nezávislé na drátovosti.

[Op]

IPv6 si klidně můžeš dělit jak chceš, třeba na /120ky jako ekvivalenty C třídy.

[pavlix]

Na Linuxu to funguje bez problémů, myslím, že by nebylo špatné časem upravit RFC k větší benevolenci.

[JMP]

asi je to trochu rizikové, protože autokonfigurační mechanismy počítají s max. /64 na síť, protože těch zbylých 64 bitů na počítače využijí komplet

počítám, že také postupem času budou přibývat zařízení s hw optimalizací|akcelerací a tam by to pak byl také značný problém...

[pavlix]

asi je to trochu rizikové, protože autokonfigurační mechanismy počítají s max. /64 na síť, protože těch zbylých 64 bitů na počítače využijí komplet

Ve skutečnosti to platí jen pro jeden z mechanismů automatické konfigurace, ale v nějakém RFC jsem to pravidlo četl jako obecně platné, nejspíš to bylo IPv6 Addressing Architecture nebo nějaké takové, a to už dává jen politický smysl (přesvědčit všechny, aby byly ready na SLAAC a přidělovali velké rozsahy), nikoliv technický.

počítám, že také postupem času budou přibývat zařízení s hw optimalizací|akcelerací a tam by to pak byl také značný problém...

To mi přijde jako příliš vágní zdůvodnění.

[JMP]

pravda - IPv6 u nás řešíme teprve měsíc, tak je to vágní, ale pokoušet to nebudu

pokud to budete pokoušet a někde narazíte, tak případně dejte vědět...

[pavlix]

Já to dělat dobrovolně nebudu, mně přijde dělení 64-64 maximálně rozumné, takže ho budu aplikovat všude, kde to půjde, bez ohledu na použitou konfiguraci.

[Petr Šobáň]

Rezerva do budoucnosti.

Kdysi se taky říkalo že 640k RAM stačí na všechno a už v dobách MS-DOSU to bylo málo a hledaly se berličky jak to pro MS-DOS obejít.....

[Heron]

Zkuste změnit pohled na věc. Adres není 2^128. Je 2^64 sítí a v každé síti může být 2^64 hostů. Zkrátka se na to zkuste podívat pohledem: kolik potřebujeme sítí? a jak velkou adresaci v rámci jedné sítě (aby se pohodlně daly dělat věci jako autoconfig, privacy apod). To už potom jako plýtvání nevypadá.

Nehledě na to, že intergalaktickou síť bych do toho vůbec netahal. Zpoždění mezi planetami byť i jenom Sluneční soustavy jsou tak velké, že na komunikaci se bude muset vymyslet zcela nový protokol než je IP.

(Jen na Mars je to někdy 56 miliónů a někdy 400 miliónů kilometrů, takže zpozdění signálu je cca 3 do cca 22 minut. Dovedete si představit jen TCP handshaking? Nehledě na to, že zkrz Slunce se stejně komunikovat nedá, takže komunikace by stejně probíhala po síti družic, takže zpoždění by ještě narostlo.)

IPv6 nám na Zemi bude tedy stačit opravdu hodně dlouho, netřeba se bát.

[Kit]

Není nutný jiný protokol, IP bude vyhovovat i pro Mars. Jen místo TCP budeme muset používat něco jiného, protože ten TCP handshake si fakt představit nedovedu. Budou se muset prodloužit pakety - IPv6 s tím počítá.

[Filip Jirsák]

Nebyl by pro Mars lepší nějaký streamový protokol? U paketů je dobré, že se na každý dá odpovědět jednotlivě a každý může jít jinou cestou. Jenže asi nebudu posílat paket, abych se za 40 minut dozvěděl odpověď "Cože?" (viz dialog Jasoně a Drsoně). A kudy navázat spojení Země - Mars je také jasné docela dlouho dopředu, a nemá smysl se najednou z ničeho nic rozhodnout vysílat jinudy.

[ebik]

No, já myslím, že to bude většinou spíš vypadat jak za starých časů: obsáhlou zprávu předáte k odeslání (progam vyděrujete na pásku a předáte obsluze mainfraimu) a po čase vám příjde zpět obsáhlá odpověď (obsluha přinese vyděrovaný výstup programu). Prostě budou se posílat celé zprávy ("obrovské packety") k dávkovému zpracování.

[Sten]

+1. Mimochodem nemusíme pro to chodit na Mars, podobné systémy se vyvíjejí a používají pro internet do málo obydlených odlehlých míst či na malé lodě (kde si nemohou dovolit platit satelitní připojení).

[lertimir]

Nebo spíše něco jako RSCS sítě BITNET/EARN. Jen pro osvěžení paměti BITNET neměl interaktivní komunikaci jen zasílání mailů nebo souborů. A existovala ftpmail gateway do níž jsi poslal mail s sadou příkazů FTP protokolu a po čase přišla mailem odpověď s výpisem do terminálu a pokud byl součástí i get příkaz tak i soubor zakódovaný UUENCODE.

Hlavní výhoda byla uřízení poměrně velkého množství informací na mizerných linkách. Každý uzel měl pro každou linku frontu souborů k odeslání s prioritizací, takže krátké soubory předbíhaly ve frontě a v podstatě linka jela na 100% kapacity pořád nebo dokud frontu nevyřídila.

[Kit]

Streamový protokol přece také běží nad IP. Nad IPv6 poběží také.

[Petr Tomášek]

To je jednoduché: IPv6 je překombinovaná a přeinženýrovaná sračka, která ani přes neustálé vydávání nových RFC pořádně nefunguje (viz např. patička).

Může za to naprosto idiotský vývoj, kdy se do vývoje protokolu sralo tolik lidí, že se namísto jasného návrhu kombinují naprosto protichůdné myšlenky, o tom, že k některým úkolům existuje několik různých řešení, ani nemluvě. Prostě bordel větší než v české státní správě...

Takže nepřekvapí, že na začátku vývoje IPv6 byli všichni podělaní z toho, že bude adres málo, tak navrhli 128 bitů. Pak se zjistilo, že to vlastně až tak málo není, tak nějaká „chytrá“ hlavička vymyslela způsob, jak tento adresní prostor spolehlivě promrhat...

[Sten]

Poslední věta jasně dokazuje, že o vývoji IPv6 nevíte v podstatě nic, protože už na začátku vývoje se začalo s tím, že bude 64 bitů sítí, ne 128 bitů adres.

[Sten]

Mimochodem četl jste vůbec ten článek, co máte v patičce? Kromě toho, že obsahuje několik podivných argumentací (např. používání privacy extensions na serverech — WTF?), obsahuje také celkem jasné sdělení, že ty problémy způsobuje to, že jejich routery IPv6 pořádně neumí a že Intel má vadné ovladače.

[pavlix]

To je jednoduché: IPv6 je překombinovaná a přeinženýrovaná sračka, která ani přes neustálé vydávání nových RFC pořádně nefunguje (viz např. patička).

Ono není moc bezpečné ani provozovat tu IPv4, ale to není dostatečně lukrativní téma.

Takže nepřekvapí, že na začátku vývoje IPv6 byli všichni podělaní z toho, že bude adres málo, tak navrhli 128 bitů. Pak se zjistilo, že to vlastně až tak málo není, tak nějaká „chytrá“ hlavička vymyslela způsob, jak tento adresní prostor spolehlivě promrhat... „

Toto je jediná část komentáře, která se nějak týká dělení adresního rozsahu, je střelená od boku a nesmyslná. Doufám, že to Petr označil jako řešení omylem, to není tlačítko like ve stylu facebooku.

[j]

Tvoji rodice spolehlive promrhali sanci nesplodit takovy individuum ...

IPv6 resi vyhradne a pouze to, co se resilo od pocatku v IPv4 a casto to bylo zcela neresitelne. Mimo jine, fragmentaci prostoru (ja vim, to je sprosty slovo), ktera kvuli tomu, ze adresy uz par patku proste nejsou, je cim dal horsi.

[pavlix]

Pokud jde o rozvržení, tak jak už se tu psalo, jen část toho celého rozsahu slouží k přidělování adres popsaným způsobem a tato část je v současné době dostatečně velká, aby se mohla používat velkoryse a zabránilo se tak přílišnému drobení rozsahu, se kterým naopak problémy kvůli velikosti globání směrovací tabulky jsou.

Vnuci budou pravděpodobně z hlediska infrastruktury ve zcela jiné situaci a tak nemá smysl se to snažit nějak moc předvídat. Pokud se jim IPv6 bude tou dobu ještě hodit, ukrojí si nový kousek a navrhnou si nové schéma, které bude vyhovovat jejich potřebám. Výhodou bude, že v takovém případě nebudou muset měnit celou infrastrukturu jako je tomu u IPv4.

Tedy vůbec nebudou muset řešit to samé a je dost možné, že budou i celkově v jiné situaci, kterou nejsme schopni předvídat.

[j]

Koukam dalsi co si neumi precist ani trivialni clanek nalezitelny behem 10s ....