AWS to start charging for IPv4 usage, but critical services don't support IPv6(old.reddit.com)
old.reddit.com
AWS to start charging for IPv4 usage, but critical services don't support IPv6
https://old.reddit.com/r/aws/comments/17rxig8/aws_wants_to_start_charging_for_all_allocated/
241 comments
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"
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
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
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.
SSM is powerful and convenient but very dangerous due to its huge surface area... I personally remove it by default.
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
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.
Newer versions of ssh have the -J option which lets you enter the bastion host and it does everything else automatically.
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.
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.
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..):
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.
$ 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.
You're confusing `awscliv2`[1], a third-party Python wrapper around AWS CLI v2[2], with instance connect. From its package page:
- 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
- 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
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.
Update: and now I've read through the github issue, oh my I've missed quite some drama.
I agree it's confusing and I think Amazon's reasons for dropping PyPI support are pretty lame:
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
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
It spins up docker containers to create an ssh connection?!
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) -
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...
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...
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.
Perhaps AWS could run these endpoints through Cloudfront in order to get IPv6 reachability.
It's called a price increase folks, don't overthink it.
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.
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.
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.
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.
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.
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.
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."
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."
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."
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 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.
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.
> IP addresses were intended to be a public good.
Were they though? The first few blocks auctioned off all went to large tech institutions
Were they though? The first few blocks auctioned off all went to large tech institutions
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.
Yes, see my reply to the other commenter above.
>IP addresses were intended to be a public good.
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.
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.
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.
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.
[1] https://aws.amazon.com/privatelink/pricing/
[1] https://aws.amazon.com/privatelink/pricing/
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.
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.
> S3 and DynamoDB access from privately addressed IPv4 VPCs is free, since it's implemented as routes not endpoints
TIL. Thanks!
TIL. Thanks!
I'm curious, why can't you use an elastic IP?
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.
[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
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
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.
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.
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.
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.
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.
> Examples include:
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.
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.
Azure and Google Cloud don't, and they didn't have full ipv6 support when making the change either
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.
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.
DigitalOcean do.
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.
Peace. ;)
So, these intermediate steps are just cooking the final dish.
Peace. ;)
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.
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.
Not just that, there are other networks too on IPv4. In industry automation, IPv6 is no thing at all yet.
Once GitHub works with ipv6 I’ll start to take it seriously.
IPv6 is a privacy nightmare, no privacy technology designed to fix IPv6, fixes it.
How is it any worse than IPv4?
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.
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.
"A price hike by any other name costs just as much."
(I didn't bother looking for the quote's source.)
(I didn't bother looking for the quote's source.)
It's James T. Kirk's. I think.
Abraham Lincoln, I'm pretty sure.
Yup and AWS CDK doesn’t support it either.
Not happy that AWS is pushing this and they don’t even fully support it.
Not happy that AWS is pushing this and they don’t even fully support it.
https://awsipv6.neveragain.de/
IPv4 only: 91%
If you want a more visceral feel to it - turn off "Hide IPv4-only services" and behold the sea of red.
IPv4 only: 91%
If you want a more visceral feel to it - turn off "Hide IPv4-only services" and behold the sea of red.
Global IPv6 adaptation is currently at around 40%, so maybe don't unassociate that IPv4 address from your load balancer just yet.
https://www.google.com/intl/en/ipv6/statistics.html
https://www.google.com/intl/en/ipv6/statistics.html
ALB doesn't support IPv6-only, so I couldn't even if I wanted to.
would be interested to see what they do to their lightsail prices
if you add these new charges onto the existing prices their offering becomes completely uncompetitive
if you add these new charges onto the existing prices their offering becomes completely uncompetitive
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.
[1] https://www.linkedin.com/in/adityasanthanam/
[2] https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...
> 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...
> IPv4 conservation 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.
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.
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.
Hmm... How much is human psychology - Scarce & Expensive is Desirable; Cheap & Plentiful is Low Class - discouraging migration from IPv4 to IPv6?
[deleted]
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?
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?
Why carry over mistakes from IPv4 when they have an opportunity to fix them? When else are they gonna make those changes?
And how would you propose making larger addresses without making them longer?
And how would you propose making larger addresses without making them longer?
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.
> 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.
>Special kinds of addresses
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 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.
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.
>But going v6 means redesigning your network.
>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.
>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.
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.
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).
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.
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.
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.
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.
Same story on every cloud, AFAICT.
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.
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.
IPv6 and Python3 are case studies in how not to roll out a new version unless you're cool with multi-decade upgrade windows.
Is there an alternative, though? Both Python3 and IPv6 both solve problems that would have been at least as painful to do incrementally, IMHO.
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".
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).
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).
> 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. (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.
On Debian with interfaces(5):
* 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.
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.
You also need to turn off DAD because if the computer comes up without a link, DAD will fail with a timeout and ifup will leave IPv6 unconfigured.
So:
dad-attempts 0
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.
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.
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.
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 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".
Except you still need all that complexity as you need to support IPv4 as well.
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.
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.
Uh... what.
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.
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.
Indeed. IPv6 is something very different from IPv4.
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...
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...
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.
> Is there an alternative, though?
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
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
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.
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.
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.
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.
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.
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...
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...
> 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 :-)
> 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 :-)
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.
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.
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.
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.
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.
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.
[deleted]
MagicMoonlight(11)
exabrial(14)
Switched to heroku. 1/5th the price with Postgres service. Still use s3 for storage though.
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.
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.
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.
OS and hardware support is not the bottleneck.
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.
[deleted]
Yep, this idea comes up every time because it's actually a good idea.
And every time people explain why the idea is either impossible or describing v6's existing behavior.
At what point do these posts become trolling?
At what point do these posts become trolling?
I've yet to see a satisfactory explanation of either. It's always basically "you'd still have to change the headers" which misses the point.
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.
> You just support longer addresses, that's it.
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).
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).
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.
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:
* 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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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?
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.
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.
> 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.
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.
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).
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.
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.
> You just support longer addresses, that's it.
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 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.
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.
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. 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!
> 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).
???
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).
> 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.
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.
> 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:
> 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.
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.
> 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 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.
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.
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.
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.
I agree and have said similar things. The address exhaustion thing is an excuse for tons of unrelated changes in v6, plus resetting ownership.
So sick of reading this idiotic take EVERY time IPv6 comes up
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.