[arin-ppml] Proposal - Remove Initial Small Assignment Requirements for IPv6

David Farmer farmer at umn.edu
Mon Sep 13 13:32:11 EDT 2021


The intent behind section 6.5.8.1 is not to conserve IPv6 address space but
to conserve slots in the IPv6 route table, AKA the default-free zone. The
abundance of /48s and /44s, or /40s, /36s, /32s for that matter, are
irrelevant, there is only a finite number of routing slots available. BGP
multihomed end-users will use a routing slot regardless of the source of
the address space they use, so it is best if it comes from an RIR. However,
single-homed end-users can be aggregated by their provider, yes this comes
at a cost of renumbering for those end-users, but eliminating renumbering
for those end-users comes at a cost of an IPv6 routing slot for the entire
Internet. Therefore the cost of renumbering born by the end-user has to be
balanced against the cost of a routing slot born by the entire Internet.

The IPv6 route table is currently growing quite quickly, see the following;
https://blog.apnic.net/2021/03/03/what-will-happen-when-the-routing-table-hits-1024k/
https://blog.apnic.net/2021/01/05/bgp-in-2020-the-bgp-table/
https://blog.apnic.net/2020/01/14/bgp-in-2019-the-bgp-table/
https://labs.ripe.net/author/stephen_strowes/visibility-of-ipv4-and-ipv6-prefix-lengths-in-2019/
https://bgp.potaroo.net/v6/as2.0/index.html
https://www.space.net/~gert/RIPE/weekly/2021/37/

The current 6.5.8.1.c was adapted from the IPv4 requirements when Draft
Policy 2010-8: Rework of IPv6 assignment criteria was adopted.  At that
time IPv4 slow-start was still in effect, and there was still an IPv4 free
pool. When the IPv4 transfer market became the primary source of IPv4
address space, slow-start was no longer practical or functional, and the
initial allocation for IPv4 was changed. However, for IPv4 there is now the
additional cost of obtaining the IPv4 block on the transfer market which
somewhat offsets the removal to slow-start at least to some extent.

So, while I do not support the wholesale removal of section 6.5.8.1, I
would support relaxing, possibly significantly relaxing, or otherwise
modifying 6.5.8.1.c-e which are the current technical qualification for
non-multihomed end-users. Fundamentally, it is not practical to have every
business that could afford to pay ARIN's fees to avoid renumbering and to
receive an IPv6 routing slot. It is not even entirely clear, there will be
sufficient IPv6 routing slots for every end-user that is willing to BGP
multi-home.

Therefore, I believe there needs some kind of technical criteria that a
non-multihomed end-user needs to meet to qualify to receive a Provider
Independent IPv6 Allocation, and it needs to be more than just the ability
to pay ARIN's fees.

And for clarity, I do not support the proposal as written.

Thanks.

On Mon, Sep 13, 2021 at 9:51 AM Larry R. Dockery <lrdocker at co.douglas.or.us>
wrote:

> https://www.arin.net/participate/policy/proposals/2021/ARIN_prop_301_orig/
>
>
>
> I would like to hear community feedback on this proposal. Thank you.
> _______________________________________________
> 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.
>


-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20210913/528bfbcf/attachment.htm>


More information about the ARIN-PPML mailing list