Re: IPv6 RIR policy [was Re: IPv6 addresses really are scarce after all]

Thomas Narten wrote:
> [..] There was overwhelming support for the PI to end sites proposal.
> Anyone who was at the ARIN meeting would have to take away two
> things: 1) some people were seriously worried about the long-term
> impact the policy would have on routing table size, and
> 2) there was still an overwhelming sense that PI for end
> sites was needed anyway, to support the requirements of larger
> enterprises. There were even some people who shared _both_ views.
My view on this is that the RIRs have, partially, done the right thing.
A RIR is for allocating internet resources in their region, as such them
providing /48's and up to their members is the right thing to do. That
they have names like "PI" and "PA" for it is IMHO wrong though, they all
should have the same name "Allocation" and the only difference should be
the size that they are allocated in, which is based on the justification
provided by the request that gets sent to them. This would then allow
anybody who can justify the need for address space to get it.

A /48 per 'site' is good, especially in the case of businesses, for
home-usage though, most very likely a /56 will be more than enough. As
such IMHO having 2 sizes, one business, one homeuser, would not be a bad
compromise, otherwise the really large ISP's, eg the ones having
multiple million customers, would need multiple million /48's and then
the address space consumption suddenly really goes really fast. Having
/56's there would slow that down a little bit. A /56 is still 256 /64's,
and I have a hard time believing that most people even on lists such as
ARIN ppml or the various IETF ones will ever configure that many subnets
 at home.

But now something the RIRs should not be doing though is meddling in
what ends up in BGP. Fortunately mostly they do stay out of there, but
unfortunately the allocation policies are based on them. Routing
(currently done mostly using BGP) is something that the ISPs will figure
out. In IPv4 >/24 is filtered out, for IPv6 at the moment it is >/48.
ISPs are running the show there and they can do what they want, and as
long as their customers can reach the sites they need to they will.
They also make up the bulk of the RIR crowd and thus can also set up
most of the policies there, nice monopoly settings are very possible
that way. Fortunately policies are more or less relaxed and as long as
you can come up with some solid business arguments one can get address
space quite easily, still the take up on IPv6 is not very high yet.

The problem with this, at least assumed, is that a certain point the
IPv4 + IPv6 routing tables will 'explode' into millions of routes and
apparently people don't want to upgrade their routers to handle these
over the coming years, which is somewhat understandable. The big
question here is, how quickly will we reach that huge number, and also
which hardware will fall over first; or otherwise said: should we really
be so worried about this. Looking again at those IPv6 takeup numbers,
should we really be worried about routing table explosion in the next
couple of years? IMHO not really, most likely current equipment will be
able to be used for the next couple of years.

Looking at http://www.sixxs.net/tools/grh/growth/ we have surpassed last
years number of allocations and one can also clearly see that ARIN
(blue) took off quite a bit allocation wise, mostly because of their
"PI" /48s.

Still, the total number of prefixes that have been allocated is only
~1600*, thus if every one of them would be announced only 1600 of them
would exist in the BGP tables, (unless folks deaggregate) could be me
but that is far off from the 200k that we have in BGP, or the 300k that
some have internally. Of course internal BGP for IPv6 can become large,
but that is why one should use a /40 per PoP or similar constructs to
nicely aggregate things up.

In the mean time though, there is great working being done on the
Routing And Addressing Mailing List
(https://www1.ietf.org/mailman/listinfo/ram) and some great ideas have
already been shown there. One should also not forget HIP of course and a
variety of other problem statements and solutions.

Greets,
 Jeroen

* = http://www.sixxs.net/tools/grh/dfp/

signature.asc
Description: OpenPGP digital signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf