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/
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf