Mailing List Archive

Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 09:04:38PM +0900 Quoting Masataka Ohta (mohta@necom830.hpcl.titech.ac.jp):

> It merely means IPv6 is not deployable with the real reason.

IPv6 is deployable. It is deployed. You are fundamentally in error. Any
conclusions stemming from the false statement "IPv6 is not deployable"
are thus false. While your statements on ports being a part of the address
might hold some value in a world where there is no alternative they are
simply too limited in a world with practically unlimited addresses.

> After finding that, I, as a theorist, totally abandoned IPv6.

You gave up, based on false conclusions.

--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
... I want a COLOR T.V. and a VIBRATING BED!!!

Mans Nilsson wrote:

Supplying context you omit:

>>> No, it is the real reason that we still have v4 around.

>> Even more than 25 years after IPv6 became a proposed standard?
>> It merely means IPv6 is not deployable with the real reason.

> IPv6 is deployable. It is deployed.

If you mean ATM is deployable and was deployed, yes, you are
right. So?

>> After finding that, I, as a theorist, totally abandoned IPv6.
> You gave up, based on false conclusions.

Sorry, but I'm not interested in how you falsely recognize the
real world of practical and theoretical internetworking.

Masataka Ohta

Once upon a time, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> said:
> It merely means IPv6 is not deployable with the real reason.

