I implemented the current NAT system in Linux. In particular, avoiding port reservation in favor of squishing more connections into one IP address, as long as the remote address allowed us to differentiate.

This, in turn, means incoming traffic from a different address is unroutable. You no longer have a public endpoint. This is "poor man's firewall", but erodes our ability to have a server the way we used to.

I was a young engineer solving a specific problem, without considering the larger picture. It wasn't the only thing, but I feel it definitely moved the internet to a client/server infrastructure and a key equality was lost.

A lot of this feels like a requiem for the days when the only people on the Internet were "high-computer-skill" type folks. Most people will gravitate to "user-friendly" solutions: Gmail and other managed email providers were popular because they didn't stop working when you shut down your computer to save electricity, when your server's hard drive crashed, when you upgraded your computer to something with a faster processor, more RAM, and a newer operating system. It was hard enough to educate laypeople about URLs and email addresses (AOL keywords, anyone?), let alone a combination of random numbers in an IP address, or convincing people to register domain names.

Yes, NAT shoved fences into a network that was all about connecting everybody. But we'd still end up with server-client cloud architectures, even if we had started with IPv6 in the beginning. ISPs would have just sold highly restrictive firewalls as part of their home-install basic boxes, and we'd still have ended up with those fences.

FWIW I (writer of blog post) am 21 years old and just a bitch lol

Skype was originally peer-to-peer for comms, but ended up with "super-nodes" because of NAT limitations (not sure if STUN/TURN/ICE had been invented by that point). BitTorrent is still peer-to-peer. A number of folks ran Mincecraft servers at home, but you'd only be able to have one on the default port.

But this doesn't only hurt server-y stuff: you may not notice it if you're with a legacy MegaISP with lots of money to throw at IPv4 allocations, but if you're with a younger or smaller ISP, then there's a good chance you're behind CG-NAT, so many console games won't work.

This works, until you have more than one person accessing your server. Then you need to worry about accounts, credentials, data isolation, etc. And then if a couple of people connect to your server and start using it, you have to worry about staying online, staying updated, backing up the data. But other than that... yes, trivial.

And just to be really explicit, you always have more than one person accessing your server, and most of the time they are unwanted users trying to break in.

Thankfully, we have wireguard now. It drops all packets by default. From the perspective of people who don't have the requisite cryptographic keys, it's like the computer is not even there to begin with.

I've always found it strange how people just put computers out there on the internet and just allow them to interact with total internet randoms. Why are we allowing our computers to talk to strangers? No wonder people are getting hacked.

Exactly. Of all the reasons why the average person doesn't have an Internet-visible server, NAT, I would say, is pretty far down on the list.

In fact you could have an IPv6 address for each user, and if one starts becoming troublesome both revoke account and stop using that address.

You could create a new IPv6 address every millisecond, and it'd take 584,868,233 years to exhaust a IPv6 subnet (/64).

Jill from Elbonia may be always be a threat, but this doesn't mean that Joe from Accounting is not a threat or cannot ever provide a vector for Jill. :)

The thing about smartphones is that they are both completely dependent on wireless connections to central servers in order to function and completely unsuitable to operate as servers. If you forced your phone to serve files anyway, your battery would drain quickly and the CPU would be drowning in its own waste heat. You might argue that you could still do non-server things on the phone, but practically speaking, a node that can't handle server tasks is just a leech. P2P networks work on a mutual aid basis; they require the majority of nodes be capable of shouldering traffic or sharing files in order to be a net benefit. If you add, say, tens of millions of new mobile phones to the network, the network will become unusable as any desktop machine gets DDoSed by hordes of phones asking for a babysitter.

So even in the world where IPv6 did to v4 what v4 did to NCP, we'd still ultimately end up with "my files go in the cloud", because clouds are coinventions of smartphones, in the same way that cars are coinventions of suburbs. You can't have one without the other, and once you do have both, they become so economically dominant that others get socially coerced into using them.

Obviously it's all very basic, but with a few years of development and polish (and probably someone besides Nokia copying the idea) I think this would be a compelling product. You could basically have the same feature set as something like iCloud but without the subscription or your files going elsewhere.

