AWS: IPv4 addresses cost too much, so you’re going to pay
theregister.com
theregister.com
Seeing something like that makes me think that AWS is completely justified in bumping the price on IPv4 addresses. People used IPv4 indiscriminately and didn't care because AWS ensured that their customers would always have enough addresses available.
And their native support for IPv6 within their services are hit-and-miss at best.
Load balancers are already somewhat expensive- the base cost for each load balancer is already $16.43 a month before bandwidth. Three IP addresses, 12 cents per day each, over 30 days is another $10.80 a month. In other words load balancers just had their base price increase by 65%.
Some of the ecosystem must be ready for it, and ipv6 support can be just another requirement to choose among solutions.
Also, you can have a reverse proxy and a cloud behind NAT64 to run servers on ipv4, but access them with ipv6.
I'm somewhat happy in that I've moved away from being way down at the low-level ISP/network side of things, so I may be missing something, but I don't see how we are ever going to elegantly transition away from IPv4 addresses. Everything just seems hacky and fragile in terms of trying to run a "pure" IPv6 environment, and be connected to the rest of the Internet.
That should simplify the network over dual-stack deploys, plus it makes providing services in "native" IPv6 the more attractive choice over NATted-to-death IPv4.
There are already some ISPs doing this. In Japan, where I live, one of the big three, NTT Docomo transitioned into a deployment like this just last year.
Edit: Ah, uses port numbers as extra bytes to encode the original senders address information. Smart!
Luckily that does not seem to be an issue here. You only have to pay for a public IPv4 address, you still have a full IPv4 stack and are able to make outbound connections via NAT.
There ain't no such thing as a free lunch.
It's possible that the business model has changed, but at least on this blog they say it's available free of cost.
> The NAT gateway recognizes the IPv6 address prefix, extracts the IPv4 address from it, and initiates an IPv4 connection to the destination. As usual, the source IPv4 address is the IPv4 address of the NAT gateway itself.
If the NAT Gateway doesn't have an IPv4 address it won't work.
Specifically:
> Regular NAT gateway charges may apply.
Which should say: "Regular NAT gateway charges apply"
Since you still pay for the traffic that is processed by the NAT gateway (per GiB).
https://github.com/orgs/community/discussions/10539 is full of people voicing their grievances but I don't think Github is paying this issue any attention anymore.
Luckily almost all providers or IPv6-only networks also offer NAT64 or similar NAT mechanisms to make IPv4 addresses reachable.
Thanks so much!
All those engineers left or retired and have been replaced by outsourcers and H1Bs.
Nobody at Azure can even spell IPv6.
Turning it on is difficult and then it breaks everything, including unrelated services in other peered vnets.
It’s just shameful how much the engineering skill has degraded in Redmond.
If you need more than web traffic, you can use our Tunnel service.
(Now I only have IPv4, so I just use Tunnel).
You get A and AAAA records by default.
Would the earlier product be used for something like a router, which can't run the Tunnel service?
But a big problem is that there is still no Ipv6 auto configuration at all on a lot of devices (e.g. no default gateway or no global address configured). Especially android devices and from experience also on Windows. Linux depends on the distro. Changing routing settings on android devices from Ipv4 to Ipv6 does often not work or is not offered by the ISP strangely.
And there are other problems like routers having enabled incoming and outgoing Ipv6 connections by default, which is good, but having router advertisements blocked by default, which is bad. Since there is no way for the OS to get the prefix to construct global addresses automatically. Most users today have little to no knowledge about networking and computers in general. So auto configuration is a must.
That leads to Ipv6 only servers being not reachable and thus the buying of Ipv4 addresses makes a lot of sense at this point.
Some countries are doing better than others (https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...), but still, ISPs are really dragging their feet...
The other big foot-draggers are corporate networks. Even if the ISP supports V6 many corporate networks do not because two generations of IT professionals learned how to do networking entirely through the lens of NAT as a requirement and don't understand how to do things without it. I've seen many IT peoples' brains just melt at the idea of things just having one address. In reality it simplifies things dramatically but sometimes getting people to grasp a simpler solution is actually harder than getting them to grasp a complex one.
I live in the USA and have had IPv6 at home for over a decade (and have used three different ISPs in that time). Many mobile networks are IPv6-first.
That being said, you can do NAT on IPv6 if you really want to, and maybe it will be needed to help soothe those with those emotional attachment to certain numbers. [fc00::192:168:1:0]/120 or [fc00::10:44:0:0]/96, for example.
V6 NAT is unnecessary and dumb but it works better than V4 NAT.
Ipv6 is overly complicated and has been riddled with bugs for 30 years now. As long as ipv4 is an option many are going to choose to completely disable it. Some of the security concerns cannot be effectively filtered at all. There are numerous examples of these vulnerabilities from even just the last few years.
It’s hard for teams of engineers to secure properly much less a home user.
I completely disable ipv6 even with a deep understanding of it.
CenturyLink (or Lumen or whatever they want to call themselves today) only has 6rd, at least in my neck of the PNW. And it's best if you don't use it, as their CPE tends to do bad things if you do; my initial CPE would reboot if a fragmented 6rd packet came in over the WAN interface. The current CPE doesn't reboot, but v6 packets sometimes take about 1 second to transit the CPE, so I gave in and run the CPE as a bridge and do PPPoE on my own equipment.
Nowadays, you shouldn't be allowed to advertise "internet access" if ipv6 isn't supported.
Ipv6 is the current protocol. And some sites don't have ipv4. (Amazon charging an extra for ipv4 is another sign that ipv4 should be a protocol for particular use cases, not for "the internet")
And it should be the same for software and connected hardware. No ipv6 ? That's not a product that works over the internet.
On a personal side, what I host is only working on ipv6, as my ISP has stable ipv6 but not ipv4, and for the convenience of configuration.
And even cheapo internet plans on mobile and landline support ipv6 by default nowadays. (The government pushed for it)
It's A protocol
> And some sites don't have ipv4
Yet there are far more sites that don't have ipv6 access.
What's the ipv6 address for hacker news?
For me it's the other way around - I disable IPv6 on all my servers and only host anything on IPv4. I know it's frowned upon in networking circles, but IPv4 "just works" for me, and I want to reduce attack scope and maintenance burden (I had some problems with IPv6 messing things up, or my ipv6 firewall misconfigurations).
Need to host something via HTTP? mod_proxy to the rescue.
IPv6 is junk protocol, overengineered. I hope IPv6 will be used for all those internet consumers and IPv4 will stay where its place to be, interesting R&D projects :)
The problem is that when you autoconf on a local network you usually want more than just a route and basic DNS. Trying to do it in the IP protocol is a bad idea since the IP protocol is intended to almost never change. It belongs in a protocol that's less tightly bound to the IP stack that can be more easily extended like DHCP.
DHCP can also integrate with things like local DNS, while this is much harder to do with IPv6 RA and SLAAC.
SLACC is something that sounded good on paper but doesn't adequately capture the entire problem domain.
IPv6 in general needs to just deprecate all the parts of the protocol that are anything but just making IP addresses larger. Everything else is "second system effect" cruft that tends to impede adoption by adding complexity or adding features in the wrong place in the stack.
Good news! Nothing in SLACC (sic) prevents you from using DHCPv6.
But now, since we have SLAAC as well, you get auto-magic working with simple link-layer connectivity without having to bother with extra infrastructure. If you need extra functionality, you have the option (not necessity).
Overall these days, beyond Google products, I think the ecosystem is in a healthy spot now and I think IPv6 chose the right path. It can still be a bit more hassle to manage in the enterprise space though and that's the one that needs to most convincing to migrate at this point.
You don't even need 64 bits. IIRC with SLAAC you send NDP messages to the entire broadcast domain. So you need broadcast-domain-sized (i.e., small) device counts on every data-link-layer subnet. So why assign /64? But because some devices won't give up if SLAAC routers aren't there and and some mysteriously default to SLAAC when they shouldn't and in fact some devices only use it, now every bottom level subnet has to be /64. Blech.
This is just one of many IPv6 annoyances that don't even need to exist.
Uncooperative ISPs will always exist. If the minimum size was /96 they'd hand that out instead of a /64. If there was no minimum size then they'd hand out a /124 or something equally as stupid. For all of the corporatize ISPs and well planned uses, starting at a /64 makes the rest of life easier.
It's the same logic, though often more accepted in this case, as the minimum advertiseable prefix on the internet being a /48. That also has nothing to do with how many theoretical end clients could fit in that and everything to do with what that actually means to equipment, scaling, and implementation planning.
Answer: Android.
This makes DHCPv6 pretty much useless in practice, when 30% of the clients simply can't use it.
Servers on the other hand, I will provision with a static IP subnet on deploy, as part of the PXE install or configuration management process, depending on the environment. They will have an ephemeral address during the install, but then query for and persist their allotted address before rebooting into the installed environment as part of their post-install.
I guess we agree that we need a single source of truth, what physical device has what IP (range) in their possession at any time. DNS is a classic way to do that, but there are other solutions, from ITIL-style CMDBs to simple config management git repos. And of course the latter doesn't mean that we don't also update DNS based on IP-assignement, DHCP is not the only tool that can be made to interface with a DNS service.
Not really, proxying also provides user privacy, and enables DDoS protection (this is especially an issue in the video game world).
Also I just did a cleanup recently myself of this and migrated an account to a hub/spoke security VPC with transit gateway. AWS makes it real pain for running instances to migrate to private IP only. You have to play games with adding a second NIC/EIP to workaround this.
There should be a “wizard” type walkthrough to guide novices through creating their first VPC (they’d generally be managing AWS via “clickops” so a wizard type UI would work here).
The biggest complaint I have with it is that it doesn’t write ID values to well known SSM parameters within the region.
And then just use one of the zero-trust overlays to secure communications between nodes.
In theory those are deployed in the private address space behind a load balancer, but getting any actual information on the production deployment was like pulling teeth.
At peak times, the clusters had substantially more than 1k API instances running together; none of the the API instances ever had a public address, and not for cost reasons.
Everything was on EC2, behind a bastion; you had to jump through two jump hosts to SSH to particular boxes (containers were not a thing yet). Everything ran on private networks. Everything was exposed through load balancers (HAProxy) via 2 or 3 public IPv4 addresses; I think one of them was only to interact with an off-AWS third-party service over the public internet.
Yes, it was a startup, just very technically-minded.
This always leaves me puzzled about the concept of "free markets." How can smaller entities compete when these massive conglomerates can perpetually introduce loss leaders or subsidize pricing in new sectors using profits from their existing businesses? This strategy effectively shields them and reduces competition.
My initial thought is that it should be illegal for companies to invest in sectors unrelated to where they generated their profits. However, I recognize this could lead to numerous unintended consequences.
So, what could be an alternative solution?
If the cost of initial operation were prohibited to be eaten by investment money, why the cost of development would not be, by the same logic?
I do think that there are cases of competition stifling through dumping, and that's illegal for a reason. Unfortunately, things are not as clearly delineated as with e.g. burning down your competitor's factory.
1890 - Start of conventional anti-trust enforcement
1930 - Ramp up of law's usage (under FDR)
1966 - First dissent against anti-trust (Brown Shoe Co. v. United States)
1974 - First decision against anti-trust (United States v. General Dynamics Corp.)
1982 - United States v. AT&T allows break up of Ma Bell. Weakened enforcement allows re-merger.
1999 - Microsoft successfully fights off anti-trust enforcement prevent company from ever being split.
If you want anti-trust enforcement, do not elect Reagan and his descendants.
[1]: https://en.wikipedia.org/wiki/United_States_antitrust_law
But usually it’s blocking mergers and acquisitions. Here’s an example: https://www.nytimes.com/2022/11/21/books/penguin-random-hous...
Waiting to break up a company for anti-trust is like waiting for your house to completely flood instead of fixing the pipe before it gets to that point.
Main consequence would be forcing companies to go bankrupt, instead of pivoting to new areas, when their current market becomes obsolete/commoditized.
In this case, AWS has had plenty of competition via other cloud services like Azure and Google Cloud as well as other hosting options. The fact that they ate this cost was immaterial and I don’t see any issue with it.
Even with all the competition, the alternatives still kind of pale in comparison so it’s definitely not a competition problem.
I had heard more than anything it was due to behind the scene implementations anyways, they likely finally resolved those.
IPv4 addressees were once as insignificant as any of these costs, now they aren't, so they are charging for it.
There's just a secondary market for v4 these days, but that's also a one-time cost, as far as I know.
In other words, either AWS is charging a recurring fee for an asset they purchase at a one-time flat fee (which is great if you use a service for less than the year or so it takes to amortize, and not so much afterwards), or I missed a development in the IPv4 exhaustion saga.
I thought it was closer to $40 per IP last time I looked. AWS charging $3.60 per month looks pretty lucrative either way since the payback is only 1-1.5 years.
actually, changing of cloud services is in the sweet spot of being both manageable, and pretty complex so you won't do it every other day.
So if companies are fed up for long enough (or if engineers find it so complicated or costly that they learn to do cloud with something else), they will change. And when they will change, they will never come back. Amazon would be just like AOL or Yahoo (or Jenkins or SVN) or any forgotten giant.
Additionally, many companies don't rely on any cloud service so far. One day, when they will eventually implement it, they won't take what has annoyed others.
AWS is already more expensive than the services of smaller companies (OVH and the like). So Beware.
This change on its own won't make much difference, but they shouldn't be too pushy.
Exactly. Once you're tied to Amazon's cloud, and especially their managed services, moving away is enormously costly and complex. Early in the cloud game people used to pretend to build abstractions to try to avoid being locked down to a single vendor, but these days that's all but done.
The result is AWS is beyond sticky.
> So if companies are fed up for long enough (or if engineers find it so complicated or costly that they learn to do cloud with something else), they will change.
Which is why Amazon will keep their fees for IPv4 high enough to be profitable but low enough that investing in changing cloud providers isn't worth the cost to their customers.
> Additionally, many companies don't rely on any cloud service so far. One day, when they will eventually implement it, they won't take what has annoyed others.
No one ever got fired for picking AWS.
If they had a compelling case to do the devops work and then everythings fine, I wouldn't mind this at all. The reality is a ton of stuff is ipv4 only (cloudfront origins, albs require ipv4, etc etc).
They realistically need free NAT or free 6to4 as a transition plan.
The other option are application-level proxies/load balancers etc., but that's not easy if you want to support all possible protocols.
This still requires mapping tables similar to explicit port forwarding, and also does not help with e.g. a scenario where all hosts need a specific port (e.g. 443) to be v4 reachable, right?
Network load balancers (NLB) are for other protocols.
Has anyone successfully used AWS's IPv6 offerings to stand up a VPC/ECS/ALB/RDS using secure best practices without friction? What tutorials did you follow? I'm all ears.
For RDS, you have to set up your instance as dual stack explicitly even if you’re deploying it into an IPv6 subnet.
i was planning to deploy an internal developer platform (think local PAAS) using lambdas behind an api gateway. no ipv6 there ?
Many fixed-line ISPs also only provide v4 over DS-lite or similar, these days.
(1) charge for IPv4
(2) move IPv4 behind CGNAT
For example, when I do an ifconfig, I get 3 ip6 addresses but 1 ip4 address.
'?' indicates a unique value, 'x' means values match between the IP addresses. That alone indicates the complexity of ip6 on setting up the server.
inet6 ????::????:????:????:???? prefixlen 64 scopeid 0x20<link>
inet6 xxxx:xxx:xxxx:xxxx::???? prefixlen 128 scopeid 0x0<global>
inet6 xxxx:xxx:xxxx:xxxx:????:????:????:???? prefixlen 64 scopeid 0x0<global>
Not that it matters much, because they all just appeared on the right interfaces and started working.
You may need to know some basic things about IPv6 for your firewall ("fe* means local link") but the same is true for IPv4 ("10.* means local network"). I think they're equally difficult to manage, but I can understand how daunting it may look to someone whose been taught networking by outdated textbooks lacking IPv6 like so many other people.
Guess they will improve soon as amazon start charging
https://gist.github.com/atoonk/b749305012ae5b86bacba9b01160d...
AWS adds an extra 5.5M IPv4 addresses(https://github.com/seligman/aws-ip-ranges) - https://news.ycombinator.com/item?id=28177807
I'm also curious if the price will come down over time as addresses are yielded back. I guess it depends on if their goal is to recoup all the money they spent on addresses, or just to avoid running out.
Developing countries often do not have the money to buy/lease IPv4 public addresses so therefore they force their subscribers to IPv6. With most of the internet still on ipv4, this makes them inaccessible (ie, github) unless you are technically inclined.
* Discussion 2 days ago: https://news.ycombinator.com/item?id=36910855
What the...
Good thing YouTubers aren't selling IP Addresses as investments. Yet.
That was the point when they should have gone pure v6 for everyone except enterprise customers. And if you wanted to expose services over v4, they should have made you pay for a load balancer. That would have made it pretty easy to pass through the real cost, and would have gotten devs used to using v6 for management and internal connectivity.
I saw a comment saying ISPs should drop v4. I consult for one and they absolutely cannot. Too many customers still rely on stuff that doesn’t support v6. It’s become a major headache. Not only are they expensive, but you also have to be careful not to buy blocks that are on legacy blacklists.
For t4g.nano it's a 119% increase (from $3.04/month to $6.62/month)
If this is what IPv4s cost, are small VPSes now uneconomical? For example, the current listed pricing for the smallest Lightsail instance, which includes an IPv4, is $42/year. [1]
For ultra cheap VPSes IPv6 only options are becoming available for just this reason.
But it also requires tools to make sure they properly prefer IPv6 over IPv4, otherwise you're paying extra because your customers run bad software.
For example WireGuard on iOS. To this day it prefers an A record over AAAA when resolving a domain. That costs money. And breaks on 464xlat.
IPv6 is a travesty because its creators failed to consider the users. Nobody wants to deal with it. And that's why its adoption will eternally be "just around the corner!"
Sure, v6 made a few other changes, but why do you think those are the problem?
1. SLAAC had been half-baked for the first 10 years. You were supposed to run SLAAC _along_ with stateless DHCPv6 just to get the DNS settings.
2. The initial rollout was embarrassing. The initial idea was to avoid the PI (Provider Independent) prefixes.
3. There is a plethora of non-intuitive features, like on-link addresses instead of the simple "subnet mask" in IPv4.
4. DHCPv6 is strictly worse than V4 for management. Whoever thought that DUIDs are a good idea...
5. IPv6 managed to break fragmentation and PMTU _even_ _more_ than IPv4.
6. HappyEyeballs that mitigate the V4/V6 instabilities became a standard only around 2012.
Etc.
Honestly, there's pretty much nothing that went right in the IPv6 development.
The question is whether IPv6 is really the way to go. Not speaking technically of course. End consumer does not really care about it and if you want to create (and sell) a product, you just cannot say "it will not work, get a better internet". So right now it means I have to work with IPv4 anyway and then it is a question of why even bother with dual-stack at all?
That means there is essentially no push from the masses and therefore no real reason for ISPs to even bother with pricing it and including into their processes.
IPv6 just failed to crack the chicken-and-egg problem. It did not offer anything substantial (or good enough) to the end user. Most of them will never care about not being able to get SIP calls working peer-to-peer as they will use WhatsApp or something like that (that works right now already).
Pretty exorbitant pricing especially when coming for free, but that's really par for the course for aws. I guess most users really don't need all that many, so maybe it's just a way to force some users have been going wild to setup a proper vpc.
good, clearly no one is going to start implementing IPv6 until using IPv4 begins to hurt
After you hit IPv4 exhaustion, the price crunch only gets worse. I guess it finally hit a tipping point where it’s going to be taken seriously.
I mean, I get AAAA records, but does anyone have a good primer on ipv6? Another on ipv6 with docker would be nice too.
There is no reason to not use v6, and excuses don't count. RFC2460 has been out since 1999 and most everything even defaults to v6 for localhost. Set up AAAA records and never think about it again...
https://www.ripe.net/participate/member-support/become-a-mem...
- AFRINIC - Africa
- ARIN - North America + misc
- APNIC - East+South Asia + Pacific
- LACNIC - South America + surrounding
Although reasonably consistently >400 days.
The above is slightly simplified but it should give you the gist.
So you could use your own IPs, but you had to use something like DirectConnect or VPNs to forward traffic to your network.
The most common way to get addresses is now on the resale market; they are currently trading at $40 or $50 per address (depending on the size of the allocation) tho prices have been as high as $60. For example, see https://ipv4.global/reports/
The minimum allocation is a /24 so you can expect to pay more than $10,000
When I helped setup our new office earlier this year, I requested IPv6 support and was told that Cox just doesn't support it at all for business lines right now.
How can anyone drop support for v4 when the ISPs still don't support v6? What good is a service that can't be accessed due to ISPs being awful?
A big drive for IPv6 adoption seems to be that some ISPs are genuinely running out of addresses. They are forced to re-engineer their network stack in order to switch to CGNAT anyways, so deploying IPv6 along with it isn't too much extra work. As long as the ISP has plenty of IPv4 space remaining, their engineers are going to have a hard time selling spending time on IPv6 to management.
You still need at least one IP address, but for services using hundreds of individual hosts the cost shouldn't rise too much this way.
For HTTPS and such protocols, where the port number is hardcoded, you'll be out of luck with plain SRV.
SVCB and HTTPS records should allow for other ports to be used with modern HTTPS, though I haven't personally played around with those.
You can try to fake it with NAT, but that introduces a whole bunch of problems of its own which then need to be worked around. It doesn't make sense to use it unless you can't get public address space in the first place.
Company requires at least 2 IP, one for outgoing and one incoming.
Where did you learn that?