I forgot to mention that I am OPPOSED to this.
I see the router slots in the DFZ of IPv6 as the limiting factor, and we
should not hand out PI addresses to those that are not actively using them
to multihome on larger networks. I agree with leaving the current
standards that require a minimum number of IPv6 addresses in order to
receive PI addresses.
By default, most providers give out more addresses than anyone needs.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Mon, 13 Sep 2021, Larry R. Dockery wrote:
Thank you for your time in providing this information. This is the best
argument against the proposal.
If this is a significant issue and holds true, then 1) most organizations do
not and should not qualify for PI space. And 2) These orgs should, per the
design recommendation in “IPv6 Address Planning”, use NTPv6 with ULA internally
to avoid ISP lock-in inherent with IPV6 PA space.
This is far better than IPv4 NAT + RFC1918 in that it is stateless, but is an
unfortunate workaround that somewhat inhibits the end-to-end principle.
That would be an unfortunate end-state for IPv6 that most SMB’s are still
behind NAT, but may be the best technical way forward.
From: David Farmer <[email protected]>
Sent: Monday, September 13, 2021 10:32 AM
To: Larry R. Dockery <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] Proposal - Remove Initial Small Assignment
Requirements for IPv6
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 <[email protected]>
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 ([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.
--
===============================================
David Farmer Email:[email protected]
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
===============================================
_______________________________________________
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.
