> You can configure your Application Load Balancer so that clients can communicate with the load balancer using IPv4 addresses only, or using both IPv4 and IPv6 addresses (dualstack).
I'd love to go IPv6 only. Amazon won't let me, and charges for the privilege.
I'm on metronet, which is a new-ish fiber optic ISP. They're exclusively IPv4 and they default everyone to CGNAT unless you call and complain - in that case you get a static IPv4 for free for a year and then $10/month after that (although another phone call usually gets another free year.)
I specifically asked for IPv6 and was told they don't offer that.
This isn't universally true. They've primarily expanded by acquiring other companies, and a few regions do have IPv6. Lansing, Michigan in particular which was previously Lightspeed.
That being said, the CGNAT thing is just silly in 2023 - give us IPv6.
I'd assume that when you have IPv6, the majority of your traffic (in bytes) will be IPv6 simply because all the CDNs and big video services do support IPv6.
Once my router at home crashed in a way that IPv4 stopped working but IPv6 kept on working and it was actually kind hard to figure out what went wrong because so much of the internet still worked fine.
Thats also six year old data; a lot has happened since, especially outside the US. For example european connectivity rate has doubled, and the top 1000 websites is close to 50% now which is also almost double that of 2018.
I've gotten a /64 delegation from my cable ISP for almost a decade. There were some hiccups at first, but it's been working for a while now, to the point where I recognize issues with IPv4 as when my wife tells me "only Google and Netflix work"
This is now so common, I expect the common software to adjust soon. You can still subnet below /64 with some patching or a more complex config. Software will match reality it exists in - we already did that for classless ipv4 https://en.m.wikipedia.org/wiki/Classless_Inter-Domain_Routi...
It's the other way around. Handing out /64 is the problem, but you and I can't solve it - that's the ISPs stupid decision. People will continue solving this by making smaller subnets and I believe this will become an official solution in the future, because smaller subnets solve a real (even if artificially created) problem.
Obviously we couldn't subnet it back when we derived the last 64 bits from the MAC address. But since then everyone decided that's a bad idea, so why not use the address space?
I'm on Verizon FIOS - they rolled out IPv6 a couple years back and it was so poorly rolled out and communicated (i.e., lots of things/services were complete broken) that I fully disabled IPv6 on my router and don't intend to reenable it until I have to...
To be fair to metronet, aside from that and some hiccups during the initial install, I've been pretty happy with the service. The speed is fantastic, and it's been fairly reliable.
The price keeps slowly going up, but that seems to be par for the course with ISPs.
Admittedly, the time you know if a ISP is good or not isn't reached _until_ there's a problem. Because it's all about how they work with you to get it resolved.
Weird, most cable ISPs that I know of have been IPv6. Last I checked in the US (pre pandemic) there is more IPv6 nights and weekends than working hours by a lot because the Cable ISPs and cell phone companies rolled out IPv6 long ago, while companies mostly are behind. OF course you didn't say what country you are in - different countries have very different numbers.
Telus in Canada is a bit annoying. Residential connections get dynamic IPv4 and not-quite-static IPv6 /56 - I had the same prefix for about 6 months until some recent maintenance changed it.
If you pay for a business connection you can get 1 or more static IPv4 addresses, but then you get no IPv6 connectivity.
I've configured at least 3 VPCs in the last decade which were exactly that.
Literally one instance with VPC service endpoints deployed and an egress NAT gateway. Surprisingly common when you have a random shitbox which sucks data up from somewhere and doesn't fit within the constraints of a Lambda or something. They mostly exist to tick the compliance and architectural documents which are all under AWS "best practices".
Note that I do not consider AWS "best practices" to be best practices necessarily. In fact a lot of time they are completely over-engineered against hypothetical scenarios which if they did happen, fixing some EC2 integration shitbox would not even remotely be the first problem you had to worry about.
But someone demands it and someone pays for it and Bezos ain't complaining so meh!
They make more money from selling servers than they do from selling v4 addresses. There's a limit to how many v4 addresses they can get, so they'll make more money if they can sell servers without v4 addresses -- otherwise the limit on v4 addresses will turn into a limit on the number of servers they can sell.
I agree and would first urge people to test IPv6 client access using some lazy-loaded image that is IPv6 only on their website. It should look like a normal resource so that false-negatives are not introduced by NoScript or uBlock.
People can of course manually test here [1] from their homes, schools, work place. I would wager most cellular data networks would be fine. The impact would probably depend on how a website is utilized. Stats on mobile vs. non-mobile would probably be telling. The people on their cell should test LTE vs Wifi and clear cache between tests.
You would lose that wager. I’m in the southeast United States. My ISP, Spectrum, works fine with IPv6. My cellular provider, Total by Verizon, is IPv4 only.
For what it's worth I did qualify my statement using most. A few of the older cellular networks are slower to adopt and sadly I can understand why having worked for one of them. If you find it interesting here [1] are some rudimentary stats from the US. It's not an all inclusive picture of things.
That seems unlikely given that the vast majority of users have no clue what the underlying service provider is for the web services they're using, and those who do know are savvy enough to understand the difference between an AWS issue and a configuration issue.
Imagine if Cloudflare went to IPV6 only. Yes, Cloudflare's customers should know what that means, but the end users that are using the service may not be and if the error in anyway says Cloudflare, then it gives Cloudflare a bad reputation.
While AWS is a bit (just a bit) more removed from the end user than Cloudflare, there is still the potential for it not being good PR.
Cloudflare actually presents end users with an authentication page on a regular basis. AWS is strictly behind the scenes. The only time I've ever become aware that a site is using AWS is when reading their engineering blog or spelunking in the dev tools.
These infinite verification prompts are the reason I no longer consider Cloudflare as an option for business use and would not recommend it to anyone. I know that they are configurable by the admins but they give bad PR to Cloudflare. I am not sure what this company was thinking associating itself with such a terrible user experience.
Cloudflare couldn't dare of IPv6 only until a lot more of the internet supports IPv6. They could however offer a discount of some sort to customers that are IPv6 only. That includes proxy your IPv6 only site to IPv4 (actually they would probably not give a discount directly, but let you apply discounts you get from your ISP)
This could also slow down IPv6 adoption. This is going to free up a ton of IPv4 addresses, reducing the need for AWS to purchase new ranges. I know of a few companies that started auditing their public IPv4 usage on AWS after the original announcement.
Some AWS customers have released 80+% of their public IPv4 addresses. The alternative isn't IPv6, it's private addresses. Many AWS customers have been slapping public IPs on EC2 instance just because they could or because they didn't know any better.
"This is going to free up a ton of IPv4 addresses, reducing the need for AWS to purchase new ranges."
Yup, this has been obvious for a while if you read the better economic analyses. Charging for IPv4 doesn't on its own remove it. It creates some sort of economic balance between the value and scarcity of the IPv4 address space.
When you're trying to fit the entire world of 7 billion people into 4 billion addresses, the space looks pretty scarce. But assuming a roughly power law distribution of services and their importance of being on IPv4, as you cut off the people with lower-end needs, like, "my cell phone needs to communicate on the internet so let's give it an IPv4 address", you extremely rapidly cut through orders of magnitude of the old uses.
That long tail of "Facebook is not willing to cut off even .01% of its user base so it has IPv4 addresses to serve on" may take a long time to get through, but we're well through getting huge swathes of the other users off of it.
What kills IPv4 is in the far future when the expense of maintaining it specially exceeds the benefits. Since maintaining it is rather cheap, this is going to take a while. But as IPv4 diminishes in importance, ironically, so does the value of entirely eliminating it. When it is 1% of the traffic, who will really be desperate to drop that to zero?
I don't find it at all difficult to imagine that someone like Google or Apple would sunset ipv4 when it reaches single digit percentage. They know no ISP would risk losing connectivity to them.
For example Apple has already been requiring that appstore apps work in ipv6 only networks since 2016. They can just keep tightening such rules until ipv4 dies.
It's naive to think that maintaining ipv4 (/dualstack) networks is (and will remain) cheap at large global scale like Google.
Thing is if it is only 0.01% of users Facebook won't give up on they can just do a few ipv4 server/address. Now Facebook has severs around the world, but if it is only a few users they just need two servers - and that is only for redundancy. Now they have thousands (maybe even millions? I don't know) of servers and they may as well give all the external facing ones IPv4 addresses as most need that anyway and so the hassle of maintaining IPv6 only servers isn't worth it.
And of course if you are in the 0.01% you will discover that while Facebook and google won't give up on you many other providers will as it just isn't worth the cost. By that time the cost won't be IPv4 addresses - they will be again free - it will be the cost of maintaining IPv4 on all the routers and servers. (the routers mean IPv4 will cost more, but it won't be for the address it will be for routing access)
Correct. I am convinced that the best way to speed up IPv6 adoption is to provide IPv6-only networking but with NAT64.
Historical evidence is on this: cell phone ISPs have started doing this a long time ago and look at how high the IPv6 adoption is on mobile.
Also, an IPv6-only network removes the happy eyeballs algorithm so any routing issues on the IPv6 internet won't be papered over by the speed of the IPv4 internet, so there's more incentive to fix that.
Of course everything I said above is conditioned on speeding up IPv6 adoption as a goal. Unfortunately for many, IPv6 adoption is not a goal at all, so nothing I said above applies to them.
Don't forget about MAP-T which does IPv4 NAT over IPv6. The client is IPv4, the ISP is IPv6, and server is IPv4. This is still CGNAT but IPv6 is provided. But means ISP uses IPv6 internally.
The problem for NAT64 in general use is that there is lots of IPv4-only software. NAT64 is great for business networks where control the software, but home users are going to try to use their Xbox 360 or Windows game from the 90s.
>The alternative isn't IPv6, it's private addresses.
I really wish more AWS services or workflows worked with private addresses. Sometimes a service can be completely internal but needs a public address to either talk to Dynamo or install packages; but those endpoints aren't available via private IP, even though they physically live in the same region
I really don't care about IPv6 or IPv4. In my neck of the woods, 10.0.0.0/8 is more than I would ever need. Most architectures I've seen only realistically need only a handful of public IPs, that then are assigned to a load balancer that does service discovery on internal services. I don't think about IP addresses at all.
Today you have to futz around with NAT, but you wouldn't have to if you simply never made any connections to the public internet. And for many services that's completely fine.
Customers having to switch to private addressing still seems like more pressure than customers having infinite free public addresses was providing, not less.
I.e. address exhaustion pressure isn't only about the complete inability to buy an IP it's about how much work you have to do to use IPv4 addresses.
It depends on how you measure IPv6 adoption. Is it about your ability as consumer to use only IPv6, or your ability to offer a website reachable only via IPv6.
AWS charging for IPv4 will help with the former, because companies now have more of a reason to care about IPv6. But it might delay the latter, because fewer IPs wasted on internal servers means less price pressure on useful IPv4 use by ISPs, giving those that still hold out less financial incentive to change anything.
IMHO, best way to measure IPv6 adoption would be - what percentage of your website's visitors are able to reach your IPv6-only site.
That percentage should be well above 99% for a popular website operator to even consider going IPv6-only; needless to say, in most markets, this figure is way lower, with no clear path to improving.
It doesn’t help that, if you enable IPv6 in Debian, the network becomes extremely slow for many things. The reason? If first tries to reach all domains with IPv6, times out, then use IPv4. Of course that’s because I didn’t successfully configure IPv6 with the network, but on the other hand, IPv4 only was successful at first try.
That's not how v6 works in Debian, or really anywhere. For one thing, you can't reach a domain with v6 if there's no AAAA record, so it certainly won't be trying to reach "all domains" with v6.
If your network has broken v6 then yeah, that's gonna cause problems. That's not v6's fault, that's down to having a broken network.
Linux doesn't have a big "enable IPv6" switch, so it's not clear what you mean.
The only way I can think of getting the behaviour you describe is if you configure the network to hand out v6 addresses and routes to hosts, and then just black hole the packets. What you have then is a broken network.
But this is also AWS exerting price pressure on its customers. This move is an increase in price pressure, not a decrease.
If everything host on AWS becomes dual stack and gets first class IPv6 support after this move, that's a win for IPv6.
The price for v4 address is going to bob up and down as more networks and content providers adopt v6 and are able to reduce their public v4 usage to just their edges.
There will definitely be a long tail of v4, especially in the corporate world, but I think we'll get to 90-95% v6 capable within the next 5-10 year
AWS owns about 7% of the entire public IPv4 allocation space. There's no way this is going to slow down IPv6 adoption. Nobody likes NAT, especially when it comes to servers.
IPv6 has been such a wild ride. About 7 years ago there was a big IPv4 depletion scare when ARIN made it harder to obtain IPv4. I did a bunch of dual stack deployments for customers around this time. In subsequent years quite a few of them ended up paying us to come back in and un-deploy IPv6 as their network engineers or often 'the IT guy' neglected to maintain firewall rules and access-lists leading to major security issues. I can't really think of any other vital technology like this that has rotted on the vine and had so many false starts.
Anecdote, my ISP gives us IPv6 but not my employer. We use the IT equipment till the last breadth. I have seen, permanent table-fan running towards Floor's network hub. I guess that one is NOT IPv6 ready. :D
I doubt it. Realistically the AWS charge mostly causes companies to stop giving IPv4 addresses to servers that never directly talk to customers. As a knock-on effect this will cause tooling to become more IPv6 aware, and put pressure on SaaS in infrastructure monitoring and dev tooling to be reachable via IPv6 (for example this might cause github to finally fix their IPv6 game because of higher customer demand).
Maybe companies use the same opportunity to make sure their services also work via IPv6. But they won't stop offering their services on IPv4, and AWS changes don't put meaningful pressure on ISPs to roll out IPv6. If anything it will reduce the pressure on the price of IPv4 addresses, making it more viable for ISPs to hold out.
I doubt it, especially that there is an option of using private/CGNAT ranges instead of adopting a whole new protocol. Everyone who cares about IPv6 have already done their part, and people who don't care about it will likely use the lower-friction option, and between private IPv4 networks and IPv6 I bet that a lot of people will see private IPv4 as a lower-friction option.
However the lowest friction option is to use private IPv4 between your servers, but give every server a public IPv6 it can use for outgoing calls: updating the OS, fetching github repositories, collecting logs on your favorite SaaS, etc.
Of course you can do all this via IPv4 by setting up proxies or gateways, but that's more work and more moving pieces than checking the checkbox that you want a public IPv6 and having it just work ... provided everyone you want to talk to talks IPv6.
The tracker is for client connections to Google. To impact that graph AWS customers would have to, en masse, decide the $1/m charge is worth losing half their current users over and then the users and ISPs would have to scramble for IPv6.
The more likely story is places using AWS pay 1$/m for a public address and use private/IPv6 internally. I.e. an incremental step, not a revolution in the chart.
IPv6 adoption is not uniformly distributed. Some usersbases might have higher penetration. But yeah, I doubt there are many where it's high enough to be worth it.
I am not sure if these incentives help IPv6 adoption. Nobody can turn off IPv4 today; there is always a long tail of people with broken IPv6 stacks. Since IPv4 continues to work, I'm not even sure it's worth setting up IPv6 so that someday you can switch IPv4 off; do work that gets you customers today, switch off of IPv4 when it becomes a crisis. I think the best incentive would be a high price on IPv4-only, but if you do the work to support dual-stack, then that fee is waived. That way, there is savings for doing the technical work today, and you pave the way for a brighter future.
Personally, I think I'd pay the fee to not be dual stack these days. Everything in your infrastructure has to now check two things. Your website uptime checker has to probe via both IPv4 and IPv6. You have to maintain two sets of firewall rules. You have to remember to "ping -6 example.com" in addition to "ping example.com" when checking connectivity. I don't think it's worth the effort, and I say that as someone who first made their website available over IPv6 in like 2008. (I moved providers in 2020 and the new one didn't have IPv6. It made me sad. But now it's just one less thing to worry about.)
There are internal servers talking to other servers which don't need ipv4. There's zerotier that gives you a private IPv6 network regardless of your network capabilities. The only part that actually still requires ipv4 is the general public user.
Not always. Sometimes you talk between different providers, or to private endpoints on other services. Or its simpler use IPv6 between two networks rather than keep a global list of ipv4 ranges to make sure they don't collide.
Using IPv6 also comes along with many other complexities. If you already have a working IPv4 solution, working around costly public IPv4 addresses is likely much easier than trying to switch to IPv6 and having to adapt every part of your infrastructure to the many surprising ways it's different.
The problem of having to re-IP your entire network doesn't go away in IPv6, it just happens in different circumstances. If you're using public IPs as recommended by the design, then if you ever switch ISP you need to re-IP your entire subnet, just as you would with overlapping private subnets in IPv4-world. Of course, the same would happen in IPv4, but it is almost unheard of to use public IPs for all machines in a private network there.
There is very little extra simplicity in IPv6. The only thing it really does that most people fight with in any common place is to get rid of NAT, which is a fairly well understood technology by now. But getting rid of DHCP didn't work, peer-to-peer networks still get bogged down in firewalls even if they don't fight NAT, MTU problems are still around when running VPNs, etc. Maybe getting rid of ARP has helped in some scenarios for more complex networks?
Instead, you have to deal with both DHCPv6 and SLAAC, with multiple IPs on every interface, with much harder to remember IPs, with always changing IPs, with the myriad IPv6/IPv4 conversion schemes, with larger DNS responses (requiring DNS over TCP more often), and I'm sure I'm forgetting a few things.
But I refuse to let them switch me, because their IPv6 offer does not include a v4 address, only CGNAT. Of course if everyone was on v6 that wouldn't matter, but until then I need the ability to forward ports to my server!
This isn't even technically in breach of the ToS; I have a business line, mostly for the customer support.
And thus I add to the problem, because now anyone who wants to connect to said server also needs a v4 option...
Not the person you're asking, but hosting a game server is one example where you probably wouldn't want to go through Tailscale, due to the added latency. A Plex server might be another one if Tailscale has bandwidth limits. (I could be wrong here - I'm on a static IP, so I've never used Tailscale)
Also, in general, it just adds a layer of complexity that I wouldn't want to deal with if I didn't have to.
> if Tailscale has bandwidth limits. (I could be wrong here - I'm on a static IP, so I've never used Tailscale)
Tailscale connections are primarily peer to peer. The service Tailscale is providing is orchestrating the connectivity and hiding the complexity, but the data flows directly.
Except that P2P mode tends to simply not work in cases where both of the clients are in CGNAT networks (unless both of them happens to have IPv6 addresses). Even Tailscale acknowledges this sad fact (https://tailscale.com/blog/how-nat-traversal-works#have-you-...) because in practice CGNAT operators deploy an endpoint-dependent NAT (aka symmetric NAT) without the possibility of port mapping.
You can use Zerotier which doesn't have the problem. Some public nodes will assist with the nat traffic. It's not an ideal situation to be in and it's a bit slower, but at least it will work.
The internet is supposed to be peer-to-peer, and I shouldn't need third-parties in between my computers, or between my friends and me. Switching to IPv6 breaks the peer-to-peer nature of the internet.
Crusty enterprise networks are far bigger problem than retail ISPs. This is clearly visible by the fact that you have clear weekend peaks in e.g. Googles IPv6 adoption stats.
This is measurably false. Google’s IPv6 adoption graph has noticeable spikes on the weekends when people use their home internet, and decreases during the work week when people go to work: https://www.google.com/intl/en/ipv6/statistics.html
Adoption is limited by enterprises who are change-averse and already entrenched in ipv4. Residential ISP’s have made much more progress.
My current (Brightspeed) and previous (Spectrum) ISPs have nominally "supported" IPv6. Except ... not nationwide, there are regional differences in how it's done and how well it works. And nobody can tell me if my specific location is supported or how to configure my equipment to use it.
On one hand, that gives me hope that we're getting closer to near-universal ISP support. On the other hand, it's been like this for so long I question if it'll ever improve.
Some sort of NAT64 is probably a better idea, because that applies below the TLS layer.
When people complain about IPv6 and IPv4 being incompatible, the fact that you can establish a cross-protocol TCP+TLS session with just a NAT is a remarkable counterexample. It could've been a lot worse.
Sure, there never was a shortage of different ipv4/ipv6 transition/interop mechanisms. Problem has been that many of them haven't been all that great, and understanding the use-cases, compromises, and tradeoffs between the options can be very difficult, especially when vendors and operators like to tout their own tech.
To this day I'm not sure what are the best options available now for different scenarios. 4rd/MAP-T/MAP-E/464XLAT/Dslite, nat64/siit/a+p, these things are enough to get your head spinning
The transition mechanisms that need to worry about now are NAT64, MAP-T, and XLAT. Only the first do you have to worry about setting up unless you are ISP. The rest are obsolete.
NAT64 is used for IPv6-only networks to talk to IPv4. It puts the IPv4 address in the IPv6 address. The downside is that doesn't work with old IPv4-only software.
XLAT is used on mobile phones, and does the translation on the device. It only works for devices where translator can be installed.
MAP-T can be used for IPv6 ISP to provide IPv4 access. It is basically CGNAT but using IPv6 as stateless transport.
I wonder how much of the IPv4 space is used for infra that could just be privately addressed with some reworking of network topology.
I find these articles on HN focus much more heavily on consumer use of IPv4 for simple things like web browsing. But not a lot of consideration is paid to massive corporate systems and API surfaces. Would be interesting to know.
I think this is what's really going to happen in AWS. People will audit their IP usage, discover that 90% doesn't need public addresses, and clean up their network. VPC more or less forces a combination of private addresses and NAT anyway and a clean VPC only needs a handful of public addresses. They don't need to deploy IPv6 and they're not going to.
Hoping this lights a fire under other AWS wrappers like Heroku and Vercel to support IPv6. Currently dealing with the fallout of the Supabase IPv6 change and frustrated that two of my core vendors still don't support it.
Meanwhile, Azure is gearing up to do the same thing.
Except that their alternative to per-VM addresses is a NAT gateway that isn’t zone-redundant. Literally everything else is — including IP addresses and virtual networks — but not outbound Internet access. That’s going to just break and leave your entire network dead in the water if one of three zones has a hiccup.
Could anybody recommend a book for learning IPv6? I know there are plenty out there, but what are the best, HN's recommendations? I get the general concepts and I use it on personal systems but I've spent too long just skirting by. It's time for a deep dive. I think the best type of book to learn from would have a mix of textbook knowledge and practical examples/demos.
The CCENT and CCNA certification books have chapters dedicated to IPv6 and I think they do a good job talking about it.
edit: Some little tips about it.
* The smallest subnet should be /64. Anyone making a smaller subnet than that is doing it wrong (looking at you, every ISP that assigns me an address)
* Subnets should be created in four-bit chunks. You should always make /64, /60, /56, etc. for readability. That's because 4 bits make up one hex character in the address.
* If you want to have private (non-internet-routable) IPv6 space, create a ULA. https://www.unique-local-ipv6.com/ Imagine never having to worry about address overlap with VPNs or routing between two internal networks.
The general approach is to gradually expand the size of a block to cover more subnets if needed, e.g. three /64s banned from the same /60 -> ban the /60, and three /60s banned from a /56 -> ban the /56, or whatever thresholds work. You already need to do this in v4 to cover people with dynamic IPs anyway, so it's not a new concept.
I don't know how things are being done by global consumer ISPs... Whether they are handing out /56 or /60 commonly. Even then, you're talking about dealing with a few hundred /64 sized nets to potentially block, rather than the quadrillions initially feared.
Really? Can’t imagine how that is possible it doesn’t fit the standard and I’d think it’d get berated. Are you sure they don’t give you a /64 or that you can request one
I've defaulted to setting up v6, but deactivating it once it causes trouble. I don't want to actively sink time into it, but in 95% it just works out of the box (or with obvious config changes, like adding an IPv6 listening port and an AAAA DNS entry), and in those cases I'm happy to let it stay until it causes trouble.
In another 10 years it's probably worth putting more effort into the other cases as well, but so far I'm happy with getting 80% of the way there for 0.1% of the effort.
Yeah, IPv6 is shut off on my Google Fiber router. Stuff on the Internet breaks when it’s on (last tested three or so months back when they sent me a new router).
When we first got Fiber, years ago, Amazon’s store was one of the things that broke until I turned off IPv6. Wouldn’t load at all, on any device on our network.
Works fine for VPNs and such, but I don’t talk to the Internet with it, because my experience has been it’s terribly unreliable.
I'm curious what breaks with IPv6 on. I've been running IPv6 dual stack for over a decade at home and pretty much never have any issues. I think I've run into a prefix change get bugged on my router's announcements that required a reboot, but that's like 2 times in the last 10+ years and I'm not 100% sure that was truly the issue. My phone is pretty much always has an IPv6 address and pretty much never has IP-related connectivity problems. I'm not using Google Fiber's router though, so that could be the complication.
The typical behavior is that DNS returns an IPv6 address, then whatever-it-is sits there until a timeout, because it’s simply not being routed. I’ve not investigated further because turning off IPv6 fixes the problem and breaks nothing (that I care about). Anything that only returns an IPv4 address from DNS works either way.
My cellular connection supports IPv6, but testing sites report it’s misconfigured in a bunch of ways. I don’t see problems in practice, though. But on my home network, it’s turned off.
This is what I was thinking about with the prefix issue. I've encountered this issue like twice and rebooting my router ended up with a different prefix, so it seems more like my router just didn't get the new prefix and thus kept handing out the old prefix to everyone with SLAAC and thus wouldn't get routed right.
I'm speaking from ignorance of course. But ipv6 has been the acknowledged next best thing for the Internet's health by everyone. Everyone gives lip service. But when actual hard steps to bring forth this common good are taken everyone breaks out the "greedy corpos" trope, the "I'm a sovereign citizen you can't take my ips from me" trope.
I'd be happy if the HackerNews typers would just end the affectations; in either direction. But this teeth-gnashing is such an incredibly garish instance of NIMBY-ism, it's unbecoming.
Sorry for being off-topic, but the utterly lacking IPv6 availability (still!) annoys me so much.
I know IPv6. I can route it. I can setup networks with it. And my ISP supports it, but just kinda. For some arcane reason, it only supports it for some types of transport.
Got Cable/Coax internet? Great! You get IPv6 and a subnet too!
Got Fiber to the Home? You get IPv4. And no subnet.
I'm in the latter segment, and I just don't get it.
The ISP in question is Telia, a pretty big ISP in Scandinavia. If someone in the know-how could tell me at least why they're doing things like this, that might offer some mental consolation.
They already are, but it is a risky investment - the higher the price goes the more people switch to IPv6 and thus the lower the value goes. Eventually there will be a tipping point where people realize they don't care about IPv4 and quickly the value will go to zero.
For my ISP, it's not just about the hardware, it's their provisioning software that needed replacing. It has to be simple for their support to understand how IPv6 is given to customers.
IPv6 has been around for 30 years and well supported by switching and routing vendors for 20. What hardware is out there today that does not support v6?
People, IPv6 was introduced 28 years ago! For some reason it is not catching on and probably never will. Let’s try something else.
EDIT: my take on IPv6 is this. In the early 2000’s I wanted to run a web server at home. Figuring out how to make my $10 gateway/router do port forwarding was hard. IPv6 sounded like the right solution. Now… none of those problems really exist
...network effects? There are still people with legacy v4-only clients, which can never reach anything other than v4, or on v4-only ISPs. There are enough of them at the moment that we still need to support them. This isn't hard to figure out.
If you know IPv4 networking, you can learn v6 in a day or two. It's just not that complicated. Some aspects, like no need for NAT, easier subnet calculations, etc. make V6 simpler to deploy. What's wrong with it? What would make it "better"? I've been running V6 at home for over 15 years (first on a tunnel, then native.) In a professional context, I am still running into people afraid to turn it on.
there's nothing wrong with ND and it addresses several security vulnerabilities, namely ARP cache poisoning. But the real reason why ARP was removed is because it's a layering violation.
> NAT support (because it's everywhere these days)
nothing at all is stopping you from doing NAT on IPv6, except for the fact that everyone hates NAT, even people that pretend that they like it.
> Correct DHCP support (SLAAC wasn't a great idea after all)
SLAAC is a great thing. Also, DHCPv6 also exists, which allows you to do exactly what DHCP lets you do. Android doesn't support DHCPv6, but that's not IPv6s fault.
- IPv6->IPv4 interop (one way)
There's no such thing as one-way communication if we're talking TCP. Besides, it's still fundamentally impossible if the other end has no idea what to do with the source address.
There are several IPv6 -> IPv4 interops (bridges) developed already.
All of them appeard due to slow IPv6 adoption. Some of them are: NAT64, XLAT6, DS-Lite.
Never heard about ND tables overflows? They fixed one thing, broken another.
ARP poisoning is mostly fixed problem.
I like NAT myself. Im dualhomed (el-cheapo), using policy routing and NAT.
Everything works like a charm. I cant imagine such setup w/o NAT actually.
SLAAC might be great thing for you, but not for others. This is why IPv6 is such a failure. Instead of creating simple protocol to meet middle ground, they slapped together annoying techs for specific cases like IoT. Great job.
DHCPv6 doesn't support dhcpv6 forwarding though like dhcpv4 does. One can't forward dhcpv6 request over multiple ipv6 hops, only hop-by-hop forwarding supported to my knowledge.
imo the 'static' ip issue with ipv6 has not been solved by providers. cable internet cabals are content to use dhcpv6 to dole prefixes out, but these are the same providers whos DNS servers typically post four-digit latency figures for DNS queries so the idea they they are to be the ones to solve DHCPv4's scalability issues remains laughable. just try getting a statically assigned prefix from their "business" or "corporate" offerings. wont happen.
SLAAC is the best hope so far, but regular hosted customers do not understand that slaac is calculated by mac, so theyll need education to ensure immutable architectures dont crash and burn on lift-and-shift redeployments. either that, or enjoy hardcoding ip's in your prefix to the boxes.
then theres networking. most corporate network engineering that would handle ingress or peer traffic to clouds (especially azure tenants) treat ipv6 as a cursory knowledge...something theyre aware of in theory but have never taken it upon themselves to practice. i predict AWS will send a lot of them scrambling for mouldy ccna texts and taking down the hybrid cloud at least twice a month until the basics sink in.
and finally, firewall and security devices. There are a lot of vendors that have gotten a free pass to grandstand about how stellar their IPv6 support is, only to send customers to phone tree purgatory trying to find support for a device that either cant route between local, unique local, special purpose ranges, ::1, or even the special discard ranges for things like DDoS protection. frankly its not an AWS issue (yet) but the only guise ive seen handle this competently are...cloudflare.
Any kind of application that acts as a server needs a direct IP connection.
Gamers get errors about "strict NAT." Traditionally the solution to this problem caused by NAT was to forward the ports. If their ISPs has chosen CGNAT port forwarding is impossible.
VoIP calls that have one way audio are a symptom of reachability issues caused by a firewall or address translation problems. VoIP services have adapted to IPv4 NAT by relying on proxying instead of STUN but CGNAT really degrades reliability.
Video chat uses the kludges of TURN when peer to peer connectivity does not work. This increases costs for the video chat service who in turn require a paid subscription as they will not relay traffic for free.
BitTorrent and file transfer services need direct IP connectivity. If p2p file transfers worked on any network we would not need to mind Gmail's 25MB attachment limit, or pay for intermediary cloud storage.
IPv6 has marginally lower latency (in most cases) and lets peer-to-peer applications work flawlessly. If your ISP only has v4 CG-NAT then it gets you a lot better connectivity.
Their devices continue to work when a scarce resource is no longer plentiful. The every day user doesn't need to care, but the people working on the stuff the every day user has need to care.
In the US, usually not - but the US is comparatively spoiled for IPv4 blocks. It's pretty common in a lot of places for ISP customers to share public-facing IPs. This causes all sorts of issues with people being unfairly spam blacklisted, etc.
There is benefit to ISPs, and has many other ISPs and cell companies have shown the world is ready and most people won't even notice if you give them IPv6 - their computers will notice and start using it.
The cost of an IPv6 address is effectively $0. The cost of a static IPv4 address is ~$90 last I checked.
And while network providers can provide dynamic IP addresses, it's pretty trivial for them to provide static addresses and just never bother changing them - it's not like there's a shortage of IPv6 addresses.
So from the perspective of a home internet user, acquiring a static IPv4 address is harder and more-expensive-than-$0.
https://docs.aws.amazon.com/elasticloadbalancing/latest/appl...
> You can configure your Application Load Balancer so that clients can communicate with the load balancer using IPv4 addresses only, or using both IPv4 and IPv6 addresses (dualstack).
I'd love to go IPv6 only. Amazon won't let me, and charges for the privilege.
Look at the list of "no"s on https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-su....