how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria]

On 6-apr-05, at 22:23, Jørgen Hovland wrote:

>> Nobody can transport an IP packet faster than 300000 km/s (well, more 
>> like 200000 km/s in practice) no matter how much money they have.

> You can't proof I can, so telling me what I can and can not based on 
> todays technology isn't too clever.

Ah, has the topic changed to philosophy?

It's as clever as we get to be today... Maybe we're more clever 
tomorrow, but it's like buying a computer: if you wait, you can buy a 
more powerful one for less money. But you have to do without a computer 
while you wait.

So I'll use today's knowledge and not second-guess myself.

> (sidenote: the speed of light is not relevant to how fast you can 
> transport IP packets) It breaks down to time and money and how much 
> you want to spend of it.

No matter how much money you have, you're not going to get a packet 
from London to New York in (say) 10 ms. Sure, if you spend more money 
you can get MORE packets from London to New York in 100 ms, but that's 
not what I call "faster".

>> That's why I proposed "provider-internal aggregation based on 
>> geography" but this fell on deaf ears. Go for the quick fix PI block 
>> and let someone else clean up the mess seems to be the prevailing 
>> attitude.

> I guess it was either a messy idea or the internet isn't ready for it 
> yet.
> (I did hear your speech but never made up my mind about it so I can't 
> tell)

Apparently you're not the only one. I would have expected people who 
want PI to be all for it, because the aggregation is optional and they 
get the PI anyway.

>> A fixed prefix length is very useful because that way you only have 
>> to renumber the top 48 bits when you switch ISPs.

> And you still don't see why I think it's silly?

No.

>> This makes life much easier.

> Well. Easier than what?

Easier than when you get a /48 from an ISP, then move to another ISP 
but now you get a /56.

> The number 48 is arbitrary.

Sure. Anyone trained in computer science knows there are only three 
numbers anyway: 0, 1 and arbitrary...

> Renumbering will be just as easy with any number between 0 and 127 as 
> long as the new prefix is equal or larger to the previous.

So how would that happen if everyone would have their own policy for 
this?

> With dhcp it doesn't matter.

Most people aren't going to use DHCP in IPv6.

> I am aware of rfc3177 saying "a company with several nets gets a /48 
> and allocate /64s for each of their subnets". But let's not mix the 
> word recommendation with must. Why we allocate a /124 on our lan 
> instead of /64 is not of anyones concern but us
 From RFC 3513:

    For all unicast addresses, except those that start with binary value
    000, Interface IDs are required to be 64 bits long and to be
    constructed in Modified EUI-64 format.

In theory I agree with you as IPv6 is supposed to be classless, but in 
practice the above makes sense as it would probably be too difficult to 
support address autoconfiguration with variable subnet sizes.

> and therefore the enforced 48 number is unreasonable.

I don't see why it's unreasonable. At least this way everyone gets the 
same, regardless of which ISP they use. (It's always possible to 
request a bigger block for those who need it.)

> A more specific problem with this allocation policy:
> You would expect that if a /64 is the standard allocation size of a 
> lan, then we can all start filtering on /64s instead of /128s if we 
> want to do per-ipv6 filtering, right?

I don't understand what you're getting at...