Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 10:26:33AM +0900 Quoting Masataka Ohta (mohta@necom830.hpcl.titech.ac.jp):
> > We cope,
> > because a lot of technical debt is amassed in corporate and ISP /
> > access provider networks that won't change.
>
> Sounds like abstract nonsense.
No, it is the real reason that we still have v4 around.
The "real" reason we have IPv4 around is that it works. Having IPv4+IPv6 is relatively easy, but dropping IPv4 to run IPv6 only is difficult. Some examples:
***
1. Your power goes out. When it comes back up, your internet connection is down. You want to log in to the router... Except you can't. You don't know the address, and you won't have one until your ISP gives you one via DHCP (or similar).
This is contrived. It only happens if you have ignored all reasonable possibility to address this situation in advance.
Sure, you could maybe provide the link-local address on the bottom of the router, but expecting a user to get
http://[fe80:211:aaff:febb:ccdd] right (and you might even need interface scoping!) is boring to cause user frustration when an ISP tech support tries to help, and having the provided CPE using fe80::1 is probably a recipe for disaster.
Likewise, having an mdns broadcast (ssssh, I know) for "gateway" or "router" is definitely not something standardised.
Nor, frankly, should it be, but you are ignoring a number of other possible mitigations:
1. Assign an additional “easy” LL address to the device in its configuration. (e.g. fe80::1). Do you think the average user
would buy unable to correctly type fe80::1?
2. Assign a ULA prefix to the interface (not my preference, but it can work).
3. Us a static GUA assignment (more complicated, but not impossible).
4. Use a non-standardized MDNS name — Who cares that it isn’t standardized, you just have to remember what you
named each of your routers. Brady, Brother, and Dymo all make products to aid in this endeavor.
The only reason this situation doesn’t exist in IPv4 is because we lack unique addresses for LANs in IPv4.
In reality, if this were truly an issue, the simple solution would be to predesignate fd00:: as a “household”
prefix and give every household fd00:: as a prefix in addition to whatever other prefixes may or may not be
assigned. I don’t see this as desirable, but if you wanted to replicate the problems of IPv4 in this regard, that
would be one mostly harmless way to do it.
2. Your IPv6 prefix changes. With some ISPs, it can change every time your router reboots, and if you're with my ISP, it crash-reboots about once a week! If your CPE isn't providing your WiFi (range extender, mesh, nerd etc) then the old prefix is still valid for a while. Yes, there's an RFC to deal with this, but realistically it's not out there today.
Also, any local services are going to break if they're on static addresses... I'm not just talking enterprise AD servers etc, it's also CCTV cameras, raspberry pis, NAS units etc. DHCP registration of addresses in DNS exists, yes, but it's just not used by most of these devices.
This could easily be fixed by having a well-known (and short/memorable!) /48 set aside that would have NAT66 (1:1, not port overload) applied at the router to the delegated prefix received from the ISP, but I'll be shouted down to hell for even mentioning that idea.
There are mitigations for this as well. The situation is not any better in IPv4 than it is with ULA IPv6. The difference is that with IPv4, you expect to have to use NAPT to break your network in order to talk to the outside world and with IPv6, you’re now asking to have your cake and eat it too.
There are implementations of exactly what you say you want readily available, but fortunately they are not standardized.
3. IPv6 "port forwarding" isn't really an easy thing -- people are not used to each machine having a global address. Sure, on many devices you can add firewall rules to allow traffic in, but it's not like the "port forwarding" concept people have gotten used to. I genuinely have no idea whether upnp/nat-pmp has an IPv6 analogue that "just works" which things like consoles (or apps like syncthing) can take advantage of.
Yes, “permit X in” is so much more complicated than “translate Y to X and map Z to A and…”
Oh, wait, no it isn’t… People will get used to the new normal. Ignorance is not a reason to halt progress.
***
IPv4 works. There is no appreciable benefit to the user in enabling IPv6, but the ISP does it and it just works. The same can't be said of going IPv6 only -- you can easily provide IPv6 only with NAT64 and DNS64 or some XLAT464 fun when you're dealing with public WiFi, but this is people's homes and businesses.
The same can’t be said today because of the number of services users want that are not yet available on IPv6. Once that changes, yes, actually, you will be able to provide IPv6 only without NAT64/etc.
Further, there will, likely soon be home gateways that do provide IPv6 only with NAT64/DNS64 which will permit IPv6-only inside and either IPv6-only and/or dual-stack upstream.
The biggest trick there is the number of legacy IPv4-only devices in the home.
IMHO, the solution not that is a cheap dongle which has two ethernets and a small NAT64/DNS64 implementation for a single device embedded in it such that you plug the dongle into the IPv4-only device and it speaks IPv4 on that side and plug the ethernet cable into the other side where it speaks IPv6, problem solved.
Likewise, there's so many devices that are IPv4 only, and aren't getting retired anytime soon. In fact, there's a lot of devices released in the last few years that fully support IPv6, but only when it also has an IPv4 address. I believe either the new Xbox and/or PS5 fit into that category.
See above. Much like the NTSC->ATSC migration and the set top box fiasco (which was a problem with the management of the program by the government, not an issue with the functioning of the set top boxes).
IPv4 is getting more expensive for ISPs because of addressing costs, but a 5-tuple CGNAT solution capable of saturating a 100Gb/s pipe is under $10k these days if you're doing it on the cheap. Yes, this is massively oversimplified.
There are some pretty nasty security implications to CGNAT that have not yet been fully explored. There are a number of services out there (Yes, Philips, I’m talking about you among others) that identify households based on a common public IPv4 address. The assumptions built into these systems mean that they break if the different devices within the household have unique addresses and also that they assume you are in the same household if you are behind the same CGN. Isn’t that delightful as we contemplate all the various smart home controllers and such?
IPv6 only is the goal. IPv4 is going to be with us for at least a decade. Getting IPv6 up and running on a network requires a lot of effort when that network is run by the IT PFY, but it will slowly get that wide penetration desired... Turning off IPv4 for your regular residential and SME ISP connections is such a PITA fraught with support problems that it is just not practical outside of very limited conditions.
If we can start turning off IPv4 on the service provider side of things, then the other side doesn’t really matter that much.
Certainly, on the content side, you can make all your HTTP services on IPv6 only servers, and have the IPv4 go to a proxy that routes based on Host header or SNI, but you need some networking knowledge already to understand what is going on there.
Many are already doing this. However, eliminating the need for those silly IPv4 proxies is still worth while.
IPv4 isn't going anywhere anytime soon. Enabling IPv6 reduces IPv4 traffic levels, it does not reduce IPv4 address usage.
Yes and no. The vast majority of IPv4 addresses are not actually deployed in residential and SOHO. Many more are deployed on
things like CDNs, enterprises, content providers, etc.
If we can eliminate the IPv4 need in those locations, that’s a win and it does free up IPv4 addresses.
Owen