[address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria

Oliver,

Would you please invest some time into discovering how grownups use 
email? The excessive funny interpunction hurts my eyes.

On 4-apr-05, at 21:10, Oliver Bartels wrote:

>> I'd rather see large routing tables rather than in 10 years time find 
>> we're
>> running out of v6 space.

Whatever we do, we're not going to run out of IPv6 space. Worst case, 
we have to start subdividing /64s and kill autoconfiguration, but that 
way we still have four billion times as many addresses in a single /64 
as in the whole IPv4 internet.

That said, the HD ratio and strange new ways to distribute from IANA to 
RIRs may eat up the bits from 3 - 47 much faster than we could have 
imagined at the time that IPv6 was designed, so we shouldn't waste v6 
space like there is no tomorrow.

Still, the routing table size problem is much more pressing than the 
depletion problem in IPv6 because even if the table size isn't fatal, 
it can get expensive easily, and when it gets fatal there is no way to 
fix it (even if we give up autoconfiguration).

> Well, we will also see routers beeing capable to route more than
> 150K prefixes. We can even see them today.

Well, we're never going to run out of oil either, but at some point 
it's going to be so expensive to get it out of the ground that it's 
easier to leave it there and walk to work.

I'm not sure what the cheapest router is that can handle a full table 
today, but I'm pretty sure it's more expensive than what one that could 
10 years ago cost then (ie a Cisco 2501).

> At these old days when these 64MB routers were designed,
> RAM chips had 4 to 16 MBits of RAM. Today we are talking
> about min. 256MBit SDRAM dies, smaller SDRAM's will have
> their "call for last order" very soon now.

Ah, but if you have N * 2 routing table entries, not only do you need 2 
times the memory, but all else being equal you're going to see 2 times 
as many updates, so assuming you need to search N * 2 entries before 
you can update one (which fortunately isn't the case, the exact math is 
left as an excercise to the reader) you need 2 * 2 = 4 times as much 
memory bandwidth.

It's not just a factor of more memory.

> Again for multiv6: *There won't be a *full* and *unrestricted* 
> solution,
> the we_want_multiv6_but_keep_BGP4 approach has fundamental
> laws of math and computer science against it:

> An *address* is an *address* and is spoken *address*, because it
> addresses something, which means it guides something to a destination,
> which does not mean that it just references something and let's
> some unknown big wonder do the job ;-/

I have no idea what you're talking about here.

> But it is possible, BGP4 is proven with existing products for appx. 
> 500K
> prefixes, if more is needed, I would suggest thinking of an protocol
> update.

And what exactly would that update entail? The problem isn't BGP 
(although BGP has problems for sure) but the fundamental problem that 
if you can't derive the answer you're looking for from the information 
you already have, you'll have to go to the place where the information 
is kept. I.e., you need to search the routing table.

> I do fully agree with Gert:
> "because if IPv6 isn't going to take up soon, it's dead."

I'm not sure how having a new techology available before the old 
technology implodes is a problem.