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

[Larry R. Dockery]

First, most small businesses don’t need any stable internal addressing. For example, a café switching ISP’s probably won’t even have to fix their guest network - everything will just work when switching PA to PA.

Second, I agree ULA+NTPv6 is a terrible workaround. I hate the idea. It seems like a step back to IPv4 thinking. I’ve seen the benefits of the end-to-end principle and anything that prevents that seems like the wrong design.

Third, to address the cost of those orgs might benefit from PI space, switching ISP’s with RFC1918 or ULA is fewer steps and lower cost than even the steps you listed. This demonstrates that switching PA addressing is not without potential disruption and cost not present with PI, ULA and RFC1918.

DNS fixes a lot, but where there is an IP-only or CIDR requirement - the re-numbering step 8 is fixing all the things that broke. The cost of switching IPv4+RFC1918 is almost nothing, often is nothing. The same is not true of IPv6 PA.

Most SMB’s using private address space can currently switch ISP’s now without actually breaking anything internally or having to contract someone to do the steps you outlined because no internal addresses need to change. Almost as important - they can know ahead of time they are free to switch rather than it being a work effort, or an unknown.

Having recently re-IP’ed a handful of orgs:

Anything, anywhere, using CIDR including but not limited to: Endpoint and server firewall rules, hardware firewall rules, AD Policies (e.g. WinRM IP-range limiting).
Tyler Tech software is written in such a way to require single-IP addresses in places where DNS should be possible.
Devices not correctly registering with DNS (in particular printers). This can be scripted with a prefix swap in DNS.
Print Servers - Though you can specify hostname, most orgs still use IP address. This can be fixed, but is not required in PI space or RFC1918 and is a cost to fix (fix the hostname on every printer, then fix the servers). See also above.
A lot of poorly written software. A whole lot. Input validators that are looking to validate an IPv4 or IPv6 address. Hostnames often are not an option. A document management software required a single IP address for LDAP.

I know the fix is to all of the above is to have Microsoft, Tyler, and all other software vendors in the world fix their software, and have the SMBs that are running these awesome GUI firewalls with 3 years left on their contracts to ditch all of that and move to better systems. And those are all really valid points, but still, a significant cost not present in RFC1918, ULA or IPv6 PI.

And fourth, I agree - the answer to this is PI space.


From: Owen DeLong <owen at delong.com>
Sent: Monday, September 13, 2021 10:44 AM
To: Larry R. Dockery <lrdocker at co.douglas.or.us>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Proposal - Remove Initial Small Assignment Requirements for IPv6

I disagree…

Renumbering a wisely deployed network in IPv6 is _MUCH_ less overhead and much much easier (and faster) in IPv6 than it was in IPv4, even on large-ish scales.

There’s on PA-ISP lockin in IPv6 unless you build your network stupidly.

If you use DHCPv6 or SLAAC to assign addresses to the majority of your systems and static address your servers only, renumbering is relatively quick and
not particularly painful.

                1.            Connect the new ISP and add the new ranges to the routers.
                2.            Add the new address range(s) to the servers.
                3.            Change your SLAAC RAs and DHCP servers over to announcing the new addresses
                4.            Wait until the old addresses are deprecated off the interfaces of all the clients.
                5.            Remove the old address range(s) from the servers.
                6.            Remove the old address ranges from the routers.
                7.            Disconnect the old ISP

Personally, if I were running an SMB IT department, I’d much rather face the above 7 steps for each ISP changeover than the joys of ULA+NPTv6.

OTOH, I’d probably just multi home in most cases, in which case, RIR /48 here I come, easy peasy, current policy.

Owen


On Sep 13, 2021, at 09:38 , Larry R. Dockery <lrdocker at co.douglas.or.us<mailto:lrdocker at co.douglas.or.us>> wrote:

Aside from it making ULA+NTPv6 a smart move, perhaps even best practice for the majority of businesses to adopt rather than allow PA-ISP lock-in, no.

With the mentioned routing issue not being sustainable however, my proposal is likely DOA.

Thank you.

From: Owen DeLong <owen at delong.com<mailto:owen at delong.com>>
Sent: Monday, September 13, 2021 9:00 AM
To: Larry R. Dockery <lrdocker at co.douglas.or.us<mailto:lrdocker at co.douglas.or.us>>
Cc: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] Proposal - Remove Initial Small Assignment Requirements for IPv6

Is there a reason that you think the majority of small businesses that are not going to multi home should
receive PI addresses rather than use PA?

I’m neither in favor nor opposed at this time, but the answer to the above question is pivotal to whether
this proposal serves an actual need or merely panders to the idea of PI for everybody, which until we
change our routing technology to separate locators from identifiers isn’t sustainable.

Owen




On Sep 13, 2021, at 07:51 , Larry R. Dockery <lrdocker at co.douglas.or.us<mailto: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<mailto: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<mailto:info at arin.net> if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20210913/ebeb802a/attachment.htm>