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.
Yup. Though this isn't contrived, this is the exact situation I'm having with my ISP at the moment, whose CPE crash-reboots every couple of days and gets a new IPv6 prefix every time... Except when the power goes out (again, annoyingly regularly -- I have had more power outages in 15 months of living here than the last 37 years of my life) and it takes up to 10 minutes for the street to get connectivity again.
The problem is not contrived…The supposed lack of solutions is contrived.
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?
It would be
http://[fe80::1] actually, and I presume you need to use interface scoping? I actually don't know that answer...
Yes, interface scoping is required for any LL address on any system with more than one interface. Since any system
where this would be useful has at least one external facing interface and one loopback interface, that would make it
essentially universally required. As long as your not on Windows, that’s not too bad.
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.
Indeed, that's what I'm proposing. As /etc/gai.conf (or the equivalent in Windows) would prefer the non-ULA space for addressing, once a connection is up, it would just work with that new prefix, but it would continue to work locally for that non-U ULA.
Absolutely nothing prevents you from doing this today and it is, IIRC, already in some of the HOMENET RFCs.
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.
Oh I'm fine with connections being broken. But when they're broken, they re-establish. When a prefix changes, what's the procedure to invalidate the old RA if the router doesn't know what prefix it had before?
See recent IETF work by Fernando Gont on exactly this subject. In short, the router shouldn’t “not know” what prefix it had before, because it’s supposed to store that in non-volatile storage. However, there are
mitigations available even if it doesn’t know.
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.
I'm not talking about halting progress, I'm saying that it's currently a stumbling block that I know for *certain* confuses a lot of people right now. Hell, I just looked at the IPv6 firewall page for my ISP's CPE and had to read it several times to work out what to do. I wanted to see what the UPNP menu did, whether it supported that new-fangled PCP thing for opening ports, but it genuinely just crash-rebooted my router twice. If I wasn't moving in a couple of months...
Why would anyone be more confused by “permit traffic to host X port Y” if they can navigate “map ip address X port Y to internal address Q on port Z”?
If you’re saying that your ISP’s CPE has a bad UI for IPv6, then I’m not going to argue with you about that, but that’s a UI problem, not an IPv6 standards problem.
File a bug with the equipment vendor in question. There is IPv6 CPE available that has pretty much the same UI for doing the equivalent things in IPv4 and IPv6.
***
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.
Not entirely. Content is slowly (too slowly) adding IPv6 capabilities. As that starts to become more ubiquitous (a few more big applications/sites would get us most of the way to where we need to be), then ISPs will be able to start either turning down IPv4 services and/or offering discounts for IPv6-only service or other incentives to get away from IPv4.
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.
Strongly doubt that these will be at all common this decade, but I'd love to be proved wrong.
Depending on whether you mean the next 10 years, or the decade ending 2029, perhaps. I suspect it will likely be a close call on “widely deployed”.
If we can start turning off IPv4 on the service provider side of things, then the other side doesn’t really matter that much.
We can't turn off IPv4 on the service provider side until almost every client has IPv6. And as you said before, there's some stuff that will never have IPv6 compatibility, and it will be a long time before they are phased out. In fact, there's a lot of devices out there that are capable of IPv6 but have it disabled because it only supports static configuration, which you can't get if you've got a dynamic interior prefix.
That’s not at all true… We can turn off IPv4 on the service provider side as soon as the potential customer loss costs less than the savings gained.
That’s _WAY_ before “almost every client…”
Look at the NTSC->ATSC cutover. That happened well before “almost every client” and the next day, a whole lot of set top boxes flew off the shelves.
I agree with your point, I just think that expecting the next phase to be gated on pervasive IPv6 is just going to mean there's no hurry to roll it out because "IPv4 works".
Except that it doesn’t, really, and it’s getting progressively worse.
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.
They're only deployed there generally because the clients need IPv4 addresses to connect to. I genuinely believe we're reaching a stalling point for IPv6 service enabling, and it's time to focus energy on running IPv6 only clients -- and to do that, we need to make the IPv6 only experience for residential / soho be as pain-free as possible, no extra knowledge required. Better/easier than IPv4 even. The rest of the IPv4-only services will rapidly want to deploy IPv6 because the IPv4 path may be less stable than the IPv6 due to CGNAT, tromboning, all that jazz.
We can’t run IPv6-only clients until we get at least a majority of the most popular applications/sites running on IPv6. We’re getting close to that point, but we’re not as far along as we should be.
That's just my viewpoint, anyway. I would love to see an GL.iNet / OpenWRT style router that was plug-and-play, that based on a hardware switch event (like the one on the GL-AR750S-Ext I use to enable/disable WireGuard) on the outside went from Dual-Stack mode to IPv6-only mode. Leave it with your family and friends, in IPv6-only mode, and get them to call you if they're having trouble. When you're suitably annoyed that they're hitting a problem that isn't going to be solved soon, get them to flick the switch over to Dual-Stack. I think it'd be a really interesting study into real-world usage.
Owen