The New Internet

(Repost of <https://news.ycombinator.com/item?id=38570370>)

edit: maybe even invite 2 or 3 DNSSEC advocates @tptacek :)

There are other ways to do that.

There are dynamic DNS schemes, so you can give your machine which only has a temporary IP address a permanent name. That's been around for decades, and seems to have a bad reputation.

There are schemes with multiple coordination nodes that know about each other, and published lists of such nodes. The list may be out of date, but as long as the published list has one live node, you can connect and get updated. That's how Kademlia, which underlies Etherium's network and some file sharing systems, works. That's about 20 years old, and sort of has a sketchy reputation.

It's possible to go only halfway, and separate discovery from transmission. Peertube does that. You find a file to stream via ordinary HTTP to a server you find by ordinary web search means. Anybody can set up such a server. The actual streaming, for files wanted by many clients, is distributed, with people currently watching also sending out blocks to other people watching. This scales well, in case your video goes viral. It's not used much, though.

So it's definitely possible to do this without someone in the middle able to cut off your air supply.

it's not a problem specific to any kind of corporation or corporations per se, but organizations or even broader, solutions.

though, do you really think that having a solution to a problem is worse than just having the problem?

historically car owners need to pay for repairs.

IPv6 was released in 1998. It had been 21 (!) years since the release of IPv6 and still what you're describing had not been implemented when Tailscale was released in 2019. Who was stopping anyone from doing it then, and who is stopping anyone from doing it now?

It's easy to paint companies as bad actors, especially since they often are, but Google, Cloudflare and Tailscale all became what they are for a reason: they solved a real problem, so people gave them money, or whatever is money-equivalent, like personal data.

If your argument is inverted, it's a kind of inverse accelerationism (decelerationism?) whereby only in making the Internet worse for everyone, the really good solutions can see the light. I don't buy it.

Tailscale is not the reason we're not seeing what you're describing, the immense work involved in creating it is why, and it's only when that immense amount of work becomes slightly less immense that any solution at all emerges. Tailscale for example would probably not exist if they had to invent Wireguard, and the fact that Tailscale now exists has led to Headscale existing, creating yet another springboard in a line of springboards to create "something" like what you describe -- for those willing to put in the time.

The folks who either (a) got in early on the IPv4 address land rush (especially the Western developed countries), or (b) with buckets of money who buy addresses.

If you're India, there probably weren't enough IPv4 address in the first place to handle your population, so you're doing IPv6:

* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...

Or even if you're in the West, if you're poor (a community Native American ISP):

> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.

* https://community.roku.com/t5/Features-settings-updates/It-s...

* Discussion: https://news.ycombinator.com/item?id=35047624

IPv4 'wasn't a problem' because the megacorps who generally run things where I'm guessing you're from (the West) were able to solve it in other means… until they can't. T-Mobile US has 120M and a few years ago it turns out that money couldn't solve IPv4-only anymore so they went to IPv6:

* https://www.youtube.com/watch?v=QGbxCKAqNUE

IPv6 is not taking off because IPv4 (and NAT/STUN/TURN) is 'better', but rather because (a) inertial, and (b) it 'works' (with enough kludges thrown at it).

Your computer can talk to your home router (CPE) and punch a hole for a connection, but if your WAN port does not have a public IP address, but rather itself also has a private address (probably 100.64/10), the CPE cannot talk to the ISP's router to punch a hole:

* https://en.wikipedia.org/wiki/Carrier-grade_NAT

The two layers of NAT (home network (192.168) -> CPE NAT (100.64/10) -> ISP NAT ('real' public IPv4)) prevent hole punching.

They have a higher resale value because they have a reputation of lasting a long time, and people are thus perhaps more willing to pay a higher initial purchase price because they know their "investment" will last longer.

And while they may not be planing to sell their car after only a few years, knowing that they'll get back more of their "investment" is also probably sitting in the back of their mind ('just in case').

Its also worth considering that, for better or worse, very few people actually own their cars today. When you have a loan on it the resale value becomes really important. If the manufacturer wants the kind of customer that buys a new car every few years they'll need resale value that at least keeps up with the principle on the loan over that time.

