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

[Owen DeLong]

> On Apr 19, 2020, at 02:16 , JORDI PALET MARTINEZ via ARIN-PPML <arin-ppml at arin.net> wrote:
> 
> LACNIC and AFRINIC have similar problems in the fee structure that doesn’t incentivize the right deployment of IPv6. I’ve already made proposals to the relevant boards to change that (it is not a matter of policies in those cases).
>  
> Many management departments of ISPs make the numbers about the right prefix for customers, not according to technical reasons, but to:
> By default, I get a /32 without justification (in all the other RIRs), done, this must work for any number of customers. Even if I give them a single /64 …
> I want to make sure that the “cost” of each customer prefix is as lower as I can.

True.


> 
> I think we should do this:
> The cost of “every” /48 out of a /40 must be proportional to the cost of “every” /48 out of a /40, /36, /32 and so on. It makes a lot of sense that as larger is the block that you get from ARIN, the proportional cost of each /48 gets cheaper and cheaper. You can do the same “proportionality” with each /128, /64, /56, or whatever. It is not related to the size of the prefix you provide, just having some symmetry.
> Right one in ARIN, if you assume that you’re using a /48 for each customer you pay for each /48 out of each /40, 0,97656 USD, out of a /36 0,12207 USD, in the case of the /32 0,01526, and in the case of the /28 0,00191 USD. I think the “jump” in between each category and the following ones is not good, especially for the smaller ISPs.

We already have this effectively.

For every 16x increase in number of /48s, your fees double, so your cost per /48 goes down by 87.5% each time you increase the size of your allocation by one nibble.

> The fee structure for IPv4, needs to be “disconnected” from the IPv6 one. IPv4 must become more expensive. IPv6 must become cheaper.

Unfortunately this isn’t economically sustainable…

RIRs are not-for-profit organizations that are (supposedly) operating on a cost-recovery basis. If you make IPv4 artificially more expensive, you have legal problems.

If you make IPv6 artificially less expensive, you have economic problems.


> If an ISP is doing a right addressing plan and provides the justification for it, even if it is providing /48 to every customer (including residential customer) that should be supported. In fact, I always tell my customers, you must go for /48 and make persistent prefixes to customers (unless they move to a different location). RIPE-690 provides explanations for that.

That’s great… It’s really the best way to do things.
 
> However, the problem is probably better resolved by the board, making a better fee structure than by a policy. Policy may help to facilitate the usage of /48, but if we also change the fee structure it will be much logic.

I don’t think there is anyone, including those of us who are advocating for the policy who disagrees here. Unfortunately, so far, our repeated attempts to get the bard to address this have not resulted in a useful resolution, so now we look at policy as the art of the possible.
 
> The case about $CABLECO it is clearly a *BAD* designed addressing plan. I still see lots of people doing *terribly bad* addressing plans with IPv6, and there is no need for that. You can still provide a /48 for each customer, even for millions of customers, and still not *waste* a lot of addresses and no require a complex interior routing setup. Many documents and trainings do a really really bad work in that. I’ve started several months ago, to write a BCOP for telling people how this can be done correctly, but I’d not the sufficient time/tranquility to finish it. Hopefully I can do it soon (happy to get in touch, in private, with other people that is interested in contributing to it).

I wouldn’t say it’s a *BAD* designed addressing plan so much as a combination of unnecessarily lazy pragmatism and failure to consider longer-term implications.
 
> I believe it is rare the case where an ISP may need /16, but because they need to justify it, and I’m sure ARIN will be stricter with a justification for a /16 or /20 than for a /32, I think this restriction should not be put in place. If there is a single case, we must support it, otherwise, we are asking that ISP to provide customers a smaller block that what he will like to do.

Will it be rare? Of course, as it should be. Are there ISPs who should have no trouble justifying a /16 or even several /16s? Absolutely. I can think of probably 3 or 4 in the US alone that I have no trouble envisioning getting at least 8 if not 16 /16s.

Point is, however, if you extrapolate that to the rest of the world, the US is roughly 5% of world population so 20x that is still only 80 /12s given out to mega-ISPs.
 
> Giving each “human” (not household) a /48 is perfectly valid. There is no IPv6 scarcity. I’ve done this numbers several times, here is one more.

It might work mathematically, but I don’t see assigning addresses to people vs. end-sites as being particularly practical from an implementation perspective. That’s why I phrased my overblown example as assuming only 1 person per household.

Owen


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