<div><div dir="auto">Spot on. Excellent analysis and great job breaking down the facts.</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 6, 2020 at 06:46 Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Jan 4, 2020, at 12:41 , <a href="mailto:hostmaster@uneedus.com" target="_blank">hostmaster@uneedus.com</a> wrote:<br>
> <br>
> I understand that there might have been some poor choices made with IPv6 in regard to address allocation that might lead to a future exhaust.  The main one is the 64 bit network and 64 bit host decision, considering that it was based on 48 bit ethernet OUI's. I think it should have been 80 bits of network and 48 bits of host instead.  Even in the largest of networks, 48 bits is clearly overkill.  Having the current /64 is clearly excessive.<br>
<br>
This fails utterly to consider the true history of the 128 bit decision.<br>
<br>
Prior to the decision to incorporate EUI-64 addressing into the process, the most likely address size for IPNG (prior to being given version number 6) was 64-bits. The additional 64 bits were added to the address fields specifically to accommodate this. At the time, it was believed that EUI-48 addresses were approaching shortage and that the IEEE was likely to make future versions of ethernet with EUI-64 identifiers built into the interfaces. Also at the time FDDI was shipping with EUI-64 baked-in addresses.<br>
<br>
The algorithm commonly attributed to IPv6 (placing ff:fe between the OUI and ESI portions of the address and turning on the locally-generated (0x02) bit) is actually the IEEE specification for converting an EUI-48 MAC to an EUI-64 address.<br>
<br>
> Other decisions like giving every node a /48 also add to the greater possibility of exhaust at some future time. Many players have already decided to assign less than a /48 to their customers by default.<br>
<br>
I can’t see any reason to give every node a /48 and I’ve never seen anyone do this. I have seen every end-site getting a /48 and I think that’s perfectly valid. Let us consider that there are roughly 7 billion people in the world. Given that the number of end sites (physical structures or tenants in multi-tenant structures) is unlikely to exceed 10x population, let’s allow for a doubling of the population to 14 billion. That would be 140 billion total end sites in the world.<br>
<br>
There are 35,184,372,088,832 /48s in 2000::/3. That’s 251+ /48s per end site for the entire planet in only 1/8th of the total IPv6 address space.<br>
<br>
> However, unlike the situation of IPv4, there is still plenty of time to correct this.  Currently only 1/16 of the address space is currently used for global addresses.  When it comes time to assign the next 1/16 of space, we could always tighten up the standards, leading to vastly more addresses being available per 1/16 block. Adoption of an 80/48 split by existing players would vastly expand their holdings.  Also, adoption of only providing a /48 upon request and defaulting to /56 or /60 can also vastly expand holdings as well.<br>
<br>
Not sure where you got that statistic of 1/16h. There is 1/8th (2000::/3) specified for IPv6 global unicast addressing currently. Far less than half of that has been allocated to RIRs so far. <br>
<br>
I was talking to JJB of Comcast one day discussing why they don’t provide /48s to their customers. His excuse was “If we were to do that, the way our network is structured, we’d need a /12.”<br>
<br>
Think about that… Probably the single largest eyeball ISP on the planet can number their entire customer base in an extremely wasteful manner (Trust me, there is no legitimate method more wasteful than CMTS when it comes to address deployment) within a /12.<br>
<br>
There are what, maybe a dozen providers that come anywhere near that size in all the world. Let’s even say there are 100 of them. Guess what… In 2000::/3, there are 512 /12s, so that still leaves 412 /12s for everyone that isn’t a customer of a humongous ISP.<br>
<br>
> We still have plenty of time while only 1/16 of the address space is being used to address being more conservative in the future.<br>
<br>
I doubt we will exhaust the 1/8th of the address space in 2000::/3 in my lifetime.<br>
<br>
> Does anyone know what is the utilization rate of 2000::/3 is or where this data is being tracked?<br>
<br>
Yes, it is tracked at IANA. I believe two RIRs have received second /12s for a total of 7 /12s allocated from the 512 in the pool. There are also some smaller earlier allocations that have been issued to RIRs from the pool, but IIRC, they total less than a /12 equivalent altogether, so roughly 8/512 or 1/64th of the address space has been issued to RIRs. (This is from memory without research, so feel free to look at the IANA data for verification).<br>
<br>
Owen<br>
<br>
> <br>
> Albert Erdmann<br>
> Network Administrator<br>
> Paradise On Line Inc.<br>
> <br>
> On Sat, 4 Jan 2020, Ronald F. Guilmette wrote:<br>
> <br>
>> In message <<a href="mailto:alpine.LRH.2.21.2001031911040.742@bigone.uneedus.com" target="_blank">alpine.LRH.2.21.2001031911040.742@bigone.uneedus.com</a>>,<br>
>> <a href="mailto:hostmaster@uneedus.com" target="_blank">hostmaster@uneedus.com</a> wrote:<br>
>> <br>
>>> [IPv6] also brings RIR's<br>
>>> back to their original record keeping role, without having to police the<br>
>>> number of addresses that a member needs.<br>
>> <br>
>> I am not persuaded that this will be the case.  When IPv4 was first<br>
>> promulgated, I do believe that just about everyone felt that there<br>
>> was no way in hell that "the Internet" such as it was, or such as it<br>
>> might become, could ever use up 4 billion addresses.  Now admittedly,<br>
>> things -are- rather different with IPv6, where the number of addreses<br>
>> is a lot closer to the number of elementary particles in the Universe,<br>
>> but I do think it is unwise to ever assume that there are any practical<br>
>> limits on man's ability and/or willingness to waste stuff.  In other<br>
>> words, I think that some amount of thoughtful husbandry of the resource<br>
>> will always be needed.<br>
>> <br>
>> <br>
>> Regards,<br>
>> rfg<br>
>> _______________________________________________<br>
>> ARIN-PPML<br>
>> You are receiving this message because you are subscribed to<br>
>> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
>> Unsubscribe or manage your mailing list subscription at:<br>
>> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
>> <br>
> _______________________________________________<br>
> ARIN-PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
<br>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Sent from Gmail Mobile</div>