Or potentially ever, as predicted when IPng was being originally thought about:
We believe that it is not possible to have a "flag-day" form of
transition in which all hosts and routers must change over at
once. The size, complexity, and distributed administration of the
Internet make such a cutover impossible.
Rather, IPng will need to co-exist with IPv4 for some period of
time. There are a number of ways to achieve this co-existence
such as requiring hosts to support two stacks, converting between
protocols, or using backward compatible extensions to IPv4. Each
scheme has its strengths and weaknesses, which have to be weighed.
Furthermore, we note that, in all probability, there will be IPv4
hosts on the Internet effectively forever. IPng must provide
mechanisms to allow these hosts to communicate, even after IPng
has become the dominant network layer protocol in the Internet.
I’d say it’s marginally simpler. Unequivocally it’s quantifiably simpler. But infinitely simpler? That’s a pretty tall claim to make.
Either way, expecting no effects on latency/bandwidth when additional processing is involved is a rather insane take. If anything, you should be the person presenting evidences to prove your position. Ideally, the cost effectiveness of whatever you present should be included too.
Anecdotally, I have experienced IPv4 slowdown due to CGNAT overload. Make of it what you will.
In a home network this is a negligible concern. In a CGNAT setup it is a limitation of the hardware or ISP, not really NAT. Furthermore it impedes establishing connections, not bandwidth.
> Furthermore, the keepalive packets
First, what keepalive packets? NAT does not introduce packets into an existing TCP or UDP stream; for TCP it uses control packets to detect state and whether teardown is needed. For UDP keepalive packets depends on the underlying protocol; for example wireguard supports a persistent keepalive. But is this material though? Will this even materially affect a dialup connection?
> Either way, expecting no effects on latency/bandwidth when additional processing is involved is a rather insane take.
You're putting words in my mouth. I asked does it materially affect bandwidth or latency or does it bottleneck it in some way. My argument is that NAT introduces packet process delay in the magnitude of microseconds per packet processing. This is negligible when most applications on the Internet deal with latency in milliseconds. Lastly, if the point is to compare, it'd be NAT against no NAT, not really NAT against IPv6. I find your position weak insofar saying port exhaustion or keepalive packets limit bandwidth; if it does, quantify it.
> Anecdotally, I have experienced IPv4 slowdown due to CGNAT overload. Make of it what you will.
That's on your ISP, not NAT. It's no different to your ISP delivering gigabit to last mile and using dialup links for connectivity. They need to adequately resource the network.
Can't have bandwidth if you are TCP RST'd.
> First, what keepalive packets?
Any devices or protocols sending a useless keepalive packets (e.g. Wireguard has this) just so the NAT won't take away the precious 5-tuple and give it to others.
> NAT against no NAT, not really NAT against IPv6
I am sorry, but I cannot imagine a "No NAT" solution that doesn't involve IPv6. So yes, NAT vs No NAT is still NAT vs IPv6.
Unless you still have a /16 IPv4 block in your hands, in which case, go on. Just remember that in this case you are the exception and not the rule.
> That's on your ISP, not NAT. It's no different to your ISP delivering gigabit to last mile and using dialup links for connectivity. They need to adequately resource the network.
NAT being stateful is ultimately the cause of this. No statefulness, no need for (additional!) expensive equipment, no resource constraints.
Thus the packets have to take a detour through the NAT engine instead of taking the shortest physical path to the destination as they can with a plain stateless L3 switched fabric. E.g. in an AON with L2/L3 switches on the provider side of the last-mile link, you can easily bend the packets right around in that switch if you're WebRTC calling your neighbor. No need to even go beyond the curbside switch.
Other than that, it's still typically gonna be a physical detour to the NAT engine instead of going straight to the destination, as the NAT engine isn't fused into the main fabric data plane.
NAT, at scale, can get expensive:
> Our [American Indian] tribal network started out IPv6, but soon learned we had to somehow support IPv4 only traffic. It took almost 11 months in order to get a small amount of IPv4 addresses allocated for this use. In fact there were only enough addresses to cover maybe 1% of population. So we were forced to create a very expensive proxy/translation server in order to support this traffic.
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
* https://community.roku.com/t5/Features-settings-updates/It-s...
* Discussion: https://news.ycombinator.com/item?id=35047624
The CG-NAT gear takes time to process the request and has a finite bandwidth.
If someone is torrenting behind the NAT you can get exhaustions
It's the whole reason why I discovered a DNS server that synthesizes AAAA records, for websites that actually support IPv6 through their CDN. [0]
> As you said though, those users can reach v4 websites.
Therefore, the question is: Can those users really reach IPv4 websites?
Mind you, I don't expect the CGNAT-overloading issue to relieve over time -- unless we deploy IPv6 everywhere ;)
And running a dual stack is trivially easy for almost everyone using it. That chart has almost half of Google's users coming in via IPv6. I promise you less than 1% of that 50% have ever even heard of IPv6, let alone done a single thing to configure it. With my ISP I'd have to go out of my way to turn it off, which I haven't done because this isn't 2008 where it broke things more often than never.
Why? Radical complexity reduction at essentially no cost to yourself or your customers seems like a tempting proposition.
Forgive me if I'm missing something here, but how is that any different WRT IPv4 vs. IPv6?
In both cases, except for those services one wishes to expose to the Internet (assuming one has a use-case for that), all incoming connections should be blocked, IPv4 or IPv6.
Or are you arguing that NAT masquerade confers some sort of security benefit on one's network that precludes the necessity of blocking incoming connections?
I'd argue that NAT (N:1 or 1:1) doesn't provide any security benefit. Nor does IPv4+NAT reduce the complexity of firewall rules as compared with IPv6.
In fact, I'd posit that NAT makes things more complicated and not less. That said, you can use NAT/NPT[0] with IPv6 (along with ULA/SLAAC) if you really want.
As such, I'd say that IPv6 provides the best and worst of IPv4, plus additional benefits.
IF we ever get completely off IPv4, that will be a good day.
[0] https://en.wikipedia.org/wiki/Network_address_translation#NA...
> In fact, I'd posit that NAT makes things more complicated and not less.
Sure, it clearly adds some iota of additional work, but I've never seen it as being the worst thing in the world. I'm young enough to have never witnessed the legendary paradise of globally-reachable static IPs for everything, so it seems more like "just the way things are". And yet there is widespread hatred against the existence of NAT, and I can't tell if it's primarily ideological, or if NAT is causing real practical difficulties for many setups. (Though at least the issues with CGNAT are easy to see. And also with broken NAT implementations.)
Meanwhile, one might argue that things like SLAAC in IPv6 can similarly add conceptual difficulties compared to IPv4. E.g., "How do I identify some particular device in my network, if its link-local IP is changing on a regular basis?" (To which the answer is something DNS-like, I guess?) So switching a network's internal operations from NATted IPv4 to NATless IPv6, with all of its different mechanisms, would seem like more of a tradeoff than an unequivocal win.
In residential environments you can do whole bunch with UPNP/PCP, but with IPv4 you have the added complexity of STUN, TURN, and ICE:
* https://community.cisco.com/t5/collaboration-knowledge-base/...
* https://medium.com/@ecosmobtechnologies/webrtc-best-practice...
With IPv6 you simply punch a whole and and the two clients simply talking to each other with their GUAs.
(In more tightly controlled environments (e.g., work), firewall policies and hole punching are dictated by IT.)
> Meanwhile, one might argue that things like SLAAC in IPv6 can similarly add conceptual difficulties compared to IPv4. E.g., "How do I identify some particular device in my network, if its link-local IP is changing on a regular basis?"
If a device gets its address via DHCP(v4), how do you identify it? SLAAC is for dynamic environments, but if you want static services, configure IPv6 statically.
At least with IPv6 you don't need DHCP infrastructure (and complexities like IP helpers configured on routers) to get going.
Eh, I wouldn't call it that simple. With an IPv6 firewall, TCP hole-punching is still difficult to impossible depending on how strict the connection tracking is (necessitating something TURN-like), and UDP hole-punching still requires some timing trickery. It's useful to keep a connection open with a STUN server regardless, in case that influences the firewall. All that NAT does is add a few more possible failure points, depending on how the router sets up mappings.
In the end, these are just hacks on hacks regardless, since we're never going to have reliable UPnP or similar on every network.
> If a device gets its address via DHCP(v4), how do you identify it?
I manage its assigned IPv4 address from the router, which itself presumably identifies it by MAC address. Doing it centrally from the router is often easier than trying to change the device's own settings.
Regarding static IPv6, can you still have static addresses within a network, while using rotating privacy addresses for outside connections? I've always been somewhat unnerved by the idea of each device in a network having a persistent address that can be separately tracked.
This has lead to many context specific problems as many of the re-written protocols don't work as well not to mention the added complexities of protocols designed specifically with NAT in mind. As another network engineer I can attest to the problems this has caused. Pretty much everything from overlay VPN networks, VoIP solutions, security and ACLS, and just our day to day maintenance tasks are complicated by NAT. It has gotten so out of hand that many of us have dedicated NAT routers just handling NAT translation.
It's so weird to me that so many people in our industry spout scalability but then laugh off IPv6... How the heck do you guys plan to communicate to the ever increasing amount of smart devices? IPv4 literally ran out a space years ago...
Not all servers are user-accessible. For instance, a database server or a NAS server might only be accessed by other servers within the same organization. Using IPv6 between these internal-only servers, instead of RFC 1918 addresses, can simplify things.
Instead you could just choose ipv4 only and reduce a lot of complexity. Sure there are also downsides -- if you're in a large org and are running out of RFC1918 space, or you're rationing it to smaller than /24 networks, that can be a pain (I don't see a benefit of more than 256 host addresses on a subnet as that's already far to large a broadcast domain)
> It's a terrible it to start a new project in 2024 without IPv6 support though.
That does not preclude ALSO supporting IPv4.
Remember that for many technical folks out there, the default is "Only do IPv4 support" which is (IMO) just batshit stupid.
(Do also note that the sentence immediately prior to the one you quoted is "I didn't recommend dropping IPv4.".)
1. Support IPv4 and IPv6.
2. Support only IPv4.
#2 has essentially no downsides and is radically simpler.
That's my point. It's not terrible to start a new project without IPv6 support, because adding IPv6 support adds a ton of complexity for almost no benefit.
I never claimed or insinuated that you recommend dropping IPv4. If I thought your recommendation was to drop v4, my argument about the complexity of dual-stack would've made no sense.
Check my handle. I'm not who you seem to think I am.
> ...adding IPv6 support adds a ton of complexity for almost no benefit.
That doesn't at all match my experience with IPv6 support in greenfield projects for the past decade+. You actually have to do extra work to make them IPv4-only. Remember that the statement you initially responded to said "It's a terrible it to start a new project in 2024..."
> Check my handle. I'm not who you seem to think I am.
Sorry, I didn't notice. Pretend I said "they" rather than "you".
> > ...adding IPv6 support adds a ton of complexity for almost no benefit.
> That doesn't at all match my experience with IPv6 support in greenfield projects for the past decade+. You actually have to do extra work to make them IPv4-only. Remember that the statement you initially responded to said "It's a terrible it to start a new project in 2024..."
Huh, I never found it difficult to ... not add an AAAA DNS record to point to a server. It surprises me that you find that to be extra work.
Have you attempted to make greenfield software written in 2024 support only IPv4 addresses and be deliberately incompatible with IPv6 addresses? It's a lot more work than just using what the standard libraries give you and just getting support for v4 and v6.
Now the software itself would probably work v6 if you set up the infrastructure for it, but that's not what I'm talking about. (I don't know for sure that it works with v6 though, never tested)
I know for sure that I've written some software before which doesn't work with IPv6 because the buffer I pass to gethostbyname is 4 bytes, but to be fair I haven't written such software in 2024. I have also written software to configure a device's interfaces and routing tables which only does DHCP4 and only configures v4 addresses, but that was in 2023 not 2024, maybe dhcp4 would've magically worked with IPv6 if I had done it this year
Hmm:
> The gethostbyname*(), gethostbyaddr*(), herror(), and hstrerror() functions are obsolete. Applications should use getaddrinfo(3), getnameinfo(3), and gai_strerror(3) instead.
* https://man7.org/linux/man-pages/man3/gethostbyaddr.3.html
Using gethostbyname turned out to be pretty easy by the way, I wouldn't say it was a lot more work than using getaddrinfo
If you're with AWS, you'll be charged for IPv4 public addresses:
* https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...
If you want to 'own' IPv4 addresses, that'll cost you as well:
* https://auctions.ipv4.global
Certainly some will be needed for 'legacy' purposes for the foreseeable future, but the more you can reduce the use of them at your edge, the less money you'll be shelling out.
That depends on your definition of "can't get away from". Your users can live on a IPv6 only lan and have the IPv4 world available to them. IPv6 supports 4 in 6 - ie you can embed IPv4 addresses in IPv6, so all you need is a gateway that translates IPv4 to IPv6 for them.
I've done it. At a conference, to unsuspecting users. All phones support IPv6 well, so they didn't notice. Not one complaint - I was blown away by how well it all worked.
It was done because some noisy attendees insisted on being assigned routable IP addresses. That can be difficult to provide with IPv4 for obvious reasons, whereas ISP's will happily hand you thousands of billions of IP{v6 routable addresses, for free.
I set up the gateway myself, rolling my own using a linux box I had lying around. Adding the 4 in 6 capabilities is maybe an hours work on top of all the other setup you have to do on the box, and that includes googling to find what tools you need and how to configure them. It's not hard.
The only benefit of this is to increase familiarity with ipv6. I'm trying to push some colleagues to do an ipv6 only section of our network which has limited interconnect, but there's a lot of concern about devices that still don't support ipv6, and ultimately what's the business reason to do it compared with subnetting 10.0/8 and natting at your firewalls
I find it amazing how that lack of curiosity about how computers work extends into modern software developers, I guess that the majority of the industry nowadays are people that do things like "bootcamps" and go into it for the money.
I have no need for ipv6, however I wanted to know about it so spent a couple of hours setting myself up with it. I don't bother with the latest fads that last 3 or 4 years and then are replaced by a new fad, but ipv6 has been around long enough that it's clearly not a fad.
IPv6 has been around long enough that it's clearly a failed project. It's been 30 years and it hasn't even breached 50% adoption. It's not even at the hard part yet, which will be the long tail.
You have a very radical definition of "failed". Take your emotions out, and perhaps you would get a more objective evaluation of the technology.
For one, it's very clear that IPv6 has only, truly received global attention after the depletion of IPv4 address space -- someone has already linked the Google IPv6 adoption page, go have a look at it, look at the flat line before 2012. That means we have spent about of 10~15 years of time deploying IPv6, not 30 years, and getting to 50% adoption in such a time period is not what I'd describe as a failure.
Secondly, if you are defining failure as "less than 50% prevalence in 30 years" then HTTPS before 2014 will probably fall under the same category too. (Don't underestimate the age of SSL/TLS.)
Do you consider HTTPS a failure?
Hell just look at SDWAN land and everyone acting like it is the second coming of jesus when it is just a fancy marketed version of technologies that have been available for decades.
Why build today with deprecated technology ? Build your infra v6-only, add a layer at the edge to support old clients via IPv4. Job's done.
You should design your infrastructure to avoid paying too much for other people's legacy.
Unfortunately, a lot of applications are building on platforms where IPv6 is an afterthought if even present at all. Take for example Azure, where IPv6 support is a fucking joke. From core services like Route Server not supporting it, to it being impossible to build v6-only networks due to forced v4 subnet and vNIC requirements, to many services that Microsoft provides only running on v4.
As much as I want to push IPv6 everywhere, that physically cannot happen until companies support it for all use cases. In the mean time dual stacking can be better than nothing but the complexity is non-trivial when the alternative is just running straight v4...
How would have it made it easier to migrate when all of the new blocks wouldn’t be accessible (in either direction) if the traffic passed through any router that hadn’t yet been upgraded? Nobody could really use any of the extended space at all until every single router had been upgraded to this IPv4+.
It is a common misunderstanding (I hear “we could have just made IPv4 bigger” a lot) but apart from the routing issues above (needing to replace every router before it could work at all), the endpoints are also a problem. Nothing in the expanded space could actually call out to a legacy IPv4 endpoint - it could sent packets to it, but that legacy host wouldn’t be able to return packets back since it wouldn’t understand the larger address. And of course the legacy endpoint couldn’t initiate a connection to anything in the extended space either from its side.
So you not only have all the same problems of IPv6 (like needing to upgrade everything), you actually add a bunch of problems of breaking the ability of big parts of the internet from being able to communicate with the rest.
Dual-stack was necessary because everything couldn’t be switched over on the same day. If everything was upgraded at once, your extended-IPv4 idea would work, but otherwise it would break the internet!
Don't forget all the DNS software: "A" records are hard-coded to 32-bits, so if you wanted >32 you needed a record type (what we now call "AAAA", RFC 3596).
Then all the DNS programming APIs had to be updated and all the C header files with new structs.
You mean like RFC 2765?
Running a single IP stack is infinitely simpler and easier than running two concurrently, and until that "single IP stack" can be v6, I see very little reason to support it.