IPv6 isn't hard, and as the article alludes to, it is different, but it's not even that different.
What is hard, is dual stack networking. Dual stack networking absolutely sucks, it's twice the stuff you have to deal with, and the edge cases are exponentially more complex because if your setup isn't identical in both stacks, you're going to hit weird issues (like the article suggests) with one stack behaving one way and the other behaving another way.
None of this is the fault of IPv6, it's a natural consequence of the strategy of having two internets during the transition period. A transition period which has now been going on longer than the internet existed when it started.
Maybe 100 years from now we'll finally be able to shut off the last IPv4 system and the "dream" of IPv6 will become a reality, but until then, life is strictly more difficult on every network administrator because of dual stack.
(Note: no, we could not have done it any other way. Any upgrade strategy to IPv4 that extended the address size would have necessitated having two internets. It just sucks that it's been this long and we're still not even at 50% IPv6 usage.)
For what it's worth I have many years of technical experience and a pretty decent knowledge of IPv4 networking, and I found it quite hard - at least when first learning.
The addressing is intimidating, getting your head away from NAT, thinking about being globally routable, the lack of (or variances in) DHCP, ND, "static" addressing via suffixes, etc.
None of this is technically "hard", but it's a significant barrier to entry because it's quite different to what most normal technical users are used to.
Dual stack may create some new problems, but it fixes a lot of others. All of the major cloud providers have awful IPv6 only support, and many prominent web resources that usually invisibly "just work" have little to no IPv6 support.
I think you thought it was hard precisely because you had a decent knowledge of IPv4.
I suspect that if the situation were reversed and we always had IPv6, and someone proposed a new IP suite where you had to use NAT for everything, and all hosts needed to have their addresses hand-picked (or served via a DHCP server that used an ugly hack to communicate with hosts that don't have an IP yet), you'd find that to be the "hard" one.
The one objectively difficult thing about IPv6 is remembering an address. Four base-10 numbers between 0 and 255 fit in working memory, while eight groups of four hex digits don't. Even a shortened address can be difficult to recall.
I can remember two numbers from 0 to 255, but four? Not in a million years.
Isn't there an idea that our working memory holds seven pieces of information? Which would be two of those numbers and change, if you consider each digit as a piece of information.
We live in an era with ubiquitous DNS, easy host file management, post-it notes still exist, and everyone has some note taking app or three on their pocket computer too. At some point if needing to remember an IPv6 address is your biggest concern with IPv6, that's a decent place to live and there are plenty of workarounds all around you.
If you want to increase adoption of a technology then the onus is on you to convince everyone else. I think being dismissive of the human element is not going to help you very much.
First of all, I don't have direct skin in this game, it's not my job to convince people to use more IPv6. (I think it's a good idea, but I'm not here to convince anyone.) Second of all, I wasn't being dismissive at all, I listed a number of good workarounds to enhance the human element, because yes human memory is (very) fallible. I'm also in the category that I've never been able to keep IPv4 addresses in my working memory (I can have a bit of dyscalculia, myself, and sometimes know all the individual digits but be entirely unable to retain their order among each other). I've personally always needed these workarounds, and was just providing a list of options for those new to this need. (Welcome to the club.)
I also could have mentioned mDNS as a distinct subclass of DNS. That's most of what I use in IPv6 LAN stuff, personally, but I don't have a lot of subnets to worry about. Also I could have mentioned tricks like writing down a subnet prefix somewhere such as a .env script and using assigned addresses full of zeroes in that prefix like $PREFIX::1, $PREFIX::16, $PREFIX::cafe, or also, if you really want, and just miss dotted quads that much: $PREFIX::136.324.154.123 (that's been a supported address format for a few years now as long as it is on the right side of a :: shortcut).
Yeah, it makes me think of finding an automatic car difficult because you're used to manual. I have noticed people are often reluctant to give up on something they had to learn, though.
It doesn't help that the use of an IPv4 is a status symbol that indicates that you are willing to spend money on your infrastructure (and are thus not a spammer). If you attempt to run an email server on IPv6, you will see what I mean.
That's not what I am observing while running a number email servers which having both IPv4 and IPv6. Spam is only on IPv4 and about 80% of legitimate email is on IPv6.
Yes, but those facts don't reach the email filtering business: There, IPv4 IPs have some reputation, maybe good or bad. IPv6 "just doesn't exist" and has a universally bad reputation. Thus your IPv6-Emails will be filtered and dropped more often, even though you are correct that actually IPv6 is an indicator of non-spam. I've got quite a few transport rules to work around those kinds of braindead filters...
> I've been sending my mail via IPv6 for ages without issues…
In most cases it does work and there are no problems. But especially medium-sized businesses who run their own email through some crappy mailfiltering middlebox file anything that comes from or through an IPv6 endpoint to spam.
> did you mean reputation or reputation?
I don't understand your question. I meant IP address reputation, which is what many mail filtering systems use to estimate spam probability or outright reject email. See for example https://www.spamhaus.org/ip-reputation/
That does not match my experience either. In fact I don't see why any mail server would bother getting and configuring an IPv6, listen on it, just to drop all received messages.
Just don't listen on v6, that would achieve your goal, would prevent reputable dual-stack senders (like Google!) to send messages over v6 that you'll drop, and simplify your configuration.
> I don't understand your question. I meant IP address reputation, […]
There's reputation of the IP address(es) among spam filters, and there's reputation among human operators configuring mail servers. I was trying to riff on ambiguity with ambiguity, that wasn't particularly helpful, sorry.
I found an open email relay on IPv6 once, because nobody scans IPv6 and therefore nobody ever sent spam through it. (Apparently this was caused by a reverse proxy misconfiguration causing the server to think IPv6 connections were from localhost)
And yet scanning IPv6 is exactly what some people are doing.
IPv6 nodes aren't individual random addresses in a 128-bit address space. They are going to be grouped in subnets, so it makes sense to explore /64 ranges where you know there's already at least 1 address active. There's a pretty decent chance at least some addresses are going to be sequential - either due to manual configuration or DHCPv6 - so you can make a decent start by scanning those. For non-client devices, SLAAC usually generates a fixed address determined by the NIC's MAC address, which in turn has a large fixed component identifying the NIC's vendor. This leaves you with a 24-bit space to scan in order to find other devices using NICs made by that vendor - not exactly an unfair assumption in larger deployments. Much faster scanning can of course be done if you can use something like DNS records as source for potential targets, and it's game over once an attacker has compromised the first device and can do link-local discovery.
It's not going to be extremely fast or efficient, but IPv6 scanning isn't exactly impossible either. It's already happening in practice[0], and it's only going to get worse.
In many situations it's a necessity. Ipv4 only devices can't connect to ipv6 only servers. So if you have ipv4 clients, your server has to support ipv4.
Yes. In my day job I work mainly on containers running entirely in data centers we own, they are fully ipv6, it’s very nice to work with.
Then there is this one customer, they are colocated in other ISP owned datacenters, and some of their server maybe have fully IPv6, some may have only IPv4, some may be a mixture of both. Supporting them is a never ending nightmare.
The really sad thing about IPv6 is that it's a relic of a bygone era. The internet was envisioned as a thing where every device on every network could, in principle, initiate a connection to any other device on any other network. But then we started running out of addresses, ISP's wouldn't give you more than one for a household, so we started doing NAT, and that kind of sealed the internet's fate.
Nowadays, we wouldn't want a world where everything was connectable, even if we had enough addresses. Everyone's network in essence has a firewall. If you run IPv4 and using NAT, you're going to be dropping unsolicited incoming packets no matter what (let alone that you wouldn't know where to route them even if you wanted to let them through) and with IPv6 you'd be insane to allow them.
Devices have "grown up" in a world where we expect the router we're connecting to, to shield us from incoming unsolicited traffic. I certainly don't have the firewall enabled on my linux desktop. Windows I _think_ has it enabled by default, but I often turn it off because I want LAN connections to work. MacOS is probably similar. Suffice to say, if the IPv6 dream happened overnight and everyone's devices were instantly connectable, all hell would break loose. We need our routers to disallow traffic. (Edit: This wasn't all that clear, so let me restate: In both the IPv4 and IPv6 world, you'd be insane to disallow incoming unsolicited traffic, which is why basically everyone blocks it in IPv6 as well as IPv4. I'm not trying to say IPv6 can't do this... quite the contrary: IPv6 routers absolutely do, and should, block unsolicited incoming traffic. But my point is that this is what prevents the original vision of IPv6 from becoming a reality: We can't design software around the idea of direct peer-to-peer communication, without stuff like UPnP. Oh, and UPnP works with NAT and IPv4 anyway so, there's the rub.)
So, even in a pure-IPv6 world, that instantly prevents any startup with an idea to allow true peer-to-peer communication using end-to-end routability. What are you going to do, train your users to log into their router and enable traffic? Approximately 0% of your customers know how to do that, even in a counterfactual universe where IPv6 happened and we all have routable IP's on our devices. Maybe in such a universe, people would be trained to use local firewalls on their device, and say "ok" to popups asking if you want to let software through. But I'd wager that a lot of people would prefer the simplicity of just having their gateway drop the traffic for them.
No, the "all devices are routable" idea came from a naive world where there wasn't a financial incentive for malicious behavior at every turn. Where there aren't millions of hackers waiting for an open port to an exploitable service they can use to encrypt all your data and ransom it for bitcoin. The internet is a dark forest now. We don't _want_ end-to-end connectivity.
Every consumer router I’ve ever seen drops unsolicited IPv6 packets by default. But that doesn’t mean that P2P routing is suddenly impossible.
IPv6 makes P2P routing substantially easier, even in a world of default firewalls that drop unsolicited packets. You can still apply standard NAT busting techniques like STUN with IPv6 devices behind firewalls, and you get much better results because IPv6 removes the need to track and predict the port mapping a standard NAT does. Two P2P systems can both send unsolicited packets to each others IPv6 addresses, with a specific port, and know that port number isn’t going to be remapped, so their outbound packets are guaranteed to have the right address and port data in them to get their respective firewalls to treat inbound traffic on those addresses and ports as solicited.
This is particularly useful when dealing with CGNATs, where your residential devices ends up behind two NAT layers, both of them messing with your outbound traffic, which just creates an absolute nightmare when trying to NAT bust. IPv6 means that you’re no longer dealing with three or more stateful NATs/firewalls between two peers, and instead only have to deal with at most 2 (in the general case) stateful firewalls, who’s behaviour is inherently simpler and more predictable than a NAT ever is.
The argument that NAT-busting (firwall-busting?) becomes easier with IPv6 is certainly true, but "easier" isn't necessarily enough to warrant an entirely new protocol suite. If that's the only benefit of IPv6, it doesn't sound worth it to me. UPnP/STUN is still possible with NAT/CGNAT, and you're going to need something like that even if there were no NAT, so to me it sounds like a bit of a wash, at least to the end-user.
(Of course, the other huge benefit of IPv6 is "more addresses", so we need it just for that. But my point is that "global routability" isn't really the dream people think it is. In practice, the only differences between modern GUA-but-deny-by-default IPv6 setups and NAT'ed IPv4 setups are the simplicity of the former for the network administrators.)
You should tell that to my ISP, they’ve managed to deploy a CGNAT that’s proven to be completely STUN proof. The only way I can achieve any kind of P2P comms is using IPv6. IPv4 is useless for anything except strictly outbound connections.
> and you're going to need something like that even if there were no NAT, so to me it sounds like a bit of a wash, at least to the end-user.
Not in my case. As above, I simply can bust my ISPs CGNAT, so IPv6 is invaluable to me. Makes a huge difference to me, the end-user.
IPv6 doesn't actually save you because it presumes a cultural norm that people will use globally unique addresses for all their networks which, while now possible, I imagine many network engineers will use IPv6's private address space to avoid ever having to re-address their network on ISP changes.
> I imagine many network engineers will use IPv6's private address space to avoid ever having to re-address their network on ISP changes.
Except with 10/8 (or 172/12) everyone is using the same address space. How many network have a 10.0.0.0/24? What are the odds of a conflict for that?
But if you have an ULA FDxx:xxxx:xxxx/48 address space, what are the odds that all those x bits will be the same for any two sites? That's 40 bits 'entropy'. Much, much lower (notwithstanding folks doing DEADBEEF, BADCAFE, etc).
Not only that. Having private IPv6 addresses in the LAN is the easiest way to work with two ISPs and have fail-over. The other way is RFC8475, but I don't know of any implementation except my custom script on OpenWrt: https://forum.openwrt.org/t/ipv6-wan-fail-over-without-ipv6-...
I imagine the threshold of org size where they stop taking their prefixes from their ISP and just go get their own from the RIR is .... Not big.
Sure, some network engineers will try and design v6 networks as though they're v4, but everyone else will just go and get a squillion addresses from the RIR that's unique to their org and then just use/announce that.
Home networks don't usually have the problem of having to suddenly merge together with another, similarly-addressed network.
Nothing stops you getting a subnet allocated from your local RIR and announcing that on the internet, if you care about that sort of thing for your home network though. You just need a decent ISP.
> Nothing stops you […] You just need a decent ISP.
I’ll just leave that there.
No, I can’t just choose to have a decent ISP. I live in the real world where there’s only one choice where I live, same as a rather large majority of people in the world.
'You should switch your working local networking stack so as to help the scenario where the company is bought and you may well not be working there anymore and it's someone else's problem. Or the scenario where the company buys a different company and very likely needs to investigate and remodel the other company's network anyway.'
1) To the extent to which you can't ask them to change their CGNAT setup, you also can't "just" ask them to upgrade to IPv6.
2) In fact you at least can ask them to change their CGNAT setup, as they at least could, if they chose, unilaterally fix their CGNAT setup, while--even if you also felt it possible to ask them to upgrade to IPv6--upgrading to IPv6 as the solution requires the rest of the world to upgrade as well.
The real question is then: which is solution to your problem is easier and cheaper to obtain, and the answer is clearly not "upgrade the world to IPv6". "I couldn't convince my ISP to fix their CGNAT setup, so I'd rather convince them--and everyone else--to upgrade to IPv6" makes no sense as a coping mechanism.
The model of having every router being a firewall has created a fair bit of false security, with vulnerable systems being left behind the firewall and simply waiting until a user inside the network does something unwise. It seems a common story where whole hospitals or municipalities get shut down because one host got infected and then all the unpatched system in the same network got hit.
There is also a bit of conflated use of terms. A firewall on windows is just a fancy name of permission management. A program want to open a port and the user get a prompt if they want to allow it (assuming the user has such privileges). It is indistinguishable from similar permission system found on phones that ask if an app is allowed to access contacts. The only distinguishable "feature" is that programs might not be aware that the permission was denied, thus opening a port that is not actually open. Windows programmers may know more of the specific of this.
So your idea is to open up access so all the IT orgs that can't keep their systems secure ...
... which is ... virtually all of them ...
get p0wned on a massive scale? You know, now with AI powered assaults for extra special vulnerability levels...
And then a magic wand happens, and the IT orgs that couldn't even install patches will be able to back-discover all the compromised hard drive firmwares, rootkits, and nth-level security holes after the fact?
I get a NAT wall isn't perfect security. But pretending it is NO security is disingenuous.
Every company in spoken to in the last few years has been moving toward zero-trust network, where you assume that every single device is on a hostile network. There’s nothing inherently safe and secure about the corp network, so treat it as if all those cubicles were connecting in from Starbucks.
Not the parent but obviously no, but maybe if in the 90' it was the standard to not assume that the network was secure we would be in a better spot now (maybe a spot where company intranets use authentication instead of vpns
You have a firewall at the edge of the network. It blocks incoming connections by default, but supports Port Control Protocol. The cacophony of unpatched legacy IoS devices stay firewalled because your ten year old network printer was never expected to have global connectivity and doesn't request it. End-to-end apps that actually want it do make the requests, and then the firewall opens the port for them without unsophisticated users having to manually configure anything.
The protocol is an evolution of NAT-PMP (RFC6886) for creating IPv4 NAT mappings, but RFC6887 supports IPv6 and "mappings" that just open incoming ports without NAT.
Sure, but is it actually a feature you want, though? We're never going to run out of legacy unpatched devices, and today's shiny new devices are going to be tomorrow's tech debt. If you support that kind of hole punching, sooner or later you will end up with vulnerable devices exposing themselves to the internet.
There's no way in hell enterprise admins are going to give that kind of control to random devices, and home users aren't going to have the skills to cull vulnerable devices from their networks. So who's going to use it?
In my opinion the current kind of hole punching is a far better option: instead of creating a mapping allowing essentially unrestricted access from everyone, have the app use an out-of-bounds protocol to allow a single incoming connection from exactly one vetted source. You get all of the benefits of a direct peer-to-peer connection with none of the risks of exposing yourself to the internet. It's well-researched when it comes to the interplay between firewalls, NAT, and UDP[0].
And that pretty much solves the problem, to be honest. These days you only really need incoming traffic to support things like peer-to-peer video calls. Hosting game servers on your local machine is a thing of the past, everything has moved to cloud services. What's left is a handful of nerds running servers for obscure hobby projects at home, but they are more than capable of setting up a static firewall rule.
> We're never going to run out of legacy unpatched devices, and today's shiny new devices are going to be tomorrow's tech debt.
It's not about new or old. The devices that don't have any reason to be globally reachable never request it. New ones would do likewise.
Devices that are expected to connect to random peers on the internet are going to do that anyway. It's not any more secure for them to do it via hole punching rather than port mapping; causing it to be nominally outgoing doesn't change that it's a connection to a peer on the internet initiated by request of the remote device.
> There's no way in hell enterprise admins are going to give that kind of control to random devices, and home users aren't going to have the skills to cull vulnerable devices from their networks. So who's going to use it?
Enterprise admins can easily use it because they have control over the gateway and how it answers requests, so they can enable it for approved applications (in high security networks) or all but blocked applications (in normal networks), and log and investigate unexpected requests. They should strongly prefer this to the alternative where possibly-vulnerable applications make random outgoing HTTPS connections that can't easily be differentiated from one another.
Whether they will or not is a different question (there are a lot of cargo cult admins), but if they don't they can expect their security posture to get worse instead of better as the apps that make outgoing HTTPS connections to avoid rigid firewalls become the vulnerable legacy apps that need to be restricted.
Home users are already using NAT-PMP or UPnP and this has only advantages over those older solutions.
> instead of creating a mapping allowing essentially unrestricted access from everyone, have the app use an out-of-bounds protocol to allow a single incoming connection from exactly one vetted source. You get all of the benefits of a direct peer-to-peer connection with none of the risks of exposing yourself to the internet.
There are significant problems with this.
The first is that it's a privacy fail. The central server is at a minimum in a position to capture all the metadata that shows who everyone is communicating with. It's made much worse if the payload data being relayed isn't end-to-end encrypted as it ought to be.
But if it is E2EE, or the server is only facilitating NAT traversal, the server isn't really vetting anything. The attacker sends a connection request or encrypted payload to the target through the relay and the target is compromised. Still all the risks of exposing yourself to the internet, only now harder to spot because it looks like an outgoing connection to a random server.
Worse, the server becomes an additional attack vector. The server gets compromised, or the company goes out of business and the expired domain gets registered by an attacker, and then their vulnerable legacy products are presenting themselves for compromise by making outgoing connections directly to the attacker.
Doing it that way also requires you to have a central server, and therefore a funding source. This is an impediment for open source apps and community projects and encourages apps to become for-profit services instead. The central server then puts the entity maintaining it in control of the network effect and becomes a choke point for enshitification.
Meanwhile the NAT traversal methods are ugly hacks with significant trade offs. To keep a NAT mapping active requires keep-alive packets. For UDP the timeout on many gateways is as short as 30 seconds, which prevents radio sleep and eats battery life on mobile devices. Requiring a negotiated connection is a significant latency hit. For real peer to peer applications where nodes are communicating with large numbers of other nodes, keeping that many connections active can exceed the maximum number of NAT table entries on cheap routers, whereas an open port requires no state table entries.
> What's left is a handful of nerds running servers for obscure hobby projects at home, but they are more than capable of setting up a static firewall rule.
The point is to allow interesting projects to benefit more than a handful of nerds and allow them to become popular without expecting ordinary users to manually configure a firewall.
> It's not about new or old. The devices that don't have any reason to be globally reachable never request it. New ones would do likewise.
Doesn't this assume all devices are well behaved, trusted and correctly implemented? You don't think the crap Samsung Smart TV will consider itself to have a reason to be globally reachable?
Most of them actually wouldn't because they have no reason to do it and creating the mapping for no reason is work. Making the thing where you're not exposed to the internet the thing that lazy developers get by default is a win.
Some of them could do it for no reason, but they could also have the devices make outgoing connections to the company's servers and then blindly trust any data the servers send back, even if the servers are compromised or the domain expires and falls into the hands of someone else, or the company's own servers are simple relays that forward arbitrary internet traffic back to their devices.
If a device can make outgoing connections then it can emulate incoming connections. Blocking incoming connections to devices that explicitly request them is therefore not a security improvement unless you're also prohibiting them from making any outgoing connections, because the result is only that they do it in a less efficient way with more complexity and attack surface and less visibility to the user/administrator.
Interesting, I haven't read much about that. I've always assumed somebody must have written an RFC to automate how home firewalls should be configurable automatically by software that "wants to" allow incoming connections. Good to see that it exists.
But it doesn't seem to be in widespread use, does it? Like, would a random internet gateway from podunk ISP support this? I kinda doubt it, right? Pretty sure the default Comcast modem/router setup my mom uses doesn't support this.
But I guess my point was about the contrapositive universe where IPv6 was actually used everywhere, and in that universe I suppose RFC6887 might have been commonplace.
Every ISP router I've had with even basic IPv6 support has supported PMP. Every home router I've handled with IPv6 support has supported it. So IME it is in pretty widespread support. Maybe there's some devices out there that don't, but it's at least as wide as UPnP support which was pretty wide.
Things like this can be useful without 100% penetration. Most end-to-end apps support a direct connection as long as either of the endpoints have an open port. Endpoints without one can also fall back to relays, but since port mapping is frequently used in gaming, that has higher latency and then users start demanding gateways that support the thing that lowers lag.
Then it starts to make it into popular internet gateways. For example, the Comcast consumer gateways generally do support UPnP, which is a miserable protocol with an unnecessary amount of attack surface that should be transitioned to Port Control Protocol as soon as possible, but it demonstrates you can get them to implement things of this nature.
> What are you going to do, train your users to log into their router and enable traffic?
You do what has already been done for decades. You ship a client premises router that does deny by default inbound and allow all outbound and things behave pretty much the same as they do today with these exact same rules in IPv4.
Network firewalls still exist in a publicly routable network. If I want my game console to allow incoming traffic for game matchmaking, I can then do that. Or have systems that auto configure that. But then I don't have to have multiple devices fighting for a limited port range, each device has more IPs and ports than they could know what to do with.
Please re-read my comment, as it seems like you skimmed it and think I’m making a different point than I did.
To use your example:
> If I want my game console to allow incoming traffic for game matchmaking, I can then do that
My point is that because of the fact that even in IPv6, consumer firewalls will block traffic by default, the company that makes the game would not have designed it to require your console to have special configuration on your firewall. Because this is not something a typical gamer knows how to do.
Instead, companies use UPnP for matchmaking, and UPnP works in both NAT and GUA environments, so what exactly does GUA give you?
If you have two Xboxes or Nintendo Switches in a standard UPnP network you'll still have NAT issues. They'll fight over port assignments. If I've got two things wanting to listen on :5000 I'm boned, I've only got one :5000 to forward from. I could remap that port in NAT, but now the downstream device needs to know to tell other clients it's actual public port.
You'll have even more problems if you're on CGNAT networks. You're not going to be able to get any of that traffic.
None of this is a problem if each device has its own IP address and its own range of ports to deal with. Every device can have its own :5000, it can know it's public IP address without having to have something see from outside, and with how big assignments usually are it can have dozens of things all listening on a public :5000 all at the same time.
If you want to hypothesize a world where we’re all on IPv6 and thus game matchmaking software can take advantage of the unique addresses for every console, you should also admit that the same software could also just use a unique port for each console today, in IPv4+NAT.
In fact, in IPv6, privacy addresses mean that the address the gaming service observes from my device shouldn’t be assumed to work for other peers, because my device may only be using that address for communication to the gaming service itself. Instead, authors of this software ought to understand that the console itself needs to tell the service “this is the address peers can use to communicate with me”, and thus you may as well just include the port in that call, and then you don’t need to assume port 5000 will work (because if I have 2 XBox’s, they could decide on a different port if another console already has one used.)
It’s just I’m disillusioned with the idea of GUA’s for every device actually solving anything. It solves like 10% of the difficulty of writing good p2p software. All the other problems are still there: firewall config, dynamic IP’s, mobile IP’s, security best practices, shitty middleware boxes not doing the right thing, etc etc etc.
My biggest argument would be CGNAT in the end really doesn't care what UPnP you do at the edge of your network; you're not getting that traffic no matter what you do. IPv6 means there's no reason to have CGNAT at all; there's more than enough addresses to go around.
Does IPv6 solve it all? No. Does it solve some of it better than IPv4? Yep. Does it just completely eliminate the need for CGNAT? Yep. It is not a silver bullet to solve all problems, but it does solve some, and for that I'd much rather use it. Because I'd rather just be able to host whatever at home and not need to remember what port is what or rely on proxies looking at other info in the request.
> shitty middleware boxes not doing the right thing
You reduce the need for shitty middleware boxes. I don't need a reverse proxy. I don't need to have a STUN/TURN server. I don't need to randomize ports or worry about running out of ports.
> the same software could also just use a unique port for each console today, in IPv4+NAT.
Why solve a problem once properly in the network stack when you can add an ad-hoc workaround to each individual protocol instead?
> the console itself needs to tell the service “this is the address peers can use to communicate with me”, and thus you may as well just include the port in that call, and then you don’t need to assume port 5000 will work
And if you're behind CGNAT so your home router doesn't know what the address and port are, what then?
Not to mention the case of a multiplayer game between two people who live in the same house and a third person who doesn't. That's one that's trivial with IPv6 but difficult with every IPv4-based system I've seen.
> It solves like 10% of the difficulty of writing good p2p software. All the other problems are still there
It all helps. I mean, people mostly manage to play games with each other today, they just get disconnects or random lag every so often. Cutting down on that, even if it was only 10%, would make a lot of lives better.
I'm dealing with the devices I've got and the software stacks they have. In the end they fight for port assignments on IPv4 and expect to just have massive port ranges assigned to them.
> Within the port range, enter the starting port and the ending port to forward. For the Nintendo Switch console, this is port 1024 through 65535.
Fixing the broken software that somehow requires a specific port and getting NAT-PMP deployed is a hell of a lot easier than redoing all of the software and all of the networks to implement IPv6.
In an IPv6 world, your home router still firewalls just like with IPv4 (the NAT is just an extra accidental firewall-ish thing), you can still skip the firewall on your laptop
Having globally allocated address space doesn’t actually imply openness of connectability
I am the last person to be defending NAT, but the benefit of NAT is that it sets up a really good default: incoming connections are not routable by default, and it's very hard to accidentally change this. There are many good ways to have "not routable by default" with IPv6, but you have to do that at the software level, while NAT forces it at a protocol level.
> incoming connections are not routable by default, and it's very hard to accidentally change this
Not just difficult, but impossible, even in principle, because there are more than one device sharing the same IP so at most one host would be vulnerable. Not the same as with IPv6, where screwing up the defaults leaves your entire network vulnerable.
Yeah, server-side NAT + use of a reverse proxy makes hosting many websites from one IPv4 a possibility, albeit a relatively difficult one. You are only really in trouble if two consumers want raw TCP/UDP on one port.
Parent poster is making the (good and underrated) point that NAT makes this logic failsafe: Turn an IPv6 firewall off and you’ve got all incoming connections allowed. Turn IPv4 NAT off and you’ve got no connectivity at all
Or make the "turned off" state block all traffic, just like closing a water valve, or a road gate. I never understood why network firewalls did not default to this.
How are you gonna get the IPv6s of your targets? Can’t scan a /64, and with ephemeral ”security” addresses used for outbound conns, an adversary won’t be able to guess the address anyway. At least that’s my understanding. So I guess my question is: is this a real threat?
This was the norm for most of the 90's and earlier. NAT was supposed to be the exception, but it became the rule. Now we have an entire generation that doesn't understand that the Internet was always supposed to support end-to-end connectivity.
Plus too many of that generation see NAT as a "security feature" not an "IP bug" and can't seem to (re-)imagine traditional firewall/router design from the time before NAT. "end-to-end connectivity" is not the same thing as "open and unsecured connectivity", we have the security tools to deal with that and they are not and have never been named "NAT".
To say NAT has nothing to do with "security" is a lie. The most common NAT (PAT) configurations are basically acting as stateful firewalls with a default deny policy for all unsolicited inbound traffic to a private, non-routeable network.
They aren't doing that though. The most common NAT (PAT) configurations don't deny unsolicited inbound traffic.
They are of course commonly deployed together with a firewall that does deny that traffic, but claiming that NAT blocks connections because it's usually deployed together with a different technology that handles all of the blocking would also be lying.
> The most common NAT (PAT) configurations don't deny unsolicited inbound traffic
That doesn’t make sense.
If I have a single routable IPv4 addresses and 100 machines behind it with RFC1918 addresses, how can any possible router “allow by default” say, port 22? Which machine would it route it to? Would it pick the first one? Randomly select one?
Of course NAT has to drop incoming unsolicited packets. Unless you tell it which machine to route them too, it couldn’t possibly know how to “allow” them in the first place.
IP packets have a "destination IP" header field that specifies where the packet goes. The router reads that to figure out where to send the packet.
The only thing NAT does is rewrite the dst or src headers of packets. If there's no rule or state entry that applies to a packet, it doesn't drop the packet. It just leaves the original headers on it.
How would a packet with a destination IP of my internal RFC1918 address have landed on my WAN interface in the first place? It would require my ISP to have a routing rule that sends it to my router. Is that the threat model you’re thinking about?
Stateful Firewalls are the security tool. NATs being mediocre to somewhat alright stateful firewalls "out-of-the-box" before adding a real Firewall is the accident (and sometimes bug). Something doing security by accident (or as a bug) isn't a security tool (just like security through obscurity isn't a security tool). You can have Stateful Firewalls without NAT. Everyone saying that you "need" NAT to have Stateful Firewalls doesn't understand Firewalls or even possibly why "firewall" is and has always been a different word from "NAT". NAT has something to do with security, but that's being generally always paired with a good firewall, not being a mediocre firewall mostly by accident.
It's still basically another mac address or unique identifier for the system, regardless of which local network it happens to be on. Great for being tracked by FAANG, I guess, but I'd rather for my devices use a generic local IP and a randomized mac. There's no reason why the refrigerator needs to be uniquely identifiable on the Internet.
No, v6 addresses are assigned by (or chosen based on) the current network, not permanently associated with a given system. They aren't MAC addresses or unique identifiers.
I wouldn’t want to relay on random caffee’s router to do this for me. I would still end up running firewall more carefully on my end devices. Which for my iPhone I’m not even sure if I can. So probably a personal VPN would be a must.
Sure... But wouldn't you want to treat this random network as hostile anyway? The router might already have port forwarding to the IP you grab from DHCP, not to mention other clients on the network. I'm also unsure how a VPN would help against inbound traffic regardless?
It depends on the VPN and its policies. Some deny all local traffic when active, routing everything through the VPN, and only leave a IPv4 /32 route for the default gateway. Some are more permissive.
A VPN can’t prevent inbound traffic but if the VPN alters the routing table it can prevent the return leg from working. This probably isn’t enough to prevent compromise.
> Having globally allocated address space doesn’t actually imply openness of connectability
Of course not, that's not my point. My point is that because of the fact that your home router still firewalls with both IPv6 and IPv4, any software which relies on being able to "just" connect to a peer over the internet, is doomed. Our networks don't work that way any more (they probably did in the early 90's though.)
My point is that even if we had global routability, we still wouldn't have open connectability, because open connectability is a stupid idea. Which means any software ideas people might have that rely on connectability, are already a non-starter. So why do we need open routability in the first place? (Honest question. This is the crux of the issue. Yes, open routability means you can have a host listen on the open internet, but fewer than 1% of people know how to configure their home firewalls to do this, so it's effectively not possible to rely on this being something your users can do.)
> My point is that because of the fact that your home router still firewalls with both IPv6 and IPv4, any software which relies on being able to "just" connect to a peer over the internet, is doomed.
With IPv6 the only thing you need is PCP (or equivalent).
With IPv4 you need PCP/whatever plus a whole bunch of STUN/TURN/ICE infrastructure.
Just hole punching is a lot easier to support than more-than-just hole punching.
Yeah, I've had to make this point several times. Getting rid of the NAT doesn't rid you of the need for NAT hole-punching and whatnot, since any sort of firewall will need a hole-punching scheme to allow incoming connections.
I'd say the biggest practical objection (not just "NAT is ugly" or "DHCP is ugly" or "NAT is evil since it delayed IPv6") is CGNAT, which really does put a lot of restrictions on end-users that they can't circumvent. The more active hosts stuffed behind a single NAT, the more they have to compete for connections.
> but fewer than 1% of people know how to configure their home firewalls to do this, so it's effectively not possible to rely on this being something your users can do.
And a chunk of that 1% are on WANs that they aren't authorized to configure even if they wanted to.
Devices behind a firewall being routable with IPv6 doesn't mean you're allowed to connect to them by default. And if you want to, you have to explicitly allow that on the firewall. Just like you would open a port and redirect it with IPv4 before. Only with IPv6 you don't have NAT and a redirect. Some people need it and some don't. Again, just like with opening ports.
Please reread my comment, it seems like you're just pattern-matching to arguments you've heard others make in the past and assuming I'me saying the same thing. I'm not. See sibling comments for elaboration.
>The really sad thing about IPv6 is that it's a relic of a bygone era. The internet was envisioned as a thing where every device on every network could, in principle, initiate a connection to any other device on any other network. But then we started running out of addresses, ISP's wouldn't give you more than one for a household, so we started doing NAT, and that kind of sealed the internet's fate.
I thought the problem was lack of upload bandwidth for almost all households without fiber to the home. Surely, if people had symmetric broadband internet at home, then there would have been commercial solutions to allow devices to connect to each other, thereby decreasing the need for giant cloud providers.
"All devices are routeable" is a good idea, because it means when we want devices to be routeable there's a simple and obvious way that should be done.
Where we've ended up with NAT though is worse though: we still need a lot of devices to routeable, and so we enable all sorts of workarounds and non-obvious ways to make it happen, giving both an unreasonable illusion of security and making network configuration sufficiently unintuitive we're increasing the risk of failures.
Something like UPnP for example - shouldn't exist (and in fact I have it turned off these days because UDP hole-punching works just fine, but all of this is insane).
The wish to not have all devices connected to the Internet does not defeat the need of having a protocol that allows that. NAT is merely a workaround that introduced a lot of technical debt because we don't have enought IPv4 addresses. And having IPv6 does not mean that you must connect everything to the internet.
IPv6 Is good and absolutely necessary. NAT is really expensive and creates a lot of problems in large networks. Having the possibility to just hand out routsble addresses solves a lot of problems.
I'm starting to notice a pattern in these threads in HN every time IPv6 comes up. It's kinda like the vim/emacs holy war back in the day. I also see it in threads about Rust vs C++.
There's a kind of holy war, where people pick sides, and if you're "team IPv6", you look for any post that kinda vaguely smells like it defends IPv4, call them ignorant, and respond with the typical slew of reasons why IPv6 is better, NAT is a hack, you can still firewall with IPv6, etc. If you're "team IPv4" you look for the IPv6 posts and talk about how NAT is useful, IPv6 should have been less complicated, etc etc.
It's really tiresome.
Personally, I'm not on either "team". These things I believe:
- We need more addresses
- IPv6 is as good a solution as any, as no solution was going to be backwards compatible.
- We should get on with it and migrate to IPv6 as soon as possible. What's the hold up? I'm sick of running dual stack.
- But don't throw away NAT, please. I want my internal addresses to be stable and if possible, static and memorizable (An fd00::1 ULA [0] is even easier to remember than 192.168.1.1! And it won't change when my ISP suddenly hands me a new prefix.)
- But CGNAT is The Devil. Don't conflate my desire for using NAT at my house for some desire to be behind CGNAT. Again, we should get on IPv6 ASAP to banish CGNAT back to hell.
- Oh and don't pretend that IPv6 would have led to a more decentralized internet. A client/server model is inevitable for so many reasons, and true peer-to-peer where customers just communicate directly with one another is not a realistic goal, even with IPv6. Even with PMP/PCP. Even with DDNS. You just can't design software around the idea that "everyone's router is perfectly configured."
[0] No, I don't actually use fd00::/64 as my ULA prefix, I actually put my cellphone number in there :-P. The point being it's as memorizable as you want it to be.
There aren't any other practical solutions. Debatable if it was the best solution but it is what it is.
>We should get on with it and migrate to IPv6 as soon as possible
Most LANs will run IPv4 forever. IPv6 offers nothing to LANs larger than home labs (when SLAAC is not enough) but smaller than huge companies (when there are more than enough addresses even in IPv4. 240/4 is for every practical purpose private). The community's hostility to NAT/NPT means LAN admins will get it de facto by running another stack internally.
>I want my internal addresses to be stable and if possible, static and memorizable.
Right. But ULAs have ridiculous routing rules. It would take at least a decade for fixes to be deployed everywhere.
>Don't conflate my desire for using NAT at my house for some desire to be behind CGNAT.
Right. But most users don't care.
> A client/server model is inevitable for so many reasons.
Could you elaborate? I’m able to run ULA-only just fine, with one line in my pf.conf to route 1:1 to my GUA prefix. The NAT is stateless.
Maybe you’re referring to the fact that typical OS’s will prefer to use IPv4 over a ULA if both are available? I’ve noticed that, and indeed it’s unfortunate.
>typical OS’s will prefer to use IPv4 over a ULA if both are available?
Yep. There's an RFC for this. I guess it would take a decade to be everywhere.
The Global > Local rule is also unfortunate in some configurations*, but that's more of a result of the end-to-end idea and software not realizing a device can have more than one address...
Is the alternative reality One where all devices can connect to all other devices and come with built-in mitigations for the problems that firewalls are normally used for?
Maybe. In the alternate reality, we probably would have the same threats on the internet as we do today, and the same boneheaded software that misconfigures things, so my guess is that we’d still have consumer firewalls at the gateway that just default-deny everything. Maybe there would be better standards about auto-configuring these firewalls though. (Or maybe the standards we already have would have just been better supported?)
But for certain, today if we had IPv6 everywhere, it still wouldn’t let you design something like a VoIP phone (or a pure peer-to-peer version of FaceTime) that just listened for connections and let other people “call” you by connecting to your device. That software would only be usable by people who know how to configure their router, and that doesn’t make for very good market penetration. You still need something like UPnP, so you’re basically right back to where we are today. At least the connection tracking would be stateless, I guess?
I’m not talking about SIP, I’m talking about a hypothetical piece of software that an IPv6 proponent may typically claim that is made possible by unique GUA’s for each device. My point is that the GUA alone isn’t enough to make this work, you still need:
- UPnP or something like it
- A place to register your address, since they change all the time even in IPv6
And if you need these two things anyway, you can do this with IPv4, with the added change that you also include the port when registering your address, which makes the “multiple phones in a network” thing work.
Port Control Protocol seems to be pretty well supported on most of the devices I own even in IPv6.
And in the end I'm pretty boned if I'm on CGNAT usually. I can pretty much never get my Switch to do matchmaking with peers on IPv4 when I'm on a CGNAT network. If we were all on IPv6, it wouldn't be a problem.
I'm saying "but what about Y" and you're acting like Y is never a valid issue that anyone ever seems to have.
So once again, how do two devices both share port 5061 on a UPnP NAT with a single public IP address? Or even worse, if they're CGNAT'd? It's a simple answer with IPv6...
Again with the not reading. Let me try to sum up my position so we can end this whole “nuh uh!” nonsense.
IPv6 was designed in a world where we thought we’d have a truly peer-to-peer internet where anyone could just talk to someone else’s device. This obviously isn’t what happened. An ipv6 proponent may say “this is because NAT breaks the necessary assumptions”, but that’s extremely oversimplified and wrong.
The reason that, when I use my iPhone to FaceTime my mom’s iPhone, it doesn’t just use SIP to contact her phone, isn’t because IPv4 and NAT. It’s because the very idea of that is nearly impossible to implement at scale even if everyone had a unique address.
I’m aware you can’t have multiple devices behind a NAT address listen on the same port. Thank you for pointing that out, you’re very smart. But it really doesn’t address my point at all, does it?
My point being that the reason we don’t use SIP and related technologies for billions of end user devices today, isn’t because of NAT. It’s because the myriad of other problems that would need to be solved for it to work reliably, and because of NAT. Eliminating NAT wouldn’t really meaningfully change the landscape of how software works. FaceTime calls would still go through Apple servers. People would still use centralized services run in real data centers, etc.
> I’m aware you can’t have multiple devices behind a NAT address listen on the same port. Thank you for pointing that out, you’re very smart.
Ah, finally, you do acknowledge that there are issues that aren't actually solved with IPv4 and NAT. Thanks.
> But it really doesn’t address my point at all, does it?
Lets go back to the first thing I was reponding to.
> it still wouldn’t let you design something like a VoIP phone (or a pure peer-to-peer version of FaceTime) that just listened for connections and let other people “call” you by connecting to your device.
With having a public IP address, PMP enabled on my router, and DNS registration I have this today. My SIP phone here is sitting by, waiting for incoming calls. I don't need Apple's servers for this. Anyone with a SIP client and who knows the name can get to it (or trawls IPv6 space). This becomes a headache with IPv4 with multiple devices all wanting that 5061 port. Sure, one could just also tell people the port and have lots of random ports assigned, but that's just yet another bit of information to get lost, one more mapping to maintain, etc. Imagine if Amazon ran their ecommerce site off a random high number port instead of :443, think they'd get as much traffic?
> With having a public IP address, PMP enabled on my router, and DNS registration I have this today.
That’s cool for you, congratulations.
I’m talking about the broader internet at large, and the billions of users on it, and the software that is written for these billions of users. This software does not behave the way your cool phone does. Because people’s IP’s change. They’re behind firewalls they are unable or don’t understand how to configure. We don’t write software this way for a lot of good reasons.
Now, I keep talking about this, then you bring up “but I have this use case, what about that?” Demanding an answer as if I give a shit that you want to run a SIP phone at your house, and you’re willing to configure your firewall, etc.
My whole point (!!!) is that what you’re doing is not what the billions of people using the internet are doing. When I bought my mom an iPhone, I didn’t have to tell her “ok so, FaceTime only works at your house, you have to reconfigure this DDNS service when your IP changes, you have to configure your router this way, and don’t ever leave the WiFi network or it won’t work, but thank god for ipv6, because it means dad can do all this too for his phone!” No. Because FaceTime doesn’t work that way, nor could it ever, because doing true peer to peer calling was never a thing that would have ever worked at scale. It’s not being held back by NAT. It’s being held back because it was never gonna work in the first place.*
I mean if you’re just going to sling ad-hominems around and invent your own argument so you have a chance at winning it, sure. I’m not aware of the specific RFC’s du jour that are used for auto-configuring routers. But after spending some time looking it up, it seems relatively niche (not as widespread as UPnP), and it appears the last 3 routers I’ve owned don’t support it. (I run an openbsd box with pf currently, but my unifi gateway before that didn’t support it, and the shitbox gateway Comcast gave me before that certainly didn’t support it. I could run a service on my openbsd box to support it but it wouldn’t make a difference because I’m perfectly capable of editing my pf.conf as it is.)
But if you’re gonna dig up other posts of mine to try and get a dig in at me, maybe at least read the rest of the post? You certainly haven’t done a good job of that so far.
Because I indicated that of course a protocol like this ought to exist, but what percentage of users of the broader internet are actually running a router that supports this? If you wanted to come out with a video calling app that only worked if your users had PMP working, what market share would you be losing out on? That’s the topic of discussion here after all (not that that’ll stop you from inventing your own discussion as you’ve continued to do.)
Funny way to say you don't know what you're talking about. If you don't know what technologies are actually out there how can you say what is and is not possible?
> but what percentage of users of the broader internet are actually running a router that supports this?
Most who aren't running their own home rolled pf setup that can't be bothered to read about "the latest" (over a decade old) RFCs.
And yeah, last I ran a UniFi gateway it supported PMP. That was several years ago. If it's a recent model device with halfway decent IPv6 support it's practically a sure thing it's got PMP support. Maybe disabled, but it supports it. Same with UPnP, might be disabled, but probably supported.
I guess you really enjoy feeling superior so I’m just going to give you this one. You win. You’re very smart and you know more about router software than I do.
(I’ll leave you to ponder whether this changes my point at all, but I don’t think it really matters. You seem to be pretty fixated on getting your digs in, so maybe we’ll just end the discussion here. Good day.)
> My post was basically the biggest pile of sarcasm I could conjure and you still took it seriously, congratulations!
> That’s cool for you, congratulations
> not that that’ll stop you from inventing your own discussion
> I don’t think I’ve met someone that truly thinks technological progress stopped in the 1990s and that URL’s and DNS are all we actually need.
And yet you accuse me of ad homenims for pointing out your acknowledgement of not knowing of the last decade+ of networking tech and that I have a need to feel superior. Pot meet kettle buddy.
You've spent so much effort telling me what's possible or not, berating me multiple times, while acknowledging you haven't kept up with decade+ old tech.
The two devices shouldn't both need to be on the one port 5061: we have numerous solutions to that problem at this point, from specifying the port as part of the connection to auto-detecting it using SRV in DNS. Yes: making some small changes to existing software to not assume hardcoded ports is required in this future... but there is no way that those changes would have been (or frankly even still are) harder than the insane solution of reimplementing and redesigning the entire world--requiring its own changes to every protocol (including SIP) and breaking a strict and extremely large superset of the same references that merely needed a port number--to support IPv6.
Because they don't want to have to rely on an external service to find the right port. Just like how your browser doesn't need to be told to connect to :443 for HTTPS. If you're connecting encrypted SIP, the port is assumed to be 5061. Just like HTTP is assumed to be 80, SSH is 22, etc.
In what world do you not need to rely on an external service to find information like this? IP addresses change, people move around, etc etc.
The topic of discussion right now is peer-to-peer software, which is the quintessential thing that is always lauded by ipv6 proponents as the killer app of ipv6, because each device has its own globally-routable IP.
But “what address do I send these packets to?” is like, 10% of the issue with designing p2p software. Users ip’s are always changing. They move around. They go behind firewalls that will block their traffic. They go behind firewalls they don’t have permission to reconfigure. This is the case in IPv4, and it will always continue to be the case even if we were 100% IPv6.
IPv4 can work today for p2p use cases if you don’t make the assumption that the port is static. But that’s like 1 of N assumptions you have to check if you’re writing peer to peer software. The other N of them are all still issues, even in IPv6.
I hope you're not implying that IPv6 solves the problem of knowing what address to connect to.
If you can avoid an explicit port, that can be nice. But anywhere you're using an IP, v6 without a port is longer than v4 with a port. An implicit port is only useful when you're using DNS. (And if you're designing a service, you can choose to use DNS records that contain the port.)
It gives you a public dynamic IP + port combination if your network is NAT1 all the way to the internet. Both IP & port being dynamic kinda complicates things, they ended up inventing a new DNS record type, "IP4P" where IPv4 address and port are encoded as an IPv6 address, and modified WireGuard/OpenVPN clients are required.
We are supposed to solve this using SRV records, but I don't think many consumer-facing apps can do this.
Did you have to look up something to know this site is hosted on :443 or did you just make an assumption? Some kind of standardized port you connected on? Wouldn't it be nice if every device could just assume the standardized ports were available for them if they wanted them?
There's little reason why they couldn't though. Why shouldn't I just call Apple by doing sip://support.apple.com ? Why can't people just call me at sip://desk-phone.vel0city.whatever (they actually can, if they know the right name) or sip://cell.hikikomori.apple.net ?
Instead, we're locked into proprietary platforms or relying on old phone systems.
Ok so try calling my phone at sip://ninkendo.example. Oh, I’m actually not at my house. I’m traveling and my device is moving from one cell tower to the next, getting a new IP address every few minutes. Then I get to my friends house and his router is gonna block unestablished connections so you better call me soon.
No, there’s a reason software like FaceTime, and calling in general, are mediated by centralized services and implemented as client-server. Because relying on your users to have stable IP’s, and to always be behind a properly configured firewall, would be an utterly insane way to design something.
Hence “ipv6 is a relic of a bygone era”, because in the era we live in now, IP addresses change and users move between networks constantly, and NAT is very much the least of our problems.
FWIW IPv6 can handle this scenario just fine, by letting you take your home IP with you when you move to other networks. I don't think "v6 is a relic of a bygone era" is fair to say when it has a way to handle this exact problem.
How does ipv6 let me take my IP with me, exactly? Citation needed. I mean, I have WireGuard installed on my phone and I get a tunnel my house wherever I go, but that’s not really the same thing, is it? You’re saying there’s a way for me, wherever I go, my house, 5G, my friends house, to just have traffic routed to my phone for a consistent IP address wherever I go? Not a VPN? Through something only IPv6 provides? Could you explain what this is? Because my ISP at home won’t even give me a consistent IP, not even a stable prefix.
> my device is moving from one cell tower to the next, getting a new IP address every few minutes
You're pretty much never getting a new IP at every cell tower.
> Then I get to my friends house and his router is gonna block unestablished connections so you better call me soon.
PMP can solve that.
> Because relying on your users to have stable IP’s
Not a stable IP, but some kind of stable identity. Like a DNS name. That can be provided by someone like Apple, or Google, or whoever. It doesn't need to be ultra-centralized by only a single thing controlling it.
> I don’t think I’ve met someone that truly thinks technological progress stopped in the 1990s and that URL’s and DNS are all we actually need
I never said this. You're putting some rather strong words in my mouth. Just giving an example of something that could have been if it wasn't for NAT and an acceptance that you need a third party platform to allow you talk. Feel free to change out the pieces to whatever.
Personally I'd like to be able to just dial a FaceTime-like client from any device instead of just what Apple blesses with accounts Apple allows. And have that stack just be the norm. I understand NAT isn't the only headache that prevents this, but it is one of the several that does.
I don't think it's crazy to think easy dynamic DNS services could have become common if advertised right. People don't know how phone numbers work but in the end they know how to use them. The tech for routers to auto configure firewall rules based on client requests exists, and potentially if everyone-has-a-public-ip was common we'd have seen less reliance on brittle edge firewalls and NAT to provide so much of our security.
Killing NAT doesn't solve all the problems, but it does solve some of them. And I'd prefer solving the ones that help give users more freedom instead of accepting things like CGNAT.
This is a misconception holding back the adoption of IPv6.
Routers have a stateful firewall meaning by default they only allow incoming packets that belong to a connection that was initiated from the inside. By default you also have this kind of firewall on every operating system. NAT adds 0 additional security.
NAT was invented to connect entire businesses to the internet that would otherwise have to manually reconfigure every single device for the internet. Keeping IPv4 going amidst address exhaustion going was a lucky coincidence of it.
I don't want all my devices to have their own unique address. The internet dream that created ipv6 is dead. It's malware, spyware, surveillance capitalism now, and the more obscurity through layers of addresses, the better.
Oh god, no, no, no. It's so frustrating to hear this over and over again. NAT is not a firewall. A firewall is a firewall and any reasonably component network admin uses one (and likewise any reasonably competent ISP supplies equipment with one to users who don't know any better). A little knowledge is a dangerous thing...
Can you pick a specific thing in my post to argue against? I never claimed NAT and firewalls are the same thing. I claimed that whether you’re using IPv4 with NAT, or IPv6 with a default-deny firewall, you can’t have software just “assume” that it can listen to incoming connections and have things just work. You need to go to your router and configure something. Since approximately 0% of people in the world at large know how to do this, it means software can’t work this way in general, and IPv6 doesn’t change this.
Ok, but things "just working" isn't the only advantage of v6. Are you aware some people don't even get v4 address at all? Have you ever been unfortunate enough to have your LAN v4 range overlap with a network you VPN to (like a corporate network)? What if you want to run two web servers?
A lot of people seem to think I’m anti-ipv6… I’m not, actually. I run it at home, I evangelize for it, I think it’s the future and the sooner we move to it, the better. It solves real problems, the shortage of addresses being the most obvious.
What I’m against is the oversimplification that if we only had ipv6 from the start, that the internet would have turned out very different and we’d be directly connecting to each other through direct unsolicited connections or something.
No, there are a lot of reasons direct unsolicited peer to peer communication are not a good expectation to have on the modern internet. NAT makes it tough, yes, but so does security (you’re gonna want to firewall your network at the gateway anyway, even in v6), changing addresses, mobility, etc.
For instance, even in my network at home, I don’t think using my real GUA prefix on each device is a great idea. Because the prefix changes, I have to use ULA for any static configs (dns, etc), which means the GUA address is this extra address I don’t use, and it only complicates things. So I’m moving toward ULA-only with NAT66, which I think is a more sane choice. I get the benefits of lots of addresses, which is great, but instead of my firewall simply allowing traffic to my public stuff, I just NAT a public IP to each public thing I want.
Maybe I'm blind, but I haven't seen anywhere else in the thread where "we'd be directly connecting unsolicited" is mentioned apart from where you've prompted it.
I don't think any reasonable engineer expects that that end would ever be the case, even if it was one of the stated original "dreams" of IPv6.
Like, I come up with these scenarios as a strawman to illustrate that direct client-to-client connections aren't going to work, and people come and say "actually it totally could work! We have PCP, and DDNS! Cell towers have mobile IP's too so you're only going to change IP addresses 3 times on your drive to your friend's house! And his router will also support PCP so it could have totally worked this way!"
I literally came up with the example to sound as crazy as possible, and people still say "Yup, that's exactly how things could have worked if we had IPv6. Now look at how stupid ninkendo is for not knowing about PCP, the moron~"
Like imagine if steve jobs came on stage in 2011 to introduce FaceTime, and said "You can make video calls to other people on iPhones, it's great! But you have to know their IP address. Or subscribe to a DDNS service. Make sure to use really low TTL's on your DNS records in case you roam to a different network. Oh and you have to have a router which supports PCP. Every router you connect to must support it." Even in a world where IPv6 was everywhere, that would be insane. (Well, other commenters seem to think that's exactly how phones ought to work? Maybe I'm the crazy one?)
1 to 1 NAT isn't doing any firewalling. Source NAT isn't doing any firewalling. Static NAT isn't doing any firewalling. All of these will generally just send traffic along if there's no other firewall rule associated.
(It does rely on state tracking, which it shares in common with stateful firewalls, but you could run a LAN with either a stateless firewall or no firewall if you really wanted to meet the "nothing in common with a firewall" requirement.)
> Note: no, we could not have done it any other way. Any upgrade strategy to IPv4 that extended the address size would have necessitated having two internets
No, this isn't right. Instead of having IPv6 we ended up extending IPv4 by using port numbers as extra address bits and using NAT. This transition was painless (for the most part), and didn't require building a second internet.
In a better and saner world we could have got roughly the same thing - except conceptually simpler and standard - instead of IPv6.
I think I’d mostly agree with you if only one layer of NAT is in play, but in reality we have CGNAT and it makes it supremely difficult to host services without a very cooperative ISP (laughable.) And there are more internet subscribers in the world than there are IP’s for them, so CGNAT is required for at least some unfortunate part of the population.
In reality we just really do need more IP’s. 32-bit addresses with 16 bits of ports isn’t enough.
When you say IPv6 isn't hard, do you mean implementing v6-only network stack isn't hard or understanding IPv6 isn't hard? Depending on which layer one lives on, I feel like the lack of networking effect makes supporting v6 difficult. Github is still isn't on v6 and some load balancers will prefer the v4 address over v6, etc...
You can't just assume linear growth. Your link acknowledges this, and the "prediction" you refer to has the right caveat: "we can look at the time series shown in Figure 1 and ask the question: 'If the growth trend of IPv6 adoption continues at its current rate, how long will it take for every device to be IPv6 capable?'". It's using such a naïve model to illustrate that we're still nowhere close to completing the transition, not to say that we'll be done in 20 years at most as you suggest.
Adoption will slow down and my guess is that we'll be stuck with a long tail forever, and only time will tell if that happens at 50% adoption or 90% adoption.
> Adoption will slow down and my guess is that we'll be stuck with a long tail forever, and only time will tell if that happens at 50% adoption or 90% adoption.
But that long tail will probably look like figure 4 of that link, only reversed: IPv4 running mostly as tunnels over a core IPv6 network. Some large cellphone networks are already at that stage, using things like 464XLAT to run IPv4 with NAT over an IPv6 network.
I'm not talking about a long tail of systems and networks which still have working IPv4 support. I'm talking about a long tail of systems and networks which still don't have working IPv6 support.
I would agree with you were it not for the fact that I'm personally investing my time into a FLOSS project to make sure the growth does not slow down by making “tomorrow NOT like today”, but gets a kick in the butt once we reach the 50% deployment inflection point instead. Stay tuned ;-)
Whatever you're cooking up, I wish you luck! My life would be significantly easier if I could just completely ignore one network protocol, be that v4 or v6. So far I have mostly just ignored v6 and everything I do uses v4, but I have no strong preference (except that v4 addresses fit in my brain while v6 addresses do not, which is honestly a not-insignificant reason why v6 is hard)
Here's to hoping, but I agree one way or another one stack needs to go :-)
BTW: Contact info is in my profile if anyone wants the inside scoop. The project just isn't fully ready for public launch yet, but we're well into the cooking.
Depending on what that dream is, it may already be a reality in the upper layers (webrtc, websockets, quic/http3, etc). This is why not many really bother if IPv4 will go away?
there could have been allocated a prefix to ipv6 that would contain the entire ipv4 space, and then all ISPs could have simply translated between at the edge, which would have made it possible for all normal consumer/company devices to only carry an ipv6 stack
There is such a prefix, though, but the problem is the end user devices themselves (or a few applications) are not always modern enough to have decent operation with a IPv6 stack. Less so these days, though. See https://en.wikipedia.org/wiki/IPv6_transition_mechanism, ::ffff:0:0:0/96.
That said, a lot of posts here don't seem to reckon with the fact that a slim majority of www.google.com connections in the United States are via IPv6, and a super-majority from India, Germany, and France. Comcast, T-Mobile, Verizon, as far as I have experienced, these all default to IPv6. While dropping IPv4 support is both a worthy, distant goal and sometimes used in goal-post moving rhetoric, it's not like nobody uses IPv6...rather, mobile broadband networks have depended on it for over a decade (see T-Mobile's deployment of 464XLAT)
There are multiple v6 prefixes already allocated for containing the v4 space. It would help if all ISPs ran NAT64 routers on the standard NAT64 prefix, but e.g. how would that function with software that only works with v4 addresses?
OS would translate the ipv4 address to ipv6 before it leaves the machine. Very rare that software writes its own packet to the network card.
On an ipv6 only device if I type "ping 1.1.1.1", I would expect that to be translated by the OS (not the program) to 64:ff9b::1.1.1.1, rather than relying on DNS64 to do it.
Then at some point upstream it would go via a nat64 gateway to reach that legacy IP.
You’re describing 464XLAT, it’s how T-Mobile internet works. iOS, macOS and windows all support what you describe out of the box (although last I checked, Windows inexplicably only does this if the interface is a mobile/5G interface. They may have fixed this.)
You can try this on a vanilla macOS install if the router advertisement hints at a NAT64 prefix (RFC8781) and you either don’t run DHCP4, or your DHCP4 server lists the IPv6-preferred option (RFC8925). I think they’ve also added a check to query a well-known ipv4-only hostname on DNS, and if it gets a AAAA back and the connection works, it knows it must be behind a working nat64 setup, which obviates the need for the router advertisement to have the PREF64 option.
I tried this a year ago and it worked great, macOS skips DHCPv4 and gives itself a single 192.0.0.1/32 address so that legacy apps can “see” an IPv4 interface, and any packets sent from it are translated to IPv6 and sent to the nat64 prefix. So “ping 1.1.1.1” works fine. I stopped using this though, because I have a garage door opener (ratGDO) that only works with ipv4, and my nat64 prefix can’t “hair-pin” the packet back to the LAN address… it basically only works if everything on your LAN is IPv6, which my garage door is not.
I think android supports this as well, but I’m not sure about vanilla Linux, I think you need to install a clat daemon to do the translation.
It did take way too long for this to work though, as you point out.
Then you're back at having "two internets" again. (Well, I don't agree that it's two Internets, but you'd be stuck with the same situation we have already because people would continue to use v4 in order for that software to continue to work.)
It's very useful for cooperatively pretending that a single machine is actually a network of machines, without all the madness of network namespaces.
Basically every server program ever supports the notion of "which IP address am I supposed to bind to?" Normally the answer is either "localhost" or "whatever my LAN or WAN address is, for a particular interface". And specifying this (both for servers and for clients) is much less effort than replacing all the standard-ish ports with ad-hoc ones.
I love this feature so much when jumping back and forth between two projects that when devving expect exclusive control of postgres. All I have to do is set the bind address for one .1 and the other .2 and all is good.
Just assign multiple IPv6 to your loopback interface and everything will work as expected. You can use either private IPv6 or even link-local IPv6 range.
There’s no need to waste thousands of addresss on this use case.
As someone who used Windows and Linux my whole career and now am forced to use Mac for a new job; I completely agree, I was right, Mac is a very weird thing overall.
…until it doesn't, when something looks at the configured addresses. The "other" addresses in 127.0/8 will easily have weird behavior in nontrivial setups.
I’m gonna get downvoted for this, but IPv6 has lost and they have to come up with something else with enough benefit for the user to achieve widespread adoption to beat IPv4.
IPv6 certainly hasn’t “won” in the sense that it’s nowhere near where it should have been by now, but I would definitely not say we need to make something else that also isn’t ipv4 and thus also isn’t forward compatible.
IPv6 is still the only game in town as a successor technology to IPv4, and it makes no sense to invent some other new thing.
The real question at hand, is do we keep trying to make IPv6 happen, or do we give up and just deal with IPv4 until the end of time. (It’s not an obvious answer. L7 load balancing and IP anycast makes it so you can basically run an entire tech company on a single IPv4 address. CGNAT is becoming more and more commonplace. The pressure on IPv4 availability is alleviating all the time. Maybe 4 billion addresses will ultimately be enough for humanity, who knows.)
But I mean it when I say that if we continue as is and just sorta gradually, grudgingly add IPv6 on a best-effort basis, it’ll likely be 100 years or so before we can actually turn off IPv4.
> What is hard, is dual stack networking. Dual stack networking absolutely sucks, [...]
Clearly you have gotten some unfortunate hands on experience with those edge cases. In my uses the dual-stacking of IPv4 & IPv6 has been a big benefit in that I have to worry a lot less about locking myself out of systems, as I can always reconnect and correct configuration mistakes on the second stack.
Comparing the IPv4+IPv6 dual-stack story to the one from the 90s of IPv4 with IPX/SPX (Novell Netware) and/or NetBIOS (Microsoft Windows), the current state is a lot more smooth and robust.
I've so far only run into 3 issues over the years (2013 till now). A local train operator running IPv6 on routers that didn't properly support non-default MTU sizes (fragmented packages getting dropped) and Microsoft where Github is still IPv4-only and Teams recently developed an IPv6-only failure on a single API endpoint.
Should we ever turn off IPv4 during my working life-time, I hope we have at that point introduced a successor to IPv6, so I can keep using a dual- or triple-stack solution, using different network protocols for robustness.
And the issues with IP (and by extension, TCP, ignoring the fundamental results from the Delta-T research at Lawrence Livermore keeps biting us all in the ass) whether IPv4 or IPv6 go even deeper, far deeper, than what that blog post already tells us, so here, have this—flawed in some minor aspects, which makes CCIEs burry their head in the sand of denial about the deeper point of it—polemic for dessert: https://web.archive.org/web/20210415054027if_/http://rina.ts...
> Please avoid acting like IPv6 makes for a good design, because it doesn't.
Where did I give that impression? I tried my hardest in that post to not make a judgement call one way or the other as to whether it was a good design, only that dual stack fucking sucks.
Their router needs to know what devices are behind it so it can route to them. But if by "their router" you meant "your router"... your ISP doesn't need to know at all. They send all traffic for your prefix to your router, and your router figures it out from there. Your ISP has no idea what devices are involved.
The existence of privacy addresses suggests that some thought was put into this.
There are no more "your routers" for about 10 years. The router is given to you by the ISP, and you don't have the root password for it, you can only reboot it over an APP on your phone.
The prefix is also not delegated to that router, the router does npd proxying, and the ISP only routes the ips which have the corresponding NAs recorded into its database.
That's... not how things work in general. It would be possible for an ISP to do that, and I'm sure somebody somewhere does, but they could do the exact same thing on v4 so you don't get to blame v6 for it.
If your ISP runs the default router for your own LAN, they'll have full visibility into it on both v4 and v6. That's just how IP works.
Most ISP I have seen implement it like this. A large chunk of those "most" also require you to bind a phone number to each separate hwaddr appearing in the network via SMS. (Not all though.)
Those few that implement it differently, do the following:
They serve ULAs to the customers over slaac, and nat6 all the ULAs to a single ipv6 assigned to the router (actually a wifi hotspot).
I totally believe that where you live things are done differently, but this is exactly why ipv6 critics call it defective. It allows too large a variety in implementations.
That's the adaptation layer between Ethernet and IP.
Broadcast was renamed to "all nodes multicast". ARP was renamed to Neighbor Discovery.
Slight improvements: ND isn't broadcast, but multicast based on several bits of the IP address. This allows NICs to filter most of the irrelevant ones based on multicast MAC address. And subnet broadcast addresses were removed. There's only local broadcast to your own subnet and not to someone else's subnet, since IPv4 routers found that to be a bad idea and mostly started blocking it anyway.
that's not what this article says. I dug through it, and the main point seems to be 'It would have been beautiful. Except for one problem: it never happened.'
there is nothing really wrong with the design of ipv6 relative to ipv4
This is a little self contradictory. Saying that it's "not that different", then going on to mention "the strategy of having two internets".
Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6, an inherent design flaw of the IPv6 protocol. Just to provide the architypical links:
As you mention, IPv6 has exsited for the majority of the commercial internet's history, now 25 years later, it's still not the default transport protocol.
It _was_ possible to create an address space extension that was IPv4 backwards compatible, this option was just not chosen, and now we're still dealing with the dual stack mess.
> Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6, an inherent design flaw of the IPv6 protocol.
It is not a design flaw of IPv6, it is a limitation of the laws of physics: how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)?
Even if the IPng protocol could recognize IPv4 address and send out data, how can a host which only understands 32-bit addresses send back a reply back to the IPng host? If a packet with a >32b address comes in, how would a 32b-only hosts be able to handle it?
From Bernstein:
> In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses.
How would a non-updated IPv4 system know about the IPng protocol? If a non-updated router had a IPng packet arrive on an interface, how would it know how to handle the packet and routing?
All the folks criticizing IPv6 don't ever describe how this mythical system would work: how do you get 32-bit-only system to understand more-32-bits of addressing? Translation boxes? Congratulations, you've just invented 6rd BR or NAT64, making it no different that IPv6.
The primary purpose of IPng was a bigger address space, but how would that work without updating every single IPv4 device? You know, like had to be done for the eventual IPng, SIPP (aka IPv6).
>how do you get 32-bit-only system to understand more-32-bits of addressing
Maybe you don't. I imagine it would work like this (where XXXX::<IPv4> is the transition block mapping the current Internet v4 into IPv6):
- 32 bit host could only talk to other 32-bit hosts, and other XXXX::<IPv4 Adress> hosts. We have this now, just without the XXXX::<IPv4> part.
- Hosts with v6 addresses outside of XXXX::<IPv4> could not talk to IPv4 addresses without having a 6to4 proxy. We also have this now.
- Hosts with v4 addresses could switch to IPv6, KEEPING their current v4 address by setting their IPv6 addres to XXXX::<IPv4>. They can now talk to all the hosts they used to be able to, AND they can start talking to IPv6 hosts, without having to have two IP, dual stack config, etc.
So we end up with a significant benefit of allowing people with IPv4 addresses and IPv6 connectivity to do an IPv6-only setup.
In my case, I simply don't see us transitioning to IPv6. Our main service has an IPv4-only address and we receive 0 complaints about it. We've literally never had anyone say they couldn't connect to our services because of it. Our users are geographically located in the central US, and everybody has IPv4s. Maybe they have an IPv6 as well, but if we went v6-only I can basically guarantee that we'd have users screaming at us. We'd probably have lawsuits over it. But going v4-only, not a peep.
> - 32 bit host could only talk to other 32-bit hosts, and other XXXX::<IPv4 Adress> hosts. We have this now, just without the XXXX::<IPv4> part.
Oh, you mean like IPv4-mapped Address (::ffff:0:0/96) as defined in RFC 4291 § 2.2.5, or NAT64 (64:ff9b::/96) as per RFC 6050. See also 6to4 in RFC 3056 dating back to 2001.
Not my idea, wasn't representing it as my idea; djb proposed it long ago (as other commenters in this thread mentioned), and as you pointed out as IPv4 mapped addresses. I was just describing how it might work, since it's a little confusing. In particular when I first started thinking about it I kept getting stuck on "Ok, so how do non-v4 mapped IPs talk to v4 addresses?"
> Not my idea, wasn't representing it as my idea; djb proposed it long ago (as other commenters in this thread mentioned), and as you pointed out as IPv4 mapped addresses. I was just describing how it might work, since it's a little confusing.
Every time IPv6 comes up some number of people talk about a protocol that 'just' added more bits IPv4 and calling it a day. But when going over the details of how what would work, exactly, you end up at the same place as IPv6 (and various 'transition mechanisms').
But there is no 'just' adding more addresses: you need to update (at least) end-hosts, update DNS, have relays/proxies if the middle of your network does not support IPng, have tunnelling to/from those special translation systems. It's basically the same thing as IPv6.
Certainly you can argue about keeping ARP versus going with NDP. Or not having SLAAC—but then you need infrastructure like DHCP (which is optional with IPv6).
>> how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)?
> By using nat46 on ISP's routers.
I do not understand.
In Ye Olde Times a system would call gethostbyname() and this send out a DNS packet asking for the IP address. Of course DNS record returned would be an A record, which is where your first problem is: A records are fixed at 32-bits (RFC 1035 § 3.4.1). So your first task is to create a new record type and update every DNS server and client to support the longer addresses.
Of course the longer address has to fit into the data structures of the OS you called gethostbyname() from, but gethostbyname() is set to use particular data structures. So now you have to update all the client DNS code to support the new, longer addresses.
Further, gethostbyname() had no way to specify an address type (like if you wanted the IPv4 address(es) or the IPng one(s)):
The the returned data structures only allowed for one type of address type, so you either got IPv4 or IPng. So if you wanted to be able to specify the record/address type to query, a new API had to be created.
Luckily the next step, setting up a socket() and connect()ing is less of a burden, because that API already supported different protocols:
But if you have a host that support IPng, but its upstream router does not, how does it support a packet with a longer source address a shorter destination address get through?
Do you send IPv4 packets with embedded IPng packets with-in them to translation relays perhaps? How is this any different IPv6 transition mechanisms like Teredo?
Your isp dns converts the AAAA record to AA record with the ipv4 of it's own (only router) configured dualstack machine, that machine does cgnat46 and visits the ipv6 only server.
If software has hardcoded ipv6 addresses, this is much harder to solve, but I don't think this is really an issue, because hardcoded ipv6 addresses appear very seldom.
Assuming you mean nat46, your description is a bit off. The NAT box doesn't have a single ipv4, it needs a big pile of ipv4 addresses to dynamically allocate whenever a new AAAA record comes through.
But that means it has to intercept all DNS requests and doesn't work with anything it didn't intercept, which seems far from ideal.
Which means that servers have zero incentive to convert to ipv6.
All this cgnat46 setup is not in the name of end users, because they will always adapt somehow, as reels have a huge force of attraction.
It is to make sure that service providers can deploy ipv6-only _servers_ and not bother that 60 percent of their target audience will be unavailable.
The issue with the ipv6 internet is not the end users, they are paying, so the ISPs will always adapt to their needs, or the users themselves will buy new equipment in the worst case, it's the service providers who stop being profitable by going ipv6-only.
That process seems extremely error prone on anything but most basic protocols... And given how many people here for example don't run their ISPs DNS... Just seems massively complex and very resource intensive process.
>That process seems extremely error prone on anything but most basic protocols...
Worse is better.
Moreover, we really mostly need to make it work on http, that's enough to say "you can watch YouTube", but also deficient enough to stimulate ipv6 transition.
>given how many people here for example don't run their ISPs DNS..
Those people usually know how to deal with ipv6.
>Just seems massively complex and very resource intensive process.
No more complex than hanging in limbo for 30 years .
> Your isp dns converts the AAAA record to AA record with the ipv4 of it's own (only router) configured dualstack machine, that machine does cgnat46 and visits the ipv6 only server.
> It _was_ possible to create an address space extension that was IPv4 backwards compatible
How? People keep claiming this, but I've yet to see a coherent design (either back then or today). Do you think they broke backwards-compatibility _on purpose_? What's the motivation here?
> no address space overlap between IPv4 and IPv6, an inherent design flaw of the IPv6
This is not an inherent design flaw and is often brought up in IPv6 threads commonly referred to as the "just add more octets, bro" argument. This comment[0] sums it up well, but I'll leave it here for convenience:
> Fact is you'd run into exactly the same problems as with IPv6. Sure, network-enabled software might be easier to rewrite to support 40-bit IPv4+, but any hardware-accelerated products (routers, switches, network cards, etc.) would still need replacement (just as with IPv6), and you'd still need everyone to be assigned unique IPv4+ addresses in order to communicate with each other (just as with IPv6).
> Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6
That's not at all what I'm suggesting, I'm saying "two internets" because there are two internets: IPv4 and IPv6. You need two internet stacks on every host to deal with this, hence two internets. If everything in the IPv6 protocol suite was literally identical to IPv4, but just with some extra bytes in every address, there would still be two internets, because they are not mutually compatible.
Saying "two internets" is not a judgement call on whether IPv6 changed too much or is too different. It's just the literal truth. There are two internets, because one can't communicate with the other.
$ ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
$ ping -6 ipv4.google.com
PING ipv4.google.com(sof04s06-in-f14.1e100.net (64:ff9b::142.251.140.78)) 56 data bytes
64 bytes from 64:ff9b::8efb:8c4e: icmp_seq=1 ttl=55 time=27.9 ms
This is a v6-only machine (no v4 address other than lo), talking to a v4-only hostname. If it was truly not possible to communicate, this wouldn't work.
> If everything in the IPv6 protocol suite was literally identical to IPv4, but just with some extra bytes in every address, because they are not mutually compatible.
This part is true though. v6 is backwards compatible in rather a lot of ways, but v4 isn't forwards compatible, and it's important to note that this comes entirely from the larger address size -- no amount of making v6 more identical to v4 than it already is would make v4 any more compatible with it, unless you undermined the entire point and made the addresses 32 bits.
Now try that on an ipv4-only host trying to talk to an IPv6-only address. You can’t, hence, 2 internets.
(Yes, I understand there is no other way for a larger address space to exist that doesn’t have this problem. We are in violent agreement here. But that doesn’t mean there aren’t 2 internets. Let’s call a spade a spade.)
I can do it with a moral equivalent of a port forward.
This situation was inevitable, but it's not like they just gave up and said "welp, guess they're separate then". We've developed basically every single method of communicating between v4 and v6 that are possible to develop. There's two address spaces, but they're linked into one Internet.
(Or really, with NAT in the picture, it's millions of overlapping address spaces, but we still consider that to be one Internet.)
>It _was_ possible to create an address space extension that was IPv4 backwards compatible, this option was just not chosen, and now we're still dealing with the dual stack mess.
The "IPv6 is Hard" source seems to be sarcastic, not serious. IPv6 is ridiculously easy, in the grand scheme of things.
What's hard is getting people who should know better to do what they're supposed to do, without playing games. The very fact that there are people who will argue why IPv6 is unnecessary tells us everything we need to know, because occasionally those people are in the path of deployment of something public. They don't write software which works agnostically with IPv6, they don't implement addressing that's stack agnostic, they don't bother taking the extra five minutes to test with IPv6.
Then you have a corporation that requires manager types to have enough "justification" to actually fix whatever Mr.-IPv4-is-good-enough, and because they don't understand that their own phone uses IPv6 all the time, they don't see a "business case" for it.
The title would be longer, but perhaps more accurate, if it were "Getting know-it-alls to stop stubbornly clinging to IPv4-is-good-enough and getting managers to realize that IPv6 is not only inevitable, but ubiquitous, are hard".
This article's conclusion isn't totally off, but in this case it's something that could easily be fixed by having a junior network admin just simply set things up. It's a trivial problem that's probably there because someone thinks they know better.
> IPv6 is ridiculously easy, in the grand scheme of things.
How do I do a guest wifi network with isolation? On ipv4 I just flip a switch and thanks to NATs it just works, always.
With ipv6? First I have to figure out what prefix delegation my ISP gives me. How do I do that? Manually, somehow, and hope it never changes. Already not "ridiculously easy" at the first step.
Oops, turns out I was given a /64. So now what? Please explain this "ridiculously easy" thing to me, thanks.
IPv6 is easy, it was just not designed to handle
intentionally adverse ISPs.
If ALL customers would get a static /48 and the router provided by ISP wouldn't be industrial waste, you could easily use a different /64 for guest WiFi. (Or even a /56, if for some reason your friend wants to delegate some /64s to VMs running on their notebook.)
But in that case these ISPs wouldn't be able to ask more money for "business" internet services.
I think this is just the result of negligence from IANA or RIRs, these "suggestions" or "best practices" should be mandatory for ISPs and enforced by RIRs.
I don't think you can frame it as "adverse ISPs". I mean in some respects yes, but also IPv6 made the assumption that networks want to be shallow & wide, yet that's not where we've ended up. Rather, we now tend to have a lot of depth to the routing tree. Is this because of NATs? Possibly. But also network isolation turned out to be a powerful tool. And every step of isolation is necessarily another subnet. So now the depth of IPv6 is a limiting factor. Great you can have infinitely wide networks, but you can't expect to nest them much anymore. And that's a rather big limitation.
Which maybe will happen eventually with RFC 9686 & 9663. Those are getting activity and maybe eventually will enable an actual IPv6 future in, oh, another 20 years? give or take.
Is that really the case though? I very much doubt it.
I get a /56. Dynamic configuration mechanisms exist. I literally do not have to anything except flip a switch. My router even supports Prefix Delegation, so a downstream router/access point can do its thing.
> Is that really the case though? I very much doubt it.
It's what AT&T fiber does. Well, they give a /60 to their shitbox, but if you want your own router with a public IP then you're stuck with a single /64 for it at least when doing the "easy" path.
You can get some routers to request multiple IPv6 blocks and then you get the freedom of a whopping 7 subnets but you've also left "ridiculously easy" way, waaaay in the rear view mirror at this point anyway
I mean it’s not a great answer, but you could always set up a ULA for your guest network and use NAT. :-P
But I’m with you on prefix delegation sucking. Prefixes change, and that makes all your devices’ addresses change. ULA’s solve this. But then you start asking hard questions like “if I’m going to use a ULA anyway, why even use the GUA addresses?” And the answer is shrug.
I mean, it’s great that you can give real addresses to your devices when you want to host a service on them, but you can always just NAT your ISP-provided prefix to them anyway. You’ll probably want better addresses for them anyway, as those randomly generated host addresses aren’t easy to remember (may as well just start your public addresses at ::1 and increment from there, routing each one to the underlying ULA.)
I've been writing software for pay for several decades and do not want IPv6.
Phones use IPv4 and IPv6 and you can switch your phone to IPv6 only in the networking settings, run like that for a month and observe multiple weird and bad behaviors.
I don't want IPv6 for several reasons, it looks like it was written by an alien and it inherently is privacy busting. I know many whose job it is to track people as closely as possibly will object but it's true, IPv6 is mainly only wanted by people whose job it is to track people.
> The very fact that there are people who will argue why IPv6 is unnecessary tells us everything we need to know
Yeah, it tells us that the IPv6 standard was invented by retarded monkeys who don't know what they're doing.
(Yeah, yeah, I know, I've heard it before - akshually it's the rest of humanity who is stupid for not switching to IPv6. If only they were enlightened enough to know they need to throw away all their hardware and switch to an untested network stack for no practical benefit!)
Haven't look at that code for a while, but IIRC it does a simple HTTP request then checks the returned HTML for anything that looks like a v4 literal, eg. http://174.136.109.18.
The biggest piece of annoyance I have with IPv6: it's really hard to tell the OS "here's your IPv6 address, here's your gateway, here are your routes, now don't mess with any of it!".
With IPv4 it's easy to set up a static configuration. With IPv6, the Linux kernel is eager to listen to all sorts of advertisements from the network, and it's hard to say "no, stop, don't ever ever listen to anything except my static configuration".
I can bring up IPv4 networking in a tiny fraction of a second. IPv6 networking sometimes takes seconds to settle down and be reliable.
(I'd be interested in any suggestions for how to improve this.)
Only accept_ra=0 is actually needed for static config. autoconf is de-facto disabled if RAs aren't being processed, and DAD is a separate thing (but relevant to the grandparent since it takes a few seconds to finish).
Although I'd also argue that you should prefer automatic config over static in general. RAs can set your default route correctly and you can use `ip token` if you really need SLAAC to give you a specific address. I think it's better to be able to just connect machines and have them get the right config rather than need to hand-craft it on each one.
For most cases I agree that automatic configuration is the right answer.
In this case I'm bringing up virtual machines, as fast as possible, and static is inherently faster and more predictable. Automatic configuration isn't compatible with literally counting milliseconds.
I don’t want to trust the network. The network is never secure. Therefore, I don’t want the server to trust any self-proclaimed router with what IP address the server should use. As far as I know, there is no IPsec for RA packets.
Now how do you do it on your phone or windows laptop? :)
What if you have multiple internet connections and you want to choose which one you go through? With ipv4 and nat you can just change the default route. And you don't even need to write down the router's address since it's <your prefix for the whole network> dot one number.
I've previously found and used all three of those, and those help but don't seem to suffice. There's still some degree to which the configuration seems unreliable, and doesn't settle down for a few seconds.
(I appreciate the confirmation of those settings, though, and those are all an important part of the setup.)
Don’t all modern server OS choose a deterministic interface ID based on the network in the router advertisement? (As I recall this is usually via hashing the MAC with the RA prefix plus some system-wide but stable seed, to avoid using the MAC directly as the interface ID)
This is a response to what appears to be a complaint that IPv6 is not treated as a first class citizen by some providers, not literally that it's hard.
If anything, IPv4 is much harder. The Internet is in an abusive relationship with NAT, thinking it's normal.
But we're in a world where if a service breaks IPv4, they lose a very large set of their customers and it's the service's fault. If they break IPv6, it's is perceived that if any customer fails to connect, then it's the customer's fault (or their ISPs fault).
"Hard" for many is "unfamiliar." IPv4 plus NAT and all that ugliness is the devil we know.
I'm also convinced that the length of IPv6 addresses and the difficulty in typing them is a major reason for lack of adoption. Very seemingly small UX annoyances can have a large effect.
> I'm also convinced that the length of IPv6 addresses and the difficulty in typing them is a major reason for lack of adoption. Very seemingly small UX annoyances can have a large effect.
I've been convinced of this since around 2000. Every network utility dealing with IPv4 had... dotted quad addresses. You could remember them, you could read them, you could speak them to someone else. Brainwise, we can remember 3-5 things - segments, digits, etc. Remembering more is harder for the average person.
Having the 6 be literally dotted sextant(?) - 5.73.192.168.0.4 for example - would have been much much much easier to transition in to, and would have given us 64k x 4 billion addresses. Yes, it's not the near infinity we have with IPv6, where apparently every molecule in the universe can have multiple IP addresses or whatever the max number is. But it would have been much much easier to transition. 27 years later we're not transitioned from ipv4, and we've got another 27 years of dotted quad baked in to daily usage everywhere.
I think you’re exactly right on this.
Further , difficulty in remembering or visualizing IPv6 addresses I think makes it more difficult to understand how it works (vs learning how v4 really works) and thus weaker adoption
Part of this would just be transitory, but... would take up far less space. Even as late as last year, I'm reading stories about BGP issues and slowdowns because routing tables are too large/many for the hardware. In 2024. How on earth was this expected to work on hardware from 1999?
there is something called an "IPv4-compatible IPv6 address" and it's exactly the scheme you suggest: the first 96 bits are zero. It doesn't help deal with the billions of devices that only handle a 32-bit address space, however. What do you suggest we do with them? _They_ are the long tail that keeps us in the dual stack world.
Those routing tables are badly made. An IPv6 route takes twice as much memory as an IPv4 route, and there are a lot less than half as many IPv6 routes.
They didn't invent SLAAC, so no that wasn't a reinvention of IPv6.
But even if they had the counter argument to "128 bit addresses are too long, 48 bit would have been better" is obviously not "that's the same thing just with 48 bit addresses!"
That would have required exactly as much work to transition, plus require computers to get good at 48-bit math. ("Why are the top 2 bytes always 0xFF?" "I don't know, grandson, but I'm sure it seemed like a great idea before Y248.")
I'd imagine many countries would claim a top spot or two, and transition all canadian addresses to, say, 7.0.0.0.0.0. Big companies would probably get some of their own. Legacy/default stuff would have leading 0.0, sure, but... so what?
No, it wouldn't have taken 'exactly as much work to transition'. See another reply. In 2024, I'm still reading about BGP/routing table issues, and hardware having problems keeping up with IPv6 networking - it's just too large. How was this supposed to work in 1999?
A smaller stepped transition from 4 billion addresses to... 64k of those would have been an easier transition step, and the ease - mental, UI, training, testing, security, etc would have given everyone involved the confidence and positive feedback to tackle a next stage to IPv6 (eventually).
Maybe a long time ago, but just about everything I've used recently supports mDNS for LAN hostnames. If I add a computer named "foo" to the LAN, it's almost certain I can run "ping foo" on another computer 3 seconds later.
that's not mDNS that's just dhcp+dns and it's something ipv6 actually breaks, which is part of the problem. DHCPv6 is optional, so local devices don't necessarily ever register their hostname nor do they necessarily ever consider your local DNS server.
Actually mDNS does exactly what they said just fine. You’re confusing it with the ability of a DHCP server to make updates in DNS on behalf of clients. There is more than one way to skin the cat. Both achieve the same affect, just differently.
> nor do they necessarily ever consider your local DNS server.
Hardcoded DNS servers are just as equally a thing with IPv4.
> Hardcoded DNS servers are just as equally a thing with IPv4.
Of course, but they aren't the baseline expectation like it is with ipv6 since ipv6 baseline assumption is SLAAC. And SLAAC is terrible. If you control all the devices on the network, like a cloud install, you can just pretend SLAAC doesn't exist and live in a much better world.
If it's a home network then you're stuck expecting at least some usage of SLAAC. And you're better off just not supporting ipv6 at all at that point
> they aren't the baseline expectation like it is with ipv6
Why not? Are you saying your computer doesn't need to know the IP address of any dns server in order to be useful?
What do you mean when you say that SLAAC is terrible? Especially when you control all the devices on the network, you are in full control of what SLAAC manages for you. Also, SLAAC is the only way to use the IPv6 Privacy Extensions.
mDNS would work just fine but the given command ('ping foo') wouldn't be using mDNS. That's just standard name resolution. `ping foo.local` would potentially use mDNS if you have a ping that does such a thing, but that's restricted to `.local` specifically.
Rather, most routers add DHCP hostname requests to the local DNS routes. That doesn't require mDNS, nor would you want to replace it with mDNS as mDNS is more limited & flakier.
My resolved in its default configuration will try appending .local and search via mDNS if no results are found via the DHCP provided server. I believe macOS does the same.
Ping foo on my machine results in foo.local being successfully pinged. Your mileage may vary.
> would potentially use mDNS if you have a ping that does such a thing
It's not a feature of ping, it's a feature of the name resolution setup on your machine (nsswitch and/or resolved on Linux).
> Rather, most routers add DHCP hostname requests to the local DNS routes
I agree that NAT sucks but IPv6 having two different ways of assigning addresses (SLAAC and DHCPv6) with one of them being practically optional (Android doesn't do DHCPv6 for address assignment) does make IPv6 harder than it needs to be.
Then there are crimes against network protocols like NAT66 that are borderline necessary in some situations because terrible ISPs have decided to dynamically alter IPv6 prefixes so they can charge extra for a static prefix.
I still think NAT makes everything harder than it should be, but I get why some people struggle with IPv6 if their ISP is particularly terrible.
I don't generally care for Android but I'm glad they chose not to support DHCPv6. It's a nice forcing function to make network admins actually learn how SLAAC works and why they should almost certainly prefer it to DHCP.
The sin of IPv6 was trying to do too much. They should have extended address sizes, period. SLAAC and most of the other extensions were a mistake.
Everyone should bomb Android bug reports with complaints about lack of DHCPv6 until they fix it. Then people can de-facto deprecate SLAAC. AFAIK Android is the only major offender here.
Some corporate networks already don't do SLAAC if they don't need Android to work on them.
> I'm also convinced that the length of IPv6 addresses and the difficulty in typing them is a major reason for lack of adoption.
Possibly, but I think it's also that some aspects of IPv6 are just badly designed, and subsequent updates only fixed some of the issues.
SLAAC, for example, is godawful stupid. And while DHCPv6 exists to fix some of that, critical aspects of the protocol, like prefix delegation, are manually configured. This is beyond idiotic and makes things like subnets massively more difficult than they have any right to be.
SLAAC and PD combine to create the worst sin of all - flakiness. It's hard to figure out why IPv6 isn't working because everything is telling you it is (it "auto configured" a valid IP despite not having any actual route to anywhere else, so helpful! /s). If IPv6 was literally just "IPv4 but 128-bit addresses instead of 32-bit ones" it almost certainly would have been adopted en masse by now. But it isn't, it made things more fragile and harder to configure for no goddamn reason.
And of course you then have ISPs doing silly stuff, like my ISP only gives me a /64 so I literally can't use IPv6 on my network since I want VLAN isolation. 18446744073709551615 possible addresses are given to me yet dividing that up into 3-5 subnets is completely impossible. Fucking stupid protocol.
It breaks SLAAC so routers won't do it. Or if they do, it's non-standard and they won't easily let you do it. /64 is the smallest PD by spec ( RFC 5375 )
> You can do it with DHCPv6, but of course there's Android. Android aside, it works fine.
are you sure? what about homepods, Chromecasts, Hue bridges, kasa smart plugs, esphome, etc etc etc...?
How much are you willing to bet your home network on Android being the final user of SLAAC? And how much time do you want to invest in figuring that out in the first place?
Although https://www.rfc-editor.org/rfc/rfc7217 doesn't require a /64 or shorter prefix for its variant of address auto-configuration, for example Linux doesn't allow otherwise.
Honestly we probably need IPv7 to roll back most of the things from IPv6 and be closer to IPv4x4. IPv6 is now older than IPv4 was at the time IPv6 was invented.
Heck, I would have probably simply added an Options flag for "long address" to support longer addresses. With the first part of the address being the IPv4 address of some ISP backbone router and the next 3 words being a device address on the network (with the all-0 device address reserved for the router itself). Then you don't even need to upgrade most of the routers beyond configuring them to accept packets with that option set. It would have been so simple and elegant and we would have probably upgraded most of the world by 2001.
>IPv6 is now older than IPv4 was at the time IPv6 was invented.
The quantity of existing deployments that need to change is much larger for v6 than it was for v4. The problem with deploying v6 isn't that it's too different from v4, the problem is that it's different at all. Your v7 will have the same problems.
IPv6 looks silly until you learn about the problems it actually solves, and then realize it would be completely impossible to incrementally upgrade IPv4 to get there.
> This is a response to what appears to be a complaint that IPv6 is not treated as a first class citizen by some providers, not literally that it's hard.
Last time I've checked, some telecoms such as Vodafone didn't even supported IPv6 yet.
telecoms that deal with consumers have at best 0 (zero) incentive to deploy ipv6 unless there's regulatory pressure.
b2b telecoms as a consequence also have at best zero incentive since if the consumer doesn't have ipv6, businesses don't need or want ipv6.
the solution here, which will inevitably strike a nerve with some, is to have a regulatory mandate for ipv6. a soft version would start with 'government networks must run exclusively on ipv6, this applies to any and all contractors, including govclouds' and work upwards from there. I understand such policies were in place or at least planned; OTOH in the current political climate it'll be sort of a miracle if the existing ipv4 networks keep working.
Change at tier one telecoms providers tends to be glacial. It follows hardware upgrade cycles that take ages to plan and implement.
I spent a decade writing element management systems. An element is a network device - switch, router, ROADM, etc. Often you give the customer kit & software and they spend a couple of years assessing it. This software would be installed on secure out of band networks with no route to the internet. 10/8 would have been adequate for the lifetime of the hardware currently in service - 200G stuff. However, that's not how things played out.
When I started working on EMS software IPv6 support was a requirement but it was just a box ticking exercise. No one was actually going to use it. A decade later IPv6 HAD to work for northbound and southbound traffic, on an internal network. Otherwise, no sale. IPv6 is being used in anger in telecoms. I have no idea how long that will take to filter to in band networks.
> telecoms that deal with consumers have at best 0 (zero) incentive to deploy ipv6 unless there's regulatory pressure.
Not entirely true. 10/8 is only so big, so the management of addresses very much has a nonzero opex cost.
And on top of that there's capex on "carrier grade NAT".
For the biggest providers 10/8 is not even big enough for their production environment. And then they acquire some some company that (obviously) also uses 10/8.
No, there's definitely incentive there. Just… not enough.
Do you have data on that? I've heard rumors, but never seen it actually done.
It was never a viable option for the Internet (million or billions of devices would never support it, and anyway it'd only buy us like 3 months), but in theory it should work better in the (more, but not entirely) controlled environment of a large prod environment.
I know of several massive setups that when running out of 10/8 evaluated 240/4 but deemed it less feasible, riskier, and definitely more work, than to "just" move to IPv6. Sorry, can't namedrop them, since I don't want to doxx myself. I've never seen 240/4 actually chosen.
We use them in AWS as IPv6 hasn't been feasible, though its become better in the last 1-2 years. AWS uses it internally, likely other big providers probably also do. If you can get away with IPv6 only, ie not constrained by provider/device, its likely worth going that direction instead.
Works fine in Linux, doesn't really work on Windows and some BSDs.
240/4 is multicast range, and mobile devices WILL wreak havoc in that range (though it's not impossible to simply drop all such traffic at ingress). I usually see service providers using 172.16/12 instead.
> telecoms that deal with consumers have at best 0 (zero) incentive to deploy ipv6 unless there's regulatory pressure.
I don't think this is true. The IPv4 address exhaustion is still a problem and it's getting worse, and telecoms which also provide internet services need to allocate addresses to their clients. With the 5G rollout these telecoms need to make room for new devices, and that's not feasible with IPv4.
Yes that don't have to allocate an IPv4 address for each customer or deploy ugly solutions like CGNAT. They simply cooperate with phone OS makers (Apple and Google) to make sure the OS and the apps work in an IPv6-only environment. Apple then forces app developers to make their app work in an IPv6+NAT64+DNS64 environment.
I don't disagree, but I would point out that one upside to every LAN being behind NAT, is that those LANs are also inherently firewalled.
This is dependent on the firewall features of the NAT router, but at least its something, and the router provides one centralized point of protection from interent traffic.
In IPv6 typically every machine on a LAN is directly connected to the internet with a public IP address. Every one of those machines now needs a full strength internet firewall.
This complicates some intra-LAN communications, and removes the feature of having the LAN be a walled garden, mostly isolated from the interent.
Or you can implement a firewall on your gateway device with a default drop policy for inbound traffic. Essentially the same behavior as NAT in terms of unsolicited (usually malicious) inbound traffic, but without the downsides of one-to-many NAT.
Which is, coincidentally, exactly how it works if your LAN is made up of devices with publicly-routable IPv4 addresses as well, which happens in business/academic/military networks all the time.
And? Most consumer routers also implement a stateful firewall with deny-by-default inbound policy. My point is that NAT isn't a security feature, and that firewalls in edge network equipment is table stakes these days.
>Most consumer routers also implement a stateful firewall with deny-by-default inbound policy.
No they don't.
Most ISP boxes only implement the bare minimum of functions to make sure that youtube is available to the users. Which includes NAT, because otherwise youtube does not work, and does not include anything else.
Well, that's news to me. I don't use consumer routers myself, but I know lots of folks who do. Now, I won't say that I go investigating their home networks, but IPv6 is rather prevalent among the discount ISPs where I live, and I know of at least two coworkers who have an IPv6 firewall by default with their router.
Anyway, NAT is costlier than a firewall. It uses more memory, it requires rewriting packets on-the-fly, and typically if you're using embedded Linux (I'll assume that the vast majority of consumer devices for this are) then you're already using `iptables` or `nftables` to get NAT functionality. It is comparatively to set default inbound/forward drop policies.
But yes, I should have said "in my experience," since it's true that I only know the networking equipment of a few people in a small country with limited IPv6 rollout (my ISP does not provide it).
In the most commonly (almost exclusively, in case of end users) deployed setups (call them NAT Masquerade, NAT Hide, NAT Overload, NAT Many-to-One, PAT, whatever) it does block incoming connections, only allowing replies to internally-originated traffic, and to do that it tracks the state of all traffic.
Is that a real, full firewall? Heck no, I'm equally worried about what my systems leak than outside threats, and it does nothing for that.
but aren't we nitpicking a little here? veering on the "technically correct, worst kind of correct".
> In the most commonly (almost exclusively, in case of end users) deployed setups (call them NAT Masquerade, NAT Hide, NAT Overload, NAT Many-to-One, PAT, whatever) it does block incoming connections, only allowing replies to internally-originated traffic, and to do that it tracks the state of all traffic.
Yes, but that's because it's co-located with a stateful firewall, sharing the same connection tracking state. Without that firewall, if a device on the WAN side sends to your router a packet with destination address on the LAN side, your router will route that packet to the LAN, even though it's not a reply to anything sent from the LAN to the WAN. That is: it's a misconception that port mapping NAT blocks incoming connections; port mapping NAT only affects outgoing connections and replies to them.
> if a device on the WAN side sends to your router a packet with destination address on the LAN side
This can happen only if the device is directly attached to the NAT server. Basically, only your ISP can do that.
Most NAT servers by default also prohibit this kind of routing (because why even allow it?!?), but even the most misconfigured bad NAT server is still vulnerable only if you control the ISP, in practice.
> Is that a real, full firewall? Heck no, I'm equally worried about what my systems leak than outside threats, and it does nothing for that.
But it is. Even a "full" firewall can't do anything against something on one of the inner host leaking into the outside. Most of the traffic is encrypted, even DNS. So the firewall can't operate on much more than the destination address to decide if a connection should be allowed.
If you want more security, you need to secure individual endpoints.
It forces the use of some system that statefully tracks packets and makes routing decisions based on that information. Such a system will be capable of firewalling unless you go out of your way to make it not.
There are some stateless things that are also called NAT, sure, but that's not what we're talking about here. (Fairly obviously, since a stateless mapping doesn't and can't save addresses).
But this feels tautological. It's been reduced to "If you want to use NAT with features that only a firewall gives you, then that forces you to use a firewall".
I suspect when people talk about "NAT" in the context of a residential connection, what they actually mean is a "default-deny firewall with connection tracking".
Feel free to replace "NAT" with "the kind of NAT that permits you to share an address between multiple devices" if you feel the need to be pointlessly pedantic about it. The point is that any device that allows sharing a single IP between multiple devices will necessarily implement connection tracking, and will therefore be capable of functioning as a firewall.
(Are you going to point out that statelessly blocking a fixed IP range used to be called "firewalling" so a device without connection tracking can still technically be a "firewall" next?)
Pretty much any system that's capable of handling IP traffic is also capable of firewalling. Not sure what that's got to do with address rewriting though.
> Pretty much any system that's capable of handling IP traffic is also capable of firewalling.
A system that can't track connection state, or doesn't have enough capacity to do so at line rate, can't meaningfully firewall. When the norm for home equipment is ISPs sending it out for "free", they absolutely send out the cheapest stuff they can get away with, and in the pre-smartphone era that meant "modems" that would just provide a straight PPPoA connection with no firewalling.
No... it's not? It's simply a widely-used technique to rewrite the addresses of IP packets that transit a router. It inherently makes no policy decisions on which packets should and shouldn't flow over and above what a router does anyway.
It doesn't do that. It rewrites the source address that outbound connections appear to come from; it doesn't implement any kind of access control.
Take two networks that are identical, except one is doing NAT and one isn't, and test them. Every connection that works on the without-NAT network will also work on the with-NAT network. The only difference you'll find is that some outbound connections which didn't work on the former will work on the latter.
Some would argue that "every connection that used to work still works, and some connections that didn't work before do now work" is kind of the opposite of a firewall.
> It doesn't do that. It rewrites the source address that outbound connections appear to come from; it doesn't implement any kind of access control.
It absolutely does. There is no way with NAT to connect from the outside network to the inside ("but what if the attacker is directly attached to the next hop blahblahblah"). That's all that firewalls need to do, everything else is useless noise in the current world.
> Take two networks that are identical, except one is doing NAT and one isn't, and test them.
Here's my IP: 192.168.80.36. Feel free to attack me. Go on. The public IPv4 of my router is 76.191.126.81. I even opened a port 8871 for you with a static page with a Bitcoin wallet worth $1000, you just need to get to it.
You can't. There's no way to get to my computer without hacking the NAT server first.
That's why NAT _is_ a firewall, and a foolproof one at that. It's secure by default, unlike IPv6 firewalls that can fail open.
It's possible to get to your computer without hacking the "NAT server", but I'm not in a position to do it. There's no point setting up a demonstration if you don't make it possible for me to actually do the demonstration!
When I set one up for you (back here: https://news.ycombinator.com/item?id=39173556) I gave you the access needed to actually do the test (...but you either missed that message or opted to ignore it, so you never tried it). You need to either move your network to routed IPs or give me a tunnel to the upstream network of your router first.
Not doing either of those doesn't make you right. NAT is still not acting as a firewall here. I'm just not in a position to take advantage of that, due to your use of RFC1918 addresses on the LAN side.
> It's possible to get to your computer without hacking the "NAT server", but I'm not in a position to do it.
Nope. Even with a misconfigured box that forwards the traffic from WAN to LAN, you need to be in the direct contact with the NAT server (an OpenWRT box). And that's the point, you are _not_, as is pretty much everybody else in the world, outside of people who have keys to my house and my ISP.
In practice, this provides all the practical security you need from a firewall.
> I'm just not in a position to take advantage of that, due to your use of RFC1918 addresses on the LAN side.
Well, duh. That's the whole point of NAT (when used typically). You don't get to access my internal network, you simply can't do that physically.
No, you don't need to be in direct contact with the NATing router. That's kind of the entire point we're trying to making here.
All you need to be able to do is send a packet that ends up at your router with the dest IP set to one of your LAN machines. This only requires being directly attached to your router if you're using RFC1918 on the LAN; if you're using a properly routed prefix then it can be done from anywhere.
> Even with a misconfigured box that forwards the traffic from WAN to LAN
Forwarding traffic from WAN to LAN isn't a misconfiguration. Your router needs to do that for TCP to work, or get replies to outbound UDP.
You can do it from anywhere on the Internet, you don't need to control the ISP's network or anything. If your NATing router receives a packet with the dest IP set to a LAN machine, it forwards it to said LAN machine regardless of where that packet came from, unless blocked by a firewall.
Whether or not someone can get that packet to your router in the first place is a separate question. If you're using RFC1918 then yeah, they'd need access to your direct upstream network. But the point I've been trying to make is that NAT doesn't influence the answer to this question: whether or not you do NAT has no influence on the behavior of any of the routers upstream of you.
NAT has no influence on whether these packets can reach your router or not, or on whether your router will forward them if they do arrive. That's why it's not a firewall: because it's not actually doing any firewalling.
> If I had a publically routed /24, then I wouldn't be using NAT in the first place. Which is the case in point: NAT _is_ a firewall.
It's not possible to go from "I wouldn't be using NAT if I had a routed /24" to "NAT's a firewall".
If you had a routed /24 then you might not use NAT, but that says nothing about whether NAT works as a firewall or not. The relevant part isn't "would I still be using NAT if the situation was different?", it's "does NAT block inbound packets?". Since it doesn't, it's not.
> Sigh. I mean allowing the SYN packets to be forwarded from WAN to LAN.
Well, yeah, allowing those is generally a misconfiguration... in the firewall. The routing part of the router doesn't pay any attention to TCP flags, just IP addresses.
It's useful to correct this misunderstanding, because people often take "I've always seen NAT come with firewalling" to mean "firewalls are impossible without NAT".
You quite regularly see people pop up in these threads arguing something like, oh, I dunno, "In IPv6 typically every machine on a LAN is directly connected to the internet with a public IP address. Every one of those machines now needs a full strength internet firewall.", as if this is somehow a problem with IPv6 rather than a problem with their own understanding. It's hard enough to get people to deploy v6 as it is without them mistakenly believing that a lack of NAT means their router can't provide firewalling either.
shrug at work we use NAT to let two different networks with overlapping addresses talk to each other all the time. No firewalls there.
NAT wasn't invented for the home-broadband user, you know.
But I'm at least glad we've cleared up the myth that NAT provides any security benefit when, in fact, it's the often deployed accompanying stateful firewall that's actually providing this.
NAT is by definition not a firewall. And while it provides security, it provides no more security than having a firewall, while making various scenarios worse. NAT is not a good solution for security.
(Title is sort of clickbait. The body is about how it isn't hard, but certain misconfigurations make it appear hard.)
Note that curl itself also implements Happy Eyeballs if you don't force a particular protocol via `-4` or `-6`. You can see it in action with `curl -vvvv https://opentalk.mailbox.org`. So you shouldn't look at the author's example and extrapolate that `curl github.com` or `curl opentalk.mailbox.org` will fail in an IPv6 environment.
It's surprising to that all comments (except a few) state that IPv6 is not hard. I'm not an IPv6 expert but I did spend time learning it (may be even more than I spent on IPv4 but with v4 I have more practical experience). I used v6 for a few years at home / home lab (and for a side project). I think IPv6 is hard - there is much more one needs to know to use it well than in case of v4. Any deviation from a happy path (a non-standard configuration / use case) is a pain (or at least it was 10 years ago, don't think it is much better now except now we likely have even more RFC to learn). Not used IPv6 recently so cannot name specific problems but I didn't enjoy working with it at all. Will do it again only if it will be well compensated.
I think there's a big difference between enterprise IT folks who can specify hardware with good IPv6 support, and which are able to switch internet providers if they don't support IPv6 well.
It's entirely a different thing for home users which get handed some shitty router from the only ISP around.
My options are cable or long-distance ADSL. The cable ISP has dynamic prefix, so I get a new prefix every week or so. If you contact them regarding IPv6 there's zero support, I had to find the prefix length by trial and error.
So much software relies on the prefix being fixed, so this can lead to a lot of frustration. On the bright side I actually get a prefix, some just get a /64.
IPv6 might not be hard, but using IPv6 might indeed be hard.
> Any deviation from a happy path (a non-standard configuration / use case) is a pain
I've posted here before about my home network with two internet connections. Not going to whine about it again, except restate that i basically have no idea what to do about it with ipv6.
IPv6 is really an example of a second-system syndrome. It really _is_ hard because it makes a lot of IPv4 conventions inapplicable.
For example, if you want to do multi-homing with IPv6 for an SMB, you need to either do NAT (not great), or have your router advertise/whithdraw prefixes dynamically. If you do the prefix withdrawal, you can end up in a situation where your devices have _no_ prefixes. So even your internal functionality like printing or VoIP starts breaking.
Great.
Then there's ULA that is mis-prioritized. You'd think that simply adding a stable ULA prefix to all devices would solve the issue above, but that's not the case. The devices will prioritize the global IPv6 source address, so stuff can _still_ break.
I have three connections at home both as a way to increase available bandwidth and also to provide some redundancy since I work from home and my ability to earn income is tied to my internet being up.
I have two primary connections that I load balance between, each providing a /56. If either fails, all traffic goes to the other. I have a third connection that is used only as a backup in the event that both the other connections go down, providing a /64.
So simple case, I assign an address from each connection out to each device.
Except, whoops--the backup ISP only provides a /64 and despite that containing something like 18.5 quintillion addresses (a number so large my spell check is telling me it's not a real word), I can't actually split those up in any meaningful way so I can only allow _one_ subnet to access the internet via that connection.
And then I'm pushing responsibility for load balancing between the two primary connections out to each client. You know, to the place with the _least_ useful information for making decisions in this situation. And then I need to figure out how to convince each device to make these decisions individually. (As far as I can tell, with an equal cost, Linux will simply use the most recently added address. So in the event that one of the primary connections is having issues and bouncing up and down, that's going to be the one that all the Linux devices choose to use preferentially. Absolutely what I'd want!)
So I give everything a ULA (which I'd want to do anyway so my internet going down doesn't mean my TV can no longer stream media from the server across the house, since that's a reasonable thing to expect to happen) and then look at doing some sort of prefix translation. Except since nobody's using this stuff because it's so very not hard, I hit a bunch of weird edge cases in my network gear trying to do that. Not the least of which is that I need to statically configure the prefix I'm translating _to_ except that's not provided to me statically so now I need to set up some sort of script to monitor the prefix on the external interface and dynamically update my firewall rules?
Oh, except apparently the RFC was only updated like a year and a half ago to prefer IPv6 ULA addresses over IPv4 so most devices would end up just using IPv4 anyway and the IPv6 deployment would be little more than a box checking exercise until everything's updated. (Though it looks like that change may never have been adopted anyway?)
Last time I was digging in to this, I ended up down a path of starting to file forms with IANA to get a IPv6 block directly allocated so I could use a GUA internally (avoiding the preference issue), do prefix translation for load balancing, and announce the IP range from AWS and tunnel it to my router to work around the /64 issue on the backup connection.
Or, or, or... hear me out... I can just... _not_. Nothing is broken right now. I derive no personal value or enjoyment from stacking up a house of cards I'll have to keep standing back up so my toaster can have a globally reachable internet address.
People can tell me it's "not hard" all they want, but after... oh hell, 30 years of bending computers and networks to my will, I feel pretty confident in saying either:
1. It is hard; or
2. IPv6 is fundamentally unfit for purpose.
I'd be happy for someone to come along and tell me I'm an idiot and _precisely why_ though. Really. Somebody. Please do. Tell me how I am supposed to make this work. I know it's a thing I _should_ be doing but I really can't figure out how.
There is an RFC proposal to allow SLAAC on networks that are smaller than /64, so you might be able to utilize the third connection and still have an ability to do subnetting.
I think “and we’re gonna kill NAT too!” is precisely where IPv6 overstepped and started making things worse for itself. It didn’t need to be this way.
NAT sounds like a bad idea at first glance, but it doesn’t exist just to alleviate address shortages (although it does.) It doesn’t just exist to provide security by default either (although it does that too.)
NAT is also the only sane choice in residential setups. Because your public IP address prefix isn’t static. That was never going to happen. And just saying “never put an IP address in any configuration file” isn’t a satisfactory answer. When a reprefix happens, and your clients are all only speaking on GUA addresses, your network is going to be fucked until they expire the old addresses. Not in theory, in practice. None of my devices in my household did any sort of reasonable thing when Comcast changes my prefix. I had to just go around and reboot everything.
NAT means I am in 100% control over what IP addresses I configure in my own network. It means I can actually run a DNS server and it works. It means I can configure devices with static addresses and it actually works.
ULA isn’t some edge case, it’s the only sane option in residential setups. (You know, that thing you need to maximally support in order for ipv6 to have a chance in hell at succeeding.)
The IETF finally releasing guidance that ULA’s should be on equal footing to GUA’s feels like them finally admitting that there might be something to this whole NAT thing. It happened entirely too late IMO.
With IPv4 and NAT, I'm setting up a network. I control it from end-to-end. I can define whatever subnets I want, connect them how I want, put a static IP on my IoT device so Home Assistant can find them reliably, etc. Then I have _a_ point (well, three) where my network touches another network and all configuration and setup around how the two interface and interact is defined and controlled there.
With IPv6 the expectation is I'm building out another little piece of someone else's network. Now all the communication within my network is closely intertwined with theirs. There's really no good way for me to handle that today.
Using SLAAC so devices update when prefixes change leaves me unable to find/connect to anything. Short of installing a DDNS client on my air quality monitor somehow, how do I manage to connect to it?
I can use DHCP6 (not on Android though!) and let the server handle DNS registrations. This would also regain the ability to push a NTP server to clients which would be a nice thing to have. Except now when the prefix changes the devices have no way to know and (like you say) I have to run around and reboot everything.
And this still doesn't give me a path to load balancing across multiple connections!
I guess really the bigger issue here is the dynamic nature of the prefixes. If I could go log into IANA and click a button and get assigned a /48 then log in to my ISPs' sites and attach it to my connection and be on my way... I'd deploy it today, no problem.
I can't see any _technical_ reason that wouldn't be possible. But there isn't a snowball's chance in hell any ISP starts offering that ability on consumer connections when they could be gating it behind having a $5k/mo business connection.
> I guess really the bigger issue here is the dynamic nature of the prefixes. If I could go log into IANA and click a button and get assigned a /48 then log in to my ISPs' sites and attach it to my connection and be on my way... I'd deploy it today, no problem.
Yes, this right here. It should work like a phone number where you can take it from provider to provider. You setup your gateway with your IPv6 prefix and then go.
Problem is all the technical and non-technical stuff to actually make that work.
- Verifying ownership of the prefix (rPKI or IRRs) and which ASNs are allowed to advertise it.
- Limiting allocations to someone? I guess phones solve this with SIMs
- Getting your ISP to route the traffic to your device
- Getting the device to announce it with RAs
- Dealing with asymmetric return routing over a slow "path" since it could be multi-homed
- Dealing with routing aggregation since IPv6 routing tables would explode with all the /56s in there
I know people that get a prefix from their RIR, announce it from a cheap $2 VPS in the same data center as their ISP, then just do a quick WireGuard tunnel to it (so sub-millisecond additional latency, ideally) and use that to route packets from the prefix. I guess it works pretty well, but like you said: I can also just… not.
Because the other issue if you’re ULA-less is that if your router loses its connection and rescinds its RA (or you just stop the RA daemon, or shut down the router, etc), suddenly you don’t even have LAN connectivity any more because everything will have deleted its routes.
> I can't see any _technical_ reason that wouldn't be possible
Every additional route and its ASN takes up RAM in nearly _every_ router that has a DFZ (default-free zone) view. This RAM is not cheap, so regional registries are incentivized to keep the number of new registrations down.
For IPv4 there are about 1 million routing entries right now, and for IPv6 about 200k. The IPv6 routing space can reasonably scale by about 5-10x before requiring serious changes in the core routers, but that's just not a lot of entries.
Yeah, that thought had crossed my mind and for some reason I figured "hey, hurricane electric will give me a /48 at points all over the world, guess someone figured it out". Thinking back... no, that doesn't mean that. It's not portable and there's no reason they're not assigning from different pools at each location.
I think that the main challenge people face with IPv6 is that they try to deal with it in the same way as with IPv4. IPv6 is not just a longer address, it's a completely different technology.
It took me a very long time to figure out how to configure my docker containers on my home server to have global IPv6 addresses. But I did it, and it taught me a lot about IPv6. I would personally prefer for the internet to be IPv6 only. It would make certain things much easier like firewall rules, IP whitelisting, and no more stupid CGNAT.
Considering in the UK you can get sim cards with 10GB or so of data for pennies I'm a bit surprised I don't hear much about people doing old school self hosted direct access stuff over ipv6.
Would there be much of a security risk if you had a dedicated device on its own network that doesn't actually directly communicate with anything else in your home?
I’d prefer to keep it on but every time I try it I run into a bunch of odd bugs. Silly stuff like GitHub container registry pulls being dialup speeds but docker.io being fine. Disable ipv6 and both at gigabit speeds. Bizarre stuff like that which I just don’t have the time and energy to go spelunking into the mysteries of dual stack to untangle.
The issue with IPv6 is that it's just too big; IETF overcompensated. Exponential growth really didn't occur "as planned" and addresses are barely readable to humans. 2^64 would have been better. That's something you can code using just 0-9 and no human will be forced to recite a never ending hexadecimal string.
My services are often run behind cloudflare, who does ipv4 for me and proxies to my ipv6-only vps.
Should you use this? Well docker's security model is pretty much only https, so it's like using a proxy server from some random hackernews comment for your `curl|sh` needs, without end-to-end encryption.
I wish github would just step up their game, at least for ghcr.io.
Try all major isps for one. Bell Telus Rogers. Just Google it and you'll find tons of people dealing with this problem as they discover they can't host anything because they're natted and unreachable.
I've lived in Canada for > 20 years in several cities and provinces. I'm telling you that CGNAT is extremely common.
I don't think you have any idea what you're talking about.
Neither Bell,Rogers or Videotron use NAT for residential internet - one is getting a global unicast IPv4 on their home routers. (Some locations are dual stack, like mine residential connection)
For mobile Bell uses 464XLAT. Bell mobility is IPv6 only network, also MPLS free, they are SRv6 early adopters, impressive!
Rogers, Videotron mobile use NAT44 for IPv6. IPv6 is native on Rogers.
In the US, Metronet uses CGNAT. There's another local ISP which uses it. They use it because they're small, growing, and cannot afford enough v4 IPs. They also have no plan to switch to IPv6.
The big issue I've seen is that there are not clear wins for all the pain of IPv6. And the failure to provide a much much better ipv4 interop story out the gate (vs just trying to yell at everyone to switch) was a big big loss. So that means folks ended up having to run ipv4 to end devices in many cases and we have dual stack hell across the network.
For the 90%+ of network clients on-prem that play by the rules you are often supporting both DHCP and SLAAC on IPv6 networks (unless android has figured out DHCP).
Dual WAN redundancy on IPv6 in SMB settings is actually worse relative to a NAT and ipv6.
The subnet size /64 is stupidly large, and the number of available subnets you can easily get annoyingly small from most upstream providers.
Firewall filtering has to be modified or you get weird errors. People don't always like ICMP coming through the firewall.
It's does lots of things differently, but for what? We do prefix delegation with DHCP but can't use DHCP to assign address (we are supposed to use SLAAC) but still need DHCP for lots of other stuff? It's nonsensical - you end up with just way too much garbage.
The privacy extension stuff hits IPv6 hard. You have lots of auto-rotating addresses.
The number of times turning of IPv6 fixes weird glitches / timeouts / stalls etc is still crazy too me.
ATT (massive corp) requires end user devices request /64 subnets one by one - which most end user gear does not support.
Getting static ipv6 IP's (despite claims there are lots of them) is seriously hard from upstream providers in many cases - but IPv4 is trivial by comparison.
The list goes on.
I would have made the subnet size 32 bits. Expanded the network part. Maybe even reduced the overall size - 128 bits feel dumb with /64's as the smallest subnet? Then just go super high interop / overlay to IPv4 with great suggestions so folks could ship ipv6 only stuff (even with on device bridge to ipv4 so outbound interface is ipv6) and no new concepts unless clearly justified.
One thing I like about IPv6 is the lack of CIDR so that every IPv6 address always has the same 48 bit site prefix and then 16 bits of subnets and than 64 bits of host. It is easy to remember the 48 bit prefix and then you can actually just sequentially number subnets and hosts if you want so an address can be prefix:1:1 if you want.
One thing I hate about it is that they used 64 bits for host which is just absurd. 32 bits or even 16 bits would have been plenty for a single broadcast domain.
The 64-bit host space is used by SEND to hold a cryptographic key as part of a method of securing neighbor discovery. 16 or 32 bits would be laughably inadequate for that. It's also used as a passive defence against IP scanning, making it significantly harder for worms to spread by brute-force scanning.
I admit it does make the address space look a bit lop-sided, but taking bits away from the host side (where they're being used) and giving them to the network side (where we should already have enough space anyway) wouldn't be a sensible trade.
That is a clever hack made necessary by the lack of crypto as part of the IPv6 protocol like it should have been. If they were more ambitious they would have built something like the Locator/ID Separation Protocol (LISP) (RFC 6830) directly into IPv6 but used public keys as the ID.
In my career I have found IPv6 simply to be unnecessary. Running a network of 7 buildings with approximately 2,300 computers for now almost 2 decades and this is still true.
Setting edge routers to simply drop all ipv6 packets and running only ipv4 works, is simpler, is faster (than dual stack) and easier to troubleshoot.
I don’t have any inheritant issues with IPv6 other than is has failed to make a case for why people like me should bother rolling it out.
Imagine running a VPN hub for about ~800 customers that your IT people do remote administration for. We moved to this model because each customer tends to use their own preferred VPN agent, and multiple VPN agents installed on the same machine tend to fight each other to the death (and the host's).
To avoid ip-range clashes between customers, traffic inside the hub was IPv6-only, with each customer given their own prefix. Routing permissions were based on group membership, so we had a very easy and secure way to make sure each of our users was only able to reach their own customers, and personnel changes did not require any customer-side changes.
Although it sounds like keeping IPv4 is a reasonable choice in your situation, if you merge with another company (or otherwise connect your networks) that uses overlapping private IPs it will cause issues.
You don't "choose" your IPv6, they are assigned to you. Even if you used private IPs (ULA) for whatever reason, there are enough of those too not to conflict.
By comparison my company uses the entirety of the private IPv4 space. `docker compose up` often fails because there is no private IP range left that is not directed through the VPN.
curl -6 https://github.com -o /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 273k 0 273k 0 0 957k 0 --:--:-- --:--:-- --:--:-- 956k
Working with IPv6 if you are not entitled to switch out every vendor, every piece of hardware, every piece of software that is lacking.. that's the hard part.
Off-topic but I'm curious why would someone purposely left-align a website? It makes no sense unless you're _really_ trying to avoid css which is not the case here.
I am SO tired of "is hard." I cringe every time I see this boring cliche.
It's a meaningless way of saying "look at me I'm smart." Everything is or is not hard depending on the audience and what it's being compared against. IPv6 is hard compared to Ethernet, but easy compared to managing a mess of NATs to handle V4 networks with conflicting addresses at different locations. All of this is a lot easier than understanding the leading proposed theories of quantum gravity.
> So in the case of the toot mentioned above there is an AAAA for the FQDN. But the connection doesn’t work. But the end user doesn’t notice. Because there is a browser feature called Happy Eyeballs (HE). Basically: A browser tries both protocols and uses the faster on. In case of non-working IPv6 IPv4 is always faster.
I mean even if there is no "Happy Eyeballs", it would still work for end users, no? Unlike `curl`, you don't specify -4 or -6 with browsers. Without HE, wouldn't (shouldn't?) it just try both in sequence?
> HE can have some funny side effects. In a project a connection to a development web server sometimes worked and sometimes didn’t. The solution was quite simple. The customer used a split VPN tunnel. IPv4 was routed via the VPN tunnel and those IPv4 addresses were allowed in the web servers access list. IPv6 was routed via the normal Internet connection and those addresses weren’t allowed.
This following sentence makes no sense, when the author literally said HE help it work when one IP family was broken and the other is not. So why would it work sometimes if IPv6 is consistently broken and IPv4 is not? (I'm not saying it won't happen; just that it shouldn't be "caused by HE" -- HE literally is the solution to this issue in general as the author said themselves!)
> I mean even if there is no "Happy Eyeballs", it would still work for end users, > no?
No browsers and other clients prefer IPv6 and there would be a rather long timeout till the client falls back and tries IPv4. If it falls back.
> So why would it work sometimes if IPv6 is consistently broken and IPv4 is not?
> (I'm not saying it won't happen; just that it shouldn't be "caused by HE" -- HE > literally is the solution to this issue in general as the author said
> themselves!)
IPv6 wasn't broken. For HE, an HTTP 403 is a valid connection. TCP handshake works, IPv6 works.
I had another case where the TCP handshake worked, and the browser decided to use IPv6 is good, but then came the TLS handshake, and it failed because PMTUD (Path MTU Discovery) was broken.
Which is why I deactivated IPv6 on almost every device in my network. My main issue is that the router/gateway provided by my ISP does not support DHCPv6 prefix delegation, which causes a couple of issues in my setup.
Sometimes you can try really hard to archive a goal, but when the workarounds to simple problems become new problems, it's time to say "no".
In theory it can use any protocol since TTL exceeded should work with any IP packet. I don't know if there's consistency between traceroute implementations so maybe some use ICMP and some use UDP.
Depends on whether you mean the tool of the technology. Yes, the common traceroute uses icmp, but since it has become very popular for transit networks to ignore echo requests, there's also tcp (e.g. lft) and udp (e.g. Cisco's default) traceroute tools.
Asking for a friend, like, what all the ipv6 use in the world is.
I'm curious. On the other side of CGNAT, you know, the mobiles, can they individually address each other, or can they only talk to each other through the CGNAT? I honestly don't know.
IPv6 is mainly only wanted by people whose job it is to track people. In any IPv6 discussion they yell, flap their virtual arms and gums and attack any non-IPv6 true believers.
ipv6 has this bullshit smell. bullshit, because it has this fucking useless naming convention (it's not for humans...) and overly complicated. like it was invented to muddle things about the internet, to raise the bar to understand it and hence coerce control. it resembles something that is not man made or deliberately made to be hard to use.
IPv6 isn't hard, and as the article alludes to, it is different, but it's not even that different.
What is hard, is dual stack networking. Dual stack networking absolutely sucks, it's twice the stuff you have to deal with, and the edge cases are exponentially more complex because if your setup isn't identical in both stacks, you're going to hit weird issues (like the article suggests) with one stack behaving one way and the other behaving another way.
None of this is the fault of IPv6, it's a natural consequence of the strategy of having two internets during the transition period. A transition period which has now been going on longer than the internet existed when it started.
Maybe 100 years from now we'll finally be able to shut off the last IPv4 system and the "dream" of IPv6 will become a reality, but until then, life is strictly more difficult on every network administrator because of dual stack.
(Note: no, we could not have done it any other way. Any upgrade strategy to IPv4 that extended the address size would have necessitated having two internets. It just sucks that it's been this long and we're still not even at 50% IPv6 usage.)
For what it's worth I have many years of technical experience and a pretty decent knowledge of IPv4 networking, and I found it quite hard - at least when first learning.
The addressing is intimidating, getting your head away from NAT, thinking about being globally routable, the lack of (or variances in) DHCP, ND, "static" addressing via suffixes, etc.
None of this is technically "hard", but it's a significant barrier to entry because it's quite different to what most normal technical users are used to.
Dual stack may create some new problems, but it fixes a lot of others. All of the major cloud providers have awful IPv6 only support, and many prominent web resources that usually invisibly "just work" have little to no IPv6 support.
I think you thought it was hard precisely because you had a decent knowledge of IPv4.
I suspect that if the situation were reversed and we always had IPv6, and someone proposed a new IP suite where you had to use NAT for everything, and all hosts needed to have their addresses hand-picked (or served via a DHCP server that used an ugly hack to communicate with hosts that don't have an IP yet), you'd find that to be the "hard" one.
The one objectively difficult thing about IPv6 is remembering an address. Four base-10 numbers between 0 and 255 fit in working memory, while eight groups of four hex digits don't. Even a shortened address can be difficult to recall.
Your working memory must be better than mine.
I can remember two numbers from 0 to 255, but four? Not in a million years.
Isn't there an idea that our working memory holds seven pieces of information? Which would be two of those numbers and change, if you consider each digit as a piece of information.
We live in an era with ubiquitous DNS, easy host file management, post-it notes still exist, and everyone has some note taking app or three on their pocket computer too. At some point if needing to remember an IPv6 address is your biggest concern with IPv6, that's a decent place to live and there are plenty of workarounds all around you.
If you want to increase adoption of a technology then the onus is on you to convince everyone else. I think being dismissive of the human element is not going to help you very much.
First of all, I don't have direct skin in this game, it's not my job to convince people to use more IPv6. (I think it's a good idea, but I'm not here to convince anyone.) Second of all, I wasn't being dismissive at all, I listed a number of good workarounds to enhance the human element, because yes human memory is (very) fallible. I'm also in the category that I've never been able to keep IPv4 addresses in my working memory (I can have a bit of dyscalculia, myself, and sometimes know all the individual digits but be entirely unable to retain their order among each other). I've personally always needed these workarounds, and was just providing a list of options for those new to this need. (Welcome to the club.)
I also could have mentioned mDNS as a distinct subclass of DNS. That's most of what I use in IPv6 LAN stuff, personally, but I don't have a lot of subnets to worry about. Also I could have mentioned tricks like writing down a subnet prefix somewhere such as a .env script and using assigned addresses full of zeroes in that prefix like $PREFIX::1, $PREFIX::16, $PREFIX::cafe, or also, if you really want, and just miss dotted quads that much: $PREFIX::136.324.154.123 (that's been a supported address format for a few years now as long as it is on the right side of a :: shortcut).
Yeah, it makes me think of finding an automatic car difficult because you're used to manual. I have noticed people are often reluctant to give up on something they had to learn, though.
It doesn't help that the use of an IPv4 is a status symbol that indicates that you are willing to spend money on your infrastructure (and are thus not a spammer). If you attempt to run an email server on IPv6, you will see what I mean.
That's not what I am observing while running a number email servers which having both IPv4 and IPv6. Spam is only on IPv4 and about 80% of legitimate email is on IPv6.
Yes, but those facts don't reach the email filtering business: There, IPv4 IPs have some reputation, maybe good or bad. IPv6 "just doesn't exist" and has a universally bad reputation. Thus your IPv6-Emails will be filtered and dropped more often, even though you are correct that actually IPv6 is an indicator of non-spam. I've got quite a few transport rules to work around those kinds of braindead filters...
> IPv6 "just doesn't exist" and has a universally bad reputation.
I've been sending my mail via IPv6 for ages without issues… did you mean reputation or reputation?
> I've been sending my mail via IPv6 for ages without issues…
In most cases it does work and there are no problems. But especially medium-sized businesses who run their own email through some crappy mailfiltering middlebox file anything that comes from or through an IPv6 endpoint to spam.
> did you mean reputation or reputation?
I don't understand your question. I meant IP address reputation, which is what many mail filtering systems use to estimate spam probability or outright reject email. See for example https://www.spamhaus.org/ip-reputation/
That does not match my experience either. In fact I don't see why any mail server would bother getting and configuring an IPv6, listen on it, just to drop all received messages.
Just don't listen on v6, that would achieve your goal, would prevent reputable dual-stack senders (like Google!) to send messages over v6 that you'll drop, and simplify your configuration.
> I don't understand your question. I meant IP address reputation, […]
There's reputation of the IP address(es) among spam filters, and there's reputation among human operators configuring mail servers. I was trying to riff on ambiguity with ambiguity, that wasn't particularly helpful, sorry.
I found an open email relay on IPv6 once, because nobody scans IPv6 and therefore nobody ever sent spam through it. (Apparently this was caused by a reverse proxy misconfiguration causing the server to think IPv6 connections were from localhost)
Also the surface area of IPv6 is huge, it just takes so much time to scan everything. It's not security, but it's a deterrent.
And yet scanning IPv6 is exactly what some people are doing.
IPv6 nodes aren't individual random addresses in a 128-bit address space. They are going to be grouped in subnets, so it makes sense to explore /64 ranges where you know there's already at least 1 address active. There's a pretty decent chance at least some addresses are going to be sequential - either due to manual configuration or DHCPv6 - so you can make a decent start by scanning those. For non-client devices, SLAAC usually generates a fixed address determined by the NIC's MAC address, which in turn has a large fixed component identifying the NIC's vendor. This leaves you with a 24-bit space to scan in order to find other devices using NICs made by that vendor - not exactly an unfair assumption in larger deployments. Much faster scanning can of course be done if you can use something like DNS records as source for potential targets, and it's game over once an attacker has compromised the first device and can do link-local discovery.
It's not going to be extremely fast or efficient, but IPv6 scanning isn't exactly impossible either. It's already happening in practice[0], and it's only going to get worse.
[0]: https://www.akamai.com/blog/security-research/vulnerability-...
Well, and the easiest way is some sort of web bug/tracker/log or traffic analysis.
See what address gets used, and blam.
In many situations it's a necessity. Ipv4 only devices can't connect to ipv6 only servers. So if you have ipv4 clients, your server has to support ipv4.
Get a front that binds a IPv4, with a loadbalancer or a wireguard tunnel.
Yes. In my day job I work mainly on containers running entirely in data centers we own, they are fully ipv6, it’s very nice to work with.
Then there is this one customer, they are colocated in other ISP owned datacenters, and some of their server maybe have fully IPv6, some may have only IPv4, some may be a mixture of both. Supporting them is a never ending nightmare.
To add:
The really sad thing about IPv6 is that it's a relic of a bygone era. The internet was envisioned as a thing where every device on every network could, in principle, initiate a connection to any other device on any other network. But then we started running out of addresses, ISP's wouldn't give you more than one for a household, so we started doing NAT, and that kind of sealed the internet's fate.
Nowadays, we wouldn't want a world where everything was connectable, even if we had enough addresses. Everyone's network in essence has a firewall. If you run IPv4 and using NAT, you're going to be dropping unsolicited incoming packets no matter what (let alone that you wouldn't know where to route them even if you wanted to let them through) and with IPv6 you'd be insane to allow them.
Devices have "grown up" in a world where we expect the router we're connecting to, to shield us from incoming unsolicited traffic. I certainly don't have the firewall enabled on my linux desktop. Windows I _think_ has it enabled by default, but I often turn it off because I want LAN connections to work. MacOS is probably similar. Suffice to say, if the IPv6 dream happened overnight and everyone's devices were instantly connectable, all hell would break loose. We need our routers to disallow traffic. (Edit: This wasn't all that clear, so let me restate: In both the IPv4 and IPv6 world, you'd be insane to disallow incoming unsolicited traffic, which is why basically everyone blocks it in IPv6 as well as IPv4. I'm not trying to say IPv6 can't do this... quite the contrary: IPv6 routers absolutely do, and should, block unsolicited incoming traffic. But my point is that this is what prevents the original vision of IPv6 from becoming a reality: We can't design software around the idea of direct peer-to-peer communication, without stuff like UPnP. Oh, and UPnP works with NAT and IPv4 anyway so, there's the rub.)
So, even in a pure-IPv6 world, that instantly prevents any startup with an idea to allow true peer-to-peer communication using end-to-end routability. What are you going to do, train your users to log into their router and enable traffic? Approximately 0% of your customers know how to do that, even in a counterfactual universe where IPv6 happened and we all have routable IP's on our devices. Maybe in such a universe, people would be trained to use local firewalls on their device, and say "ok" to popups asking if you want to let software through. But I'd wager that a lot of people would prefer the simplicity of just having their gateway drop the traffic for them.
No, the "all devices are routable" idea came from a naive world where there wasn't a financial incentive for malicious behavior at every turn. Where there aren't millions of hackers waiting for an open port to an exploitable service they can use to encrypt all your data and ransom it for bitcoin. The internet is a dark forest now. We don't _want_ end-to-end connectivity.
Every consumer router I’ve ever seen drops unsolicited IPv6 packets by default. But that doesn’t mean that P2P routing is suddenly impossible.
IPv6 makes P2P routing substantially easier, even in a world of default firewalls that drop unsolicited packets. You can still apply standard NAT busting techniques like STUN with IPv6 devices behind firewalls, and you get much better results because IPv6 removes the need to track and predict the port mapping a standard NAT does. Two P2P systems can both send unsolicited packets to each others IPv6 addresses, with a specific port, and know that port number isn’t going to be remapped, so their outbound packets are guaranteed to have the right address and port data in them to get their respective firewalls to treat inbound traffic on those addresses and ports as solicited.
This is particularly useful when dealing with CGNATs, where your residential devices ends up behind two NAT layers, both of them messing with your outbound traffic, which just creates an absolute nightmare when trying to NAT bust. IPv6 means that you’re no longer dealing with three or more stateful NATs/firewalls between two peers, and instead only have to deal with at most 2 (in the general case) stateful firewalls, who’s behaviour is inherently simpler and more predictable than a NAT ever is.
The argument that NAT-busting (firwall-busting?) becomes easier with IPv6 is certainly true, but "easier" isn't necessarily enough to warrant an entirely new protocol suite. If that's the only benefit of IPv6, it doesn't sound worth it to me. UPnP/STUN is still possible with NAT/CGNAT, and you're going to need something like that even if there were no NAT, so to me it sounds like a bit of a wash, at least to the end-user.
(Of course, the other huge benefit of IPv6 is "more addresses", so we need it just for that. But my point is that "global routability" isn't really the dream people think it is. In practice, the only differences between modern GUA-but-deny-by-default IPv6 setups and NAT'ed IPv4 setups are the simplicity of the former for the network administrators.)
> UPnP/STUN is still possible with NAT/CGNAT
You should tell that to my ISP, they’ve managed to deploy a CGNAT that’s proven to be completely STUN proof. The only way I can achieve any kind of P2P comms is using IPv6. IPv4 is useless for anything except strictly outbound connections.
> and you're going to need something like that even if there were no NAT, so to me it sounds like a bit of a wash, at least to the end-user.
Not in my case. As above, I simply can bust my ISPs CGNAT, so IPv6 is invaluable to me. Makes a huge difference to me, the end-user.
> If that's the only benefit of IPv6, it doesn't sound worth it to me.
It's not the only benefit, as anyone who's tried to build a large network or merge two networks with overlapping address space will tell you.
IPv6 doesn't actually save you because it presumes a cultural norm that people will use globally unique addresses for all their networks which, while now possible, I imagine many network engineers will use IPv6's private address space to avoid ever having to re-address their network on ISP changes.
> I imagine many network engineers will use IPv6's private address space to avoid ever having to re-address their network on ISP changes.
Except with 10/8 (or 172/12) everyone is using the same address space. How many network have a 10.0.0.0/24? What are the odds of a conflict for that?
But if you have an ULA FDxx:xxxx:xxxx/48 address space, what are the odds that all those x bits will be the same for any two sites? That's 40 bits 'entropy'. Much, much lower (notwithstanding folks doing DEADBEEF, BADCAFE, etc).
Not only that. Having private IPv6 addresses in the LAN is the easiest way to work with two ISPs and have fail-over. The other way is RFC8475, but I don't know of any implementation except my custom script on OpenWrt: https://forum.openwrt.org/t/ipv6-wan-fail-over-without-ipv6-...
I imagine the threshold of org size where they stop taking their prefixes from their ISP and just go get their own from the RIR is .... Not big.
Sure, some network engineers will try and design v6 networks as though they're v4, but everyone else will just go and get a squillion addresses from the RIR that's unique to their org and then just use/announce that.
What about home private network (for smart home, for example)?
Home networks don't usually have the problem of having to suddenly merge together with another, similarly-addressed network.
Nothing stops you getting a subnet allocated from your local RIR and announcing that on the internet, if you care about that sort of thing for your home network though. You just need a decent ISP.
> Nothing stops you […] You just need a decent ISP.
I’ll just leave that there.
No, I can’t just choose to have a decent ISP. I live in the real world where there’s only one choice where I live, same as a rather large majority of people in the world.
'You should switch your working local networking stack so as to help the scenario where the company is bought and you may well not be working there anymore and it's someone else's problem. Or the scenario where the company buys a different company and very likely needs to investigate and remodel the other company's network anyway.'
> UPnP/STUN is still possible with NAT/CGNAT
Sometimes. I've experienced a few networks where even with STUN I'm still not able to get a workable session in IPv4.
Fixing that network you had an issue with to have working NAT-PMP or whatever is going to be infinitely easier than IPv6ing the entire world.
I can't just ask my cell provider to change their CGNAT setup. There's nothing I can do on my end.
1) To the extent to which you can't ask them to change their CGNAT setup, you also can't "just" ask them to upgrade to IPv6.
2) In fact you at least can ask them to change their CGNAT setup, as they at least could, if they chose, unilaterally fix their CGNAT setup, while--even if you also felt it possible to ask them to upgrade to IPv6--upgrading to IPv6 as the solution requires the rest of the world to upgrade as well.
The real question is then: which is solution to your problem is easier and cheaper to obtain, and the answer is clearly not "upgrade the world to IPv6". "I couldn't convince my ISP to fix their CGNAT setup, so I'd rather convince them--and everyone else--to upgrade to IPv6" makes no sense as a coping mechanism.
The model of having every router being a firewall has created a fair bit of false security, with vulnerable systems being left behind the firewall and simply waiting until a user inside the network does something unwise. It seems a common story where whole hospitals or municipalities get shut down because one host got infected and then all the unpatched system in the same network got hit.
There is also a bit of conflated use of terms. A firewall on windows is just a fancy name of permission management. A program want to open a port and the user get a prompt if they want to allow it (assuming the user has such privileges). It is indistinguishable from similar permission system found on phones that ask if an app is allowed to access contacts. The only distinguishable "feature" is that programs might not be aware that the permission was denied, thus opening a port that is not actually open. Windows programmers may know more of the specific of this.
So your idea is to open up access so all the IT orgs that can't keep their systems secure ...
... which is ... virtually all of them ...
get p0wned on a massive scale? You know, now with AI powered assaults for extra special vulnerability levels...
And then a magic wand happens, and the IT orgs that couldn't even install patches will be able to back-discover all the compromised hard drive firmwares, rootkits, and nth-level security holes after the fact?
I get a NAT wall isn't perfect security. But pretending it is NO security is disingenuous.
Every company in spoken to in the last few years has been moving toward zero-trust network, where you assume that every single device is on a hostile network. There’s nothing inherently safe and secure about the corp network, so treat it as if all those cubicles were connecting in from Starbucks.
IMO this is the only way forward.
Not the parent but obviously no, but maybe if in the 90' it was the standard to not assume that the network was secure we would be in a better spot now (maybe a spot where company intranets use authentication instead of vpns
There is a solution to this: RFC6887.
You have a firewall at the edge of the network. It blocks incoming connections by default, but supports Port Control Protocol. The cacophony of unpatched legacy IoS devices stay firewalled because your ten year old network printer was never expected to have global connectivity and doesn't request it. End-to-end apps that actually want it do make the requests, and then the firewall opens the port for them without unsophisticated users having to manually configure anything.
The protocol is an evolution of NAT-PMP (RFC6886) for creating IPv4 NAT mappings, but RFC6887 supports IPv6 and "mappings" that just open incoming ports without NAT.
Sure, but is it actually a feature you want, though? We're never going to run out of legacy unpatched devices, and today's shiny new devices are going to be tomorrow's tech debt. If you support that kind of hole punching, sooner or later you will end up with vulnerable devices exposing themselves to the internet.
There's no way in hell enterprise admins are going to give that kind of control to random devices, and home users aren't going to have the skills to cull vulnerable devices from their networks. So who's going to use it?
In my opinion the current kind of hole punching is a far better option: instead of creating a mapping allowing essentially unrestricted access from everyone, have the app use an out-of-bounds protocol to allow a single incoming connection from exactly one vetted source. You get all of the benefits of a direct peer-to-peer connection with none of the risks of exposing yourself to the internet. It's well-researched when it comes to the interplay between firewalls, NAT, and UDP[0].
And that pretty much solves the problem, to be honest. These days you only really need incoming traffic to support things like peer-to-peer video calls. Hosting game servers on your local machine is a thing of the past, everything has moved to cloud services. What's left is a handful of nerds running servers for obscure hobby projects at home, but they are more than capable of setting up a static firewall rule.
[0]: https://tailscale.com/blog/how-nat-traversal-works
> We're never going to run out of legacy unpatched devices, and today's shiny new devices are going to be tomorrow's tech debt.
It's not about new or old. The devices that don't have any reason to be globally reachable never request it. New ones would do likewise.
Devices that are expected to connect to random peers on the internet are going to do that anyway. It's not any more secure for them to do it via hole punching rather than port mapping; causing it to be nominally outgoing doesn't change that it's a connection to a peer on the internet initiated by request of the remote device.
> There's no way in hell enterprise admins are going to give that kind of control to random devices, and home users aren't going to have the skills to cull vulnerable devices from their networks. So who's going to use it?
Enterprise admins can easily use it because they have control over the gateway and how it answers requests, so they can enable it for approved applications (in high security networks) or all but blocked applications (in normal networks), and log and investigate unexpected requests. They should strongly prefer this to the alternative where possibly-vulnerable applications make random outgoing HTTPS connections that can't easily be differentiated from one another.
Whether they will or not is a different question (there are a lot of cargo cult admins), but if they don't they can expect their security posture to get worse instead of better as the apps that make outgoing HTTPS connections to avoid rigid firewalls become the vulnerable legacy apps that need to be restricted.
Home users are already using NAT-PMP or UPnP and this has only advantages over those older solutions.
> instead of creating a mapping allowing essentially unrestricted access from everyone, have the app use an out-of-bounds protocol to allow a single incoming connection from exactly one vetted source. You get all of the benefits of a direct peer-to-peer connection with none of the risks of exposing yourself to the internet.
There are significant problems with this.
The first is that it's a privacy fail. The central server is at a minimum in a position to capture all the metadata that shows who everyone is communicating with. It's made much worse if the payload data being relayed isn't end-to-end encrypted as it ought to be.
But if it is E2EE, or the server is only facilitating NAT traversal, the server isn't really vetting anything. The attacker sends a connection request or encrypted payload to the target through the relay and the target is compromised. Still all the risks of exposing yourself to the internet, only now harder to spot because it looks like an outgoing connection to a random server.
Worse, the server becomes an additional attack vector. The server gets compromised, or the company goes out of business and the expired domain gets registered by an attacker, and then their vulnerable legacy products are presenting themselves for compromise by making outgoing connections directly to the attacker.
Doing it that way also requires you to have a central server, and therefore a funding source. This is an impediment for open source apps and community projects and encourages apps to become for-profit services instead. The central server then puts the entity maintaining it in control of the network effect and becomes a choke point for enshitification.
Meanwhile the NAT traversal methods are ugly hacks with significant trade offs. To keep a NAT mapping active requires keep-alive packets. For UDP the timeout on many gateways is as short as 30 seconds, which prevents radio sleep and eats battery life on mobile devices. Requiring a negotiated connection is a significant latency hit. For real peer to peer applications where nodes are communicating with large numbers of other nodes, keeping that many connections active can exceed the maximum number of NAT table entries on cheap routers, whereas an open port requires no state table entries.
> What's left is a handful of nerds running servers for obscure hobby projects at home, but they are more than capable of setting up a static firewall rule.
The point is to allow interesting projects to benefit more than a handful of nerds and allow them to become popular without expecting ordinary users to manually configure a firewall.
> It's not about new or old. The devices that don't have any reason to be globally reachable never request it. New ones would do likewise.
Doesn't this assume all devices are well behaved, trusted and correctly implemented? You don't think the crap Samsung Smart TV will consider itself to have a reason to be globally reachable?
Most of them actually wouldn't because they have no reason to do it and creating the mapping for no reason is work. Making the thing where you're not exposed to the internet the thing that lazy developers get by default is a win.
Some of them could do it for no reason, but they could also have the devices make outgoing connections to the company's servers and then blindly trust any data the servers send back, even if the servers are compromised or the domain expires and falls into the hands of someone else, or the company's own servers are simple relays that forward arbitrary internet traffic back to their devices.
If a device can make outgoing connections then it can emulate incoming connections. Blocking incoming connections to devices that explicitly request them is therefore not a security improvement unless you're also prohibiting them from making any outgoing connections, because the result is only that they do it in a less efficient way with more complexity and attack surface and less visibility to the user/administrator.
Interesting, I haven't read much about that. I've always assumed somebody must have written an RFC to automate how home firewalls should be configurable automatically by software that "wants to" allow incoming connections. Good to see that it exists.
But it doesn't seem to be in widespread use, does it? Like, would a random internet gateway from podunk ISP support this? I kinda doubt it, right? Pretty sure the default Comcast modem/router setup my mom uses doesn't support this.
But I guess my point was about the contrapositive universe where IPv6 was actually used everywhere, and in that universe I suppose RFC6887 might have been commonplace.
Every ISP router I've had with even basic IPv6 support has supported PMP. Every home router I've handled with IPv6 support has supported it. So IME it is in pretty widespread support. Maybe there's some devices out there that don't, but it's at least as wide as UPnP support which was pretty wide.
Things like this can be useful without 100% penetration. Most end-to-end apps support a direct connection as long as either of the endpoints have an open port. Endpoints without one can also fall back to relays, but since port mapping is frequently used in gaming, that has higher latency and then users start demanding gateways that support the thing that lowers lag.
Then it starts to make it into popular internet gateways. For example, the Comcast consumer gateways generally do support UPnP, which is a miserable protocol with an unnecessary amount of attack surface that should be transitioned to Port Control Protocol as soon as possible, but it demonstrates you can get them to implement things of this nature.
> What are you going to do, train your users to log into their router and enable traffic?
You do what has already been done for decades. You ship a client premises router that does deny by default inbound and allow all outbound and things behave pretty much the same as they do today with these exact same rules in IPv4.
Network firewalls still exist in a publicly routable network. If I want my game console to allow incoming traffic for game matchmaking, I can then do that. Or have systems that auto configure that. But then I don't have to have multiple devices fighting for a limited port range, each device has more IPs and ports than they could know what to do with.
Please re-read my comment, as it seems like you skimmed it and think I’m making a different point than I did.
To use your example:
> If I want my game console to allow incoming traffic for game matchmaking, I can then do that
My point is that because of the fact that even in IPv6, consumer firewalls will block traffic by default, the company that makes the game would not have designed it to require your console to have special configuration on your firewall. Because this is not something a typical gamer knows how to do.
Instead, companies use UPnP for matchmaking, and UPnP works in both NAT and GUA environments, so what exactly does GUA give you?
If you have two Xboxes or Nintendo Switches in a standard UPnP network you'll still have NAT issues. They'll fight over port assignments. If I've got two things wanting to listen on :5000 I'm boned, I've only got one :5000 to forward from. I could remap that port in NAT, but now the downstream device needs to know to tell other clients it's actual public port.
You'll have even more problems if you're on CGNAT networks. You're not going to be able to get any of that traffic.
None of this is a problem if each device has its own IP address and its own range of ports to deal with. Every device can have its own :5000, it can know it's public IP address without having to have something see from outside, and with how big assignments usually are it can have dozens of things all listening on a public :5000 all at the same time.
If you want to hypothesize a world where we’re all on IPv6 and thus game matchmaking software can take advantage of the unique addresses for every console, you should also admit that the same software could also just use a unique port for each console today, in IPv4+NAT.
In fact, in IPv6, privacy addresses mean that the address the gaming service observes from my device shouldn’t be assumed to work for other peers, because my device may only be using that address for communication to the gaming service itself. Instead, authors of this software ought to understand that the console itself needs to tell the service “this is the address peers can use to communicate with me”, and thus you may as well just include the port in that call, and then you don’t need to assume port 5000 will work (because if I have 2 XBox’s, they could decide on a different port if another console already has one used.)
It’s just I’m disillusioned with the idea of GUA’s for every device actually solving anything. It solves like 10% of the difficulty of writing good p2p software. All the other problems are still there: firewall config, dynamic IP’s, mobile IP’s, security best practices, shitty middleware boxes not doing the right thing, etc etc etc.
My biggest argument would be CGNAT in the end really doesn't care what UPnP you do at the edge of your network; you're not getting that traffic no matter what you do. IPv6 means there's no reason to have CGNAT at all; there's more than enough addresses to go around.
Does IPv6 solve it all? No. Does it solve some of it better than IPv4? Yep. Does it just completely eliminate the need for CGNAT? Yep. It is not a silver bullet to solve all problems, but it does solve some, and for that I'd much rather use it. Because I'd rather just be able to host whatever at home and not need to remember what port is what or rely on proxies looking at other info in the request.
> shitty middleware boxes not doing the right thing
You reduce the need for shitty middleware boxes. I don't need a reverse proxy. I don't need to have a STUN/TURN server. I don't need to randomize ports or worry about running out of ports.
> the same software could also just use a unique port for each console today, in IPv4+NAT.
Why solve a problem once properly in the network stack when you can add an ad-hoc workaround to each individual protocol instead?
> the console itself needs to tell the service “this is the address peers can use to communicate with me”, and thus you may as well just include the port in that call, and then you don’t need to assume port 5000 will work
And if you're behind CGNAT so your home router doesn't know what the address and port are, what then?
Not to mention the case of a multiplayer game between two people who live in the same house and a third person who doesn't. That's one that's trivial with IPv6 but difficult with every IPv4-based system I've seen.
> It solves like 10% of the difficulty of writing good p2p software. All the other problems are still there
It all helps. I mean, people mostly manage to play games with each other today, they just get disconnects or random lag every so often. Cutting down on that, even if it was only 10%, would make a lot of lives better.
For badly designed games maybe? There's no real reason why they need the same port forwarded, it could be any random port.
I'm dealing with the devices I've got and the software stacks they have. In the end they fight for port assignments on IPv4 and expect to just have massive port ranges assigned to them.
> Within the port range, enter the starting port and the ending port to forward. For the Nintendo Switch console, this is port 1024 through 65535.
https://en-americas-support.nintendo.com/app/answers/detail/...
Nintendo tells me to forward all high numbered ports to my console. Because obviously we're only going to have a single one in the house.
Fixing the broken software that somehow requires a specific port and getting NAT-PMP deployed is a hell of a lot easier than redoing all of the software and all of the networks to implement IPv6.
In an IPv6 world, your home router still firewalls just like with IPv4 (the NAT is just an extra accidental firewall-ish thing), you can still skip the firewall on your laptop
Having globally allocated address space doesn’t actually imply openness of connectability
I am the last person to be defending NAT, but the benefit of NAT is that it sets up a really good default: incoming connections are not routable by default, and it's very hard to accidentally change this. There are many good ways to have "not routable by default" with IPv6, but you have to do that at the software level, while NAT forces it at a protocol level.
> incoming connections are not routable by default, and it's very hard to accidentally change this
Not just difficult, but impossible, even in principle, because there are more than one device sharing the same IP so at most one host would be vulnerable. Not the same as with IPv6, where screwing up the defaults leaves your entire network vulnerable.
You can forward all ports to a device, pretty common feature.
Right but that only leaves that device vulnerable. The other devices are not.
In practice, that makes the entire network vulnerable.
Yeah, server-side NAT + use of a reverse proxy makes hosting many websites from one IPv4 a possibility, albeit a relatively difficult one. You are only really in trouble if two consumers want raw TCP/UDP on one port.
> incoming connections are not routable by default
Tons of firewalls ship with this as a default logic, it doesn't require NAT in the slightest.
Parent poster is making the (good and underrated) point that NAT makes this logic failsafe: Turn an IPv6 firewall off and you’ve got all incoming connections allowed. Turn IPv4 NAT off and you’ve got no connectivity at all
So gate it behind a "here be dragons" option or hide it in the GUI entirely for the basic home version.
Turning off the firewall could just as easily be a unnoticed configuration error that causes it to die on startup
Or make the "turned off" state block all traffic, just like closing a water valve, or a road gate. I never understood why network firewalls did not default to this.
How are you gonna get the IPv6s of your targets? Can’t scan a /64, and with ephemeral ”security” addresses used for outbound conns, an adversary won’t be able to guess the address anyway. At least that’s my understanding. So I guess my question is: is this a real threat?
Only if you trust your ISP:
https://www.anvilsecure.com/blog/dhcp-games-with-smart-route...
This reminds me of a company where the admin used public routable IPs for the internal subnet. The gap is always the human in the loop.
There's nothing wrong with this, and it's common at universities that have large IPv4 allocations.
The subnet that he used internally was "officially" used and owned by oracle and our printers regularly send traffic falsely to Silicon Valley.
This was the norm for most of the 90's and earlier. NAT was supposed to be the exception, but it became the rule. Now we have an entire generation that doesn't understand that the Internet was always supposed to support end-to-end connectivity.
Plus too many of that generation see NAT as a "security feature" not an "IP bug" and can't seem to (re-)imagine traditional firewall/router design from the time before NAT. "end-to-end connectivity" is not the same thing as "open and unsecured connectivity", we have the security tools to deal with that and they are not and have never been named "NAT".
To say NAT has nothing to do with "security" is a lie. The most common NAT (PAT) configurations are basically acting as stateful firewalls with a default deny policy for all unsolicited inbound traffic to a private, non-routeable network.
They aren't doing that though. The most common NAT (PAT) configurations don't deny unsolicited inbound traffic.
They are of course commonly deployed together with a firewall that does deny that traffic, but claiming that NAT blocks connections because it's usually deployed together with a different technology that handles all of the blocking would also be lying.
> The most common NAT (PAT) configurations don't deny unsolicited inbound traffic
That doesn’t make sense.
If I have a single routable IPv4 addresses and 100 machines behind it with RFC1918 addresses, how can any possible router “allow by default” say, port 22? Which machine would it route it to? Would it pick the first one? Randomly select one?
Of course NAT has to drop incoming unsolicited packets. Unless you tell it which machine to route them too, it couldn’t possibly know how to “allow” them in the first place.
IP packets have a "destination IP" header field that specifies where the packet goes. The router reads that to figure out where to send the packet.
The only thing NAT does is rewrite the dst or src headers of packets. If there's no rule or state entry that applies to a packet, it doesn't drop the packet. It just leaves the original headers on it.
How would a packet with a destination IP of my internal RFC1918 address have landed on my WAN interface in the first place? It would require my ISP to have a routing rule that sends it to my router. Is that the threat model you’re thinking about?
He's assuming your non-routeable RFC1918 addresses are actually routed from the Internet, which won't be happening in the normal consumer use case.
Even if there's no blocking, using internal RFC-1918 addresses still adds a layer of security since they are not reachable globally.
> basically acting as stateful firewalls
Stateful Firewalls are the security tool. NATs being mediocre to somewhat alright stateful firewalls "out-of-the-box" before adding a real Firewall is the accident (and sometimes bug). Something doing security by accident (or as a bug) isn't a security tool (just like security through obscurity isn't a security tool). You can have Stateful Firewalls without NAT. Everyone saying that you "need" NAT to have Stateful Firewalls doesn't understand Firewalls or even possibly why "firewall" is and has always been a different word from "NAT". NAT has something to do with security, but that's being generally always paired with a good firewall, not being a mediocre firewall mostly by accident.
It's still basically another mac address or unique identifier for the system, regardless of which local network it happens to be on. Great for being tracked by FAANG, I guess, but I'd rather for my devices use a generic local IP and a randomized mac. There's no reason why the refrigerator needs to be uniquely identifiable on the Internet.
No, v6 addresses are assigned by (or chosen based on) the current network, not permanently associated with a given system. They aren't MAC addresses or unique identifiers.
I wouldn’t want to relay on random caffee’s router to do this for me. I would still end up running firewall more carefully on my end devices. Which for my iPhone I’m not even sure if I can. So probably a personal VPN would be a must.
Sure... But wouldn't you want to treat this random network as hostile anyway? The router might already have port forwarding to the IP you grab from DHCP, not to mention other clients on the network. I'm also unsure how a VPN would help against inbound traffic regardless?
> I wouldn’t want to relay on random caffee’s router to do this for me. I would still end up running firewall more carefully on my end devices.
Are you not doing that already? If you trust whoever else happens to be on the same wifi in the cafe you're a braver man than I.
Does a VPN prevent inbound traffic on other IPs? If I put my laptop on a VPN, I can still SSH to it on its RFC 1918 address.
It depends on the VPN and its policies. Some deny all local traffic when active, routing everything through the VPN, and only leave a IPv4 /32 route for the default gateway. Some are more permissive.
A VPN can’t prevent inbound traffic but if the VPN alters the routing table it can prevent the return leg from working. This probably isn’t enough to prevent compromise.
> Having globally allocated address space doesn’t actually imply openness of connectability
Of course not, that's not my point. My point is that because of the fact that your home router still firewalls with both IPv6 and IPv4, any software which relies on being able to "just" connect to a peer over the internet, is doomed. Our networks don't work that way any more (they probably did in the early 90's though.)
My point is that even if we had global routability, we still wouldn't have open connectability, because open connectability is a stupid idea. Which means any software ideas people might have that rely on connectability, are already a non-starter. So why do we need open routability in the first place? (Honest question. This is the crux of the issue. Yes, open routability means you can have a host listen on the open internet, but fewer than 1% of people know how to configure their home firewalls to do this, so it's effectively not possible to rely on this being something your users can do.)
> My point is that because of the fact that your home router still firewalls with both IPv6 and IPv4, any software which relies on being able to "just" connect to a peer over the internet, is doomed.
With IPv6 the only thing you need is PCP (or equivalent).
With IPv4 you need PCP/whatever plus a whole bunch of STUN/TURN/ICE infrastructure.
Just hole punching is a lot easier to support than more-than-just hole punching.
If you have PCP (NAT-PMP or whatever), why would you need STUN or TURN? (You still might like ICE, but ICE also makes sense to have on IPV6.)
Yeah, I've had to make this point several times. Getting rid of the NAT doesn't rid you of the need for NAT hole-punching and whatnot, since any sort of firewall will need a hole-punching scheme to allow incoming connections.
I'd say the biggest practical objection (not just "NAT is ugly" or "DHCP is ugly" or "NAT is evil since it delayed IPv6") is CGNAT, which really does put a lot of restrictions on end-users that they can't circumvent. The more active hosts stuffed behind a single NAT, the more they have to compete for connections.
> but fewer than 1% of people know how to configure their home firewalls to do this, so it's effectively not possible to rely on this being something your users can do.
And a chunk of that 1% are on WANs that they aren't authorized to configure even if they wanted to.
Devices behind a firewall being routable with IPv6 doesn't mean you're allowed to connect to them by default. And if you want to, you have to explicitly allow that on the firewall. Just like you would open a port and redirect it with IPv4 before. Only with IPv6 you don't have NAT and a redirect. Some people need it and some don't. Again, just like with opening ports.
Please reread my comment, it seems like you're just pattern-matching to arguments you've heard others make in the past and assuming I'me saying the same thing. I'm not. See sibling comments for elaboration.
How many users know how to "open a port"? UPnP exists because people don't want to deal with these things.
What's your point?
It's exactly the same in IPv4 and IPv6 just like FeistySkink was suggesting.>The really sad thing about IPv6 is that it's a relic of a bygone era. The internet was envisioned as a thing where every device on every network could, in principle, initiate a connection to any other device on any other network. But then we started running out of addresses, ISP's wouldn't give you more than one for a household, so we started doing NAT, and that kind of sealed the internet's fate.
I thought the problem was lack of upload bandwidth for almost all households without fiber to the home. Surely, if people had symmetric broadband internet at home, then there would have been commercial solutions to allow devices to connect to each other, thereby decreasing the need for giant cloud providers.
This seems like it's conflating problems?
"All devices are routeable" is a good idea, because it means when we want devices to be routeable there's a simple and obvious way that should be done.
Where we've ended up with NAT though is worse though: we still need a lot of devices to routeable, and so we enable all sorts of workarounds and non-obvious ways to make it happen, giving both an unreasonable illusion of security and making network configuration sufficiently unintuitive we're increasing the risk of failures.
Something like UPnP for example - shouldn't exist (and in fact I have it turned off these days because UDP hole-punching works just fine, but all of this is insane).
NAT is not an illusion of security, it's very practical security.
Just look at the distribution of successful attacks in 2000 and in 2025.
Yes, because NAT was the only notable change in home computing between 2000 and 2025. Totally not all the other changes that happened, 100% NAT. Yep.
> "The really sad thing about IPv6 is that it's a relic of a bygone era."
Yes, and not only for the NAT reason you say; see "The world in which IPv6 was a good deisgn" by Apenwarr, from 2017: https://apenwarr.ca/log/20170810
Your comment comes grom a place If ignorance.
> We don't _want_ end-to-end connectivity.
YOU dont want that.
The wish to not have all devices connected to the Internet does not defeat the need of having a protocol that allows that. NAT is merely a workaround that introduced a lot of technical debt because we don't have enought IPv4 addresses. And having IPv6 does not mean that you must connect everything to the internet.
IPv6 Is good and absolutely necessary. NAT is really expensive and creates a lot of problems in large networks. Having the possibility to just hand out routsble addresses solves a lot of problems.
I'm starting to notice a pattern in these threads in HN every time IPv6 comes up. It's kinda like the vim/emacs holy war back in the day. I also see it in threads about Rust vs C++.
There's a kind of holy war, where people pick sides, and if you're "team IPv6", you look for any post that kinda vaguely smells like it defends IPv4, call them ignorant, and respond with the typical slew of reasons why IPv6 is better, NAT is a hack, you can still firewall with IPv6, etc. If you're "team IPv4" you look for the IPv6 posts and talk about how NAT is useful, IPv6 should have been less complicated, etc etc.
It's really tiresome.
Personally, I'm not on either "team". These things I believe:
- We need more addresses
- IPv6 is as good a solution as any, as no solution was going to be backwards compatible.
- We should get on with it and migrate to IPv6 as soon as possible. What's the hold up? I'm sick of running dual stack.
- But don't throw away NAT, please. I want my internal addresses to be stable and if possible, static and memorizable (An fd00::1 ULA [0] is even easier to remember than 192.168.1.1! And it won't change when my ISP suddenly hands me a new prefix.)
- But CGNAT is The Devil. Don't conflate my desire for using NAT at my house for some desire to be behind CGNAT. Again, we should get on IPv6 ASAP to banish CGNAT back to hell.
- Oh and don't pretend that IPv6 would have led to a more decentralized internet. A client/server model is inevitable for so many reasons, and true peer-to-peer where customers just communicate directly with one another is not a realistic goal, even with IPv6. Even with PMP/PCP. Even with DDNS. You just can't design software around the idea that "everyone's router is perfectly configured."
[0] No, I don't actually use fd00::/64 as my ULA prefix, I actually put my cellphone number in there :-P. The point being it's as memorizable as you want it to be.
>We need more addresses
True.
>IPv6 is as good a solution as any...
There aren't any other practical solutions. Debatable if it was the best solution but it is what it is.
>We should get on with it and migrate to IPv6 as soon as possible
Most LANs will run IPv4 forever. IPv6 offers nothing to LANs larger than home labs (when SLAAC is not enough) but smaller than huge companies (when there are more than enough addresses even in IPv4. 240/4 is for every practical purpose private). The community's hostility to NAT/NPT means LAN admins will get it de facto by running another stack internally.
>I want my internal addresses to be stable and if possible, static and memorizable.
Right. But ULAs have ridiculous routing rules. It would take at least a decade for fixes to be deployed everywhere.
>Don't conflate my desire for using NAT at my house for some desire to be behind CGNAT.
Right. But most users don't care.
> A client/server model is inevitable for so many reasons.
Right.
> Right. But ULAs have ridiculous routing rules
Could you elaborate? I’m able to run ULA-only just fine, with one line in my pf.conf to route 1:1 to my GUA prefix. The NAT is stateless.
Maybe you’re referring to the fact that typical OS’s will prefer to use IPv4 over a ULA if both are available? I’ve noticed that, and indeed it’s unfortunate.
>typical OS’s will prefer to use IPv4 over a ULA if both are available?
Yep. There's an RFC for this. I guess it would take a decade to be everywhere.
The Global > Local rule is also unfortunate in some configurations*, but that's more of a result of the end-to-end idea and software not realizing a device can have more than one address...
* One example from this thread: https://news.ycombinator.com/item?id=43070290
Is the alternative reality One where all devices can connect to all other devices and come with built-in mitigations for the problems that firewalls are normally used for?
Maybe. In the alternate reality, we probably would have the same threats on the internet as we do today, and the same boneheaded software that misconfigures things, so my guess is that we’d still have consumer firewalls at the gateway that just default-deny everything. Maybe there would be better standards about auto-configuring these firewalls though. (Or maybe the standards we already have would have just been better supported?)
But for certain, today if we had IPv6 everywhere, it still wouldn’t let you design something like a VoIP phone (or a pure peer-to-peer version of FaceTime) that just listened for connections and let other people “call” you by connecting to your device. That software would only be usable by people who know how to configure their router, and that doesn’t make for very good market penetration. You still need something like UPnP, so you’re basically right back to where we are today. At least the connection tracking would be stateless, I guess?
> You still need something like UPnP
I have two SIP phones both wanting to register port 5061 to forward to their address. How does this work with IPv4/UPnP?
I’m not talking about SIP, I’m talking about a hypothetical piece of software that an IPv6 proponent may typically claim that is made possible by unique GUA’s for each device. My point is that the GUA alone isn’t enough to make this work, you still need:
- UPnP or something like it - A place to register your address, since they change all the time even in IPv6
And if you need these two things anyway, you can do this with IPv4, with the added change that you also include the port when registering your address, which makes the “multiple phones in a network” thing work.
> I’m talking about a hypothetical piece of software that an IPv6 proponent may typically claim that is made possible by unique GUA’s for each device.
Like, say, a SIP client? Wanting to listen on the standard SIP port?
Or say two web servers that both want to listen on :443 and you don't want to have to reverse proxy them from another box.
> UPnP or something like it
> https://datatracker.ietf.org/doc/html/rfc6887
Port Control Protocol seems to be pretty well supported on most of the devices I own even in IPv6.
And in the end I'm pretty boned if I'm on CGNAT usually. I can pretty much never get my Switch to do matchmaking with peers on IPv4 when I'm on a CGNAT network. If we were all on IPv6, it wouldn't be a problem.
> Like, say, a SIP client?
No, not like, say, a SIP client.
You seem pretty intent on not reading my whole comments or something. Mind responding to what I’m saying and not just making up your own arguments?
I’m saying “ipv6 alone won’t solve X”, and you’re saying “but what about Y?”
I'm saying "but what about Y" and you're acting like Y is never a valid issue that anyone ever seems to have.
So once again, how do two devices both share port 5061 on a UPnP NAT with a single public IP address? Or even worse, if they're CGNAT'd? It's a simple answer with IPv6...
Again with the not reading. Let me try to sum up my position so we can end this whole “nuh uh!” nonsense.
IPv6 was designed in a world where we thought we’d have a truly peer-to-peer internet where anyone could just talk to someone else’s device. This obviously isn’t what happened. An ipv6 proponent may say “this is because NAT breaks the necessary assumptions”, but that’s extremely oversimplified and wrong.
The reason that, when I use my iPhone to FaceTime my mom’s iPhone, it doesn’t just use SIP to contact her phone, isn’t because IPv4 and NAT. It’s because the very idea of that is nearly impossible to implement at scale even if everyone had a unique address.
I’m aware you can’t have multiple devices behind a NAT address listen on the same port. Thank you for pointing that out, you’re very smart. But it really doesn’t address my point at all, does it?
My point being that the reason we don’t use SIP and related technologies for billions of end user devices today, isn’t because of NAT. It’s because the myriad of other problems that would need to be solved for it to work reliably, and because of NAT. Eliminating NAT wouldn’t really meaningfully change the landscape of how software works. FaceTime calls would still go through Apple servers. People would still use centralized services run in real data centers, etc.
> I’m aware you can’t have multiple devices behind a NAT address listen on the same port. Thank you for pointing that out, you’re very smart.
Ah, finally, you do acknowledge that there are issues that aren't actually solved with IPv4 and NAT. Thanks.
> But it really doesn’t address my point at all, does it?
Lets go back to the first thing I was reponding to.
> it still wouldn’t let you design something like a VoIP phone (or a pure peer-to-peer version of FaceTime) that just listened for connections and let other people “call” you by connecting to your device.
With having a public IP address, PMP enabled on my router, and DNS registration I have this today. My SIP phone here is sitting by, waiting for incoming calls. I don't need Apple's servers for this. Anyone with a SIP client and who knows the name can get to it (or trawls IPv6 space). This becomes a headache with IPv4 with multiple devices all wanting that 5061 port. Sure, one could just also tell people the port and have lots of random ports assigned, but that's just yet another bit of information to get lost, one more mapping to maintain, etc. Imagine if Amazon ran their ecommerce site off a random high number port instead of :443, think they'd get as much traffic?
> With having a public IP address, PMP enabled on my router, and DNS registration I have this today.
That’s cool for you, congratulations.
I’m talking about the broader internet at large, and the billions of users on it, and the software that is written for these billions of users. This software does not behave the way your cool phone does. Because people’s IP’s change. They’re behind firewalls they are unable or don’t understand how to configure. We don’t write software this way for a lot of good reasons.
Now, I keep talking about this, then you bring up “but I have this use case, what about that?” Demanding an answer as if I give a shit that you want to run a SIP phone at your house, and you’re willing to configure your firewall, etc.
My whole point (!!!) is that what you’re doing is not what the billions of people using the internet are doing. When I bought my mom an iPhone, I didn’t have to tell her “ok so, FaceTime only works at your house, you have to reconfigure this DDNS service when your IP changes, you have to configure your router this way, and don’t ever leave the WiFi network or it won’t work, but thank god for ipv6, because it means dad can do all this too for his phone!” No. Because FaceTime doesn’t work that way, nor could it ever, because doing true peer to peer calling was never a thing that would have ever worked at scale. It’s not being held back by NAT. It’s being held back because it was never gonna work in the first place.*
> and you’re willing to configure your firewall
I didn't have to configure the firewall, that happened automatically with PMP. That thing you didn't even know existed until a few hours ago.
But somehow you know all that is and is not possible. All that could have been if things were different.
Sick burn bro
I mean if you’re just going to sling ad-hominems around and invent your own argument so you have a chance at winning it, sure. I’m not aware of the specific RFC’s du jour that are used for auto-configuring routers. But after spending some time looking it up, it seems relatively niche (not as widespread as UPnP), and it appears the last 3 routers I’ve owned don’t support it. (I run an openbsd box with pf currently, but my unifi gateway before that didn’t support it, and the shitbox gateway Comcast gave me before that certainly didn’t support it. I could run a service on my openbsd box to support it but it wouldn’t make a difference because I’m perfectly capable of editing my pf.conf as it is.)
But if you’re gonna dig up other posts of mine to try and get a dig in at me, maybe at least read the rest of the post? You certainly haven’t done a good job of that so far.
Because I indicated that of course a protocol like this ought to exist, but what percentage of users of the broader internet are actually running a router that supports this? If you wanted to come out with a video calling app that only worked if your users had PMP working, what market share would you be losing out on? That’s the topic of discussion here after all (not that that’ll stop you from inventing your own discussion as you’ve continued to do.)
> I’m not aware of the specific RFC’s du jour
Funny way to say you don't know what you're talking about. If you don't know what technologies are actually out there how can you say what is and is not possible?
> but what percentage of users of the broader internet are actually running a router that supports this?
Most who aren't running their own home rolled pf setup that can't be bothered to read about "the latest" (over a decade old) RFCs.
And yeah, last I ran a UniFi gateway it supported PMP. That was several years ago. If it's a recent model device with halfway decent IPv6 support it's practically a sure thing it's got PMP support. Maybe disabled, but it supports it. Same with UPnP, might be disabled, but probably supported.
I guess you really enjoy feeling superior so I’m just going to give you this one. You win. You’re very smart and you know more about router software than I do.
(I’ll leave you to ponder whether this changes my point at all, but I don’t think it really matters. You seem to be pretty fixated on getting your digs in, so maybe we’ll just end the discussion here. Good day.)
> I guess you really enjoy feeling superior
> Sick burn bro
> My post was basically the biggest pile of sarcasm I could conjure and you still took it seriously, congratulations!
> That’s cool for you, congratulations
> not that that’ll stop you from inventing your own discussion
> I don’t think I’ve met someone that truly thinks technological progress stopped in the 1990s and that URL’s and DNS are all we actually need.
And yet you accuse me of ad homenims for pointing out your acknowledgement of not knowing of the last decade+ of networking tech and that I have a need to feel superior. Pot meet kettle buddy.
You've spent so much effort telling me what's possible or not, berating me multiple times, while acknowledging you haven't kept up with decade+ old tech.
The two devices shouldn't both need to be on the one port 5061: we have numerous solutions to that problem at this point, from specifying the port as part of the connection to auto-detecting it using SRV in DNS. Yes: making some small changes to existing software to not assume hardcoded ports is required in this future... but there is no way that those changes would have been (or frankly even still are) harder than the insane solution of reimplementing and redesigning the entire world--requiring its own changes to every protocol (including SIP) and breaking a strict and extremely large superset of the same references that merely needed a port number--to support IPv6.
Why would they need the same port?
Because they don't want to have to rely on an external service to find the right port. Just like how your browser doesn't need to be told to connect to :443 for HTTPS. If you're connecting encrypted SIP, the port is assumed to be 5061. Just like HTTP is assumed to be 80, SSH is 22, etc.
In what world do you not need to rely on an external service to find information like this? IP addresses change, people move around, etc etc.
The topic of discussion right now is peer-to-peer software, which is the quintessential thing that is always lauded by ipv6 proponents as the killer app of ipv6, because each device has its own globally-routable IP.
But “what address do I send these packets to?” is like, 10% of the issue with designing p2p software. Users ip’s are always changing. They move around. They go behind firewalls that will block their traffic. They go behind firewalls they don’t have permission to reconfigure. This is the case in IPv4, and it will always continue to be the case even if we were 100% IPv6.
IPv4 can work today for p2p use cases if you don’t make the assumption that the port is static. But that’s like 1 of N assumptions you have to check if you’re writing peer to peer software. The other N of them are all still issues, even in IPv6.
> But “what address do I send these packets to?” is like, 10% of the issue with designing p2p software
So wouldn't it be nice to go ahead and solve that 10% of the problem instead of just limping along with it?
I hope you're not implying that IPv6 solves the problem of knowing what address to connect to.
If you can avoid an explicit port, that can be nice. But anywhere you're using an IP, v6 without a port is longer than v4 with a port. An implicit port is only useful when you're using DNS. (And if you're designing a service, you can choose to use DNS records that contain the port.)
I'm all for things to start using SRV records as well!
But the external service needs to know your ip, so why not port as well?
We have this thing called NATMap: https://github.com/heiher/natmap
It gives you a public dynamic IP + port combination if your network is NAT1 all the way to the internet. Both IP & port being dynamic kinda complicates things, they ended up inventing a new DNS record type, "IP4P" where IPv4 address and port are encoded as an IPv6 address, and modified WireGuard/OpenVPN clients are required.
We are supposed to solve this using SRV records, but I don't think many consumer-facing apps can do this.
Did you have to look up something to know this site is hosted on :443 or did you just make an assumption? Some kind of standardized port you connected on? Wouldn't it be nice if every device could just assume the standardized ports were available for them if they wanted them?
VOIP systems don't really work like random webservers though.
There's little reason why they couldn't though. Why shouldn't I just call Apple by doing sip://support.apple.com ? Why can't people just call me at sip://desk-phone.vel0city.whatever (they actually can, if they know the right name) or sip://cell.hikikomori.apple.net ?
Instead, we're locked into proprietary platforms or relying on old phone systems.
Ok so try calling my phone at sip://ninkendo.example. Oh, I’m actually not at my house. I’m traveling and my device is moving from one cell tower to the next, getting a new IP address every few minutes. Then I get to my friends house and his router is gonna block unestablished connections so you better call me soon.
No, there’s a reason software like FaceTime, and calling in general, are mediated by centralized services and implemented as client-server. Because relying on your users to have stable IP’s, and to always be behind a properly configured firewall, would be an utterly insane way to design something.
Hence “ipv6 is a relic of a bygone era”, because in the era we live in now, IP addresses change and users move between networks constantly, and NAT is very much the least of our problems.
FWIW IPv6 can handle this scenario just fine, by letting you take your home IP with you when you move to other networks. I don't think "v6 is a relic of a bygone era" is fair to say when it has a way to handle this exact problem.
How does ipv6 let me take my IP with me, exactly? Citation needed. I mean, I have WireGuard installed on my phone and I get a tunnel my house wherever I go, but that’s not really the same thing, is it? You’re saying there’s a way for me, wherever I go, my house, 5G, my friends house, to just have traffic routed to my phone for a consistent IP address wherever I go? Not a VPN? Through something only IPv6 provides? Could you explain what this is? Because my ISP at home won’t even give me a consistent IP, not even a stable prefix.
It kind of exists in IPv4, but is a lot messier. Also, the lack of IPv4 addresses makes this a lot harder to do something like this in IPv4.
https://datatracker.ietf.org/doc/html/rfc6275
> my device is moving from one cell tower to the next, getting a new IP address every few minutes
You're pretty much never getting a new IP at every cell tower.
> Then I get to my friends house and his router is gonna block unestablished connections so you better call me soon.
PMP can solve that.
> Because relying on your users to have stable IP’s
Not a stable IP, but some kind of stable identity. Like a DNS name. That can be provided by someone like Apple, or Google, or whoever. It doesn't need to be ultra-centralized by only a single thing controlling it.
[flagged]
> I don’t think I’ve met someone that truly thinks technological progress stopped in the 1990s and that URL’s and DNS are all we actually need
I never said this. You're putting some rather strong words in my mouth. Just giving an example of something that could have been if it wasn't for NAT and an acceptance that you need a third party platform to allow you talk. Feel free to change out the pieces to whatever.
Personally I'd like to be able to just dial a FaceTime-like client from any device instead of just what Apple blesses with accounts Apple allows. And have that stack just be the norm. I understand NAT isn't the only headache that prevents this, but it is one of the several that does.
I don't think it's crazy to think easy dynamic DNS services could have become common if advertised right. People don't know how phone numbers work but in the end they know how to use them. The tech for routers to auto configure firewall rules based on client requests exists, and potentially if everyone-has-a-public-ip was common we'd have seen less reliance on brittle edge firewalls and NAT to provide so much of our security.
Killing NAT doesn't solve all the problems, but it does solve some of them. And I'd prefer solving the ones that help give users more freedom instead of accepting things like CGNAT.
This is a misconception holding back the adoption of IPv6.
Routers have a stateful firewall meaning by default they only allow incoming packets that belong to a connection that was initiated from the inside. By default you also have this kind of firewall on every operating system. NAT adds 0 additional security.
NAT was invented to connect entire businesses to the internet that would otherwise have to manually reconfigure every single device for the internet. Keeping IPv4 going amidst address exhaustion going was a lucky coincidence of it.
I don't want all my devices to have their own unique address. The internet dream that created ipv6 is dead. It's malware, spyware, surveillance capitalism now, and the more obscurity through layers of addresses, the better.
Oh god, no, no, no. It's so frustrating to hear this over and over again. NAT is not a firewall. A firewall is a firewall and any reasonably component network admin uses one (and likewise any reasonably competent ISP supplies equipment with one to users who don't know any better). A little knowledge is a dangerous thing...
Can you pick a specific thing in my post to argue against? I never claimed NAT and firewalls are the same thing. I claimed that whether you’re using IPv4 with NAT, or IPv6 with a default-deny firewall, you can’t have software just “assume” that it can listen to incoming connections and have things just work. You need to go to your router and configure something. Since approximately 0% of people in the world at large know how to do this, it means software can’t work this way in general, and IPv6 doesn’t change this.
Ok, but things "just working" isn't the only advantage of v6. Are you aware some people don't even get v4 address at all? Have you ever been unfortunate enough to have your LAN v4 range overlap with a network you VPN to (like a corporate network)? What if you want to run two web servers?
A lot of people seem to think I’m anti-ipv6… I’m not, actually. I run it at home, I evangelize for it, I think it’s the future and the sooner we move to it, the better. It solves real problems, the shortage of addresses being the most obvious.
What I’m against is the oversimplification that if we only had ipv6 from the start, that the internet would have turned out very different and we’d be directly connecting to each other through direct unsolicited connections or something.
No, there are a lot of reasons direct unsolicited peer to peer communication are not a good expectation to have on the modern internet. NAT makes it tough, yes, but so does security (you’re gonna want to firewall your network at the gateway anyway, even in v6), changing addresses, mobility, etc.
For instance, even in my network at home, I don’t think using my real GUA prefix on each device is a great idea. Because the prefix changes, I have to use ULA for any static configs (dns, etc), which means the GUA address is this extra address I don’t use, and it only complicates things. So I’m moving toward ULA-only with NAT66, which I think is a more sane choice. I get the benefits of lots of addresses, which is great, but instead of my firewall simply allowing traffic to my public stuff, I just NAT a public IP to each public thing I want.
Maybe I'm blind, but I haven't seen anywhere else in the thread where "we'd be directly connecting unsolicited" is mentioned apart from where you've prompted it.
I don't think any reasonable engineer expects that that end would ever be the case, even if it was one of the stated original "dreams" of IPv6.
> I don't think any reasonable engineer expects that that end would ever be the case, even if it was one of the stated original "dreams" of IPv6.
Then imagine my frustration when that'e the exact argument people are giving: https://news.ycombinator.com/item?id=43072844
Like, I come up with these scenarios as a strawman to illustrate that direct client-to-client connections aren't going to work, and people come and say "actually it totally could work! We have PCP, and DDNS! Cell towers have mobile IP's too so you're only going to change IP addresses 3 times on your drive to your friend's house! And his router will also support PCP so it could have totally worked this way!"
I literally came up with the example to sound as crazy as possible, and people still say "Yup, that's exactly how things could have worked if we had IPv6. Now look at how stupid ninkendo is for not knowing about PCP, the moron~"
Like imagine if steve jobs came on stage in 2011 to introduce FaceTime, and said "You can make video calls to other people on iPhones, it's great! But you have to know their IP address. Or subscribe to a DDNS service. Make sure to use really low TTL's on your DNS records in case you roam to a different network. Oh and you have to have a router which supports PCP. Every router you connect to must support it." Even in a world where IPv6 was everywhere, that would be insane. (Well, other commenters seem to think that's exactly how phones ought to work? Maybe I'm the crazy one?)
How would you design a NAT-based LAN that shares nothing in common with a firewall?
1 to 1 NAT isn't doing any firewalling. Source NAT isn't doing any firewalling. Static NAT isn't doing any firewalling. All of these will generally just send traffic along if there's no other firewall rule associated.
When most people say "NAT", in the home user / consumer sense, they really mean "PAT": ports mapping to multiple private IPs using a single public IP.
"PAT" is not doing any firewalling either.
(It does rely on state tracking, which it shares in common with stateful firewalls, but you could run a LAN with either a stateless firewall or no firewall if you really wanted to meet the "nothing in common with a firewall" requirement.)
> Note: no, we could not have done it any other way. Any upgrade strategy to IPv4 that extended the address size would have necessitated having two internets
No, this isn't right. Instead of having IPv6 we ended up extending IPv4 by using port numbers as extra address bits and using NAT. This transition was painless (for the most part), and didn't require building a second internet.
In a better and saner world we could have got roughly the same thing - except conceptually simpler and standard - instead of IPv6.
I think I’d mostly agree with you if only one layer of NAT is in play, but in reality we have CGNAT and it makes it supremely difficult to host services without a very cooperative ISP (laughable.) And there are more internet subscribers in the world than there are IP’s for them, so CGNAT is required for at least some unfortunate part of the population.
In reality we just really do need more IP’s. 32-bit addresses with 16 bits of ports isn’t enough.
> makes it supremely difficult to host services without a very cooperative ISP
Sadly, that's a feature, not a bug.
Two layers of NAT sucks, but I guess it could have been avoided if a designed (instead of ad-hoc) solution to the problem was devised.
> And there are more internet subscribers in the world than there are IP’s for them
Is this really true, did somebody actually run the business math? "Internet subscriber" roughly corresponds to "household", not to "person".
When you say IPv6 isn't hard, do you mean implementing v6-only network stack isn't hard or understanding IPv6 isn't hard? Depending on which layer one lives on, I feel like the lack of networking effect makes supporting v6 difficult. Github is still isn't on v6 and some load balancers will prefer the v4 address over v6, etc...
Understanding it isn’t hard.
Obviously you can use (just) IPv6, e.g. GitHub.
Good news: it's 20 years, not 100, at the most :-)
https://labs.apnic.net/index.php/2024/10/19/the-ipv6-transit...
You can't just assume linear growth. Your link acknowledges this, and the "prediction" you refer to has the right caveat: "we can look at the time series shown in Figure 1 and ask the question: 'If the growth trend of IPv6 adoption continues at its current rate, how long will it take for every device to be IPv6 capable?'". It's using such a naïve model to illustrate that we're still nowhere close to completing the transition, not to say that we'll be done in 20 years at most as you suggest.
Adoption will slow down and my guess is that we'll be stuck with a long tail forever, and only time will tell if that happens at 50% adoption or 90% adoption.
> Adoption will slow down and my guess is that we'll be stuck with a long tail forever, and only time will tell if that happens at 50% adoption or 90% adoption.
But that long tail will probably look like figure 4 of that link, only reversed: IPv4 running mostly as tunnels over a core IPv6 network. Some large cellphone networks are already at that stage, using things like 464XLAT to run IPv4 with NAT over an IPv6 network.
I'm not talking about a long tail of systems and networks which still have working IPv4 support. I'm talking about a long tail of systems and networks which still don't have working IPv6 support.
I would agree with you were it not for the fact that I'm personally investing my time into a FLOSS project to make sure the growth does not slow down by making “tomorrow NOT like today”, but gets a kick in the butt once we reach the 50% deployment inflection point instead. Stay tuned ;-)
Whatever you're cooking up, I wish you luck! My life would be significantly easier if I could just completely ignore one network protocol, be that v4 or v6. So far I have mostly just ignored v6 and everything I do uses v4, but I have no strong preference (except that v4 addresses fit in my brain while v6 addresses do not, which is honestly a not-insignificant reason why v6 is hard)
Here's to hoping, but I agree one way or another one stack needs to go :-)
BTW: Contact info is in my profile if anyone wants the inside scoop. The project just isn't fully ready for public launch yet, but we're well into the cooking.
> and the "dream" of IPv6 will become a reality
Depending on what that dream is, it may already be a reality in the upper layers (webrtc, websockets, quic/http3, etc). This is why not many really bother if IPv4 will go away?
ISPs aren't helping either. Ziply Fiber only provides IPv6 with their 10 Gig and up plans, starting at $300/month.
there could have been allocated a prefix to ipv6 that would contain the entire ipv4 space, and then all ISPs could have simply translated between at the edge, which would have made it possible for all normal consumer/company devices to only carry an ipv6 stack
There is such a prefix, though, but the problem is the end user devices themselves (or a few applications) are not always modern enough to have decent operation with a IPv6 stack. Less so these days, though. See https://en.wikipedia.org/wiki/IPv6_transition_mechanism, ::ffff:0:0:0/96.
That said, a lot of posts here don't seem to reckon with the fact that a slim majority of www.google.com connections in the United States are via IPv6, and a super-majority from India, Germany, and France. Comcast, T-Mobile, Verizon, as far as I have experienced, these all default to IPv6. While dropping IPv4 support is both a worthy, distant goal and sometimes used in goal-post moving rhetoric, it's not like nobody uses IPv6...rather, mobile broadband networks have depended on it for over a decade (see T-Mobile's deployment of 464XLAT)
"Simply" is doing a lot of heavy lifting there.
There are multiple v6 prefixes already allocated for containing the v4 space. It would help if all ISPs ran NAT64 routers on the standard NAT64 prefix, but e.g. how would that function with software that only works with v4 addresses?
OS would translate the ipv4 address to ipv6 before it leaves the machine. Very rare that software writes its own packet to the network card.
On an ipv6 only device if I type "ping 1.1.1.1", I would expect that to be translated by the OS (not the program) to 64:ff9b::1.1.1.1, rather than relying on DNS64 to do it.
Then at some point upstream it would go via a nat64 gateway to reach that legacy IP.
This should have been in OS stacks 20 years ago.
You’re describing 464XLAT, it’s how T-Mobile internet works. iOS, macOS and windows all support what you describe out of the box (although last I checked, Windows inexplicably only does this if the interface is a mobile/5G interface. They may have fixed this.)
You can try this on a vanilla macOS install if the router advertisement hints at a NAT64 prefix (RFC8781) and you either don’t run DHCP4, or your DHCP4 server lists the IPv6-preferred option (RFC8925). I think they’ve also added a check to query a well-known ipv4-only hostname on DNS, and if it gets a AAAA back and the connection works, it knows it must be behind a working nat64 setup, which obviates the need for the router advertisement to have the PREF64 option.
I tried this a year ago and it worked great, macOS skips DHCPv4 and gives itself a single 192.0.0.1/32 address so that legacy apps can “see” an IPv4 interface, and any packets sent from it are translated to IPv6 and sent to the nat64 prefix. So “ping 1.1.1.1” works fine. I stopped using this though, because I have a garage door opener (ratGDO) that only works with ipv4, and my nat64 prefix can’t “hair-pin” the packet back to the LAN address… it basically only works if everything on your LAN is IPv6, which my garage door is not.
I think android supports this as well, but I’m not sure about vanilla Linux, I think you need to install a clat daemon to do the translation.
It did take way too long for this to work though, as you point out.
> It did take way too long for this to work though, as you point out.
That's the point. It should have been in from the start, making it normal way to do anything.
> I think android supports this as well, but I’m not sure about vanilla Linux, I think you need to install a clat daemon to do the translation.
So still not the norm. Will take another 20 years to get rid of equipment being installed now which rely on an ipv4 network.
it wouldnt, that software would update or get left behind, too bad.
Then you're back at having "two internets" again. (Well, I don't agree that it's two Internets, but you'd be stuck with the same situation we have already because people would continue to use v4 in order for that software to continue to work.)
One major annoyance of IPv6 is that it lacks support for IPv4's whole 127.0.0.1/8 range.
What are the use cases for it beyond the regular .1 address that you dont get from ::1?
It's very useful for cooperatively pretending that a single machine is actually a network of machines, without all the madness of network namespaces.
Basically every server program ever supports the notion of "which IP address am I supposed to bind to?" Normally the answer is either "localhost" or "whatever my LAN or WAN address is, for a particular interface". And specifying this (both for servers and for clients) is much less effort than replacing all the standard-ish ports with ad-hoc ones.
I love this feature so much when jumping back and forth between two projects that when devving expect exclusive control of postgres. All I have to do is set the bind address for one .1 and the other .2 and all is good.
You can literally do the same thing with IPv6.
Just assign multiple IPv6 to your loopback interface and everything will work as expected. You can use either private IPv6 or even link-local IPv6 range.
There’s no need to waste thousands of addresss on this use case.
Which is configuration that's requires arcane invocations and permissions I might not have.
As opposed to IPv4, where everything Just Works™.
I wish that were true. MacOS for example only assigns 127.0.0.1/32. You have to assign extra IPs manually, the same way you would on IPv6.
that is a mac problem, not an ipv4 problem. The mac does a lot of pretty stupid things
As someone who used Windows and Linux my whole career and now am forced to use Mac for a new job; I completely agree, I was right, Mac is a very weird thing overall.
Same thing on FreeBSD. It's just not something you can rely on and the spec doesn't say it needs to be assigned.
Yeah, and I always do.
Because parent is right, having multiple loopback addresses is just so nice for a lot of things.
…until it doesn't, when something looks at the configured addresses. The "other" addresses in 127.0/8 will easily have weird behavior in nontrivial setups.
> waste thousands
Yeah would hate to run out
I was counting on that just a few days ago and failed spectacularly when Windows SMB client refused to connect to 127.0.0.2
I’m gonna get downvoted for this, but IPv6 has lost and they have to come up with something else with enough benefit for the user to achieve widespread adoption to beat IPv4.
IPv6 certainly hasn’t “won” in the sense that it’s nowhere near where it should have been by now, but I would definitely not say we need to make something else that also isn’t ipv4 and thus also isn’t forward compatible.
IPv6 is still the only game in town as a successor technology to IPv4, and it makes no sense to invent some other new thing.
The real question at hand, is do we keep trying to make IPv6 happen, or do we give up and just deal with IPv4 until the end of time. (It’s not an obvious answer. L7 load balancing and IP anycast makes it so you can basically run an entire tech company on a single IPv4 address. CGNAT is becoming more and more commonplace. The pressure on IPv4 availability is alleviating all the time. Maybe 4 billion addresses will ultimately be enough for humanity, who knows.)
But I mean it when I say that if we continue as is and just sorta gradually, grudgingly add IPv6 on a best-effort basis, it’ll likely be 100 years or so before we can actually turn off IPv4.
> What is hard, is dual stack networking. Dual stack networking absolutely sucks, [...]
Clearly you have gotten some unfortunate hands on experience with those edge cases. In my uses the dual-stacking of IPv4 & IPv6 has been a big benefit in that I have to worry a lot less about locking myself out of systems, as I can always reconnect and correct configuration mistakes on the second stack.
Comparing the IPv4+IPv6 dual-stack story to the one from the 90s of IPv4 with IPX/SPX (Novell Netware) and/or NetBIOS (Microsoft Windows), the current state is a lot more smooth and robust.
I've so far only run into 3 issues over the years (2013 till now). A local train operator running IPv6 on routers that didn't properly support non-default MTU sizes (fragmented packages getting dropped) and Microsoft where Github is still IPv4-only and Teams recently developed an IPv6-only failure on a single API endpoint.
Should we ever turn off IPv4 during my working life-time, I hope we have at that point introduced a successor to IPv6, so I can keep using a dual- or triple-stack solution, using different network protocols for robustness.
> we're still not even at 50% IPv6 usage
Partially due to companies like Metronet whose focus is on growing rather than doing what it should be doing.
The dual stack strategy was criticized 20+ years ago on these grounds, it seemed pretty obvious to me, and as you point out critics were right.
You can run a pure IPv6 network that can connect out to both, though. You don't need to run dual stack.
We don't live in the world in which IPv6 was a good design. Please avoid acting like IPv6 makes for a good design, because it doesn't.
See apenwarr's by now nearly a decade old blog post "The world in which IPv6 was a good design": https://apenwarr.ca/log/20170810, previous discussions of it here: https://hn.algolia.com/?query=The%20world%20in%20which%20IPv..., as well as the follow up blog post here: https://apenwarr.ca/log/20200708, previous discussions here: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
And the issues with IP (and by extension, TCP, ignoring the fundamental results from the Delta-T research at Lawrence Livermore keeps biting us all in the ass) whether IPv4 or IPv6 go even deeper, far deeper, than what that blog post already tells us, so here, have this—flawed in some minor aspects, which makes CCIEs burry their head in the sand of denial about the deeper point of it—polemic for dessert: https://web.archive.org/web/20210415054027if_/http://rina.ts...
> Please avoid acting like IPv6 makes for a good design, because it doesn't.
Where did I give that impression? I tried my hardest in that post to not make a judgement call one way or the other as to whether it was a good design, only that dual stack fucking sucks.
My followup post in fact, totally agrees with you? https://news.ycombinator.com/item?id=43070286
It's almost exactly just IPv4 with longer addresses. If IPv6 isn't a good design then IPv4 is even worse because of the address shortage.
>It's almost exactly just IPv4 with longer addresses
No it's not. Slaac and NA make it a totally different beast.
If ipv6 only had dhcp6-pd, it would have been "just like ipv4 with longer addresses".
> No it's not. Slaac and NA make it a totally different beast.
How many ways to be assigned an ipv6 address are there anyway? Two or three too many?
Why should the ISP know what devices I have behind their router?
Considering the amount of enterprise-ish thought that went into ipv6, they thought preciously little of privacy, for example.
Their router needs to know what devices are behind it so it can route to them. But if by "their router" you meant "your router"... your ISP doesn't need to know at all. They send all traffic for your prefix to your router, and your router figures it out from there. Your ISP has no idea what devices are involved.
The existence of privacy addresses suggests that some thought was put into this.
There are no more "your routers" for about 10 years. The router is given to you by the ISP, and you don't have the root password for it, you can only reboot it over an APP on your phone.
The prefix is also not delegated to that router, the router does npd proxying, and the ISP only routes the ips which have the corresponding NAs recorded into its database.
That's... not how things work in general. It would be possible for an ISP to do that, and I'm sure somebody somewhere does, but they could do the exact same thing on v4 so you don't get to blame v6 for it.
If your ISP runs the default router for your own LAN, they'll have full visibility into it on both v4 and v6. That's just how IP works.
>That's... not how things work in general.
Most ISP I have seen implement it like this. A large chunk of those "most" also require you to bind a phone number to each separate hwaddr appearing in the network via SMS. (Not all though.)
Those few that implement it differently, do the following:
They serve ULAs to the customers over slaac, and nat6 all the ULAs to a single ipv6 assigned to the router (actually a wifi hotspot).
I totally believe that where you live things are done differently, but this is exactly why ipv6 critics call it defective. It allows too large a variety in implementations.
How does IPv4 prevent shitty ISPs from existing?
I don't think I ever claimed that.
But shitty or not, you have to somehow convince them, incentivise them to deploy ipv6.
That's not how it works here. I don't even use my ISPs router. Once the tech left, I swapped it out for a pfsense box. I have a /56 delegated.
Well, they also junked useless un-scalable things like broadcast and ARP.
That's the adaptation layer between Ethernet and IP.
Broadcast was renamed to "all nodes multicast". ARP was renamed to Neighbor Discovery.
Slight improvements: ND isn't broadcast, but multicast based on several bits of the IP address. This allows NICs to filter most of the irrelevant ones based on multicast MAC address. And subnet broadcast addresses were removed. There's only local broadcast to your own subnet and not to someone else's subnet, since IPv4 routers found that to be a bad idea and mostly started blocking it anyway.
Meanwhile adding science fiction things like mobile IP.
That's a solution to a problem you don't personally have, and it exists in IPv4 too.
Your cellphone company uses it - or would like to.
It's like SCTP: just because you don't use it doesn't mean there isn't a big group of people who do.
Yeah, that one's a bit silly.
that's not what this article says. I dug through it, and the main point seems to be 'It would have been beautiful. Except for one problem: it never happened.'
there is nothing really wrong with the design of ipv6 relative to ipv4
This is a little self contradictory. Saying that it's "not that different", then going on to mention "the strategy of having two internets".
Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6, an inherent design flaw of the IPv6 protocol. Just to provide the architypical links:
This was documented about 25 years ago by DJB:
https://cr.yp.to/djbdns/ipv6mess.html
And has been repeatedly discussed on HN:
https://news.ycombinator.com/item?id=10854570
As you mention, IPv6 has exsited for the majority of the commercial internet's history, now 25 years later, it's still not the default transport protocol.
It _was_ possible to create an address space extension that was IPv4 backwards compatible, this option was just not chosen, and now we're still dealing with the dual stack mess.
> Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6, an inherent design flaw of the IPv6 protocol.
It is not a design flaw of IPv6, it is a limitation of the laws of physics: how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)?
Even if the IPng protocol could recognize IPv4 address and send out data, how can a host which only understands 32-bit addresses send back a reply back to the IPng host? If a packet with a >32b address comes in, how would a 32b-only hosts be able to handle it?
From Bernstein:
> In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses.
How would a non-updated IPv4 system know about the IPng protocol? If a non-updated router had a IPng packet arrive on an interface, how would it know how to handle the packet and routing?
All the folks criticizing IPv6 don't ever describe how this mythical system would work: how do you get 32-bit-only system to understand more-32-bits of addressing? Translation boxes? Congratulations, you've just invented 6rd BR or NAT64, making it no different that IPv6.
The primary purpose of IPng was a bigger address space, but how would that work without updating every single IPv4 device? You know, like had to be done for the eventual IPng, SIPP (aka IPv6).
* https://datatracker.ietf.org/doc/html/rfc1752
>how do you get 32-bit-only system to understand more-32-bits of addressing
Maybe you don't. I imagine it would work like this (where XXXX::<IPv4> is the transition block mapping the current Internet v4 into IPv6):
- 32 bit host could only talk to other 32-bit hosts, and other XXXX::<IPv4 Adress> hosts. We have this now, just without the XXXX::<IPv4> part.
- Hosts with v6 addresses outside of XXXX::<IPv4> could not talk to IPv4 addresses without having a 6to4 proxy. We also have this now.
- Hosts with v4 addresses could switch to IPv6, KEEPING their current v4 address by setting their IPv6 addres to XXXX::<IPv4>. They can now talk to all the hosts they used to be able to, AND they can start talking to IPv6 hosts, without having to have two IP, dual stack config, etc.
So we end up with a significant benefit of allowing people with IPv4 addresses and IPv6 connectivity to do an IPv6-only setup.
In my case, I simply don't see us transitioning to IPv6. Our main service has an IPv4-only address and we receive 0 complaints about it. We've literally never had anyone say they couldn't connect to our services because of it. Our users are geographically located in the central US, and everybody has IPv4s. Maybe they have an IPv6 as well, but if we went v6-only I can basically guarantee that we'd have users screaming at us. We'd probably have lawsuits over it. But going v4-only, not a peep.
> - 32 bit host could only talk to other 32-bit hosts, and other XXXX::<IPv4 Adress> hosts. We have this now, just without the XXXX::<IPv4> part.
Oh, you mean like IPv4-mapped Address (::ffff:0:0/96) as defined in RFC 4291 § 2.2.5, or NAT64 (64:ff9b::/96) as per RFC 6050. See also 6to4 in RFC 3056 dating back to 2001.
Your idea is not new.
Not my idea, wasn't representing it as my idea; djb proposed it long ago (as other commenters in this thread mentioned), and as you pointed out as IPv4 mapped addresses. I was just describing how it might work, since it's a little confusing. In particular when I first started thinking about it I kept getting stuck on "Ok, so how do non-v4 mapped IPs talk to v4 addresses?"
> Not my idea, wasn't representing it as my idea; djb proposed it long ago (as other commenters in this thread mentioned), and as you pointed out as IPv4 mapped addresses. I was just describing how it might work, since it's a little confusing.
Every time IPv6 comes up some number of people talk about a protocol that 'just' added more bits IPv4 and calling it a day. But when going over the details of how what would work, exactly, you end up at the same place as IPv6 (and various 'transition mechanisms').
But there is no 'just' adding more addresses: you need to update (at least) end-hosts, update DNS, have relays/proxies if the middle of your network does not support IPng, have tunnelling to/from those special translation systems. It's basically the same thing as IPv6.
Certainly you can argue about keeping ARP versus going with NDP. Or not having SLAAC—but then you need infrastructure like DHCP (which is optional with IPv6).
>how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)?
By using nat46 on ISP's routers.
>> how can you fit >32 bits of data (IPv6) into 32 bit data structures (IPv4: struct s_addr)?
> By using nat46 on ISP's routers.
I do not understand.
In Ye Olde Times a system would call gethostbyname() and this send out a DNS packet asking for the IP address. Of course DNS record returned would be an A record, which is where your first problem is: A records are fixed at 32-bits (RFC 1035 § 3.4.1). So your first task is to create a new record type and update every DNS server and client to support the longer addresses.
Of course the longer address has to fit into the data structures of the OS you called gethostbyname() from, but gethostbyname() is set to use particular data structures. So now you have to update all the client DNS code to support the new, longer addresses.
Further, gethostbyname() had no way to specify an address type (like if you wanted the IPv4 address(es) or the IPng one(s)):
* https://man.freebsd.org/cgi/man.cgi?query=gethostbyname&manp...
The the returned data structures only allowed for one type of address type, so you either got IPv4 or IPng. So if you wanted to be able to specify the record/address type to query, a new API had to be created.
Luckily the next step, setting up a socket() and connect()ing is less of a burden, because that API already supported different protocols:
* https://man.freebsd.org/cgi/man.cgi?query=socket&manpath=Fre...
But if you have a host that support IPng, but its upstream router does not, how does it support a packet with a longer source address a shorter destination address get through?
Do you send IPv4 packets with embedded IPng packets with-in them to translation relays perhaps? How is this any different IPv6 transition mechanisms like Teredo?
Your isp dns converts the AAAA record to AA record with the ipv4 of it's own (only router) configured dualstack machine, that machine does cgnat46 and visits the ipv6 only server.
If software has hardcoded ipv6 addresses, this is much harder to solve, but I don't think this is really an issue, because hardcoded ipv6 addresses appear very seldom.
Assuming you mean nat46, your description is a bit off. The NAT box doesn't have a single ipv4, it needs a big pile of ipv4 addresses to dynamically allocate whenever a new AAAA record comes through.
But that means it has to intercept all DNS requests and doesn't work with anything it didn't intercept, which seems far from ideal.
>it needs a big pile of ipv4 addresses to dynamically allocate whenever a new AAAA record comes through.
But those don't have to be globally routable.
>it needs a big pile of ipv4 addresses to dynamically allocate whenever a new AAAA record comes through.
This wasn't really a problem until doh/dot became a thing.
But even nowadays doh and dot are provided by whom? By google and cloudflare who are tls-mitm'ing half of the internet anyway.
Moreover most ISPs intercept dns to display those "please enter your phone number to verify your identity" screens anyway.
>far from ideal.
No more imperfect than NAT. Idealism is what is killing ipv6.
If I'm going to run single stack locally I'm going to use IPv6 and a stateless converter for IPv4.
Which means that servers have zero incentive to convert to ipv6.
All this cgnat46 setup is not in the name of end users, because they will always adapt somehow, as reels have a huge force of attraction.
It is to make sure that service providers can deploy ipv6-only _servers_ and not bother that 60 percent of their target audience will be unavailable.
The issue with the ipv6 internet is not the end users, they are paying, so the ISPs will always adapt to their needs, or the users themselves will buy new equipment in the worst case, it's the service providers who stop being profitable by going ipv6-only.
Your idea also gives servers no incentive to convert, and if they do convert they become less reliable for anyone on IPv4.
That process seems extremely error prone on anything but most basic protocols... And given how many people here for example don't run their ISPs DNS... Just seems massively complex and very resource intensive process.
>That process seems extremely error prone on anything but most basic protocols...
Worse is better.
Moreover, we really mostly need to make it work on http, that's enough to say "you can watch YouTube", but also deficient enough to stimulate ipv6 transition.
>given how many people here for example don't run their ISPs DNS..
Those people usually know how to deal with ipv6.
>Just seems massively complex and very resource intensive process.
No more complex than hanging in limbo for 30 years .
> Your isp dns converts the AAAA record to AA record with the ipv4 of it's own (only router) configured dualstack machine, that machine does cgnat46 and visits the ipv6 only server.
You mean like:
* https://en.wikipedia.org/wiki/IPv6_transition_mechanism#464X...
* https://en.wikipedia.org/wiki/4over6
Not, it's the other way round.
If an isp already has full ipv6 deployment, accommodating for ipv4 is easy.
The biggest issue is, surprisingly, not ISPs, but service providers.
> It _was_ possible to create an address space extension that was IPv4 backwards compatible
How? People keep claiming this, but I've yet to see a coherent design (either back then or today). Do you think they broke backwards-compatibility _on purpose_? What's the motivation here?
By promoting cgnat46
> no address space overlap between IPv4 and IPv6, an inherent design flaw of the IPv6
This is not an inherent design flaw and is often brought up in IPv6 threads commonly referred to as the "just add more octets, bro" argument. This comment[0] sums it up well, but I'll leave it here for convenience:
> Fact is you'd run into exactly the same problems as with IPv6. Sure, network-enabled software might be easier to rewrite to support 40-bit IPv4+, but any hardware-accelerated products (routers, switches, network cards, etc.) would still need replacement (just as with IPv6), and you'd still need everyone to be assigned unique IPv4+ addresses in order to communicate with each other (just as with IPv6).
[0]: https://news.ycombinator.com/item?id=37120422
> Having two internets suggests that it's totally different, in the sense that there is no address space overlap between IPv4 and IPv6
That's not at all what I'm suggesting, I'm saying "two internets" because there are two internets: IPv4 and IPv6. You need two internet stacks on every host to deal with this, hence two internets. If everything in the IPv6 protocol suite was literally identical to IPv4, but just with some extra bytes in every address, there would still be two internets, because they are not mutually compatible.
Saying "two internets" is not a judgement call on whether IPv6 changed too much or is too different. It's just the literal truth. There are two internets, because one can't communicate with the other.
Well, that's just not true:
This is a v6-only machine (no v4 address other than lo), talking to a v4-only hostname. If it was truly not possible to communicate, this wouldn't work.> If everything in the IPv6 protocol suite was literally identical to IPv4, but just with some extra bytes in every address, because they are not mutually compatible.
This part is true though. v6 is backwards compatible in rather a lot of ways, but v4 isn't forwards compatible, and it's important to note that this comes entirely from the larger address size -- no amount of making v6 more identical to v4 than it already is would make v4 any more compatible with it, unless you undermined the entire point and made the addresses 32 bits.
Now try that on an ipv4-only host trying to talk to an IPv6-only address. You can’t, hence, 2 internets.
(Yes, I understand there is no other way for a larger address space to exist that doesn’t have this problem. We are in violent agreement here. But that doesn’t mean there aren’t 2 internets. Let’s call a spade a spade.)
I can do it with a moral equivalent of a port forward.
This situation was inevitable, but it's not like they just gave up and said "welp, guess they're separate then". We've developed basically every single method of communicating between v4 and v6 that are possible to develop. There's two address spaces, but they're linked into one Internet.
(Or really, with NAT in the picture, it's millions of overlapping address spaces, but we still consider that to be one Internet.)
> there is no address space overlap between IPv4 and IPv6
Yes there is: https://www.rfc-editor.org/rfc/rfc4291.html#section-2.5.5.2
It's not that different, it's separate.
>It _was_ possible to create an address space extension that was IPv4 backwards compatible, this option was just not chosen, and now we're still dealing with the dual stack mess.
This was never possible.
cgnat46 is totally possible
The "IPv6 is Hard" source seems to be sarcastic, not serious. IPv6 is ridiculously easy, in the grand scheme of things.
What's hard is getting people who should know better to do what they're supposed to do, without playing games. The very fact that there are people who will argue why IPv6 is unnecessary tells us everything we need to know, because occasionally those people are in the path of deployment of something public. They don't write software which works agnostically with IPv6, they don't implement addressing that's stack agnostic, they don't bother taking the extra five minutes to test with IPv6.
Then you have a corporation that requires manager types to have enough "justification" to actually fix whatever Mr.-IPv4-is-good-enough, and because they don't understand that their own phone uses IPv6 all the time, they don't see a "business case" for it.
The title would be longer, but perhaps more accurate, if it were "Getting know-it-alls to stop stubbornly clinging to IPv4-is-good-enough and getting managers to realize that IPv6 is not only inevitable, but ubiquitous, are hard".
This article's conclusion isn't totally off, but in this case it's something that could easily be fixed by having a junior network admin just simply set things up. It's a trivial problem that's probably there because someone thinks they know better.
The conversation is ridiculously fast.
* We can't not support IPv4.
* IPv6 clients can connect to v4 only hosts.
* Supporting IPv6 is nonzero additional work.
* The cost of v4 addresses is on the order of a deli sandwich.
* (If not greenfield) We have a working v4 system right now and adding v6 support is entirely risk with no benefit.
* (Meant negatively) v6 is substantially different. So we will forever be maintaining two sets of networking stacks that play by different rules.
> * IPv6 clients can connect to v4 only hosts.
May I introduce you to my ipv6-only vps
> IPv6 is ridiculously easy, in the grand scheme of things.
How do I do a guest wifi network with isolation? On ipv4 I just flip a switch and thanks to NATs it just works, always.
With ipv6? First I have to figure out what prefix delegation my ISP gives me. How do I do that? Manually, somehow, and hope it never changes. Already not "ridiculously easy" at the first step.
Oops, turns out I was given a /64. So now what? Please explain this "ridiculously easy" thing to me, thanks.
IPv6 is easy, it was just not designed to handle intentionally adverse ISPs.
If ALL customers would get a static /48 and the router provided by ISP wouldn't be industrial waste, you could easily use a different /64 for guest WiFi. (Or even a /56, if for some reason your friend wants to delegate some /64s to VMs running on their notebook.)
But in that case these ISPs wouldn't be able to ask more money for "business" internet services.
I think this is just the result of negligence from IANA or RIRs, these "suggestions" or "best practices" should be mandatory for ISPs and enforced by RIRs.
I don't think you can frame it as "adverse ISPs". I mean in some respects yes, but also IPv6 made the assumption that networks want to be shallow & wide, yet that's not where we've ended up. Rather, we now tend to have a lot of depth to the routing tree. Is this because of NATs? Possibly. But also network isolation turned out to be a powerful tool. And every step of isolation is necessarily another subnet. So now the depth of IPv6 is a limiting factor. Great you can have infinitely wide networks, but you can't expect to nest them much anymore. And that's a rather big limitation.
"If things were different for a lot of people, it would be easy".
So it's not easy.
Guest WiFi network isolation happens below the IP layer: you would use VLANs for that.
Setting up a VLAN for the first time isn't ridiculously easy, but it's the same whether you are using IPv4 or IPv6.
hint, the problem is doing ipv6 vlans with only a single /64. Spoiler alert: you can't do it while also following spec
Sure you can, the tradeoff is that you can't reliably do SLAAC (which I agree needs to get deprecated yesterday).
Which maybe will happen eventually with RFC 9686 & 9663. Those are getting activity and maybe eventually will enable an actual IPv6 future in, oh, another 20 years? give or take.
> Oops, turns out I was given a /64.
Is that really the case though? I very much doubt it.
I get a /56. Dynamic configuration mechanisms exist. I literally do not have to anything except flip a switch. My router even supports Prefix Delegation, so a downstream router/access point can do its thing.
> Is that really the case though? I very much doubt it.
It's what AT&T fiber does. Well, they give a /60 to their shitbox, but if you want your own router with a public IP then you're stuck with a single /64 for it at least when doing the "easy" path.
You can get some routers to request multiple IPv6 blocks and then you get the freedom of a whopping 7 subnets but you've also left "ridiculously easy" way, waaaay in the rear view mirror at this point anyway
Separate vlan. Filtering on Ap. There's several options here.
I mean it’s not a great answer, but you could always set up a ULA for your guest network and use NAT. :-P
But I’m with you on prefix delegation sucking. Prefixes change, and that makes all your devices’ addresses change. ULA’s solve this. But then you start asking hard questions like “if I’m going to use a ULA anyway, why even use the GUA addresses?” And the answer is shrug.
I mean, it’s great that you can give real addresses to your devices when you want to host a service on them, but you can always just NAT your ISP-provided prefix to them anyway. You’ll probably want better addresses for them anyway, as those randomly generated host addresses aren’t easy to remember (may as well just start your public addresses at ::1 and increment from there, routing each one to the underlying ULA.)
Doing stateless NAT through prefix translation is still much more pleasant than stateful port mapping.
A static NAT is all you'd need for ULA to public 1:1.
If you have a static NAT you don't need connection tracking on the router.
You’d need more than a /64 from your ISP if you wanted to do a separate guest network with static NAT though.
OP was saying ipv6 makes it hard to do a guest network if all you get is a /64 from your ISP, but stateful NAT can fix that.
To address some of your points:
I've been writing software for pay for several decades and do not want IPv6.
Phones use IPv4 and IPv6 and you can switch your phone to IPv6 only in the networking settings, run like that for a month and observe multiple weird and bad behaviors.
I don't want IPv6 for several reasons, it looks like it was written by an alien and it inherently is privacy busting. I know many whose job it is to track people as closely as possibly will object but it's true, IPv6 is mainly only wanted by people whose job it is to track people.
v6 is not inherently privacy busting.
It's just an IP. Worry about browser cookies and phone apps sending tracking IDs, not the randomized and non-persistent IPs they're sending them from.
> The very fact that there are people who will argue why IPv6 is unnecessary tells us everything we need to know
Yeah, it tells us that the IPv6 standard was invented by retarded monkeys who don't know what they're doing.
(Yeah, yeah, I know, I've heard it before - akshually it's the rest of humanity who is stupid for not switching to IPv6. If only they were enlightened enough to know they need to throw away all their hardware and switch to an untested network stack for no practical benefit!)
Not hard, just different. Maybe the "harder" bit is actually remembering any one address.
My IPv6 connectivity tester at https://ready.chair6.net is still doing its thing, twelve years since https://news.ycombinator.com/item?id=2154124.
Looks like Hacker News has added support in five years since https://news.ycombinator.com/item?id=21382275.
I built a bit similar simple tool which tracks failed HTTP domains.
https://v6check.miyuru.lk/
will add a link to your site on the failed domains page.
What is the "IPv4 Literals" test?
Haven't look at that code for a while, but IIRC it does a simple HTTP request then checks the returned HTML for anything that looks like a v4 literal, eg. http://174.136.109.18.
The biggest piece of annoyance I have with IPv6: it's really hard to tell the OS "here's your IPv6 address, here's your gateway, here are your routes, now don't mess with any of it!".
With IPv4 it's easy to set up a static configuration. With IPv6, the Linux kernel is eager to listen to all sorts of advertisements from the network, and it's hard to say "no, stop, don't ever ever listen to anything except my static configuration".
I can bring up IPv4 networking in a tiny fraction of a second. IPv6 networking sometimes takes seconds to settle down and be reliable.
(I'd be interested in any suggestions for how to improve this.)
In your /etc/sysctl.d/local.conf:
Or, in your network startup script (like Debian’s /etc/network/interfaces): Or, in your /etc/systemd/network/en0whatever.network:Only accept_ra=0 is actually needed for static config. autoconf is de-facto disabled if RAs aren't being processed, and DAD is a separate thing (but relevant to the grandparent since it takes a few seconds to finish).
Although I'd also argue that you should prefer automatic config over static in general. RAs can set your default route correctly and you can use `ip token` if you really need SLAAC to give you a specific address. I think it's better to be able to just connect machines and have them get the right config rather than need to hand-craft it on each one.
For most cases I agree that automatic configuration is the right answer.
In this case I'm bringing up virtual machines, as fast as possible, and static is inherently faster and more predictable. Automatic configuration isn't compatible with literally counting milliseconds.
If you don’t need link-local addresses, have you tried these?
and/orInteresting! I'll look into those, those look helpful.
I don’t want to trust the network. The network is never secure. Therefore, I don’t want the server to trust any self-proclaimed router with what IP address the server should use. As far as I know, there is no IPsec for RA packets.
Fine, then don't connect to it. Nobody's making you.
There's always static IPs. Do you trust DHCP on v4?
Now how do you do it on your phone or windows laptop? :)
What if you have multiple internet connections and you want to choose which one you go through? With ipv4 and nat you can just change the default route. And you don't even need to write down the router's address since it's <your prefix for the whole network> dot one number.
I've previously found and used all three of those, and those help but don't seem to suffice. There's still some degree to which the configuration seems unreliable, and doesn't settle down for a few seconds.
(I appreciate the confirmation of those settings, though, and those are all an important part of the setup.)
What's the use case for static IPv6 configuration?
because you don't want your server's ip to change.
Don’t all modern server OS choose a deterministic interface ID based on the network in the router advertisement? (As I recall this is usually via hashing the MAC with the RA prefix plus some system-wide but stable seed, to avoid using the MAC directly as the interface ID)
For servers, if you have anything pointing to it (DNS, clients pointing to the IP, firewall rules...)
This is a response to what appears to be a complaint that IPv6 is not treated as a first class citizen by some providers, not literally that it's hard.
If anything, IPv4 is much harder. The Internet is in an abusive relationship with NAT, thinking it's normal.
But we're in a world where if a service breaks IPv4, they lose a very large set of their customers and it's the service's fault. If they break IPv6, it's is perceived that if any customer fails to connect, then it's the customer's fault (or their ISPs fault).
"Hard" for many is "unfamiliar." IPv4 plus NAT and all that ugliness is the devil we know.
I'm also convinced that the length of IPv6 addresses and the difficulty in typing them is a major reason for lack of adoption. Very seemingly small UX annoyances can have a large effect.
> I'm also convinced that the length of IPv6 addresses and the difficulty in typing them is a major reason for lack of adoption. Very seemingly small UX annoyances can have a large effect.
I've been convinced of this since around 2000. Every network utility dealing with IPv4 had... dotted quad addresses. You could remember them, you could read them, you could speak them to someone else. Brainwise, we can remember 3-5 things - segments, digits, etc. Remembering more is harder for the average person.
Having the 6 be literally dotted sextant(?) - 5.73.192.168.0.4 for example - would have been much much much easier to transition in to, and would have given us 64k x 4 billion addresses. Yes, it's not the near infinity we have with IPv6, where apparently every molecule in the universe can have multiple IP addresses or whatever the max number is. But it would have been much much easier to transition. 27 years later we're not transitioned from ipv4, and we've got another 27 years of dotted quad baked in to daily usage everywhere.
I think you’re exactly right on this. Further , difficulty in remembering or visualizing IPv6 addresses I think makes it more difficult to understand how it works (vs learning how v4 really works) and thus weaker adoption
You have merely re-invented IPv6 but with a 48-bit address space. In your universe you would still have to run dual-stack with IPv4 indefinitely.
Prefix every IP with 'missing' info with 0.0.
Part of this would just be transitory, but... would take up far less space. Even as late as last year, I'm reading stories about BGP issues and slowdowns because routing tables are too large/many for the hardware. In 2024. How on earth was this expected to work on hardware from 1999?
there is something called an "IPv4-compatible IPv6 address" and it's exactly the scheme you suggest: the first 96 bits are zero. It doesn't help deal with the billions of devices that only handle a 32-bit address space, however. What do you suggest we do with them? _They_ are the long tail that keeps us in the dual stack world.
Those routing tables are badly made. An IPv6 route takes twice as much memory as an IPv4 route, and there are a lot less than half as many IPv6 routes.
https://blog.apnic.net/wp-content/uploads/2023/01/Figure-1-%...
https://blog.apnic.net/wp-content/uploads/2023/01/Figure-14-...
They didn't invent SLAAC, so no that wasn't a reinvention of IPv6.
But even if they had the counter argument to "128 bit addresses are too long, 48 bit would have been better" is obviously not "that's the same thing just with 48 bit addresses!"
That would have required exactly as much work to transition, plus require computers to get good at 48-bit math. ("Why are the top 2 bytes always 0xFF?" "I don't know, grandson, but I'm sure it seemed like a great idea before Y248.")
I'd imagine many countries would claim a top spot or two, and transition all canadian addresses to, say, 7.0.0.0.0.0. Big companies would probably get some of their own. Legacy/default stuff would have leading 0.0, sure, but... so what?
No, it wouldn't have taken 'exactly as much work to transition'. See another reply. In 2024, I'm still reading about BGP/routing table issues, and hardware having problems keeping up with IPv6 networking - it's just too large. How was this supposed to work in 1999?
A smaller stepped transition from 4 billion addresses to... 64k of those would have been an easier transition step, and the ease - mental, UI, training, testing, security, etc would have given everyone involved the confidence and positive feedback to tackle a next stage to IPv6 (eventually).
Yes, though in hex.
Maybe a long time ago, but just about everything I've used recently supports mDNS for LAN hostnames. If I add a computer named "foo" to the LAN, it's almost certain I can run "ping foo" on another computer 3 seconds later.
that's not mDNS that's just dhcp+dns and it's something ipv6 actually breaks, which is part of the problem. DHCPv6 is optional, so local devices don't necessarily ever register their hostname nor do they necessarily ever consider your local DNS server.
>that's not mDNS that's just dhcp+dns
Actually mDNS does exactly what they said just fine. You’re confusing it with the ability of a DHCP server to make updates in DNS on behalf of clients. There is more than one way to skin the cat. Both achieve the same affect, just differently.
> nor do they necessarily ever consider your local DNS server.
Hardcoded DNS servers are just as equally a thing with IPv4.
That's right. I'm specifically talking about mDNS, not DHCP+DNS. It works out of the box nearly all the time that I've tried it.
> Hardcoded DNS servers are just as equally a thing with IPv4.
Of course, but they aren't the baseline expectation like it is with ipv6 since ipv6 baseline assumption is SLAAC. And SLAAC is terrible. If you control all the devices on the network, like a cloud install, you can just pretend SLAAC doesn't exist and live in a much better world.
If it's a home network then you're stuck expecting at least some usage of SLAAC. And you're better off just not supporting ipv6 at all at that point
> they aren't the baseline expectation like it is with ipv6
Why not? Are you saying your computer doesn't need to know the IP address of any dns server in order to be useful?
What do you mean when you say that SLAAC is terrible? Especially when you control all the devices on the network, you are in full control of what SLAAC manages for you. Also, SLAAC is the only way to use the IPv6 Privacy Extensions.
mDNS would work just fine but the given command ('ping foo') wouldn't be using mDNS. That's just standard name resolution. `ping foo.local` would potentially use mDNS if you have a ping that does such a thing, but that's restricted to `.local` specifically.
Rather, most routers add DHCP hostname requests to the local DNS routes. That doesn't require mDNS, nor would you want to replace it with mDNS as mDNS is more limited & flakier.
My resolved in its default configuration will try appending .local and search via mDNS if no results are found via the DHCP provided server. I believe macOS does the same.
Ping foo on my machine results in foo.local being successfully pinged. Your mileage may vary.
> would potentially use mDNS if you have a ping that does such a thing
It's not a feature of ping, it's a feature of the name resolution setup on your machine (nsswitch and/or resolved on Linux).
> Rather, most routers add DHCP hostname requests to the local DNS routes
What do you mean?
You don't need DHCPv6 to auto register hosts in DNS. You just configure the DNS server to register based on neighbor discovery.
Things like RA and NDP would clue hosts into the local DNS server as well. You don't need DHCPv6 to advertise a local DNS server.
> "Hard" for many is "unfamiliar." IPv4 plus NAT and all that ugliness is the devil we know.
Indeed. I meant that if evaluating the two de novo, IPv4+NAT is harder.
I agree that NAT sucks but IPv6 having two different ways of assigning addresses (SLAAC and DHCPv6) with one of them being practically optional (Android doesn't do DHCPv6 for address assignment) does make IPv6 harder than it needs to be.
Then there are crimes against network protocols like NAT66 that are borderline necessary in some situations because terrible ISPs have decided to dynamically alter IPv6 prefixes so they can charge extra for a static prefix.
I still think NAT makes everything harder than it should be, but I get why some people struggle with IPv6 if their ISP is particularly terrible.
I don't generally care for Android but I'm glad they chose not to support DHCPv6. It's a nice forcing function to make network admins actually learn how SLAAC works and why they should almost certainly prefer it to DHCP.
The sin of IPv6 was trying to do too much. They should have extended address sizes, period. SLAAC and most of the other extensions were a mistake.
Everyone should bomb Android bug reports with complaints about lack of DHCPv6 until they fix it. Then people can de-facto deprecate SLAAC. AFAIK Android is the only major offender here.
Some corporate networks already don't do SLAAC if they don't need Android to work on them.
In that case ISPs would give you a single /126 and ask more money for extra devices, eg. /124 for a "family plan".
> I'm also convinced that the length of IPv6 addresses and the difficulty in typing them is a major reason for lack of adoption.
Possibly, but I think it's also that some aspects of IPv6 are just badly designed, and subsequent updates only fixed some of the issues.
SLAAC, for example, is godawful stupid. And while DHCPv6 exists to fix some of that, critical aspects of the protocol, like prefix delegation, are manually configured. This is beyond idiotic and makes things like subnets massively more difficult than they have any right to be.
SLAAC and PD combine to create the worst sin of all - flakiness. It's hard to figure out why IPv6 isn't working because everything is telling you it is (it "auto configured" a valid IP despite not having any actual route to anywhere else, so helpful! /s). If IPv6 was literally just "IPv4 but 128-bit addresses instead of 32-bit ones" it almost certainly would have been adopted en masse by now. But it isn't, it made things more fragile and harder to configure for no goddamn reason.
And of course you then have ISPs doing silly stuff, like my ISP only gives me a /64 so I literally can't use IPv6 on my network since I want VLAN isolation. 18446744073709551615 possible addresses are given to me yet dividing that up into 3-5 subnets is completely impossible. Fucking stupid protocol.
Why is delegating smaller addresses impossible? Kernels will totally take /72, /88, /96, etc. without issue... or at least any OS I've ever used will.
It breaks SLAAC so routers won't do it. Or if they do, it's non-standard and they won't easily let you do it. /64 is the smallest PD by spec ( RFC 5375 )
It may brake SLAAC. OpenBSD implements autoconfiguration for non /64 prefixes (IIRC)
You can do it with DHCPv6, but of course there's Android. Android aside, it works fine.
The core of V6 -- longer IPs -- is great. SLAAC and /64 being the smallest need to be deprecated. It's asinine.
Really absolutely everything but longer IPs should be deprecated and was a mistake.
> You can do it with DHCPv6, but of course there's Android. Android aside, it works fine.
are you sure? what about homepods, Chromecasts, Hue bridges, kasa smart plugs, esphome, etc etc etc...?
How much are you willing to bet your home network on Android being the final user of SLAAC? And how much time do you want to invest in figuring that out in the first place?
You can have IPv6. Though you can't have SLAAC.
Although https://www.rfc-editor.org/rfc/rfc7217 doesn't require a /64 or shorter prefix for its variant of address auto-configuration, for example Linux doesn't allow otherwise.
Honestly we probably need IPv7 to roll back most of the things from IPv6 and be closer to IPv4x4. IPv6 is now older than IPv4 was at the time IPv6 was invented.
Heck, I would have probably simply added an Options flag for "long address" to support longer addresses. With the first part of the address being the IPv4 address of some ISP backbone router and the next 3 words being a device address on the network (with the all-0 device address reserved for the router itself). Then you don't even need to upgrade most of the routers beyond configuring them to accept packets with that option set. It would have been so simple and elegant and we would have probably upgraded most of the world by 2001.
>IPv6 is now older than IPv4 was at the time IPv6 was invented.
The quantity of existing deployments that need to change is much larger for v6 than it was for v4. The problem with deploying v6 isn't that it's too different from v4, the problem is that it's different at all. Your v7 will have the same problems.
IPv6 looks silly until you learn about the problems it actually solves, and then realize it would be completely impossible to incrementally upgrade IPv4 to get there.
> This is a response to what appears to be a complaint that IPv6 is not treated as a first class citizen by some providers, not literally that it's hard.
Last time I've checked, some telecoms such as Vodafone didn't even supported IPv6 yet.
telecoms that deal with consumers have at best 0 (zero) incentive to deploy ipv6 unless there's regulatory pressure.
b2b telecoms as a consequence also have at best zero incentive since if the consumer doesn't have ipv6, businesses don't need or want ipv6.
the solution here, which will inevitably strike a nerve with some, is to have a regulatory mandate for ipv6. a soft version would start with 'government networks must run exclusively on ipv6, this applies to any and all contractors, including govclouds' and work upwards from there. I understand such policies were in place or at least planned; OTOH in the current political climate it'll be sort of a miracle if the existing ipv4 networks keep working.
Change at tier one telecoms providers tends to be glacial. It follows hardware upgrade cycles that take ages to plan and implement.
I spent a decade writing element management systems. An element is a network device - switch, router, ROADM, etc. Often you give the customer kit & software and they spend a couple of years assessing it. This software would be installed on secure out of band networks with no route to the internet. 10/8 would have been adequate for the lifetime of the hardware currently in service - 200G stuff. However, that's not how things played out.
When I started working on EMS software IPv6 support was a requirement but it was just a box ticking exercise. No one was actually going to use it. A decade later IPv6 HAD to work for northbound and southbound traffic, on an internal network. Otherwise, no sale. IPv6 is being used in anger in telecoms. I have no idea how long that will take to filter to in band networks.
> telecoms that deal with consumers have at best 0 (zero) incentive to deploy ipv6 unless there's regulatory pressure.
Not entirely true. 10/8 is only so big, so the management of addresses very much has a nonzero opex cost.
And on top of that there's capex on "carrier grade NAT".
For the biggest providers 10/8 is not even big enough for their production environment. And then they acquire some some company that (obviously) also uses 10/8.
No, there's definitely incentive there. Just… not enough.
240/4 is usually used when 10/8 isn't enough.
Do you have data on that? I've heard rumors, but never seen it actually done.
It was never a viable option for the Internet (million or billions of devices would never support it, and anyway it'd only buy us like 3 months), but in theory it should work better in the (more, but not entirely) controlled environment of a large prod environment.
I know of several massive setups that when running out of 10/8 evaluated 240/4 but deemed it less feasible, riskier, and definitely more work, than to "just" move to IPv6. Sorry, can't namedrop them, since I don't want to doxx myself. I've never seen 240/4 actually chosen.
We use them in AWS as IPv6 hasn't been feasible, though its become better in the last 1-2 years. AWS uses it internally, likely other big providers probably also do. If you can get away with IPv6 only, ie not constrained by provider/device, its likely worth going that direction instead.
Works fine in Linux, doesn't really work on Windows and some BSDs.
https://blog.benjojo.co.uk/post/class-e-addresses-in-the-rea...
240/4 is multicast range, and mobile devices WILL wreak havoc in that range (though it's not impossible to simply drop all such traffic at ingress). I usually see service providers using 172.16/12 instead.
224/4 is multicast. AWS uses it, we use it in AWS, as do others. Works fine with Linux, Windows not so much, afaik android and osx are fine with it.
> telecoms that deal with consumers have at best 0 (zero) incentive to deploy ipv6 unless there's regulatory pressure.
I don't think this is true. The IPv4 address exhaustion is still a problem and it's getting worse, and telecoms which also provide internet services need to allocate addresses to their clients. With the 5G rollout these telecoms need to make room for new devices, and that's not feasible with IPv4.
I was under the impression that cell carriers famously went all in on v6 because it saves them money?
Yes that don't have to allocate an IPv4 address for each customer or deploy ugly solutions like CGNAT. They simply cooperate with phone OS makers (Apple and Google) to make sure the OS and the apps work in an IPv6-only environment. Apple then forces app developers to make their app work in an IPv6+NAT64+DNS64 environment.
They're using it internally. It's probably for the best that the last place they test it on is their customers.
I don't disagree, but I would point out that one upside to every LAN being behind NAT, is that those LANs are also inherently firewalled.
This is dependent on the firewall features of the NAT router, but at least its something, and the router provides one centralized point of protection from interent traffic.
In IPv6 typically every machine on a LAN is directly connected to the internet with a public IP address. Every one of those machines now needs a full strength internet firewall.
This complicates some intra-LAN communications, and removes the feature of having the LAN be a walled garden, mostly isolated from the interent.
Or you can implement a firewall on your gateway device with a default drop policy for inbound traffic. Essentially the same behavior as NAT in terms of unsolicited (usually malicious) inbound traffic, but without the downsides of one-to-many NAT.
Which is, coincidentally, exactly how it works if your LAN is made up of devices with publicly-routable IPv4 addresses as well, which happens in business/academic/military networks all the time.
But most users are not business academic military.
They just want to watch some reels.
And? Most consumer routers also implement a stateful firewall with deny-by-default inbound policy. My point is that NAT isn't a security feature, and that firewalls in edge network equipment is table stakes these days.
>Most consumer routers also implement a stateful firewall with deny-by-default inbound policy.
No they don't.
Most ISP boxes only implement the bare minimum of functions to make sure that youtube is available to the users. Which includes NAT, because otherwise youtube does not work, and does not include anything else.
Well, that's news to me. I don't use consumer routers myself, but I know lots of folks who do. Now, I won't say that I go investigating their home networks, but IPv6 is rather prevalent among the discount ISPs where I live, and I know of at least two coworkers who have an IPv6 firewall by default with their router.
Anyway, NAT is costlier than a firewall. It uses more memory, it requires rewriting packets on-the-fly, and typically if you're using embedded Linux (I'll assume that the vast majority of consumer devices for this are) then you're already using `iptables` or `nftables` to get NAT functionality. It is comparatively to set default inbound/forward drop policies.
But yes, I should have said "in my experience," since it's true that I only know the networking equipment of a few people in a small country with limited IPv6 rollout (my ISP does not provide it).
NAT is awesome. It automatically forces users to have a stateful border firewall that makes incoming connections impossible.
NAT does not, in any way, "force" the use of a firewall. They're entirely separate concepts.
In the most commonly (almost exclusively, in case of end users) deployed setups (call them NAT Masquerade, NAT Hide, NAT Overload, NAT Many-to-One, PAT, whatever) it does block incoming connections, only allowing replies to internally-originated traffic, and to do that it tracks the state of all traffic.
Is that a real, full firewall? Heck no, I'm equally worried about what my systems leak than outside threats, and it does nothing for that.
but aren't we nitpicking a little here? veering on the "technically correct, worst kind of correct".
> In the most commonly (almost exclusively, in case of end users) deployed setups (call them NAT Masquerade, NAT Hide, NAT Overload, NAT Many-to-One, PAT, whatever) it does block incoming connections, only allowing replies to internally-originated traffic, and to do that it tracks the state of all traffic.
Yes, but that's because it's co-located with a stateful firewall, sharing the same connection tracking state. Without that firewall, if a device on the WAN side sends to your router a packet with destination address on the LAN side, your router will route that packet to the LAN, even though it's not a reply to anything sent from the LAN to the WAN. That is: it's a misconception that port mapping NAT blocks incoming connections; port mapping NAT only affects outgoing connections and replies to them.
> if a device on the WAN side sends to your router a packet with destination address on the LAN side
This can happen only if the device is directly attached to the NAT server. Basically, only your ISP can do that.
Most NAT servers by default also prohibit this kind of routing (because why even allow it?!?), but even the most misconfigured bad NAT server is still vulnerable only if you control the ISP, in practice.
> Is that a real, full firewall? Heck no, I'm equally worried about what my systems leak than outside threats, and it does nothing for that.
But it is. Even a "full" firewall can't do anything against something on one of the inner host leaking into the outside. Most of the traffic is encrypted, even DNS. So the firewall can't operate on much more than the destination address to decide if a connection should be allowed.
If you want more security, you need to secure individual endpoints.
It forces the use of some system that statefully tracks packets and makes routing decisions based on that information. Such a system will be capable of firewalling unless you go out of your way to make it not.
No, your thinking of a stateful IPv4 home style NAT. There's also stateless subnet mapping.
There are some stateless things that are also called NAT, sure, but that's not what we're talking about here. (Fairly obviously, since a stateless mapping doesn't and can't save addresses).
But this feels tautological. It's been reduced to "If you want to use NAT with features that only a firewall gives you, then that forces you to use a firewall".
I suspect when people talk about "NAT" in the context of a residential connection, what they actually mean is a "default-deny firewall with connection tracking".
Feel free to replace "NAT" with "the kind of NAT that permits you to share an address between multiple devices" if you feel the need to be pointlessly pedantic about it. The point is that any device that allows sharing a single IP between multiple devices will necessarily implement connection tracking, and will therefore be capable of functioning as a firewall.
(Are you going to point out that statelessly blocking a fixed IP range used to be called "firewalling" so a device without connection tracking can still technically be a "firewall" next?)
Pretty much any system that's capable of handling IP traffic is also capable of firewalling. Not sure what that's got to do with address rewriting though.
> Pretty much any system that's capable of handling IP traffic is also capable of firewalling.
A system that can't track connection state, or doesn't have enough capacity to do so at line rate, can't meaningfully firewall. When the norm for home equipment is ISPs sending it out for "free", they absolutely send out the cheapest stuff they can get away with, and in the pre-smartphone era that meant "modems" that would just provide a straight PPPoA connection with no firewalling.
NAT _is_ a firewall. And it provides the same level of security as pretty much all of the "firewalls" marketed as such.
No... it's not? It's simply a widely-used technique to rewrite the addresses of IP packets that transit a router. It inherently makes no policy decisions on which packets should and shouldn't flow over and above what a router does anyway.
It automatically prevents the outside world from being able to access the inside network. Which is the main function of most of the firewalls.
Pretty much everything else in a firewall in the modern world is just useless feature creep.
It doesn't do that. It rewrites the source address that outbound connections appear to come from; it doesn't implement any kind of access control.
Take two networks that are identical, except one is doing NAT and one isn't, and test them. Every connection that works on the without-NAT network will also work on the with-NAT network. The only difference you'll find is that some outbound connections which didn't work on the former will work on the latter.
Some would argue that "every connection that used to work still works, and some connections that didn't work before do now work" is kind of the opposite of a firewall.
> It doesn't do that. It rewrites the source address that outbound connections appear to come from; it doesn't implement any kind of access control.
It absolutely does. There is no way with NAT to connect from the outside network to the inside ("but what if the attacker is directly attached to the next hop blahblahblah"). That's all that firewalls need to do, everything else is useless noise in the current world.
> Take two networks that are identical, except one is doing NAT and one isn't, and test them.
Here's my IP: 192.168.80.36. Feel free to attack me. Go on. The public IPv4 of my router is 76.191.126.81. I even opened a port 8871 for you with a static page with a Bitcoin wallet worth $1000, you just need to get to it.
You can't. There's no way to get to my computer without hacking the NAT server first.
That's why NAT _is_ a firewall, and a foolproof one at that. It's secure by default, unlike IPv6 firewalls that can fail open.
I've just remembered the firewall alignment chart, which asserts a view of the world that an excavator is a firewall.
https://sh.itjust.works/pictrs/image/421c9549-83ee-487a-9fa0...
It's possible to get to your computer without hacking the "NAT server", but I'm not in a position to do it. There's no point setting up a demonstration if you don't make it possible for me to actually do the demonstration!
When I set one up for you (back here: https://news.ycombinator.com/item?id=39173556) I gave you the access needed to actually do the test (...but you either missed that message or opted to ignore it, so you never tried it). You need to either move your network to routed IPs or give me a tunnel to the upstream network of your router first.
Not doing either of those doesn't make you right. NAT is still not acting as a firewall here. I'm just not in a position to take advantage of that, due to your use of RFC1918 addresses on the LAN side.
> It's possible to get to your computer without hacking the "NAT server", but I'm not in a position to do it.
Nope. Even with a misconfigured box that forwards the traffic from WAN to LAN, you need to be in the direct contact with the NAT server (an OpenWRT box). And that's the point, you are _not_, as is pretty much everybody else in the world, outside of people who have keys to my house and my ISP.
In practice, this provides all the practical security you need from a firewall.
> I'm just not in a position to take advantage of that, due to your use of RFC1918 addresses on the LAN side.
Well, duh. That's the whole point of NAT (when used typically). You don't get to access my internal network, you simply can't do that physically.
No, you don't need to be in direct contact with the NATing router. That's kind of the entire point we're trying to making here.
All you need to be able to do is send a packet that ends up at your router with the dest IP set to one of your LAN machines. This only requires being directly attached to your router if you're using RFC1918 on the LAN; if you're using a properly routed prefix then it can be done from anywhere.
> Even with a misconfigured box that forwards the traffic from WAN to LAN
Forwarding traffic from WAN to LAN isn't a misconfiguration. Your router needs to do that for TCP to work, or get replies to outbound UDP.
> No, you don't need to be in direct contact with the NATing router.
Or control the internal network of my ISP.
> All you need to be able to do is send a packet that ends up at your router with the dest IP set to one of your LAN machines.
Which you can't do.
> if you're using a properly routed prefix then it can be done from anywhere.
If I had a publically routed /24, then I wouldn't be using NAT in the first place. Which is the case in point: NAT _is_ a firewall.
> Forwarding traffic from WAN to LAN isn't a misconfiguration
Sigh. I mean allowing the SYN packets to be forwarded from WAN to LAN.
You can do it from anywhere on the Internet, you don't need to control the ISP's network or anything. If your NATing router receives a packet with the dest IP set to a LAN machine, it forwards it to said LAN machine regardless of where that packet came from, unless blocked by a firewall.
Whether or not someone can get that packet to your router in the first place is a separate question. If you're using RFC1918 then yeah, they'd need access to your direct upstream network. But the point I've been trying to make is that NAT doesn't influence the answer to this question: whether or not you do NAT has no influence on the behavior of any of the routers upstream of you.
NAT has no influence on whether these packets can reach your router or not, or on whether your router will forward them if they do arrive. That's why it's not a firewall: because it's not actually doing any firewalling.
> If I had a publically routed /24, then I wouldn't be using NAT in the first place. Which is the case in point: NAT _is_ a firewall.
It's not possible to go from "I wouldn't be using NAT if I had a routed /24" to "NAT's a firewall".
If you had a routed /24 then you might not use NAT, but that says nothing about whether NAT works as a firewall or not. The relevant part isn't "would I still be using NAT if the situation was different?", it's "does NAT block inbound packets?". Since it doesn't, it's not.
> Sigh. I mean allowing the SYN packets to be forwarded from WAN to LAN.
Well, yeah, allowing those is generally a misconfiguration... in the firewall. The routing part of the router doesn't pay any attention to TCP flags, just IP addresses.
I’ve never seen one without the other, so while technically correct, not useful to debate.
It's useful to correct this misunderstanding, because people often take "I've always seen NAT come with firewalling" to mean "firewalls are impossible without NAT".
You quite regularly see people pop up in these threads arguing something like, oh, I dunno, "In IPv6 typically every machine on a LAN is directly connected to the internet with a public IP address. Every one of those machines now needs a full strength internet firewall.", as if this is somehow a problem with IPv6 rather than a problem with their own understanding. It's hard enough to get people to deploy v6 as it is without them mistakenly believing that a lack of NAT means their router can't provide firewalling either.
shrug at work we use NAT to let two different networks with overlapping addresses talk to each other all the time. No firewalls there.
NAT wasn't invented for the home-broadband user, you know.
But I'm at least glad we've cleared up the myth that NAT provides any security benefit when, in fact, it's the often deployed accompanying stateful firewall that's actually providing this.
We out-number companies, perhaps by an order of magnitude.
Not by allocated IP address count.
NAT is by definition not a firewall. And while it provides security, it provides no more security than having a firewall, while making various scenarios worse. NAT is not a good solution for security.
I second this, it forces security by default (at least keeping devices from being directly exposed)
(Title is sort of clickbait. The body is about how it isn't hard, but certain misconfigurations make it appear hard.)
Note that curl itself also implements Happy Eyeballs if you don't force a particular protocol via `-4` or `-6`. You can see it in action with `curl -vvvv https://opentalk.mailbox.org`. So you shouldn't look at the author's example and extrapolate that `curl github.com` or `curl opentalk.mailbox.org` will fail in an IPv6 environment.
It's surprising to that all comments (except a few) state that IPv6 is not hard. I'm not an IPv6 expert but I did spend time learning it (may be even more than I spent on IPv4 but with v4 I have more practical experience). I used v6 for a few years at home / home lab (and for a side project). I think IPv6 is hard - there is much more one needs to know to use it well than in case of v4. Any deviation from a happy path (a non-standard configuration / use case) is a pain (or at least it was 10 years ago, don't think it is much better now except now we likely have even more RFC to learn). Not used IPv6 recently so cannot name specific problems but I didn't enjoy working with it at all. Will do it again only if it will be well compensated.
I think there's a big difference between enterprise IT folks who can specify hardware with good IPv6 support, and which are able to switch internet providers if they don't support IPv6 well.
It's entirely a different thing for home users which get handed some shitty router from the only ISP around.
My options are cable or long-distance ADSL. The cable ISP has dynamic prefix, so I get a new prefix every week or so. If you contact them regarding IPv6 there's zero support, I had to find the prefix length by trial and error.
So much software relies on the prefix being fixed, so this can lead to a lot of frustration. On the bright side I actually get a prefix, some just get a /64.
IPv6 might not be hard, but using IPv6 might indeed be hard.
> On the bright side I actually get a prefix, some just get a /64
what's the difference?
I can use SLAAC, which is nice for non-server hosts like our Android phones and such. And AFAIK privacy extensions rely on SLAAC.
> Any deviation from a happy path (a non-standard configuration / use case) is a pain
I've posted here before about my home network with two internet connections. Not going to whine about it again, except restate that i basically have no idea what to do about it with ipv6.
As per the article mentions of resolving AAAA IPv6 records, a feature was just merged into Linux's systemd-resolved last week.
https://github.com/systemd/systemd/pull/34165
So you can do.
RefuseRecordTypes=AAAA
So there, your DNS won't ever query for IPv6 AAAA records.
(in fact you can refuse any DNS questions like MX, SRV, TXT as well with:
RefuseRecordTypes=MX SRV TXT)
Note - I started adding that feature because some applications were "misbehaving" and querying AAAA records when IPv6 stack was disabled.
can it do `RefuseRecordTypes=A` as well?
IPv6 is really an example of a second-system syndrome. It really _is_ hard because it makes a lot of IPv4 conventions inapplicable.
For example, if you want to do multi-homing with IPv6 for an SMB, you need to either do NAT (not great), or have your router advertise/whithdraw prefixes dynamically. If you do the prefix withdrawal, you can end up in a situation where your devices have _no_ prefixes. So even your internal functionality like printing or VoIP starts breaking.
Great.
Then there's ULA that is mis-prioritized. You'd think that simply adding a stable ULA prefix to all devices would solve the issue above, but that's not the case. The devices will prioritize the global IPv6 source address, so stuff can _still_ break.
I have three connections at home both as a way to increase available bandwidth and also to provide some redundancy since I work from home and my ability to earn income is tied to my internet being up.
I have two primary connections that I load balance between, each providing a /56. If either fails, all traffic goes to the other. I have a third connection that is used only as a backup in the event that both the other connections go down, providing a /64.
So simple case, I assign an address from each connection out to each device.
Except, whoops--the backup ISP only provides a /64 and despite that containing something like 18.5 quintillion addresses (a number so large my spell check is telling me it's not a real word), I can't actually split those up in any meaningful way so I can only allow _one_ subnet to access the internet via that connection.
And then I'm pushing responsibility for load balancing between the two primary connections out to each client. You know, to the place with the _least_ useful information for making decisions in this situation. And then I need to figure out how to convince each device to make these decisions individually. (As far as I can tell, with an equal cost, Linux will simply use the most recently added address. So in the event that one of the primary connections is having issues and bouncing up and down, that's going to be the one that all the Linux devices choose to use preferentially. Absolutely what I'd want!)
So I give everything a ULA (which I'd want to do anyway so my internet going down doesn't mean my TV can no longer stream media from the server across the house, since that's a reasonable thing to expect to happen) and then look at doing some sort of prefix translation. Except since nobody's using this stuff because it's so very not hard, I hit a bunch of weird edge cases in my network gear trying to do that. Not the least of which is that I need to statically configure the prefix I'm translating _to_ except that's not provided to me statically so now I need to set up some sort of script to monitor the prefix on the external interface and dynamically update my firewall rules?
Oh, except apparently the RFC was only updated like a year and a half ago to prefer IPv6 ULA addresses over IPv4 so most devices would end up just using IPv4 anyway and the IPv6 deployment would be little more than a box checking exercise until everything's updated. (Though it looks like that change may never have been adopted anyway?)
Last time I was digging in to this, I ended up down a path of starting to file forms with IANA to get a IPv6 block directly allocated so I could use a GUA internally (avoiding the preference issue), do prefix translation for load balancing, and announce the IP range from AWS and tunnel it to my router to work around the /64 issue on the backup connection.
Or, or, or... hear me out... I can just... _not_. Nothing is broken right now. I derive no personal value or enjoyment from stacking up a house of cards I'll have to keep standing back up so my toaster can have a globally reachable internet address.
People can tell me it's "not hard" all they want, but after... oh hell, 30 years of bending computers and networks to my will, I feel pretty confident in saying either:
I'd be happy for someone to come along and tell me I'm an idiot and _precisely why_ though. Really. Somebody. Please do. Tell me how I am supposed to make this work. I know it's a thing I _should_ be doing but I really can't figure out how.There is an RFC proposal to allow SLAAC on networks that are smaller than /64, so you might be able to utilize the third connection and still have an ability to do subnetting.
Sometime around 2035.
I think “and we’re gonna kill NAT too!” is precisely where IPv6 overstepped and started making things worse for itself. It didn’t need to be this way.
NAT sounds like a bad idea at first glance, but it doesn’t exist just to alleviate address shortages (although it does.) It doesn’t just exist to provide security by default either (although it does that too.)
NAT is also the only sane choice in residential setups. Because your public IP address prefix isn’t static. That was never going to happen. And just saying “never put an IP address in any configuration file” isn’t a satisfactory answer. When a reprefix happens, and your clients are all only speaking on GUA addresses, your network is going to be fucked until they expire the old addresses. Not in theory, in practice. None of my devices in my household did any sort of reasonable thing when Comcast changes my prefix. I had to just go around and reboot everything.
NAT means I am in 100% control over what IP addresses I configure in my own network. It means I can actually run a DNS server and it works. It means I can configure devices with static addresses and it actually works.
ULA isn’t some edge case, it’s the only sane option in residential setups. (You know, that thing you need to maximally support in order for ipv6 to have a chance in hell at succeeding.)
The IETF finally releasing guidance that ULA’s should be on equal footing to GUA’s feels like them finally admitting that there might be something to this whole NAT thing. It happened entirely too late IMO.
Yeah, to agree with you in different words--
With IPv4 and NAT, I'm setting up a network. I control it from end-to-end. I can define whatever subnets I want, connect them how I want, put a static IP on my IoT device so Home Assistant can find them reliably, etc. Then I have _a_ point (well, three) where my network touches another network and all configuration and setup around how the two interface and interact is defined and controlled there.
With IPv6 the expectation is I'm building out another little piece of someone else's network. Now all the communication within my network is closely intertwined with theirs. There's really no good way for me to handle that today.
Using SLAAC so devices update when prefixes change leaves me unable to find/connect to anything. Short of installing a DDNS client on my air quality monitor somehow, how do I manage to connect to it?
I can use DHCP6 (not on Android though!) and let the server handle DNS registrations. This would also regain the ability to push a NTP server to clients which would be a nice thing to have. Except now when the prefix changes the devices have no way to know and (like you say) I have to run around and reboot everything.
And this still doesn't give me a path to load balancing across multiple connections!
I guess really the bigger issue here is the dynamic nature of the prefixes. If I could go log into IANA and click a button and get assigned a /48 then log in to my ISPs' sites and attach it to my connection and be on my way... I'd deploy it today, no problem.
I can't see any _technical_ reason that wouldn't be possible. But there isn't a snowball's chance in hell any ISP starts offering that ability on consumer connections when they could be gating it behind having a $5k/mo business connection.
> I guess really the bigger issue here is the dynamic nature of the prefixes. If I could go log into IANA and click a button and get assigned a /48 then log in to my ISPs' sites and attach it to my connection and be on my way... I'd deploy it today, no problem.
Yes, this right here. It should work like a phone number where you can take it from provider to provider. You setup your gateway with your IPv6 prefix and then go.
Problem is all the technical and non-technical stuff to actually make that work.
- Verifying ownership of the prefix (rPKI or IRRs) and which ASNs are allowed to advertise it.
- Limiting allocations to someone? I guess phones solve this with SIMs
- Getting your ISP to route the traffic to your device
- Getting the device to announce it with RAs
- Dealing with asymmetric return routing over a slow "path" since it could be multi-homed
- Dealing with routing aggregation since IPv6 routing tables would explode with all the /56s in there
Maybe bring back Mobile IPv6? https://en.wikipedia.org/wiki/Mobile_IP
I know people that get a prefix from their RIR, announce it from a cheap $2 VPS in the same data center as their ISP, then just do a quick WireGuard tunnel to it (so sub-millisecond additional latency, ideally) and use that to route packets from the prefix. I guess it works pretty well, but like you said: I can also just… not.
Because the other issue if you’re ULA-less is that if your router loses its connection and rescinds its RA (or you just stop the RA daemon, or shut down the router, etc), suddenly you don’t even have LAN connectivity any more because everything will have deleted its routes.
> I can't see any _technical_ reason that wouldn't be possible
Every additional route and its ASN takes up RAM in nearly _every_ router that has a DFZ (default-free zone) view. This RAM is not cheap, so regional registries are incentivized to keep the number of new registrations down.
For IPv4 there are about 1 million routing entries right now, and for IPv6 about 200k. The IPv6 routing space can reasonably scale by about 5-10x before requiring serious changes in the core routers, but that's just not a lot of entries.
Yeah, that thought had crossed my mind and for some reason I figured "hey, hurricane electric will give me a /48 at points all over the world, guess someone figured it out". Thinking back... no, that doesn't mean that. It's not portable and there's no reason they're not assigning from different pools at each location.
IPv4 and nat solved the problem quite nicely in the real world.
IPv6 just yelled at people and said it wasn’t a problem.
I think that the main challenge people face with IPv6 is that they try to deal with it in the same way as with IPv4. IPv6 is not just a longer address, it's a completely different technology.
It took me a very long time to figure out how to configure my docker containers on my home server to have global IPv6 addresses. But I did it, and it taught me a lot about IPv6. I would personally prefer for the internet to be IPv6 only. It would make certain things much easier like firewall rules, IP whitelisting, and no more stupid CGNAT.
Considering in the UK you can get sim cards with 10GB or so of data for pennies I'm a bit surprised I don't hear much about people doing old school self hosted direct access stuff over ipv6.
Would there be much of a security risk if you had a dedicated device on its own network that doesn't actually directly communicate with anything else in your home?
I’ve taken to just disabling it.
I’d prefer to keep it on but every time I try it I run into a bunch of odd bugs. Silly stuff like GitHub container registry pulls being dialup speeds but docker.io being fine. Disable ipv6 and both at gigabit speeds. Bizarre stuff like that which I just don’t have the time and energy to go spelunking into the mysteries of dual stack to untangle.
(Out of the box opnsense)
you might be having issues connecting to faslty.
afk ghcr uses fastly and docker uses cloudflare.
The issue with IPv6 is that it's just too big; IETF overcompensated. Exponential growth really didn't occur "as planned" and addresses are barely readable to humans. 2^64 would have been better. That's something you can code using just 0-9 and no human will be forced to recite a never ending hexadecimal string.
> 2^64 would have been better. That's something you can code using just 0-9
That doesn't make any sense. 0-9 is base ten while 2^64 is base two.
I run a ghcr proxy server to avoid having to rent an ipv4 address just to pull the container images I build with github actions:
My services are often run behind cloudflare, who does ipv4 for me and proxies to my ipv6-only vps.Should you use this? Well docker's security model is pretty much only https, so it's like using a proxy server from some random hackernews comment for your `curl|sh` needs, without end-to-end encryption.
I wish github would just step up their game, at least for ghcr.io.
CGNAT is hard at scale, although very few operate it. On other hand IPv6 is easy.
What are you talking about? Tons of smaller isps use cgnat here in Canada.
No, not really. Please name those ISPs specifically in Canada.
Also my key point is 'hard at scale', in contrast to yours 'smaller isps'.
Try all major isps for one. Bell Telus Rogers. Just Google it and you'll find tons of people dealing with this problem as they discover they can't host anything because they're natted and unreachable.
I've lived in Canada for > 20 years in several cities and provinces. I'm telling you that CGNAT is extremely common.
I don't think you have any idea what you're talking about.
Neither Bell,Rogers or Videotron use NAT for residential internet - one is getting a global unicast IPv4 on their home routers. (Some locations are dual stack, like mine residential connection)
For mobile Bell uses 464XLAT. Bell mobility is IPv6 only network, also MPLS free, they are SRv6 early adopters, impressive!
Rogers, Videotron mobile use NAT44 for IPv6. IPv6 is native on Rogers.
I was most recently with EBOX (Bell reseller) and I was stuck behind CGNAT.
The fact is ipv4 is scarce, why wouldn't ISPs NAT their customers? Hardly anyone cares, and that's why they get away with it.
I'm now on Bell Fibe and it's a relief to be reachable again, but who knows how long this lasts. But yes at least Rogers is on IPv6...
EBOX is not using NAT, never was.
Happy that Bell Fibe is good for you!
Bell Fibe even has IPv6 in some markers even. ( EBOX has IPv6 everywhere on fiber for years )
EBOX support confirmed I was natted. Not sure why you want to argue this.
In the US, Metronet uses CGNAT. There's another local ISP which uses it. They use it because they're small, growing, and cannot afford enough v4 IPs. They also have no plan to switch to IPv6.
Same in India.
The big issue I've seen is that there are not clear wins for all the pain of IPv6. And the failure to provide a much much better ipv4 interop story out the gate (vs just trying to yell at everyone to switch) was a big big loss. So that means folks ended up having to run ipv4 to end devices in many cases and we have dual stack hell across the network.
For the 90%+ of network clients on-prem that play by the rules you are often supporting both DHCP and SLAAC on IPv6 networks (unless android has figured out DHCP).
Dual WAN redundancy on IPv6 in SMB settings is actually worse relative to a NAT and ipv6.
The subnet size /64 is stupidly large, and the number of available subnets you can easily get annoyingly small from most upstream providers.
Firewall filtering has to be modified or you get weird errors. People don't always like ICMP coming through the firewall.
It's does lots of things differently, but for what? We do prefix delegation with DHCP but can't use DHCP to assign address (we are supposed to use SLAAC) but still need DHCP for lots of other stuff? It's nonsensical - you end up with just way too much garbage.
The privacy extension stuff hits IPv6 hard. You have lots of auto-rotating addresses.
The number of times turning of IPv6 fixes weird glitches / timeouts / stalls etc is still crazy too me.
ATT (massive corp) requires end user devices request /64 subnets one by one - which most end user gear does not support.
Getting static ipv6 IP's (despite claims there are lots of them) is seriously hard from upstream providers in many cases - but IPv4 is trivial by comparison.
The list goes on.
I would have made the subnet size 32 bits. Expanded the network part. Maybe even reduced the overall size - 128 bits feel dumb with /64's as the smallest subnet? Then just go super high interop / overlay to IPv4 with great suggestions so folks could ship ipv6 only stuff (even with on device bridge to ipv4 so outbound interface is ipv6) and no new concepts unless clearly justified.
One thing I like about IPv6 is the lack of CIDR so that every IPv6 address always has the same 48 bit site prefix and then 16 bits of subnets and than 64 bits of host. It is easy to remember the 48 bit prefix and then you can actually just sequentially number subnets and hosts if you want so an address can be prefix:1:1 if you want.
One thing I hate about it is that they used 64 bits for host which is just absurd. 32 bits or even 16 bits would have been plenty for a single broadcast domain.
The 64-bit host space is used by SEND to hold a cryptographic key as part of a method of securing neighbor discovery. 16 or 32 bits would be laughably inadequate for that. It's also used as a passive defence against IP scanning, making it significantly harder for worms to spread by brute-force scanning.
I admit it does make the address space look a bit lop-sided, but taking bits away from the host side (where they're being used) and giving them to the network side (where we should already have enough space anyway) wouldn't be a sensible trade.
That is a clever hack made necessary by the lack of crypto as part of the IPv6 protocol like it should have been. If they were more ambitious they would have built something like the Locator/ID Separation Protocol (LISP) (RFC 6830) directly into IPv6 but used public keys as the ID.
In my career I have found IPv6 simply to be unnecessary. Running a network of 7 buildings with approximately 2,300 computers for now almost 2 decades and this is still true.
Setting edge routers to simply drop all ipv6 packets and running only ipv4 works, is simpler, is faster (than dual stack) and easier to troubleshoot.
I don’t have any inheritant issues with IPv6 other than is has failed to make a case for why people like me should bother rolling it out.
Imagine running a VPN hub for about ~800 customers that your IT people do remote administration for. We moved to this model because each customer tends to use their own preferred VPN agent, and multiple VPN agents installed on the same machine tend to fight each other to the death (and the host's).
To avoid ip-range clashes between customers, traffic inside the hub was IPv6-only, with each customer given their own prefix. Routing permissions were based on group membership, so we had a very easy and secure way to make sure each of our users was only able to reach their own customers, and personnel changes did not require any customer-side changes.
Although it sounds like keeping IPv4 is a reasonable choice in your situation, if you merge with another company (or otherwise connect your networks) that uses overlapping private IPs it will cause issues.
> , if you merge with another company (or otherwise connect your networks) that uses overlapping private IPs it will cause issues.
Wouldn't this be true with IPv6 as well, assuming that both companies happened to have chosen some overlapping ranges?
You don't "choose" your IPv6, they are assigned to you. Even if you used private IPs (ULA) for whatever reason, there are enough of those too not to conflict.
By comparison my company uses the entirety of the private IPv4 space. `docker compose up` often fails because there is no private IP range left that is not directed through the VPN.
For your use case is fine today IPv4. In my case, I would love to get rid of my CGNAT IPv4 ISP address and use only IPv6.
I've worked at companies big enough to start running out of private IPs. That isn't fun.
The github curl worked for me?
You're on an network with DNS64 and NAT64 as its IPv4 compatibility mechanism probably.
That's the worst part of the problem. Sometimes it works, sometimes it doesn't.
It didnt work for me.
If everyone supported it, IPv6 wouldn't be hard.
Working with IPv6 if you are not entitled to switch out every vendor, every piece of hardware, every piece of software that is lacking.. that's the hard part.
In short: reality is hard.
Off-topic but I'm curious why would someone purposely left-align a website? It makes no sense unless you're _really_ trying to avoid css which is not the case here.
I am SO tired of "is hard." I cringe every time I see this boring cliche.
It's a meaningless way of saying "look at me I'm smart." Everything is or is not hard depending on the audience and what it's being compared against. IPv6 is hard compared to Ethernet, but easy compared to managing a mess of NATs to handle V4 networks with conflicting addresses at different locations. All of this is a lot easier than understanding the leading proposed theories of quantum gravity.
> So in the case of the toot mentioned above there is an AAAA for the FQDN. But the connection doesn’t work. But the end user doesn’t notice. Because there is a browser feature called Happy Eyeballs (HE). Basically: A browser tries both protocols and uses the faster on. In case of non-working IPv6 IPv4 is always faster.
I mean even if there is no "Happy Eyeballs", it would still work for end users, no? Unlike `curl`, you don't specify -4 or -6 with browsers. Without HE, wouldn't (shouldn't?) it just try both in sequence?
> HE can have some funny side effects. In a project a connection to a development web server sometimes worked and sometimes didn’t. The solution was quite simple. The customer used a split VPN tunnel. IPv4 was routed via the VPN tunnel and those IPv4 addresses were allowed in the web servers access list. IPv6 was routed via the normal Internet connection and those addresses weren’t allowed.
This following sentence makes no sense, when the author literally said HE help it work when one IP family was broken and the other is not. So why would it work sometimes if IPv6 is consistently broken and IPv4 is not? (I'm not saying it won't happen; just that it shouldn't be "caused by HE" -- HE literally is the solution to this issue in general as the author said themselves!)
> I mean even if there is no "Happy Eyeballs", it would still work for end users, > no?
No browsers and other clients prefer IPv6 and there would be a rather long timeout till the client falls back and tries IPv4. If it falls back.
> So why would it work sometimes if IPv6 is consistently broken and IPv4 is not? > (I'm not saying it won't happen; just that it shouldn't be "caused by HE" -- HE > literally is the solution to this issue in general as the author said > themselves!)
IPv6 wasn't broken. For HE, an HTTP 403 is a valid connection. TCP handshake works, IPv6 works.
I had another case where the TCP handshake worked, and the browser decided to use IPv6 is good, but then came the TLS handshake, and it failed because PMTUD (Path MTU Discovery) was broken.
> If you don’t take it seriously, don’t do IPv6.
Which is why I deactivated IPv6 on almost every device in my network. My main issue is that the router/gateway provided by my ISP does not support DHCPv6 prefix delegation, which causes a couple of issues in my setup.
Sometimes you can try really hard to archive a goal, but when the workarounds to simple problems become new problems, it's time to say "no".
I thought traceroute always used icmp.
In theory it can use any protocol since TTL exceeded should work with any IP packet. I don't know if there's consistency between traceroute implementations so maybe some use ICMP and some use UDP.
Windows tracert uses icmp.
Depends on whether you mean the tool of the technology. Yes, the common traceroute uses icmp, but since it has become very popular for transit networks to ignore echo requests, there's also tcp (e.g. lft) and udp (e.g. Cisco's default) traceroute tools.
> So please: If you do IPv6 take it seriously. If you don’t take it seriously, don’t do IPv6.
Amen - replace IPv6 in the above aphorism with $anything, and it's a great rule for running projects.
So is CGNAT "real" ipv6?
Asking for a friend, like, what all the ipv6 use in the world is.
I'm curious. On the other side of CGNAT, you know, the mobiles, can they individually address each other, or can they only talk to each other through the CGNAT? I honestly don't know.
IPv6 is mainly only wanted by people whose job it is to track people. In any IPv6 discussion they yell, flap their virtual arms and gums and attack any non-IPv6 true believers.
ipv6 has this bullshit smell. bullshit, because it has this fucking useless naming convention (it's not for humans...) and overly complicated. like it was invented to muddle things about the internet, to raise the bar to understand it and hence coerce control. it resembles something that is not man made or deliberately made to be hard to use.
[dead]