[arin-ppml] Fwd: Advisory Council Meeting Results - December 2019
fhfrediani at gmail.com
Sun Jan 5 15:28:46 EST 2020
On 05/01/2020 15:26, hostmaster at uneedus.com 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,
>> On Sat, Jan 4, 2020 at 15: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
>> 48 bits is clearly overkill. Having the current /64 is clearly
>> Other decisions like giving every node a /48 also add to the
>> possibility of exhaust at some future time. Many players have
>> 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.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
>> > promulgated, I do believe that just about everyone felt that
>> > 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
>> > things -are- rather different with IPv6, where the number of
>> > is a lot closer to the number of elementary particles in the
>> > but I do think it is unwise to ever assume that there are any
>> > 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.
>> 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:
>> Please contact info at arin.net if you experience any issues.
> 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:
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML