On 05/01/2020 15:26, [email protected] wrote:
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.
Fully agree with this view for quiet a while and find weird some
'recommendations' of /48 for all.
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 <[email protected]> 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
<[email protected]>,
> [email protected] 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 ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected] if you experience any issues.
>
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
