Spot on. Excellent analysis and great job breaking down the facts. On Mon, Jan 6, 2020 at 06:46 Owen DeLong <o...@delong.com> wrote:
> > > > On Jan 4, 2020, at 12:41 , hostmas...@uneedus.com wrote: > > > > 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. > > This fails utterly to consider the true history of the 128 bit decision. > > 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. > > 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. > > > 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. > > 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. > > 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. > > > 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. > > 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. > > 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.” > > 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. > > 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. > > > 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. > > I doubt we will exhaust the 1/8th of the address space in 2000::/3 in my > lifetime. > > > Does anyone know what is the utilization rate of 2000::/3 is or where > this data is being tracked? > > 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). > > Owen > > > > > Albert Erdmann > > Network Administrator > > Paradise On Line Inc. > > > > On Sat, 4 Jan 2020, Ronald F. Guilmette wrote: > > > >> In message <alpine.lrh.2.21.2001031911040....@bigone.uneedus.com>, > >> hostmas...@uneedus.com wrote: > >> > >>> [IPv6] also brings RIR's > >>> back to their original record keeping role, without having to police > the > >>> number of addresses that a member needs. > >> > >> I am not persuaded that this will be the case. When IPv4 was first > >> promulgated, I do believe that just about everyone felt that there > >> was no way in hell that "the Internet" such as it was, or such as it > >> might become, could ever use up 4 billion addresses. Now admittedly, > >> things -are- rather different with IPv6, where the number of addreses > >> is a lot closer to the number of elementary particles in the Universe, > >> but I do think it is unwise to ever assume that there are any practical > >> limits on man's ability and/or willingness to waste stuff. In other > >> words, I think that some amount of thoughtful husbandry of the resource > >> will always be needed. > >> > >> > >> Regards, > >> rfg > >> _______________________________________________ > >> ARIN-PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> https://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact i...@arin.net if you experience any issues. > >> > > _______________________________________________ > > ARIN-PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > > Unsubscribe or manage your mailing list subscription at: > > https://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact i...@arin.net if you experience any issues. > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > -- Sent from Gmail Mobile
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.