"Naturally, people noticed this was a problem almost immediately, because people have wanted to run game servers, FTP servers, and web servers from their bedrooms since roughly the beginning of time."

TCP/IP was in use for at least thirteen years before the first "commercial ISP" offering internet access oustide of work or school

In 1994 the www had only been public for less than twelve months

According to one source, 11 million US households got internet access in 1994

https://www.pewinternet.org/2014/03/11/world-wide-web-timeli...

In 1994, there were over 97 million US households

https://fred.stlouisfed.org/series/TTLHH

According to another source, "no one" had home internet access in 1994

https://www.ntia.gov/sites/default/files/data/fttn99/FTTN_I/...

Did the majority of internet users want to run servers from their bedrooms

In 1994, the majority of the US population did not even have a home computer

(Perhaps everyone reading this had one but that's not the majority)

In some ways, little has changed. Organisations like academic institutions, governments and large businesses can have internet access without "NAT"

Everyone else is an afterthought

And most internet subscribers still have no interest in running servers from their bedrooms

If anything, NAT has saved millions of wildly insecure devices running unpatched old Windows versions from getting pwned the second they connect to the open internet.

The conceit behind NAT is that 99% of traffic over the router will be client-server and the last 1% can get away with separately negotiating with the router to get inbound traffic.

For example my ISP Xfinity by default will put your router in CGNAT space (and ipv6) but if you request port forwarding from a mobile app the upstream router will assign you a ipv4 address and it all works. NAT is considered fine because adding roadblocks to server hosting is a acceptable tradeoff.

The reason they i think they can be so flexible is that they likey have a ipv6 backbone to route to all the customers and ipv4 is not used for routing but as a extra service layered on top with packing the 48 bits of ipv4 and port inside a ipv6 address via MAP-T

IPv6 just works. DNS gives me the address and that's it, I am now talking to my remote computer.

Going to a model of "you don't get a public IP address, all traffic must go through servers other people host for you" is what finally kills the open Internet. It's okay enough for cell phones where it's a hack to work around TCP/IP's lack of roaming support, but it should be illegal to deploy as residential Internet.

You can have a stateful firewall that blocks non-established-connection packs and all your publicly addressable devices would not be reachable. NAT ≠ firewall (though they often glommed together on CPEs).

And NAT is also giving a false sense of security in some ways: "this device has an RFC 1918 address so is not reachable, and therefore safe". Yeah, except if another device already on the inside is / gets compromised. Perhaps if everything had a public address folks would be more circumspect.

Right, but it's easy to get in the mindset that because devices are on the "inside" network they are safer. This is the risk that NAT brings: RFC 1918 = safe(r).

If every device has a 200::/3 address, then even if there's a SPI firewall which prevents external connections, it may help to reduce this inside/outside thinking.

I don't think NAT being a janky ad hoc firewall does anyone a service. It shields the devices enough to keep the developers oblivious about security, but not enough to stop them from connecting to arbitrary hosts. This perpetuates the humongous botnet ecosystem.

I doubt it.

Very few devices do port NAT without also doing firewalling, since firewalling is simpler.

This is worse for everyone in so many ways:

1. Forwarding ports suddenly makes you insecure, because you already were.

2. You have to fuck with your router config to even do that, and risk breaking something else along the way. Nobody should have to bother, because port forwarding shouldn't exist in the first place.

3. Many ISPs make it difficult or impossible to configure your firewall, let alone reserve a static public IP.

4. It's an eternal problem that isolates itself from any true solution. Any actually good UPnP implementation would just be stuck behind your NAT and firewall.

The entire premise "as long as you can control it" is the core issue, and the fundamental reason why NAT is the original sin. Without NAT, there wouldn't be anything to get control of.

If you try to use those port forwarding hacks, you force every single piece of software to deal with the fact that the IP address it sees for itself is not the IP address its peer sees for it. And you force every single protocol design to allow for that possibility. Add in UPNP, and now you have to implement a whole extra (badly designed) protocol in parallel with the actual application.

It's not trivial to even discover the address your peer is seeing; even now there's a huge diversity of nasty unreliable hacks for doing it.

HTTP isn't the world. In fact, HTTP becoming "the world" was another part of the problem.

In an alternate universe (or a current one with IPv6) every home router would have a default deny inbound security policy, and home admins could punch holes as needed the way they do today with port forwarding.

Its definitely the opposite. People started ignoring security because its "natted" anyways, even though NAT was never supposed to be security-critical. Thats what firewalls are for.

I sent them a screenshot of her shared drive through ICQ, and not long after she bought a router.

Software was created with no security because no one demanded it because no one cared. Technologies that came later did not create that situation.

This might not be a good thing. Perhaps if there had been no protection for those odious operating systems, they'd have died the horrible deaths they earned decades ago. We should only want to protect things we intend to keep, after all, and none of us wanted to keep that garbage.

I know of zero systems that can survive exposure to the raw Internet, unpatched and without administrative oversight, with uptimes of years.

Sure. And as long as nothing has to survive exposure to the raw Internet, no one will build anything that could survive it. Not sure why that's so difficult to understand. You seem to think that the protection is the reaction to dangerous operating systems, when it's the cause.

In the "real world", you don't really need that much security. Your actual security comes from the fact that all the worst criminals are already locked up, most of the would-be criminals are afraid of being locked up, and if somebody does actually commit a crime, they will get locked up and won't be able to do it again for a good while. A lot of real-world security is about post-factum detection (think alarms, CCTV, panic buttons etc), because in the real world, detection and prevention are two sides of the same coin.

This only works because if a real-world crime happens, the criminal by definition is in the same location as the victim, and law enforcement cares most about the community they serve. If the criminal is across the world, as is the case in cyberspace, even if it's a friendly country, it's often "not their problem". This means internet systems need actual security, and NAT provides exactly that.

If not for NAT, we'd all need a firewall, and things would be almost if not exactly the same. In the real world, "leave things relatively open, because locks are mostly for keeping honest people honest" is a valid strategy. This strategy doesn't work on the internet.

You still need a firewall regardless of NAT. Otherwise, every time you take your computer outside of your home, you're no longer protected. Any attacker or compromised device on your hotel, airport, or coffee shop wifi network would have direct access to your machine.

A NAT implementation could broadcast any "WAN" side incoming packets to all link local clients (aka: put everyone in the DMZ). The only thing preventing that is a stateful firewall.

There's probably a field of study with vocabulary and accompanying proofs of significant rigor that prove or disprove this. Maybe they'll stop by our little subthread and clear it up.

This is a very common misunderstanding. NAT and firewalls are separate concepts. You can also have NAT with no meaningful firewall -- a port remapping NAT that allows anything through.

Most IPv6 networks are firewalled but there's no NAT.

You could share things easily, sure, but anyone could get hacked pretty easily and very targetted.

After NAT, sharing was still easy lots of 'piracy' apps, various messengers with NAT passthrough

Both before and after you needed to be technical, you can't ask someone that doesnt know about computers to set up an FTP server, and if they did it would be a nightmare and they'd likely share their whole drive

Same goes for anything else.

Anyway, we'll get the whole non-nat with IPv6, let's see what that brings

Correct. Every home wifi router worth its salt will firewall incoming connections by default, whether v4 or v6. It's then possible (unless it's some shitty ISP-provided locked down device) to add specific allow rules, or allow all for a particular client.

