It's kinda crazy how in CS, any random implementation-specific behavior is codified and relied upon.
As in, the design goal of NAT - sharing small number of external IPs by larger number of machines -- is best realized with what STUN calls "symmetric NAT". I am pretty sure the only reason full cone/restricted NAT type exists is performance, routers trying to keep translation table smaller for memory or CPU reasons.
And yet, based on router's internal implementation detail, there is now a protocol and an RFC and tools, detectors, software support, tutorials and so on.
This has less to do with CS and more to do with engineering constraints. Conflating the two is common but in this case it matters. Algorithms themselves are not system-specific. RFCs codify an idea and the people who write the code make the system specific modifications. In this case routers are bespoke enough still that standards are basically controlled by a few major players.
For the longest time home routers were coming with tiny amounts of memories. It was pretty easy to crash some of them by running P2P file sharing with connections to too many IPs
In many ways, the NAT classification scheme generated from the BEHAVE wg is a lot better. Splitting it in to "mapping" and "filtering" characteristics, and then indicating if each is "endpoint independent" or "endpoint dependent", with the latter having "address dependent" or "address and port dependent".
That then covers more than the simple, opaque, and inadequate terminology of "cones" used by the earlier RFCs. i.e. see https://www.rfc-editor.org/rfc/rfc4787
As to "implicit firewall", as has been indicated, there isn't really such a thing, just the filtering behaviour.
It is not uncommon for a CGNAT to have EIM and EIF, hence they're "full cone"; so that is what one will generally experience when tethering to a LTE/5G mobile network.
> As to "implicit firewall", as has been indicated, there isn't really such a thing, just the filtering behaviour.
I mean, there clearly is a firewall. If you buy a printer today, you don't really have to worry very much about how safe its network features are or if the firmware is updated, because if you put it behind a NAT router, it's not reachable from the global internet. Which is clearly a kind of firewall. And, generally, a good thing: it would be TERRIBLE for security if every shoddy network enabled device that anyone's bought for the last 30 years were reachable from the public internet. In the utopian "every device has a unique IPv6 address!", that would be the case.
It's true that an IPv6 gateway/router/whatever could have an explicit firewall that provides the same security, but the fact that this comes "by default" with a NAT router is honestly pretty nice for most users. And it's silly to deny it's an "implicit firewall", it clearly is. That's why I called the IPv6 version an "explicit firewall" two sentences ago.
The effect of EIM + EIF is that if a private port reaches out to somewhere on the Internet, then anywhere on the Internet can reach back to that port. So a port scan can find it. Off the shelf consumer NAT "routers" tend to have an "allow out by default" policy.
Now given the garbage one tends to find in the software of lot of off the shelf devices, the only way to ensure they don't "reach out to the Internet" is with an explicit outbound firewall, which prevents them reaching out.
A web browser these days opens so may connections, and is so vulnerable, that one should view those sitting behind a consumer NAT is not behind a firewall.
FWIW - My day job includes implementing and maintaining (i.e. writing the software) for commercial NAT and firewall devices.
> In the utopian "every device has a unique IPv6 address!", that would be the case.
No - every device would be routable. Routability is not the same thing as reachability.
This whole implicit / explicit thing is a bit silly. A DSL router doing NAT on IPv4 has a firewall, and a DSL router that's on IPv6 has a firewall. If you throw packets with an RFC1918 destination address at the WAN port on a router doing v4/NAT, it will drop them because of its firewall - nothing to do with NAT.
Absolutely not. NAT was created to help with the limited IPv4 space, and only that. The separation into routable wan and non-routable lan was a nasty side effect of this work around. IPv6 doesn’t have this issue, even though for some reasons it also has the NAT mechanism. Every device should be globally routable and the access should be policed by the firewalls.
> NAT was created to help with the limited IPv4 space, and only that.
Irrelevant. It's paramount that LAN operators should have tools for configuring LAN routing policies properly.
It so happens that NAT is the tool usually used for this.
(Not necessarily, though; we don't use NAT on the corporate LANs I'm responsible for, we have two interfaces and OSPF and wireguard to tie it all together.)
In a just and sane world IPv6 should have solved the tunneling problem so we don't have to rely on the myriad of incompatible and broken solutions just to bridge two network segments. Alas, we got the useless solution to a non-problem instead.
> Every device should be globally routable
That is literally insane, like I said. People who propose this should be banned from ever doing IT again.
> ...the access should be policed by the firewalls
Of course that too, but that issue is vastly less important than the routing issue.
> Irrelevant. It's paramount that LAN operators should have tools for configuring LAN routing policies properly.
It so happens that NAT is the tool usually used for this.
No, it is absolutely relevant. There is no “routing policies” enforced by NAT whatsoever. NAT has nothing to do with routing, it’s literally the address translation mechanism. Routing doesn’t change whether you’re using NAT or assigning addresses to devices within LAN from the provider’s network or your own PI range. There’s no “routing issue” in either case, the only meaningful difference is the LAN address range.
The only issue I can think of is using the provider’s range for LAN addressing - it will be unnecessary difficult to use multiple uplinks in this case. And having to renumber your network in case of provider change also quite a disadvantage. PI addresses and BGP peering with uplinks would be the right solution in this case (and getting your own v6 subnet is currently trivial).
> That is literally insane, like I said. People who propose this should be banned from ever doing IT again.
This is an amazing argument, thank you for that, I have immediately changed my mind after reading it. Also check the address of the cellular interface of your mobile, chances are it is in fact global, despite of your disagreement.
>That would imply that NAT is some kind of firewall. It's not. NAT doesn't block connections, so it's not a firewall.
I know. I am arguing with the people who think NAT is a good security mechanism. I called it an accidental firewall because without configuring NAT, you do not have a path from the Internet to a private network. I'm speaking on their terms.
>In the first place, NAT is something you apply to outbound connections, not inbound ones
Where in the literature did you read this? You absolutely can NAT in any direction you wish. Source NAT, Destination NAT, many-to-one NAT, 1:1 NAT, etc.
Source: multi-decade network and security engineer
I'm talking about the kind of NAT that everybody else is talking about here, the one you get in Linux by running "iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE".
It has "-o wan0" so it only applies to outbound connections.
> I know. I am arguing with the people who think NAT is a good security mechanism. I called it an accidental firewall because without configuring NAT, you do not have a path from the Internet to a private network. I'm speaking on their terms.
But you do normally have that. Your ISP gives you address space to use for your network and routes that space to your router, and your router routes it to your end machines. People far prefer using the Internet this way over using proxies.
Of course, if your ISP can't give you enough address space then you're stuck using RFC1918 (which is very common on v4, but it's hardly a normal way to run a network, just one you're forced into due to v4 being so exhausted.) The Internet won't be able to reach your network... but this isn't due to NAT because RFC1918 isn't NAT. It's not a firewall either because any inbound connections that do reach your network will work fine.
At this point, you'll add NAT so you can actually make working outbound connections. This is the opposite of a firewall. Your ISP will still be able to connect in too.
If you really wanted to, you could add NAT even when not using RFC1918. Any inbound connection that worked before you added it would keep working afterwards.
Having or not having NAT doesn't make any difference on who can connect in. That's why it's not a firewall, accidental or otherwise.
I wish there were IP successor which would _only_ expand address space and not redo everything network-related. Increasing size of some structs and recompiling software is easy. Re-doing entire address allocation logic, address splitting, and network administration approach is much harder, as it affects millions of customized setups.
Oh well, too late for this now. I guess this is the lesson for future network protocol designers: small, backwards-compatible changes will have much higher chances of working. And saying "you must drop old thing entirely and redo everything from scratch" means it'll take more than 30 years for your protocol to be deployed.
It's impossible to implement a backwards-compatible successor to IP without breaking the principle that every node can address other node.
Old nodes will have no idea how to address "new" ones, and if you want actual communication to happen, then addressability needs to function in both directions.
(You've also glossed over the fact that so much hardware assumed that an IP address was an int32. Swapping that out was always going to take a long time).
If it was just a simple expansion you could have had a deadline for a switch over date. For example, on 1999-1-1 00:00:0.000Z stop using 32 bit address, and roll over to a 64 bit address. This is what happened when the internet switched from NCP to TCP.
But, since it's not just a simple expansion of the address space and it fundamentally does things differently, this is impossible. And we've been stuck in limbo for about 28 years now.
It has been more almost 30 years now, multiple generations of devices (and OS'es) have happened. If the only problem was low-level network stack support, it would have been fixed.
There is nothing impossible about designing compatible system, if the compatibility is your goal. Let's think about "simple address expansion" - there is a "IP-long" ethertype which is used with IP addresses longer than 32 bits; and all code is structured such that if IP address fits in 32 bits, then old IPv4 packets are used. All apps are hardcoded to use a single address family (IP-long), but as if you are running in IPv4-compat mode, only last 32 bits of address would be nonzero.
ARP has PTYPE field, and arbitrary address length already. It could have worked with "IP-long" schema with minor changes (for example to send parallel requests for compatibility). We could have IP-long capable devices operating in IPv4 compat mode for years.. until one day the assigned address changes to be longer than 32 bits and now the new protocol is in effect. Since majority of kernel code would be the same for IPv4 and IP-long packets, there was a good chance it would "just work".
Sadly, this cannot happen with IPv6, because they made an explicit decision to break compatibility, and so they got rid if ARP. Note there was nothing "fundamental" that required they did so, they just didn't like it.
For DHCP, we could have an all-new option, "client supports IP-long". Old DCHP servers would ignore it and return regular IPv4 address. New DHCP servers would return IP-long allocation to supported clients, and could optionally return "compat" record to IPv4-only clients (possibly with packet-translating gateway). We could have a network where you can mix and match clients, and enabling longer address would be as simple as creating a new private IP pool in the DHCP config with longer IP addresses.
Sadly, this cannot happen with IPv6, because they made an explicit decision to break compatibility, and so they made a different IP allocation mechanism. And also NATs are heavily deprecated so "create a new private IP pool" makes no sense either. Note there was nothing "fundamental" that required new addressing mechanism, IPv6 designers just wanted to start from scratch.
DNS actually works pretty well, obviously you'd want another record type for IP-long addresses but adding new record type is a known process. The only reason DNS is hard under IPv6 is because of "happy eyeballs" and all the non-working IPv6 deployments.
ICMP could use the same treatment as ARP, that is has IPv4-comaptible versions and "long" versions for long addresses. We could have a single ICMP stack in the kernel and all the tools, with the only long-aware changes being in network packet decoding code.
Sadly, this cannot happen with IPv6, because they made an explicit decision to break compatibility, and so they stuffed all sorts of things into ICMP protocol (ARP, IGMP, etc...).
I mean it’s all probably true, but how would it be easier to migrate to long ipv4 than to ipv6? Looks like there’s basically the same struggle, no? I think the major part of the migration problem is the global routing - the new protocol should be implemented in hardware, in ASICs and route processors. The LAN part of the migration is likely the easiest. And if it’s true, breaking compatibility and introducing a completely different protocol was probably well justified. IPv6 solves some other problems aside of the address space exhaustion - see SLAAC, easier route summarization, simplified packet header. That would not have been resolved by simply increasing the address space for v4.
Is global routing really the problem in 2023? Anecdotally, its the end user's service which is hardest to migrate, and specifically all
If end user wants IPv6 in the office, but their ISP does not support it, enable HE (or some other one) tunnel on router and you done, here is a few dozens more IPv6 hosts generating traffic and increasing IPv6 fraction. If ISP wants everyone to use IPv6, but end users do not support it... well, ISP can do whatever but the traffic should eventually emerge as IPv4 and there would be no forward motion.
I know a few places which still use IPv4 and have no plans for IPv6 -- my work's DC network, my work's office network, my home network, etc.. The reason they are are still on IPv4 have nothing to do with global routing or hardware support (everything is on a fairly new software), but rather all the unrelated changes IPv6 has bundled with longer addressees such as SLAAC.
Do you know of any networks which are still on IPv4? What is their sysadmin's motivation?
I don't think so, why? I was talking about migrating from v4 on the day 0, when every single ip-speaking device used v4 only. My point was that on day 0 the main problem was global routing, because the new protocol should have got hardware support and all the network equipment should have been replaced. Local networks migration is much easier to do.
> Do you know of any networks which are still on IPv4?
I managed networks for around 15 years, up until 2018 and I've never managed an IPv6 network in my whole career. My current company (a well-known company from SF) runs v4 only network. I think the question should be different: what is the motivation for sysadmins and the business to migrate to v6, if v4 runs perfectly fine? And the answer is - there's basically none.
Oh, I don't think "day 0" migration would ever be possible.. but with less breaking changes it could have taken 10 or 15 years instead 30+. And then no one would care about IPv4 shortages anymore for example.
The companies change stuff all the time - there is new software, there are new protocols, new hardware. For example, I remember setting up QoS/DSCP once because I _thought_ it might help with ssh sessions (it didn't). My current company routinely has cleanup/general improvement projects, to both improve network and keep network engineers happier. And given the amount of noise about IP shortage, we'd definitely consider IPv6 migration _if it only wasn't so damn expensive, time-wise_.
That might well be true! It just doesn't seem to be possible. There's no point wishing for fewer breaking changes when the one thing you're doing all of this for -- longer addresses -- is the thing causing the breakage.
I don't think any of your IP-long suggestions would reduce the time you needed to deploy v6. If you disagree... perhaps v6 wouldn't actually take you as much time to deploy as you're imagining it will.
They didn't explicitly decide to break compatibility. They actually put a lot of effort into maintaining it; the breaks in compatibility are forced by v4-only software/hardware/protocols. Unless you have some way to deal with those, you can't improve compatibility over what v6 already does.
> There is nothing impossible about designing compatible system, if the compatibility is your goal. Let's think about "simple address expansion" - there is a "IP-long" ethertype which is used with IP addresses longer than 32 bits; and all code is structured such that if IP address fits in 32 bits, then old IPv4 packets are used. All apps are hardcoded to use a single address family (IP-long), but as if you are running in IPv4-compat mode, only last 32 bits of address would be nonzero.
This is basically IPv6. It has its own ethertype, and software can be hardcoded to use v6 sockets only, with v4 addresses being represented by e.g. "::ffff:8.8.8.8". Using addresses with that prefix generates v4 packets, and IPs outside of that prefix generate v6 packets.
But how do you handle software that doesn't support it? That's where the compatibility gets broken, and you didn't propose anything to help with that.
> We could have IP-long capable devices operating in IPv4 compat mode for years.. until one day the assigned address changes to be longer than 32 bits and now the new protocol is in effect. Since majority of kernel code would be the same for IPv4 and IP-long packets, there was a good chance it would "just work".
Yes, this is IPv6 again, you can absolutely have v6-capable devices working in v4 compatibility mode for years, and then you can stop assigning v4 on the network and start assigning v6 on it to cut over to the new protocol.
But again... how do you handle devices or software that don't support it? Addresses longer than 32 bits will never "just work" with v4-only stacks. It's just fundamentally not something they can do. And most kernels already merge most of the code in their v4 and v6 stacks, so that's not a new suggestion.
> ARP
You're right that ARP could have been used for v6, but doing so wouldn't have made v6 any more compatible with v4 devices because those devices couldn't handle the new PTYPE or the addresses in it. (It would have saved people from needing to write NDP implementations, but how many people do you know who are blocked on deploying v6 because they need to implement NDP?)
The compatibility problem was imposed by v4 devices, so it wasn't an explicit choice in v6. It did present an opportunity to use something other than ARP though, which we took not because somebody didn't like ARP but because it fixed a problem we were having: ARP doesn't scale to network segments larger than a few thousand hosts due to all the broadcast traffic, which was a limiting factor in network size. You might think "nobody runs VLANs with more than a few thousand hosts", but... this is the reason they don't.
> DHCP
Fun fact: DHCP was released at around the time v6 was in development, and it wasn't ubiquitous on v4 networks until the late 90s. DHCP seems like the obvious choice to you now, but at the time v6 was being developed it wasn't popular.
v6's main autoconf was based on things like IPX (which was considered much easier to configure than IP), so they weren't starting from scratch. This wasn't breaking compatibility so much as not knowing what to be compatible with.
Using DHCPv4 options to configure v6 machines wouldn't have made v4 and v6 any more compatible though, because you still have the issue of v4 machines not being able to handle v6 addresses. You can already mix and match clients on a network with v6, but how can you expect the v4-only ones to talk v6? Mashing the config protocols together wouldn't change any of this.
Re hardware: Maybe it was the case in 2000, but how all virtually all hardware have a capability to support IPv6. Even $3 ESP32 microcontrollers do so. They just don't enable that capability.. why? see below.
Re backwards-compatible: we have no problems upgrading other protocols (like TLS or SSH) while keeping some amount of backward compatibility. The procedure is known: (1) create software which talks both old and new versions, auto-selecting right one (2) start deploying, initially in compatibility mode (3) once a very high fraction of devices are upgraded, start cutting off old versions.
IPv6 could have been the same. Make it use IPv4-like IP address formatting, and change network stack to emit IPv4 packets for ::ffff: addresses - this'd allow changing application software painlessly: the packets are IPv4 on the wire, but apps already use IPv6 code. Next, recommend that every router has some sort of SIIT translator by default: now you can mix and match IPv4 and IPv6 devices on same network (the performance might suffer but at least things work). Eventually you could go full IPv6, and then finally drop that NAT in the router.
But no. One of the large goals of IPv6 was to "simplify everything" so such solutions would be unacceptable. Everything that could be used to ease IPv4 transition was extra complexity, so this information is hidden and left for special circumstances only. IPv6 is a shining example what happens when people want to design nice, clean system without backwards compatibility.
Take your post for example -- you are outright saying "it is impossible [...] without breaking the principle that every node can address other node." and it is correct.. but how often do you have full node-to-node communication? Things like NAT64 can help you transition, but try finding it in a beginners example.
> Re backwards-compatible: we have no problems upgrading other protocols (like TLS or SSH) while keeping some amount of backward compatibility. The procedure is known: (1) create software which talks both old and new versions, auto-selecting right one (2) start deploying, initially in compatibility mode (3) once a very high fraction of devices are upgraded, start cutting off old versions.
The IP stack is nothing like TLS or SSH. Besides, step (2) in what you're describing is what we have today, and is called dual-stack. Pretty much all software today can communicate on sockets with v4 or v6 addressing, and the vast majority doesn't actually care.
> Next, recommend that every router has some sort of SIIT translator by default ...
"Simply draw the rest of the owl". I have a sibling comment where I explain why it's not as simple as just "translating the packets in the router". You need a solution to how most of the protocols that underpin the internet are going to work (ARP, DNS etc.) because they historically were all very tightly coupled to IPv4.
> But no. One of the large goals of IPv6 was to "simplify everything" so such solutions would be unacceptable. Everything that could be used to ease IPv4 transition was extra complexity, so this information is hidden and left for special circumstances only. IPv6 is a shining example what happens when people want to design nice, clean system without backwards compatibility.
Simplifying things is a laudable goal. If you're designing a replacement for something, once you realise that backwards compatibility is impossible, then you then have an opportunity to fix some things to make them better (e.g. neighbour discovery, routing). IPv6 is not perfect by any means, but given the enormous task, complexity and competing constraints, I think they did an ok job.
Pace of adoption is entirely an economic issue, not a technological one. There's no change without incentive: the carrot was never particularly big and until recently the stick was non-existent.
> but how often do you have full node-to-node communication? Things like NAT64 can help you transition, but try finding it in a beginners example.
I use full node-to-node communication every day. It's the bedrock on which the internet functions. Also, I managed to get NAT64 working by fiddling with my DNS server (unbound) and installing jool on my router. Took me about half an hour.
I've replied about protocol compatibility in the other thread. Here, I'd just say:
Yes, simplifying things is a laudable goal -- but so is keeping things compatible. You need to choose a right tradeoff here, if you want your system to take less than 30 years to deploy.
As a very concrete example: there is no reason that having 128-bit addresses should means your usual node now has half a dozen of them, per interface. It was someone's personal idea, which would normally be completely ignored, but this time it was merged into larger proposal that promised something people wanted.
I remember in the early-mid 90s, I would read many of the foundational RFCs, the ones which became STDs, etc. and down at the bottom, there is always a section labeled "SECURITY CONSIDERATIONS", and every last one says in a single line, "Security considerations are not addressed in this memo."
That's pretty much what v6 is. The other proposals were significantly different to v4, but v6 works almost exactly the same as v4 does.
It's also backwards compatible with v4 in pretty much every way that you can be backwards compatible with v4. It's not v6's fault that v4 isn't forwards compatible with bigger address sizes.
> Increasing size of some structs and recompiling software is easy
This turns out to not be so easy. People are STILL writing new code with "struct sockaddr_in" allocations and "socket(AF_INET, ...)" and crap like that. That's the main thing blocking people from moving from dual stack to v6-only today.
This could be true in 2000, but its 2023, all major software (and hardware) has IPv6 support. And yet my work's office and DC networks are IPv4 only and have no immediate plans for transition. Why? Some of the reasons:
- IPv4 and IPv6 are treated as completely separate things. So tunnels, firewalls, etc.. need to be configured twice if you want both IPv4 and IPv6 support. Any IP-related settings or database fields must be duplicated. (Linux didn't help here with iptables6 being completely separate; neither did FreeBSD by prohibiting combined ipv4/ipv6 sockets).
- Best practice in IPv4 is single internet-capable address per machine. Best practice in IPv6 is multiple internet-capable addresses per machine, and sometimes they also dynamically change. This means all the logic which assumes "machine's IP address" need to be rewritten.
- Usual practice in IPv4 is NAT + private IP ranges, which completely hides internet provider's IP allocation. Usual practice is IPv6 is "leaking" ISP-provided data to every end station.. if you get a new ISP, you get to renumber all the device and change every hardcoded IP.
- Address format is different - all the logic which touches IP address needs to be updated. And .split(":") is no longer going to cut it.
... etc.. there are tons of reasons which are not related to "struct sockaddr_in".
(One interesting observation is at lot of it is "best practice" or "implementation details": technically IPv6 is flexible enough to operate in IPv4-like mode... In theory, one can build IPv6 network on fixed addresses allocated by DHCP that uses NAT for internet access, so that existing tooling is preserved. In practice, of course, attempting to create such monstrosity will get you laughed out of the meeting.)
When you've invented something better you can also invent a time machine, take a trip back half a century and cause everything to be done the right way from the very start.
> Doing things properly would cost money. Nobody is willing to pay. So nothing will ever change.
That's not a fair characterization of the problem:
Unless everybody switches at the same time (~impossible), IPv6 requires paying for both stacks until the migration is complete. That's simply not economical, and not everybody on the internet can afford to disregard economics that way.
I'm also running IPv6 on all my hobbyist projects, but I really can't blame anyone that doesn't.
It's a game theory problem: nobody wanted to foot the bill on their side, endlessly punting and waiting for others to foot it for them.
End result is that now everyone foots a different, worse bill, yet will still have to foot the previous bill because the workarounds have their limits when the attrition game pans out.
Hobbyists: "Wanna do IPv6? It's cool and we'll do our part for incentivizing people to also switch! It should only take a couple of Saturday afternoons." "Sure, sounds cool, let's do it!"
Meanwhile, at any average corporation: "Ok, so implementing IPv6 will cost us x$ and n person months, got it. And the upside is that we'd get a badge on some IPv6 readiness site, yes?
And what would be the consequence, for us, of not doing this? Interesting, absolutely nothing you say, at least until every single customer is at least on IPv6 dual stack, since we need to provide our existing IPv4 stack too? Cool, thank you for presenting, please don't come again!"
About the only large commercial entities that see any benefits of rolling out IPv6 are eyeball-heavy ISPs (since selling native IPv6 + CG-NAT for IPv4 is a slightly less horrible proposition than selling CG-NAT alone), and much less importantly any entity so large that CG-NAT capacity (memory and assigned IP/port tuples) is an issue for them.
And no wonder they think that when they ignore all of the benefits of doing v6 and only look at the costs _and_ ignore all of the costs of staying exclusively v4.
If you have a web store, subscriptions or ads, you'll have conversion metrics. Even small changes in your website's page load time (just hundreds of milliseconds) can have noticeable impacts on these metrics, and therefore on your income. Facebook say they see 10-15% faster page loads[1] on v6, so not having it is costing you money.
If you don't have v6, you have to do everything on v4. In practice that inevitably means dealing with RFC1918 and NAT, which means dealing with split DNS, VPNs, RFC1918 clashes and cross-NATing, and all the other problems which come with all that. That costs engineer time and therefore money.
Most companies don't even know how much these two points are costing them. How can you balance this against the cost of doing v6 when you don't even know one of the values you're balancing?
Most parts of v6 deployment should happen as part of your regular work: you shouldn't need to replace equipment specially for v6 because you should be buying v6-capable equipment as part of normal procurements, and you should be configuring v6 when you configure v4, and so on. So why is v6 deployment its own special project with its own budget, when the costs of v4 are rolled up into your regular budget and treated as if they're zero?
Put all of this together and you end up with an incredible and unjustified bias against v6.
> they ignore all of the benefits of doing v6 and only look at the costs _and_ ignore all of the costs of staying exclusively v4.
Nobody is ignoring all costs. People are just mostly interested about costs incurred by themselves only. This can and often does yield globally suboptimal outcomes. Not sure what exactly the game-theoretical term for this is.
> Facebook say they see 10-15% faster page loads[1]
This is quite surprising! Is there any explanation for this observed behavior? Are there saturated v4 paths that have a less congested v6 alternative? Are CG-NATs adding that much latency?
> If you don't have v6, you have to do everything on v4. In practice that inevitably means dealing with RFC1918 and NAT, which means dealing with split DNS, VPNs, RFC1918 clashes and cross-NATing, and all the other problems which come with all that. That costs engineer time and therefore money.
I think you're thinking about the eyeball ISP side here; I was mostly talking about the data center/cloud side of things, where the situation is quite different: As long as there is a non-negligible customer IPv4-only user base, you need to be dual-stack, which will always cost more in terms of management than IPv4 or IPv6 only.
For eyeball ISPs, as I've mentioned in my post above, the economics can indeed be different: If they're IPv4-contrained, they'll probably need NAT anyway, and 464XLAT can make that significantly easier than doing IPv6-only CG-NAT, while also providing native IPv6 connectivity.
Put together, this yields the following game-theoretical situation:
- On the eyeball side, you need IPv4 (either natively or increasingly commonly via some version of CG-NAT) for IPv4-only services. You can add IPv6 for more efficient connections to dual-stack servers, and many eyeball ISPs already do. 464XLAT or DS-Lite make CG-NAT more scalable (some ISP networks are too large to fit into a private /8 network!).
- On the server/hosting side, you need IPv4 (for IPv4-only eyeballs), and only IPv4 (since there are practically no IPv6-only eyeballs). You can add IPv6 for a bit more performance, but you need to be dual-stack capable, for the IPv4-only eyeballs which you can't afford to lose.
The result is: The largest players support IPv6, yet we might well be stuck with a long tail of IPv4-only properties for the next decade or more.
> This is quite surprising! Is there any explanation for this observed behavior? Are there saturated v4 paths that have a less congested v6 alternative? Are CG-NATs adding that much latency?
I can give a few theories. Some CGNAT setups do add a lot of latency (e.g. T-Mobile hand v6 traffic off locally where possible but v4 has to be hauled to one of their CGNAT installations, which might be a long way away). Some CGNATs are outright overloaded. v6 doesn't have a checksum, so routers don't need to update the checksum when they fiddle the TTL header. NAT must add some latency too.
A "page load" involves lots of round-trips, so even a very small difference in round-trip time can add up to make a bigger difference in page load time. (This does suggest that improvements to HTTP and rate control algorithms to reduce the number of round-trips would narrow the difference.)
> I think you're thinking about the eyeball ISP side here
I was thinking about "company internal" networks, both their own internal networks but also the internal parts of their hosting setups.
In hosting, it's generally true that you need to handle v4-only clients... but that can be handled entirely at the edge by your load balancers or by NAT46, it doesn't force you to use v4 inside at all. You can use v6 inside, and it'll be easier and cheaper than v4 for the reasons I mentioned.
> we might well be stuck with a long tail of IPv4-only properties for the next decade or more
NAT64 can handle the long tail of v4-only websites for v6-only clients, so this is actually okay. It's not blocking deployment of v6 or undeployment of v4. The only real problem it causes is that people use it as an excuse to not do v6...
Well said – and it's mutually reinforcing excuses, even: Hosters don't need v6 because eyeballs support v4 anyway (through NAT); eyeballs don't need IPv6 because there's no v6-exclusive content.
But I suspect that that'll resolve at the very latest when v4 exhaustion starts hurting hosters (and maybe ISPs, they still need a few for CG-NAT after all) in earnest.
And once ISPs run out of internal v4 space and switches to v6 for that, there's no point in not just supplying public v6 addresses as well.
> Are there saturated v4 paths that have a less congested v6 alternative?
Every time I saw that kind of gain, it was mostly due to slow DNS and browsers or caches preferring IPv6 data.
The entire internet needs to optimize for one of those, as they some times conflict. And the obvious one to optimize for is the one that will keep working in the future. But those conflicts tend to be on accidental features at the margin; there is a small amount of problems caused by the large routing tables of IPv4, but on the main networking problems they were designed to behave almost the same.
Who is appreciating these bandaids? Are you talking about the fact that NAT has a defacto inbound firewall? It would be pretty easy to implement that firewall without a NAT.
There's two different ways of looking at the internet.
The greybeards philosophy is how it initially was. There aren't multiple networks, there is supposed to be ONE network, THE internet with ONE global address space.
The philosophy of those who grew up with NAT, who think that sounds insane. The internet is just the glue network between heaps and heaps of separate networks, each with their own, enclosed address space. Why would you want all networks to be one network, why should your printer have a globally-unique globally-routable address?
The two different philosophies don't tend to get along.
You can still have unique addresses and private networks. For things that shouldn't be globally routable give them a unique internal address. For things that should be give them a unique public address. It still makes things simpler to not have the NAT.
The whole point of using NAT is that you want to be part of the one network but can't get enough address space for your bit of it. If you didn't, you wouldn't even have routing to the Internet in the first place and therefore would have no need for NAT.
It's perfectly fine to run a separate network. You can do that and still access Internet hosts easily by having one machine that's on both networks and running a proxy on it.
But nobody wants to do that. Almost everybody actually wants to be able to route to the Internet and back, so they set a router up to join the networks, and then (on v4) they have to NAT because nobody will give them enough v4 space for their network.
Unfortunately there's a severe lack of understanding of basic networking concepts and of what routing and NAT are doing, even in people who work in the field.
Yes, and literally the only reason I have a router is to make my LAN devices behind it unroutable from outside. (It says so in the name "router" itself.)
That doesn't make any sense, because if you didn't want anybody from outside your network to route packets onto it, why not just not have the router?
You actually do want your LAN devices to be routable from the outside, because you want them to be able to talk to Internet hosts and you want those hosts to be able to reply. That's the real reason you have the router.
What you probably don't want is for people outside your network to be able to initiate new connections to inside of it, and that's something you get with a firewall, running either on your devices or on the router.
NAT only comes in to any of this if your ISP can't issue you enough address space to use on your LAN, without which your network won't be routable even with a router in place. NAT is the big hack to try and get routing to work without sufficient ISP-assigned address space. It's not needed for anonymity or for getting a single point of control.
> You actually do want your LAN devices to be routable from the outside
I do not. I certainly don't want the internet to know how many devices I have and what they are. Traffic to and from the LAN should be anonymous. As far as the internet is concerned, my LAN is a black box.
> It's not needed for anonymity or for getting a single point of control.
NAT used that way usually, because other solutions are lacking or too expensive, and because the people who invented IPv6 didn't bother trying to solve real problems.
At the very least then, you need it as a prerequisite for something else that you want. Or perhaps I'm assuming too much about your network here. Let me double-check: do you use NAT? You've said things about it, but do you use it on your network?
NAT applies on top of routing, so you can't use it without routing. If you're using NAT, then you've made your devices routable. Whatever you say about not wanting to do that, you did do that, so it must have been preferable to you in some manner or another.
I know this would contradict your claim that you only have a router to make your network unroutable, but that claim never made any sense in the first place. It's the job of a router to make a network routable.
> NAT used that way usually, because other solutions are lacking or too expensive, and because the people who invented IPv6 didn't bother trying to solve real problems.
Nobody is using it to get a single point of control. In order to NAT you need to set a router up, which means you already have a single point of control. There's no need to also do NAT and it won't help either, so it's not being used for this.
It's not usually being used for anonymity either, because most people using it only have a single IP address in the first place and that's the one all their NATed connections appear to come from. They get no anonymity from NAT.
The people who invented v6 did bother trying to solve real problems. But getting a single point of control was never a real problem and didn't need solving; the real problem was the lack of address space, which they did solve.
Actually that isn't quite correct. A router is needed to route packets both directions, in your case and in a no-NAT scenario. The ISP could make everything a flat L2 network between consumers (you'd plug a switch into your ISP handoff), but that would be a bad idea on a lot of levels.
> None of that was needed, but why make a proper fix when you can instead do a series of band-aids?
It was needed temporarily until we got more address space.
The original NAT RFC 1631 (later 3022) was released in 1994:
The huge advantage of this approach is that it can be installed
incrementally, without changes to either hosts or routers. (A few
unusual applications may require changes). As such, this solution can
be implemented and experimented with quickly. If nothing else, this
solution can serve to provide temporarily relief while other, more
complex and far-reaching solutions are worked out.
The only instances of IPv6 NAT I've seen are situations like "I have only a single IPv6 address available but need to run a VM/a Wi-Fi hotspot/...", and arguably that's a completely different matter than "I have full control over my network, but I simply can't request the address space I need because there's none left".
Practically, I've not encountered it myself. I was recently surprised to learn that even when tethering from my iPhone, client devices receive a public IPv6, so apparently mobile networks assign more than an /128 address to even single-line customers.
On fixed-line IPv6, I've also never encountered any less than an /64 network.
/64 is not enough if you need to run two networks (e.g., a guest WiFi in addition to the main one). And yet, here in the Philippines, an IPv6 subnet larger than /64 is an enterprise-only feature that is denied to home users.
You can subnet /64. You'll just lose SLAAC. (+ some idiocy around some devices that refuse to implement both DHCPv6 and manual setting of IPv6 addresses)
That's interesting. I've been tethering for years using Android phones, and using a 4G standalone router. I've never seen a client be allocated any IPv6 address in either case. I know the phone gets one for itself, but I don't think the router does. Looking at the phone's IP address status, it is given a non-public IPv4 by the mobile network (so CGNAT if it uses it), and what looks like a single IPv6 by the mobile network.
I worry about the loss of the implicit firewall that NAT offers.
Network security audits of dual-stack networks far too often show practically no open ports on IPv4, because of NAT, while IPv6 exposes everything. The security through obscurity of the practically unscannable IPv6 address space is not a firewall.
> but the default configuration on many ISP-supplied routers has no firewalling beyond what NAT offers
Repeat after me: NAT does not provide firewalling in any way.
What you think as 'firewalling' is just inability to route packets to your LAN[0] for someone further than your immediate gateway and this is true only until you have no active inbound NAT sessions.
If for some reason there is a session what allows anyone to contact the machine on your LAN (ie Full Cone NAT) then... anyone can contact your machine behind the NAT. I'm not sure there any router or appliance what would do that automatically anymore (because by default outbound session would create a thing called Address and Port Restricted NAT in TFA) but it's quite easy to do this by misconfiguration or some automatic mechanism, like UPnP.
If the problem is in the 'default configuration of many ISP-supplied routers' then you really should address that and not treat NAT as a firewall.
And last, but not least: every modern OS comes with a built-in firewall. Even Windows' one is pretty decent to block anything not explicitly allowed. There is no network scanning in IPv6, it's pointless or requires to sit on the wire to listen for NDP - and at this point NAT wouldn't help, too.
[0] or sometimes the packets are routed pretty fine in, it's just the absence of the state and/or proper rules what forbids the answer to be routed back. If you ever needed to troubleshoot an assymetric NAT you would know this.
ADD: this should had been a reply for your further comment, of course, but I leave it here.
The scenerio I commonly see is a dual-stack (IPv4 & IPv6) router blocking all unsolicited incoming IPv4 packets (because of NAT), while all IPv6 LAN hosts will unintentionally be globally accessible through the internet.
This is why I worry about more IPv6 deployment. Too many people are ignorantly relying on IPv4 NAT as a layer of protection.
> Too many people are ignorantly relying on IPv4 NAT as a layer of protection.
Too many people think pulling out works every time, too many people think what not using the seat belts because they aren't going far or fast is safe, yada, yada.
What the attack scenario? For the most part the machine is firewalled anyway by built-in firewall (if we talking about any modern Windows and Linux) by default. Most attacks need the actual vulnerable software and this is the browser nowadays => it's client initiated anyway.
Sure, a properly configured router would block the incoming traffic (with or without NAT, there are routed IPv4 too, you know? I have five /24 there and a bunch of smaller ones, no NAT on them), but again, the onus here on the default configuration of the router. There are still 'DMZ' buttons in some routers what would DNAT everything to the machine, there are people who do that without understanding what this opens up their machine (despite being behind the NAT) ie 'make it globally routable'..
I didn't touch home/soho routers for almost a decade so I can't say anything about that, except what Zyxels have the sane defaults and what Mikrotik is shipped with IPv6 disabled altogether.
Don't forget, most of the 'hacks' are happening by scanning the IPv4 subnet and then meticulously probing everything. It's easy with IPv4 (hell, /16 is only 65k hosts), with IPv6 this is...
Here: 2a10:1fc0:6::/48
I have a machine there, go, find it.
The only feasible way for someone to find your globally addressable machine is for the 'victim' is to first trigger something, eg by accessing some website. Yes, in this case the owner of the site (or the malware which infected the site) would know your IP. But same applies to IPv4 and in both cases you need something which is:
vulnerable
accepting packets from anywhere
not firewalled
And you still need to lure the victim to your site first.
You would have more chances with sending Nigerian prince letters and you would be way more profitable.
> And you still need to lure the victim to your site first.
You don't need to lure anything. Hack some websites. Plenty have publicly accessible analytics or logs. That gives you full IPv6 addresses to target. Ideally, it might give you a username as well.
What if someone gets the logs of an IOT cloud provider with IPv6 enabled IOT devices?
How many of those addresses have SSH, Samba, APFS, Telnet, or a DNS server running? How many have a username + password combo that's in a leak? How many have an IOT Restful API endpoint with unpatched vulnerabilities?
IPv4 NAT allows people to have quite weak security internally in a network, and not get compromised. Device firewalls don't work where the devices themselves provide services, which is increasingly common.
Right. For example, in 2016, Shodan had sneakily infiltrated the NTP.org pool to harvest IPv6 IPs. The methods have obviously gotten more sophisticated and more prevalent since then.
> IPv4 NAT allows people to have quite weak security internally in a network, and not get compromised
DENY from ANY to ANY
on the WAN port works with both IPv4 and IPv6 and allows people to have a strong security internally in the network.
Here, one simple solution, works on both IP versions, does not rely on NAT or hoping everything would be fine.
> How many of those addresses have SSH, Samba, APFS, Telnet, or a DNS server running?
Ah, yes, some idiots have the telnet and APFS running and open to the whole world that's why NAT to the rescue! Instead of, you know, having a brain and, at least, firewalling. At The Router.
You all NAT apologists somehow do have the router with NAT and firewall for IPv4, but at the same time there is only luminiferous æther for IPv6 with nothing between the poor, young and defenseless IoT device and the 3vi1 h4x0r somewhere on the other side of the planet. Come on.
> What if someone gets the logs of an IOT cloud provider with IPv6 enabled IOT devices?
What if someone gets in your house and find your nudes? Should we ban cameras everywhere, because someone might do that?
Thanks to privacy extensions most of those logged addresses will have expired and be useless. Also most people don't permit connections from the Internet to privacy addresses in the first place, they only add firewall exceptions for the base addresses, so even if you're running a server on the same machine you make an outbound connection from, the servers you connect to don't learn the IP needed to make an inbound connection on.
> IPv4 NAT allows people to have quite weak security internally in a network, and not get compromised.
No, it doesn't. This is allowed by having a firewall on the router, exactly the same as in v6. NAT doesn't block connections, so it doesn't contribute to this security.
Device firewalls do work, but connections will generally be rejected by the router's firewall before they even get that far.
> I worry about the loss of the implicit firewall that NAT offers.
... NAT does not offer 'implicit firewall'
It's just what Average Hacker somewhere on the net can't route easily into your local network. If this is no longer an Average Hacker or he is sitting on your wire then the only thing what your NAT 'offers' is your false sense of security.
And by the way, nobody, noone forbade you from having explicit firewall rules denying anything from anywhere, not explicitly allowed. Just like it is done in a proper IPv4 configuration.
> And by the way, nobody, noone forbade you from having explicit firewall rules denying anything from anywhere, not explicitly allowed. Just like it is done in a proper IPv4 configuration.
Sure, in a perfect world, migrating to IPv6 should be safe, but the default configuration on many ISP-supplied routers has no firewalling beyond what NAT offers.
I won't say there aren't ISP routers without firewalling, but for the most part they're pretty decent at having it. It's just that the firewalling is a completely separate thing to NAT.
Essentially, most NATs are symmetric, with some port forwarding rules, which operate in Full Cone mode.
More interesting questions are "what happens when there's multiple NAT IPs?" "how long do the symmetric rules stay around for?" "what keeps them around?"
At least most home routers (on connections that still get a public IPv4 address) are fortunately not symmetric, or STUN would not be working with them. (STUN only works if at least one endpoint is port-restricted or better, if I remember correctly; it might also have been both ends.)
Many carrier-side NATs are indeed often symmetric, unfortunately.
Visualization is the more powerful tool to help readers conceptualize the text, but it's also difficult to get right. After some experimentation with diagramming tools, I ended up going for an ASCII-based view.
It's important to not overlook the section "Types of NAT in the Real World", which is just a quote from the relevant part of Wikipedia, to essentially say that in practice none of these theoretical models are perfectly found in real-world equipment. Still a useful differentiation to learn, but one shouldn't expect network equipment to behave as one of the described categories 100% of the time.
As in, the design goal of NAT - sharing small number of external IPs by larger number of machines -- is best realized with what STUN calls "symmetric NAT". I am pretty sure the only reason full cone/restricted NAT type exists is performance, routers trying to keep translation table smaller for memory or CPU reasons.
And yet, based on router's internal implementation detail, there is now a protocol and an RFC and tools, detectors, software support, tutorials and so on.