Vlákno názorů k článku Proč 18 trilionů adres domácnosti nestačí od Michal - Problém je samozřejmě v tom rozdělení 64:64. Celý...
-
Článek je starý, nové názory již nelze přidávat.
-
Michal (neregistrovaný)
Problém je samozřejmě v tom rozdělení 64:64. Celý svět se prakticky musí adresovat pomocí prvních 61 bitů a na jeden síťový segment, kde je nezřídka jen hrstka počítačů, se pak vyplácá těch druhých 64 bitů.
Chápu že první implementace autokonfigurace takhle byly navržené, ale za posledních 15 let se přímé mapování z MAC adresy už stejně opustilo a teď není důvod proč nějak předepisovat fixní velikost síťové masky v segmentu.
Tohle se mělo už dávno opustit a začít podporovat jakoukoliv velikost segmentu. Nechápu proč se toho 64:64 rozdělení tak zuby nehty drží...
-
snajpa (neregistrovaný)
Souhlasim, ze by se mohlo pouzivat misto EUI64 neco mensiho, ale. Kdyz to nebude aspon cely unikatni kus adresy rozhrani, tak to zavadi povinne do kazde podsite konfiguracni stav. Protoze i kdyz nechci nic nastavovat, chci vedet, jakou adresu bude pocitac mit i nez ho vubec zapnu - MAC adresa byva videt nekde v papirech okolo, nebo na nalepkach na zarizeni. Kdyby to melo byt min, nez 47 bitu v Ethernetove siti, hrozi mi adresni kolize. A tem bych se rad v sitich vyhnul :)
-
Petr M (neregistrovaný)
Běž už s MAC adresou někam.
MAC adresa je jenom identifikátor na MAC vrstvě (L1) pro Ethernet. Co když se ukáže, že MAC adresy nestačí a budou MAC2 adresy s velikostí 52b? Nebo se z Ethernetu přejde na Supernet s MAC adresou 64b a budeš v pr... A co sítě, který už dneska neběží na Ethernetu, třeba PAN na Bluetooth?
-
Honza (neregistrovaný)
MAC adresa je na L2 a ne na L1! L1 je fyzická vrstva. IMHO myslím si, že jednoho dne dojdou MAC adresy, neb 6bytů určitě nebude stačit. Předpokládám, že si pak zařízení budou "losovat" nějakou adresu. Prvně zkusí, jestli je daná MAC na síti aktivní, a pokud ne, tak ji použijou. Jinak podobná věc se už dneska děje s různama IoT hračkama. Ty žádnou MAC nemají, prostě si nějakou vymyslí... MAC adres je pak vcelku dostatek, protože 2^48 zařízení v L2 je dostačující počet...
-
y, (neregistrovaný)
A je tu nejaky problem? Smutny fakt je, kdyby ten split byl 96:32, tak vam stejne poskytovatele budou davat nejmensi mozny (32). To neni podle mne problem splitu, ale mentality. Dokazu si predstavit (pseudo)racionalni vysvetleni toho, proc operatori davaji nejmensi mozne splity -- IMO to neni proto, ze by cekali takovy narust zakazniku, nebo ze by byli lakomi, ale proto, ze, alespon prozatim, se nechteji vazat k nejake komplexnejsi strukture ci segmentaci na jejich siti, castecne protoze se jim o tom nechce premyslet a castecne, ze se boji, ze se dalsi RFC prijde s necim novym a oni uz budou zablokovany (i.e. nebudou moznost to nasadit, at uz "to" je cokoliv).
Jinak kdyz to tak pocitam, tak pokud jsou vyblokovane tri bity, tak to dava jeste dalsich 15 pokusu s rozsahem podobne velikost (ve skutecnosti asi min, protoze ne vsechny tribitove konfigurace budou vyuzitelne, nebo uz jsou rezervovane na neco jineho, ale nechce se mi to zjistovat).
-
Michal (neregistrovaný)
Ten split by nemel byt vubec predepsany a segment by mel moci mit uplne jakkoliv dlouhy prefix. Stejne jako na IPv4 mi nikdo nerika jak dlouhy mam mit na segmentu prefix a DHCP si klidne poradi jak s /20 tak s /30.
Bohuzel do IPv6 se snazili na zacatku nacpat takovych nesmyslu o ktere nikdo nestal ze to bylo slozite na implementaci a konfiguraci. Treba povine IPsec (RFC4292), address roaming (RFC3775), podivne DNS (A6 a DNAME RRs - RFC2874), atd. Vetsina z toho uz je nastesti davno zapomenuta. Taky znovu objevovali kolo takze misto funkcniho DHCPv6 tu mame hybrida mezi ND, SLAAC a DHCP coz jednoduchosti nasazeni zrovna neprospiva.
Proste v IPv6 se snazili vyresit "vsechny" problemy existujici i neexistujici najednou, misto aby resili jen nedostatek adres.
-
SB (neregistrovaný)
Nadáváte tu na zbytečnosti, a sám jednu zavádíte - předěl přes celých 128 bitů komplikuje situaci směrovačům při sporném přínosu.
Tímto způsobem uvažování jsme mohli skončit taky s délkou celé adresy 96, nebo taky 64 bitů. Přece nebudeme plýtvat místem v hlavičkách IP!
Nakonec to vypadá, že hlavním nedostatkem IPv6 je nedostatečná ochrana koncových uživatelů před ISP! -
Petr M (neregistrovaný)
Za sebe, těch /64 je super nápad. Kulatý násobek šířky sběrnice procesoru (x1, x2, x4, nebo x8) pro přidělený prefix, druhý stejně velký číslo obdrží/vygeneruje nějakým algoritmem a je to. Z pohledu aplikace je to furt 128 bitů, z pohled u koncovýho zařízení je jeho část zarovnána a síťová část taky, z pohledu sítě může prostě kulatých 8B na konci ignorovat.
Pokud jako adresu v podsíti použije MAC identifikátor sítě (a to nemusí být Ethernet nebo Bluetooth s 48b), tak se buďto vejde, nebo spočítá 64b hash. Nebo může čísla dostat, vygenerovat jinak, použít náhodný,... Prostě si dělat cokoliv jak za NATem.
A pošuci, co se snaží skrblit, v tom zbytečně dělají hokej z pohledu bezpečnosti. Pokud nastane třeba DDoS nebo hádání hesla, bloknu /64 a mám jistotu, že je odstřelená právě jedna síť. Ne jak v IPv4, kde šmiknutím jedné IP adresy nevíš, jestli jsi odpálkoval jednu přípojku nebo jednu vesnici.
-
Sten (neregistrovaný)
To je hrozné, celý svět se musí vejít do druhé mocniny všech IPv4 adres /s
To rozdělení 64:64 je schválně. Těch 64 bitů by totiž mělo stačit na věky samo o sobě, a takový byl i původní návrh toho, z čeho vzniklo IPv6. Těch druhých 64 bitů se tam přidalo až později, a to jen proto, aby to byla mocnina dvojky, jinak by klidně použili třeba těch 48 bitů. Fixní velikost zůstane, protože RA by se muselo úplně změnit a tím by se rozbily všechny existující implementace IPv6.