egress is typically wide open, although sometimes they lock down particular protocols by default (eg. smtp, bittorrent)

That's mostly because a phone is very locked down, can you run an accessible ftp server on your phone?

It's also not windows

If you want to use the standard port, that's only true as of very recently, though, see https://issuetracker.google.com/issues/218578943#comment17

I would invest in a proper firewall for the entire home before opening up anything to the world, IPv6 or not.

You can have firewalls with no NAT just fine. You can also have NAT with no firewall.

NAT is not about security and never was. It's about stretching the IPv4 supply and allowing each endpoint to just get one precious V4 IP.

I'll believe it when I see it. So far it doesn't look like IPv6 will win anytime soon.

Ultimately I think none of this will be solved at the low level, it needs something like Iroh or libp2p where you build a new network on top of the Internet infrastructure, so that you can have things like persistent cryptographic identities and addresses that you can carry with you, largely independent of the underlying network architecture.

I don't see a reason why my machine addresses should change over time... then again, most shouldn't have direct internet access anyway, a http proxy on firewall should be enough.

You can still use fixed addresses locally if you want, its not like IPv6 is forcing you to use the prefix assigned if you just want to communicate locally over never-changing addresses.

You can have your computers be fd01::1, fd01::2, fd01::3, etc, and talk to everything on their local addresses when wanting to stay local. And then when they want to talk on the public internet they can just use whatever public addresses like 2600:1700:53c2:2573:4c:c001:dead:beef based on whatever prefix your ISP gives you.

