<div><br></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">We’re operating networks today with typically three to five year horizons. Let conditions on the ground do their job.</div><div dir="auto"><br></div><div dir="auto">YMMV, and warm regards,</div><div dir="auto"><br></div><div dir="auto">-M<</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 4, 2020 at 15:41 <<a href="mailto:hostmaster@uneedus.com">hostmaster@uneedus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I understand that there might have been some poor choices made with IPv6 <br>
in regard to address allocation that might lead to a future exhaust.  The <br>
main one is the 64 bit network and 64 bit host decision, considering that <br>
it was based on 48 bit ethernet OUI's. I think it should have been 80 bits <br>
of network and 48 bits of host instead.  Even in the largest of networks, <br>
48 bits is clearly overkill.  Having the current /64 is clearly excessive.<br>
<br>
Other decisions like giving every node a /48 also add to the greater <br>
possibility of exhaust at some future time. Many players have already <br>
decided to assign less than a /48 to their customers by default.<br>
<br>
However, unlike the situation of IPv4, there is still plenty of time to <br>
correct this.  Currently only 1/16 of the address space is currently used <br>
for global addresses.  When it comes time to assign the next 1/16 of <br>
space, we could always tighten up the standards, leading to vastly more <br>
addresses being available per 1/16 block. Adoption of an 80/48 split by <br>
existing players would vastly expand their holdings.  Also, adoption of <br>
only providing a /48 upon request and defaulting to /56 or /60 can also <br>
vastly expand holdings as well.<br>
<br>
We still have plenty of time while only 1/16 of the address space is being <br>
used to address being more conservative in the future.<br>
<br>
Does anyone know what is the utilization rate of 2000::/3 is or where this <br>
data is being tracked?<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>
</blockquote></div></div>