• Blog post: <https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-...>

• As a podcast episode: <https://blog.apnic.net/2023/03/16/podcast-dnssec-the-case-fo...>

• This does not really solve the problem, since a real solution would be to change the internet to make the problem go away

• A company making a lot of money gets to have an enormous influence on what is considered reasonable to standardize on. See for instance Google’s and Microsoft’s influence on things like the W3C. (Or if Tailscale is allowed to define what ”The New Internet” will be.)

Or, more to the point, the server that I use to run my RSS feed reader?

Or my NAS?

Tailscale makes these more secure and more accessible for me. They are never meant to have the world access them.

Now for email and a few other things, sure, their nature is that they need to access the world.

just the other day i was discouraging a youngster from manually populating his hosts-file in order to circumvent a dmca-related dns block.... what has the world come to.

Because that is how the internet is meant to work. It is an end-to-end network. If SSH would not be secure enough to handle this, it would need a secure replacement.

> Or my NAS? […] They are never meant to have the world access them.

What is a NAS, if not a Network-Attached Storage, i.e. meant to be accessed from the network? The concept of a ”local”, ”secure” network is a dangerous illusion. Embrace ”zero trust” networking.

I always bring this up and it’s always dismissed because tech people continue to dismiss usability concerns.

Even “small” usability differences can have a huge effect on adoption.

The solution for IPv6 addresses is the same for Ethernet addresses; don’t use them directly. Leave it to the name resolution system, and use host names.

If only there was some mechanism in which we could use a human-friendly label and have that translated to a computer-usable address…

> I always bring this up and it’s always dismissed because tech people continue to dismiss usability concerns.

I don't bother remembering IPv4 addresses, so I'm not sure why I would bother to remember IPv6 addresses. Heck, phone numbers are generally short as well, and who remembers them nowadays? ("0118 999 881 999 119 725… 3")

Maybe it's dismissed because people see it as a non-issue. I regularly work at OSI Layer 2 (and even 1, pulling fibres in a DC), and Layer 3, and am not sure what the concerns are about.

Even if something is open, complexity is almost like closed as we can see with crazy complicated web standards for which there are few implementations.

In modern devops in particular it is common to create and tear down IP networks in seconds and sling stuff everywhere. The extra moving part is an extra thing to break.

DNS also runs over IP which means if IP is down DNS doesn’t work. What do you have to do then? You have to debug IP without DNS.

There is mDNS but it’s not reliable and doesn’t scale to large networks. It also runs on the IP layer so if there is a problem there it can break.

> Our [Native American] tribal network started out IPv6, but soon learned we had to somehow support IPv4 only traffic. It took almost 11 months in order to get a small amount of IPv4 addresses allocated for this use. In fact there were only enough addresses to cover maybe 1% of population. So we were forced to create a very expensive proxy/translation server in order to support this traffic.

> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.

* https://community.roku.com/t5/Features-settings-updates/It-s...

* Discussion: https://news.ycombinator.com/item?id=35047624

Certainly it is not-zeroconf, but it is the same not-zeroconf for both IPv4 and IPv6.

But extra work with DHCP is needed for IPv4, and extra-extra work if you need to do things like configure 'IP helper', whereas IPv6 can be configured using only a router (which you need regardless) and some on-link packets (RAs).

> DNS also runs over IP which means if IP is down DNS doesn’t work. What do you have to do then? You have to debug IP without DNS.

And? At least you have fe80/64 as a basic starting point. Run a tcpdump to see if you're on-link in any way (or in the correct VLAN), and if you are, you can then ping(6) ff02::2 to find if there any on-link routers. You've now debugged Layer 2 and Layer 3 connectivity. Tada.

You're making IPv6 (sound) way more complicated than it is. It is no more or less complicated than IPv4 or IPX/SPX or …. It's protocol data units at OSI Layer 2 or 3 in different formats with different fields.

I have no problem criticizing tech companies, but I try to wait until they behave badly.

I suppose if you follow that thread though a lot of businesses just shouldn't exist except for fulfilling the need they fill for the sake of those in need.

Me, that’s the new number for the emergency services.

Actually, that’s the only phone number I can remember :D

In fact, I prefer that capitalist model at this point having seen countless OSS/nonprofit efforts turn into glorified abandonware.

At least the business has an interest in remaining a going concern and maintaining the stack.

If we could find a credible DNSSEC advocate (for our audience; that is: a cryptography engineer, vulnerability researcher, or an engineering leader at a major firm), we would absolutely invite them on.

'teddyh below gave you links to two pro-DNSSEC resources; fun note: the latter source (Geoff Huston, one of the world's more respected networking researchers) has since then written this:

https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/.

  Competition
  Jurisdiction
  Resilience
  Biodiversity

Yes, there are ways to configure IPv6 to isolate subnets, separate local traffic from internet traffic, set up firewalls and DMZs, run local DNS, etc., but they're all more complicated to configure and administer than their IPv4 equivalents.

This is security theatre. People have been saying that NAT is not a security feature for over a decade:

* https://blog.ipspace.net/2011/12/is-nat-security-feature/

but the message still has not sunk in. The "Zero Trust" paper was published by John Kindervag in 2010:

* https://media.paloaltonetworks.com/documents/Forrester-No-Mo...

Most modern attacks start from a compromised internal host (e.g., from phishing), or through stolen credentials via a remote access method. The above is "castle-and-moat" thinking that tends to have weaker internal controls because it is thought the internal network is "hidden" from the dangerous outside network.

Set your firewall to default deny, then add a rule for allow outgoing connections, followed by only allow incoming connections if they are replies. For most machines (and networks), most of the time, this is what's needed: the above is applicable for both IPv6 and IPv4 (with or without NAT).

The protection comes from filtering (generally) and stateful packet inspection, not from hiding addresses.

> […] and having no distinction between a local IP and a public IP has a lot of disadvantages.

Just because something has a global addresses does not mean global reachability (see default deny above). Further you can layout your IPv6 address plan so that you can tell at a glance if hosts are externally accessible. Using a /48 a basis, you break out sixteen /52s, numbered $PREFIX:[0-f]000::/52.

To make it easier to remember what is externally accessible, you put all of those hosts in $PREFIX:e000::/52, where e stands for external. That /52 can then be broken down into:

* sixteen /56s

* 256 /60s

* 4096 /64s

or any combination thereof. See Figure A-5 for various ways to slice and dice:

* https://www.oreilly.com/library/view/ipv6-address-planning/9...

Everything in $PREFIX:[0-d,f]000::/52 is not externally reachable.

For the love of expletive this mistaken belief needs to have died yesterday. NAT boxes help primarily because they also contain a firewall. But most of 2024's network security problems originate from the devices behind your firewall getting exploited through their on requests, not some random shit connecting from the outside. (Yes, that does still happen, so you keep your firewall.)

> no distinction between a local IP and a public IP

https://en.wikipedia.org/wiki/Unique_local_address

I'd rather not wait until they have a (quasi-)monopoly on something though. Twitter was great until…

Last I checked, it hasn't solved DNS yet (there are unofficial projects trying to do that). I tested a small private network with a few devices and it worked very well.

Eh, I think that has hindsight bias. Setting up NAT manually, or customizing how things are NATed beyond the typical "one or two subnets/IP ranges behind a NAT gateway and maybe a DMZ" you see in businesses and residences is quite complicated! It's just that our control planes are really optimized to make that common case very easy. From router web UIs to pf presets to Windows'/NetworkManager's "share network" functionality to what articles/how-tos are available, that complexity is very effectively hidden but not removed.

As IPv6 becomes more entrenched (and more sites move to IPv6-only or public-IPv6-only deployments), the same thing that happened for the IPv4 world will happen for network segmentation configuration in the IPv6 world: it will get a lot easier and common defaults/conventions will emerge. I don't think the inherent complexity differences between IPv4 and IPv6 are that relevant here.

Well, for a long time, IPv6 didn't work very well. We're past that, mostly. Google reports that 45% of their incoming connections worldwide are IPv6.[1] Growth rate has been close to linear, at 4%/year, since 2015. IPv6 should pass 50% some time in 2025.

Mobile is already 70%-90% IPv6. They need a lot of addresses.