Its not like your devices have to only have a single IP address.

At home it can be if I connect t to my ip6 ssid, but there’s a stateful firewall which may as well nat.

Well, good to know!

This is the draw to onionv3 services for me. It's still exactly like this.

I made a post the other day wondering why they aren't way more popular than they are. Do most people just not know? It's a pretty nice thing to be able to do.

Especially in a world where you can create your own utilities very easily, it's the perfect way to gain back some sovereignty over your compute in the age of CGNAT.

Sure it's not blazing fast or anything...but it's perfectly adequate for 90% of things.

1) The typical "NAT" is a "PAT", which requires state for mapping traffic flow. An implementation is going to look very similar to a stateful firewall, by necessity, not accident.

2) The use of RFC-1918 addresses behind the router / NAT box provides some protection. If your address is not globally reachable, it's much harder to reach any hosts behind it. Yes, a poor implementation might allow direct routing from adjacent networks, like your ISP or neighbor. But that still isolates you from 99.99% of the internet.

I ran Linux, *BSD, and Solaris systems for years without any firewalls, host or otherwise.

Absolutely not. They can charge your $9.99/mo so you can connect their craptastic app to their craptastic cloud so you can "use their app from anywhere".

Because of NAT, hierarchy (centralized servers) is the foundational design pattern of the internet, and anyone who wants any semblance of anarchy (decentralized networks) must use a workaround that is itself hierarchical and costly. We are all interconnected, but only a wealthy few can truly speak fist.

The issue that ipv4 exhausting and "solutions" around it like NAT are making it very hard for actual users (bussiness, people etc) to get access to public IP space without strings attached.

IPv6 solves a lot of this, especially because IP space is so massive LIR's don't need to be so spare with giving out address space.

The far larger issue we have is that applications are ingrained in a client server mindset, in which big incumbents want to have this architecture because it forces control from the server towards to client. And control usually also means having the data itself, which is where the real value lies.

The sin here is the hierarchy imposed by SSL and its infatuation with server names. Its says: these people are lords, they can wear the server hat. As for the peasants, your client hats are over there. If we catch a peasant wearing a server hat, the browsers will make them look like a criminal.

Our applications have evolved accordingly.

Working around NAT was trivial for the people who actually cared about it. I was adding port forwarding rules to my parents' router at age 12. Turns out exposing a poorly-configured Windows XP box to the wider interwebs is a Really Bad Idea - and for the same reason UPnP letting random unpatched shady P2P applications do the same is Very Much Not Good.

Let's face it: consumer devices simply aren't secured well enough to let the entire internet poke around in them, and it was even worse a decade or two ago. Decentralization is pointless when it only results in people compromising their own machines, and the people with the skills to set up a 24/7 Linux server in a broom closet won't care about adding some NAT forwarding rules.

Even without NAT, we would've definitely gotten home internet routers firewalled with a default-deny policy on all incoming connections. Exactly the same "manually configure a bypass, or use UPnP" dance blocking you from trivially running a web-available service on your machine, but with a firewall rule rather than a NAT port forward.

It's of course a different story with CGNAT, but that only became a thing well after the internet was already centralized.

