[arin-ppml] Fwd: Advisory Council Meeting Results - December 2019

Sun Jan 5 15:16:00 EST 2020

Spot on. Excellent analysis and great job breaking down the facts.

On Mon, Jan 6, 2020 at 06:46 Owen DeLong <owen at delong.com> wrote:

>
>
> > On Jan 4, 2020, at 12:41 , hostmaster at 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.742 at bigone.uneedus.com>,
> >> hostmaster at 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 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.
> >>
> > _______________________________________________
> > 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.
>
> _______________________________________________
> 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.
>
-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20200106/a444e852/attachment.htm>