[arin-ppml] Fwd: Advisory Council Meeting Results - December 2019
hostmaster at uneedus.com
hostmaster at uneedus.com
Sun Jan 5 15:49:19 EST 2020
That is why I think a /48 only upon customer or equipment request, and a
smaller number by default is the best overall way to go.
"Upon Request" also includes devices that do dhcp prefix delegation as
well. It would be helpful if the makers of these devices would not
default to always requesting a /48. The devices should ask for the
smallest unit of space based on how many v6 subnets the device currently
serves, and then ask for more if needed.
While those of us here on the list are likely to ask for, and likely to
expand into any /48 we request, the "average" Joe that buys an internet
connection for Netflix and the Web does NOT need a /48 for their couple of
dozen devices. And those average Joes vastly outnumber us, and therefore
setting their default assignment to less can lead to much less waste, and
a lifetime of thousands rather than hundreds of years for IPv6. The
providers also stand to save RIR fees as well by such a decision.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Sun, 5 Jan 2020, Fernando Frediani wrote:
>
>
> 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,
>
> -M<
>
> 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 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.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 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 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.
> >
> _______________________________________________
> 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.
>
>
>
>
> _______________________________________________
> 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.
>
>
>
More information about the ARIN-PPML
mailing list