May be due to US DoD holding large amounts of IPv4 for no reason

Vendors have been pushing it though, because implementing IPV6 only somehow is still a very, very scary thing for large ISP's to pull off.

what should happen is it should be very easy to deploy ipv6/4 translation mechanisms in ipv4 only networks, this would allow easy interopability and make it easier for the large networks to push IPV6.

At that price point you can get a small vm, but if you have a dedicated server you want to use on-prem, 10$/mo seems like a reasonable price.

> Or I can use DHCP, where my IPv4 address can change at their whim.

Check the dhcp.lease to make sure, I used to think that, then I looked at the dhcp lease and the IP was being reserved for up to 48 hours of disconnection. I went years without it ever being released.

Phone operators won't necessarily transmit this information to you, the true ISP operator is the DHCP server. Not only is it more knowledgeable, but DHCPd has no incentive to upsell you, just provides you with what it is configured to.

I'd even go as far as checking if you can send parameters during the dhcp lease request, maybe you can request a longer lease on the IP.

There's a right way to do things, it's not trivial to discern from the wrong way to do it, but once you see it, you notice that you lose almost nothing, it's not like the 'wrong' way is simpler, it's just 'wronger', all the way through. I guess the reason they persist is sunk-cost fallacy, the businesses and people that went with NAT then developed STUN, and then they developed ICE, and then they develop Tailscale, every time you need to invent a bigger spade to dig you out of the hole and into a deeper one.

Or you can just use IPv4. But aghast, you have to pay 10$/month (or learn DHCP)

Every. Single. Individual. End. User. Device. Should. Be. Addressable. Given that there are more such devices out there then there are IPv4 addresses to begin with, cost doesn't even come into it.

No, the question was taking the price that the NIC sells the IP blocks at. Understanding that in order to get 1 IPv4 address you will be buying from a distributor at a markup, but still, with Wholesale prices at 0.6$ (LACNIC) to 2.5$ (ARIN) per IP address per year, even with a markup of 300%, we are still at filthy cheap prices (2.4$/year to 10$/year)

>Every. Single. Individual. End. User. Device. Should. Be. Addressable. Given that there are more such devices out there then there are IPv4 addresses to begin with, cost doesn't even come into it.

Oh, ok, I was writing mostly about server side IPv4 assignment. I guess your position is a much stronger stance than mine, I argue that all servers should have an IP(v4) adress, you argue that every client device should. In that sense, consider that there's a lot of users, on this website even, that insist on running hosts without a dedicated IP address. There's lower hanging fruit.

http://github.com/richlegrand/bitbang-cli

I've been using it and it certainly has the potential. I signed up for Cloudflare's TURN server which you use with bitbang and it gets you 1TB free data transfer per month.

Why do so many people still think NAT equals firewall when they're not directly related?

I guess it's because they're normally packaged together for practical reasons. They're both packet handling functions often performed in the same place. But they are NOT the same and you can have either one without the other. Most IPv6 networks have firewalls, and it's possible to have NAT that liberally passes anything.

I wonder how much this misconception has delayed V6 adoption? "But I'll be wide open without NAT!" No, you can have a firewall. Most IPv6 routers have stateful firewalls on by default.

The reason NAT is seen as security on home networks is that, absent a firewall, it acts as a default deny to inbound traffic.

If I wanted to blame large corporate "users" for NAT (which I actually do), I would blame their obnoxious intransigent refusal to upgrade to IPv6. That part wasn't the ISPs' idea, but it had nothing to do with the cost of address space and everything to do with shortighted laziness. They were, in fact, willing to pay for IPv4 space to avoid having to do anything.

The idea of router sounds simple and like it should implement some standard protocols. But in practice -- a lot of it is a mishmash of proprietary, ad hoc shitware. Something I never hear spoken about is the deep packet inspection filter component of the router firmware. It's a part of the router that decides on what traffic is allowed / not, and almost no company publishes this part. So you're not even in control of your own Internet traffic, tiny blobs of code written by some company get to decide if something is allowed or not.

