AWS is estimated to make $400M to $1B with the new IPv4 charge
border0.comWhat's really offensive about this is that AWS does not have good enough IPv6 support for most customers to migrate off of IPv4, even if they want to.
ALB uses 2-4 IPv4 addresses. It supports dualstack, but not IPv6-only.
CloudFront does not support IPv6 origins.
All APIs except for a handful are IPv4-only, so you either need a VPC endpoint (priced per month per AZ per API) or an IPv4 address to communicate with them.
It frustrates me that I'll be paying for a bunch of IPv4 addresses that I don't need for any business reason, I only have them because they're necessary within the AWS ecosystem.
I find the lack of IPv6 support for their own APIs the most insulting. In my case, I would end up paying more for VPC Endpoints than I would for IPv4 addresses. There is no escaping from this new fee. I really hope they resolve this soon.
It's also pretty ridiculous their reverse proxy (ALB) "dual stack" mode can't serve IPv6 clients unless your backend app server is also IPv6. This is so much worse than anything you'd set up yourself.
That doesn't seem right, for example this reddit thread (yeah, I know) says that ipv6 alb -> ipv4 target should work fine: https://old.reddit.com/r/aws/comments/1145bcw/dualstack_alb_...
Like most of the people in the linked reddit thread, I read the docs (and web search results[1] and LLM answers) as requiring v6 behind the ALB too. Not taking the poster's word for it yet but could be worth another look.
[1] https://repost.aws/knowledge-center/elb-configure-with-ipv6
https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-su...
yeah, that's a sad table. AWS has gazillion services and handful have even basic dual-stack support and even fewer have ipv6-only support :(
What's interesting to me is that they always had this cost, but in the past it was always baked into the cost of anything that used a public IP (namely EC2).
The prices for IPv4 addresses finally got so high that they had to break it out into a separate charge because otherwise it would be too much to bake into the cost of everything. I also completely believe them when they say they are doing it to force people to be more intentional about their use of public IPv4.
And of course it's a great way to get people to move to IPv6, since those are still "free" (in quotes because those prices are still baked into the things that support them).
> And of course it's a great way to get people to move to IPv6, since those are still "free" (in quotes because those prices are still baked into the things that support them).
They are basically free because there is no shortage of them.
The costs to AWS are having to upgrade all their routers and any other equipment that handles IP (including the management cards in each physical host).
What percentage of their routers were acquired pre-IPv6? S3 wasn't publicly available until 2006, EC2 followed later. Was most enterprise networking equipment in the mid 2000's still without IPv6 support?
There is no way AWS has any equipment that is not IPv6-ready. These things are replaced about every 5 years or so. I bet it's all software that assumes IPv4, which is arguably worse.
AWS is selling still M4 instances that originally date from 2015, nearly 10 years ago https://aws.amazon.com/about-aws/whats-new/2015/06/introduci...
AWS is holding onto those routers running something earlier than, what, IOS 12.4 from 2005? And all those servers with iDRAC6s from, what, 2012?
Some day people will stop pretending IPv6 support is something that hasn't been ubiquitous in network gear for a decade or more.
The gear might support it in theory, but may not actually have sufficiently powerful CPUs or enough RAM to actually handle all the traffic. Also there is a bunch of software in between that needs upgrades.
If it were easy and straightforward they would have done it years ago. The fact that even today most things AWS don’t support ipv6 tells me that it’s hard.
If it were easy and straightforward they would have done it years ago.
You have absolutely no idea what their constraints are or what their IPv6 decision making process is. Neither do I. It might be operational issues. It might be legacy code. It might just be because they've figured not doing it makes them more money or because they think not enough customers are asking for it. Hell, it could be as simple as the right executive thinking "IPv6 is a fad" and roadblocking. But it's not "because the hardware doesn't support it"; that's a long ago solved problem. And AWS designs/builds their own networking gear, so they aren't waiting on Cisco or whomever to give them what they need...they would have done it years ago.
> You have absolutely no idea what their constraints are or what their IPv6 decision making process is.
Yes I do. I've talked to them about it in depth.
> But it's not "because the hardware doesn't support it";
I never said the hardware doesn't support it. I said the hardware needs upgrades to support it at their scale, which includes software updates to the hardware, as well as the operations around said hardware.
It's been a priority for them for years and customers have been asking for years. It's not done because it requires a lot of work and capital. Hopefully the revenue they bring in from charging for IPv4 will help offset the cost of upgrades.
Yes I do. I've talked to them about it in depth.
Thanks for that. I needed a good chuckle after today.
And thank you as well. Everyone’s a comedian today apparently.
I mean you can choose to believe me or not, but I just worked at Amazon for the last two years and worked with AWS networking products while I was there, including this: https://aws.amazon.com/blogs/networking-and-content-delivery...
You know there are actual network engineers who've like, written IPv6 RFCs here right?
You know he's like a Staff Engineer at Amazon right now right?
Surely by now all of their equipment can support IPv6 with at most a firmware upgrade?
Did they reduce the cost of everything that it was baked into? Did EC2 instances get cheaper?
If history is any indication, they would either reduce the cost or just not raise it for a while. AWS is usually pretty good about keeping their profit percent steady and adjusting prices accordingly.
This is the only way IPv6 will ever finally take off; if there's a cost to IPv4.
Money is a terrible discriminator unless you want to advantage the rich. This would fuck up connectivity for everyone that relies on affordable hosting long before it'd force a rusted old enterprise to adopt IPv6.
dig github.com AAAA
I hear you, and do appreciate your point. But, what other incentive alignment levers are available for corporations than their bottom line?
Also, I'm just saying:
I'd bet that's in no small part due to them hosting on GCP$ dig gitlab.com. AAAA 2606:4700:90:0:f22e:fbec:5bed:a9b9Interestingly, it seems AWS is the outlier in the "IPv6 control plane is a fad" stance
$ dig admin.googleapis.com. AAAA # as one might expect 2607:f8b0:4005:810::200a $ dig management.azure.com. AAAA # which surprised me 2603:1030:a0b::10 $ dig ec2.amazonaws.com. AAAA # :trollface: $ dig ec2.amazonaws.com. A 209.54.181.135
The EC2 API is available over IPv6. AWS services that support IPv6 for their APIs use the .aws TLD and the SDKs and CLIs know how to invoke that when IPv6 is preferred. See https://docs.aws.amazon.com/general/latest/gr/rande.html#dua...$ dig AAAA ec2.us-east-1.api.aws ... 2600:1f70:8000:a0:41d7:f53b:34f4:5798The reason is for backwards compatibility. If IPv6 was simply added to the original names, some clients would instantly shift from using IPv4 to IPv6 and in the process break any customer IAM policy in place that is restricted by IP address. Some day it may be the right call to let that kind of breakage happen, but for now the preference is to ensure that customers are not surprised.
See also: https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-su...
I'm not trying to shoot the messenger, but that is pretty up there in the list of dumbest things, and accompanying reason for dumb things, I've heard in quite a long time
Also, I especially enjoy that control-f "iam" or "sts" on https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-su... is all hurp-durp as is $(dig sts.api.aws. AAAA) so I guess one should be sure to email themselves some credentials in any such IPv6-only EC2 setup. I wondered if it was just a documentation oversight but https://docs.aws.amazon.com/general/latest/gr/sts.html seems to agree
Now I'm just deathly curious and will try to remember to boot up one of these allegedly IPv6-only EC2 setups to see what running $(aws --debug sts get-caller-identity) does from one of those Instance Profiles
You're not shooting the messenger. I signed off on this strategy. In our case, quite a number of customers lock down their IAM policies with IP address based permissions. They have rules like "This account can be used only from our datacenter", or "These EIPs are the only legitimate source for changes" that help them defend against credential theft. There are other defenses, but for some ... this simple defense makes sense. My understanding is that GitHub have a similar challenge, and you can see in their note at: https://docs.github.com/en/enterprise-cloud@latest/organizat...
If we turned IPv6 on like a light switch and suddenly broke all of those customers whose traffic would flip to IPv6 ... that'd be pretty bad. That's not dumb. So instead we have dedicated endpoints for IPv6 and are working with customers to get their policies updated and tested.
For IAM creds on an EC2 instance it's more common to use EC2 Instance Roles. Those are retrieved locally from the IMDS, which is available over IPv6. We have a number of customers, including some large ones, running IPv6-only on their EC2 setups.
> So the approximate value of Amazon's IPv4 estate today is about: $4.6 Billion dollars!
> AWS will likely make anywhere between $400 Million and $1 Billion dollars a year with this new IPv4 charge!
In other words, it's not clear AWS is "making" anything at all. It might take them over 10 years to pay back the cost of what it would take to acquire them today.
Now I assume Amazon is making some level of profit on them, but the article seems to confuse income with profit. "Making" money is generally understood to mean profit, not income.
The IPv4 space almost certainly did not cost them $4.6 billion to acquire. They acquired it much cheaper, and they can’t reasonably sell it because they need it for users. So charging for it when they previously did not nets them revenue they were leaving on the floor before.
The exact price doesn't matter. The point is, it's wrong to conflate profits with income. You need to subtract costs before you can declare that Amazon "makes" a particular amount of money.
You are of course correct that this gives them revenue, my point is that the article is falsely framing this entirely as profit.
The costs were already paid. AWS bought that IP space over the past decade. On their financials for 2024, the cost of the IP space they already held is zero.
They already own those IPs and there is no ongoing fee to keep owning them. So everything they make is profit since they costs have already been accounted for.
Like if you already owned a piece of land and let people rent houses on the land, and now you're charging them extra rent per square foot of land. You already own the land, so it's pure profit, because before you were including the cost of land in the houses. But of course the metaphor breaks down because at AWS you can move to IPv6 to avoid the cost, but you can't move the house off the land.
That is not correct.
IP addresses are intangible property and, at this scale, their cost would probably be amortized over a period of e.g. 20 years.
For accounting (and tax purposes), it's not one big up-front cost where everything that follows is pure profit.
Just because costs happen before income, it doesn't follow that all the income is profit. You have to look at things over the expected useful time frame of property.
> Now I'm sure Amazon is making some level of profit on them, but the article seems to confuse income with profit. "Making" money is generally understood to mean profit, not income.
Common clickbait tactic, hence avoiding the use of falsifiable terms like net income or profit.
But did they acquire them all today? (No, no they did not.)
What is raging is to know that IP v4 address ranges are provided at no cost to organisations. And even if they still had to acquire some from other organizations at a cost, there certainly don't have to pay a regular fee to keep them.
So in the end, they take a public good that is basically free, a lot lot lot of it, and like a hold up they make a lot of money racketeering you monthly because you are too insignificant to be allowed to own your own ips...
This is not true at all, at least in the ARIN service region.
* Aside from a very minimal amount of space allocated for v6 transition technologies[1] and from the waitlist[2], organizations do have to pay market rates for IP addresses.
* Organizations do need to pay a yearly fee to keep them, which scales with the amount of address space held.[3]
* You are not too insignificant to be allowed to own your own IPs - anyone can establish at least 2 peering relationships, ask ARIN for an ASN, and acquire some IPs.
[1]: https://www.arin.net/participate/policy/nrpm/#6-5-3-1-subseq...
[2]: https://www.arin.net/participate/policy/nrpm/#4-1-8-arin-wai...
Related discussion on the ipv4 change announcement 6 months ago:
AWS to begin charging for public IPv4 addresses
If Google just banked $3B by extending their server depreciation schedule, imagine how much more profitable AWS would be if they also did the same.
https://news.ycombinator.com/item?id=39199841
I wouldn't be surprised if AWS are holding back on implementing this financial change for a future raining day quarter ... because it'd have a bigger impact than IPv4 billing.
Jeez. Eventually someone is going to break down and invent a new IP solution that doubles the number of addresses that we have now.
I mean if I were doing it, I'd probably make it more like 1,028 times bigger but maybe it would present as hubris. Addresses would be so plentiful they'd basically be free.
And since I am using magic to do all of this, I'd invent it over 20 years ago, so that it'd have been decades since we were still talking about it.
This ongoing "IPv4 with more bits" meme needs to die.
There was no way to change IPv4 to have more address space while maintaining compatibility with existing routers. Routers are hardware-accelerated so can't just support new protocols with a software update.
If you need a new protocol, why just lengthen the address without fixing other weaknesses, since you'll never be able to change it again? This is IPv6, and while you can argue some changes weren't necessary, it is simply not true say that IPv4 with extra bits would have been easy.
"If we don't study the mistakes of the future, we're bound to repeat them for the first time." - Ken M
And I would make sure it had complete feature parity with IPv4 (DHCP, VRRP etc) instead of embarking on a religious crusade to reinvent the way devices connect.
It took over a decade to get feature parity from the non-network-operators that overtook the IETF, and that seriously delayed IPv6 adoption.
I know you're joking & making fun of glacial IPv6 adoption, but if IPv6 was just IPv4 + more address bits, I'm sure it'd be fully adopted by now and IPv4 would be something kids taking computer networking courses would be taught about in the "history" section.
IPv6 involved too many other changes to make it a straightforward upgrade. I agree that it's ridiculous that we still don't have universal v6 support, but let's not pretend the protocol designers made it easy.
There's new features in IPv6 but if you don't use them, it's pretty just more bits as far as applications and users can see. The biggest change is probably replacing ARP, but that part has been unchanged and shipping since the start and invisible to users. And of course there's also simplifications vs IPv4.
The biggest shock is for people who have gotten the NAT stockhold syndrome (which always went against IPv4 internet architecture, there's a reason it's outlawed in the standard track IP RFCs).
To be fair, a lot of the growing pains with IPv6 were pains that had to be discovered as we went.
I wish IPng had taken a totally different approach to addressing and routing:
- for addressing, yes, very large (or even variable-length, like CNLP, see below) addresses fields in the IPng header
- for routing, the IPng header should have had a source and destination ASN fields, with the source being filled in by the sender's router(s) (either immediately in the interior, or at the edge), and the destination ASN fields to be filled in by the sender by querying something like the DNS (but optimized for, essentially, CIDR-style IP->ASN lookups, though DNS can do it). This would have made routing much simpler and faster, since routing protocols would only have to exchange information about ASNs and not about any address prefixes, thus yielding much smaller routing tables. The address->ASN lookup service would have needed very little churn since its contents would change only when sites change Internet service providers.
I wasn't there then, so don't blame me, but also honestly I probably wouldn't have thought of this either.
In practice we ended up with something just like this but... without address number portability, which is a shame.
So what's taking you so long?!
time travel machine mvp is taking a bit more than planned
So far it can only go forwards in time [at 1s/s].
IPv5 xxx.xxx.xxx.xxx.xxx for the win! /s
Tbh not sure why the protocol couldn't be upgraded so that xxx.xxx.xxx.xxx, xxxx.xxxx.xxxx.xxxx and xxx.xxx.xxx.xxx.xxx are all accepted. Seems a monumentally shite oversight to not be like that. I mean it's a freaking telephone book address system. Astounding they baked it in just xxx.xxx.xxx.xxx and didn't upgrade the protocol at all in the last 20 years (is this just entirely due to profit/asset protecting?).
Response was to make a wholly new protocol when they could have just updated the standard and forced suppliers to patch updates?
USB backwards compatability that shiz. The fact I can take a modern usb device and plug it in a 1.1 gen port and it still just works. Why the hell isn't ipv4 like that for upgrades?
Seriously is there any real technical hurdle why we didn't do it this way?
This very confident sentiment comes up in every comment section about IPV4/6
- "Updating the standard" is making a new protocol
- "forced suppliers to patch updates" - how?
- "USB backwards compatability that shiz. The fact I can take a modern usb device and plug it in a 1.1 gen port and it still just works. Why the hell isn't ipv4 like that for upgrades?" - because you're changing the address space of the protocol. If the new standard can address more than 2^32 things, then it won't be backwards compatible with v4.
- "Seriously is there any real technical hurdle why we didn't do it this way?" - Assuming you're talking about having a variable-length address from the start in IPV4, because I assume having a non-fixed packet header size would be much more computationally expensive and violate a lot of assumptions that you can make when the header is fixed (having a fixed region of the buffer that is known to always be the full header). You'd be much better having a fixed-length address that is enough to cover all possible nodes in the network - exactly what IPV6 has done.
- "Astounding they baked it in just xxx.xxx.xxx.xxx" - IPV4 was first deployed in 1982. Wikipedia tells me that the year before, there were just over 200 nodes on the ARPANET. I think you're doing a bit of a disservice to the people who designed this stuff by castigating them for not factoring a 20'000'000x increase in network size into their protocol.
Because I don’t want to feel like I’m shopping at IKEA when I’m configuring my router.
Here are all the IKEA products you can spell in hex:
A16 ALG, A15EDA ALSEDA, A77E57 ATTEST, BA66E BAGGE, BA615 BAGIS, BA7157 BATIST, BEA7A BEATA, BE57A BESTÅ, BE7A BETA, B1BB1 BIBBI, B155A BISSA, B1716 BITIG, B1AD BLAD, B1ADE7 BLADET, B0A17 BOALT, B0110 BOLLÖ, B055E BOSSE, B0A5 BOÅS, BA5715 BÄSTIS, DA7A DATA, DE701F DETOLF, D10D DIOD, D170 DITO, D177E DITTE, D0F7A DOFTA, D01D DOLD, DA71D DÅTID, ED17 EDIT, E1DE EIDE, E16A ELGÅ, FAD0 FADO, FA5 FAS, FA57B0 FASTBO, F1BBE FIBBE, F1A7A FLÄTA, F070 FOTO, 6A5E11 GASELL, 61DEA GIDEÅ, 61E5 GLES, 610BA1 GLOBAL, 610DA GLÖDA, 60D15 GODIS, 605A GOSA, 60516 GOSIG, 1BE57AD IBESTAD, 157AD ISTAD, 1ADDA LADDA, 1ADE LADE, 1066A LOGGA, 1075 LOTS, 1A77 LÄTT, 0B1 OBI, 0DDA ODDA, 011E OLLE, 5A1B0 SALBO, 5177A SITTA, 50DA SODA, 50F1A SOFIA, 501 SOL, 50157A SOLSTA, 57A11 STÄLL, 7A6 TAG, 7A55A TASSA, 7177A TITTA, 70B1A5 TOBIAS, 70B0 TOBO, 70F7B0 TOFTBO, 706A TOGA, 7016 TOLG, 7016A TOLGA, ADA1 ÅDAL, A5E1E ÅSELE, 061A ÖGLA
Quite a few actually. I used https://lar5.com/ikea/ for the input words.
> Seriously is there any real technical hurdle why we didn't do it this way?
Yes, because designing and implementing a protocol like USB is nothing like designing and implementing an internetworking protocol.
> not sure why the protocol couldn't be upgraded so that xxx.xxx.xxx.xxx, xxxx.xxxx.xxxx.xxxx and xxx.xxx.xxx.xxx.xxx are all accepted
You can't just add address bits to a fixed-size protocol header that wasn't intended to be extended in that manner. IP addresses don't actually look like those dotted strings you're talking about. Those representations are for convenience and ease of reading for humans. For computers, it's a 4-byte quantity that's sent over the wire in binary, not a string of base-10 numbers separated by dots. When these things were designed, CPUs, custom processing units, and RAM were incredibly expensive. When you designed a protocol, you designed it for efficiency in size and parsing speed. Otherwise no one would implement your protocol, because it wouldn't be cost-effective to do so. Today we throw around JSON payloads in our HTTP responses without a care for the bandwidth needed or processing power used to parse. If you tried to do something like that back in 1981 when IPv4 was introduced, you'd be laughed out of the room and fired.
Your middle suggestion ("xxxx.xxxx.xxxx.xxxx") makes no sense: each part of the dotted-quad notation we're familiar with represents an 8 bit quantity (base-10 numbers 0 through 255). Adding another base-10 digit is nonsensical. The last example, a dotted-...er...quint? is certainly one option, which would increase the address field in the header from 4 to 5 bytes, giving us 256 times the current number of addresses (more or less). IPv6, instead of going from 4 to 5 address bytes, goes to 8 address bytes. That allows us to give every grain of sand on all the Earth's beaches an IPv6 address, several times over. Overkill? Maybe. Probably. But consider how long it's taken to adopt this new protocol. If we were to only add 1 more address byte, and then run out of addresses again, we'd likely have to wait even longer than this time for a future IPv7 to become adopted.
Now, going back to the fairly modest 1-byte increase in the address fields (and presumably no other protocol changes). For some devices a fairly simple software update would suffice, but for many router-type hardware of the time (25+ years ago), it wouldn't have been feasible to solely upgrade the software or firmware. Consider that things like routing tables would now require 25% more memory per address, and memory was something routers of the time didn't have in abundance. And some of these older pieces of hardware actually had parts of the protocol "parsing" done in hardware, which you can't change after the fact; you need to scrap the entire thing and build something new.
I do agree that it was foolish to design a whole new protocol. If they'd just released a new protocol where the only change was more address bits, I'm sure it'd be fully adopted by now and IPv4 would be a thing of the past.
What probably could have been done (and kind of was done with NAT) would have been to move one byte from the port number to the address, giving us 256 additional “Internets” worth of addresses but limiting each address to 256 ports.
That's a good idea; it's called MAP-T.
Here's a NANOG presentation: https://www.youtube.com/watch?v=ZmfYHCpfr_w
You could do that, and if you did, I think you'd find a lot of success with your new solution, as people the world over would switch to using it.
Just make sure you make it as user-friendly & functional as its predecessor and don't stuff a whole bunch of nonsensical half-baked features into it. Otherwise, people may have no choice but to keep using the older solution.
That's awesome. I have no doubt you would use common sense and make the addresses in this new system simple, recognizable, and just an extended version of what everybody is already used to, like 111.222.33.44.55.66
This right here was the biggest mistake for IPv6. Adoption would have been so much easier if IP6s were just "extra numbers" tacked onto the end so that if an old router saw it, it would ignore the extra bits and send it to the "IPv4" part of the address.
That's not how routers or routes work.
I'm aware of how routers work and this is obviously simplified. But basically you would just have a high part of the address that would be outside the mask, and old routers would just ignore it.
So your IPv6 would be 1.2.3.4.5.6.7.8, and old routers would just see 5.6.7.8 and route to the place where that IP should go. The router at 5.6.7.8 would be responsible for understanding IPv6 and how to route from there with the full address.
That wouldn't work either. Why would the 5.6.7.8 router necessarily know how to route to the longer-address destination? There's no guarantee it's been upgraded. And why should it have to, anyway? It could get DoSed (accidentally, even) by traffic intended for a completely different destination outside its control.
Also consider that even if that 5.6.7.8 router knew how to route to the 1.2.3.4.5.6.7.8 network, it would have no guarantee that the packets wouldn't hit another router along the way that didn't understand the extra address bits. You could end up with weird routing loops and other issues. (Fortunately TTLs would quash these, but not after wasting a bunch of extra resources.)
Now, there might be some clever ways to work around this, and it might require some more internet infrastructure to deal with these routing challenges. Maybe that would have been faster and cheaper to deal with than the current IPv6 mess we have, maybe not.
The device with IP 5.6.7.8 would have to be capable of routing the new packets, but nothing in between would. Just like today the device at 5.6.7.1 has to know how to route 5.6.7.8/24. It’s just assumed that the special IP knows what to do.
> So your IPv6 would be 1.2.3.4.5.6.7.8, and old routers would just see 5.6.7.8 and route to the place where that IP should go.
Thats absolutely not what would happen to an IPv4 only router though. You're fundamentally misunderstanding what IPv4 actually is.
That IPv4 router getting a packet with a source address of 9.10.11.12.13.14.15.16 addressed to 1.2.3.4.5.6.7.8 wouldn't know to route it to 5.6.7.8. That packet would be parsed as a source of 9.10.11.12 and a destination of 13.14.15.16. The real destination would have been spilled over into the Options header or payload of the packet. This is because in IPv4, bits 128-159 are the source address, 160-191 are the destination. Having a 64-bit address mushed into an IPv4 packet would just lead to those bits spilling over to the next location.
An IPv4-only router would not be able to route your theoretical IPv6 packet.
I assume the high bits would be in the variable length ip option field. So to an old stack it would look like a packet from 13.14.15.16 to 5.6.7.8. Both of those devices would have to be capable of routing ipv6 packets, but nothing in between would.
Hmm, might work for the middle boxes that just do routing.
This would then only really work with both ends supporting this new IPv6 though. If one side only spoke OG IPv4 and the other side spoke this weird IPv6 with half its address bits in the header, there's a good chance the IPv4 side would just ignore the header bits on its return packets and thus wouldn't address it right. So, while that router in the middle might route these packets OK, you'd still practically need an IPv4 address to talk to other IPv4 devices. Which means we'd still have this mixed support, or that 5.6.7.8 would need to pretty much be a complete stateful NAT keeping track of connections for 6 to 4.
> or that 5.6.7.8 would need to pretty much be a complete stateful NAT keeping track of connections for 6 to 4.
Yeah, that would be the transition period. Where any v6 router would also be a NAT gateway for any OG connections and would have to have both a v4 and v6 address.
The potential number of edge cases in IPv4-only hardware is staggering.
For sure, and they would have been found really quickly. But in either case, it would involve fixing or upgrading the hardware or software, which is true whether we do it with extra numbers or the whole new scheme for IPv6.
Can't they provide an anycast ip's like fly.io does to all their customers. Most of the things are anyhow behind dns entries and i doubt people direct hit IP addresses.
They do, it's called Global Accelerator
article turns into an ad at the end, just a FYI