Except that is provably wrong. A significant number of people are using
IPv6 (and probably don't even know it, because it works without notice).
Almost everything you do on the US cell networks is IPv6. I'm running
over IPv6 to send this message, or when I go to Google or Facebook or
Netflix for example.

I didn't have to do anything special to get any of that to work; I use
my own CPE (which I didn't have to configure special to get IPv6), but
my provider-provided CPE also supported IPv6 out of the box. The common
client OSes all support IPv6 out of the box (only major snag I'm aware
of is Android and DHCPv6, c'mon Google, but typical residential CPE does
RA anyway so this only affects larger businesses with managed networks).

Non-general-purpose devices are lagging some, but on the game system
front, Xbox (at least) supports IPv6. IPv6 support is even in things
like my home audio receiver (Internet connected for streaming music,
which Pandora and Spotify at least support IPv6) and 5+ year old injket
printer.

Could I run IPv6 only today? No, not quite. But it's getting closer to
that point every day. Providers running CG-NAT see that getting IPv6
dual-stack deployed reduces the IPv4 bandwidth (so reduces the CG-NAT
costs) because so much is IPv6-enabled already.

--
Chris Adams <cma@cmadams.net>

> On 18-Nov-2021, at 09:10, Jerry Cloe <jerry@jtcloe.net> wrote:
>
>
>
> Subject: Redploying most of 127/8 as unicast public
> To: nanog <nanog@nanog.org <mailto:nanog@nanog.org>>;
> This seems like a really bad idea to me; am I really the only one who noticed?
>
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html <https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html>
>
> I can think of about a dozen /8's that would be better to use. (Hint, they all have DOD in the name.) They haven't been in routing tables for decades and there wouldn't be hardly any technical issues (like there would be with 127/8). The only drawback is I've seen a lot of organizations treat them like rfc1918 space.
>
This seems to be much better idea then 127/8 or 240/8

On Sat, 20 Nov 2021 at 13:47, Måns Nilsson <mansaxel@besserwisser.org>
wrote:

> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20,
> 2021 at 11:16:59AM +0000 Quoting Matthew Walster (matthew@walster.org):
> > 3. IPv6 "port forwarding" isn't really an easy thing -- people are not
> used
> > to each machine having a global address.
>
> This is the problem in a nutshell. After 27 years of destroying the
> E2E model on the internet, people do not anymore understand how IP
> (regardless of version) was supposed to work; any node to any node.
>
> Why should we burden ourselves with this cumbersome and painful, useless
> layer of abstraction that is "port forwarding", when the choice of
> universal reachability is around the corner?
>

Because it's a REALLY bad idea to have unmanaged devices reachable from the
open internet. Dial-out, not dial-in. You need a firewall. You need a way
of punching holes in that firewall for services you explicitly allow, be
that manually through an interface, or temporarily via an automated system
like upnp/nat-pmp.


> If people can set a port forward up, they can click "allow" in a
> routing-based firewall interface. Only it is better, because one can
> have several parallel services using well-known ports. Sometimes (most
> of the time) the protocol spec has no option to change port either,
> making port forwarding futile anyway. (the let's have a TXT record bunch
> at it again, purposefully ignoring SRV since its inception.)
>

It's not always people. Lots of games, lots of telephony things, services
like Syncthing... They all open firewall holes (yes, NAT is a firewall) to
allow inbound connections for specific conditions, like "this protocol and
port combination".


> I guess juggling our pains differently is what we are doing here. What
> is unthinkable to one is quite OK to someone else.
>

Indeed.


> (But I am right)
>

You are not. I'm glad my internet connected light bulbs are controlled by
the Australian firm that manufactures them and the American firm that has a
surveillance device in my kitchen listening for the immortal words "turn on
the living room lights", rather than Billy* from Doncaster who's looking
for something funny to do after losing at CS:GO again and happens to have
found a list of IP addresses of known vulnerable devices accessible from
the internet.

M

*Billy may or may not be a fictional person living in Yorkshire, UK. For
the sake of argument, Not All Yorkshiremen.

> On Nov 19, 2021, at 10:50 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>
>
> Owen DeLong wrote:
>>
>>> LLA and ULA and whatever random prefix you may wish to use for loopback, whether in IPv6 or even IPv4 have none of these qualities.
>> And if we implement the proposal at hand, which as near as I can tell you are supporting, that changes.
>>
>> Having trouble following your desired outcome here. It seems as if you both want 127.0.0.0/8 to retain it’s unique properties
>> as deterministically loopback only and also want the benefits of repurposing it as GUA.
>>
>> Have cake, Eat cake, please to pick only one.
>
> Let me clear that up then.
>
> I support serious consideration of the idea. My desired outcome is to see ideas like these either adopted or not but based solely on their own merits and especially in their own protocol context. And that folk who have studied the issue and invested their efforts be taken seriously and not be met with undeserved and might I add, unkind, scorn.
>
> (I havent studied the issue or invested the effort, so you may continue to direct your scorn this way)
>
> Its well past time to stop behaving as if we are a bunch of teenagers on a private BBS.
>
> I like the loopback prefix feature of IPv4.
>
> I can easily concede that its too large, especially in this day and age. And that there is a good chance that significant benefit can come from addressing that before IPv4 becomes obsolete.
>
> I question the lack of dedicated loopback feature in IPv6 and I acknowledge that yes, you can accomplish the same with non loopback prefixes by essentially assigning them to loopback, but point out that that does not make them the same thing.

I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some additional convincing of its utility to support such a notion.
>
> I can understand that sometimes you may explicitly not want to use the loopback prefix for loopback applications. In fact many times. However, you dont really have much options when it comes to IPv6

I have not encountered a device where I could not assign additional prefixes to a loopback interface in IPv6, so I’m having trouble understanding your meaning here.

> And I discuss IPv6 loopback simply because of the pushback directed in a non-meritorious fashion from folk who apparently believe simultaneously that IPv6 is superior in every way to IPv4 and that any improvements|changes to IPv4 somehow endanger IPv6 imminent dominance.

I have little concern (if any) of the latter. I believe that IPv6 is mostly equivalent to IPv4 in virtually every way and vastly superior in exactly one way… It has enough addresses. (and in all the ways that result from that, i.e. potential to restore end to end addressing, elimination of NAPT, etc.). I think that IPv6 also offers some features not available in IPv4, the benefits of which we haven’t fully explored or realized (MIP6, DHCP-PD, improved zeroconf, RD, etc.). Certainly the IPSEC implementation in IPv6 is quite a bit cleaner than it’s back-ported counterpart on IPv4 which has become such a nightmare in most implementations that the vast majority of VPNs have migrated to some cockamamy HTTPS “SSL VPN” thing.

>>>> having a prefix
>>>> dedicated to that purpose globally vs. allowing each site that cares to choose their own doesn’t seem like the best
>>>> tradeoff.
>>>>
>>>> Owen
>>>>
>>> But this is how it is to be done in IPv6, so lets get some lack-of-feature parity going with IPv4.
>> I’m all for IPv6 having better implementations than IPv4 rather than mere feature parity.
>
>
> Actually I am (somewhat facetiously) suggesting that IPv4 have non-feature parity with IPv6 by taking away its loopback prefix.

Both have a loopback prefix. IPv4: 127.0.0.0/8 and IPv6: ::1/128

Admittedly, there are a lot more addresses available in the IPv4 loopback prefix, but again, I view that as being mostly waste as a result of historical ignorance at the time a decision was being made.

>> IMHO, having additional loopbacks be assigned from either LLA or ULA space (or even GUA, really)
>> where that is needed is a superior choice vs. 127.0.0.0/8.
>
> Anyone who wants to assign routable IPv4 to loopback is free to do so and there are plenty of IPv4 ranges to choose from.
>
> The converse is not true in IPv6.

I guess that depends on what you mean by “converse”.
If you mean non-routable addresses deployed on the loopback interface, I think LL works fine for that purpose.
If you mean routable addresses deployed on the loopback interface, I think ULA or GUA works fine for that purpose.
If you mean something else, then I’m still not clear what you’re intent is here.

>> For one thing, the alternative addressing schemes (other than LLA) allow for routing of the
>> addresses off the box even though they are configured on loopback interfaces. There are
>> a number of situations where this can be a useful way to ensure that the addresses remain
>> usable regardless of the up/down state of connectivity on any particular non-loopback
>> interface on the box.
>>
>> It’s one of the reasons, for example, that virtually every IBGP speaking router has a GUA
>> or ULA/1918 loopback address which is routed in the IGP and almost all IBGP sessions
>> are terminated on those loopback interfaces.
>>
>> Owen
>>
> And its the fairly common way of implementing anycast services. But that is not what we are addressing on this thread.
>
> I actually think that IPv6 evangelicals should welcome any all ideas like this, especially if they believe it will further degrade the overall state of IPv4, because that should only serve as stronger impetus for IPv6 deployment. That mode of thought has been commonly expressed here and other places before.

I don’t think the current proposals being discussed will improve or degrade IPv4. I think they will distract implementors that choose to implement them from useful work for a while and end in neither benefit nor detriment beyond the detriment that comes from wasting effort.

If I thought it would significantly degrade IPv4, I might be all for it, but I doubt it would even be that useful.

Owen

> On Nov 19, 2021, at 11:46 , John Gilmore <gnu@toad.com> wrote:
>
> Joe Maimon <jmaimon@jmaimon.com> wrote:
>> And all thats needed to be done is to drop this ridiculous .0 for
>> broadcast compatibility from standards.....why is this even controversial?
>
> Not to put words in his mouth, but that's how original BSD maintainer
> Mike Karels seemed to feel when we raised this issue for FreeBSD. He
> was like, what? We're wasting an address per subnet for 4.2BSD
> compatability? Since 1986? Let's fix that.
>
> John

Don’t get me started on BSD vs. IETF Standards… The whole stupidity
around VRRP and CARP still irritates me, so I don’t think holding up
the BSD attitude towards network standards is helping your case any.

Owen

Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 09:15:24PM +0000 Quoting Matthew Walster (matthew@walster.org):

> > Why should we burden ourselves with this cumbersome and painful, useless
> > layer of abstraction that is "port forwarding", when the choice of
> > universal reachability is around the corner?
>
> Because it's a REALLY bad idea to have unmanaged devices reachable from the
> open internet. Dial-out, not dial-in. You need a firewall. You need a way
> of punching holes in that firewall for services you explicitly allow, be
> that manually through an interface, or temporarily via an automated system
> like upnp/nat-pmp.

It's like you did not read the next part.

> > If people can set a port forward up, they can click "allow" in a
> > routing-based firewall interface. Only it is better, because one can
> > have several parallel services using well-known ports. Sometimes (most
> > of the time) the protocol spec has no option to change port either,
> > making port forwarding futile anyway. (the let's have a TXT record bunch
> > at it again, purposefully ignoring SRV since its inception.)
> >
>
> It's not always people. Lots of games, lots of telephony things, services
> like Syncthing... They all open firewall holes (yes, NAT is a firewall) to
> allow inbound connections for specific conditions, like "this protocol and
> port combination".

You obviously read it. Now I'm confused.

> You are not. I'm glad my internet connected light bulbs are controlled by
> the Australian firm that manufactures them and the American firm that has a
> surveillance device in my kitchen listening for the immortal words "turn on
> the living room lights", rather than Billy* from Doncaster who's looking
> for something funny to do after losing at CS:GO again and happens to have
> found a list of IP addresses of known vulnerable devices accessible from
> the internet.

( I'd rather not have my lighting in the cloud. But I'm strange like that. )

Routing and allowing traffic are choices. Only that people with unusable
non-unique addresses don't get to make those choices. One can probably
find quantitative research stating that letting people handle their
IT security makes for less secure systems, and from that standpoint
argue that they don't deserve the choice. To me, that is elitist and
condescending (And I oughta know condescending, I'm quite good at it.) and
I think we could do better.

--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
I want another RE-WRITE on my CEASAR SALAD!!

> On Nov 20, 2021, at 03:16 , Matthew Walster <matthew@walster.org> wrote:
>
>
>
> On Sat, 20 Nov 2021, 09:21 Måns Nilsson, <mansaxel@besserwisser.org <mailto:mansaxel@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@necom830.hpcl.titech.ac.jp <mailto: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

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

> On Nov 20, 2021, at 03:16 , Matthew Walster <matthew@walster.org> wrote:
> On Sat, 20 Nov 2021, 09:21 Måns Nilsson, <mansaxel@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@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

Owen DeLong wrote:
>
> I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some additional convincing of its utility to support such a notion.

Since the loopback prefix in IPv4 is present and usable on all systems,
IPv6 parity would require the same, so merely designating a prefix would
only be the beginning.

There may not be a need. But there is clearly some benefit.

>> I can understand that sometimes you may explicitly not want to use the loopback prefix for loopback applications. In fact many times. However, you dont really have much options when it comes to IPv6
> I have not encountered a device where I could not assign additional prefixes to a loopback interface in IPv6, so I’m having trouble understanding your meaning here.

In IPv6 if you want a loopback prefix you have to pick one yourself or
determine which one the system has chosen on its own. Because there is
no dedicated loopback prefix other than ::1/128

>
>> Anyone who wants to assign routable IPv4 to loopback is free to do so and there are plenty of IPv4 ranges to choose from.
>>
>> The converse is not true in IPv6.
> I guess that depends on what you mean by “converse”.

I mean that in IPv6 you must assign an otherwise non-loopback prefix if
you want one.

> If you mean non-routable addresses deployed on the loopback interface, I think LL works fine for that purpose.

It works, but it is non deterministic and system dependent.
> If you mean routable addresses deployed on the loopback interface, I think ULA or GUA works fine for that purpose.

And IPv4 has that too.
>
>> I actually think that IPv6 evangelicals should welcome any all ideas like this, especially if they believe it will further degrade the overall state of IPv4, because that should only serve as stronger impetus for IPv6 deployment. That mode of thought has been commonly expressed here and other places before.
> I don’t think the current proposals being discussed will improve or degrade IPv4. I think they will distract implementors that choose to implement them from useful work for a while and end in neither benefit nor detriment beyond the detriment that comes from wasting effort.

There seems to be some weird mental representation of how standards
affect the real world. Standards do not demand or direct or control in
any way what individuals do based upon their own assessment of their
needs, available resources and resulting benefits.

You are neither responsible or in control of how people choose to expend
their implementing resources. Nor should you.

What standards do is increase the potential benefits of conforming to
certain behavior.

So what you are really saying is that standardizing something that
others may then choose to recognize as a worthwhile expenditure of their
resources is something you would like to prevent on the assumption that
those efforts would have otherwise gone into IPv6 advancement.

You dont have the immediate moral high ground on that one.

You dont have the long term moral high ground on that one because such
thinking isnt new and we know its wishful at best.

You dont have the logical high ground on that one because you are
assuming facts not in evidence, namely that

- Resources are being feverishly expended deploying IPv6 (as if)

- Those same resources will be the ones redirected to implement ideas
such as these

- That those efforts are in anyways comparable in scope to work being
done on IPv6 (which is supposed to be done already)

- That any such diversion of activity will actually have any real world
affect on the state of IPv6


> If I thought it would significantly degrade IPv4, I might be all for it, but I doubt it would even be that useful.
>
> Owen
>

Reclaiming 127/8 while assigning a /64 for loopback in IPv6 would create
a clear (but narrow) case where IPv6 would be superior to IPv4,
irrelevant of overall network state.

Objectors to the proposal based upon their real world use of far larger
than v4 /16 for loopback applications could implement on IPv6 with even
more space, and in the exact same addressing context.

Which GUA and LL are not, no matter how readily available and easily
assignable and otherwise equivalent they are in every way but the one.
They are not loopback designated by standard (and system implementation).

Joe

> On Nov 20, 2021, at 13:15 , Matthew Walster <matthew@walster.org> wrote:
>
>
>
> On Sat, 20 Nov 2021 at 13:47, Måns Nilsson <mansaxel@besserwisser.org <mailto:mansaxel@besserwisser.org>> wrote:
> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 11:16:59AM +0000 Quoting Matthew Walster (matthew@walster.org <mailto:matthew@walster.org>):
> > 3. IPv6 "port forwarding" isn't really an easy thing -- people are not used
> > to each machine having a global address.
>
> This is the problem in a nutshell. After 27 years of destroying the
> E2E model on the internet, people do not anymore understand how IP
> (regardless of version) was supposed to work; any node to any node.
>
> Why should we burden ourselves with this cumbersome and painful, useless
> layer of abstraction that is "port forwarding", when the choice of
> universal reachability is around the corner?
>
> Because it's a REALLY bad idea to have unmanaged devices reachable from the open internet. Dial-out, not dial-in. You need a firewall. You need a way of punching holes in that firewall for services you explicitly allow, be that manually through an interface, or temporarily via an automated system like upnp/nat-pmp.

This is a common fallacy… The real concept here isn’t “universal reachability”, but universal transparent addressing. Policy then decides about reachability.

Think stateful firewall without NAT.

If you want to allow the incoming connection, you simply permit it rather than having to set up some sort of convoluted port forward.

You can allow open access to a hardened host entirely, or you can open specific ports.

What you don’t have to do is carefully map a limited number of external ports to each be forwarded to a particular port on a particular
internal destination host because you aren’t recycling the one and only public address that all the incoming packets have to first land
on, each host has its own address that you can simply enable.

So again, how is port forwarding better than this? (it isn’t).

> If people can set a port forward up, they can click "allow" in a
> routing-based firewall interface. Only it is better, because one can
> have several parallel services using well-known ports. Sometimes (most
> of the time) the protocol spec has no option to change port either,
> making port forwarding futile anyway. (the let's have a TXT record bunch
> at it again, purposefully ignoring SRV since its inception.)
>
> It's not always people. Lots of games, lots of telephony things, services like Syncthing... They all open firewall holes (yes, NAT is a firewall) to allow inbound connections for specific conditions, like "this protocol and port combination".

No, NAT is not a firewall. The stateful inspection that NAT depends on is a firewall.

You can do all of the exact same things without needing NAT. You just get additional capabilities without NAT that you didn’t have with NAT due to the limitations of shared addressing.

> I guess juggling our pains differently is what we are doing here. What
> is unthinkable to one is quite OK to someone else.
>
> Indeed.

Why juggle pains when you can (mostly) relieve them.

There’s no need for the UI to open a port in IPv6 direct addressing to be any more complex (or really even any different) from the UI to set up a port forward in IPv4 with NAT. In fact, it’s simpler because you don’t need to configure external to internal port mapping, you can simply permit traffic to host X port Y.

> (But I am right)
>
> You are not. I'm glad my internet connected light bulbs are controlled by the Australian firm that manufactures them and the American firm that has a surveillance device in my kitchen listening for the immortal words "turn on the living room lights", rather than Billy* from Doncaster who's looking for something funny to do after losing at CS:GO again and happens to have found a list of IP addresses of known vulnerable devices accessible from the internet.

Yes, well, that’s still just as possible with direct addressing as it is with NAT.

You an do stateful inspection and reject unwanted packets without having to mutilate the packet header in the process.

So to that extent, he is actually right, but you’re applying an emotional reaction to a poorly chosen term and it’s overriding actual logic.

Owen

Please make sure there’s video we can all watch when you try to take DoD’s IP addresses
by force.

ROFLMAO

Owen


> On Nov 20, 2021, at 11:20 , Gaurav Kansal <gaurav.kansal@nic.in> wrote:
>
>
>
>> On 18-Nov-2021, at 09:10, Jerry Cloe <jerry@jtcloe.net <mailto:jerry@jtcloe.net>> wrote:
>>
>>
>>
>> Subject: Redploying most of 127/8 as unicast public
>> To: nanog <nanog@nanog.org <mailto:nanog@nanog.org>>;
>> This seems like a really bad idea to me; am I really the only one who noticed?
>>
>> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html <https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html>
>>
>> I can think of about a dozen /8's that would be better to use. (Hint, they all have DOD in the name.) They haven't been in routing tables for decades and there wouldn't be hardly any technical issues (like there would be with 127/8). The only drawback is I've seen a lot of organizations treat them like rfc1918 space.
>>
> This seems to be much better idea then 127/8 or 240/8
> <https://amritmahotsav.nic.in/>

> On Nov 20, 2021, at 15:35 , Matthew Walster <matthew@walster.org> wrote:
>
>
>
> On Sat, 20 Nov 2021 at 22:35, Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote:
>> On Nov 20, 2021, at 03:16 , Matthew Walster <matthew@walster.org <mailto:matthew@walster.org>> wrote:
>> On Sat, 20 Nov 2021, 09:21 Måns Nilsson, <mansaxel@besserwisser.org <mailto:mansaxel@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@necom830.hpcl.titech.ac.jp <mailto: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.
>
> Chicken and egg.

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.

That doesn’t seem like it would be all that hard.

Owen

Owen DeLong via NANOG wrote:

(snips for brevity and reply relevancy)
>
> This is a common fallacy… The real concept here isn’t “universal
> reachability”, but universal transparent addressing. Policy then
> decides about reachability.
>
> Think stateful firewall without NAT.
>
> No, NAT is not a firewall. The stateful inspection that NAT depends on
> is a firewall.
>
> You can do all of the exact same things without needing NAT. You just
> get additional capabilities without NAT that you didn’t have with NAT
> due to the limitations of shared addressing.
>
> You an do stateful inspection and reject unwanted packets without
> having to mutilate the packet header in the process.
>
>
> Owen
>

You are completely correct in theory.

However, in IPv4 there is a generally true assumption that there are all
these sorts of devices that will be deployed in a somewhat secure
fashion and not by virtue of any particular efforts on the part of their
manufactures, because they are rarely deployed without a NAT in front of
them simply due to address scarcity, where NAT becomes a feature of
network functionality and not of network security.

The hope that there will be equivalent pervasiveness of a statefull
deny-any layer in front of these classes of devices or that they will be
deployed|developed with sufficient/equivalent security without that
layer is not nearly as re-assuring.

Worse, with the assumption of NAT induced security in place its all too
logical to predict and expect that these devices are woefully
under-equipped to protect themselves in any way without it.

Best case scenario is that practically all SOHO v6 gateways default
configuration is statefull deny-any. In which case all you can hope to
get from theoretical E2E is less packet mangling.

(Packet mangling is a good test case for protocols who needlessly commit
layering violations by embedding lower layer addressing directly or
implicitly into their behavior, so NAT has actually been beneficial in
this manner)

The security conscious are better off deploying these devices with IPv6
turned off. Much less chance of them accidentally becoming individually
responsible for their own protection due to any network changes that may
not take their existence or particularly sensitive and vulnerable state
into consideration.

Further, security track records as they are suggest that security will
never become the prime focus or even more than an afterthought for the
producers of these classes of devices.

We can all wish that were not the case but it would be naive to assume
otherwise.

Joe

> On Nov 20, 2021, at 19:11 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>
>
> Owen DeLong wrote:
>>
>> I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some additional convincing of its utility to support such a notion.
>
> Since the loopback prefix in IPv4 is present and usable on all systems, IPv6 parity would require the same, so merely designating a prefix would only be the beginning.
>
> There may not be a need. But there is clearly some benefit.

Which is? You still haven’t answered that question.

>>> I can understand that sometimes you may explicitly not want to use the loopback prefix for loopback applications. In fact many times. However, you dont really have much options when it comes to IPv6
>> I have not encountered a device where I could not assign additional prefixes to a loopback interface in IPv6, so I’m having trouble understanding your meaning here.
>
> In IPv6 if you want a loopback prefix you have to pick one yourself or determine which one the system has chosen on its own. Because there is no dedicated loopback prefix other than ::1/128

Well, technically, fe80::/10 is also present and predictable on every loopback interface. It does come with the additional baggage of having to specify a scope id when referencing it, but that’s pretty minor.

>>> Anyone who wants to assign routable IPv4 to loopback is free to do so and there are plenty of IPv4 ranges to choose from.
>>>
>>> The converse is not true in IPv6.
>> I guess that depends on what you mean by “converse”.
>
> I mean that in IPv6 you must assign an otherwise non-loopback prefix if you want one.

Again, not really…fe80::/10 is right there waiting for you.

>> If you mean non-routable addresses deployed on the loopback interface, I think LL works fine for that purpose.
>
> It works, but it is non deterministic and system dependent.

Nope… It’s every bit as deterministic as 127.0.0.0/8.

If you send packets to fe80::*%lo0 on a linux box, they’ll get there. If you try it on something other than linux, it probably doesn’t work.
That’s also true of 127.*.*.*.

>> If you mean routable addresses deployed on the loopback interface, I think ULA or GUA works fine for that purpose.
>
> And IPv4 has that too.

Right, so we have parity or better in the case of IPv6.

In IPv4, you have 16.7 Million addresses reserved for this purpose. In IPv6, it’s considerably more if you count all of fe80::/10.

(somewhere north of 340,000,000,000,000,000,000,000,000,000,000,000 addresses IIRC)

You can also get away with IPv6 loopback behavior on a dual stack system by using ::ffff:7fxx:xxxx as well.

>>> I actually think that IPv6 evangelicals should welcome any all ideas like this, especially if they believe it will further degrade the overall state of IPv4, because that should only serve as stronger impetus for IPv6 deployment. That mode of thought has been commonly expressed here and other places before.
>> I don’t think the current proposals being discussed will improve or degrade IPv4. I think they will distract implementors that choose to implement them from useful work for a while and end in neither benefit nor detriment beyond the detriment that comes from wasting effort.
>
> There seems to be some weird mental representation of how standards affect the real world. Standards do not demand or direct or control in any way what individuals do based upon their own assessment of their needs, available resources and resulting benefits.

Maybe, maybe not. They certainly influence some of those choices in a variety of ways.

> You are neither responsible or in control of how people choose to expend their implementing resources. Nor should you.

Agreed. But I have every right to express my desires and displeasures with widespread plans to encourage what I perceive as misuse and that’s exactly what’s happening here.

My right to attempt to discourage it by opposing proposed standards is exactly equal to your right to encourage it by promoting them.

> What standards do is increase the potential benefits of conforming to certain behavior.

No, what standards do is encourage people to implement things in compatible ways in hopes that doing so is beneficial. A proposed standard that doesn’t provide an apparent clear benefit, therefore doesn’t merit adoption.

> So what you are really saying is that standardizing something that others may then choose to recognize as a worthwhile expenditure of their resources is something you would like to prevent on the assumption that those efforts would have otherwise gone into IPv6 advancement.

I’m really saying what I said. That IMHO, there’s no benefit to the internet overall if this proposed change is accepted and/or implemented and I see no benefit to standardizing it. As such, I remain opposed to doing so.

Whether or not the effort that would be wasted implementing it would go to IPv6 or to some other more useful pursuit is not a concern I factor into my opinion in this case.

> You dont have the immediate moral high ground on that one.

I’m really not concerned about where your misinterpretations of my statements land me in your opinion of the moral high ground, but thanks for playing.

> You dont have the long term moral high ground on that one because such thinking isnt new and we know its wishful at best.

Same response.

> You dont have the logical high ground on that one because you are assuming facts not in evidence, namely that

Same response.

> - Resources are being feverishly expended deploying IPv6 (as if)

Some are. More certainly would be beneficial.

> - Those same resources will be the ones redirected to implement ideas such as these

I have made no such assumption. I have made the assumption that since this is a complete waste of effort, whatever else those resources could be used for would likely be more useful.
I believe there to be sufficient evidence to support that assumption, though I understand you don’t agree with the assertion it is based upon.

> - That those efforts are in anyways comparable in scope to work being done on IPv6 (which is supposed to be done already)

I’ve made no such assumption, nor do I consider the relative scope to be in any way relevant.

> - That any such diversion of activity will actually have any real world affect on the state of IPv6

Again, have not made any such assumption here, either. It’s not relevant. The only thing I consider relevant is that any resources expended on a complete waste of time could be better
expended elsewhere.

>> If I thought it would significantly degrade IPv4, I might be all for it, but I doubt it would even be that useful.
>>
>> Owen
>>
>
> Reclaiming 127/8 while assigning a /64 for loopback in IPv6 would create a clear (but narrow) case where IPv6 would be superior to IPv4, irrelevant of overall network state.

Why do you need another /64 when you already have a /10?

> Objectors to the proposal based upon their real world use of far larger than v4 /16 for loopback applications could implement on IPv6 with even more space, and in the exact same addressing context.

They can already effectively do that today.

> Which GUA and LL are not, no matter how readily available and easily assignable and otherwise equivalent they are in every way but the one. They are not loopback designated by standard (and system implementation).

And this matters why?

Owen

Owen DeLong wrote:
>
>> On Nov 20, 2021, at 19:11 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>>
>>
>>
>> Owen DeLong wrote:
>>> I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some additional convincing of its utility to support such a notion.
>> Since the loopback prefix in IPv4 is present and usable on all systems, IPv6 parity would require the same, so merely designating a prefix would only be the beginning.
>>
>> There may not be a need. But there is clearly some benefit.
> Which is? You still haven’t answered that question.

You have right below.

And if there is indeed no benefit, than there is no reason not to
repurpose 127/8 considering that you may use many other ranges in IPv4
for loopback and that you can just use IPv6 for loopback and there you
go you have a whole /10.

Its not like it will overnight cause system admin headaches. And they
should be running their loopback apps on IPv6 anyways.
>
> Well, technically, fe80::/10 is also present and predictable on every loopback interface. It does come with the additional baggage of having to specify a scope id when referencing it, but that’s pretty minor.
>
>
> Nope… It’s every bit as deterministic as 127.0.0.0/8.
>
> If you send packets to fe80::*%lo0 on a linux box, they’ll get there. If you try it on something other than linux, it probably doesn’t work.
> That’s also true of 127.*.*.*.

So fe80::/10 is the loopback prefix for IPv6


Joe

Owen DeLong wrote:

> Agreed. But I have every right to express my desires and displeasures with widespread plans to encourage what I perceive as misuse and that’s exactly what’s happening here.
>
> My right to attempt to discourage it by opposing proposed standards is exactly equal to your right to encourage it by promoting them.

Since your discouragement may take form in preventing some amount of
improvement or amelioration to IPv4 users, there is a human cost
associated to that.

Absent the equivalent clear correlation of harm to whatever else you
believe those resources are engaged in, I would not say those two
behaviors are of equal consequence.

> I’m really saying what I said. That IMHO, there’s no benefit to the internet overall if this proposed change is accepted and/or implemented and I see no benefit to standardizing it. As such, I remain opposed to doing so.

There is a clear difference of opinion on this, that there stands a very
good chance that prompt implementation now may prove to provide
significant benefit in the future, should IPv6 continue to lag, which
you cannot guarantee it wont.

Further, there is historical precedent that discouraging re-purposing
IPv4 addressing is the wrong decision.

>
> Whether or not the effort that would be wasted implementing it would go to IPv6 or to some other more useful pursuit is not a concern I factor into my opinion in this case.

And I appreciate that, as I consider that reasoning to be specious at
best, morally dubious at worst.

> Again, have not made any such assumption here, either. It’s not relevant. The only thing I consider relevant is that any resources expended on a complete waste of time could be better
> expended elsewhere.

I dont consider my opinion as to what people's effort should be spent on
relevant to whether a particular proposal has merit all of its own.

>> Which GUA and LL are not, no matter how readily available and easily assignable and otherwise equivalent they are in every way but the one. They are not loopback designated by standard (and system implementation).
> And this matters why?
>
> Owen

So re-purpose 127/8 and if users and developers agree with you, it will
become available right about the time IPv6 should have finally managed
to obsolete IPv4, no harm no foul. And if it fails at that again, at
least we will have 127/8 and cohorts.

Joe

On 21 Nov 2021, at 00.00, Joe Maimon <jmaimon@jmaimon.com> wrote:
>
> There is a clear difference of opinion on this, that there stands a very good chance that prompt implementation now may prove to provide significant benefit in the future, should IPv6 continue to lag, which you cannot guarantee it wont.

The reassignment being implemented faster than IPv6 seems like a big assumption.

Max Harmony via NANOG wrote:
> On 21 Nov 2021, at 00.00, Joe Maimon <jmaimon@jmaimon.com> wrote:
>> There is a clear difference of opinion on this, that there stands a very good chance that prompt implementation now may prove to provide significant benefit in the future, should IPv6 continue to lag, which you cannot guarantee it wont.
> The reassignment being implemented faster than IPv6 seems like a big assumption.
>
>
Suppose you are correct. This time. Even a broken clock can be right
twice a day.

The only loss for the most part in most of these related proposals is
the time spent dickering on them and a few extra patches thrown in over
the next decade.

So just agree already.

127/8 is actually the proposal with the most potential for
implementation issues as the definition change wends its way into system
updates. And its easy to see that typical system updates tend to bring
far greater disruption to system administrators on a regular basis. I
would not rule out this change in that regard.

And if you are wrong, as history suggests you may very well be?

What is lost by not acting now is possibly far greater.

Joe

Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 10:47:10PM -0500 Quoting Joe Maimon (jmaimon@jmaimon.com):

> layer in front of these classes of devices or that they will be
> deployed|developed with sufficient/equivalent security without that layer is
> not nearly as re-assuring.

The inside/outside paradigm inherent in the reasoning of "NAT is a good,
big part of my firewall" crowd is woefully inadequate to describe and
counter the threats of today. The techniques to get past uni-reachability
(The NATted client can ask the net, but not in reverse) are many and
advanced. Since there is a somewhat inflated belief of the efficiency
of the unroutability paradigm, once inside, the rules tend to be relaxed.

It might very well be so that the resultant protection level will be better
once you realise you can't trust the net to not deliver packets to you.

Also, I much prefer writing firewall rules where the IP addresses don't
change in-flight. Less to screw up.
--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
Of course, you UNDERSTAND about the PLAIDS in the SPIN CYCLE --

On Sat, Nov 20, 2021 at 7:16 PM Owen DeLong via NANOG <nanog@nanog.org> wrote:
> This is a common fallacy… The real concept here isn’t “universal reachability”, but universal transparent addressing. Policy then decides about reachability.
>
> Think stateful firewall without NAT.
>
> If you want to allow the incoming connection, you simply permit it rather than having to set up some sort of convoluted port forward.
>
> You can allow open access to a hardened host entirely, or you can open specific ports.
>
> What you don’t have to do is carefully map a limited number of external ports to each be forwarded to a particular port on a particular
> internal destination host because you aren’t recycling the one and only public address that all the incoming packets have to first land
> on, each host has its own address that you can simply enable.
>
> So again, how is port forwarding better than this? (it isn’t).

Hi Owen,

This has been hashed and rehashed on this group about a gajillion
times but for the sake of those who are new:

Firewalls are programmed by people. People make mistakes. Lots of
mistakes. 1:1 stateful firewalls and 1:many stateful firewalls (NAT)
behave differently in the face of those mistakes. When 1:1 stateful
firewalls are mistakenly told to pass all traffic they faithfully do
so exposing unhardened hosts directly to the Internet. When 1:many
stateful firewalls (NAT) are mistakenly told to pass all traffic they
can't do so. They don't have enough information to decide which
interior host to send a packet to so they simply break.

One fails as a security perimeter breach. The other fails as a system
down. Pick which security posture you prefer but they're very much not
the same. A knocked over fence versus a lost padlock key and well into
the zombie apocalypse.

Regards,
Bill Herrin


--
William Herrin
bill@herrin.us
https://bill.herrin.us/

> On Nov 20, 2021, at 19:47 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>
>
> Owen DeLong via NANOG wrote:
>
> (snips for brevity and reply relevancy)
>>
>> This is a common fallacy… The real concept here isn’t “universal reachability”, but universal transparent addressing. Policy then decides about reachability.
>>
>> Think stateful firewall without NAT.
>>
>> No, NAT is not a firewall. The stateful inspection that NAT depends on is a firewall.
>>
>> You can do all of the exact same things without needing NAT. You just get additional capabilities without NAT that you didn’t have with NAT due to the limitations of shared addressing.
>>
>> You an do stateful inspection and reject unwanted packets without having to mutilate the packet header in the process.
>>
>>
>> Owen
>>
>
> You are completely correct in theory.
>
> However, in IPv4 there is a generally true assumption that there are all these sorts of devices that will be deployed in a somewhat secure fashion and not by virtue of any particular efforts on the part of their manufactures, because they are rarely deployed without a NAT in front of them simply due to address scarcity, where NAT becomes a feature of network functionality and not of network security.

This is a fallacy which has repeatedly been proven false by numerous security researchers. It’s time to educate beyond this silly assertion and recognize that NAT is an obfuscation tool, not a security tool.

They are at least as secure behind a non-NAT stateful firewall as they are behind NAT.

> The hope that there will be equivalent pervasiveness of a statefull deny-any layer in front of these classes of devices or that they will be deployed|developed with sufficient/equivalent security without that layer is not nearly as re-assuring.

Virtually all home gateways today ship with a stateful default deny-all policy for IPv6, so it’s not a hope, it’s current reality.

There is hope that manufacturers will eventually start improving security as well, but I agree that depending on that at this stage is rather perilous.

OTOH, it’s also perilous to believe that NAT provides adequate protection for their failures in this arena.

> Worse, with the assumption of NAT induced security in place its all too logical to predict and expect that these devices are woefully under-equipped to protect themselves in any way without it.

NAT does not induce security. It induces headaches. It induces difficulties in troubleshooting. It induces difficulties in correlating logs and audit trails. It induces all manner of things that make it harder to address security incidents. It does NOT induce security.

Further, 100% of the alleged or perceived security gains attribute to NAT come from stateful inspection, not NAT itself. As such, no, there’s no need for NAT to have equivalent security even if you just assume a stateful default deny-all in the gateway vs. assuming NAT.

I agree that the idea of producing a home gateway without a stateful default deny-any inbound policy should be (and basically is, frankly) as unrealistic as producing a home gateway for IPv4 without NAT, but once that’s the case (and really, from what I have seen of current market entrants, it is), there’s no meaningful difference in the security level between the two options. The non-NAT option does provide greater choice and freedom in controlling your security and permitting things in, but not significantly more dangerous than current port forwarding setups with NAT.

> Best case scenario is that practically all SOHO v6 gateways default configuration is statefull deny-any. In which case all you can hope to get from theoretical E2E is less packet mangling.

That’s already the case from my observations. OpenWRT, Linksys, Netgear, D-Link, Belkin, and several others all default this way already.

> (Packet mangling is a good test case for protocols who needlessly commit layering violations by embedding lower layer addressing directly or implicitly into their behavior, so NAT has actually been beneficial in this manner)

If you want to put packet mangling capability into test equipment in SQA environments, by all means, feel free, but it has no useful place in the modern internet once we move forward from restricted addressing.

> The security conscious are better off deploying these devices with IPv6 turned off. Much less chance of them accidentally becoming individually responsible for their own protection due to any network changes that may not take their existence or particularly sensitive and vulnerable state into consideration.

We can agree to disagree here. The security conscious are better off deploying these products IPv6-only where they can get proper audit and log correlation with transparent addressing and making sure that the upstream router(s) have adequate protection configured. That’s at least as good as having a NAT upstream, given that a NAPT port forward can be just as dangerous to these devices as a transparent permit.

> Further, security track records as they are suggest that security will never become the prime focus or even more than an afterthought for the producers of these classes of devices.

I can’t effectively argue against this, but my hope is that we can eventually arrive at a place where manufacturers face real liability for damages inflicted by the insecurity of these products. Kind of a “unsafe at any bandwidth” equivalent of the “unsafe at any speed” campaign to improve automotive safety and get seatbelt mandates and the like. Much of that happened through product liability law.

> We can all wish that were not the case but it would be naive to assume otherwise.

It’s naive to assume it’s otherwise today. I do have hope that real progress will be made in liability laws helping to remedy the situation in the future.

Nothing says “fix your broken security” like a multi-million dollar jury verdict against your unlucky competitor.

Nonetheless, even with that remaining the case, I still believe that a stateful inspection without header mutilation is better security than a NAPT.

Owen

> On Nov 20, 2021, at 20:37 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>
>
> Owen DeLong wrote:
>>
>>> On Nov 20, 2021, at 19:11 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>>>
>>>
>>>
>>> Owen DeLong wrote:
>>>> I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some additional convincing of its utility to support such a notion.
>>> Since the loopback prefix in IPv4 is present and usable on all systems, IPv6 parity would require the same, so merely designating a prefix would only be the beginning.
>>>
>>> There may not be a need. But there is clearly some benefit.
>> Which is? You still haven’t answered that question.
>
> You have right below.
>
> And if there is indeed no benefit, than there is no reason not to repurpose 127/8 considering that you may use many other ranges in IPv4 for loopback and that you can just use IPv6 for loopback and there you go you have a whole /10.

One doesn’t need a reason for inaction… One needs a reason to act. There is (so far) no compelling reason to repurpose 127/8 as far as I can see.

> Its not like it will overnight cause system admin headaches. And they should be running their loopback apps on IPv6 anyways.

You are arguing that just because we can do a thing, we should do a thing. I am arguing that unless there’s a compelling reason to change the standard, we should leave it as is until it dies a natural death of old age.
(or alternatively until we finally disconnect the life support keeping it artificially alive which is a more accurate metaphor for the current state of IPv4).

>> Well, technically, fe80::/10 is also present and predictable on every loopback interface. It does come with the additional baggage of having to specify a scope id when referencing it, but that’s pretty minor.
>>
>>
>> Nope… It’s every bit as deterministic as 127.0.0.0/8.
>>
>> If you send packets to fe80::*%lo0 on a linux box, they’ll get there. If you try it on something other than linux, it probably doesn’t work.
>> That’s also true of 127.*.*.*.
>
> So fe80::/10 is the loopback prefix for IPv6

It’s link local. It’s present on loopback. fe80::/10%lo0 (on a linux box) is a loopback prefix for IPv6 which is universally deployed.
The scope id becomes important in this context, but other than that, it’s identical to the semantics of IPv4.

Owen

> On Nov 20, 2021, at 21:00 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>
>
> Owen DeLong wrote:
>
>> Agreed. But I have every right to express my desires and displeasures with widespread plans to encourage what I perceive as misuse and that’s exactly what’s happening here.
>>
>> My right to attempt to discourage it by opposing proposed standards is exactly equal to your right to encourage it by promoting them.
>
> Since your discouragement may take form in preventing some amount of improvement or amelioration to IPv4 users, there is a human cost associated to that.

Since wasted effort may prevent other things I see as advantageous to the network and humanity in general from happening, there is a human cost to not preventing it.

> Absent the equivalent clear correlation of harm to whatever else you believe those resources are engaged in, I would not say those two behaviors are of equal consequence.

You are entitled to your opinion. I do not happen to share it.

>> I’m really saying what I said. That IMHO, there’s no benefit to the internet overall if this proposed change is accepted and/or implemented and I see no benefit to standardizing it. As such, I remain opposed to doing so.
>
> There is a clear difference of opinion on this, that there stands a very good chance that prompt implementation now may prove to provide significant benefit in the future, should IPv6 continue to lag, which you cannot guarantee it wont.

There stands some chance. It’s not clear how good that chance is. Obviously you think it is a higher probability than I do. You also assume that it would be widely implemented faster than deployment of IPv6 which is also an assertion of which I remain unconvinced.

> Further, there is historical precedent that discouraging re-purposing IPv4 addressing is the wrong decision.

Nope… There is historical precedent that you don’t like it. IMHO, we’ve done far too many things and put far too much effort into avoiding rather than completing IPv6 transition. As such, I think that the historical precedent argues that adding to those errors will not accelerate IPv6 transition and is, therefore, wasted effort at best and potentially counterproductive.

>> Whether or not the effort that would be wasted implementing it would go to IPv6 or to some other more useful pursuit is not a concern I factor into my opinion in this case.
>
> And I appreciate that, as I consider that reasoning to be specious at best, morally dubious at worst.

At least we agree on something.

>> Again, have not made any such assumption here, either. It’s not relevant. The only thing I consider relevant is that any resources expended on a complete waste of time could be better
>> expended elsewhere.
>
> I dont consider my opinion as to what people's effort should be spent on relevant to whether a particular proposal has merit all of its own.

IMHO, the proposal has no merit and is therefore a waste of time. Clearly you disagree. That’s fine.

>>> Which GUA and LL are not, no matter how readily available and easily assignable and otherwise equivalent they are in every way but the one. They are not loopback designated by standard (and system implementation).
>> And this matters why?
>>
>> Owen
>
> So re-purpose 127/8 and if users and developers agree with you, it will become available right about the time IPv6 should have finally managed to obsolete IPv4, no harm no foul. And if it fails at that again, at least we will have 127/8 and cohorts.

Meh, feel free to do whatever you want. In terms of any IETF WG adoption call or consensus call, I’ll object as I consider it useless at best and harmful at worst.

Nothing you have said provides any indication that there is sufficient merit to be worth the time I have wasted on this thread, let alone further effort.

Owen