If that sounds sus AF and kind of a bad idea -- well, it is. You can always run 100% open software with open-wrt. But the thing is -- the Internet isn't just your part of it. It's a network of networks, and all those shitty routers, with all that shitty firmware, is deeply ingrained within the entire Internet. That's millions of devices that would need to be replaced to fix the issue.

I've never heard of a claim like this, so I'm really curious. Note that I'm not talking about the huge DPI market for corporate/state networks.

https://news.ycombinator.com/item?id=49454785

> Even more ironic is that NAT got normalized as a security feature — “your devices are hidden!” — which is one of the things that made people resist the thing that would fix it.

That tracks. I briefly looked into the Tailscale website and I thought maybe I was wrong, maybe it's not a NAT/ddns toolchain, maybe it's something more complex that I'm too dumb to understand. But if my thesis that it's NATware is right, it makes sense to market it as a security product, it fooled me for one, but it also passes as a quality product for an organization, and they feel they are getting a security product when they are actually signing the purchase request of a developer that is applying networking techniques they learned from managing a videogame server.

I use it in 3 ways:

1. My phone connects to my home network by joining the tailnet. I can play music and movies from my home server when I am away. No struggles with configuration. 2. A dedicated mini pc at home is on a smart plug. I keep it powered off mostly. I can turn the plug on remotely and power the mini pc. It runs "tailscale --advertise-routes" which then exposes every device at my house to the tailnet. No open ports, but suddenly my phone thinks that it is back at home with all my home PCs. 3. I take my laptop with me and use "tailscale serve" which serves as a pipe. I can pipe my home movies to a smart TV at your house. Just install the jellyfin app, and browse for servers, and my server in my house appears in the list at your house.

the first lets me provide locally hosted services without exposing them to the internet, by allowing members of the VPN ("tailnet" in their parlance) to connect to those services

the second was very handy to move a few users from a company in the process of shutting down to their homes, so they could continue to work like they had in the company network once the actual internal company network was shut down.

The other common but completely distinct usecase of VPNs being residential usage to encrypt traffic and even more distinct, with the purpose of masking the true origin of a request.

In the former type of usage, which is the one you use, I think any VPN system would fulfill your purposes, of course you have to use something, but I'd venture a guess that you are using the generic features of tailscale, not its commercially distinguishing features. But they are still very on brand, generic or not.

fwiw, the author/founder seems to have made a career out of building post-hoc hacks in one layer to fix the shortcoming of other layers, to take memcached as an example. I don't think my thesis is novel, that these types of hacks are subpar when compared to solving the issue at the appropriate layer, it's part of the tradeoff of the technologies, but I'm just particulary opposed to any hack that allows server admins to skip the step where they get a dedicated IP address, I'm less opposed (but still) to other types of hacks.

The main selling point is acting as a relatively efficient private overlay network, giving you a consistent private network even as devices move between different internet connections. (Something that NAT makes a bit harder but you don't get for free even if NAT isn't a factor)

But if I see a user that exposes a server without a dedicated IP address, and they use tailscale for this, the way I would describe it is that they are adding a third party node that routes traffic for them (just to provide multiplexing), so in terms of security, it's an additional unnecessary man in the middle. It's a testament to the marketing team that they are able to sell it as 'added security'. It's hard to know exactly how such open infra technologies are used, but I get the feeling that a good part of the customer base is buying tailscale to patch up a bad infra decision, while being (self) deluded into thinking that their system is very bleeding edge and secure.

Props to tailscale actually, lots to learn here, the lesson is to let the client save face and sell your tech not as something that fixes an embarassing mistake, but as something that's a bit opaque, high tech and implements security protocols, even if performatively.

Bonus points if there is upsell or onramp into actually sound technologies, like eventually you have to drop the whole tailscale thing and help the client actually get an IP address right? Or maybe even onboard the rogue ddnsed service onto the organization's existing ASN. It's a hard sell because the best solution in that case actually removes the product from the organization altogether, but I can imagine ways were the product stays in a non-central, QA-like sidechannel.

