Jeroen, On Jun 8, 2006, at 5:04 AM, Jeroen Massar wrote:
As such every organisation in whatever form will want to have their own address space at a certain point. Unless you want to force NAT down everybodies throat,
I don't think the RIRs are in a position to force anything down anyone's throat. The RIRs exist at the mercy and pleasure of its members. Like NATv4, NATv6 will occur is the market demands it. Given renumbering is hard in IPv6 and IPv6 uses the same routing technology as IPv4, NATv6 is assured.
For current ISP type organisations there should not be a problem for getting a plan for 200 sites.
Yep.
But if you are only your own office and you want your own web/mail/...- servers then you are never going to be that large, even if you plan for it. That is why they need a *seperate* policy, or at least seperate in wording from the current one.
Personal opinion: what was needed was for IPv6 to be finished before we attempted to deploy it. It wasn't. Now we have the challenge of trying to engineer _policies_ to address technical failure. One can argue that there is plenty of routing system headroom and/or we'll fix the technology soon, so it is OK to allocate PI to all and sundry, but people said that about CIDR back in the early to mid-90's. The reality is that it is _highly_ likely that in the future, we'll have to deal with the increased nitrogen content of the pool that we pee in today.
The whole problem with these policies is that they seem more targetted at "Routes" and not at "Address Space".
Exactly. And the reason for this is that IPv6 made the exact same mistake as IPv4 in overloading the address with both routing locator and end point identifier.
Everyone who really needs it thus should be able to get address space.
They can. I think what you meant is everybody who really needs it should be able to get provider independent address space.
But the amount of address space SHOULD measure up to the amount that will actually be used.
This doesn't make sense in the context of IPv6. "Amount of address space" is irrelevant given the lower 64 bits is inconceivably sparsely used by fiat. IPv6 allocations are oriented towards networks not addresses.
I am being a bit mean here as above I state that routing and addressing are seperate.
Unfortunately, IPv6 does not treat them as separate and that, I believe, leads to the difficulty. Ideally, routing prefixes would be allocated to transit networks and end point identifiers would be assigned to end users. These two address spaces can and should be separate, but IPv6 maps both into the same address space. End users would present their end point identifiers to the transit networks for transit services. However, we're not in the ideal, so many of the policies that are being proposed are attempting to paper around the problem.
The /48's are PI, as such these can pop up in the size allocated.
There are 281,474,976,710,656 possible /48s. The routing system can't flat route 32 bits, how is it going to route 48 bits?
There is potential (note that I write potential ;) problem that could arise, being that the routing table size becomes very large.
To be clear, routing table size isn't really the issue. It is routing table thrash. But yes, that is the potential problem and every PI oriented proposal I've seen to date exacerbates the problem.
There is one nice side-effect to this. Lets say that 500.000 allocations will be made. That means that RIPE will receive: 500.0000 * 2000 EUR yearly. That should allow for some good people to get an incentive to build some nice routing setup that also scales to that magnitude...
The problem hasn't been solved with IPv4. What makes you think it'll be solved with IPv6? Rgds, -drc