I did not write this to open a debate on IPv6 exhaustion, but merely to point out that policies could be changed in the future to reduce address consumption within IPv6 if the community found it is needed.

Looking at the IANA assignments of the first 1/16 of the address space, it is highly likely that the next 1/16 assignment may not take place in the next 50 years. Going from a /23 to a /12 for RIR assignments greatly changed the rate of going back to IANA for more.

It is also likely that the policy of many large ISP's to give a /60 or /56 by default instead of a /48 may not be motivated by any attempt at address conservation, but simply to prevent the ISP from having to ask for more v6 space from their RIR. All RIR's including ARIN set policies that require more fees for larger blocks. In other words, it is about saving money. When IPv6 becomes the primary protocol, RIR costs will be driven by their IPv6 holdings, unlike today where most pay on the basis of IPv4 holdings. Giving out smaller blocks by default will save those operators money.

Unlike IPv4, where it was realized that the 32 bit address would be too small and the IPng which became IPv6 was started within 15 years of the beginning of IPv4, we will have a MUCH longer time frame with IPv6. I do not honestly expect any serious discussion at the ITEF or otherwise until more than 1/2 of the available global addresses are in the hands of the RIR's. That point is likely 100's of years down the road.

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Sat, 4 Jan 2020, Martin Hannigan wrote:



This all seems silly to me. #IMHO, IPv4 policy should be geared only mostly 
assuaging operators to get to v6. Total exhaustion is a part of that. Talking 
about v6
exhaustion is probably better suited for the IETF. Either way, we’ll all be 
dead if/when it happens and it is not unreasonable to avoid worrying about a 
future that
is unknown. Do we need to be responsible? Yes. Do we need to worry about every 
little detail for 2050? No. 

We’re operating networks today with typically three to five year horizons. Let 
conditions on the ground do their job.

YMMV, and warm regards,

-M<

On Sat, Jan 4, 2020 at 15: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.

      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.

      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.

      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.

      Does anyone know what is the utilization rate of 2000::/3 is or where this
      data is being tracked?

      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.

Reply via email to