If you are listening on a public IP, you can trivially be attacked by anyone on the Internet.

If you listen on a private IP that only Tailscale can reach directly, you can only be attacked by Tailscale itself, or by anyone who successfully infiltrated Tailscale's network.

Should you run plaintext protocols over Tailscale? Absolutely not. But you're going to receive orders of magnitude less malicious traffic on a server accessible only over Tailscale compared to a server listening on the public Internet.

It just works: connect devices and they immediately show up in their portal. Most config is just clicking, but more advanced things can be configured as well. Definitely feels like a high quality product, not just something thrown together by a developer that learned a few network techniques.

Huh. Why are you doing this, is the datacenter IP being (rightfully) blocked by some service to avoid abuse? Is your usecase breaking some services ToS?

Certainly adding more fire to the "never a GOOD reason to use this" thesis

So you make up reasons to be judgemental and then insist they're right?

It's practical to block entire datacenters. It's not so "right" that working around it becomes "wrong". If whatever the server's doing can fit through a single home connection then it's probably fine.

I'll give you a concrete use case: A few times a month I want to wget a file on imgur to my server. That's a valid action miles away from any kind of abuse, but the IP range is blocked so I use my desktop to do it. If I routed it over tailscale instead that would be equally valid.

When I consider that quality of IPv6’s design, it communicates to me an old and ideal vision of what we thought the internet would and should be - a hyper-connected, shared infrastructure where [Layer 3] identity is universally unique such that connectivity between any two arbitrary nodes is possible (which obviously isn’t true for NAT w/ overload).

I’m just a lowly SysAdmin who finally decided to get his CCNA - so I’m a nobody - but as I worked through the material I felt like I was paging through a history book or biography of how the Internet’s life came to be and all the mistakes made along the way. Most features felt like patches for design considerations that were overlooked. Examples: DHCP Snooping, STP’s various * Guards, and the mere fact that Layer 2 and Layer 3 addresses are distinct concepts.

I don’t think there’s any disagreement that NAT was co-opted as a security feature. I never hear that said in a positive way, either. I think if we were to start over, with IPv6 as the default assumption, the tools we’d develop for network security would look very different, but not at all impossible or any more difficult.

But again - I’m a nobody. Just thinking out loud here.

So, of course, we then got Privacy Addresses, or whatever the name is. Which now means that you don't actually have a stable unique public IP, it actually changes all the time, and legitimate tracking and logging of your own network activity actually becomes much more complicated on IPv6.

If it weren't you couldn't have the same IP over several interfaces.

>mere fact that Layer 2 and Layer 3 addresses are distinct concepts.

The logical separation between the ideas allows for a lot of flexibility, and there were some wrong answers on how scalable vs flexible things should be.

Ethernet and IP beat the shit out of everything else: https://en.wikipedia.org/wiki/Protocol_Wars

They emerged with a decent answer: L2 crosses intranetwork, L3 crosses internetwork. Their separation allows L3 addressing to be completely unaware of multiple changing L2 (lower level) intranetwork switches, which is immensely useful.

Trying to solve everything with One Master Protocol to solve it all turned out like this: https://xkcd.com/927/

IPv6 solves this by doing neighbour discovery on link local addresses and multicast addresses.

This is the cost to splitting your routing between layer 3 and 4.

I'm now IPv6 everywhere, and so I get to just use ping. Much simpler.

Further, protecting IPv6 services is simpler, because I can terminate (m)TLS on the backend. With a reverse proxy on another host, I have to have yet another means of securing the proxy-backend path. Yet more complexity!

> And the fact that consumers can't just directly connect to each other is a feature.

Consumers should be protected by firewalls. That's independent of routing.

New network growth (mobile, Africa, Asia) uses it, old growth stays on v4 and will eventually roll over. People with address space usually don't need much more, but the IPv6 space better reflects how connected the world is - we're gonna need a bigger address space than v4, that's for sure.

New protocols shipped quickly on rough consensus and working code and weren't perfect - some left all kinds of undefined behavior, or lacked clear advantages over predecessors and competing protocols.