Most of the delay comes from enterprise networks. They have limited connectivity to the outside world, and much of that limiting involves some kind of address translation. So a "corporate IPv6 strategy" is required.

[1] https://www.google.com/intl/en/ipv6/statistics.html

Riddled with viruses.

This is a lie. A "session through the NAT" does not really expose the host to the outside world, because in 99% of the cases this is a TCP session, and the NAT machine would drop all "out of order" packets.

>Most modern attacks start from a compromised internal host (e.g., from phishing), or through stolen credentials via a remote access method.

Your statement is a perfect example of https://en.wikipedia.org/wiki/Survivorship_bias.

Most modern attacks start from an internal host exactly because NAT makes external attacks infeasible for the majority of scenarios.

>Set your firewall to default deny, then add a rule for allow outgoing connections, followed by only allow incoming connections if they are replies.

What about I don't do it, and the system is still _automatically_ secure, because NAT does exactly that while being _required_ for the system to work.

>See Figure A-5

LOL. What about I don't see any figures, and the system still works and is secure for the 99% of the cases.

That is Survivor Bias at its best.

The originate _inside_ because NAT effectively blocks all _external_ requests.

  Eight six seven five three oh nine
  Eight six seven five three oh nine

You mean the firewall effectively blocks all external requests.

I don't understand why they didn't just add two or four more fields to ipv4 e.g. 0.91.127.0.0.1 is localhost where 0.91 can be omitted in the local context.

PS: I don't understand how networking works. Feels very very complex and full of jargons.

This is the Cloudflare problem all over again. One day Matthew Prince will get hit by a bus, all the "trustworthy people" will leave, a PE firm will take the company private, and merge it with an ad network. Congrats, the entire internet now has a single companies ads all over it and we let it happen because we happened to like the people fucking us.

Hell I can’t get tech people I work with to give me their public IP.

No, it's not. NAT only translates addresses and does not inspect the TCP "internals" (like sequence number etc, which would allow it to block certain packets).

What you are describing is a stateful firewall that allows "reply packets" for an established TCP-session.

It's a fact of life that working with networking that we'll have to work with IP addresses at some level. It's easy to tell someone, "hey try typing in 'ping 8.8.8.8' and tell me what you get".

The readability of IPv6 is, in my opinion, worse with repeated symbols and more characters to remember. The symbols that were chosen were also poorly thought out. Colons are used in networking a lot of times when you want to connect to a service on a particular port, so if you want to visit 2001:4860:4860::8888 in your browser, you have to enclose the address in square brackets.

The reason NAT works for this is because by default there are no Internet-accessible services available via the router. If a request is received by the router that doesn't match an open port, its OS will, by default, reject it, with no firewall required.

That's why people don't necessarily, and shouldn't, trust that Tailscale won't head down the same path. It's hard enough for non-profits - heck, the Mozilla Foundation is losing all the good will they've ever had, and even the Raspberry Pi Foundation decided to gaslight people when they started eyeing corporate money.

If there's an open source way to do a thing that's a pain in the ass and a way to do the same thing from a for-profit company, I'll take the pain in the ass thing every time. History has shown it to be the prudent thing time and time again.

NAT is not required for any of the things you’re talking about.

An example IPv4 address is 8 to 12 digits:

  10.30.115.5

  2001:db8:404:14::42

  2001:db8:404::42

  site 2001:db8:404::
  net              :14::
  host                ::42

But, there are billions of other devices (IoT etc). that barely has any security protections in place that rely completely on not being exposed to the outside world.

A simple protocol is more likely to last.

IPSec is not always a VPN protocol. L2TP over IPSec is often used as one, but IPSec does little more than encrypt a tunnel between two IP addresses. IPSec in tunnel mode can be a minimal VPN, but it's not used as such as in VPN scenarios without a second packet encapsulation protocol, as it lacks authorization beyond key exchange.

As for the risk of ossification: that didn't go away with the current system either. HTTPS over TLS 1.3 looks like a TLS 1.2 session resumption on the wire (in its default configuration) because shitty middleboxes are used often enough that it would impede the protocol.

