Redploying most of 127/8 as unicast public

Sat Nov 20 23:35:37 UTC 2021

On Sat, 20 Nov 2021 at 22:35, Owen DeLong <owen at delong.com> wrote:

> On Nov 20, 2021, at 03:16 , Matthew Walster <matthew at walster.org> wrote:
> On Sat, 20 Nov 2021, 09:21 Måns Nilsson, <mansaxel at besserwisser.org>
> wrote:
>
>> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov
>> 20, 2021 at 10:26:33AM +0900 Quoting Masataka Ohta (
>> mohta at 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.

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

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

> 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?

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

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

Chicken and egg.

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

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

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

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

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.

M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20211120/1c05d9e8/attachment.html>