Agreed, while I recognise that both look bad, I'm skeptical as to how bad they actually are. Some comparisons against good examples of these sorts of transitions would be good.
IPv6 provided some features people needed (larger addresses), made some changes born from experience (removing IP-level header checksums in favor of packet checksums like those in UDP and TCP, removing fragmentation), and then bundled in a pile of mandatory added complexity (DAD, SLAAC and router advertisements rather than DHCP, initially mandatory IPsec).
If IPv6 had left out the mandatory added complexity, and just focused on the larger addresses and cleanups, it would have been easier to adopt. The other changes could have happened via other standards, rather than bundling them all into "IPv6".
> […] and then bundled in a pile of mandatory added complexity (DAD, SLAAC and router advertisements rather than DHCP, initially mandatory IPsec).
SLAAC and RA reduce complexity as you no longer need 'extra' infrastructure (DHCP) to get going: plug in and the router sends the information and you're done.
You also get rid of the complexity of STUN/ICE/etc as you no longer need NAT, so you just need hole punching for SPI firewall (also needed with NAT for port forwarding, so no change there).
There is NAT64 for that https://en.wikipedia.org/wiki/NAT64
Many mobile operators use that, in USA that is Sprint/T-mobile, Bell in Canada.
All modern OSes support that pretty well.
Once you add up the real world factor of half-assed implementations and bad business/tech decisions, you end up with DHCP and NAT (or its IPv6 cousin, NPT) to solve issues.
> plug in and the router sends the information and you're done.
If you want the network to come up in a timely fashion, the new system needs to poke the network to get information proactively sent to it as soon as possible, at which point you have about the same level of complexity as poking a DHCP server. (With added bonus "this could happen asynchronously at any time and you never reliably know when your network is actually done being configured".)
If those standards are so valuable, they should have stood on their own, as optional things people could have adopted if they wanted to do things completely differently from IPv4. Meanwhile, people already have DHCP servers, and could have just told those DHCP servers to start giving out IPv6 addresses too.
The reaction I have every time I interact with IPv6 is that it seems incredibly hard to make a system just use the configuration you tell it to use and never ever listen to any configuration from the network.
> If you want the network to come up in a timely fashion, the new system needs to poke the network to get information proactively sent to it as soon as possible, at which point you have about the same level of complexity as poking a DHCP server.
I've had to fight with ip-helper issues and DHCP scopes enough times to not wish to have to deal with it if possible.
I have to configure the router (or the VLAN on a Layer 3 switch) anyway, so a few extra lines for /64 scopes that are sent out via RAs on the same device I have to touch anyway is easier.
> The reaction I have every time I interact with IPv6 is that it seems incredibly hard to make a system just use the configuration you tell it to use and never ever listen to any configuration from the network.
I recently had to switch ISPs to one that doesn't do IPv6 for FTTH (but their smart offerings are (AFAICT) IPv6-only), but my previous IPv6 did, and activating it for my home network was a couple clicks on my Asus router: all my devices (including a networked printer) picked it up without issue.
The complexity is already paid for since you aren't going to be able, or even want to, wholly rip and replace IPv4 since it gains very little and risks a lot. IPv6 would have been great if it didn't have to work in a brownfield environment. Unfortunately, nobody is going to change because it's conceptually purer to not have those ancillary protocols. This is what the creators of v6 failed to consider: IPv4 was entrenched, it's not 1982 with ARPANET connecting a handful of systems all managed by people who knew each other.
And DHCP does a bunch of stuff that's irritatingly dumb to do with IPv6, to the extent that v6 ended up shoving partial compromises _anyway_ like RDNSS.
It's classic second-system effect and design by people without production experience or skin in the game.
> The complexity is already paid for since you aren't going to be able, or even want to, wholly rip and replace IPv4 since it gains very little and risks a lot.
> It's classic second-system effect and design by people without production experience or skin in the game.
Begin with "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" for part of the discussion from back in the day (1993):
Those are the very things that makes IPv6 anti-privacy. We lose all control at the router level. Users are served up like lambs to the privacy slaughter.
You don't lose control at the router level. v6 isn't anti-privacy and there's no privacy slaughter in it. RAs have no privacy impact and SLAAC makes no meaningful difference.
Yes but you've left out the biggest and most disruptive change in v6: all pre-existing v4 addresses and routing are not carried over to it. This alone makes it a conceptually separate network from ipv4.
I think that if IPv6 would just be IPv4 with bigger addresses, the rollout would be much easier. Sure, you would still need new hardware, but the basic operations would still be the same as IPv4. Currently, it is far from that.
Are there recommendations that result in IPv6 looking like something more than just IPv4 with bigger addresses? Yes.
Is there anything stopping you from effectively running IPv6 networks the same way as you run IPv4 networks, but with larger address pools? No.
You can do NAT66, you can do DHCPv6, you can run every network as a /120 (IPv6 equivalent of a /24 - 256 addresses) if you want to as well.
You can even (outside of whatever prefix is delegated to you) only use numbers for the host addressing portion if you want to, and not bother with letters.
Just because the recommendations and standards say you SHOULD do things a particular way, it doesn’t mean you MUST.
Sure, I don't have to, but everything in the stack assumes I would run it in the recommended way. I gave up trying to setup my LAN to support IPv6 after I wasted more than 2 hours on convincing my router, and devices behind it, to somehow work with the /128 address I got from my ISP. Should it be technically possible? Yes, definitely. Is there any value for me in spending a lot of time on it? No, there is not, everything is reachable on IPv4 anyway.
This would not be a problem if it would be just bigger IPv4 and there still was NAT, DHCP and everything. But that is not the way you are expected to be doing IPv6...
That's because there are good reasons for running it in the recommended way. If you're going to go out of your way to run it in bad, unpopular ways instead then it's on you to get devices that support what you're trying to do. (For example, squid on Linux would do it just fine, whereas some random consumer WiFi/switch/router combo thing is probably not going to go far outside of its basic functionality.)
Instead of giving up, I'd suggest doing it the normal way -- do DHCPv6-PD to get a routed prefix, use that on the LAN and route to the Internet. On most v6-capable routers that's the default and will happen automatically, and it would be hard to make it easier to roll out than that.
> Sure, I don't have to, but everything in the stack assumes I would run it in the recommended way.
> This would not be a problem if it would be just bigger IPv4 and there still was NAT, DHCP and everything.
Irony, I remember life before DHCP/NAT44 defaults, and having to struggle so much to do it myself. Mind, this was 1997, and IPv6 was already a defined standard, which then never got any traction because NAT44 ended up being “good enough” for most people who didn’t think about what they lost in the process.
> Should it be technically possible? Yes, definitely. Is there any value for me in spending a lot of time on it?
There was a lot of value in me spending a lot of time and effort on setting up DHCP and NAT in my home environment in the 90s. Nobody else I knew thought it was worthwhile though, and thought I was insane.
There was a lot of value in me spending a lot of time and effort on dual stacking my LAN too. I see a parallel here that’s amusing to me :-)
Certainly some people didn't like the changes of ND vs ARP and such, but once you're changing the address length, you have to alter the data structure on every bit of networking code, and any transition is going to be a slog.
IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+.
And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere.
But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection.
And of course as long as IPv4 works there's little inherent motivation to go to any kind of IPng.
See "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" for part of the discussion from back in the day (1993):
In practice, port number is used as part of address, or, VPN, with tagging, are used. We can make convention that top 4 bits of port number are part of the host address. It will increase number of available addresses by up to 16x.
For example, we have router at 1.2.3.4/192.168.0.254, and 15 hosts behind it, then, by convention, we can access 192.168.0.1 from public internet as 1.2.3.4:32848 (port 32767+1+80), host 192.168.0.3 as 1.2.3.4:32849, and so on.
A much simpler and compatible solution would be to assign a single IPv4 address per AS and then use IP options to pass additional address bits to identify the specific host within the AS.
That wouldn't be simple or compatible, but also... v6 basically already has what you're suggesting here, except forget every AS: every single v4 address already has a /48 of v6 space tunnelled to it.
They're more a case study on institutional inertia and not providing a good justification for businesses to upgrade. Gotta sell the benefits.
I think cloud providers charging for IPv4 is a great stick, since the initial carrots (easier subnetting, huge networks, multiple IPs per host, encryption, etc) didn't work. I do wish they provided NAT64 services though.
At least with Python3, there was eventually Python 2.7 to permit a compatibility layer to move over.
It took ages, but there was at least a "best effort" to help people write code that could be easily moved between 2 and 3. (In spite of apparent behavior from the Python developers at the time).
IPv6's hard break with IPv4 means that the switchover likely won't happen anytime soon.
> At least with Python3, there was eventually Python 2.7 to permit a compatibility layer to move over. [...] IPv6's hard break with IPv4 means that the switchover likely won't happen anytime soon.
There was no hard break. The same way you have compatibility layers between Python 3.x and Python 2.7, we have compatibility layers between IPv4 and IPv6. For instance, 6to4 meant that anyone with an IPv4 address automatically had an IPv6 network, and could talk to IPv6 hosts; I used it for a while, and it worked nicely. Another one was Teredo, which worked even if your IPv4 host was behind an IPv4 NAT. Nowadays, the preference is for newer transition mechanisms, like NAT64/DNS64 and 464XLAT. On the software side, IPv4-mapped IPv6 addresses allow software written for IPv6 to transparently use the host's IPv4 stack to connect to an IPv4 address; this last one is very similar to the preferred approach of writing Python 3 code and using a compatibility layer to make it run on Python 2.7.
IMO they should've just conceded and added a `print` syntax to Py3 similar to Py2. Stupid as it sounds, that was often the only reason someone's script was Py2-only. That and the integer division should've stayed the same.
Anyone that is surprised by this behavior from AWS probably has very little experience using it. The whole console is full of dark pattens to get you to setup larger than needed defaults and accidentally leave things running.
I'm always surprised that people think they're getting a good deal from a guy who spent a billion dollars to launch a dick into space. The days of the door desk are long gone.
Do the other cloud providers give you IPv4 endpoints for free? I didn't think that was the case. (ie I thought AWS was just falling into line with the others on charging).
As for the "critical services not supporting IPv6" in the post I was quite surprised that it's such a short list of things that don't work - I would have expected more. They've obviously made a ton of progress.
But did they tell you to "think about accelerating your adoption of IPv6 as a modernization and conservation measure" when they announced the charges? Because AWS did.
I get the feeling this is far from an exhaustive list. I think this person just mentioned two things that they had run into and could say didn’t support IPv6 without having to look it up.
Hetzner is charging 0.50€/month, compared to AWS's $3.60/month. Which I guess is in line with the usual price difference between the two, but usually AWS does a better job justifying the price difference.
Oracle Cloud does. Linode did, I don't know if they still do. I believe Vultr may. It would take some time for someone to research all cloud providers.
Linode still does. I’m running a business on it (and moving personal stuff over from DigitalOcean). The pricing/performance value proposition on Linode has been fantastic.
Ip addresses have an actual market value now. They cost 50 cents a month to lease.
AWS is charging $3.60 per month. Which isn't orders of magnitude off when you consider AWS probably has a poor utilization rate (can only advertise /24's) and profit margins to consider.
IP addresses were intended to be a public good. The fact that AWS has monopolized so many of them, and now that they own a significant fraction of them is deciding to charge for them. It's ridiculous.
Then don't use AWS and discourage others from using AWS.
I guess that might also include all Amazon businesses if you really want to try to send a message, not that it'd really hurt Amazon that much if more people don't actually follow through with going to alternatives.
Or you can complain about it with no results or actions.
The Internet was designed by hippies and IP addresses weren't auctioned in the old days; they were given for free. When IPv4 runout was in sight the hippies argued loudly that addresses should be rationed instead of sold.
It might be right to call Jon Postel a hippie, but Vint Cerf sports a three piece suit. The Internet was designed by DARPA contractors and university grad students, so it’s a bit of a weird mix.
So far as I'm aware IP addresses exist out of a functional need, not a moral imperative, but if you have a source with regards to that I'd love to read it. You can hardly call the number of IPv4 addresses that AWS has a monopoly either, iirc they have something like 2% of the IPv4 space? Not charging for them was comparatively strange given that other cloud providers have been charging for them for a good long while. Managing their address space isn't a zero cost endeavor for AWS, so why wouldn't they charge for it? At the least to cover their costs, but given the way the world works these days making a profit isn't weird or unexpected either.
If you're really upset about it you can go through the trouble of registering your own ASN and get on the list to get your own allocation from ARIN. No one is stopping you from doing so.
I think there's an enormous number of things that it's very worth criticizing AWS (and other cloud providers) for, but this really isn't one of them in my book.
> So far as I'm aware IP addresses exist out of a functional need, not a moral imperative, but if you have a source with regards to that I'd love to read it.
Are we talking about IPv4 addresses or are we talking about the internet as a whole? Because that quote seems to be about the latter and I was referring to the former above. I read the Licklider paper that they link and it's much more on the abstract side rather than discussing actual implementation details.
Licklider and Taylor did have some very interesting predictions about how the internet would shape up though. Probably my favorite quote from the article:
"Unemployment would disappear from the face of the earth forever, for
consider the magnitude of the task of adapting the network’s software to all
the new generations of computer, coming closer and closer upon the heels
of their predecessors until the entire population of the world is caught up in
an infinite crescendo of on-line interactive debugging."
There's also the issue of AWS actually running out and not being able to take on more customer, or at least larger customers. It is solely for the benefit of AWS, not it's customers in any case. If it was about the customers NAT gateways would get reduced in price at the same time.
That being said, I do know companies that have freed up 80% or more of their IPv4 allocation with no service impact. It was simply not an issue previously and AWS made it easier to just allocate more public IP addresses.
They at least hit the right price to ensure that people care, but not making it unreasonable if you do need an IPv4 allocation.
The comment by Adi Santhanam[1] who is an AWS product manager for networking has indicated a Lightsail pricing increase for IPv4 later this year[2].
> Yes, Lightsail is revising instance bundle pricing to accommodate IPv4
and new pricing will be published later this year. We understand the
importance of bundled and predictable pricing for Lightsail, so revised
pricing will include the IPv4 conservation charge in a monthly bundle
cost and not as a separate charge.
It's stunning, the hypocrisy that permeates Amazon now. I left AWS Lightsail for Oracle Cloud. When they announced Prime members would be shown Ads in movies and shows, we cancelled Prime.
One day will come, when network admins will be so happy to finally turn off IPv4 on their stack. When router manufacturers will feel happy to support only IPv6. It is definitely coming within my lifetime.
So, these intermediate steps are just cooking the final dish.
I don't think that will ever happen... Too many big businesses squatting on their IPv4 allocations to ever want to spend the money to implement IPv6. They don't need to worry about allocation running out or charging for IPs because they've got theirs.
They would need to be forced to move by customers, probably through an ISP being IPv6 only. And that probably won't ever happen as the customers of those ISPs would drop them for one that does support IPv4 because they expect access to the same big businesses mentioned earlier.
I think the whole thing has lots of inertia to not move to IPv6 and there's no incentive to force it.
I can’t know for sure what the parent comment was alluding to, but I would assume the idea is that because IPv6 isn’t built around an assumption of NAT, that it’s less private because you don’t have an intermediary router (potentially) concealing traffic origins as a network design feature.
That’s the only thing about IPv6 that I’ve heard of that I think is a reasonable argument regarding a degradation in privacy.
With that said, NAT was a fix for issues that weren’t about privacy, and NAT itself was not designed to give you privacy. It used to be that IPv4 connections were always direct in the same way IPv6 connections were designed to be direct.
In that regard you could make the argument that IPv6 is a regression, but that regression is effectively answering for an architectural shortcoming in IPv4 that we’ve tried hard to fix but that can only go so far.
Edit to add: NAT also doesn’t protect anyone’s privacy anymore than their ISP is willing to protect it anyway, for what it’s worth.
Not having mature IPv6 support for VPC network, even though regrettable, is understandable, but not supporting it for public endpoints like {s3,ec2,lambda,sqs,...}.{region}.amazonaws.com is a real head scratcher.
Perhaps AWS could run these endpoints through Cloudfront in order to get IPv6 reachability.
To be fair I have a bunch of instances with public IP addresses just so I can ssh into them easily. This situation made me look into how I'd get into these instances otherwise and indeed you can set up an appropriate endpoint and then run "aws ec2 instance-connect" to make a tunnel that gets you an ssh connection without needing the public IP, so just like that my needs for public IPs actually goes down pretty drastically.
On the other hand, on my first try I couldn't get "instance-connect" to work and it turned out I needed a different package "awscliv2" which I had no idea existed.. I've been using "awscli" for the longest time and didn't know there was an alternative and more up to date package available. What a mess.
Also, when running the new one apparently it does a bunch of weird docker magic in the background instead of just being a normal Python program so not sure what to think but I guess it works. If anyone knows a leaner solution to opening an instance-connect tunnel I'd love to know.
Are you using a docker image to run AWS CLI or something? It shouldn’t have anything to do with docker at all if you’re just running the bare ‘aws’ command.
aws ec2-instance-connect doesn't use docker, it just sets up a short lived ssh key in the instance metadata that you can use to connect. You can connect either via a public ipv4, ipv6, or a vpc private endpoint.
I don't really know any details, but all I can tell you is that this is the output of running it in a fresh environment (masked out the instance details and snipped some output..):
And now I am logged into the machine. You can clearly see that it downloaded an AWS docker image. Exit from ssh, back to local terminal, and now there is an image on my machine:
$ docker images | grep aws-cli
amazon/aws-cli latest 817d1061df76 3 hours ago 384MB
So I don't know if I agree that aws ec2-instance-connect doesn't use docker. And also, I don't necessarily have a problem that it does, it just surprised me a bit.
Oh I see. I installed awscliv2 after discovering that awscli did not have the ec2-instance-connect command, so I could not follow the documentation and went searching to see if there was an updated package and discovered that one. So I guess you are not supposed to install it using pip anymore. Good to know.
Update: and now I've read through the github issue, oh my I've missed quite some drama.
Don't overlook SSM <https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/session-...> which doesn't require sshd nor public access to get onto a machine and one can opt in to a bunch of audit logging if that's your jam. They also have some "ansible-y" behavior about running playbooks against groups of instances, but I haven't had good experiences with that process in order to recommend it. It's just a small bonus that one can also hop onto an instance from the AWS Console when using SSM, since it is websocket based and not "ssh from the browser"
I really like SSM, and for specifically for Windows RDP, the port forwarding feature. When combined with SSO, proper policies and tagging, you can do away with SSH keys, bastion hosts and VPNs.
The traditional method to achieve this is a ssh bastion. You have one tiny server running that has a publicly reachable IP, and can also reach the other servers (usually via the private network). You ssh into the bastion, then ssh from there into your actual server (or use port forwarding to make an ssh connection via the bastion, which some tooling supports out-of-the-box).
Considering the cheapest ec2 instance type is now cheaper than an ipv4 address this is easy to justify if the AWS specific options don't fit your usecase
Bastions are a good option. sshd supports jumping through them by default using the -J flag (jump) or automatically by adding the 'ProxyJump' statement to your .ssh/config.
See, you’re already acting as if you’re being selfish.
You’re not.
Having an IP per endpoint that is conveniently globally routable from any other endpoint is the entire purpose of the Internet!
It’s not some sort of greed or abuse of privilege! It’s the reason for the thing to exist!
This is like going to a shopping centre that has been growing along with the local population exponentially but refuses to buy more shopping carts. You can’t feel guilty for using a shopping cart “just” for your quick snack shopping as-if that’s a greedy move taking it away from more deserving people with “real” grocery shopping to do.
Stop thinking like this.
Seriously, STOP!
You’re the victim here.
You’re the victim of Amazon’s greed and lock-in.
You’re the victim of the lack of foresight for the most predictable resource exhaustion in the history of the world.
You’re the victim of a problem that has had a solution for two decades that is now included for free(!) in every network device being made but is being turned off by lazy administrators that can’t be bothered averting slow-moving catastrophies.
> And this is why I think we need to just modify IPv4 to add more numbers.
There is no "just" in this.
Copy-pasting from my other comment:
--
IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+.
And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere.
But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection.
--
So "just" expanding IPv4 to IPv4+ ends up being the exact same amount of work as ended up with IPv6.
Only only thing you could say with "just" more addresses is keeping ARP and the like (instead of DAD, etc).
In what way would this have "Complete backwards compatibility"? Maybe read https://en.wikipedia.org/wiki/Internet_Protocol first, specifically the part where it specifies the on-the-wire format. What backwards compatible change would you actually propose there?
There's one of these posts in literally every IPv6 thread.
> Complete backwards compatibility
> If it's 8 bytes then it's a full address
Existing IPv4 devices wouldn't be able tell that it's 8 bytes, and wouldn't be able to make heads or tails of such a packet. At best, they discard the packet, at worse, they misinterpret it. It's not backwards compatible.
You can attempt to construe the bits however you like, but you're going to butt up against the pigeon-hole principle here. Any solution that works is going to be materially the same as IPv6.
You can't extend the size of the ipv4 packet headers unfortunately without breaking backwards compatibility, so we're stuck with with the address size.
However, we're pretty stupid how we use ipv4. A connection identifier is actually 48 bits, which is a massive pool. Currently nearly everything on the internet runs 32 bit ipv4 address with a 16bit port number. The vast majority of internet traffic waste the last 16 bits because of convention (Hey only accept HTTP/SSL connections on port 443! lol)
We could extend ipv4 a couple hundred years by adopting SRV records, which would be a painless change compared to swapping ipv4 to ipv6. That puts the last 16 bits of the total 48 bits to work.
The other part of the ipv4 packet is a bunch of flags that are pretty dangerous and nobody uses. Those might be able to be used as identifiers, but it'd be pretty not-backwards compatible.
I'm a critic of the ipv6 transition because of the players promoting it in a certain way that is detrimental to the consumers. However, one thing ipv6 gets correct is the concept of network flows and the removal of a ton of cruft from the ipv4 packets. In that regard ipv6 is very well designed.
Anyway, I will continue to turn off ipv6 and block it on all the devices and networks I operate, as it offers no benefit to me personally, only downsides, and it's just one more thing to monitor for privacy.
I think a lot of other commenters complaining about the parent commenter missing the IPv4/6 header size are missing the forest for the trees here. The main problems with IPv6 (that are why most customer-facing components are not switching to it anytime soon) are simple:
1. The address space is ludicrously unwieldy. Humans are good at remembering long numbers. We're quite bad at remembering random strings outside of pure muscle memory. For the cases where you're manually fiddling with IPv6 space in situations where a domain name isn't mapped to an IP (ie. home networks), the reality is that IPv6 is only a negative. Telling people to go to "192.168.2.1" to log in on their router is easy. Telling them to punch in a long IPv6 address that includes the A-F range isn't. (And that's without getting into colon collapsing 0000 ranges which just reeks of "did anyone run this past a human being", because this makes even less sense to people who barely get "I need to type the address on the ISP router sticker in my browser").
2. The complete lack of even a one-way compatibility layer with IPv4 (so communicating from an IPv6 to an IPv4, which should be possible in a tech stack) means that even if you take the slow movement of hardware to IPv6 space into account, the offering simply isn't worth it until everyone switches over. Right now the standard offer for home ISPs is CGNAT + IPv6 if they offer the latter, is not solving anything - the reality is that if you give an IPv6-only offer, your customers just straight up can't access ~40% of the internet (and by law of institutions, that will include parts of the internet they really need because the people running it are restricted by yellow tape and budgets to also move to IPv6), so all we get is the worst of both worlds where IPv4 is still running out of space and IPv6 isn't ready to replace it.
Would it really have been too much work to slightly compromise on address space for IPv6 to just allocate a region to old IPv4 addresses, where the relevant low-level bits of the stack just switches over to the IPv4 protocol if it detects that region? If that were the case, the transition process would go much smoother and we probably wouldn't be haranguing about getting public entities to sell off their address space, just to delay the inevitable.
Those are the reasons why IPv6 isn't replacing anything beyond a slow crawl of "maybe I should set an AAAA record" (and considering like 80% of the DNS+VPS providers I've used in the past decade just dump the /16 when you pick a VPS from a dropdown in the address, which obviously fails to work, it's also clear that hosting companies don't consider it a real priority either). When it comes to core infrastructure like this, backwards compatibility isn't a "nice to have" or to be "thrown out because it was based on bad ideas". It's a requirement, no matter how insane the original product might have looked.
There is a compatibility later for IPv6 to access IPv4 called NAT64. It requires that IPv6 have a large address space to fit the IPv4 address inside IPv6 address. There is also MAP-T which can do stateless IPv4 NAT over IPv6 network by shoving the whole NAT state, ports and address, in the IPv6 address.
The length of IPv6 addresses is an advantage because people don't try typing them because they are so long. My home network have IPv6 and I have never had to enter IPv6 address. I don't know what my prefix is, I don't know any host addresses, I use mDNS to get to other hosts.
> Telling people to go to "192.168.2.1" to log in on their router is easy. Telling them to punch in a long IPv6 address that includes the A-F range isn't.
I think you're off base here. The direct equivalent of 192.168.0.1 is FEC0::1 and that's not harder to remember or type. The difference is that those addresses, site-local, got deprecated.
For link-local addresses, nothing stops a home router from using FE80::1. It doesn't have to be a pain to type.
> And that's without getting into colon collapsing 0000 ranges which just reeks of "did anyone run this past a human being", because this makes even less sense to people who barely get "I need to type the address on the ISP router sticker in my browser"
Is FE80:0000:0000:0000:E3B0:C442:98FC:1C14 better than FE80::E3B0:C442:98FC:1C14? I wouldn't say so.
And FE80:0000:0000:0000:0000:0000:0000:0001 is definitely not better than FE80::1.
And I don't share your preference for digits either. If you formatted your average link-local IPv6 address as digits, it would have 30-36 of them. No normal person would memorize it or enjoy typing it. Doing 4 characters at a time, 5 times, is much better than 254.128.0.0.0.0.0.0.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx. Even with the hassle of the double colon. I'd rather have an extra colon than make sure I counted exactly 6 0s in a row.
the trick is actually to add the extra bytes on the back end.
192.168.8.9.0.1.2.3
old devices get accessed the old way. new devices "know" about the add ons. The new part of the address travels inside "as data" so it gets delivered.
as company firewalls and routers switch to new, the whole company needs only one "old" ip. To get the ball rolling, spend some time deploying before it's switched on.
All those early adopters who have class A networks? They can go first this time too, freeing up their class A's quickly to facilitate the transition for everybody else.
source: this was my idea for phone numbers back when they kept rejiggering area codes.
This avoids some core router upgrades, but if you're on a device with a long address then every service you talk to also needs to be upgraded to use the extra bytes. So it still has similar adoption problems.
Unless you hide it all with NAT, but if you're doing that then you're losing lots of the benefits of more address space. And the NAT version is something you can already build yourself, but is rarely chosen for a reason.
What's the incentive to actually set it up, though?
You can do it right now as a graceful transition to IPv6. Running a pure IPv6 network with NAT64 or similar. But almost nobody does it. Why would your scheme be more tempting to them?
You're roughly describing 6to4, where 2002:c0a8:0809::123 belongs to 192.168.8.9. Though 6to4 is mostly deprecated, and you generally don't use it with "private" IPv4 addresses, unless you're incrementally deploying IPv6 in an environment where half the switching fabrics are IPv4-only and the other half can do hardware-encap/decap 6to4 but not 6rd.
This was called TUBA and was rejected by the working group around 1993 on the basis that the then-named IPng needed to offer more features than just expanded address space (e.g. get rid of ARP and DHCP).
If you say "ok then we'll set IPv4 source and destination to a fixed value and put the address somewhere else":
You've just made a new protocol that isn't IPv4, and is even /worse/ than IPv6.
Now, not only does one have still have to upgrade every device that deals with these packets, since every device that is routing these packets hop by hop needs to know where to find the new address, every packet now has 64 bits of unusable data in the header.
And the Internet still has to do all of the ancillary work to upgrade things like DNS!
Yes. You no longer need NAT, so port negotiation is much easier (even when inbound is blocked)
> Are you _really_ just going to allow random traffic into your network?
Common misconception! Even without NAT, the router can have port/traffic policies. There's just no address translation happening.
There's a lot of good stuff about IPv6, and I would encourage more people to learn about it and try it out.
- ULAs can act like static internal LAN addresses
- A "strong" NAT is easier to avoid and no longer breaks connections to things that are sensitive like gaming consoles
- Randomized, temporary IPv6 public addresses are a nice feature, and mostly turned on by default
- The biggest one is people seem to equate NAT = router/firewall. This is absolutely not the case, and they are distinctly different. You can absolutely have a router/firewall without NAT!
- CG-NAT is becoming more popular due to the lack of IPv4 addresses, and I hate everything about that.
- You can even run a NAT64 to provide IPv4 access to your IPv6-only devices
This can particularly play havoc with sensitive protocols like STUN. I believe many game consoles make use of this when in multiplayer matches. I have personally run into this using OpenBSD's pf, but I'm fortunate enough to have access and the known-how to fix it for my consoles.
It's one of those things that's fine until you run into "edge cases," and unfortunately NAT configurations can introduce a lot of undefined behavior from the user perspective.
Two peers, each behind a CG-NAT (or other symmetric NAT), depend on somebody running a relay in order to be able to communicate.
This makes it very expensive (and sometimes risky, since unrestricted relays can be used for all kinds of nefarious things too) to deploy any new VoIP service.
I'd call that "broken by NAT".
> everything works right now.
Yes, everything that works right now works right now, but that's a tautology, not proof of anything. The things that don't exist because they wouldn't work in a predominately NATted world don't work, because we live in a predominately NATted world.
You're always free to use a relay for privacy reasons. Many common VoIP solutions allow just that.
IPv6 (or more generally, the absence of NAPT) just changes the switch label from "try [not] to use direct connections, unless NAT gets in the way" to "[always|never] use direct connections".
In other words, it cleanly separates the two distinct concerns of privacy and connection topology. I think that's a good thing.
I remember having to do a lot of port forwarding to get certain things to work behind a nat. Certainly doable but beyond the competence of a non-expert.
And sometimes, entire nations. Qatar used to share a single IPv4 address, which I found out when news articles started reporting that the entire country could no longer edit Wikipedia without an account, which at the time, was also restricted if your IP was banned from anonymous edits. If you didn't create an account prior to the ban, you were completely blocked from editing.
This isn't entirely about static port-forwarding. As others have pointed out, STUN, VoIP, PASV, etc rely on deterministic NAT behavior to work. That is not always guaranteed, and often out of your control.
The existence of PASV mode and STUN/TURN is because the end-to-end addressibility of the IP protocol was broken with CGNAT.
Furthermore, in populous countries like India, ISPs enforce extremely aggressive timeouts on IPv4 connections in order to keep the 5-tuples on the egress side of things manageable. Trying to make a request that takes 10 seconds to process (like a user requesting a report consisting of multiple SQL queries)? You get a connection reset.
I must also must point out the HN guidelines because you bring a combative tone to this entire conversation which is not helping it.
> Be kind. Don't be snarky. Converse curiously; don't cross-examine.
> The existence of PASV mode and STUN/TURN is because the end-to-end addressibility of the IP protocol was broken with CGNAT.
But isn't all that still necessary as long as the typical user isn't going to be opening their firewall on those ports to arbitrary incoming connections? That's the whole point here.
STUN (or something similar) yes (since you'll need to coordinate outbound traffic which creates the appropriate inbound rules), TURN no (since STUN will always succeed with stateful but non-translating firewalls).
And STUN scales almost infinitely better than TURN.
>> The biggest one is people seem to equate NAT = router/firewall. This is absolutely not the case,
I dont think anyone equate that, but IPv6 proponents refuse to recognize that decades and decades, especially in home users, and SMB space, NAT was a layer of the security model, often times one of the biggest
Right or wrong is irrelevant, that is/was the reality
Just tossing IPv6 as a replacement for ipv4 with out factoring that in while simply screaming into the void "NAT IS NOT A FIREWALL" will be of little comfort to the elderly retiree that has their home computer ransomwared, or the small business that is put under due to a cyber attack because the ipv6 address was strait on the public internet
Yes, and every router has to do it properly by default, which so far they haven't really been. NAT is a lot harder to do wrong, cause the local IPs aren't even addressible.
Its not harder to do wrong, its just less noticeable when done wrong, it's been a security consideration since NAT was created, and a persistent issue since then:
It's defense in depth. I don't understand if and how this exploit allows an attacker to hit port 80 on my PC for instance, but either way it looks like a pretty sophisticated attack only discovered in 2021, and I still don't see panic over it.
If they haven't really been, then NAT wouldn't be working either, that's the point I'm making. NAT requires connection tracking to function, because NAT is actually an extra step on top of a basic stateful firewall, and the mapping part isn't the part that provides security, it is the connection tracking part.
Then disable it. IPv6 SLAAC privacy extensions are device-controlled, meaning neither your ISP nor your router can force you to use/not use them (unless they're so incompetent that they do things like hand out /128s).
I disable privacy extensions on my server so that I can give it a static IP within the prefix, so I can vouch that (at least on Linux) the process is quite simple.
Well, what I do is disable ipv6. I don't want the possibility that this is misconfigured, especially if the defaults tend to be wrong. Maybe my router doesn't even respect my firewall settings, like this: https://community.verizon.com/t5/Fios-Internet-and-High-Spee... Maybe the customer is wrong, but this shouldn't even be a question.
The rare times I want something publicly accessible, I use DMZ or port forwarding.
Not really. Many home routers used to assign all ports to the first device to connect to the router, and you'd need to setup NAT just for your second computer. Eventually the default settings wised up.
It is much more probable that security defaults will be much tighter today than they were when ADSL initially took off.
> Just tossing IPv6 as a replacement for ipv4 with out factoring that in while simply screaming into the void "NAT IS NOT A FIREWALL" will be of little comfort to the elderly retiree that has their home computer ransomwared, or the small business that is put under due to a cyber attack because the ipv6 address was strait on the public internet
This is definitely what I'm seeing. IPv4 is really engrained in us - I actually had a really hard time conceptualizing how things worked until I forced myself to learn by deploying dual-stack and ipv6-only networks.
The major downside I see right now is that "addresses are harder to memorize," but there are solutions to that as well.
So we're supposed to do things wrong forever because some router vendors are too incompetent to set a firewall as well as NAT? That doesn't seem like a good approach to me.
Right and wrong in this context is subjective there are many things in IPv6 that I find to be wrong convoluted and overly complex
When IPv6 was created they had the opportunity to just make it an expansion of the IPv4 space they chose not to do that and instead they added in a bunch of wish list items that were not needed to accomplish the goal that they were seeking to do which was prevent the exhaustion of IPv4 addresses
Absent address space exhaustion I massively prefer working with IPv4 than I do IPv6
lmao, I heard five dozen arguments against IPv6, but "it's spyware!" wasn't one of them until today.
CGNAT on IPv4 is not gonna save you from the Big Brother. IPv6 has many issues, but it is disingenuous to say the least that "it's a distraction from the big problems." The big problems you're talking about are completely unrelated to your IP packet version, and are not to be fought easily on this battlefield.
> * "OMG Every device needs a publicly addressable IP!!!"
> ok, but why?
So we can get rid of STUN/ICE/etc and make peer-to-peer easier. All you're left with is hole punching through your SPI firewall (no worse than today).
> Are you _really_ just going to allow random traffic into your network?
I don't know why this misconception is so wide spread: globally addressable ≠ globally reachable.
Firewalls still exist with IPv6.
Before I recently changed ISPs, I was with one which gave out IPv6, and so all devices had an address (including things like my printer). But I couldn't initiate connections from the outside in—only replies to internally-initiated messages were let in by my Asus.
Even if things were wide open—which they were not—good luck scanning a /64.
> So we can get rid of STUN/ICE/etc and make peer-to-peer easier. All you're left with is hole punching through your SPI firewall (no worse than today).
Do you really think Roomba is going to let you run your Robot Vacuum without contacting, er permission, from their data center in Virginia?
Currently my roomba is behind a nat and still insists on contacting their main data centers. And if i turn off the internet to my nat the roomba will run but none of the advanced cell phone related features of the roomba will work, even though my cell phone is connected to the same wifi network in the same nat as the roomba.
So this is completely unrelated. IP addressing schemes will not change the business methods of large consumer device companies.
Removing a cost and an artificial shortage may cause many innovative things to happen. History is full of examples when lower costs and higher availability of something have caused a burst of innovation.
What I meant in the grandparent comment is that if a company makes it their business strategy to have all devices call home, they will do that regardless if they use ipv4 or ipv6. But if ipv6 is widely implemented and there is no cost to ip addresses, it is entirely possible that another company can create an ap that allows you to directly communicate to your devices without using a central server.
> That's exactly the point; they market it as if it would make a plethora of new and innovative things happen but in reality they will allow none of it.
How much innovation and applications have been stymied by artificial network-layer barriers:
> First is actually a more subtle issue... the Skype peer-to-peer network architecture elected certain nodes to be "supernodes", to help maintain the index of peers as well as handle parts of the NAT/firewall traversal for other peers.
> So we can get rid of STUN/ICE/etc and make peer-to-peer easier. All you're left with is hole punching through your SPI firewall (no worse than today).
There’s (IMO) a much better reason: so your endpoints can have globally unique addresses. If I have a service in Google Cloud and a service in AWS and an on-prem service and a customer service and ten different upstream services from ten different hosted providers, I want these services to have different addresses, TYVM. And I want to configure my networking to them without needing to worry about whether all parties actually agree on the addressing scheme.
This is far more important than actually making anything globally routable. If my AWS thingy is 192.168.3.7, I don’t need whatever random third party service I’m using to be able to route to 192.168.3.7 (and I’d probably prefer that it not be able to route there). But I don’t want to worry about the service provider using 192.168.3.7 for another purpose.
I’d also like traceroute to work without having a bunch of intermediate hops where the addresses simply cannot be mapped to their owners without extra side knowledge of the network topology.
I'd argue having to run STUN and TURN relays imposes additional costs on service operators and therefore increases centralization instead of decreasing it. Furthermore, if Amazon (of all companies) was pushing for IPv6, we'd see a little more IPv6 support at least on their public endpoints, as I commented elsewhere.
As for public reachability, most OSes have a firewall of sorts (nftables, pf etc.) and can be configured to block traffic by default; on consumer OSes they already do so. There's also the local unicast range fc00::/7, which seems conveniently forgotten about in these kinds of comments.
Here is something very simple, with no self flogging and no circus hoops. I do not want to pay for a number. There is no shortage of numbers. In fact there is an infinite amount of them. There are many things I am forced to pay for and their prices keep going up and up and more things get added every year. Well on this one I fight back. I do not wish to pay for the use of an arbitrary number just so my device can be connected to a network.
Of all of the arguments, I personally find this one the weakest. As you're describing your IP address makes it no different than a phone number for your mobile.
This counterargument doesn't really make any sense. I don't pay for my phone number. I got my phone number for free I don't know how many decades ago from a provider that doesn't even exist today. Ever since, I've been carrying it over when switching a provider and it's still free. I pay for things such as data, but not for the number.
For me it's not about any of that, it's more about a restricted supply of IPv4 that only big corporations own and having to pay ever increasing rent for them
Anti-ipv6 is like the NIMBYism of IP address space, why can't we just "build" more to inflate the supply and crater the prices of existing ones?
> * "It's so hard to initiate a connection to something behind a ipv4 NAT firewall!! "
> Is that going to change with ipv6?
Yes, because stateful firewalls are much easier to consistently traverse than NAPTs. This alone is a huge advantage for P2P applications.
Behind a (usually symmetric) CG-NAT, I have no way to directly connect to anybody else behind one without a relaying server (which are expensive and add needless latency).
> Are you _really_ just going to allow random traffic into your network?
No, but nobody is suggesting that.
> ipv6 is a distraction from the really problem of control and privacy
IPv6 is also doing nothing to combat pollution by microplastics and overfishing.
We need IPv6 because we're out of IPv4 addresses. When you launch a new ISP and knock on the door of a RIR like RIPE, they don't have any IPv4 addresses left to allocate and so you're put on a waiting list. The solution is IPv6. Even without allocating an address per device, without IPv6 just the status quo of every customer having an IP address is no longer possible.
The predecessor of my ISP introduced full IPv6 support for all customers 15 years ago. The only argument against at this point is inertia.
If that's the problem, then the solution would've been just adding more address space to ipv4, preserving all existing addresses and pretty much everything else about it. 1.1.1.1/32 is still 1.1.1.1/32, and new ISPs can take blocks like 72.33.22.11.33/40 once enough routers are updated to support them. This could've even used the exact ipv6 packet structure, making it quite similar to v6 under the hood but more like v4 from the user's perspective.
Instead, ipv6 created a separate world, with extra goals like making every device addressable (aka removing NAT), using randomized addresses, and resetting all ownership of existing blocks. "We're out of addresses" is not a good excuse for all that.
> If that's the problem, then the solution would've been just adding more address space to ipv4, preserving all existing addresses and pretty much everything else about it.
That's not possible. IPv4 addresses are 32-bit numbers. Once you change that, you're no longer "preserving existing addresses".
> once enough routers are updated to support them.
That's actually "once all routers and end devices are updated to support them". As the classic spamsolutions.txt says, "requires immediate total cooperation from everybody at once".
> This could've even used the exact ipv6 packet structure, making it quite similar to v6 under the hood but more like v4 from the user's perspective.
Changing the packet structure means changing all hardware and software (yes, software too, the API for IPv4 uses 32 bits for the addresses). The changes visible to the user are the easy part.
> Instead, ipv6 created a separate world, with extra goals like making every device addressable (aka removing NAT),
It's more like "not needing NAT" than removing it; port mapping NAT is not a part of IPv4 (it's a hack on top of it), and it can be done identically in IPv6, but few do it on IPv6 since it's not necessary.
> using randomized addresses,
This is an optional thing which was added later; nothing in IPv6 requires randomized addresses, but IPv6 makes them possible by virtue of having enough free bits in the address. Were randomized addresses possible with IPv4, we'd see them happening.
> and resetting all ownership of existing blocks.
IPv6 has done no such thing; the existing IPv4 blocks are still there.
> That's actually "once all routers and end devices are updated to support them". As the classic spamsolutions.txt says, "requires immediate total cooperation from everybody at once".
This point cannot be emphasized enough. To quote Hyrum's Law [0]:
> With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
And for networking this means that, even if the NRO decreed that all reserved/testing IPv4 blocks [1] would be publicly routable and turned over to the RIRs for allocation, those blocks would be effectively unusable. It doesn't matter how many RFCs you produce saying "you must assume these addresses will be someday used", networking hardware and software has ossified around specific expectations pertaining to what addresses are valid and invalid, what protocols are acceptable, etc.
A great example of this is TLS 1.3: due to protocol ossification, the spec had to be rewritten to be more similar to TLS 1.2 because network middleboxes kept assuming it was a threat and blocking the connections [2]. This is also the reason SCTP has yet to gain widespread adoption, and why any new layer 4 protocol is likely doomed to fail: networking hardware hates anything that deviates from the acceptable traffic patterns which have been hard-coded in, RFCs be damned.
Imagine if previously unused IPv4 blocks started getting allocated. You'd be cut off from most of the internet, and most of the internet would be cut off from you. It wouldn't be enough, of course - even if all 2^32 addresses were publicly routable, that's still not even enough for 1 IP per person, you'd still have to rely on NAT, and all the problems it causes. (This is also why I think suggestions like "organizations like Apple who have a /8 but barely use it should just give up those extra IPv4s" are misguided and really understate of the scale of the problem - it's just putting a band-aid on an open fracture that cut your femoral artery.)
> That's not possible. IPv4 addresses are 32-bit numbers. Once you change that, you're no longer "preserving existing addresses".
I am uniquely employee number 6100. That field is 32 bits in HR's database. If they make it 64-bit, I'm still 6100.
> That's actually "once all routers and end devices are updated to support them". As the classic spamsolutions.txt says, "requires immediate total cooperation from everybody at once".
No it doesn't, it requires gradual cooperation, as the 4.1-compatible hosts will still speak v4 as needed. Same as how v6 stack support was added even to hosts not using it.
> It's more like "not needing NAT" than removing it; port mapping NAT is not a part of IPv4 (it's a hack on top of it), and it can be done identically in IPv6, but few do it on IPv6 since it's not necessary.
Yeah but the goal is to remove it. The feature set of v6, including random addressing, is intended to support p2p applications. The authors of ipv6 did not envision NAT being enable by default. Defaults and intent matter more than technical details here.
> IPv6 has done no such thing; the existing IPv4 blocks are still there.
They aren't there on practically any ipv6 network, despite an optional ipv6 extension for v4-mapped addresses. That's the critical difference vs what I've described.
It would be a lot simpler for IoT manufacturers to let folks direct connect to their devices over IPv6, BUT that puts all the network management onto the user, which is a support nightmare.
Admittedly this was a couple years ago, but last I checked, Azure managed PG didn't support v6. (We're mostly moving away from Azure for other reasons … so I'll probably never re-check.)
GKE on GCP doesn't really support v6. (If you selected the v2 "data plane" when you created your cluster, then it can, assuming the vnet can. If not, then not yet, and there's no way to upgrade data planes presently.) Peering VPCs doesn't work with v6-only, meaning if I want to peer VPCs, I pretty much am forced to solve all the problems v4 has with that … which defeats the entire point of a v6 peering. Cloud NAT doesn't support v6, so I'm super not clear on how ULA VPCs are supposed to work.
I'm not sure what the AWS services not supporting IPv6 has to do with charging for public IPv4 usage. Private IPv4 is still free so can access services over endpoints. NAT gateways cost the same and can access services over public IPv4 network.
AWS also added IPv6 NAT64 gateway so it should be possible to run IPv6-only internally and still access AWS services and the rest of the Internet.
This would be acceptable if this internal route was already configured for free. However, it appears VPC endpoints have their own pricing[1], at which point one must carefully consider whether paying up for the IPv4 address is the better option.
This entire thread is about the additional costs imposed on a publicly accessible IP[1].
Granted, there are other (but similarly expensive) workarounds such as NAT gateways[2] for outbound connectivity or the cheaper NAT instance method which AWS doesn't support any more, but there are alternatives[3]. However, for use cases requiring inbound connectivity such as setting up websites on EC2 instances, or using an ELB which need internet access, you need an IPv4 address and these charges definitely rack up.
Ah, I think i had the connectivity backwards. I thought the complaint was about hosts connecting to these services, not inbound connections to hosts.
Ultimately, they will probably want people to solve it with service endpoints, and give preferred pricing on that. But I kind of get why that is a bit wigged out. Because it locks more architecture into them as a vendor. I'm not really sure putting a public ip is a good solution to this, but it is kind of scary because suddenly we are deciding infrastructure decisions more based on how they are being priced. Needs regulation.
Interestingly, S3 and DynamoDB access from privately addressed IPv4 VPCs is free, since it's implemented as routes not endpoints, and although rather constraining you can definitely build things with that.
Case in point, I had some internal instances that very occasionally want to pull files from a partner's endpoint. Previous solution, NAT gateway. New solution, DynamoDB request table streamed to AWS Lambda and results in S3. Caveat programmer: only suitable if the task is not latency sensitive.
DynamoDB/Lambda are not everyone's cup of tea, but it's nice to have options.
We [1] just went through a process to remove public ipv4 IPs for some of our internal facing EC2 instances.
Just in case some people are on the same boat. Here's a simple process [2] to remove public ipv4 IPs from existing EC2 instances (no need to shutdown / reboot) -
Had IPv6 been a superset of IPv4, we would have switched 10 years ago.
IPv4 1.2.3.4 becomes IPv6 0.0.0.0.1.2.3.4
Owning IPv6 0.0.0.0.1.2.3.4 means you also own IPv4 1.2.3.4, because addresses that begin with 4 zeroes mean they also own the equivalent IPv4 address.
Owning 2.2.2.2.1.2.3.4 means you do not fully own an IPv4 address. In this case you'll have a NAT IPv4 address.
If you connect to 1.2.3.4 you use the IPv4 protocol. If you connect to 0.0.0.0.1.2.3.4 or 2.2.2.2.1.2.3.4 you use IPv6 packets that are identical but larger header to accommodate the bigger address.
As long as you have an IPv6 that begins with 4 zeroes, you are fully compatible with everything, without needing any kind of NAT. If you have an IPv6 2.2.2.2.1.2.3.4 then you'll need NAT to connect to IPv4 addresses, but can connect directly to IPv6 addresses.
This comes up every time, but it doesn't make any sense. Routers, software, IT professionals, would've all been just as happy to not support IPv4.1 as they have been to not support IPv6. At this point though the inflection point has already been passed adoption-wise and AWS needs to just do the thing already.
v6 introduces more hurdles. New different kinds of addresses (link-local, etc). No more NAT by default. Existing v4 addresses not accessible over it. In contrast, switching to this "v4.1" would be low-risk. You just support longer addresses, that's it.
Supporting longer addresses still means there's no forwards compatibility from v4. Neighbor discovery replacing ARP, link local addresses, etc. are not really the source of headache when it comes to v6 deployments - the legacy environment that v4 created is.
v4.1 host is still addressable from v4 host as long as its address is 32-bit. So they don't start leasing out the longer ones until v4.1 adoption is good enough. In the meantime, you slap in v4.1 hardware without having to even think about it.
You can also make compromises with NAT, like handing out 40-bit addresses that are auto-translated to/from 32-bit with 8 bits going into the port.
And a IPv6 host is still addressable from an IPv4 host as long as it has an IPv4 address. You've done absolutely nothing to spur adoption - because the mere fact that you extended the address space and required infrastructure all across the globe to be replaced and reconfigured to support it causes the exact same issues.
Again, neighbor discovery, SLAAC, link-local addressing, none of it has anything to do with how long it's taken the world to adopt IPv6. The fact that they have to do anything at all is, and there's no solution around that.
My v4.1 address would be the same as my v4 address if I was on v4 before. Even if I turn off v4.0, I'm still reachable at the same address on v4.1. This is not the case with v6. That's the problem.
Furthermore, the longer addresses would be routed similarly to the 32-bit ones: dst=1.1.1.1.2 would go to the 1.1.1.1/32 router the same exact way dst=1.1.1.1 does. Only difference is what that router does with the packet.
> Furthermore, the longer addresses would be routed similarly to the 32-bit ones: dst=1.1.1.1.2 would go to the 1.1.1.1/32 router the same exact way dst=1.1.1.1 does. Only difference is what that router does with the packet.
IPv4 packets have 32-bit address fields in the packet header, 1.1.1.1/32 still needs to understand IPv4.1 packets or it's going to think you're sending it corrupt garbage.
Again, nothing changes - if you do anything to change the structure of the packet header the same problem happens, no matter what.
Yes, the packet header changes. Basically all routers have supported v6 packets for a while, which was a large effort, but evidently it was possible. And yet, we've not collectively adopted v6. We are stuck with dual stacks.
If the same support was added except with the /32s preserved, everyone could've switched to v4.1 with basically no change to the routing, DNS, NAT, etc. Not a big jump like going to v6. Then ISPs could later divide up their /32s and hand out, say, /88s to customers. Address crunch would've been already averted.
> with basically no change to the routing, DNS, NAT, etc.
Except you're wrong on all of the above.
We'd still need a completely different "v4.1" routing layer, because a /32 could never be a subnet while also being a distinct endpoint, so we'd have to treat any routes smaller than a /33 as being the old IPv4 world while a /33 and bigger would be v4.1. So we still end up with the exact same split, except now our address space is an even bigger fucking mess instead of the clear break v6 is giving us to make a more hierarchical network (eventually getting rid of the ludicrous routing table bloat we currently have, though we really need to come up with a better solution for multi-WAN failover in small networks to avoid everyone and their dog needing an ASN and BGP session to have a HA setup).
DNS would still need changes, because the struct for an A record still contains a 32-bit address.
Nothing stopped us from using NAT with IPv6, but it sucks and broke end to end connectivity so while we already had to break the world to make the switch why not deal away with the ugly hack while we were at it.
There is no world in which any successor to IPv4 did not have a long transition time without government mandates, and that's basically what it is taking to get ISP's and cloud providers to adapt it (the whole reason AWS, Azure, GCP, et. al. are slowly getting their shit together is the US government is mandated to go single stack).
They need to retrofit those things to support longer addresses, but I mean the existing data and rules don't change. The DNS records and IP routes stay the same. And no, you don't introduce special v4 vs v4.1 routing. For this phase, everyone is still using /32s.
Then once basically everything is speaking v4.1 and ok with longer addrs, it's trivial to split up /32 blocks as desired. And yes, NAT stays for most people. That's fine, you'd still be free to disable it and give your devices public IPs if you want.
> Even if I turn off v4.0, I'm still reachable at the same address on v4.1. This is not the case with v6. That's the problem.
That's not the problem.
Being reachable "at the same address on v4.1" (or v6) does not mean that v4 hosts can reach you. In order for v4 hosts to reach you, you have to be doing v4, because v4 hosts will be sending you v4 packets. If you've turned off v4 then that won't work. It'll work if you leave v4 on... but then you're just doing dual stack, and v6 can do that too.
The problem here is that you haven't realized that what you're describing is no different to v6's approach, just phrased differently.
As far as I can tell, nearly every system has an ipv6 stack included, but they are often choosing not to enable it. So ipv6's adoption problem is no longer related to a lack of capabilities on hosts. Do you agree with that?
Let's say every ipv6 stack we have today were instead playing by "ipv4.1"'s rules, meaning same addresses and routing as v4 (and possibly the same packet format as v6). Nobody is taking advantage of longer addresses yet, but the bits are there for later. This also means old DNS entries are still valid, and NATs are still common. What would stop many people from flipping on ipv4.1 mode?
How is that not what we're already doing? Almost everyone with a v6 stack still has the exact same v4 address they had before, using the exact same routing as v4. Old DNS entries are still valid, NAT's still common.
The only difference seems to be that some people are already making use of the bigger address space, rather than waiting. And that's surely a good thing? If you told everybody to wait until absolutely everything supported it, you'd be waiting forever, and you'd be giving up the benefits of having a larger address space available the entire time... and you don't have a way to force people to wait anyway, so that idea wouldn't even implementable in the first place.
There is no way a router that does not understand the address extension is able to route packages to the larger address spaces correctly. So this is not possible to do.
IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+.
And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere.
But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection.
--
So "just" expanding IPv4 to IPv4+ ends up being the exact same amount of work as ended up with IPv6.
The only thing you could say with "just" more addresses is keeping ARP and the like (instead of DAD, etc).
Building it is the same amount of work as building ipv6 support. Adopting it is not the same work as adopting v6. We already have ubiquitous v6 hardware/software support, but it's a whole 'nother thing to actually use it.
1. Add v4.1 support, but keep using 32-bit addresses.
2. Start using >32-bit addresses when ready.
By the way, the WWW has gone through transitions like adopting HTTPS and banning old versions of TLS with it. Crucial to that was having transitional periods where both things work. This step was missed in ipv6 rollout.
> 1. Add v4.1 support, but keep using 32-bit addresses. 2. Start using >32-bit addresses when ready.
When who is ready? Different people/organizations will be ready at different times.
Some people will not be able to get IPv4 addresses so will be 'stuck' with being IPv4.1-only.
Given the finite IPv4 addresses, some will move the IPv4 addresses to revenue-generating areas and will go IPv4.1-only internally—which is what prompted Microsoft to be IPv6-only/first internally: their IPv4 addresses got sent to Azure:
And once that happens, which it would inevitably too with IPv4.1, we're at:
If you have a IPv4-only network elements/devices, they cannot talk to IPv4.1-only devices/services (and vice verse), so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an IPv4.1 network is an island in a sea of IPv4, so you have to have tunneling. Of course some may have both IPv4 and IPv4.1, and want to talk to something has also has IPv4 and IPv4.1, so now you have to have code for source/destination selection.
Switch to >32-bit when enough routers/hosts support it, i.e. they can parse the new packet format. We've already accomplished that with v6 long ago.
In the meantime, ISPs that cannot afford enough 32-bit addresses for their customers can hand out 40-bit ones and perform a NAT-like translation. Same as what they're doing now with cgnat, except there's an exit strategy.
Individual hosts decide. Same as how I can no longer visit httpS://chase.com on my ancient PC that doesn't support HTTPS, let alone a modern web renderer. Chase has left it behind.
ISPs also decide; they turn off their cgnats and start handing out /48s etc, at the latest when the cost of leasing /32s addresses exceeds the cost of being incompatible with a tiny few straggling hosts.
The lack of NAT represents the removal of an issue. The fact that you already understand NAT does not reduce the actual, real complexity that it is introducing.
NAT is a more desirable form of security than a firewall for most users, despite it not being intended for that purpose. It should be the default, and if you don't want NAT, go ahead and don't use it.
> NAT is a more desirable form of security than a firewall for most users...
I don't agree with this. First, most users don't know or care about security. So neither is more desirable for them. But also, on its merits NAT isn't more desirable. It provides zero security that is not provided by a simple default deny inbound rule on a firewall. And on top of that, it introduces additional complexity that even a non-technical user has to contend with sometimes (port forwarding).
NAT is not and never has been a security mechanism. We need to stop trying to shoehorn it in to a role it isn't meant for.
It's not shoehorned, though. Corporate and home users find it convenient. It's very hard to screw up, unlike v6 firewalls which often have bad defaults or possibly don't work as intended. Especially when one of the other goals of ipv6 is to enable p2p applications, which might lead to permissive defaults.
My home router has one public IP and many private IPs. No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports. With v6, I'd instead be double-checking that my router firewall is doing its job, e.g. https://community.verizon.com/t5/Fios-Internet-and-High-Spee... . Even if the router turns out to be WAI, I shouldn't have to question that!
> My home router has one public IP and many private IPs. No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports.
Only because your router also has a properly configured stateful firewall for ipv4 as part of its NAT implementation. I have a Mikrotik CCR2004 at home, I can enable SNAT without appropriate firewall rules and have any other customer of my ISP on the same subnet send packets towards the WAN interface of my router and have it happily forward them onto my internal network.
NAT is implemented using a stateful firewall, but the mere presence of it does not mean the firewall is configured to reject unestablished connections from outside. IPv6 just exposes such poor configurations more readily.
NAT is not a firewall. It's not actively blocking anything, rather it's actively forwarding things. If NAT drops the ball in various ways, the router still doesn't know to send dst=71.177.17.171 to my PC on 192.168.1.2 vs another one. I mean sure a NAT could intentionally pick my local IP as the lucky winner of every inbound packet, but how does that happen on accident.
> IPv6 just exposes such poor configurations more readily.
Yes, that's the exact dealbreaker for me and many corp environments.
> If NAT drops the ball in various ways, the router still doesn't know to send dst=71.177.17.171 to my PC on 192.168.1.2 vs another one.
Yeah, it does in many (most) cases. That's precisely why my firewall rules on my own router look like this:
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
You would have to have a system on the same subnet as the public interface of my router to try and take advantage of these rules not being in place (because of the nature of how IP forwarding works), but without them it would absolutely forward them because the route table just looks like this
Note, it's just one route table - with IP forwarding enabled the only thing stopping anything coming in the WAN interface from being capable of forwarding to the LAN interface is the firewall rule.
> Yes, that's the exact dealbreaker for me and many corp environments.
My point remains, NAT is not a security measure - any corporate environment who thinks they are protected merely because they have NAT enabled is fooling themselves. The exact same set of firewall rules I need to properly secure IPv4 traffic are the same ones I need for IPv6 traffic; the only reason I haven't bothered to copy/paste them is because my ISP in 2023 still does not hand me an IPv6 allocation.
> You would have to have a system on the same subnet as the public interface of my router
Making sure I understand, you mean an attacker sends dst=192.168.1.2 directly to your router without any extra hops, which the router forwards to your PC. I don't know if that's what happens in practice (there's no legit reason to do it), but I can see a router doing that.
Yes, you shouldn't rely on NAT alone, rather the router should have a firewall. Usually it does, but not always. When that fails, at least it's still pretty hard to exploit. How often does this kind of attack occur?
> Making sure I understand, you mean an attacker sends dst=192.168.1.2 directly to your router without any extra hops, which the router forwards to your PC. I don't know if that's what happens in practice (there's no legit reason to do it), but I can see a router doing that.
Yes, you understand the problem correctly. The fact that there's no legitimate reason to do it is precisely why routers have a default set of firewall rules to prevent it. Hell, as long as you control enough of the network to be able to route such a packet to the WAN interface of your router it doesn't even have to be on the same network segment - so compromise within your ISP's network would open you up to attack if you just assumed NAT alone without a proper stateful firewall would save you.
> How often does this kind of attack occur?
Due to needing to be on the same layer 2 segment or having control elsewhere of the network this would very much be a targeted attack. But one any enterprise should care about, and why the assumption that NAT alone is what protects you is dangerous. NAT just does source/destination (ip, port) rewriting, that's it.
> It's very hard to screw up, unlike v6 firewalls which often have bad defaults or possibly don't work as intended.
???
Firewalls generally have inside and outside: default-deny any new connections from the outside and you're done. This is how all CPE gears ships out of the box.
> Especially when one of the other goals of ipv6 is to enable p2p applications, which might lead to permissive defaults.
For this you need hole punching, with on CPE gear is done with UPnP and/or PCP, the exact same protocols that are used with IPv4 NAT. (But of course applications also have to futz around with TURN/ICE/STUN if there's NAT.)
> No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports.
When I was still with a residential ISP that did IPv6 this was the exact same with all of my home devices behind my ten+ year old Asus.
Further, because you only have one public IPv4 address, someone can scan just that address to see which ports are forwarded. People regularly scan the entire IPv4 address space: 2^32 addresses is not a difficult task.
With IPv6, they'd have to know the IPv6 address of your service that you had opened to the public. If you hadn't advertised the address publicly, an Internet rando is not going to find it: good luck remotely scanning a single /64 (never mind a /60 or /56 that many ISPs hand out).
Not at all. This would be much easier to migrate and support.
Nowadays you have two entire separate stacks, each with their own firewall rules. That's why the first thing I do is outright disable IPv6 because of the potential security issues due to misconfiguration.
The hardware and operating systems have supported IPv6 for a very long time. The problem is that it's a pain in the ass to maintain 2 stacks simultaneously, that's why adoption is so slow.
People keep trotting this out (and there is another conversation about the same topic) but there have been no experiments or evidence to show IPv4 + an additional options header for the additional address parts to have worked better, in terms of compatibility and/or vendor uptake.
A similar issue came up when the internet migrated from class-based to classless IPv4 routing, and in that case, there were experiments that showed most networking gear continued to work and there was little to no adverse effect due to this switch.
just a quick aside, but the ipv4 address is mapped inside the ipv6 address space. 192.0.2.1 is represented in IPv6 as ::ffff:192.0.2.1. This is known as IPv4-mapped IPv6 addresses.
You wanna bring psychology into it, it seems like v6 abuses the crisis of low address supply to sneak in a bunch of unrelated changes. If the solution were truly just aimed at adding more addresses, it would've looked very different, for instance the existing ipv4 addresses would've been carried over to ipv6.
Another thing about humans, addresses like 2001:4860:4860::8888 look awful. You gonna tell me that's an upgrade over 8.8.8.8? And 192.168.1.2 becomes fe80::1c03:b6d1:9222:3a02. Why can't I keep 192.168.1.2?
There isn't a strong enough consensus that these were mistakes, aside from making the address size too small. Maybe removing fragmenting was uncontroversial, but aside from that, ipv6 seems more complicated than ipv4 in many ways. Special kinds of addresses (link-local, v4-mapped, ULA, etc), special ways to write them, and so on.
> And how would you propose making larger addresses without making them longer?
Pre-existing ones don't need to be longer. If my IP before was 1.2.3.4, it stays that way. If a new ISP can't afford /32s for its customers, maybe it hands out /48s like 1.2.3.4.5.6, and if there are ever 282 trillion users, the next one is 1.2.3.4.5.6.7. At home on my LAN, ofc 192.168.1.2 is free and I keep it.
IPv6 addrs are only long because they're spread out.
You give one example (ULA) and I can raise you four: 192.168.0.0/16, 10.0.0.0/8, 172.12.0.0/12. You give one example (LLA) and I can raise you another: 169.254.0.0/16.
So come on now with the "complexity" talks. It's obvious that you are not even educated in IPv6 technologies, or else you will be talking about NDP and others, not mere addresses.
>Pre-existing ones don't need to be longer
We cannot do that even if we wanted to do so.
Think about this: computer A supports only the "shorter IPv4" and computer B supports both the "shorter" and "longer IPv4". Now computer B has the IP "1.2.3.4.5". How can computer A, which supports only the shorter IP address, connect to computer B? By the magic of having hindsight? No.
Therefore: Congratulations! You have just repeated the current IPv4-IPv6 pain point without being aware of it. Which is fine, but note that in your comments you have tended to act like your solution is better than IPv6's.
> You have just repeated the current IPv4-IPv6 pain point without being aware of it
The current pain point with ipv6 is not simply that hosts/routers need to support the new packet header. Vast majority of them do by now, right? But going v6 means redesigning your network. If all the addresses, routing, etc were kept the same as before and switching just meant handling a different packet header, it'd be a much easier transition. Then once everyone's on v4.1, people could start using longer addresses.
> It's obvious that you are not even educated in IPv6 technologies, or else you will be talking about NDP and others, not mere addresses.
They're mere addresses in ipv4, but not so in ipv6. ULAs are routed specially, basically as a replacement for NAT. See, I can use jargon too, but it doesn't matter here. From a common sense standpoint, there's no way that making the address field bigger requires changing all existing addresses.
>If all the addresses, routing, etc were kept the same as before
It is a natural consequence of having a greater address space.
If you decide to expand the address to become 128-bits long (heck, even 64 bits), you will also expand the routing table and risk overwhelming the limited memory of some routers.
Hence, we need to find ways to aggregate the routes and make the route table more efficient, and that's what you are looking at with IPv6 addressing. The /64 per network requirement effectively cuts the size of your route table in half, for example.
But even so... your point that:
>Then once everyone's on v4.1, people could start using longer addresses.
...is incredibly naïve. It took decades to have everyone support HTTPS, and to this day we still have HTTP-only websites.
>ULAs are routed specially, basically as a replacement for NAT.
For god's sake, no. It is better to think ULAs are specifically used for internal communications than to think they are for NATs.
Like I said, you really don't understand IPv6 at all, stop pretending that you are, lest you repeat all the same so-claimed "mistakes of IPv6" in your own solution.
>no way that making the address field bigger requires changing all existing addresses.
Except that when you are moving pre-existing machines out of a NATted network, you will need to give them new addresses, and then you realize that you have to renumber everything anyways in the end - otherwise you will have locally proximal machines in vastly different subnets.
> Hence, we need to find ways to aggregate the routes and make the route table more efficient, and that's what you are looking at with IPv6 addressing. The /64 per network requirement effectively cuts the size of your route table in half, for example.
Maybe I'm misinterpreting what you're saying here, but expanding your address space doesn't suddenly mean you have more routes to deal with. Like, ISP is routing all 1.2.3.4/32 traffic to my router; they don't care what addresses it forwards to underneath that. The ISP could support more customers by handing out /40s, but that's a gradual increase.
Unless you're saying that just supporting the longer field means more memory is used for the existing addresses (true), but idk if that means you have to re-optimize all your routes.
> ...is incredibly naïve. It took decades to have everyone support HTTPS, and to this day we still have HTTP-only websites.
Most sites are HTTPS-only because it's safe to assume every client will support it. Now how many big websites are ipv6-only?
HTTPS is the networking migration success story I like to point to, in fact. Just the right amount of force was applied, including banning old TLS versions later.
> For god's sake, no. It is better to think ULAs are specifically used for internal communications than to think they are for NATs.
I didn't say they are for literal NATs. They are replacement for the private networking feature of NAT, where your LAN hosts aren't reachable from WAN.
> Except that when you are moving pre-existing machines out of a NATted network, you will need to give them new addresses, and then you realize that you have to renumber everything anyways in the end - otherwise you will have locally proximal machines in vastly different subnets.
If you're moving pre-existing machines out of a NATted network. Not everyone has to.
>doesn't suddenly mean you have more routes to deal with.
Routing tables don't magically change their structures according to the routes either. Think about this: the routing table must provide at least 40 bits of space to accomodate for possibly 40-bit routes or 32-bit routes. After all, the router cannot tell what routes you are putting in when it is manufactured.
If you increase your address space by any number of bits, your routing table must necessarily increase its size.
>I didn't say they are for literal NATs.
Private networking is private networking, NAT is NAT. The fact that you are conflating those two makes me highly worried, especially in the context of Internet Protocol designing.
>If you're moving pre-existing machines out of a NATted network. Not everyone has to.
Now here is your very fundamental misunderstanding of any next-generation Internet Protocol! If we are not getting rid of NAT, there is no point in introducing larger address space in first place.
> If you increase your address space by any number of bits, your routing table must necessarily increase its size.
So you're talking about the second thing I mentioned. Supporting N users requires storing at least Nlog(N) bits of addresses in total. Going to /40 doesn't seem like a big enough increase to require redoing all the routes. And even if it is, an ISP could even roll out v4.1 sticking with /32s for now, keeping their routing tables exactly the same and leaving the expansion effort for later.
> Private networking is private networking, NAT is NAT. The fact that you are conflating those two makes me highly worried, especially in the context of Internet Protocol designing.
In IPv4, a very common reason you'd have a private network is because of a NAT, even though they aren't the same concept. To help get rid of NAT in IPv6, they added ULAs. That's all I mean.
> If we are not getting rid of NAT, there is no point in introducing larger address space in first place.
The point is that we're running out of addresses, like ipv6 proponents keep saying. Everyone who needs public IPs for any reason should be able to obtain them cheaply. This doesn't mean that NAT needs to disappear everywhere, though some users (like ISPs running CGNATs) might be happy to either ditch their NATs or split them up later on.
And this is what I said in my original comment, ipv6 has extra goals (like removing NAT day 1).
>And this is what I said in my original comment, ipv6 has extra goals (like removing NAT day 1).
Extra goals? Removing NAT? Come on now... Don't act like NAT was invented along with the Internet itself, you know it wasn't.
And again, never ever conflate NAT with private networks.
NAT is a packet-modifying technique that is closely associated with stateful firewalls, but it still ain't firewall. If you want private networks, you would actually use a firewall, not NAT.
Neither NATs nor firewalls were invented with the Internet, and it doesn't matter. NATs are a thing now. And even if it wasn't their original purpose, NATs are used as firewalls. Functionally they're similar except NATs also rewrite addresses, which is actually a nice feature too. There's some reassurance in having such a clear default-deny behavior, with local IPs that aren't globally unique to begin with.
What's the big problem with NAT existing anyway, especially when you're free to ditch it on your own network? Maybe because the main point of getting rid of NAT in v6 is to allow any device to claim a public IP on default networks, for p2p applications. NAT's default behavior would get in the way of that. So it seems like ipv6 is about pushing default-allow behaviors onto network operators. Again this is pretty separate from the address space crisis.
>Neither NATs nor firewalls were invented with the Internet, and it doesn't matter. NATs are a thing now.
Don't forget the context: we were talking about "removing NAT as an extra goal of IPv6," not "does it matter when was NAT invented".
So here I am reiterating my point again: It was never an extra goal, considering that IPv6 was designed in an era when NAT never predominated the internet.
>What's the big problem with NAT existing anyway,
Oooh no biggie other than breaking all sorts of P2P communication? It's so bad that we have to implement literal hacks like TURN and STUN on top of the hack that is NAT itself.
Or maybe we can talk about how it broke all sorts of protocols so badly that we to this day need application-level gateways[1] to help those protocols transverse NAT?
Or let's have some time to talk about how inefficient NAT is. You should know it requires computing power to track each connection flow and to maintain a state table for those flows.
>So it seems like ipv6 is about pushing default-allow behaviors onto network operators. Again this is pretty separate from the address space crisis.
What are you talking about? Default-allow and default-deny are both firewall rules. Even NAT (the "full-cone" or "endpoint-independent" ones) is prone to this, if a port is open everyone can connect to you through the IP:port.
I would say removal of NAT and addressing space is closely intertwined, but alas you seem to have pretty amateurish understanding of it.
Also, just in case you bring up your IPv4.1 again: all address space enlarging efforts will inevitably face incompatibility issues.
IPv6 with default-deny firewalls in most places would break P2P communication too. No application would be able to rely on both users having open listening ports. You ok with that?
I keep hearing this have your cake and eat it too kind of argument. "It supports P2P" and "just default-deny if you're worried about security" do not mix. We get one or the other as the assumed default. IPv4 + NAT is the default-deny. IPv6 seems to be about default-allow even if that's not inherent to it.
>IPv6 with default-deny firewalls in most places would break P2P communication too.
That's why you have the PCP protocol to help you setup a hole in your firewall, you default-deny until some host in your network says "I can handle port 12345". If your router doesn't support that, in the worst case scenario you can fallback to manually setting up firewall entries much like NAT.
Sure, PCP works in NAT cases too, but not always - especially in double-NAT or CGNAT scenarios. And we already know how prevalent CGNAT is, don't we? I don't know where do you live in, but here all ISPs have deployed CGNAT.
By the way that's one of the disadvantages of having NAT, you are forced into a centralized architecture where the central node in the ISP (the CGNAT device) decides what kind of niceties you could get.
IPv6, the ISP only carries traffic around and it does not meddle with layer 4 activities.
The Reddit commenter who said "Everyone is charging for IPv4, except AWS (until now)" is uninformed or lying. I've been on Oracle Cloud Always Free selfhosting my mail and web services for months now including free IPv4 public addresses.
244 comments
[ 0.20 ms ] story [ 217 ms ] thread(I didn't bother looking for the quote's source.)
If IPv6 had left out the mandatory added complexity, and just focused on the larger addresses and cleanups, it would have been easier to adopt. The other changes could have happened via other standards, rather than bundling them all into "IPv6".
SLAAC and RA reduce complexity as you no longer need 'extra' infrastructure (DHCP) to get going: plug in and the router sends the information and you're done.
You also get rid of the complexity of STUN/ICE/etc as you no longer need NAT, so you just need hole punching for SPI firewall (also needed with NAT for port forwarding, so no change there).
If you want the network to come up in a timely fashion, the new system needs to poke the network to get information proactively sent to it as soon as possible, at which point you have about the same level of complexity as poking a DHCP server. (With added bonus "this could happen asynchronously at any time and you never reliably know when your network is actually done being configured".)
If those standards are so valuable, they should have stood on their own, as optional things people could have adopted if they wanted to do things completely differently from IPv4. Meanwhile, people already have DHCP servers, and could have just told those DHCP servers to start giving out IPv6 addresses too.
The reaction I have every time I interact with IPv6 is that it seems incredibly hard to make a system just use the configuration you tell it to use and never ever listen to any configuration from the network.
I've had to fight with ip-helper issues and DHCP scopes enough times to not wish to have to deal with it if possible.
I have to configure the router (or the VLAN on a Layer 3 switch) anyway, so a few extra lines for /64 scopes that are sent out via RAs on the same device I have to touch anyway is easier.
> The reaction I have every time I interact with IPv6 is that it seems incredibly hard to make a system just use the configuration you tell it to use and never ever listen to any configuration from the network.
On Debian with interfaces(5):
For Netplan-based stuff, this looks similar:* https://github.com/canonical/netplan/blob/main/examples/dire...
I recently had to switch ISPs to one that doesn't do IPv6 for FTTH (but their smart offerings are (AFAICT) IPv6-only), but my previous IPv6 did, and activating it for my home network was a couple clicks on my Asus router: all my devices (including a networked printer) picked it up without issue.
And DHCP does a bunch of stuff that's irritatingly dumb to do with IPv6, to the extent that v6 ended up shoving partial compromises _anyway_ like RDNSS.
It's classic second-system effect and design by people without production experience or skin in the game.
You should tell that to Microsoft:
* https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...
Veronika McKillop is now President of the UK IPv6 Council:
* https://www.youtube.com/@ukipv6council468/videos
* https://fr.linkedin.com/in/veronika-mckillop-ipv6
> It's classic second-system effect and design by people without production experience or skin in the game.
Begin with "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" for part of the discussion from back in the day (1993):
* https://datatracker.ietf.org/doc/html/rfc1347
The author of that document attended the first IETF meeting in 1986; interview:
> He’s now a Distinguished Engineer at Juniper Networks, author of 14 RFCs, and chair of the MPLS Working Group at IETF.
* https://www.internetsociety.org/blog/2016/02/interview-ross-...
* https://www.linkedin.com/in/ross-callon-b8383695
He co-edited the MPLS architectural document:
* https://datatracker.ietf.org/doc/html/rfc3031
But sure: "without production experience or skin in the game".
You don't lose control at the router level. v6 isn't anti-privacy and there's no privacy slaughter in it. RAs have no privacy impact and SLAAC makes no meaningful difference.
And due to the large number of significant changes it's still a work in progress as a standard, with important RFCs coming out "as we speak"[1].
[1]: https://packetpushers.net/podcast/ipv6-buzz-134-revisiting-u...
Is there anything stopping you from effectively running IPv6 networks the same way as you run IPv4 networks, but with larger address pools? No.
You can do NAT66, you can do DHCPv6, you can run every network as a /120 (IPv6 equivalent of a /24 - 256 addresses) if you want to as well.
You can even (outside of whatever prefix is delegated to you) only use numbers for the host addressing portion if you want to, and not bother with letters.
Just because the recommendations and standards say you SHOULD do things a particular way, it doesn’t mean you MUST.
This would not be a problem if it would be just bigger IPv4 and there still was NAT, DHCP and everything. But that is not the way you are expected to be doing IPv6...
Instead of giving up, I'd suggest doing it the normal way -- do DHCPv6-PD to get a routed prefix, use that on the LAN and route to the Internet. On most v6-capable routers that's the default and will happen automatically, and it would be hard to make it easier to roll out than that.
> This would not be a problem if it would be just bigger IPv4 and there still was NAT, DHCP and everything.
Irony, I remember life before DHCP/NAT44 defaults, and having to struggle so much to do it myself. Mind, this was 1997, and IPv6 was already a defined standard, which then never got any traction because NAT44 ended up being “good enough” for most people who didn’t think about what they lost in the process.
> Should it be technically possible? Yes, definitely. Is there any value for me in spending a lot of time on it?
There was a lot of value in me spending a lot of time and effort on setting up DHCP and NAT in my home environment in the 90s. Nobody else I knew thought it was worthwhile though, and thought I was insane.
There was a lot of value in me spending a lot of time and effort on dual stacking my LAN too. I see a parallel here that’s amusing to me :-)
Certainly some people didn't like the changes of ND vs ARP and such, but once you're changing the address length, you have to alter the data structure on every bit of networking code, and any transition is going to be a slog.
IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+.
And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere.
But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection.
And of course as long as IPv4 works there's little inherent motivation to go to any kind of IPng.
See "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" for part of the discussion from back in the day (1993):
* https://datatracker.ietf.org/doc/html/rfc1347
For example, we have router at 1.2.3.4/192.168.0.254, and 15 hosts behind it, then, by convention, we can access 192.168.0.1 from public internet as 1.2.3.4:32848 (port 32767+1+80), host 192.168.0.3 as 1.2.3.4:32849, and so on.
I think cloud providers charging for IPv4 is a great stick, since the initial carrots (easier subnetting, huge networks, multiple IPs per host, encryption, etc) didn't work. I do wish they provided NAT64 services though.
It took ages, but there was at least a "best effort" to help people write code that could be easily moved between 2 and 3. (In spite of apparent behavior from the Python developers at the time).
IPv6's hard break with IPv4 means that the switchover likely won't happen anytime soon.
There was no hard break. The same way you have compatibility layers between Python 3.x and Python 2.7, we have compatibility layers between IPv4 and IPv6. For instance, 6to4 meant that anyone with an IPv4 address automatically had an IPv6 network, and could talk to IPv6 hosts; I used it for a while, and it worked nicely. Another one was Teredo, which worked even if your IPv4 host was behind an IPv4 NAT. Nowadays, the preference is for newer transition mechanisms, like NAT64/DNS64 and 464XLAT. On the software side, IPv4-mapped IPv6 addresses allow software written for IPv6 to transparently use the host's IPv4 stack to connect to an IPv4 address; this last one is very similar to the preferred approach of writing Python 3 code and using a compatibility layer to make it run on Python 2.7.
As for the "critical services not supporting IPv6" in the post I was quite surprised that it's such a short list of things that don't work - I would have expected more. They've obviously made a ton of progress.
I get the feeling this is far from an exhaustive list. I think this person just mentioned two things that they had run into and could say didn’t support IPv6 without having to look it up.
AWS is charging $3.60 per month. Which isn't orders of magnitude off when you consider AWS probably has a poor utilization rate (can only advertise /24's) and profit margins to consider.
I guess that might also include all Amazon businesses if you really want to try to send a message, not that it'd really hurt Amazon that much if more people don't actually follow through with going to alternatives.
Or you can complain about it with no results or actions.
Were they though? The first few blocks auctioned off all went to large tech institutions
If you're really upset about it you can go through the trouble of registering your own ASN and get on the list to get your own allocation from ARIN. No one is stopping you from doing so.
I think there's an enormous number of things that it's very worth criticizing AWS (and other cloud providers) for, but this really isn't one of them in my book.
OK
https://www.theverge.com/2017/12/19/16792306/fcc-net-neutral...
"For Licklider, this wasn’t just a new technology, but a new way for human beings to exist in the world."
Licklider and Taylor did have some very interesting predictions about how the internet would shape up though. Probably my favorite quote from the article:
"Unemployment would disappear from the face of the earth forever, for consider the magnitude of the task of adapting the network’s software to all the new generations of computer, coming closer and closer upon the heels of their predecessors until the entire population of the world is caught up in an infinite crescendo of on-line interactive debugging."
Then it was a pretty poor idea to have less IPs than humans on the planet.
We have IPv6 which, at least for the time being can give every individual a few zillion IPs. Providers like this just need to get them rolled out.
That being said, I do know companies that have freed up 80% or more of their IPv4 allocation with no service impact. It was simply not an issue previously and AWS made it easier to just allocate more public IP addresses.
They at least hit the right price to ensure that people care, but not making it unreasonable if you do need an IPv4 allocation.
https://www.google.com/intl/en/ipv6/statistics.html
if you add these new charges onto the existing prices their offering becomes completely uncompetitive
> Yes, Lightsail is revising instance bundle pricing to accommodate IPv4 and new pricing will be published later this year. We understand the importance of bundled and predictable pricing for Lightsail, so revised pricing will include the IPv4 conservation charge in a monthly bundle cost and not as a separate charge.
[1] https://www.linkedin.com/in/adityasanthanam/
[2] https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...
It's stunning, the hypocrisy that permeates Amazon now. I left AWS Lightsail for Oracle Cloud. When they announced Prime members would be shown Ads in movies and shows, we cancelled Prime.
So, these intermediate steps are just cooking the final dish.
Peace. ;)
They would need to be forced to move by customers, probably through an ISP being IPv6 only. And that probably won't ever happen as the customers of those ISPs would drop them for one that does support IPv4 because they expect access to the same big businesses mentioned earlier.
I think the whole thing has lots of inertia to not move to IPv6 and there's no incentive to force it.
Shame on you Turk Telekom and Turkcell. Still don’t support IPv6.
That’s the only thing about IPv6 that I’ve heard of that I think is a reasonable argument regarding a degradation in privacy.
With that said, NAT was a fix for issues that weren’t about privacy, and NAT itself was not designed to give you privacy. It used to be that IPv4 connections were always direct in the same way IPv6 connections were designed to be direct.
In that regard you could make the argument that IPv6 is a regression, but that regression is effectively answering for an architectural shortcoming in IPv4 that we’ve tried hard to fix but that can only go so far.
Edit to add: NAT also doesn’t protect anyone’s privacy anymore than their ISP is willing to protect it anyway, for what it’s worth.
Not happy that AWS is pushing this and they don’t even fully support it.
Perhaps AWS could run these endpoints through Cloudfront in order to get IPv6 reachability.
On the other hand, on my first try I couldn't get "instance-connect" to work and it turned out I needed a different package "awscliv2" which I had no idea existed.. I've been using "awscli" for the longest time and didn't know there was an alternative and more up to date package available. What a mess.
Also, when running the new one apparently it does a bunch of weird docker magic in the background instead of just being a normal Python program so not sure what to think but I guess it works. If anyone knows a leaner solution to opening an instance-connect tunnel I'd love to know.
So I don't know if I agree that aws ec2-instance-connect doesn't use docker. And also, I don't necessarily have a problem that it does, it just surprised me a bit.
- This is not an official AWS CLI v2 application
- By default this app uses amazon/aws-cli Docker image
The only official macOS distribution of AWS CLI v2 is via a macOS installer package:
https://docs.aws.amazon.com/cli/latest/userguide/getting-sta...
It's also available in Homebrew[3] but the packaging is maintained by a third-party, not Amazon.
[1] https://pypi.org/project/awscliv2/
[2] https://awscli.amazonaws.com/v2/documentation/api/latest/ind...
[3] https://formulae.brew.sh/formula/awscli
Update: and now I've read through the github issue, oh my I've missed quite some drama.
https://github.com/aws/aws-cli/issues/4947#issuecomment-5860...
They also have't provided a reason for why they don't distribute via Homebrew:
https://github.com/aws/aws-cli/issues/727
The agent is Apache 2 if one wanted to build, enhance, or audit what it does: https://github.com/aws/amazon-ssm-agent#readme as is the local binary that awscli uses for the websocket handshaking: https://github.com/aws/session-manager-plugin#readme
Considering the cheapest ec2 instance type is now cheaper than an ipv4 address this is easy to justify if the AWS specific options don't fit your usecase
You’re not.
Having an IP per endpoint that is conveniently globally routable from any other endpoint is the entire purpose of the Internet!
It’s not some sort of greed or abuse of privilege! It’s the reason for the thing to exist!
This is like going to a shopping centre that has been growing along with the local population exponentially but refuses to buy more shopping carts. You can’t feel guilty for using a shopping cart “just” for your quick snack shopping as-if that’s a greedy move taking it away from more deserving people with “real” grocery shopping to do.
Stop thinking like this. Seriously, STOP!
You’re the victim here.
You’re the victim of Amazon’s greed and lock-in.
You’re the victim of the lack of foresight for the most predictable resource exhaustion in the history of the world.
You’re the victim of a problem that has had a solution for two decades that is now included for free(!) in every network device being made but is being turned off by lazy administrators that can’t be bothered averting slow-moving catastrophies.
There is no "just" in this.
Copy-pasting from my other comment:
--
IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+.
And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere.
But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection.
--
So "just" expanding IPv4 to IPv4+ ends up being the exact same amount of work as ended up with IPv6.
Only only thing you could say with "just" more addresses is keeping ARP and the like (instead of DAD, etc).
> Complete backwards compatibility
> If it's 8 bytes then it's a full address
Existing IPv4 devices wouldn't be able tell that it's 8 bytes, and wouldn't be able to make heads or tails of such a packet. At best, they discard the packet, at worse, they misinterpret it. It's not backwards compatible.
You can attempt to construe the bits however you like, but you're going to butt up against the pigeon-hole principle here. Any solution that works is going to be materially the same as IPv6.
However, we're pretty stupid how we use ipv4. A connection identifier is actually 48 bits, which is a massive pool. Currently nearly everything on the internet runs 32 bit ipv4 address with a 16bit port number. The vast majority of internet traffic waste the last 16 bits because of convention (Hey only accept HTTP/SSL connections on port 443! lol)
We could extend ipv4 a couple hundred years by adopting SRV records, which would be a painless change compared to swapping ipv4 to ipv6. That puts the last 16 bits of the total 48 bits to work.
The other part of the ipv4 packet is a bunch of flags that are pretty dangerous and nobody uses. Those might be able to be used as identifiers, but it'd be pretty not-backwards compatible.
I'm a critic of the ipv6 transition because of the players promoting it in a certain way that is detrimental to the consumers. However, one thing ipv6 gets correct is the concept of network flows and the removal of a ton of cruft from the ipv4 packets. In that regard ipv6 is very well designed.
Anyway, I will continue to turn off ipv6 and block it on all the devices and networks I operate, as it offers no benefit to me personally, only downsides, and it's just one more thing to monitor for privacy.
1. The address space is ludicrously unwieldy. Humans are good at remembering long numbers. We're quite bad at remembering random strings outside of pure muscle memory. For the cases where you're manually fiddling with IPv6 space in situations where a domain name isn't mapped to an IP (ie. home networks), the reality is that IPv6 is only a negative. Telling people to go to "192.168.2.1" to log in on their router is easy. Telling them to punch in a long IPv6 address that includes the A-F range isn't. (And that's without getting into colon collapsing 0000 ranges which just reeks of "did anyone run this past a human being", because this makes even less sense to people who barely get "I need to type the address on the ISP router sticker in my browser").
2. The complete lack of even a one-way compatibility layer with IPv4 (so communicating from an IPv6 to an IPv4, which should be possible in a tech stack) means that even if you take the slow movement of hardware to IPv6 space into account, the offering simply isn't worth it until everyone switches over. Right now the standard offer for home ISPs is CGNAT + IPv6 if they offer the latter, is not solving anything - the reality is that if you give an IPv6-only offer, your customers just straight up can't access ~40% of the internet (and by law of institutions, that will include parts of the internet they really need because the people running it are restricted by yellow tape and budgets to also move to IPv6), so all we get is the worst of both worlds where IPv4 is still running out of space and IPv6 isn't ready to replace it.
Would it really have been too much work to slightly compromise on address space for IPv6 to just allocate a region to old IPv4 addresses, where the relevant low-level bits of the stack just switches over to the IPv4 protocol if it detects that region? If that were the case, the transition process would go much smoother and we probably wouldn't be haranguing about getting public entities to sell off their address space, just to delay the inevitable.
Those are the reasons why IPv6 isn't replacing anything beyond a slow crawl of "maybe I should set an AAAA record" (and considering like 80% of the DNS+VPS providers I've used in the past decade just dump the /16 when you pick a VPS from a dropdown in the address, which obviously fails to work, it's also clear that hosting companies don't consider it a real priority either). When it comes to core infrastructure like this, backwards compatibility isn't a "nice to have" or to be "thrown out because it was based on bad ideas". It's a requirement, no matter how insane the original product might have looked.
The length of IPv6 addresses is an advantage because people don't try typing them because they are so long. My home network have IPv6 and I have never had to enter IPv6 address. I don't know what my prefix is, I don't know any host addresses, I use mDNS to get to other hosts.
I think you're off base here. The direct equivalent of 192.168.0.1 is FEC0::1 and that's not harder to remember or type. The difference is that those addresses, site-local, got deprecated.
For link-local addresses, nothing stops a home router from using FE80::1. It doesn't have to be a pain to type.
> And that's without getting into colon collapsing 0000 ranges which just reeks of "did anyone run this past a human being", because this makes even less sense to people who barely get "I need to type the address on the ISP router sticker in my browser"
Is FE80:0000:0000:0000:E3B0:C442:98FC:1C14 better than FE80::E3B0:C442:98FC:1C14? I wouldn't say so.
And FE80:0000:0000:0000:0000:0000:0000:0001 is definitely not better than FE80::1.
And I don't share your preference for digits either. If you formatted your average link-local IPv6 address as digits, it would have 30-36 of them. No normal person would memorize it or enjoy typing it. Doing 4 characters at a time, 5 times, is much better than 254.128.0.0.0.0.0.0.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx. Even with the hassle of the double colon. I'd rather have an extra colon than make sure I counted exactly 6 0s in a row.
192.168.8.9.0.1.2.3
old devices get accessed the old way. new devices "know" about the add ons. The new part of the address travels inside "as data" so it gets delivered.
as company firewalls and routers switch to new, the whole company needs only one "old" ip. To get the ball rolling, spend some time deploying before it's switched on.
All those early adopters who have class A networks? They can go first this time too, freeing up their class A's quickly to facilitate the transition for everybody else.
source: this was my idea for phone numbers back when they kept rejiggering area codes.
Unless you hide it all with NAT, but if you're doing that then you're losing lots of the benefits of more address space. And the NAT version is something you can already build yourself, but is rarely chosen for a reason.
it enables a graceful transition period
You can do it right now as a graceful transition to IPv6. Running a pure IPv6 network with NAT64 or similar. But almost nobody does it. Why would your scheme be more tempting to them?
You've just made a new protocol that isn't IPv4, and is even /worse/ than IPv6. Now, not only does one have still have to upgrade every device that deals with these packets, since every device that is routing these packets hop by hop needs to know where to find the new address, every packet now has 64 bits of unusable data in the header.
And the Internet still has to do all of the ancillary work to upgrade things like DNS!
Because NAT breaks a lot of services.
> Is that going to change with ipv6?
Yes. You no longer need NAT, so port negotiation is much easier (even when inbound is blocked)
> Are you _really_ just going to allow random traffic into your network?
Common misconception! Even without NAT, the router can have port/traffic policies. There's just no address translation happening.
There's a lot of good stuff about IPv6, and I would encourage more people to learn about it and try it out.
- ULAs can act like static internal LAN addresses
- A "strong" NAT is easier to avoid and no longer breaks connections to things that are sensitive like gaming consoles
- Randomized, temporary IPv6 public addresses are a nice feature, and mostly turned on by default
- The biggest one is people seem to equate NAT = router/firewall. This is absolutely not the case, and they are distinctly different. You can absolutely have a router/firewall without NAT!
- CG-NAT is becoming more popular due to the lack of IPv4 addresses, and I hate everything about that.
- You can even run a NAT64 to provide IPv4 access to your IPv6-only devices
https://serverfault.com/questions/208522/what-is-strict-mode...
This can particularly play havoc with sensitive protocols like STUN. I believe many game consoles make use of this when in multiplayer matches. I have personally run into this using OpenBSD's pf, but I'm fortunate enough to have access and the known-how to fix it for my consoles.
It's one of those things that's fine until you run into "edge cases," and unfortunately NAT configurations can introduce a lot of undefined behavior from the user perspective.
Two peers, each behind a CG-NAT (or other symmetric NAT), depend on somebody running a relay in order to be able to communicate.
This makes it very expensive (and sometimes risky, since unrestricted relays can be used for all kinds of nefarious things too) to deploy any new VoIP service.
I'd call that "broken by NAT".
> everything works right now.
Yes, everything that works right now works right now, but that's a tautology, not proof of anything. The things that don't exist because they wouldn't work in a predominately NATted world don't work, because we live in a predominately NATted world.
IPv6 (or more generally, the absence of NAPT) just changes the switch label from "try [not] to use direct connections, unless NAT gets in the way" to "[always|never] use direct connections".
In other words, it cleanly separates the two distinct concerns of privacy and connection topology. I think that's a good thing.
https://en.wikipedia.org/wiki/User:82.148.97.69
https://techcrunch.com/2007/01/01/wikipedia-bans-qatar/
Furthermore, in populous countries like India, ISPs enforce extremely aggressive timeouts on IPv4 connections in order to keep the 5-tuples on the egress side of things manageable. Trying to make a request that takes 10 seconds to process (like a user requesting a report consisting of multiple SQL queries)? You get a connection reset.
I must also must point out the HN guidelines because you bring a combative tone to this entire conversation which is not helping it.
> Be kind. Don't be snarky. Converse curiously; don't cross-examine.
But isn't all that still necessary as long as the typical user isn't going to be opening their firewall on those ports to arbitrary incoming connections? That's the whole point here.
And STUN scales almost infinitely better than TURN.
I dont think anyone equate that, but IPv6 proponents refuse to recognize that decades and decades, especially in home users, and SMB space, NAT was a layer of the security model, often times one of the biggest
Right or wrong is irrelevant, that is/was the reality
Just tossing IPv6 as a replacement for ipv4 with out factoring that in while simply screaming into the void "NAT IS NOT A FIREWALL" will be of little comfort to the elderly retiree that has their home computer ransomwared, or the small business that is put under due to a cyber attack because the ipv6 address was strait on the public internet
If an IPv6 home router closes all ports by default, then the same level of security is achieved.
> Randomized, temporary IPv6 public addresses are a nice feature, and mostly turned on by default
I really do not want this.
If you take away the mapping the tracking doesn't go away. Inbound traffic still needs to match to to a session created by outbound traffic.
https://datatracker.ietf.org/doc/html/rfc2993#page-22
https://threatpost.com/remote-attackers-internal-network-dev... https://www.anvilsecure.com/blog/dhcp-games-with-smart-route...
Then disable it. IPv6 SLAAC privacy extensions are device-controlled, meaning neither your ISP nor your router can force you to use/not use them (unless they're so incompetent that they do things like hand out /128s).
I disable privacy extensions on my server so that I can give it a static IP within the prefix, so I can vouch that (at least on Linux) the process is quite simple.
The rare times I want something publicly accessible, I use DMZ or port forwarding.
Not really. Many home routers used to assign all ports to the first device to connect to the router, and you'd need to setup NAT just for your second computer. Eventually the default settings wised up.
It is much more probable that security defaults will be much tighter today than they were when ADSL initially took off.
This is definitely what I'm seeing. IPv4 is really engrained in us - I actually had a really hard time conceptualizing how things worked until I forced myself to learn by deploying dual-stack and ipv6-only networks.
The major downside I see right now is that "addresses are harder to memorize," but there are solutions to that as well.
Definitely. That DNS thing sounds promising!
When IPv6 was created they had the opportunity to just make it an expansion of the IPv4 space they chose not to do that and instead they added in a bunch of wish list items that were not needed to accomplish the goal that they were seeking to do which was prevent the exhaustion of IPv4 addresses
Absent address space exhaustion I massively prefer working with IPv4 than I do IPv6
In practice someone can still configure NAT on IPv6 same as on IPv4 at least on Linux and some vendors, even if IETF resists standardizing it.
https://blogs.infoblox.com/ipv6-coe/you-thought-there-was-no...
So you might still see CGNAT if someone is determined to configure it.
CGNAT on IPv4 is not gonna save you from the Big Brother. IPv6 has many issues, but it is disingenuous to say the least that "it's a distraction from the big problems." The big problems you're talking about are completely unrelated to your IP packet version, and are not to be fought easily on this battlefield.
> ok, but why?
So we can get rid of STUN/ICE/etc and make peer-to-peer easier. All you're left with is hole punching through your SPI firewall (no worse than today).
> Are you _really_ just going to allow random traffic into your network?
I don't know why this misconception is so wide spread: globally addressable ≠ globally reachable.
Firewalls still exist with IPv6.
Before I recently changed ISPs, I was with one which gave out IPv6, and so all devices had an address (including things like my printer). But I couldn't initiate connections from the outside in—only replies to internally-initiated messages were let in by my Asus.
Even if things were wide open—which they were not—good luck scanning a /64.
Do you really think Roomba is going to let you run your Robot Vacuum without contacting, er permission, from their data center in Virginia?
So this is completely unrelated. IP addressing schemes will not change the business methods of large consumer device companies.
That's exactly the point; they market it as if it would make a plethora of new and innovative things happen but in reality they will allow none of it.
So, it's pointless to rush adoption.
What I meant in the grandparent comment is that if a company makes it their business strategy to have all devices call home, they will do that regardless if they use ipv4 or ipv6. But if ipv6 is widely implemented and there is no cost to ip addresses, it is entirely possible that another company can create an ap that allows you to directly communicate to your devices without using a central server.
How much innovation and applications have been stymied by artificial network-layer barriers:
> First is actually a more subtle issue... the Skype peer-to-peer network architecture elected certain nodes to be "supernodes", to help maintain the index of peers as well as handle parts of the NAT/firewall traversal for other peers.
* https://ip.topicbox.com/groups/ip/T9f6a724f4bcd6616-M0e99aba...
* https://arstechnica.com/information-technology/2012/05/skype...
CPE gear has gotten better hole punching over time (PCP, UPnP), but one still has to futz around with STUN/ICE/TURN.
We've invented entirely new protocols (QUIC) because of middleware boxes blocking things (SCTP, DCCP) and generally getting in the way.
Ideally yes, but IRL they are related concepts. Things will get misconfigured, often by default.
> So we can get rid of STUN/ICE/etc and make peer-to-peer easier. All you're left with is hole punching through your SPI firewall (no worse than today).
There’s (IMO) a much better reason: so your endpoints can have globally unique addresses. If I have a service in Google Cloud and a service in AWS and an on-prem service and a customer service and ten different upstream services from ten different hosted providers, I want these services to have different addresses, TYVM. And I want to configure my networking to them without needing to worry about whether all parties actually agree on the addressing scheme.
This is far more important than actually making anything globally routable. If my AWS thingy is 192.168.3.7, I don’t need whatever random third party service I’m using to be able to route to 192.168.3.7 (and I’d probably prefer that it not be able to route there). But I don’t want to worry about the service provider using 192.168.3.7 for another purpose.
I’d also like traceroute to work without having a bunch of intermediate hops where the addresses simply cannot be mapped to their owners without extra side knowledge of the network topology.
Complications with address space collisions (esp. M&A) was one of the reasons given in this Wells Fargo presentation from 2014:
* https://www.youtube.com/watch?v=EzTWjNUb4H4
As for public reachability, most OSes have a firewall of sorts (nftables, pf etc.) and can be configured to block traffic by default; on consumer OSes they already do so. There's also the local unicast range fc00::/7, which seems conveniently forgotten about in these kinds of comments.
Anti-ipv6 is like the NIMBYism of IP address space, why can't we just "build" more to inflate the supply and crater the prices of existing ones?
> Do you really think IoT device makers are going to allow your smartphone to connect directly to your device
This happened because of IPv4 NAT.
You might not be facing issues in your country but here in India millions are behind NAT and it degrades QoS
> Is that going to change with ipv6?
Yes, because stateful firewalls are much easier to consistently traverse than NAPTs. This alone is a huge advantage for P2P applications.
Behind a (usually symmetric) CG-NAT, I have no way to directly connect to anybody else behind one without a relaying server (which are expensive and add needless latency).
> Are you _really_ just going to allow random traffic into your network?
No, but nobody is suggesting that.
> ipv6 is a distraction from the really problem of control and privacy
IPv6 is also doing nothing to combat pollution by microplastics and overfishing.
We disagree but I actually laughed at that.
Having globally unique addresses removes the need of (stateful) mapping tables, which in turn make it easier to intentionally allow traffic in.
In other words, it's quite hard to even name the traffic you want to let in if names are globally overloaded.
> ok, but why?
Because it makes things easier.
> Is that going to change with ipv6?
It already has.
> Are you _really_ just going to allow random traffic into your network?
Doesn't mater if I _am_ or not. I want the option. (And before you say port forwarding: try forwarding ports when its your ISP doing the NAT)
Why not?
The predecessor of my ISP introduced full IPv6 support for all customers 15 years ago. The only argument against at this point is inertia.
Instead, ipv6 created a separate world, with extra goals like making every device addressable (aka removing NAT), using randomized addresses, and resetting all ownership of existing blocks. "We're out of addresses" is not a good excuse for all that.
That's not possible. IPv4 addresses are 32-bit numbers. Once you change that, you're no longer "preserving existing addresses".
> once enough routers are updated to support them.
That's actually "once all routers and end devices are updated to support them". As the classic spamsolutions.txt says, "requires immediate total cooperation from everybody at once".
> This could've even used the exact ipv6 packet structure, making it quite similar to v6 under the hood but more like v4 from the user's perspective.
Changing the packet structure means changing all hardware and software (yes, software too, the API for IPv4 uses 32 bits for the addresses). The changes visible to the user are the easy part.
> Instead, ipv6 created a separate world, with extra goals like making every device addressable (aka removing NAT),
It's more like "not needing NAT" than removing it; port mapping NAT is not a part of IPv4 (it's a hack on top of it), and it can be done identically in IPv6, but few do it on IPv6 since it's not necessary.
> using randomized addresses,
This is an optional thing which was added later; nothing in IPv6 requires randomized addresses, but IPv6 makes them possible by virtue of having enough free bits in the address. Were randomized addresses possible with IPv4, we'd see them happening.
> and resetting all ownership of existing blocks.
IPv6 has done no such thing; the existing IPv4 blocks are still there.
This point cannot be emphasized enough. To quote Hyrum's Law [0]:
> With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
And for networking this means that, even if the NRO decreed that all reserved/testing IPv4 blocks [1] would be publicly routable and turned over to the RIRs for allocation, those blocks would be effectively unusable. It doesn't matter how many RFCs you produce saying "you must assume these addresses will be someday used", networking hardware and software has ossified around specific expectations pertaining to what addresses are valid and invalid, what protocols are acceptable, etc.
A great example of this is TLS 1.3: due to protocol ossification, the spec had to be rewritten to be more similar to TLS 1.2 because network middleboxes kept assuming it was a threat and blocking the connections [2]. This is also the reason SCTP has yet to gain widespread adoption, and why any new layer 4 protocol is likely doomed to fail: networking hardware hates anything that deviates from the acceptable traffic patterns which have been hard-coded in, RFCs be damned.
Imagine if previously unused IPv4 blocks started getting allocated. You'd be cut off from most of the internet, and most of the internet would be cut off from you. It wouldn't be enough, of course - even if all 2^32 addresses were publicly routable, that's still not even enough for 1 IP per person, you'd still have to rely on NAT, and all the problems it causes. (This is also why I think suggestions like "organizations like Apple who have a /8 but barely use it should just give up those extra IPv4s" are misguided and really understate of the scale of the problem - it's just putting a band-aid on an open fracture that cut your femoral artery.)
[0]: https://www.hyrumslaw.com/
[1]: https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4
[2]: https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet...
I am uniquely employee number 6100. That field is 32 bits in HR's database. If they make it 64-bit, I'm still 6100.
> That's actually "once all routers and end devices are updated to support them". As the classic spamsolutions.txt says, "requires immediate total cooperation from everybody at once".
No it doesn't, it requires gradual cooperation, as the 4.1-compatible hosts will still speak v4 as needed. Same as how v6 stack support was added even to hosts not using it.
> It's more like "not needing NAT" than removing it; port mapping NAT is not a part of IPv4 (it's a hack on top of it), and it can be done identically in IPv6, but few do it on IPv6 since it's not necessary.
Yeah but the goal is to remove it. The feature set of v6, including random addressing, is intended to support p2p applications. The authors of ipv6 did not envision NAT being enable by default. Defaults and intent matter more than technical details here.
> IPv6 has done no such thing; the existing IPv4 blocks are still there.
They aren't there on practically any ipv6 network, despite an optional ipv6 extension for v4-mapped addresses. That's the critical difference vs what I've described.
Admittedly this was a couple years ago, but last I checked, Azure managed PG didn't support v6. (We're mostly moving away from Azure for other reasons … so I'll probably never re-check.)
GKE on GCP doesn't really support v6. (If you selected the v2 "data plane" when you created your cluster, then it can, assuming the vnet can. If not, then not yet, and there's no way to upgrade data planes presently.) Peering VPCs doesn't work with v6-only, meaning if I want to peer VPCs, I pretty much am forced to solve all the problems v4 has with that … which defeats the entire point of a v6 peering. Cloud NAT doesn't support v6, so I'm super not clear on how ULA VPCs are supposed to work.
AWS also added IPv6 NAT64 gateway so it should be possible to run IPv6-only internally and still access AWS services and the rest of the Internet.
[1] https://aws.amazon.com/privatelink/pricing/
Granted, there are other (but similarly expensive) workarounds such as NAT gateways[2] for outbound connectivity or the cheaper NAT instance method which AWS doesn't support any more, but there are alternatives[3]. However, for use cases requiring inbound connectivity such as setting up websites on EC2 instances, or using an ELB which need internet access, you need an IPv4 address and these charges definitely rack up.
[1] https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...
[2] https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gat...
[3] https://fck-nat.dev
Ultimately, they will probably want people to solve it with service endpoints, and give preferred pricing on that. But I kind of get why that is a bit wigged out. Because it locks more architecture into them as a vendor. I'm not really sure putting a public ip is a good solution to this, but it is kind of scary because suddenly we are deciding infrastructure decisions more based on how they are being priced. Needs regulation.
Case in point, I had some internal instances that very occasionally want to pull files from a partner's endpoint. Previous solution, NAT gateway. New solution, DynamoDB request table streamed to AWS Lambda and results in S3. Caveat programmer: only suitable if the task is not latency sensitive.
DynamoDB/Lambda are not everyone's cup of tea, but it's nice to have options.
TIL. Thanks!
Just in case some people are on the same boat. Here's a simple process [2] to remove public ipv4 IPs from existing EC2 instances (no need to shutdown / reboot) -
1) Create a new elastic ip with autoassigned ipv4 IP - https://us-west-1.console.aws.amazon.com/ec2/home?region=us-...:
2) Associate this new elastic ip to an existing EC2 instance. This will replace existing public ipv4 ip of this instance.
3) Create a new network interface - https://us-west-1.console.aws.amazon.com/ec2/home?region=us-...:
4) Attach this new network interface to the EC2 instance. Now the EC2 instance has two network interfaces, thus two private ipv4 IPs.
5) Disassociate the new elastic ip & release the ip - https://us-west-1.console.aws.amazon.com/ec2/home?region=us-...:
By this point, the EC2 instance doesn't have a public ipv4 ip anymore.
---
[1] https://www.listennotes.com/
[2] https://stackoverflow.com/questions/38533725/can-i-remove-th...
IPv4 1.2.3.4 becomes IPv6 0.0.0.0.1.2.3.4
Owning IPv6 0.0.0.0.1.2.3.4 means you also own IPv4 1.2.3.4, because addresses that begin with 4 zeroes mean they also own the equivalent IPv4 address.
Owning 2.2.2.2.1.2.3.4 means you do not fully own an IPv4 address. In this case you'll have a NAT IPv4 address.
If you connect to 1.2.3.4 you use the IPv4 protocol. If you connect to 0.0.0.0.1.2.3.4 or 2.2.2.2.1.2.3.4 you use IPv6 packets that are identical but larger header to accommodate the bigger address.
As long as you have an IPv6 that begins with 4 zeroes, you are fully compatible with everything, without needing any kind of NAT. If you have an IPv6 2.2.2.2.1.2.3.4 then you'll need NAT to connect to IPv4 addresses, but can connect directly to IPv6 addresses.
You can also make compromises with NAT, like handing out 40-bit addresses that are auto-translated to/from 32-bit with 8 bits going into the port.
Again, neighbor discovery, SLAAC, link-local addressing, none of it has anything to do with how long it's taken the world to adopt IPv6. The fact that they have to do anything at all is, and there's no solution around that.
Furthermore, the longer addresses would be routed similarly to the 32-bit ones: dst=1.1.1.1.2 would go to the 1.1.1.1/32 router the same exact way dst=1.1.1.1 does. Only difference is what that router does with the packet.
IPv4 packets have 32-bit address fields in the packet header, 1.1.1.1/32 still needs to understand IPv4.1 packets or it's going to think you're sending it corrupt garbage.
Again, nothing changes - if you do anything to change the structure of the packet header the same problem happens, no matter what.
If the same support was added except with the /32s preserved, everyone could've switched to v4.1 with basically no change to the routing, DNS, NAT, etc. Not a big jump like going to v6. Then ISPs could later divide up their /32s and hand out, say, /88s to customers. Address crunch would've been already averted.
Except you're wrong on all of the above.
We'd still need a completely different "v4.1" routing layer, because a /32 could never be a subnet while also being a distinct endpoint, so we'd have to treat any routes smaller than a /33 as being the old IPv4 world while a /33 and bigger would be v4.1. So we still end up with the exact same split, except now our address space is an even bigger fucking mess instead of the clear break v6 is giving us to make a more hierarchical network (eventually getting rid of the ludicrous routing table bloat we currently have, though we really need to come up with a better solution for multi-WAN failover in small networks to avoid everyone and their dog needing an ASN and BGP session to have a HA setup).
DNS would still need changes, because the struct for an A record still contains a 32-bit address.
Nothing stopped us from using NAT with IPv6, but it sucks and broke end to end connectivity so while we already had to break the world to make the switch why not deal away with the ugly hack while we were at it.
There is no world in which any successor to IPv4 did not have a long transition time without government mandates, and that's basically what it is taking to get ISP's and cloud providers to adapt it (the whole reason AWS, Azure, GCP, et. al. are slowly getting their shit together is the US government is mandated to go single stack).
Then once basically everything is speaking v4.1 and ok with longer addrs, it's trivial to split up /32 blocks as desired. And yes, NAT stays for most people. That's fine, you'd still be free to disable it and give your devices public IPs if you want.
That's not the problem.
Being reachable "at the same address on v4.1" (or v6) does not mean that v4 hosts can reach you. In order for v4 hosts to reach you, you have to be doing v4, because v4 hosts will be sending you v4 packets. If you've turned off v4 then that won't work. It'll work if you leave v4 on... but then you're just doing dual stack, and v6 can do that too.
The problem here is that you haven't realized that what you're describing is no different to v6's approach, just phrased differently.
Let's say every ipv6 stack we have today were instead playing by "ipv4.1"'s rules, meaning same addresses and routing as v4 (and possibly the same packet format as v6). Nobody is taking advantage of longer addresses yet, but the bits are there for later. This also means old DNS entries are still valid, and NATs are still common. What would stop many people from flipping on ipv4.1 mode?
The only difference seems to be that some people are already making use of the bigger address space, rather than waiting. And that's surely a good thing? If you told everybody to wait until absolutely everything supported it, you'd be waiting forever, and you'd be giving up the benefits of having a larger address space available the entire time... and you don't have a way to force people to wait anyway, so that idea wouldn't even implementable in the first place.
There is no way a router that does not understand the address extension is able to route packages to the larger address spaces correctly. So this is not possible to do.
There is no "just" in this.
Copy-pasting from my other comment:
--
IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+.
And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere.
But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection.
--
So "just" expanding IPv4 to IPv4+ ends up being the exact same amount of work as ended up with IPv6.
The only thing you could say with "just" more addresses is keeping ARP and the like (instead of DAD, etc).
1. Add v4.1 support, but keep using 32-bit addresses. 2. Start using >32-bit addresses when ready.
By the way, the WWW has gone through transitions like adopting HTTPS and banning old versions of TLS with it. Crucial to that was having transitional periods where both things work. This step was missed in ipv6 rollout.
When who is ready? Different people/organizations will be ready at different times.
Some people will not be able to get IPv4 addresses so will be 'stuck' with being IPv4.1-only.
Given the finite IPv4 addresses, some will move the IPv4 addresses to revenue-generating areas and will go IPv4.1-only internally—which is what prompted Microsoft to be IPv6-only/first internally: their IPv4 addresses got sent to Azure:
* https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...
And once that happens, which it would inevitably too with IPv4.1, we're at:
If you have a IPv4-only network elements/devices, they cannot talk to IPv4.1-only devices/services (and vice verse), so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an IPv4.1 network is an island in a sea of IPv4, so you have to have tunneling. Of course some may have both IPv4 and IPv4.1, and want to talk to something has also has IPv4 and IPv4.1, so now you have to have code for source/destination selection.
In the meantime, ISPs that cannot afford enough 32-bit addresses for their customers can hand out 40-bit ones and perform a NAT-like translation. Same as what they're doing now with cgnat, except there's an exit strategy.
And who gets to decide when "enough" devices support it? Who decides on that flag day?
* https://en.wikipedia.org/wiki/Flag_day_(computing)
The Tier 1s?
* https://en.wikipedia.org/wiki/Tier_1_network
Good luck coördinating that with the global Internet.
ISPs also decide; they turn off their cgnats and start handing out /48s etc, at the latest when the cost of leasing /32s addresses exceeds the cost of being incompatible with a tiny few straggling hosts.
I don't agree with this. First, most users don't know or care about security. So neither is more desirable for them. But also, on its merits NAT isn't more desirable. It provides zero security that is not provided by a simple default deny inbound rule on a firewall. And on top of that, it introduces additional complexity that even a non-technical user has to contend with sometimes (port forwarding).
NAT is not and never has been a security mechanism. We need to stop trying to shoehorn it in to a role it isn't meant for.
My home router has one public IP and many private IPs. No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports. With v6, I'd instead be double-checking that my router firewall is doing its job, e.g. https://community.verizon.com/t5/Fios-Internet-and-High-Spee... . Even if the router turns out to be WAI, I shouldn't have to question that!
Only because your router also has a properly configured stateful firewall for ipv4 as part of its NAT implementation. I have a Mikrotik CCR2004 at home, I can enable SNAT without appropriate firewall rules and have any other customer of my ISP on the same subnet send packets towards the WAN interface of my router and have it happily forward them onto my internal network.
NAT is implemented using a stateful firewall, but the mere presence of it does not mean the firewall is configured to reject unestablished connections from outside. IPv6 just exposes such poor configurations more readily.
> IPv6 just exposes such poor configurations more readily.
Yes, that's the exact dealbreaker for me and many corp environments.
Yeah, it does in many (most) cases. That's precisely why my firewall rules on my own router look like this:
You would have to have a system on the same subnet as the public interface of my router to try and take advantage of these rules not being in place (because of the nature of how IP forwarding works), but without them it would absolutely forward them because the route table just looks like this Note, it's just one route table - with IP forwarding enabled the only thing stopping anything coming in the WAN interface from being capable of forwarding to the LAN interface is the firewall rule.> Yes, that's the exact dealbreaker for me and many corp environments.
My point remains, NAT is not a security measure - any corporate environment who thinks they are protected merely because they have NAT enabled is fooling themselves. The exact same set of firewall rules I need to properly secure IPv4 traffic are the same ones I need for IPv6 traffic; the only reason I haven't bothered to copy/paste them is because my ISP in 2023 still does not hand me an IPv6 allocation.
Making sure I understand, you mean an attacker sends dst=192.168.1.2 directly to your router without any extra hops, which the router forwards to your PC. I don't know if that's what happens in practice (there's no legit reason to do it), but I can see a router doing that.
Yes, you shouldn't rely on NAT alone, rather the router should have a firewall. Usually it does, but not always. When that fails, at least it's still pretty hard to exploit. How often does this kind of attack occur?
Yes, you understand the problem correctly. The fact that there's no legitimate reason to do it is precisely why routers have a default set of firewall rules to prevent it. Hell, as long as you control enough of the network to be able to route such a packet to the WAN interface of your router it doesn't even have to be on the same network segment - so compromise within your ISP's network would open you up to attack if you just assumed NAT alone without a proper stateful firewall would save you.
> How often does this kind of attack occur?
Due to needing to be on the same layer 2 segment or having control elsewhere of the network this would very much be a targeted attack. But one any enterprise should care about, and why the assumption that NAT alone is what protects you is dangerous. NAT just does source/destination (ip, port) rewriting, that's it.
???
Firewalls generally have inside and outside: default-deny any new connections from the outside and you're done. This is how all CPE gears ships out of the box.
> Especially when one of the other goals of ipv6 is to enable p2p applications, which might lead to permissive defaults.
For this you need hole punching, with on CPE gear is done with UPnP and/or PCP, the exact same protocols that are used with IPv4 NAT. (But of course applications also have to futz around with TURN/ICE/STUN if there's NAT.)
> No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports.
When I was still with a residential ISP that did IPv6 this was the exact same with all of my home devices behind my ten+ year old Asus.
Further, because you only have one public IPv4 address, someone can scan just that address to see which ports are forwarded. People regularly scan the entire IPv4 address space: 2^32 addresses is not a difficult task.
With IPv6, they'd have to know the IPv6 address of your service that you had opened to the public. If you hadn't advertised the address publicly, an Internet rando is not going to find it: good luck remotely scanning a single /64 (never mind a /60 or /56 that many ISPs hand out).
Nowadays you have two entire separate stacks, each with their own firewall rules. That's why the first thing I do is outright disable IPv6 because of the potential security issues due to misconfiguration.
The hardware and operating systems have supported IPv6 for a very long time. The problem is that it's a pain in the ass to maintain 2 stacks simultaneously, that's why adoption is so slow.
OS and hardware support is not the bottleneck.
At what point do these posts become trolling?
A similar issue came up when the internet migrated from class-based to classless IPv4 routing, and in that case, there were experiments that showed most networking gear continued to work and there was little to no adverse effect due to this switch.
Scarce & Desirable is Expensive; Low Class & Plentiful is Cheap
It doesn't always go both ways.
Another thing about humans, addresses like 2001:4860:4860::8888 look awful. You gonna tell me that's an upgrade over 8.8.8.8? And 192.168.1.2 becomes fe80::1c03:b6d1:9222:3a02. Why can't I keep 192.168.1.2?
And how would you propose making larger addresses without making them longer?
> And how would you propose making larger addresses without making them longer?
Pre-existing ones don't need to be longer. If my IP before was 1.2.3.4, it stays that way. If a new ISP can't afford /32s for its customers, maybe it hands out /48s like 1.2.3.4.5.6, and if there are ever 282 trillion users, the next one is 1.2.3.4.5.6.7. At home on my LAN, ofc 192.168.1.2 is free and I keep it.
IPv6 addrs are only long because they're spread out.
You give one example (ULA) and I can raise you four: 192.168.0.0/16, 10.0.0.0/8, 172.12.0.0/12. You give one example (LLA) and I can raise you another: 169.254.0.0/16.
So come on now with the "complexity" talks. It's obvious that you are not even educated in IPv6 technologies, or else you will be talking about NDP and others, not mere addresses.
>Pre-existing ones don't need to be longer
We cannot do that even if we wanted to do so.
Think about this: computer A supports only the "shorter IPv4" and computer B supports both the "shorter" and "longer IPv4". Now computer B has the IP "1.2.3.4.5". How can computer A, which supports only the shorter IP address, connect to computer B? By the magic of having hindsight? No.
Therefore: Congratulations! You have just repeated the current IPv4-IPv6 pain point without being aware of it. Which is fine, but note that in your comments you have tended to act like your solution is better than IPv6's.
The current pain point with ipv6 is not simply that hosts/routers need to support the new packet header. Vast majority of them do by now, right? But going v6 means redesigning your network. If all the addresses, routing, etc were kept the same as before and switching just meant handling a different packet header, it'd be a much easier transition. Then once everyone's on v4.1, people could start using longer addresses.
> It's obvious that you are not even educated in IPv6 technologies, or else you will be talking about NDP and others, not mere addresses.
They're mere addresses in ipv4, but not so in ipv6. ULAs are routed specially, basically as a replacement for NAT. See, I can use jargon too, but it doesn't matter here. From a common sense standpoint, there's no way that making the address field bigger requires changing all existing addresses.
>If all the addresses, routing, etc were kept the same as before
It is a natural consequence of having a greater address space.
If you decide to expand the address to become 128-bits long (heck, even 64 bits), you will also expand the routing table and risk overwhelming the limited memory of some routers.
Hence, we need to find ways to aggregate the routes and make the route table more efficient, and that's what you are looking at with IPv6 addressing. The /64 per network requirement effectively cuts the size of your route table in half, for example.
But even so... your point that:
>Then once everyone's on v4.1, people could start using longer addresses.
...is incredibly naïve. It took decades to have everyone support HTTPS, and to this day we still have HTTP-only websites.
>ULAs are routed specially, basically as a replacement for NAT.
For god's sake, no. It is better to think ULAs are specifically used for internal communications than to think they are for NATs.
Like I said, you really don't understand IPv6 at all, stop pretending that you are, lest you repeat all the same so-claimed "mistakes of IPv6" in your own solution.
>no way that making the address field bigger requires changing all existing addresses.
Except that when you are moving pre-existing machines out of a NATted network, you will need to give them new addresses, and then you realize that you have to renumber everything anyways in the end - otherwise you will have locally proximal machines in vastly different subnets.
Maybe I'm misinterpreting what you're saying here, but expanding your address space doesn't suddenly mean you have more routes to deal with. Like, ISP is routing all 1.2.3.4/32 traffic to my router; they don't care what addresses it forwards to underneath that. The ISP could support more customers by handing out /40s, but that's a gradual increase.
Unless you're saying that just supporting the longer field means more memory is used for the existing addresses (true), but idk if that means you have to re-optimize all your routes.
> ...is incredibly naïve. It took decades to have everyone support HTTPS, and to this day we still have HTTP-only websites.
Most sites are HTTPS-only because it's safe to assume every client will support it. Now how many big websites are ipv6-only?
HTTPS is the networking migration success story I like to point to, in fact. Just the right amount of force was applied, including banning old TLS versions later.
> For god's sake, no. It is better to think ULAs are specifically used for internal communications than to think they are for NATs.
I didn't say they are for literal NATs. They are replacement for the private networking feature of NAT, where your LAN hosts aren't reachable from WAN.
> Except that when you are moving pre-existing machines out of a NATted network, you will need to give them new addresses, and then you realize that you have to renumber everything anyways in the end - otherwise you will have locally proximal machines in vastly different subnets.
If you're moving pre-existing machines out of a NATted network. Not everyone has to.
Routing tables don't magically change their structures according to the routes either. Think about this: the routing table must provide at least 40 bits of space to accomodate for possibly 40-bit routes or 32-bit routes. After all, the router cannot tell what routes you are putting in when it is manufactured.
If you increase your address space by any number of bits, your routing table must necessarily increase its size.
>I didn't say they are for literal NATs.
Private networking is private networking, NAT is NAT. The fact that you are conflating those two makes me highly worried, especially in the context of Internet Protocol designing.
>If you're moving pre-existing machines out of a NATted network. Not everyone has to.
Now here is your very fundamental misunderstanding of any next-generation Internet Protocol! If we are not getting rid of NAT, there is no point in introducing larger address space in first place.
So you're talking about the second thing I mentioned. Supporting N users requires storing at least Nlog(N) bits of addresses in total. Going to /40 doesn't seem like a big enough increase to require redoing all the routes. And even if it is, an ISP could even roll out v4.1 sticking with /32s for now, keeping their routing tables exactly the same and leaving the expansion effort for later.
> Private networking is private networking, NAT is NAT. The fact that you are conflating those two makes me highly worried, especially in the context of Internet Protocol designing.
In IPv4, a very common reason you'd have a private network is because of a NAT, even though they aren't the same concept. To help get rid of NAT in IPv6, they added ULAs. That's all I mean.
> If we are not getting rid of NAT, there is no point in introducing larger address space in first place.
The point is that we're running out of addresses, like ipv6 proponents keep saying. Everyone who needs public IPs for any reason should be able to obtain them cheaply. This doesn't mean that NAT needs to disappear everywhere, though some users (like ISPs running CGNATs) might be happy to either ditch their NATs or split them up later on.
And this is what I said in my original comment, ipv6 has extra goals (like removing NAT day 1).
Extra goals? Removing NAT? Come on now... Don't act like NAT was invented along with the Internet itself, you know it wasn't.
And again, never ever conflate NAT with private networks.
NAT is a packet-modifying technique that is closely associated with stateful firewalls, but it still ain't firewall. If you want private networks, you would actually use a firewall, not NAT.
What's the big problem with NAT existing anyway, especially when you're free to ditch it on your own network? Maybe because the main point of getting rid of NAT in v6 is to allow any device to claim a public IP on default networks, for p2p applications. NAT's default behavior would get in the way of that. So it seems like ipv6 is about pushing default-allow behaviors onto network operators. Again this is pretty separate from the address space crisis.
Don't forget the context: we were talking about "removing NAT as an extra goal of IPv6," not "does it matter when was NAT invented".
So here I am reiterating my point again: It was never an extra goal, considering that IPv6 was designed in an era when NAT never predominated the internet.
>What's the big problem with NAT existing anyway,
Oooh no biggie other than breaking all sorts of P2P communication? It's so bad that we have to implement literal hacks like TURN and STUN on top of the hack that is NAT itself.
Or maybe we can talk about how it broke all sorts of protocols so badly that we to this day need application-level gateways[1] to help those protocols transverse NAT?
Or let's have some time to talk about how inefficient NAT is. You should know it requires computing power to track each connection flow and to maintain a state table for those flows.
>So it seems like ipv6 is about pushing default-allow behaviors onto network operators. Again this is pretty separate from the address space crisis.
What are you talking about? Default-allow and default-deny are both firewall rules. Even NAT (the "full-cone" or "endpoint-independent" ones) is prone to this, if a port is open everyone can connect to you through the IP:port.
I would say removal of NAT and addressing space is closely intertwined, but alas you seem to have pretty amateurish understanding of it.
Also, just in case you bring up your IPv4.1 again: all address space enlarging efforts will inevitably face incompatibility issues.
[1]: https://en.wikipedia.org/wiki/Application-level_gateway
I keep hearing this have your cake and eat it too kind of argument. "It supports P2P" and "just default-deny if you're worried about security" do not mix. We get one or the other as the assumed default. IPv4 + NAT is the default-deny. IPv6 seems to be about default-allow even if that's not inherent to it.
That's why you have the PCP protocol to help you setup a hole in your firewall, you default-deny until some host in your network says "I can handle port 12345". If your router doesn't support that, in the worst case scenario you can fallback to manually setting up firewall entries much like NAT.
Sure, PCP works in NAT cases too, but not always - especially in double-NAT or CGNAT scenarios. And we already know how prevalent CGNAT is, don't we? I don't know where do you live in, but here all ISPs have deployed CGNAT.
By the way that's one of the disadvantages of having NAT, you are forced into a centralized architecture where the central node in the ISP (the CGNAT device) decides what kind of niceties you could get.
IPv6, the ISP only carries traffic around and it does not meddle with layer 4 activities.
IPv4 only: 91%
If you want a more visceral feel to it - turn off "Hide IPv4-only services" and behold the sea of red.