Redploying most of 127/8 as unicast public

Sun Nov 21 03:12:17 UTC 2021

> On Nov 20, 2021, at 13:15 , Matthew Walster <matthew at walster.org> wrote:
> 
> 
> 
> On Sat, 20 Nov 2021 at 13:47, Måns Nilsson <mansaxel at besserwisser.org <mailto:mansaxel at 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 at walster.org <mailto:matthew at 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

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