The "let's remake TCP over UDP" approach QUIC takes has very similar origins. UDP is generally allowed by random firewalls over that network, while other (more suited) protocols for this type of stuff like SCTP are not. The operating system doesn't allow opening raw network sockets without high privileges, so adding a new QUIC protocol at the layer of TCP and UDP to implement them at the right spot in the stack wouldn't be usable for many devices. Same is true for the TCP stack you have to use what the OS provides or get higher privileges to do your own; patching the TCP state machine isn't practical. So, if you want to implement a better version of TCP optimised for web browsing and such, you use UDP, because while technically incorrect, it'll work in most cases and has the least restrictions.

In the context of the network, IPSec is the new protocol here, not the result of ossification.

IPv6 doesn't have that problem, though.

Or, you know, because firewalls block stuff.

I've had hosts with public IPv4 addresses attacked on (e.g.) tcp/80 and tcp/443 because that's what the firewall allowed through so the web service was available to the public. I've had hosts with internal IPv4 addresses attacked on web ports because they were behind a (reverse proxy) load balancer for serving traffic: the fact that they had a 10/8 and were behind a NAT did not protect them from attack.

Before recently switching ISPs, my last one had IPv6 (new one does not). They activated IPv6 at some point, and I enabled it on my Asus, and suddenly all my internal devices got an IPv6 address (via RA), including things like my printer.

I had SSH enabled on my macOS laptop and desktop, but could not SSH into them from an outside source. My printer has a web interface on port 80 that I could connect to internally, but not externally. Even though all the devices had IPv6 addresses.

Just because a device is globally addressable does not mean it is globally reachable.

> What about I don't do it, and the system is still _automatically_ secure, because NAT does exactly that while being _required_ for the system to work.

Because NAT is doing that I describe, so you are doing it. The firewall is checking state on incoming packets and rejecting those that are not in its state table. The firewall is also coïncidentally just happening to also be fiddling some bits in the address field.

It is the stateful inspection that is protecting you.

* https://en.wikipedia.org/wiki/Stateful_firewall

what happens with an incoming packet if there are no firewall rules on the NAT gateway/middlebox? without having a corresponding conntrack entry they will be dropped (and maybe even an ICMP message sent back, depending on the protocol), no?

for example if there is an incoming TCP packet with a 4-tuple (src ip, src port, dst ip, dst port) ... by necessity "dst ip" is the public IP of the NAT box, and on a pure NAT box there are no bound listening sockets. so whatever "dst port" is .. unless it gets picked up by an established NAT flow ... it will splash on the wall and getting a TCP RST.

isn't the argument that "NAT is not required", but that "NAT is implicitly a firewall"?

IPv6 is completely useless and doesn't solve this problem.

Normal people don't care if they have to pay 5 dollars instead of 50 cents to rent an IP address. This is a problem specific only to the huge providers, and we don't need to rollout a whole internet upgrade just to optimize a tiny part of the operational costs for huge providers.

> should be accessible from anywhere, and be secured at the end points, not at the network layer

If you're not securing at both the network layer and the endpoints, then you have utterly failed security and you need to go sit in the dunce corner.

No. The "internet" is literally the "inter-network", a way to connect private networks between each other.

The fact that VPN technologies sit behind proprietary corporate intellectual property is not by design, it is a failure of the internet standardization process as it was gamed by corporate interests.

Because they thought that 64-bits would not be enough, and did not want to have to go through yet another transition.

The IPng proposal that was chosen, SIPP, was originally 'only' 64-bits:

* https://datatracker.ietf.org/doc/html/rfc1752#section-9

See also §10.2:

* https://datatracker.ietf.org/doc/html/rfc1752#section-10.2

Specifically (§11.1):

    * scale - an address size of 128 bits easily meets the need to
      address 10**9 networks even in the face of the inherent
      inefficiency of address allocation for efficient routing

See perhaps stateless NAT:

* https://wiki.nftables.org/wiki-nftables/index.php/Performing...

Yes. And you can not-expose them via default deny firewall rule.

My home printer had an IPv6 in a prefix assigned from my ISP, but it was not accessible to the Internet (it was actually ping6-able because my Asus allowed ICMPv6 by default, but I could not connect to its web interface, like I can internally). Neither could I SSH into my macOS desktop or laptop from the outside (but could between the two internally).

