Ne, naopak - já si myslím, že ta koordinace má naopak usnadnit propojování - v rámci CZFree.
IPv6 svým přístupem a svými doporučeními tak nějak trochu "zhora" nařizuje, jak velké celky mají vznikat, jak velké celky mají mít autonomii. Je to možná jenom takový paranoidní pocit, ale je to tak.
Pokud bude CZFree předem připravené na propojení, tak proč ne. Rozdělování rozsahu je skutečně pitomost. Sekvenční zábor je naopak asi zbytečný - stačí asi generovat ty rozsahy náhodně - ale pak je poctivě oznámit do fóra a do CZF RIPE,a hlídat unikátnost nově vygenerovaných rozsahů. To nám myslím nikdo zakázat nemůže.
Co se týče vlastní 128bitového čísla a mé dynamické délky adresy v GFNP: ano, mám za to, že "transakční náklady" budou u 128bitového čísla příliš velké. Ve skutečnosti se to už nebude používat tak globálně jako IPv4 - nebude to vhodné pro strojové zpracování na páteři. Výrobci routerů pro páteřní sítě přišli už teď se speciálními metodami "balení" packetů do optimálně zpracovatelných obálek - je to "něco jako" L2, "něco jako" ARP tabulka. Prostě proprietární záležitost, ale zároveň reálný program pro reálné železo - do kterého výrobcům autoři "virtuálních" sí?ových protokolů nemají co kecat.
Mám určitý nejasný pocit, že 64-bitové sí?ové adresy by mohly stačit nejen pro adresování počítačů v síti - ale i pro budoucí potřeby distribuovaných sí?ových aplikací. Přímé mapování 64-bitových adres na 64-bitové adresy v paměti a 64bitové integery předávané přímo CPU má opravdu hodně výhod - a není důvod to nezkusit...
Té variabilní délky adresy se podle mě není potřeba bát. V praxi provozované implementace by prostě byly naprogramované ve strojovém kódu maximálně tak 8x - odlišně pro adresy délky, 1, 2 až 8 bajtů - ale pokaždé optimálně. Protože moje sí? se mezi těmito stavy nepřepíná náhodně a zvláš? často - ale jen v důsledku speciálního druhu instrukce, na který bude čekat vždy ten specializovaný kód - tak není potřeba to nějak zvláš? řešit.
Dovedu si představit, že délka adresy globální sí? by se měnila třeba několikrát během dne - s tím, jak by lidé zapínali a vypínali počítače v časových pásmech s největší hustotou zalidnění. Mít zbytečně dlouhou délku adresy v době, kdy svítí slunce nad Pacifikem a kdy většina planety už nebo ještě chrápe, je podle mě blbost. Může to znamenat až gigabajtové úspory u dat přenesených v nočních hodinách... a v konečném důsledku úspory energie, protože CPU prostě vykonají méně instrukcí a spotřebují méně strojového času. Takže čistě evolučně by se nakonec proměnná délka adresy někdy prosadit mohla...
To ze se ty prefixy prideluji tim pseudonahodnym algoritmem je dobre k tomu, aby byla vetsi pravdepodobnost, ze kdyz se s jinou takovou siti rozhodnu udelat tunel, nebudeme kolidovat. Jakmile se totiz povoli nenahodna generace, lidi si vyberou s velkou pravdepodobnosti par lukrativnich (na pohled hezkych) rozsahu a ostatni nebude pouzivat nikdo (same nuly, same jednicky, sama F, de:ad:be:ef, atd...)
Ja vim, ze se to podle toho RFC "nesmi", ale jen bych tu chtel vyjadrit par myslenek, ktere me vedou k nazoru, ze pridelit si sekvencne nejaky vetsi rozsah by bylo lepsi:
- Jako CZFree nam jde predevsim o to, aby jsme nekolidovali navzajem. To nam paradoxne sekvencni pridel zaruci lepe.
- Kdyz celej ten vetsi rozsah, kterej bychom si prideliili, bude zacinat na nejake nahodne vygenerovane hranici, je prece pravdepodobnost ze budeme kolidovat s nekym jinym uplne stejna, jako kdyz si kazdy cloud vybere svuj vlastni nahodny rozsah.
- Bude jednodussi napriklad nastaveni DNS (jedna velka reverzni zona). Kdybychom si kazdej pridelili svuj vlastni prefix, museji bud vsechny CZF DNS servery vedet o vsech tech prefixech a pro kazdy mit zvlastni zonu, nebo udelame v DNS zonu pro uplne cely ten privatni range, coz je ale zase hloupe pro pripad, ze bude nekdo pouzivat krome CZFree jeste jinou sit na stejnem typu adres
- Stejne tak ruzne filtrovani paketu -- napriklad nekde budu chtit odfiltrovat pakety co nepatri do CZFree, nebo budu chtit na BGP odfiltrovat prefixy ktere nepatri do CZFree -- toto opet je mozne jen se spojitym rozsahem.
Tak, a ted me kamenujte :-)
Je nejaky technicky duvod proc bychom si ten spojity rozsah nechteli pridelit? Je ta podminka v tom RFC snad z nejakeho duvodu, ktery jsem prehledl?
__________________
let's meet on IRC!
#czfree.net/IRCNet (irc.felk.cvut.cz)
#czfree.net/irc.czf
05.12.2005 v 20:50
