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...