<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 05/01/2020 15:26,
<a class="moz-txt-link-abbreviated" href="mailto:hostmaster@uneedus.com">hostmaster@uneedus.com</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:alpine.LRH.2.21.2001051221520.27054@bigone.uneedus.com"><br>
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.
<br>
</blockquote>
<p>Fully agree with this view for quiet a while and find weird some
'recommendations' of /48 for all.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:alpine.LRH.2.21.2001051221520.27054@bigone.uneedus.com">
<br>
<br>
On Sat, 4 Jan 2020, Martin Hannigan wrote:
<br>
<br>
<blockquote type="cite">
<br>
<br>
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
<br>
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
<br>
is unknown. Do we need to be responsible? Yes. Do we need to
worry about every little detail for 2050? No.
<br>
<br>
We’re operating networks today with typically three to five year
horizons. Let conditions on the ground do their job.
<br>
<br>
YMMV, and warm regards,
<br>
<br>
-M<
<br>
<br>
On Sat, Jan 4, 2020 at 15:41 <a class="moz-txt-link-rfc2396E" href="mailto:hostmaster@uneedus.com"><hostmaster@uneedus.com></a>
wrote:
<br>
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 class="moz-txt-link-rfc2396E" href="mailto:alpine.LRH.2.21.2001031911040.742@bigone.uneedus.com"><alpine.LRH.2.21.2001031911040.742@bigone.uneedus.com></a>,
<br>
> <a class="moz-txt-link-abbreviated" href="mailto:hostmaster@uneedus.com">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 class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
<br>
> Unsubscribe or manage your mailing list subscription
at:
<br>
> <a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
<br>
> Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">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 class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
<br>
Unsubscribe or manage your mailing list subscription at:
<br>
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
<br>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
<br>
<br>
<br>
<br>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
</body>
</html>