[arin-ppml] Policy Proposal: Open Access To IPv6

[George, Wes E [NTK]]

-----Original Message-----
>From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael K. Smith
>Sent: Friday, May 29, 2009 11:57 PM
>To: Member Services; arin-ppml at arin.net
>Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6
>
>- There is at least one major transit provider that will accept nothing more
>specific than a /32.
>- If we continue to inhibit providers' ability to get a /32, they may have
>reachability issues.
>
>Mike

As one of the folks that personally oversaw the liberalization of the IPv6 route acceptance policy at what may still be classified as a major transit provider, I can say that IMO this is not a good basis for an argument in support of standardizing on allocating a /32 to more entities. If all of a major transit provider's customers expect to be able to route smaller blocks than that because, well, that's what they were assigned, they will either modify their policy or lose those customers.
We used to rigidly follow RFC 2772 back in the 6bone days. Customers came to us with legitimate reasons for accepting deaggregates, and we moved down to accepting a /48. At first, we tried to use the strict case listed at http://www.space.net/~gert/RIPE/ipv6-filters.html which keeps track of which blocks are being used for micro-allocations and eventually abandoned it in favor of the loose case because we couldn't keep up with the changes, and there were legitimate reasons for customers to announce deaggregates to us even if they had a /32. Yes, eventually that is going to create routing table bloat, but there's not many other ways to manage multiple sites allocated from the same /32 that aren't connected to each other except via the ISP. We do warn people that if they choose not to advertise an aggregate from at least one site, they may have reachability issues, but that reachability to networks beyond our own is not a guarantee because we don't control their routing policy.

I think maybe the bigger issue is the assumption (based on RFC3177) that each site or sub-allocation needs to be able to have a /48 allocated to it, and therefore multi-site locations automatically justify a /32 or larger so that they can allocate contiguously. I'm not aware of too many applications that will get anywhere NEAR allocating an entire /48's worth of hosts per site even with a lot of subnets. Beyond routing rules which may or may not exist in the DFZ, I certainly can't come up with many reasons why you would need something larger than /48 for a network that would have trouble meeting the current 200 sub-allocations requirement. Perhaps what we should be doing is simply expecting people to more efficiently use /48s. I'd like to hope that the IPv6 addressing debate has evolved a bit since 2001 when 3177 was written, but even if you still assume allocation of a /64 to each host, that's 64K hosts (aka a /16 of IPv4 space). As Bill Herrin pointed out in a previous mail, a /48 is 16 /52's or 256 /56's or 4096 /60's. Even the smallest of those sub-allocations gives you 16 subnets.

No, deaggregation of /48s doesn't solve the routing table bloat problem, it probably exacerbates it, but at least it uses addresses more efficiently. I'm hearing a scary amount of language akin to "we'll *never* run out of IPv6 addresses even if we use /32s like /24s". Echoes of the quote about 640K of RAM attributed to Bill Gates seem appropriate here. Yes, IPv6 has a mind-bogglingly large amount of space, and yes everyone who wants IPv6 space should be able to get it from some source. Giving everyone a /32 is not the way to solve the problem being presented (I think) by this policy proposal - that not everyone who wants IPv6 can get it today. I'd rather not be thought of as one of the folks that caused us to have to move to IPv8 (256 bit addresses) because we didn't use any care in allocating space or expecting people not to waste it simply because we couldn't get our heads around how big it was or was not.

Thanks,
Wes

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.