[arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Owen DeLong]

> On Apr 16, 2020, at 08:42 , John Curran <jcurran at arin.net> wrote:
> 
> On 24 Mar 2020, at 1:20 PM, ARIN <info at arin.net <mailto:info at arin.net>> wrote:
>> ...
>> Reserving /40s only for organizations initially expanding into IPv6 from an initial sliver of IPv4 space will help to narrowly address the problem observed by Registration Services while avoiding unintended consequences by accidentally giving a discount for undersized allocations.
> 
> ARIN tries to provide as much flexibility as possible in dealing with requests, so it is important that the community document the reasoning behind policy language that constrains the choices available to those requesting resources.   ARIN staff will certainly get asked about such restrictions, so we best understand the motivation. 
> 
> For this reason, would it be possible for the advocates of the policy to elaborate (on the list) on the perceived "unintended consequences by accidentally giving a discount for undersized allocations”?   (In particular, if a party specifically sought a /40 IPv6 allocation but they held more than /24 of IPv4, is the desire that ARIN would deny the request if they failed to agree to a larger IPv6 allocation or agree to divesture of IPv4 resources down to the /24 maximum?) 

Frankly, I wouldn’t even want to allow access to this option through divestiture of their IPv4 holdings.

I look at it this way.. Originally, we wanted ISPs to have a minimum /32 in order to maximize aggregation while still providing reasonably good support for handing out /48s to every subscriber end site regardless of size.

Then, because there were unintended consequences of IPv4<->IPv6 fee structure alignment, we put in place a mechanism to allow that down to /36 if the ISP really wanted to do that to avoid the fee increase.

Now, we’re talking about going down another nibble.

A /40 is only 256 /48s and you have to account for the ISPs infrastructure within that too.

For an ISP running their entire customer base on a single /24, that might not have any unintended consequences, but even in that case, there’s the risk that said ISP has more than a couple hundred customers behind that /24 via various forms of address sharing (NAT and worse), in which case a /40 simply won’t provide the desired IPv6 policy outcome of /48s for everyone.

Admittedly, /48s for everyone still isn’t gaining as much traction as we’d like due to a combination of IPv4-think at some ISPs and other reasons I have trouble understanding.

E.G. I once had a discussion with the IPv6 project manager for a major $CABLECO about why they were sticking it to their residential customers with a maximum /60 instead of a /48. His answer perplexed me… He said that the problem was that if they gave out /48s to all their customers the way their network is structured, they’d need a /12. Now I realize that policy only allows ARIN to give out a /16 at a time, but I’m quite certain this particular organization could easily qualify for 16 /16s without any issue whatsoever. When I pointed this out, he just walked away shaking his head.

Now I realize a /12 sounds like a ridiculous amount of space, but if you think about it, this is an organization that has several /8s worth of IPv4, so it’s not actually all that far fetched. Also, I seriously doubt that there are anywhere near 100 organizations with the number of customers this $CABLECO has. There are 512 /12s in 2000::/3 which is just the first 1/8th of IPv6 address space designated as GUA (Global Unicast Addresses). The math works. We have the address space to do this and give everyone /48s without any issue of running out.

So… we have a circumstance of competing tradeoffs in policy:

	1.	We don’t want policy to create perverse incentives to not give /48s to customers. That’s one of the reasons
		for the particular wording of the PAU text in the IPv6 ISP policy (which staff doesn’t do a particularly good
		job of following in my observation).

	2.	We don’t want to create economic disincentives to IPv6 deployment.

This policy is an effort to reduce issue number 2 at the cost of potentially exacerbating issue number 1. We’d very much like to minimize the extent to which that unintended exacerbation of issue number 1 occurs.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20200418/c65b02ef/attachment.htm>