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 <[email protected]>
Sent: Monday, September 13, 2021 10:44 AM
To: Larry R. Dockery <[email protected]>
Cc: [email protected]
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 
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>>
Sent: Monday, September 13, 2021 9:00 AM
To: Larry R. Dockery 
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
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 
<[email protected]<mailto:[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]<mailto:[email protected]>).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected]<mailto:[email protected]> if you experience any issues.

_______________________________________________
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.

Reply via email to