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

Sun Apr 19 10:16:31 EDT 2020

hi/bonjour, 

+1 with @JORDI [..] strategy, increase IPV4 cost (even if there is a black market of opportunities effect of those can deal) and have an affordable price for IPV6. That could be fix for a "transition period" of 3 or 5 years to manage ROI of investors. 

sorry if my sharing is out of the box, i'm new and don't really know all exchanges rules 

regards and stay safe at home from people under lockdown program 

regards from Guadeloupe, French caribbean 

-- 
Betty FAUSTA— CEO IPEOS I-Solutions 
Mobile: +590 690 497 309 
Twitter/Instagram: @betfau 

www.ipeos.com | www.ipeos.net 
Sales: +590 590 228 020 - info at ipeos.com - Fax (0)972 337 124 
Hotline: +590 590 227 217 - https://support.ipeos.com 
[ https://docmail.apps-ipeos.com/ | Découvrez la messagerie collaborative par IPEOS  ] 

De: "JORDI PALET MARTINEZ via ARIN-PPML" <arin-ppml at arin.net> 
À: arin-ppml at arin.net 
Envoyé: Dimanche 19 Avril 2020 05:16:12 
Objet: Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations 

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: 

    1. 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 … 
    2. I want to make sure that the “cost” of each customer prefix is as lower as I can. 

I think we should do this: 

    1. 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. 

    1. The fee structure for IPv4, needs to be “disconnected” from the IPv6 one. IPv4 must become more expensive. IPv6 must become cheaper. 
    2. 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. 

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. 

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 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. 

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. 

Each /3 has 35.184.372.088.832 /48’s. 

Assuming that we are so terrible with the utilization of IPv6, that we waste 50% of it, we have only 17.592.186.044.416 /48’s . 

Assuming that in the earth we can get 2^35 inhabitants ( 34.359.738.368). 

Assuming that each person lives 100 years and we don’t recover the IPv6 space when they are buried. 

If we give each person a /48, then we have sufficient number of them for the next 51.200 years. 

If we give each person 4 /48’s, then we have sufficient number of them only for the next 12.800 years. 

If we start using the other 7/8 of the addressing space, then we have IPv6 for the next 409.600 or 102.400 years (depending on if we provide a single /48 or 4 of them). 

I know those figures look an exaggeration, but they are just numbers. The issue here is that we need to understand that the next big “problem” in Internet is not the number of addresses (even if addressing plans need to be done in such way that they are not wasteful), but may other issues to come. 

See [ https://tools.ietf.org/html/draft-palet-v6ops-rfc6177-bis-02 | https://tools.ietf.org/html/draft-palet-v6ops-rfc6177-bis-02 ] . I need to update it! 

Regards, 

Jordi 

@jordipalet 

El 18/4/20 10:42, "ARIN-PPML en nombre de Fernando Frediani" < [ mailto:arin-ppml-bounces at arin.net | arin-ppml-bounces at arin.net ] en nombre de [ mailto:fhfrediani at gmail.com | fhfrediani at gmail.com ] > escribió: 

On 18/04/2020 05:26, Owen DeLong wrote: 

... 

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. 

Thankfully it is not ! 

BQ_BEGIN

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. 

BQ_END

And he is right. I still fail to understand from where this idea of giving residential customers a /48 came from. And this is not thinking with IPv4's mind really. 

BQ_BEGIN

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. 

BQ_END

Well, I hear this every time I talk against this "/48 for all" idea. And I don't think because of this justification 'we have plenty so let's give them' should be broadly and always applied. Give people whatever is reasonable for their usage, but not a tremendous exaggeration. And a /48 for a residential customer is an exaggeration that will hardly ever be used. If one day this changes we can adapt to the new scenario. 
BQ_BEGIN

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. 

BQ_END

I can see the intents of this proposal specially for point 2 and perhaps there are adjustments to be done, but certainly not with the idea of giving /48 everywhere in mind. 

Fernando 
BQ_BEGIN

_______________________________________________ 
ARIN-PPML 
You are receiving this message because you are subscribed to 
the ARIN Public Policy Mailing List ( [ mailto:ARIN-PPML at arin.net | ARIN-PPML at arin.net ] ). 
Unsubscribe or manage your mailing list subscription at: 
[ https://lists.arin.net/mailman/listinfo/arin-ppml | https://lists.arin.net/mailman/listinfo/arin-ppml ] 
Please contact [ mailto:info at arin.net | info at arin.net ] if you experience any issues. 

BQ_END

_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. 

********************************************** 
IPv4 is over 
Are you ready for the new Internet ? 
http://www.theipv6company.com 
The IPv6 Company 

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. 

_______________________________________________ 
ARIN-PPML 
You are receiving this message because you are subscribed to 
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). 
Unsubscribe or manage your mailing list subscription at: 
https://lists.arin.net/mailman/listinfo/arin-ppml 
Please contact info at arin.net if you experience any issues. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20200419/27da3862/attachment.htm>