AWS to start charging for IPv4 usage, but critical services don't support IPv6
old.reddit.com
old.reddit.com
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.
$ docker rmi amazon/aws-cli
<snip>
$ cd /tmp
$ python3 -m venv venv
<snip>
$ . venv/bin/activate
$ pip install awscliv2
<snip>
$ ssh -i mykey.pem ec2-user@i-masked -o ProxyCommand='awsv2 ec2-instance-connect open-tunnel --instance-id i-masked'
Unable to find image 'amazon/aws-cli:latest' locally
latest: Pulling from amazon/aws-cli
6ebddf7084e9: Pull complete
eb7d160dbc3b: Pull complete
af71d24e41d0: Pull complete
cf26adf9ea98: Pull complete
2491adb1df28: Pull complete
Digest: sha256:a8c8edb4641672d9ef61873594aa02d1c493341ca30f96e257fdc4d3da17ef9c
Status: Downloaded newer image for amazon/aws-cli:latest
A newer release of "Amazon Linux" is available.
<snip>
$ docker images | grep aws-cliSo 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...
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:
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.
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...
Perhaps AWS could run these endpoints through Cloudfront in order to get IPv6 reachability.
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.
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.
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...
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!
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.
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.
(I didn't bother looking for the quote's source.)
Not happy that AWS is pushing this and they don’t even fully support it.
IPv4 only: 91%
If you want a more visceral feel to it - turn off "Hide IPv4-only services" and behold the sea of red.
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.
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.
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.
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):
auto eth0
iface eth0 inet6 static
address 2001:db8:aaa:bbbb:cccc::dead:beef
netmask 64
gateway 2001:db8:aaa:bbbb:cccc::1
accept_ra 0
* 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.
dad-attempts 0
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):
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.
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:
/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
DST-ADDRESS GATEWAY DISTANCE
DAd 0.0.0.0/0 1.1.1.1 1
DAc 1.1.1.0/24 wan1 0
DAc 192.168.0.0/24 lan1 0
> 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.