And even if my globally addressable devices were globally reachable (which they were not), good luck scanning a /64.

Still is.

> I've had hosts with internal IPv4 addresses attacked on web ports because they were behind a (reverse proxy) load balancer for serving traffic: the fact that they had a 10/8 and were behind a NAT did not protect them from attack.

You explicitly set up a NAT bypass (reverse proxy) and then claim NAT didn't protect them. If I am an external attacker coming in towards a single public IP where the backside hasn't set up UPNP/Port Forwarding/STUN/Reverse Proxy, NAT does exactly what the previous poster said. It drops packets because the 'destination' is the router itself in the packet. It has no where else to go, it has literally reached its destination.

A stateful firewall is in no way necessary for this functionality to exist. Even UDP stateless packets cannot bypass the NAT because there if there is no table tracking the conversation from the POV of the inside->out initiating the conversation because the router would have zero idea which interior host to forward the packet to and no reason to do so.

“I guess the question we should be asking is — if we want a secured namespace what aspects should we change about the way DNSSEC is used to make it simpler, faster, and more robust?”

I'd argue it's just enough to make the difference though.

The problem is that people got used to being able to rely on memorizing IP addresses. IPv6 does its best at making IP addresses both harder to memorize, and completely dynamic, going so far as to change the IP on a fairly regular basis. It's antithetical to some very core qualities that an IP address is supposed to have in the minds of many.

You get a Full Cone NAT. Once the middlebox maps an (internal IP, port) tuple to an external port, every connection to that external port would lead to that internal tuple.

Why should Host C be able to reach Host A, when Host A is only speaking to Host B?

I am sure you know this but still, I have to stress that NAT is merely a mapper from one tuple to another tuple. If your router can handle NAT it certainly can handle an IPv6 firewall. And modern home/SOHO routers come with IPv6 firewall enabled by default (for the non-home routers, you have a bigger issue if your networking guys are not checking whether firewall is active) so I find the firewall discussions utterly as meaningless as someone fearing their DHCP server is not turned on by default. And frankly speaking, it's just an excuse for not implementing IPv6 -- saying that your ISP doesn't provide IPv6 connectivity would have been more convincing.

I think you misunderstand my post. My "philosophical inquiry" is about trying to get to the bottom of this, and it seem to me that NAT, as virtually everywhere deployed and found in the unspeakably many SoHo setups, is a stateful NAT, and it's implicitly a bad firewall.

So when people say that this is "meme" should die .... well they are right, but not technically right, no?

If you do this, your application has no listening ports on the WAN, LAN, or host OS network and thus cannot be attacked from the external network/IP.

The asymmetry of risk now favours the defender, not attacker. Oh, plus we also have pre-built tunnelers for endpoints if you cannot do app embedded.

The point is not that "it can", the point is that on ipv4 "it doesn't work without".

In order for ipv4 to work at all you MUST use NAT, and implicitly a firewall, those two always work together even if there the person installing the system doesn't know the word "firewall", which is usually the case.

Yes it is. How would it forward response packets back if it doesn't track connections?

In real life I haven't seen "stateless NAT" for about 20 years.

But cgnat machines usually go beyond that and even verify sequence numbers.

Hmm. I hadn't seen this brought up and I think it's a stronger argument than most others.

The IPv6 equivalent is services on ULA only, but that's not a default behaviour.

For example, every existing solution touts "security" and yet completely mangles the difference between authentication and encryption.

Authentication is important - you don't want random servers or users to enroll on your network, and you want good tools to rotate and manage secrets.

Encryption isn't important unless you care about state-level actors sniffing your traffic at the backbone. (And if you care about that then you already have your own datacenter.)

Meanwhile encrypting all network traffic is a huge performance penalty. (Orders of magnitude for some valid use cases.)

The wackiest example I've seen of this is the `ipv6-literal.net` notation for Windows UNC paths: https://devblogs.microsoft.com/oldnewthing/20100915-00/?p=12...

I have a SaaS-crush on buf because they did such a good job on fixing such an annoying problem.