[arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations
owen at delong.com
Sat Apr 18 20:46:46 EDT 2020
> On Apr 18, 2020, at 15:01 , Fernando Frediani <fhfrediani at gmail.com> wrote:
> On 18/04/2020 18:44, Owen DeLong wrote:
>> Handing out a /48 to each end site is a core engineering design that was put into IPv6 for many valid reasons.
>> You continue to rail against it, yet you’ve provided no reason or basis for your claim that it is “an exaggeration” or that it is in any way detrimental.
> Yes /48 to a site absolutely no problem.
A residential customer is just one kind of end site.
From NRPM section 2.10:
The term End Site shall mean a single structure or service delivery address, or, in the case of a multi-tenant structure, a single tenant within said structure (a single customer location).
> To a residential customers is an truly absurd. /56 or /60 is broadly fine for this and you can always treat the exceptions and easily give out a /48 to customers who justify or really have a need of it, like some corporate customers for instance. But not for all indistinctly.
No, it isn’t… For all of the reasons I’ve outlined before and others.
> I am trying not to go too much into this topic because I fear to to divert from the policy discussion. Yes, in order to discuss this we have to put up technical considerations and it's fine, but I guess a more elaborated technical discussion wouldn't be beneficial to this list.
It is a crucial part of the reasoning behind this policy. Were it not for the need for /48s for all, I would not be supporting the policy, so it isn’t a diversion, it’s a central and key part of justifying this policy proposal.
If you’re worried about whether it’s beneficial to the list, feel free to send it to me directly. My email address is in the From: line.
I will even respect your wishes about whether I can quote what you say with or without attribution.
>> In terms of any concerns or fears about running out if we use such an address allocation policy, consider the following:
>> 1. Current earth population is approximately 7,000,000,000 (7e9).
>> 2. Let’s assume that within the lifetime of IPv6 we are somehow able to double that population to 14e9.
>> 3. Let’s further assume that each individual resides in a solitary end site (average density is 2.3 humans per household).
>> 4. Let’s also give each individual a separate /48 for their place of work and an additional /48 for their share of the various
>> services and companies they communicate with as well as network infrastructure they use.
>> 5. If we bake in all of those exaggerated assumptions, we need a total of 42e9 /48s.
>> 6. There are 2^45 /48s in 2000::/3 (the current IETF/IANA designated IPv6 GUA pool (which can be expanded several times).
>> 7. 2^25 is 35,184,372,088,832 (more than 35e12).
>> 8. So, in fact, without exhausting the current pool of address space, we can give every individual on earth 6 /48s and we
>> still only consume 0.1% of 1/8th of the address space, leaving 99.9% of the current 2000::/3 still available.
> I never worry about running out of IPv6 addresses. This isn't really the issue.
> We must use them reasonably and intelligently and as mentioned above nowadays a /48 for a residential customer is way too much and the vast majority will not use even a tiny portion of it, even in a near future. I'd rather the technologies to develop around the usage of a for example a /56 which are 256 x /64 networks and still a lot for a residential proposes. Again, if really necessary it's not hard to give out /48 to someone who justify for *real needs* not for *perhaps in the future*.
A /64 is way too much too by that reasoning. I mean what residential (or even business) will ever use even a tiny portion of 18+ quintillion IPv6 addresses?
Your logic is flawed and it ignores the design principles of IPv6.
If you believe that what you are saying works in the real world, you are sadly mistaken. ISPs will not give /48s to residential customers who ask for them unless that’s the standard size they give to every residential customer. Residential internet access is a volume business that depends on avoiding one-offs and custom solutions in order to be profitable. What you get is what you get. Don’t like it, go buy your internet access from their non-existent competitor.
If minimal end-site assignments to residential customers becomes the norm, then that will define software development into the future. I can prove this with modern day examples…
Once upon a time, applications were developed on the basis that each end host was uniquely addressed and could be reached simply by sending a packet to that end host. Today, applications are built with the built-in assumption that you can’t reach back into a residential network except through a rendezvous host on the outside.
Consider for example, a popular video recorder. They have an application that supports out of the home streaming. It will not, however, connect directly to your DVR and stream from it. It insists on working through one of their rendezvous hosts because it is built to the lowest common (NAT) denominator of modern residential access.
Consider a popular company that makes thermostats and smoke detectors. There is no way to access them directly even from within your home network. You must work through their cloud service. Why? Because they operate and code to the lowest common (NAT) denominator and assume that they cannot provide a consistent experience outside of the home as inside unless they require rendezvous hosts.
If we want to see these new technologies get developed, then we must make the platform that can support them ubiquitous first. The web wasn’t built first to enable deployment of the internet… It very much happened the other way… The internet existed and the web was a clever application to take advantage of this existing infrastructure. Now, the popularity of the web led to greatly expanded infrastructure which in turn led to a greatly expanded web with even more capabilities. So yes, there is some extent to which the growth and improvement of the applications and more stringent application requirements does feed back into investment in infrastructure. Nonetheless, unless there’s a really good reason to do it, crippling the infrastructure simply because the applications to take advantage of it do not yet exist is, in short, the best way to ensure that those applications never emerge, or, if they do, it takes considerably longer and costs considerably more.
> Otherwise in a few years someone will start to propose to give out /32 to residential customers because, otherwise this may limit innovation. Sorry I cannot agree with this reasoning.
It’s been 25+ years and nobody has proposed more than a /48 for residential customers. Everyone recognizes that there are less than 4 billion usable /32s and more than 4 billion end users. You’ve just boiled your entire argument down to a reductio ad absurdum of the classic slippery slope where no slope exists, the surface is not slippery, and there has never in 25 years so far been ay suggestion to move the boundary left of /48.
In short, you are very much suffering form IPv4-think, whether you realize it or not.
More information about the ARIN-PPML