Je uplne jedno, jak routovaci tabulky vypadaly v minulosti a tudiz jak to mame z tohoto duvodu dnes. Proc by dnesni ipv4 routovaci tabulka nemohla byt proste 2^32 dlouhe pole 32b polozek, kde kazda polozka je gw a cilova ipv4 adresa indexem do tohoto pole? To je 16GB, jestli se nepletu. Tudiz o velikosti tabulky ani o rychlosti prohledavani to neni. Ciste technicky by to urcite slo. V drevnich dobach se ze stejneho duvodu zvladl prechod na classless ipv4 a nebeska klenba se na nas nezritila. Jina vec je, ze ipv4 uz je opravdu prezitek. To jen tak na okraj.
Jinak nekoliduje nahodou dnesni pozadavek na maximalni roztrideni vsech sitovych kramu do separatnich vlan s mechanizmem ipv6 pro delegaci prefixu? Jak pracne je nastavit si subdelegaci casti ipv6 rozsahu od poskytovatele do nekolika urovni vnitrnich segmentu site? Muzou ty kusy ipv6 rozsahu byt ruzne velke?
Dobrý den, vaše úvaha je správná, nicméně se vždy najde najde několik ALE. Typicky totiž nemáte TCAM v routeru v řádech GB, ale MB - dnes mají routery typicky max. 5 milionů prefixů v TCAM (ano, jsou i FP5 s 10 mil. + komprese apod).
Musíte také počítat s tím, že ASBR má několik cest a je potřeba si všechny prefixy, všech cest, pamatovat pro přepočítávání - tj. potřebujete RAM - úplné teoretické minimum pro uložení všech IPv4 + relevantní next-hop je 32GB - k tomu nějaká režie, bavíme se tady pro každý upstream o desitkách GB možná stovkách a jen pro IPv4. Dnes má IPv6 globální tabulka kolem 240tis. prefixů k tomu. Pro TCAM je to cca 6MB navíc bez komprese. Také je potřeba si uvědomit, že typické ASBR ještě musí alokovat TCAM a RAM směrem do ISP, kam v lepším případě ukládá "jen" MPLS tagy, ale třeba také dělá export/import pro zákaznické VRF.
Můj názor je, že zas až tak jednoduché to není a jakékoli drobení jak IPv4, tak IPv6 nepomáhá stabilitě a rychlosti konvergence.