<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 20 Nov 2021 at 22:35, Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><blockquote type="cite"><div>On Nov 20, 2021, at 03:16 , Matthew Walster <<a href="mailto:matthew@walster.org" target="_blank">matthew@walster.org</a>> wrote:</div><div><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 20 Nov 2021, 09:21 Måns Nilsson, <<a href="mailto:mansaxel@besserwisser.org" target="_blank">mansaxel@besserwisser.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 10:26:33AM +0900 Quoting Masataka Ohta (<a href="mailto:mohta@necom830.hpcl.titech.ac.jp" rel="noreferrer" target="_blank">mohta@necom830.hpcl.titech.ac.jp</a>):<br>
<br>
> > We cope,<br>
> > because a lot of technical debt is amassed in corporate and ISP /<br>
> > access provider networks that won't change.<br>
> <br>
> Sounds like abstract nonsense.<br>
<br>
No, it is the real reason that we still have v4 around.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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:</div><div dir="auto"><br></div><div dir="auto">***</div><div dir="auto"><br></div><div dir="auto">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).</div></div></div></blockquote><div><br></div>This is contrived. It only happens if you have ignored all reasonable possibility to address this situation in advance.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.<span style="font-family:Arial,Helvetica,sans-serif"> </span></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><blockquote type="cite"><div><div dir="auto"><div dir="auto">Sure, you could maybe provide the link-local address on the bottom of the router, but expecting a user to get <a>http://[fe80:211:aaff:febb:ccdd</a>] 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.</div></div></div></blockquote><blockquote type="cite"><div><div dir="auto"><div dir="auto"><br></div><div dir="auto">Likewise, having an mdns broadcast (ssssh, I know) for "gateway" or "router" is definitely not something standardised.</div></div></div></blockquote><div><br></div>Nor, frankly, should it be, but you are ignoring a number of other possible mitigations:</div><div><br></div><div>1.<span style="white-space:pre-wrap">        </span>Assign an additional “easy” LL address to the device in its configuration. (e.g. fe80::1). Do you think the average user</div><div><span style="white-space:pre-wrap">     </span>would buy unable to correctly type fe80::1?</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">It would be http://[fe80::1] actually, and I presume you need to use interface scoping? I actually don't know that answer...</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>2.<span style="white-space:pre-wrap">       </span>Assign a ULA prefix to the interface (not my preference, but it can work).</div><div><br></div><div>3.<span style="white-space:pre-wrap">    </span>Us a static GUA assignment (more complicated, but not impossible).</div><div><br></div><div>4.<span style="white-space:pre-wrap">    </span>Use a non-standardized MDNS name — Who cares that it isn’t standardized, you just have to remember what you</div><div><span style="white-space:pre-wrap">  </span>named each of your routers. Brady, Brother, and Dymo all make products to aid in this endeavor.</div><div><br></div><div>The only reason this situation doesn’t exist in IPv4 is because we lack unique addresses for LANs in IPv4.</div><div>In reality, if this were truly an issue, the simple solution would be to predesignate fd00:: as a “household”</div><div>prefix and give every household fd00:: as a prefix in addition to whatever other prefixes may or may not be</div><div>assigned. I don’t see this as desirable, but if you wanted to replicate the problems of IPv4 in this regard, that</div><div>would be one mostly harmless way to do it.</div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><blockquote type="cite"><div><div dir="auto"><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div></div></div></blockquote><div><br></div>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.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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?</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>There are implementations of exactly what you say you want readily available, but fortunately they are not standardized.</div><div><br><blockquote type="cite"><div><div dir="auto"><div dir="auto">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.</div></div></div></blockquote><div><br></div>Yes, “permit X in” is so much more complicated than “translate Y to X and map Z to A and…”</div><div><br></div><div>Oh, wait, no it isn’t… People will get used to the new normal. Ignorance is not a reason to halt progress.</div></div></blockquote><div><br></div><div><div class="gmail_default" style=""><font face="arial, helvetica, sans-serif">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...</font><span style="font-family:Arial,Helvetica,sans-serif"> </span></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><blockquote type="cite"><div><div dir="auto"><div dir="auto">***</div><div dir="auto"><br></div><div dir="auto">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.</div></div></div></blockquote><div><br></div>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.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Chicken and egg.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>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.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Strongly doubt that these will be at all common this decade, but I'd love to be proved wrong.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>If we can start turning off IPv4 on the service provider side of things, then the other side doesn’t really matter that much.</div></div></blockquote><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"></span></div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">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. </span></div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></span></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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".</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><blockquote type="cite"><div dir="auto"><div dir="auto">IPv4 isn't going anywhere anytime soon. Enabling IPv6 reduces IPv4 traffic levels, it does not reduce IPv4 address usage.</div></div></blockquote>Yes and no. The vast majority of IPv4 addresses are not actually deployed in residential and SOHO. Many more are deployed on</div><div>things like CDNs, enterprises, content providers, etc.</div><div><br></div><div>If we can eliminate the IPv4 need in those locations, that’s a win and it does free up IPv4 addresses.</div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">M</div></div></div>