[ppml] Those pesky EUI-64's causing a shortage of IPv6 space (Was: [address-policy-wg] Those pesky ULAs again)
Paul_Vixie at isc.org
Paul_Vixie at isc.org
Mon Jun 4 13:15:47 EDT 2007
- Previous message: [ppml] Those pesky EUI-64's causing a shortage of IPv6 space (Was: [address-policy-wg] Those pesky ULAs again)
- Next message: [ppml] Those pesky EUI-64's causing a shortage of IPv6 space (Was: Those pesky ULAs again)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> But why would anybody want to 'ban' EUI-64 configured addresses? because if it remains in the standard, then everybody will have to support it and networks will have to be allocated on /64 boundaries for all of the yet-unborn IPv6 capable SNMP-monitorable door knobs. > Then again, on the other side, there are 536870912 (500 million) /32's in > 2000::/3 alone. Which will really not easily fit in any routing table of any > sort (but please prove me wrong ;) > > Oh and when 2000::/3 is full, we can always pick one of the other 7 /3's > which are not being used yet and 'try again'. Enough for even my kids their > kids and their to play with. agreed, and this is why i consider ULA to be a silly idea. since we have more IPv6 space than we can ever route, why would we mark any allocations unroutable, even if we know what "routable" meant? i can see a need for policy around giving each minimum allocation size its own IPv6 address range, so that those of us who only want to accept TE routes from our peers, can filter them out of our transit tables. but i cannot understand why we would declare that some allocations were never supposed to come into the DFZ (breidbart's "the internet") at all, given that there's no way we could ever route all the /32's we could allocate.
- Previous message: [ppml] Those pesky EUI-64's causing a shortage of IPv6 space (Was: [address-policy-wg] Those pesky ULAs again)
- Next message: [ppml] Those pesky EUI-64's causing a shortage of IPv6 space (Was: Those pesky ULAs again)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the PPML mailing list