The IPv6 Transition(potaroo.net)
potaroo.net
The IPv6 Transition
https://www.potaroo.net/ispcol/2024-10/ipv6-transition.html
431 comments
I recently moved to a 'cheap' ISP because I could get double the speed for half the price. They use CG-NAT and it's been awful.
I don't need to forward any ports but seemingly because I share an IP with a billion people I get Captchas everywhere (Google, Cloudflare etc.). I was even blocked from accessing Reddit without an account at some point.
I don't need to forward any ports but seemingly because I share an IP with a billion people I get Captchas everywhere (Google, Cloudflare etc.). I was even blocked from accessing Reddit without an account at some point.
Starlink uses CGNAT. It's awful, I'm regularly getting CAPTCHAs on random websites.
They now support IPv6 but only with dynamic address allocations so you don't get a lot of advantages from it.
They now support IPv6 but only with dynamic address allocations so you don't get a lot of advantages from it.
I've been using Starlink since early 2021 with IPv6 only internally. Starlink User Terminal hands out a /56 prefix (via DHCPv6) and mine has not changed in all that time so I wouldn't call it dynamic.
The User Terminal issues a router advertisement (RA) and my gateway gives itself an address in that /64 via SLAAC in addition to assigning itself an address from the /56 prefix.
If not using prefix delegation each host's address is dependent on their SLAAC policy - if not preferring stable addresses (e.g: EUI64) then of course the public address will vary (be dynamic) when using temporary "privacy" addresses.
My gateway delegates /60 sub-prefixes of the /56 and bare-metal hosts then either delegates /62 or advertises /64s from the /60 to VMs, containers, network namespaces and so forth.
As someone else described, I have my gateway also delegate ULA prefixes by changing just the first two octets of the public delegated prefix to fddc (fd = ULA, dc = "data center :) but otherwise identical and likewise on the bare-metal hosts, etc.
ULA is used for internal services; ISP delegated prefix for anything that needs public access.
Multicast-DNS takes care of internal hostnames; everything is ${hostname}.local
There's a separate VLAN for legacy IPv4-only devices that does NAT64 using a ULA prefix.
DNS64/NAT64 for the laggards like github.com that can't grok 128 bit addresses :)
The only time I have problems with web services is when their DNS advertises an AAAA resource record but their firewall/load-balancers/servers are not configured to allow/listen on it.
The User Terminal issues a router advertisement (RA) and my gateway gives itself an address in that /64 via SLAAC in addition to assigning itself an address from the /56 prefix.
If not using prefix delegation each host's address is dependent on their SLAAC policy - if not preferring stable addresses (e.g: EUI64) then of course the public address will vary (be dynamic) when using temporary "privacy" addresses.
My gateway delegates /60 sub-prefixes of the /56 and bare-metal hosts then either delegates /62 or advertises /64s from the /60 to VMs, containers, network namespaces and so forth.
As someone else described, I have my gateway also delegate ULA prefixes by changing just the first two octets of the public delegated prefix to fddc (fd = ULA, dc = "data center :) but otherwise identical and likewise on the bare-metal hosts, etc.
ULA is used for internal services; ISP delegated prefix for anything that needs public access.
Multicast-DNS takes care of internal hostnames; everything is ${hostname}.local
There's a separate VLAN for legacy IPv4-only devices that does NAT64 using a ULA prefix.
DNS64/NAT64 for the laggards like github.com that can't grok 128 bit addresses :)
The only time I have problems with web services is when their DNS advertises an AAAA resource record but their firewall/load-balancers/servers are not configured to allow/listen on it.
Thanks for the report with success with IPv6 and Starlink. Do you make inbound connections to devices on your LAN? Do they work?
Starlink recently updated their FAQ with more info on addressing: https://www.starlink.com/support/article/1192f3ef-2a17-31d9-...
As for static addresses, it says "a reservation system retains the ... IPv6 prefix even when the system is off or rebooted. However, relocating the Starlink or software updates may change these addresses."
I suspect in practice the IPv6 address will only change if you get moved to a different POP ground station. Some customers never get moved. I've been moved several times because I'm in NorCal and they keep switching me between Seattle and Los Angeles.
Here's some recent discussion of users reporting what they've observed about changing IPv6 addresses: https://www.reddit.com/r/Starlink/comments/1b6mr4c/how_stati...
Starlink recently updated their FAQ with more info on addressing: https://www.starlink.com/support/article/1192f3ef-2a17-31d9-...
As for static addresses, it says "a reservation system retains the ... IPv6 prefix even when the system is off or rebooted. However, relocating the Starlink or software updates may change these addresses."
I suspect in practice the IPv6 address will only change if you get moved to a different POP ground station. Some customers never get moved. I've been moved several times because I'm in NorCal and they keep switching me between Seattle and Los Angeles.
Here's some recent discussion of users reporting what they've observed about changing IPv6 addresses: https://www.reddit.com/r/Starlink/comments/1b6mr4c/how_stati...
Yes, I use direct IPv6 peer-to-peer connections both outbound and inbound using the delegated prefix.
Even for a changing prefix, if operating a DNS authoritative server for a domain, any changes to the prefix can be quickly and automatically updated in both forward (AAAA) and reverse (PTR) resource records provided the TTL for those records is appropriately short, and thus allow almost seamless inbound via FQDNs. I do this with a bind9 (hidden) master locally that notifies external slave servers operated by a highly available, anycast, DNS service.
Even for a changing prefix, if operating a DNS authoritative server for a domain, any changes to the prefix can be quickly and automatically updated in both forward (AAAA) and reverse (PTR) resource records provided the TTL for those records is appropriately short, and thus allow almost seamless inbound via FQDNs. I do this with a bind9 (hidden) master locally that notifies external slave servers operated by a highly available, anycast, DNS service.
> Starlink User Terminal hands out a /56 prefix (via DHCPv6) and mine has not changed in all that time so I wouldn't call it dynamic.
Unless the service explicitly states that your subnet is your or yours alone you should assume it's dynamic.
If you start relying on the prefix not ever changing you might have a bad surprise.
And from experience, that kind of surprises always come when you least need them.
Unless the service explicitly states that your subnet is your or yours alone you should assume it's dynamic.
If you start relying on the prefix not ever changing you might have a bad surprise.
And from experience, that kind of surprises always come when you least need them.
Why do dynamic address allocations matter? Most IPv4 consumer WAN addresses are also dynamic.
I’m asking, because I’m an advocate of having your gateway advertise a separate, stable ULA /64 in conjunction with the globally-routable dynamic /64.
This gives you a stable set of addressable LAN IPs, and you can usually ignore the dynamic globally routable IPs.
Granted this won’t work for everyone, but if dynamic global addresses are an issue, you should be requesting a plan that supports a static delegation from your ISP anyway.
I’m asking, because I’m an advocate of having your gateway advertise a separate, stable ULA /64 in conjunction with the globally-routable dynamic /64.
This gives you a stable set of addressable LAN IPs, and you can usually ignore the dynamic globally routable IPs.
Granted this won’t work for everyone, but if dynamic global addresses are an issue, you should be requesting a plan that supports a static delegation from your ISP anyway.
It matters, because when the prefix changes, it changes IP addresses of every single device in your network.
As you wrote, internally, you can use ULA. But you cannot open access from outside, because your firewall rules will become invalid with prefix change. With classic IPv4 NAT, your internal addresses don't change, so your port forwarding works, even if the WAN address changes.
Together, with a single /64 -- which means no subnets for you -- you are getting worse deal than with IPv4. You shouldn't have to contact your ISP for a plan (for a premium, obviously), that allows you to segment your network or open access to specific devices. What's the use of direct connections -- the IPv6 promise -- when you cannot use them anyway?
In short, with limitations like these, you are getting a bad deal.
As you wrote, internally, you can use ULA. But you cannot open access from outside, because your firewall rules will become invalid with prefix change. With classic IPv4 NAT, your internal addresses don't change, so your port forwarding works, even if the WAN address changes.
Together, with a single /64 -- which means no subnets for you -- you are getting worse deal than with IPv4. You shouldn't have to contact your ISP for a plan (for a premium, obviously), that allows you to segment your network or open access to specific devices. What's the use of direct connections -- the IPv6 promise -- when you cannot use them anyway?
In short, with limitations like these, you are getting a bad deal.
I don’t know what router you use, but openwrt lets you set firewall rules that only match the last 64 bits. This should solve your problem, provided you configure your router to hand out static IPv6 leases to devices.
There are wildly different solutions for different routers.
I'm using Mikrotik, which doesn't allow prefix-less addresses in firewall, but allows you to put hostnames into your rules (so it will ask DNS what the address is and once the ttl expires, it will ask again).
On some CPEs (I don't remember which), it allowed to enter mac addresses, so the forwarding would always work for specific device, with any GUA address.
But we have to remember, that all these solution are optional and brand-specific; there's a wide range of devices that do not have anything to solve this problem.
I'm using Mikrotik, which doesn't allow prefix-less addresses in firewall, but allows you to put hostnames into your rules (so it will ask DNS what the address is and once the ttl expires, it will ask again).
On some CPEs (I don't remember which), it allowed to enter mac addresses, so the forwarding would always work for specific device, with any GUA address.
But we have to remember, that all these solution are optional and brand-specific; there's a wide range of devices that do not have anything to solve this problem.
> It matters, because when the prefix changes, it changes IP addresses of every single device in your network.
My solution for my home network was to write a script that periodically checks my IPv6 prefix and updates the firewall rules and DNS if it ever changes. It doesn't feel like a great way to do it but it seems to work.
My solution for my home network was to write a script that periodically checks my IPv6 prefix and updates the firewall rules and DNS if it ever changes. It doesn't feel like a great way to do it but it seems to work.
Could you NAT the router WAN external address and route it to a static ULA?
I think the more elegant solution is to use static IP space for hosting services, but most of us home users aren’t used to that.
I think the more elegant solution is to use static IP space for hosting services, but most of us home users aren’t used to that.
A /64 is a literal ton of subnets. Not sure what you mean by that.
SLAAC requires the bottom 64 bits to be part of the host portion of the address. A network prefix larger than /64 limits SLAAC to providing link-local addresses only, which means another mechanism needs to provide routable addresses, such as DHCPv6. That, in turn, prevents the use of privacy addresses.
DHCPv6 is also optional, clients do not have to support it; some do not support it intentionally. So for example, any Android device won't be up and running on SLAAC-less network.
Having an extra 1:1 ipv6 NAT for ULA is added complexity that wouldn't be neccessary if you just give out static addresses.
Its not like IPv6 /56 subnets are expansive. Just give each customer a full /56 net and you are done.
Its not like IPv6 /56 subnets are expansive. Just give each customer a full /56 net and you are done.
I think the OC was arguing that if your global /64 changes, the firewall rules would change as well for any hosted services.
I proposed that you might be able to route the external router’s WAN to a ULA via NAT to save in complexity when the PD changes, but I agree that a static delegation would by far be the easiest. Us home hosters aren’t used to that even though it is technically against the license agreement more often than not.
I proposed that you might be able to route the external router’s WAN to a ULA via NAT to save in complexity when the PD changes, but I agree that a static delegation would by far be the easiest. Us home hosters aren’t used to that even though it is technically against the license agreement more often than not.
I hadn’t put that quite together. I wonder how many people would value IPv6 if they knew it meant less CAPTCHAs.
I'd imagine that to be short lived. IPv6 having such a huge address spaces means the IP reputations are even more worthless than IPv4 so eventually the bots would use it too, and if the ratio of bots to real users become too high sites may refuse IPv6 traffic altogether.
It’s a little different though in that rather than an IP having a bad reputation, it’s usually a /64. That’s how I have seen IPv6 reputation managed since it’s a common network slice & NAT is not really used anymore.
You can block ipv6 /64 subnets just like you can block IPv4 /32 IPs.
Ooof that's an ugly thought. But I think "refuse IPv6 traffic altogether" is not possible for any consumer site. Per the article, there's 40% adoption of IPv6 now and it's only growing. Major parts of the world rely on IPv6 working right. I guess sites could go IPv4-only but given how many other problems there are with IP reputations, that'd be awfully dumb.
CAPTCHAs are the main reason I turned IPv6 on. No idea if it will actually help in practice, it's hard to measure.
The other Starlink hassle is the geocoding for user IPv4 addresses is wildly wrong. I'm in Grass Valley, CA near Sacramento but sites all think my IP is either in Seattle or Los Angeles, depending on the week. This makes streaming services a huge PITA, I have to jump through hoops to convince them I'm in the Sacramento TV market about once a month. IPv6 could help with this too, Starlink could give out more precisely geolocated addresses. Not sure they're doing it though, all I see are IPv4 addresses in the geocoding feed: https://geoip.starlinkisp.net/feed.csv
The other Starlink hassle is the geocoding for user IPv4 addresses is wildly wrong. I'm in Grass Valley, CA near Sacramento but sites all think my IP is either in Seattle or Los Angeles, depending on the week. This makes streaming services a huge PITA, I have to jump through hoops to convince them I'm in the Sacramento TV market about once a month. IPv6 could help with this too, Starlink could give out more precisely geolocated addresses. Not sure they're doing it though, all I see are IPv4 addresses in the geocoding feed: https://geoip.starlinkisp.net/feed.csv
Or, as an alternative, we try to convince people that geoIP lookups are at best uncertain and at worst actively misleading -- and perhaps shouldn't be taken at face value. I personally think this would be a great thing. For paid services that allegedly need to know where you are geographically located, use your billing address. For advertisers it's one less bit of useful information...
I agree! Now please convince Youtube TV, Hulu, and friends.
YTTV at least will prefer your phone's geolocation to the IP address, that's how I "check in" to my metro every couple of months.
YTTV at least will prefer your phone's geolocation to the IP address, that's how I "check in" to my metro every couple of months.
I was on a cruise ship in the Caribbean for a week just last month and I purchased the starlink powered internet package. Looking at my IP data, location info showed that I was actually in Dallas, Texas. Very sad!
[deleted]
[deleted]
> The only practically useful thing about my IPv6 enabled network is that I can run globally routable services on my lan, without NAT port mapping. Of course, only if the client is also IPv6.
A couple of other practically useful things:
- You never get address collisions when connecting to someone else's VPN, or connecting to your home network via VPN from someone else's private network (if you've set that up)
- If there are two people living in your home, they can play online games against a mutual friend who doesn't live in the home without anything breaking
I think you're right that IPv6 isn't a game-changing improvement for most people. It gets rid of some annoyances, it's the obviously correct thing to do for new networks (and cheaper than setting up CGNAT), but fundamentally the pile of hacks on IPv4 is "good enough" for most use cases.
A couple of other practically useful things:
- You never get address collisions when connecting to someone else's VPN, or connecting to your home network via VPN from someone else's private network (if you've set that up)
- If there are two people living in your home, they can play online games against a mutual friend who doesn't live in the home without anything breaking
I think you're right that IPv6 isn't a game-changing improvement for most people. It gets rid of some annoyances, it's the obviously correct thing to do for new networks (and cheaper than setting up CGNAT), but fundamentally the pile of hacks on IPv4 is "good enough" for most use cases.
so for anyone that "just browses the web" (which is overwhelming majority) there is virtually no difference/benefit?
I don't play online games, don't use VPN, have a couple of services on my local RPi that has port forwarded on router and that's it...
ipv6 could be handy when testing some service on my laptop and trying with external services but this happens so rarely that it's not an issue... on the flipside, whenever I enable ipv6 I usually run into problems :|
I don't play online games, don't use VPN, have a couple of services on my local RPi that has port forwarded on router and that's it...
ipv6 could be handy when testing some service on my laptop and trying with external services but this happens so rarely that it's not an issue... on the flipside, whenever I enable ipv6 I usually run into problems :|
> so for anyone that "just browses the web" (which is overwhelming majority) there is virtually no difference/benefit?
Our current patterns of internet behaviour are limited by IPv4, so almost by construction nobody does things that need IPv6.
Few people made international journeys before deep water navigation; watched live streams before Twitch; or had pizza delivered at 4am before dominos.
Our current patterns of internet behaviour are limited by IPv4, so almost by construction nobody does things that need IPv6.
Few people made international journeys before deep water navigation; watched live streams before Twitch; or had pizza delivered at 4am before dominos.
Could you give examples?
One, the most obvious, is actually having distributed net and serving content from your own machine and in the ancient times like 15 years ago Opera tried that by bundling sort of local http-server (?!, can't even remember the name of the project…) but it floped... I'm not sure that ipv4 was the issue or rather the fact that people don't usually have or want their machine work 24/7...
for calls we have to rely on STUN/TURN but than again some consider this a feature as it hides external IP... which with ipv6 would be even more privacy invading?
One, the most obvious, is actually having distributed net and serving content from your own machine and in the ancient times like 15 years ago Opera tried that by bundling sort of local http-server (?!, can't even remember the name of the project…) but it floped... I'm not sure that ipv4 was the issue or rather the fact that people don't usually have or want their machine work 24/7...
for calls we have to rely on STUN/TURN but than again some consider this a feature as it hides external IP... which with ipv6 would be even more privacy invading?
I’m hesitant to suggest specific use cases because general purpose technologies are hard to predict in their applications. I doubt whether anyone accurately forecasted the impact of JS in the browser, for example.
However, I’d love to be able to interact with my car, CCTV cameras and other IoT devices at long distance with fewer middlemen involved.
However, I’d love to be able to interact with my car, CCTV cameras and other IoT devices at long distance with fewer middlemen involved.
I don't see significant difference for most private people. I guess the median has three phones, a tablet and a tv box, there's not much scope to improve the network for that use case.
But IPv6 makes a difference for some other situations. If you operate a network with routers and such, it makes sense to have all connections to internal services use IPv6. Backup, file storage, databases, management interfaces, blah: Give everything its own IPv6 address, don't accept connections on IPv4, and allow IPv4 packets from 192.168/16 only to the outside world.
But IPv6 makes a difference for some other situations. If you operate a network with routers and such, it makes sense to have all connections to internal services use IPv6. Backup, file storage, databases, management interfaces, blah: Give everything its own IPv6 address, don't accept connections on IPv4, and allow IPv4 packets from 192.168/16 only to the outside world.
It's likely the web itself has been shaped by the technology underpinning it. The article would seem to suggest something similar. Look at email. Now we all connect to the central email servers at Google and they handle most of everything else. Perhaps on the IPv6 internet, you would be able to buy a USB stick that handles all your emails for you. No more centralised mail, you just have a small server in your house that does it for you. The same of social media, etc. It would be feasible to offer an entire plug-and-play P2P internet in the form-factor and cost of a small HDD.
Would people want to own such a server? I don't know, but as it stands currently, only the centralised players in the internet sphere can afford to serve content. Perhaps our relationship to these companies would be different if there was no barrier to entry for competition. Perhaps our entire conception of the internet would be different without that fundamental limitation. Or perhaps nothing would change. The central model has its advantages, but I'd also like to be able to own my own website.
Would people want to own such a server? I don't know, but as it stands currently, only the centralised players in the internet sphere can afford to serve content. Perhaps our relationship to these companies would be different if there was no barrier to entry for competition. Perhaps our entire conception of the internet would be different without that fundamental limitation. Or perhaps nothing would change. The central model has its advantages, but I'd also like to be able to own my own website.
> Perhaps on the IPv6 internet, you would be able to buy a USB stick that handles all your emails for you.
You are too optimistic. Poeple can't be bothered to migrate off the google to some alternative provider (also free) and you expect them to buy a "usb stick" for local (mail) server? And then have to keep their machines up all the time and also connected constantly? (not everyone lives in the USA and have FTTH)...
I already mentioned that Opera tried something like "personal pod" 15-20 years ago and it flopped...
> No more centralised mail, you just have a small server in your house that does it for you. The same of social media, etc.
"social media" case seems interesting but again - we had mastodon for distributed social media and it's adoption is lukewarm... and now we have bluesky, which is also distributed and anyone host it and whatnot and it's userbase skyrocketed... and everyone use single instance.
All in all - people don't care about it, they want convenience and nothing else...
You are too optimistic. Poeple can't be bothered to migrate off the google to some alternative provider (also free) and you expect them to buy a "usb stick" for local (mail) server? And then have to keep their machines up all the time and also connected constantly? (not everyone lives in the USA and have FTTH)...
I already mentioned that Opera tried something like "personal pod" 15-20 years ago and it flopped...
> No more centralised mail, you just have a small server in your house that does it for you. The same of social media, etc.
"social media" case seems interesting but again - we had mastodon for distributed social media and it's adoption is lukewarm... and now we have bluesky, which is also distributed and anyone host it and whatnot and it's userbase skyrocketed... and everyone use single instance.
All in all - people don't care about it, they want convenience and nothing else...
> And then have to keep their machines up all the time and also connected constantly?
The idea would be that you plug the stick into a USB port, then it just draws power from the wall and serves files over WiFi. Similar to the Amazon Fire TV stick, it would be a full computer in a small form-factor.
> and everyone use single instance
I wonder if this has anything to do with how difficult it would be to set up your own instance? We already have distributed social media, it's called websites. I think having your own website is pretty appealing to a lot of people. BlueSky is really just a worse version of HTTP with page indexers, which only needs to be that way because of NAT.
> All in all - people don't care about it, they want convenience and nothing else...
I know that people will not bother to migrate off their current software, but the product has its own pros and cons. Perhaps if they were presented with both options when they first obtained an email address, they would have made different choices.
And actually, I think people do care quite a lot. Even something as simple as sending a file to someone is massively complicated by NAT. People don't like the fact that they need to trust their digital lives to a handful of massive American companies. That people lack knowledge of the alternatives is not a sign that there are no better alternatives. See Ford on cars, Jobs on phones, etc.
The idea would be that you plug the stick into a USB port, then it just draws power from the wall and serves files over WiFi. Similar to the Amazon Fire TV stick, it would be a full computer in a small form-factor.
> and everyone use single instance
I wonder if this has anything to do with how difficult it would be to set up your own instance? We already have distributed social media, it's called websites. I think having your own website is pretty appealing to a lot of people. BlueSky is really just a worse version of HTTP with page indexers, which only needs to be that way because of NAT.
> All in all - people don't care about it, they want convenience and nothing else...
I know that people will not bother to migrate off their current software, but the product has its own pros and cons. Perhaps if they were presented with both options when they first obtained an email address, they would have made different choices.
And actually, I think people do care quite a lot. Even something as simple as sending a file to someone is massively complicated by NAT. People don't like the fact that they need to trust their digital lives to a handful of massive American companies. That people lack knowledge of the alternatives is not a sign that there are no better alternatives. See Ford on cars, Jobs on phones, etc.
No gaming allowed. In true communism you don't need entertainment, because you love your job.
what? the world doesn't end with fortnite or whatever brain-rot is currently popular (on utterly locked up platform with excessive anti-cheat)... there is a gazzilion of super entertaining games that you can play locally... :shrug:
False dichotomy. Quake 3 can be played locally and over network.
ULA address clashes are possible, but yes it's highly unlikely
NAT is mostly okay, but carrier grade NAT where you can't forward a port causes real problems.
IPv4 exhaustion is a real problem, it's just not enough to motivate people much.
IPv4 exhaustion is a real problem, it's just not enough to motivate people much.
The main problem I had when I was on CGNAT was not so much port forwarding (annoying, but solvable), but with being banned from all sorts of stuff. The address is shared with so many people and one person did something stupid or malicious or whatnot. Sometimes you don't even know if you're banned or not.
For better or worse, IP blocks are still very common. It's easy to complain about this, but there aren't really any good methods to deal with persistent abuse.
For better or worse, IP blocks are still very common. It's easy to complain about this, but there aren't really any good methods to deal with persistent abuse.
Ah… that makes it sound as if we've reached a phase where IPv6 has no significant problems and saves a little bother compared to IPv4. Switch to v6 ⇒ escape false alarms from tools like fail2ban.
CGNAT is a small tor.
> IPv4 exhaustion is a real problem, it's just not enough to motivate people much.
Well, its only really a problem if you're poor. Rich people don't care - IPs are still cheap enough when you live in a wealthy country & have a decent job.
The people affected by IP address exhaustion are largely the exact set of people who can't do anything about it.
Well, its only really a problem if you're poor. Rich people don't care - IPs are still cheap enough when you live in a wealthy country & have a decent job.
The people affected by IP address exhaustion are largely the exact set of people who can't do anything about it.
What country is that where poor people can’t afford an IP address? Is it a real place?
From the article, IPv4 only has 3.03 billion unique, routable addresses. The world population is 8.2 billion. So there's only enough IPv4 addresses for 1 unique address per 3 people on the planet. But of course, in reality, huge swathes of the IP address range are held by big companies (like amazon), universities and the US military.
Its very common for whole streets or neighbourhoods to collectively share a single IPv4 address. Its required, as a result of simple math.
You'll even see this in some parts of the US and UK.
Its very common for whole streets or neighbourhoods to collectively share a single IPv4 address. Its required, as a result of simple math.
You'll even see this in some parts of the US and UK.
What you're saying is similar to "there's limited amount of SWIFT codes", not enough for each person on earth, so each person cannot have their own bank to receive money transfers.
True, but each person does not need to have their own bank to send or receive money, they can have an account within a bank of their preference, and use that extra information to route money transfers precisely.
"But they can't route money directly" — most people will never need to.
True, but each person does not need to have their own bank to send or receive money, they can have an account within a bank of their preference, and use that extra information to route money transfers precisely.
"But they can't route money directly" — most people will never need to.
Yeah I hear the argument that CG-NAT is fine for most people. It’s true, but kinda sad. It means most people won’t be able to run home servers, or learn to be the server for a multiplayer video game, or all sorts of other things I took for granted when learning the craft. It kinda locks in, technically, the consumer and producer relationship between computers on the internet. And for no good technical reason - just a quirk of history. CGNAT is usable; but it’s sad.
I agree that it’s diverging from what was envisioned for the internet originally, so the thing doesn’t reach its technical potential.
On the other hand, I find it beautiful that network routing architecture and network security architecture naturally converged on NATs — I think because they are easier to understand for people, and more closely reflect what’s actually happening, without some hidden magic.
On the other hand, I find it beautiful that network routing architecture and network security architecture naturally converged on NATs — I think because they are easier to understand for people, and more closely reflect what’s actually happening, without some hidden magic.
In reality an IP address costs about $2 a month at market rates.
Because of two technologies
1) CG-NAT
2) IPv6
You literally can not have one unique IPv4 address per mobile phone.
1) CG-NAT
2) IPv6
You literally can not have one unique IPv4 address per mobile phone.
So? Is your argument that it’s so cheap that everyone should get an IP? That would be mathematically impossible.
If more people wanted an IP, the price would just rise. The same percentage of people (less than 1/3) would have one. They would just pay more.
It’s like buying land in a city like SF. Demand can change the price, but the supply remains the same.
If more people wanted an IP, the price would just rise. The same percentage of people (less than 1/3) would have one. They would just pay more.
It’s like buying land in a city like SF. Demand can change the price, but the supply remains the same.
The argument is that migrating to IPv6 isn't worth anyone's time. (Except for maybe CG-NAT operators.)
The number of people behind CGNAT is huge and rising. It's collectively worth it. And really not that much effort. (If your internal business network is sufficiently entrenched you don't have to change it.)
It is enough for Amazon/Google/FB/Netflix - they start to choke on IPv4 and they also don't want to pay up insane amounts for holding IPv4 ranges. When they switch to IPv6 they have more cheaper addressing. Once they force it down by making faster services via IPv6 all the ISPs will follow right away because everyone will want to have their Netflix/YT streams load faster.
If it was a real problem, market pricing would reflect the increasing severity of that problem.
The truth is that people who care about port forwarding are such a small minority -- especially now that P2P file sharing has lost its hype -- that they don't make a visible dent in the rate of IPv4 exhaustion.
The truth is that people who care about port forwarding are such a small minority -- especially now that P2P file sharing has lost its hype -- that they don't make a visible dent in the rate of IPv4 exhaustion.
The truth is that major cloud providers such as Amazon AWS have begun to charge [more] for static, routed IPv4 addresses.
Last I checked (a few years ago, I suppose), AWS APIs were incapable of using IPv6 internally, so a VPC still needed to dual-stack it in order to use AWS cloud features. That may have changed by now.
Last I checked (a few years ago, I suppose), AWS APIs were incapable of using IPv6 internally, so a VPC still needed to dual-stack it in order to use AWS cloud features. That may have changed by now.
Yep, lots of AWS apis don't work over ipv6, and many require making requests outside the VPC, so you need to have at least one ipv4 address for a NAT.
You can use NAT64, it works with all the AWS services. Although it's pretty stupid that services like ECR don't have IPv6.
NAT64 requires you to have a NAT with a public ipv4 address. Or possibly pay to use someone elses NAT.
AWS supports NAT64 automatically if you have an Internet gateway attached, you just need to set it up in the VPC settings.
https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway...
Says you need to have an AWS NAT for that to work. And AFAIK, setting up a NAT requires an ipv4 elastic ip.
And it makes since that AWS would want customers to have their own IP for NAT64, so that if one customer does something to get the ip address blocklisted it doesn't impact other customers.
Says you need to have an AWS NAT for that to work. And AFAIK, setting up a NAT requires an ipv4 elastic ip.
And it makes since that AWS would want customers to have their own IP for NAT64, so that if one customer does something to get the ip address blocklisted it doesn't impact other customers.
Yes, you're correct.
Though I don't think AWS cares too much about IP blocklist, you can always just get another elastic IP at any moment.
Though I don't think AWS cares too much about IP blocklist, you can always just get another elastic IP at any moment.
IPv4 prices peaked during the Covid pandemic, presumably because of sudden high demand. Amazon took this as an opportunity to increase prices.
Now IPv4 prices are returning to pre-Covid long-term trends. But of course Amazon won't reflect that in their pricing table.
Now IPv4 prices are returning to pre-Covid long-term trends. But of course Amazon won't reflect that in their pricing table.
> Amazon took this as an opportunity to increase prices.
IPv4 prices peaked in early 2022; AWS started charging for public IPv4 in 2024 (announced in 2023):
* https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...
If they had increased prices in 2022 (or at least announced in 2022), then I could see some kind of correlation, but give it was 1.5-2 years after, I doubt there is a connection.
IPv4 prices peaked in early 2022; AWS started charging for public IPv4 in 2024 (announced in 2023):
* https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...
If they had increased prices in 2022 (or at least announced in 2022), then I could see some kind of correlation, but give it was 1.5-2 years after, I doubt there is a connection.
i would expect aws needs a year or two from when they decide to charge for something new just to work out the details
> i would expect aws needs a year or two from when they decide to charge for something new just to work out the details
The price had already dropped, and was continuing to fall, when they announced the change, so if rising acquisition cost was the primary reason for adding the IPv4 charge, it had already went away.
I think AWS has looked at a utilization graph and sees a time their current pool is get used up at current rates and doesn't want to go through the hassle of acquiring more IPv4 addresses, regardless of cost (even if it is "cheap").
I also think that they have statistic for their www.Amazon.com storefront, and maybe are seeing a good proportion from IPv6 and so figure that there's a 'critical mass' (especially mobile).
The price had already dropped, and was continuing to fall, when they announced the change, so if rising acquisition cost was the primary reason for adding the IPv4 charge, it had already went away.
I think AWS has looked at a utilization graph and sees a time their current pool is get used up at current rates and doesn't want to go through the hassle of acquiring more IPv4 addresses, regardless of cost (even if it is "cheap").
I also think that they have statistic for their www.Amazon.com storefront, and maybe are seeing a good proportion from IPv6 and so figure that there's a 'critical mass' (especially mobile).
There is a lot of lag in decisions like this so price falling isn't enough to say anything.
AWS is seeing growth rates reduce and needs to pump up their revenue.
They're moving onto the "squeeze" part of the cycle.
They're moving onto the "squeeze" part of the cycle.
In practice the tech giants such as Google, Apple and Microsoft will dictate adoption of technology. When Chrome starts mandating or heavily recommending IPv6, adoption will reach 99% overnight. That's what happened with https: https://www.znetlive.com/blog/google-chrome-68-mandates-http...
One can only hope.
Either this or a "killer app" use-case that requires IPv6 will push it forward significantly, IMHO.
Either this or a "killer app" use-case that requires IPv6 will push it forward significantly, IMHO.
Like high-quality video calling for free?
Companies will relay your video calls for free. For now. Basically undercutting. The only way to prevent undercutting is by the government regulation.
Companies will relay your video calls for free. For now. Basically undercutting. The only way to prevent undercutting is by the government regulation.
The market price is only something like 5 or 10 dollars a month, but anyone having to pay that to be accessible is an embarrassing failure of the system. It doesn't matter whether it's a big dent in the number of IPs or not.
There are billions of people out there who can access the internet, and make themselves accessible through the internet the way they want, just fine without a dedicated IP address.
Maybe you have a definition of "access" that is different from the usual one. That's fine, but let's be honest, it's not the usual definition.
Maybe you have a definition of "access" that is different from the usual one. That's fine, but let's be honest, it's not the usual definition.
Someone being able to connect to their device is the definition I use. What's your definition?
Being able to relay through a third party is a different thing.
Being able to relay through a third party is a different thing.
Most people are totally fine relaying everything through a third party. A vanishingly small number of email users host it themselves.
But is it "well off people not having a problem paying a buck or two directly or indirectly to an american corporation to be able to bounce traffic" which you refer to as "most people"? I can see how a few billion other people would have problems with that concept for many reasons apart from the obvious financial one.
And for everyone that does pay this "internet tax", it only strengthens the position of said corporations to be able to buy up even more of the available routable ips. It's not hard to see that the end result is very much not in the consumers favor, regardless of how unnecessary it feels for customers currently to have a real ip when all they want is kitten animations on social media.
And for everyone that does pay this "internet tax", it only strengthens the position of said corporations to be able to buy up even more of the available routable ips. It's not hard to see that the end result is very much not in the consumers favor, regardless of how unnecessary it feels for customers currently to have a real ip when all they want is kitten animations on social media.
But this third party isn't free service even if it runs on ip6.
What? I don’t write a check to Google to use their email. It’s free.
This is a problem.
Almost nobody (far, far less than 1% of users overall) do pay this; the system is in this regard smashingly successful by econometric standards.
The IP consolidation is reasonably successful, but it doesn't have to break port forwarding, that's laziness and negligence.
This isn't necessarily true. The scarcity of IPv4 addresses could very well induce a lack of demand and decrease the price. You wouldn't dream of developing a technology that requires people to have an individual IP address, so you don't. This massively reduces the demand for v4 addresses. It's not as if there are users out there who will demand the features you can't implement, and it's not as if you could fund the entire IPv6 network by yourself to bring about those features. Then ISPs have no reason to support v6 because no customers demand it. Instead of increased price, the cost is paid through decreased service. Think of a congested road network. It could be well worth it to build some more roads and ease congestion, but if there is no one in the system willing to pay for it, everyone will suffer.
Doesn't CGNAT also mess up things like Nintendo Switch online multiplayer?
Nintendo should really enable IPv6 on the Switch to help with this
The network experience on Nintendo devices always seemed janky and home-grown. I feel like they built everything from scratch at corp HQ complete with wonky edge cases.
Why was this downvoted? It’s exactly right.
The reason that IPv6 is so lightly used is that it’s cheaper to use IPv4 + workarounds.
I’m not saying this is a good thing or a bad thing, or making any value judgment about IPv4 vs IPv6.
People and businesses don’t spend money on technology upgrades where the benefit is not measurably better than what they already have.
This is just common sense; no one wants to throw away money.
If you want people to use IPv6, then IPv4 has to fail first. As long as people keep making it work then the benefits of changing will never outweigh the costs.
BTW this is exactly the same situation as clean energy vs fossil fuel, etc. In that situation governments are actively putting their thumb on the economic scales in all sorts of ways. Again, I’m not offering a value judgment, just an observation.
The reason that IPv6 is so lightly used is that it’s cheaper to use IPv4 + workarounds.
I’m not saying this is a good thing or a bad thing, or making any value judgment about IPv4 vs IPv6.
People and businesses don’t spend money on technology upgrades where the benefit is not measurably better than what they already have.
This is just common sense; no one wants to throw away money.
If you want people to use IPv6, then IPv4 has to fail first. As long as people keep making it work then the benefits of changing will never outweigh the costs.
BTW this is exactly the same situation as clean energy vs fossil fuel, etc. In that situation governments are actively putting their thumb on the economic scales in all sorts of ways. Again, I’m not offering a value judgment, just an observation.
> The reason that IPv6 is so lightly used is that it’s cheaper to use IPv4 + workarounds
Cheaper? Hetzner and other hosts give IPv6 addresses out for free and charge extra for IPv4 addresses.
Cheaper? Hetzner and other hosts give IPv6 addresses out for free and charge extra for IPv4 addresses.
Most people don’t need a public IPv4 address and can live with CGNAT.
For the relatively small number of people who do need public addresses, renting them from a cloud provider or buying blocks at auction are still economically viable, in comparison to the capital costs of upgrading everything that needs upgrading to support IPv6-only.
For the relatively small number of people who do need public addresses, renting them from a cloud provider or buying blocks at auction are still economically viable, in comparison to the capital costs of upgrading everything that needs upgrading to support IPv6-only.
And if you want PI addresses, they exist for IPv6 only.
Have you tried using PCP to forward the port? I was under the (maybe-incorrect, and if so I would really like to learn) impression that most major CG-NAT setups supported it.
Nah, many carriers don’t support it. I’ve always had to resort to STUN
STUN also isn’t guaranteed if the router is strict. IPv6 removes a lot of these unknown and strange ways that IPv4 infrastructure can break things.
Yep, my point was just that STUN works far more frequently than explicit port forwarding protocols. Part of the reason (for better or worse) is that most major console networks (Xbox live, PSN, etc) will grade your connection poorly if STUN doesn’t work. Customers who otherwise don’t know about networking do complain to ISPs about this sort of thing.
PCP is not widely deployed in South East Asia at the very least. Relying on it is not feasible.
I suppose I can try that some time. I can find absolutely zero mentions of that for the ISP, just the option of buying a static IP.
I had to reluctantly deploy ipv6 on my home network because of ISP requirements + will to use pihole.
Ipv6 is hard. I had to learn quite a bit to make it work and not only I see no value, but it is significantly more difficult to use dire to the address length.
I think IPv6 is a missed opportunity, it was probably designed by experts that did not take into account the population that will use it (not the one users who do not care, but the layer above them)
Ipv6 is hard. I had to learn quite a bit to make it work and not only I see no value, but it is significantly more difficult to use dire to the address length.
I think IPv6 is a missed opportunity, it was probably designed by experts that did not take into account the population that will use it (not the one users who do not care, but the layer above them)
I struggled to get IPv6 running on my home network, then had issues with DNS dual stack once I got it going, so I turned it off.
That said, I think the difficulty of IPv6 is in the UI of the home routers that implement it, and a lack of sane defaults.
The ISP should give every SOHO/residential customer a /60. The router of a simple IPv6 should do prefix delegation. The router should default to SLAAC for local IP addresses, and configuring DNS with Router Advertisements. And residential routers can be set up to have an internal DNS server which populates the ".internal" domain with hostnames from the network.
As a network admin, you have to learn new things like the uses of IPv6 multicast, and ND, the lack of ARP, and some other things. Home users shouldn't have to care about that.
That said, I think the difficulty of IPv6 is in the UI of the home routers that implement it, and a lack of sane defaults.
The ISP should give every SOHO/residential customer a /60. The router of a simple IPv6 should do prefix delegation. The router should default to SLAAC for local IP addresses, and configuring DNS with Router Advertisements. And residential routers can be set up to have an internal DNS server which populates the ".internal" domain with hostnames from the network.
As a network admin, you have to learn new things like the uses of IPv6 multicast, and ND, the lack of ARP, and some other things. Home users shouldn't have to care about that.
Sorry, but under no circumstances should an ISP router auto route internal computers from the network. Thats just going to expose so many internal services, most consumers wouldn't even know they were running in the first place.
If we are to have a transition to IPv6, and I am very much in favour of this, then by all means make the addresses be globally routable, but force people to select the ports and addresses to be shared in their router. Otherwise we end up with another mess ala "open wifi".
If we are to have a transition to IPv6, and I am very much in favour of this, then by all means make the addresses be globally routable, but force people to select the ports and addresses to be shared in their router. Otherwise we end up with another mess ala "open wifi".
I didn't think I suggested an open firewall.
Just as today people have to adjust NAT as kind of an implicit inbound policy, a proper home IPv6 router defaults to drop for inbound traffic.
Just as today people have to adjust NAT as kind of an implicit inbound policy, a proper home IPv6 router defaults to drop for inbound traffic.
That's literally the ISP's and router's job: get packets from A to B.
Now, a home router should probably have a stateful firewall that's on by default, but that's a different matter.
Now, a home router should probably have a stateful firewall that's on by default, but that's a different matter.
It doesn't need to, IPv6 has unique local addresses which is are non-globally reachable; I recall those had it's own can of worms depending on deployment but it's an option for private, local addresses.
EDIT: I also understood the GP comment to be getting around the problem of long IPv6 addresses and not actually making every machine globally accessible.
EDIT: I also understood the GP comment to be getting around the problem of long IPv6 addresses and not actually making every machine globally accessible.
"Auto routing" is fine, as long as there is a firewall.
>The ISP should give every SOHO/residential customer a /60.
The ISP should give every residence 295 quintillion IPv6 addresses? I know there is an abundance of ipv6 addresses but that seems like a lot of waste.
Even assigning a /96 would provide 4.3 billion ipv6 addresses (which is the same number as all ipv4 addresses in existence)
And since available ipv6 space is basically 4.3 Billion^2, assigning an ipv6 /96 would be like assigning a /32 in ipv4 terms of total ipv6 space utilization.
The ISP should give every residence 295 quintillion IPv6 addresses? I know there is an abundance of ipv6 addresses but that seems like a lot of waste.
Even assigning a /96 would provide 4.3 billion ipv6 addresses (which is the same number as all ipv4 addresses in existence)
And since available ipv6 space is basically 4.3 Billion^2, assigning an ipv6 /96 would be like assigning a /32 in ipv4 terms of total ipv6 space utilization.
/64 is needed for SLAAC to work and is basically the default.
Anything larger (usually /56, sometimes even /48) gives the customers a chance to segment their LAN.
Anything larger (usually /56, sometimes even /48) gives the customers a chance to segment their LAN.
Like other person said, /64 is the minimum subnet size. And submitting in ipv6 is best done 4 bits at a time. A /60 is overkill for residents, but because it gives 16 subnets, not because it gives excessive addresses.
There's no minimum subnet size.
/64 acts as a soft limit due to the prevalence of SLAAC. Which is good in a way, since it means ISPs have to give out at least /64, which means you're always able to subnet (although you can't use SLAAC and must use static addresses or DHCP) unlike IPv4 where you have to pay for extra addresses.
Yes, you can't use SLAAC feature, but there's no subnetting limit in IPv6. Any subnet size works.
Writing to you from /72.
Writing to you from /72.
You're technically correct, but ISPs best practice is to hand out a /64.
The purpose of SLAAC intends to have many customers in one /64 network though.
No, just many devices.
You can DoS your whole subnet by pretending to be a billion devices. In IPv4 you can do it by occupying all the IP addresses. Therefore putting several customers on one network is a bad idea, just like in IPv4.
You can DoS your whole subnet by pretending to be a billion devices. In IPv4 you can do it by occupying all the IP addresses. Therefore putting several customers on one network is a bad idea, just like in IPv4.
The purpose of SLAAC is to make it "easy" for a client to get onto the network without something like a DHCP server tracking addresses. If you set it up, it generally just works.
Previously it worked by putting the MAC address in the last 64 bits.
Yes, that was before privacy extensions. It hasn't been like that (in most implementations) for a very long time.
And you get no privacy if /64 prefix is a stable identifier of one customer.
That's not how you're supposed to use IPv6. It would just be 64 bits if that was the case. Instead, 99% of the time, it's a 64 bit subnet ID and a 64 bit device ID.
What requirement could an ISP impose on you for you to be forced to migrate the intranet to IPv6 (because of PI-hole)?
You could always place a small NAT-enabled router between your ISP's device and your home network.
The only problem I could see would be the lack of a (semi-)static public IPv4 address, which one could solve by renting a VPS.
You could always place a small NAT-enabled router between your ISP's device and your home network.
The only problem I could see would be the lack of a (semi-)static public IPv4 address, which one could solve by renting a VPS.
My ISP is the French "Free". They provide a router that is difficult to swap with my own (it is possible, but it is way easier to switch it to a bypass mode). With this router comes a TV box that requires IPv6 to work.
When I replace DHCP/DNS with Pihole I need to account for that. While this is not a complex setup once you understand IPv6 you still need to learn it.
I work in IT so I tried to get myself to IPv6 several times but never had any reason to do so (despite self-hosting a lot and generally being a nerd). I had to do that this time and my uninformed opinion is that it could have been done so that it is much simpler for advanced users (but not yet networking experts)
When I replace DHCP/DNS with Pihole I need to account for that. While this is not a complex setup once you understand IPv6 you still need to learn it.
I work in IT so I tried to get myself to IPv6 several times but never had any reason to do so (despite self-hosting a lot and generally being a nerd). I had to do that this time and my uninformed opinion is that it could have been done so that it is much simpler for advanced users (but not yet networking experts)
So you had to learn IPv6 the same way you learned IPv4. The question is: was it harder ?
It seems you wanted to know IPv6 without learning it because you thought it would be the same as IPv4.
And yes the Free boxes are hard to work with if you don't want to mess with vlan and still have TV services.
I think the main difference is that when I learned IPv4, pure-v4 was sufficient. Today, you can't run a pure-v6 network; you have to deal with both. The closest you can get is NAT64, which 1. doesn't always work, and 2. is still annoying to manage. (Which sucks, because doing just v6 would be nice)
I think this misses the point. An IPv4-only home network has a lot of benefits, simplifying whatever you to in it which relies on IP addresses which you'll have to handle manually in code and databases.
His scenario is really a PITA, where he's basically forced to migrate to IPv6 only because of IPTV. There might have been a solution by creating an IPv6-only VLAN just for the TV, while keeping the rest at legacy, but it's not really trivial.
IPTV with Deutsche Telekom is also a pain, because they feed it in a separate VLAN and the routers and switches need to handle IGMP messages properly (IGMP proxy, IGMP snooping).
His scenario is really a PITA, where he's basically forced to migrate to IPv6 only because of IPTV. There might have been a solution by creating an IPv6-only VLAN just for the TV, while keeping the rest at legacy, but it's not really trivial.
IPTV with Deutsche Telekom is also a pain, because they feed it in a separate VLAN and the routers and switches need to handle IGMP messages properly (IGMP proxy, IGMP snooping).
The biggest design failure of IPv6 is that it was not designed to be backwards-compatible with IPv4. Technologies with established user bases need to evolve with backwards compatibility if they want to take advantage of existing network effects.
This comment shows up like clockwork.
How does a device with a 32-bit-sized addressing scheme construct an IP packet to a device with an address in a 128-bit-sized addressing scheme?
How does a device with a 32-bit-sized addressing scheme construct an IP packet to a device with an address in a 128-bit-sized addressing scheme?
I also appreciated how much the linked article is adamant that IPv6 is what you get when all you do is increase the addressing size. There were wilder alternatives discussed that broke more things or took a more progressive stance. Part of the "there's no compelling 'use case' for IPv6" is that it really doesn't do anything new or exciting, it just increased the address size, and then dealt with the consequences (including "lack of backward compatibility", that was always going to be a consequence of increasing the address size).
It could work like 4 socks requests wrapped in each other like onion. But LAN services wouldn't need to care about long addressing as they don't need to cross network boundary, while letting everything else use new approach, so you could use old stuff without changing anything and there would be no need for new ip6 drivers with new vulnerabilities that are yet to be fixed.
There have been tunneling protocols and systems for IPv6 since nearly the beginning of IPv6. The ability to tunnel it hasn't solved all the "backwards compatibility" complaints for IPv6.
Same for network address translation, both NAT46 and NAT64 standards have existed for a while now and that also hasn't solved the "backwards compatibility" complaints for IPv6.
Same for network address translation, both NAT46 and NAT64 standards have existed for a while now and that also hasn't solved the "backwards compatibility" complaints for IPv6.
Presumably NAT46 still requires most things like middle boxes to upgrade to ipv6, and also somehow needs to squeeze ipv6 addresses into ipv4 addresses, which is only a temporary solution at best.
If addressing is two layer, e.g. NAT is 1.1.1.1 and everything behind it is in 10.0.0.0/8 network (cloudflare could use this scheme while having only one top level address), then you can use existing socks support without any new hardware or software.
If addressing is two layer, e.g. NAT is 1.1.1.1 and everything behind it is in 10.0.0.0/8 network (cloudflare could use this scheme while having only one top level address), then you can use existing socks support without any new hardware or software.
My understanding is NAT46 is very nearly the same as NAT44 ("traditional NAT" between IPv4 and IPv4), using tricks like (but sometimes different from) SOCKS and UPnP and fake port numbers to accept incoming connections for one (or more) IPv4 addresses to pretend to be/delegate to some number of IPv6 consumers behind it. It doesn't solve general routing of any IPv6 address, just specific addresses routing via an IPv4 proxy.
To my understanding, the difference between NAT44 and NAT46 is really hard to spot in practice and somewhat "just" a distinction of whether or not the NAT in question thinks of its IPv6 subnet or IPv4 subnet as "primary". I've heard some major consumer-side routers quietly upgraded to NAT46 as "primary" because it does lend itself to better consumer experiences. Also I've heard some CGNAT (Carrier Grade NAT) is easier to build when considered as NAT46 than NAT44 (as awful as CGNAT is as a general thing).
NAT46 is absolutely a standard designed to be a temporary solution. It's just about the exact same ugly temporary solution as NAT44. (Or at least as NAT44 was supposed to be. The continued confusion of NAT44 as a security measure will probably keep NAT44 still in use long after its problem disappears and its temporary transition window has expired.)
(NAT64 is the interesting one that may not be as temporary as networks move to IPv6-only single stacks. Some cell carriers have already moved in that direction.)
To my understanding, the difference between NAT44 and NAT46 is really hard to spot in practice and somewhat "just" a distinction of whether or not the NAT in question thinks of its IPv6 subnet or IPv4 subnet as "primary". I've heard some major consumer-side routers quietly upgraded to NAT46 as "primary" because it does lend itself to better consumer experiences. Also I've heard some CGNAT (Carrier Grade NAT) is easier to build when considered as NAT46 than NAT44 (as awful as CGNAT is as a general thing).
NAT46 is absolutely a standard designed to be a temporary solution. It's just about the exact same ugly temporary solution as NAT44. (Or at least as NAT44 was supposed to be. The continued confusion of NAT44 as a security measure will probably keep NAT44 still in use long after its problem disappears and its temporary transition window has expired.)
(NAT64 is the interesting one that may not be as temporary as networks move to IPv6-only single stacks. Some cell carriers have already moved in that direction.)
NAT44 translates only client addresses, leaving server addresses intact, NAT46 has to translate both client and server addresses, which can be taxing if there are more servers than clients behind NAT, which is further exacerbated by server farms as each domain now has several addresses. Well, if clients connect only to facebook and google, that's only two addresses to translate.
I don't think you can use port numbers to disambiguate between servers as clients will connect to port 443 for https.
I don't think you can use port numbers to disambiguate between servers as clients will connect to port 443 for https.
But no v4 devices support this "four socks requests wrapped like an onion" thing you're proposing, so how would they work with it?
Socks goes on application layer, hardware sees it as normal tcp/ip4.
Applications don't support it either, and if the hardware is seeing normal v4 then you're limited to sending to v4 destinations. How is this helping?
It would help everything else, applications are not the only part of the network (and many already support socks), there are middle boxes, DHCP, NAT, firewalls, reverse proxies, LAN services and what not that don't need to be aware of new addressing scheme. Firewalls might benefit from it, but even they would still mostly work, even if with less than perfect precision. And even applications can benefit from simplification due to absence of dual mode sockets and no need for two sockets to listen on 0.0.0.0 and [::].
Many already support SOCKS, but not this 4-layer thing you're suggesting. How can a device, application, whatever that doesn't have support for this use it to handle longer addresses? How can it communicate with a remote node that doesn't have support? How can that remote node communicate back?
If you just want to transport v6 over an existing v4 network there are already approaches to do that in v6.
If you just want to transport v6 over an existing v4 network there are already approaches to do that in v6.
I’m curious what your home network involves that’s more complicated than simply plugging everything in to one cheap router.
My network is not particularly complicated. It is the ISP router that manages the biber connection (FTTH). So I have to have that specific ISP provided box, which offers me some more or less crappy features (DNS, DHCP, ...).
If I want to use Pihole for DHCP (because it handles internal registration well) and DNS (because if offers filtering) I need to disable DHCP on the ISP router. But since the TV is handled through IPv6 I need to understand it to make sure that that stack is correctly implemented.
Then I have two mesh networks (tailscale and Wireguard as a backup because I manage family networks that are not available from internet) and a docker stack which has its own surprises.
I would love to put a linux box as the egress router and handle everything there (the fiber, DNS, DHCP, etc.) but it is not possible with the provider because the SFP is proprietary (sort of)).
I am really happy to have a relatively stable 1 Gbps fiber connection so I am not complaining - but doing things exactly as I would wish is not always possible.
If I want to use Pihole for DHCP (because it handles internal registration well) and DNS (because if offers filtering) I need to disable DHCP on the ISP router. But since the TV is handled through IPv6 I need to understand it to make sure that that stack is correctly implemented.
Then I have two mesh networks (tailscale and Wireguard as a backup because I manage family networks that are not available from internet) and a docker stack which has its own surprises.
I would love to put a linux box as the egress router and handle everything there (the fiber, DNS, DHCP, etc.) but it is not possible with the provider because the SFP is proprietary (sort of)).
I am really happy to have a relatively stable 1 Gbps fiber connection so I am not complaining - but doing things exactly as I would wish is not always possible.
> Grade NAT are good enough
CGNAT would cripple every customer I've ever had, going back to the beginning of broadband. Everyone one has had something on-premises that needs to be accessible. Nearly always, it's multiple things that are critical to operations.
CGNAT would cripple every customer I've ever had, going back to the beginning of broadband. Everyone one has had something on-premises that needs to be accessible. Nearly always, it's multiple things that are critical to operations.
However. if someone wants to forever keep 100% of their accessible data in someone else's silos...
and be forced to pay 3rd parties to access anything located on their own premises (ex:cameras)
then imprisonment behind CGNAT might feel 'good enough' to them.> Private networks, NAT, Carrier Grade NAT are good enough, and internet really doesn't care about being completely peer-to-peer.
CG-NAT adds a cost that not everyone can easily afford:
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
> First off I despise both Apple and that other evil empire (house of mouse) I want nothing to do with either of them. Now with that said I am one of four individuals that suggested and lobbied 15 other tribal nations to offer a new AppleTV device in exchange for active ROKU devices. Other nations are facing the same dilemma. Spend an exorbitant amount of money to support a small amount of antiquated devices or replace the problem devices at fraction of the cost.
* https://community.roku.com/t5/Features-settings-updates/It-s...
* "Roku devices don't support IPv6 in 2023 and it's costing ISPs", https://news.ycombinator.com/item?id=35047624
CG-NAT adds a cost that not everyone can easily afford:
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
> First off I despise both Apple and that other evil empire (house of mouse) I want nothing to do with either of them. Now with that said I am one of four individuals that suggested and lobbied 15 other tribal nations to offer a new AppleTV device in exchange for active ROKU devices. Other nations are facing the same dilemma. Spend an exorbitant amount of money to support a small amount of antiquated devices or replace the problem devices at fraction of the cost.
* https://community.roku.com/t5/Features-settings-updates/It-s...
* "Roku devices don't support IPv6 in 2023 and it's costing ISPs", https://news.ycombinator.com/item?id=35047624
Fun reasons why my home network is still on IPv4: IPv6 drains my girlfriend's phone battery :-)
Something to do with Router Advertisement intervals being too short, though I don't get why that only affects her ~5yo android phone. And IPv6 is so complex, I haven't figured out if the RA interval is something I can or should tweak, whether that comes from the PiHole or whether I'd have to flash OpenWRT on my router, or whether my ISP ultimately controls that upstream. Like, I can't figure out as easily where the boundary between me and "the internet" ends with things like the /64 prefixes and SLAAC and RDNSS and all the other acronyms.
Yeah, yeah, I should RTFM, and eventually I might figure out what makes a "good" home IPv6 network. But I can't be arsed to do that in my free time yet, and neither can most software companies cough cough Google/Android and that one guy causing IPv6 drama in the android team
Like.... Ehhh... I'll come back to it in a few more years. "Are we IPv6 yet?"
Something to do with Router Advertisement intervals being too short, though I don't get why that only affects her ~5yo android phone. And IPv6 is so complex, I haven't figured out if the RA interval is something I can or should tweak, whether that comes from the PiHole or whether I'd have to flash OpenWRT on my router, or whether my ISP ultimately controls that upstream. Like, I can't figure out as easily where the boundary between me and "the internet" ends with things like the /64 prefixes and SLAAC and RDNSS and all the other acronyms.
Yeah, yeah, I should RTFM, and eventually I might figure out what makes a "good" home IPv6 network. But I can't be arsed to do that in my free time yet, and neither can most software companies cough cough Google/Android and that one guy causing IPv6 drama in the android team
Like.... Ehhh... I'll come back to it in a few more years. "Are we IPv6 yet?"
I have an Android on my IPv6 network with no issues, and this is across several different router vendors with different defaults for RAs. Maybe it's not an IPv6 issue and you're barking up the wrong tree?
Probably definitely barking up the wrong tree, yes. I happened upon a forum post somewhere about Sony Xperia XA2 battery drain on networks where router advertisment intervals were every 10 seconds or something.
Who knows, maybe I dreamed it.
Nonetheless, I disabled IPv6 again and that, somehow, was the smoking gun that solved the "my phone always runs out of charge overnight when I stay connected to your wi-fi" problem.
Who knows, maybe I dreamed it.
Nonetheless, I disabled IPv6 again and that, somehow, was the smoking gun that solved the "my phone always runs out of charge overnight when I stay connected to your wi-fi" problem.
Never would have guessed that ipv6 could be a battery drain
> It doesn't work from most hotels
Most? I have not seen a _single_ hotel that supported IPv6. Not one. And I always check, just for fun.
I've been to one hotel (in Menlo Park) that used to give out public IPv4 addresses automatically, and several hotels (The Venetian, Bellagio) where you could request a public IPv4 as needed.
BTW, I'm also looking for a SIP provider that supports IPv6. So far I haven't found any in the US.
Most? I have not seen a _single_ hotel that supported IPv6. Not one. And I always check, just for fun.
I've been to one hotel (in Menlo Park) that used to give out public IPv4 addresses automatically, and several hotels (The Venetian, Bellagio) where you could request a public IPv4 as needed.
BTW, I'm also looking for a SIP provider that supports IPv6. So far I haven't found any in the US.
How does requesting a public IP address at a hotel even work? I’m sure if I called the front desk at any hotel and I asked about IP addresses they’d have no idea what I was talking about. Do big fancy hotels have a dedicated IT help desk line?
My anecdote with an ipv6-only home network (linux router):
Doing NAT64 runs into MTU issues and the behavior I observed is chrome would resend the request but only after 30s, firefox and other programs entirely failed to resend requests that were rejected due to MTU issues. Once I got the rejection, retrying in firefox or whatever would work though, so it seems like the path MTU was cached somewhere at the OS level. Reducing MTU manually seemed to fix the problem, but isn't that supposed to be automatic? Why didn't the kernel do the resends?
Old iPads, Androids just don't work, I'm not sure why. My iPhone 11 would connect to the network but declare itself disconnected after 24h or so (some lease or dns expiry which it doesn't renew?).
Steam hardcodes an ipv4 address for login... !! I'm not sure what to make of that, and the fact that it was reported around 10 years ago and they still haven't fixed it. Is it even using TLS?
I needed to make docker dev containers use host networking, because otherwise they'd get ipv4 addresses and try to do ipv4 traffic which couldn't be tunneled by default over ipv6.
Other than that it basically worked.
There's fundamentally only two different ways ipv6 can be configured from an ISP: SLAAC with no delegation, so you essentially share a network with other customers, or DHCPv6 delegation. Unlike IPv4 which has a million different offerings: PPPoE, DSLite, MAP-E, DHCP, etc etc and many of those aren't supported by linux.
I signed up with an ISP that claimed to support NAT64 (Biglobe) but they only support it on their SLAAC ipv6 + PPPoE ipv4 setup, not on their DHCPv6 PD + MAP-E setup, so I had to switch back to SLAAC. At this point in time the NAT64 support seems to be have been a lie... But anyways, to control my network DNS settings despite that I made a program to rewrite RA (and various other packets) with my own DNS server information.
Doing NAT64 runs into MTU issues and the behavior I observed is chrome would resend the request but only after 30s, firefox and other programs entirely failed to resend requests that were rejected due to MTU issues. Once I got the rejection, retrying in firefox or whatever would work though, so it seems like the path MTU was cached somewhere at the OS level. Reducing MTU manually seemed to fix the problem, but isn't that supposed to be automatic? Why didn't the kernel do the resends?
Old iPads, Androids just don't work, I'm not sure why. My iPhone 11 would connect to the network but declare itself disconnected after 24h or so (some lease or dns expiry which it doesn't renew?).
Steam hardcodes an ipv4 address for login... !! I'm not sure what to make of that, and the fact that it was reported around 10 years ago and they still haven't fixed it. Is it even using TLS?
I needed to make docker dev containers use host networking, because otherwise they'd get ipv4 addresses and try to do ipv4 traffic which couldn't be tunneled by default over ipv6.
Other than that it basically worked.
There's fundamentally only two different ways ipv6 can be configured from an ISP: SLAAC with no delegation, so you essentially share a network with other customers, or DHCPv6 delegation. Unlike IPv4 which has a million different offerings: PPPoE, DSLite, MAP-E, DHCP, etc etc and many of those aren't supported by linux.
I signed up with an ISP that claimed to support NAT64 (Biglobe) but they only support it on their SLAAC ipv6 + PPPoE ipv4 setup, not on their DHCPv6 PD + MAP-E setup, so I had to switch back to SLAAC. At this point in time the NAT64 support seems to be have been a lie... But anyways, to control my network DNS settings despite that I made a program to rewrite RA (and various other packets) with my own DNS server information.
Can it be that IPv4 price now leveled off because big players are getting ready to switch to IPv6 any time and not buying up anything that is available?
If GooG/FB/Amazon force IPv6 how long will it take for ISPs to switch? I think in one week where some people cannot reach GooG/FB and any ISP that was dragging his feet has implemented IPv6 by the end of the week.
I expect IPv6 adoption will blow up any time now as past performance is not indication of future changes ;) because there is much more required on the server side than it was ever before. ISP and home use could live with NAT but servers not really even if you can handle bunch of services on a single IP address, there is just limited traffic you can squeeze onto a single server.
If GooG/FB/Amazon force IPv6 how long will it take for ISPs to switch? I think in one week where some people cannot reach GooG/FB and any ISP that was dragging his feet has implemented IPv6 by the end of the week.
I expect IPv6 adoption will blow up any time now as past performance is not indication of future changes ;) because there is much more required on the server side than it was ever before. ISP and home use could live with NAT but servers not really even if you can handle bunch of services on a single IP address, there is just limited traffic you can squeeze onto a single server.
TFA is suggesting almost the exact opposite. "Servers" are moving more and more to an architecture where the service is a distributed collection of machines all over the world sharing only a DNS name; multiple servers share the same physical box, relying on TLS SNI to decide which particular content is intended. While NAT itself would be a problem, the reality is that a service no longer needs some unique IP: the same public IP can be shared by Netflix and Max, and the only relevant thing is that the incoming connection specifies which of the two is intended through the DNS name.
SNI took the pressure a notch down. It was introduced 2012 and graph in article was showing peak of price of IP address in 2021 - where everyone was watching Netflix all day or was in video calls. SNI is not solving video streaming problem you just need more physical networking gear to handle streaming and more public IP addresses.
> internet really doesn't care about being completely peer-to-peer
Internet (I mean, the IETF) does care a lot about the end-to-end principle, however. It is true that "misbehaving" NATs break e2e badly. It is also true that IPv6 can also be put behind such NATs.
Internet (I mean, the IETF) does care a lot about the end-to-end principle, however. It is true that "misbehaving" NATs break e2e badly. It is also true that IPv6 can also be put behind such NATs.
> I have even implemented an IPv6-Only network. It fully works, including accessing IPv4 only websites like github.com via DNS64 and NAT64 at my router.
What did you use to implement that? I found it surprisingly difficult to find software to do NAT64 on Linux.
What did you use to implement that? I found it surprisingly difficult to find software to do NAT64 on Linux.
I use tayga.
> I have fully implemented IPv6 in my home network.
I could have written this message in 1999. That's 25 years ago (as you alluded to). That's a long time to hold your breath.
I could have written this message in 1999. That's 25 years ago (as you alluded to). That's a long time to hold your breath.
Don't forget that Hetzner and other hosts are also charging extra for IPv4 addresses now, while IPv6 is free.
Also, you're speaking from the privileged perspective of a first-world country- many other countries missed the boat on IPv4 addresses and are limited to IPv6, which also probably explains why global uptake continues upwards despite the US stagnating.
I have never gotten github access from my IPv6-only Hetzner-hosted machine. I don't have control over their router(s) and I am not an experienced network admin who would know how to set up something that would let me simply fucking "git clone" from that machine. I would end up having to set up something janky. The fact that Github is IPv4-only in 2024 is atrociously bad and hopefully handing over business hand-over-fist to their closed-source and open-source competitors.
I love having access to all my internal machines over IPv6 from anywhere without having to use janky hacks. I'd be able to self-host boutique and portfolio websites for example (at least from IPv6-enabled clients), without having to use (and pay for) an external host just for the sake of access.
The fact that hotels and work LANs don't permit access is a "hotel and work LAN" problem, as well as a chicken-and-egg one. If enough people request it (perhaps work people want some cheap Hetzner hosts for dev environments and traveling devs want access to the same machines), the Sysops That Be will make it happen- They are certainly educated enough in the space to enable it.
You are neglecting the cost savings and the non-Western perspective, as well as the "simple developer, not devops expert" perspective.
Also, you're speaking from the privileged perspective of a first-world country- many other countries missed the boat on IPv4 addresses and are limited to IPv6, which also probably explains why global uptake continues upwards despite the US stagnating.
I have never gotten github access from my IPv6-only Hetzner-hosted machine. I don't have control over their router(s) and I am not an experienced network admin who would know how to set up something that would let me simply fucking "git clone" from that machine. I would end up having to set up something janky. The fact that Github is IPv4-only in 2024 is atrociously bad and hopefully handing over business hand-over-fist to their closed-source and open-source competitors.
I love having access to all my internal machines over IPv6 from anywhere without having to use janky hacks. I'd be able to self-host boutique and portfolio websites for example (at least from IPv6-enabled clients), without having to use (and pay for) an external host just for the sake of access.
The fact that hotels and work LANs don't permit access is a "hotel and work LAN" problem, as well as a chicken-and-egg one. If enough people request it (perhaps work people want some cheap Hetzner hosts for dev environments and traveling devs want access to the same machines), the Sysops That Be will make it happen- They are certainly educated enough in the space to enable it.
You are neglecting the cost savings and the non-Western perspective, as well as the "simple developer, not devops expert" perspective.
Well there are serious network effects at play.IPv6 would be a lot more valuable if it was more broadly deployed.
What do you see as the key points that create a lot more value?
You are correct that - for many common environments - IPv6 lacks a compelling case for deployment. However, that is not universally true: for those organizations closer to the core of the Internet (with corresponding larger traffic and growth rates), the premise that you can carry all the traffic through CGNAT fails (simply review communications on the nanog mailing list from organizations such as Comcast, T-mobile, ATT, Google, MSFT Azure, Amazon, Verizon, etc.) to see clear evidence of such…. IPv6 solves their IPv4 exhaustion problem and has allowed the Internet continue to grow - if you’re not seeing a similar need, then it is simply that you are not at the core of the Internet.
To give ipv6 some credit, there are some very useful things like flow labels. But I agree completely with the rest of your sentiment.
IPv4 is "good enough", but we could do some things to extend its usage further.
First, adopt service location in DNS, and being to retire it at the TCP port-number layer. Then we could run more than one website per ip address, and this would significantly increase resilience against censorship. Rotating ports for censored websites is a significantly easier task than rotating IPs for them since it does not involve routing changes. This could be done with "here and now" technology.
IPv4 is "good enough", but we could do some things to extend its usage further.
First, adopt service location in DNS, and being to retire it at the TCP port-number layer. Then we could run more than one website per ip address, and this would significantly increase resilience against censorship. Rotating ports for censored websites is a significantly easier task than rotating IPs for them since it does not involve routing changes. This could be done with "here and now" technology.
> To give ipv6 some credit, there are some very useful things like flow labels.
They are not useful, as you can't depend on them.
They are not useful, as you can't depend on them.
Wasn't aware of this actually, whats the issue with them?
If you're using solely the flow labels to do load balancing, malicious clients can force traffic to come through only one load balancer by setting the same flow label.
You need to add the source IP/port into the mix. But they alone are in practice enough for decent load balancing.
You need to add the source IP/port into the mix. But they alone are in practice enough for decent load balancing.
> internet really doesn't care about being completely peer-to-peer.
I think this is mostly the way it is because of all the NAT headaches that come with IPv4.
We regularly see the limitations of Dropbox/Google drive when we just want to share that large birthday video with our friends/family. Imagine them having a secure link to your device that you can revoke any time.
Same with all the home automation / iot devices / cctv cameras that have no excuse not to be local first/need you to install an ad infested app.
I think this is mostly the way it is because of all the NAT headaches that come with IPv4.
We regularly see the limitations of Dropbox/Google drive when we just want to share that large birthday video with our friends/family. Imagine them having a secure link to your device that you can revoke any time.
Same with all the home automation / iot devices / cctv cameras that have no excuse not to be local first/need you to install an ad infested app.
I work in media technology, and the amount of equipment in that field (think: room control systems, touch panels, projectors, media players, remote controled power switches) that does only support IPv4 is staggering.
As it might be wise to banish those devices into an isolated net anyways that might not matter too much — but a transition to IPv6-only has many places where hard- and software is the blocking factor.
As it might be wise to banish those devices into an isolated net anyways that might not matter too much — but a transition to IPv6-only has many places where hard- and software is the blocking factor.
> Other than this one use case, IPv6 does nothing for me.
IPv6 was not created for you, but it benefits you. NAT is computationally expensive and it does have a real impact for large organizations with thousands and tens of thousands of devices. Such as large universities or you know ISPs.
IPv6 was not created for you, but it benefits you. NAT is computationally expensive and it does have a real impact for large organizations with thousands and tens of thousands of devices. Such as large universities or you know ISPs.
This statement above is the point…. Your networking requirements are quite modest compared to those whom IPv6 is essential.
This was true 25 years ago and is still as true today.
China's IPv6 transition is 74% complete.[1] Conversion to IPv6 was specifically called out in China's 14th Five Year Plan, which gives the goal high visibility within the government and the Party. Conversion is quite far along. The current goal is everything IPv6 enabled by 2025, IPv4 turns off in 2030.
99% of the top 100 mobile applications in China are on IPv6. China Mobile's backbone is now IPv6 only.
[1] https://www.china-ipv6.cn/#/
99% of the top 100 mobile applications in China are on IPv6. China Mobile's backbone is now IPv6 only.
[1] https://www.china-ipv6.cn/#/
India is also around 75%. Both of them cover quite a bit of humanity. The regions where growth is going to happen don't own a lot of blocks so they will focus on IPv6.
Vietnam (pop. 98M) has mandated moving to IPv6, with goals for migration between 2025 and 2030:
* https://www.theregister.com/2024/10/14/vietnam_digital_infra...
* https://www.theregister.com/2024/10/14/vietnam_digital_infra...
Meanwhile in Australia I called my ISP to enable IPv6 and they asked me to justify why I needed it.
Because "it's the Internet" and has been a standard since the year 2000 doesn't seem to be sufficient reason to bother...
Because "it's the Internet" and has been a standard since the year 2000 doesn't seem to be sufficient reason to bother...
Some of the larger Danish ISP has explained that they do not offer IPv6, because there's no demand. I very much doubt that they have any demand for IPv4 either, because most people don't know and don't care how the internet is delivered to them.
If it's NBN, Aussie Broadband and Superloop/Exetel have good IPv6 support with prefix delegation giving you a /56.
I'm on Aussie Broadband, but the building is with OptiComm -- a company that decided that their business model is lock-in contracts with the apartment builders and price-gouging of customers.
Yup, I have a /56 delegated. Now if I only had something at home that needs to be world accessible...
"I'm a software developer and I need it to do my job."
Even if it's not strictly true, that seems like a solid justification. Though obviously that won't work for the general public.
Even if it's not strictly true, that seems like a solid justification. Though obviously that won't work for the general public.
That is a wild response to give a customer. I'm surprised they are still in business if that's how they treat fairly reasonable customer requests.
Yeah, a normal ISP would just say "we don't have it".
What ISP is that? Name and shame. I'm Australian and want to know to avoid them.
OptiComm
You can't avoid them because they're not a retail telco, they provide wholesale/bulk services to apartment buildings with 15-year lock in contracts.
You can't avoid them because they're not a retail telco, they provide wholesale/bulk services to apartment buildings with 15-year lock in contracts.
The IPv6 transition is a side effect of China building their own internal "internet" from the ground up that will not be connected to what we think of as the internet. "Turning off IPv4" is code for shutting off the DFZ and users only being able to reach other networks within the country.
We should absolutely not be pointing to this as a success or a model for other countries.
We should absolutely not be pointing to this as a success or a model for other countries.
I don't think they need IPv6 to cut off everyone from the internet (if that were their plan). They can do the same with just IPv4.
What? You can still connect to worldwide IPv6 endpoints in China -- some endpoints are censored, just the same as how the IPv4 firewall is accomplished.
You are describing as if the IPv6 network within China is completely blocked off from the wider network. It's not.
You are describing as if the IPv6 network within China is completely blocked off from the wider network. It's not.
US Dept. of Commerce mandates the same:
https://www.commerce.gov/about/policies/ipv6-policy
https://www.commerce.gov/about/policies/ipv6-policy
Collective action by people willing to listen to experts is needed to achieve positive infrastructure results. Infrastructure being a precept to growth, I would not be surprised if our inability to do this leads to the West's current global position becoming greatly diminished.
This is yet another way they're ahead relative to the US.
When you want to control and censor all internet is much easier todo that only with ipv6 and not care for ipv4, not sure if that's a "step ahead"
IPV4 internet is so broken in terms of surveillance you might as well just get a satellite uplink or some sort of out-of-band channel if you're in china.
v6 is just as easy to censor as v4. Given the popularity of Veitnamese pho noodles over there, I don't think internet censorship is as important an objective as you estimate. Have you noticed how many Chinese tourists there are around the world? Not much you can do about internet when any of them could just pick up a newspaper.
My impression is that the Chinese government doesn’t care about a few people being able to access blocked content. What they want to do is prevent large social movements from forming via the mainstream internet.
People posting have mentioned that IPv4 is working for what they use the internet for. But of course it is. When NATs has been required for your whole life, how could the internet have built features that needed p2p routing? Just convince businesses to build something that requires special router configuration? And still wouldn’t work on phones or with ISPs that require CG NAT? You got what worked out of the box. You obviously couldn’t use what didn’t exist.
Why do people assume IPv6 means "easy p2p"?
Even if NAT will be gone one day, the stateful firewalls won't. Every every home router would still ship with "deny all incoming" by default, and every corporate network would have the same setting as well.
Same as IPv4, IPv6 serving would still need registration with border device, either manual by user, or via UPnP-equivalent.
Even if NAT will be gone one day, the stateful firewalls won't. Every every home router would still ship with "deny all incoming" by default, and every corporate network would have the same setting as well.
Same as IPv4, IPv6 serving would still need registration with border device, either manual by user, or via UPnP-equivalent.
UDP hole punching works when you don't have symmetric NAT. So e.g. voice and video calls don't need a proxy and can be higher quality. You only need a third party to locate/signal your peer.
"everything gets a global IP, no more NAT headaches" was one of marketing talking points for IPv6. Not necessarily the case nor welcomed by everyone, but that was the intent.
Wide scale deployment of NAT (the "home router" that allowed you to connect multiple devices) was the greatest leap in internet security we ever made. I remember the days when we had "everything gets a global IP," and we do NOT want to go back to that. Look up Conficker, Code Red, Blaster, etc.
People naively assume the large IPv6 address space somehow hides your computer on the internet. That isn't true. Both because v6 host discovery is a solved-ish problem for attackers, and worms have near unlimited resources to throw at the wall.
People naively assume the large IPv6 address space somehow hides your computer on the internet. That isn't true. Both because v6 host discovery is a solved-ish problem for attackers, and worms have near unlimited resources to throw at the wall.
NAT is technically not a firewall in itself, I believe early/some NAT implementations used deterministic assignments between external range to internal ip:port. They can be more transparent if that is the goal.
But the effect of proliferation of cheap Wi-Fi routers with cheap dynamic NAPTs in conjunction with UPnP did to XP-era PC security - 100% agreed, it was like sunlight self-disinfecting brass door handles.
But the effect of proliferation of cheap Wi-Fi routers with cheap dynamic NAPTs in conjunction with UPnP did to XP-era PC security - 100% agreed, it was like sunlight self-disinfecting brass door handles.
You'll still need a router to route. It just won't have to do NAT. It can still do a statefull firewall, just like it does with IPv4.
I remember those days too. They had nothing to do with computers not being behind a NAT.
They had to do with computers being directly addressable, routable, and reachable by the entire Internet, which was the default prior to widespread deployment of NAT. NAT isn't the best way to do it, but it probably is the single biggest factor in reducing the external reachability of endpoint IPs.
NAT deployment here is only tangential to the real differentiator: the firewall. I mean, you can make a case that NAT is a poor man's firewall but you should know that it's not a substitute for a security model. Zero trust is now the dominant philosophy, and it allows for firewall rules to be derived procedurally.
It's a shame the likes of Microsoft only care about "zero trust" insofar their compliance checkboxes with the the US government. They see it as a chore. Contrary to Google, Cloudflare, et al.
It's a shame the likes of Microsoft only care about "zero trust" insofar their compliance checkboxes with the the US government. They see it as a chore. Contrary to Google, Cloudflare, et al.
NAT was originally delivered as a security mechanism.
With how trivial generating new addresses in IPv6 is, it'd be cool to have a host block all incoming traffic on its own and have each service that deserves to be reached over the listen on an address unique to the service.
> have each service that deserves to be reached over the listen on an address unique to the service
It’s already a thing. These unique per-service addresses are called “ports” in IP protocol.
It’s already a thing. These unique per-service addresses are called “ports” in IP protocol.
Hosting service A shouldn't mean that every user of service A can also figure out you host C, B and D.
Also, the IP protocol does not care about ports at all. Ports are a thing for UDP and TCP.
Also, the IP protocol does not care about ports at all. Ports are a thing for UDP and TCP.
> Also, the IP protocol does not care about ports at all. Ports are a thing for UDP and TCP.
You're right, they are one level above.
> Hosting service A shouldn't mean that every user of service A can also figure out you host C, B and D.
It how are ports on a single IP address essentially different from multiple IP addresses within a subnet?
You're right, they are one level above.
> Hosting service A shouldn't mean that every user of service A can also figure out you host C, B and D.
It how are ports on a single IP address essentially different from multiple IP addresses within a subnet?
In a /64, enumerating all hosts will not be as practical as enumerating all ports on a single IP. Further, you will not be able to link that two services are running on the same host by just the IP.
[deleted]
I can do more with the Internet today than I could with a static /22 assigned over my ISDN BRI back in the mid-1990s. A lot of things I would do back then, I would do differently today; running a chat system by connecting directly out to 6667/tcp feels pretty silly now, for instance. It's rough to build protocols that work that way today, but you're not missing much. Things were not better before the advent of presumptive NAT.
p2p was simpler. The NAT epidemic has totally suffocated P2P because no one can host anything anymore.
You can't trivially host your own blog, for example, without going to your ISP and requesting a static address, and then configuring port forwarding. This is why everyone got stuck on social media, because they need someone else to run their website essentially.
You can't trivially host your own blog, for example, without going to your ISP and requesting a static address, and then configuring port forwarding. This is why everyone got stuck on social media, because they need someone else to run their website essentially.
That's a retcon. People used Blogger because it was more convenient than setting up Apache and PHP on a webserver of their own. Linux nerds for whom doing that is no big deal are an infinitesimal fraction of everyone who blogged.
why does it have to be such a big ordeal? A blog is pretty much just a static site.
Is it unimaginable that someone uses a HTML editor like microsoft word or something to write a blog and then copies it into the folder of a static web server? I'm sure it would be way simpler if people had the time to figure out P2P and the associated UI, it's not fundamentally super complicated versus client-server.
Is it unimaginable that someone uses a HTML editor like microsoft word or something to write a blog and then copies it into the folder of a static web server? I'm sure it would be way simpler if people had the time to figure out P2P and the associated UI, it's not fundamentally super complicated versus client-server.
Just the idea of having an always-on computer anywhere in your home excludes probably more than 80% of everyone who has ever written a blog. IPv4 is not why people use hosted services.
> Just the idea of having an always-on computer anywhere in your home excludes probably more than 80% of everyone who has ever written a blog.
I have yet to meet someone who turns off the router at night, although I have heard of such people.
Then if you think about it, TVs, washing machines, etc. people are too lazy to turn them off, and OLED TVs even require being turned on while not being used.
I have yet to meet someone who turns off the router at night, although I have heard of such people.
Then if you think about it, TVs, washing machines, etc. people are too lazy to turn them off, and OLED TVs even require being turned on while not being used.
He obviously meant a general-purpose PC, the type of thing you might host a blog from.
so when you can have a TV for movies, why can't you have a server for a blog?
Because you have to have a TV for movies (unless you want to watch them on a small laptop screen)[1]. Whereas there is very literal practical reason to self-host a blog.
[1]: Yes I know cinemas exist but they are very expensive and don't show content on demand.
[1]: Yes I know cinemas exist but they are very expensive and don't show content on demand.
So you can.
This argument is a different one compared to the one before.
This argument is a different one compared to the one before.
What is complex is ongoing work. You have to watch for and apply security patches forever.
Well sure, I’m not trying to say that the internet is less capable generally now than in the past.
I’m suggesting that the way you build an app is shaped by the prevalence of NAT, the same way the apps you build are shaped by how much bandwidth home users have for devices.
Some types of apps benefit from p2p functionality, and those hit obstacles for normal users due to port forwarding requirements, and are largely impossible which CG. I don’t think NAT is a villain, just something that does affect what and how we build stuff.
I’m suggesting that the way you build an app is shaped by the prevalence of NAT, the same way the apps you build are shaped by how much bandwidth home users have for devices.
Some types of apps benefit from p2p functionality, and those hit obstacles for normal users due to port forwarding requirements, and are largely impossible which CG. I don’t think NAT is a villain, just something that does affect what and how we build stuff.
I gotta say don't sleep on this article thinking it's just another article about IPv6 adoption stats.
There's a lot of interesting thought in the second half about what the Internet fundamentally is and where it's going. The author argues that the use of TLS and SNI has fundamentally changed the internet from a number based routing network to a network based on DNS names and SNI where the numbers involved don't really matter anymore.
> Where is this heading in the longer term? We are pushing everything out of the network and over to applications. Transmission infrastructure is becoming an abundant commodity. Network sharing technology (multiplexing) is decreasingly relevant. We have so much network and computing resources that we no longer have to bring consumers to service delivery points. Instead, we are bringing services towards consumers and using the content frameworks to replicate servers and services With so much computing and storage the application is becoming the service, rather than just a window to a remotely operated service.
There's a lot of interesting thought in the second half about what the Internet fundamentally is and where it's going. The author argues that the use of TLS and SNI has fundamentally changed the internet from a number based routing network to a network based on DNS names and SNI where the numbers involved don't really matter anymore.
> Where is this heading in the longer term? We are pushing everything out of the network and over to applications. Transmission infrastructure is becoming an abundant commodity. Network sharing technology (multiplexing) is decreasingly relevant. We have so much network and computing resources that we no longer have to bring consumers to service delivery points. Instead, we are bringing services towards consumers and using the content frameworks to replicate servers and services With so much computing and storage the application is becoming the service, rather than just a window to a remotely operated service.
Yes, I read the article as well!
I'd still love to have a dedicated IP address associated to the house so I didn't need a contract to dish up a blog & photos for my 3 friends. I'm sure P2P would make it much harder to extract money from people.
I'd still love to have a dedicated IP address associated to the house so I didn't need a contract to dish up a blog & photos for my 3 friends. I'm sure P2P would make it much harder to extract money from people.
GitHub is still not accessible on the IPv6-only internet: https://isgithubipv6.live/
Consider codeberg.org as alternative: Has full IPv6 support, is not owned by Microsoft, does not force 2FA on its users and is a non-commercial enterprise.
Yup. GitHub alone killed my last effort to go all-in on IPv6 for my personal cloud.
Sure, I could have hacked my way through it. But, that was more work than just paying the extra few cents a month for IPv4.
Sure, I could have hacked my way through it. But, that was more work than just paying the extra few cents a month for IPv4.
AStonesThrow(1)
IPv6 is _still_ not at the feature parity with IPv4!
I'm not kidding. For example, Android doesn't support stateful DHCPv6. And DHCPv6 doesn't have the _basic_ feature of DHCPv4: hostnames. You can't easily use it to do a quick survey of your network.
Then you have that @#&(^(&!@^ that is ULA.
With IPv4 we have a very useful pattern: you create an "internal" network that is stable and predictable. It's routed to the outside world through NAT. If the external connection goes down, the internal network is unaffected.
With IPv6 you're supposed to have ULA and the global routed addresses in parallel. So now the external connection goes down, and the router withdraws the prefix from the router advertisement. Half of the hosts lose their external addresses, but keep the ULAs. Half of the hosts don't implement prefix withdrawal, and keep both their ULAs and the normal addresses. Congrats, now these hosts can't talk to each other due to the ULA addresses being less preferred.
And of course, IPv6 hasn't improved on the PMTU. So if you're running an Internet service, you need to use something like 1400 MTU to make sure some of the misconfigured tunneled clients don't get shafted. There's now an RFC that makes it useful: https://datatracker.ietf.org/doc/html/rfc9268 , but it's Experimental and it'll need ~20 years to be deployed anyways.
IPv6, a story of recursive utter failure at all levels...
I'm not kidding. For example, Android doesn't support stateful DHCPv6. And DHCPv6 doesn't have the _basic_ feature of DHCPv4: hostnames. You can't easily use it to do a quick survey of your network.
Then you have that @#&(^(&!@^ that is ULA.
With IPv4 we have a very useful pattern: you create an "internal" network that is stable and predictable. It's routed to the outside world through NAT. If the external connection goes down, the internal network is unaffected.
With IPv6 you're supposed to have ULA and the global routed addresses in parallel. So now the external connection goes down, and the router withdraws the prefix from the router advertisement. Half of the hosts lose their external addresses, but keep the ULAs. Half of the hosts don't implement prefix withdrawal, and keep both their ULAs and the normal addresses. Congrats, now these hosts can't talk to each other due to the ULA addresses being less preferred.
And of course, IPv6 hasn't improved on the PMTU. So if you're running an Internet service, you need to use something like 1400 MTU to make sure some of the misconfigured tunneled clients don't get shafted. There's now an RFC that makes it useful: https://datatracker.ietf.org/doc/html/rfc9268 , but it's Experimental and it'll need ~20 years to be deployed anyways.
IPv6, a story of recursive utter failure at all levels...
> dhcpv6
Just skip DHCPV6, just use SLAAC. Plus I've never seen DHCP hostnames work.
Now I just ping ff02::1 multicast to see what devices are on my network. Unfortunately much software makes it a pain to use link-local addresses but they're really convenient as they normally don't change across networks.
> Half of the hosts don't implement prefix withdrawal, and keep both their ULAs and the normal addresses. Congrats, now these hosts can't talk to each other due to the ULA addresses being less preferred.
I've had similar issues with crappy devices not relinquishing DHCPv4 IPs properly. Always fun trying to figure out why your laptop is dropped off your network after 20 minutes because it honors DHCP.
The lack of proper prefix widthdrawl sucks. Though it's something software should be able to handle by preferring ULA addresses when communicating locally.
Just skip DHCPV6, just use SLAAC. Plus I've never seen DHCP hostnames work.
Now I just ping ff02::1 multicast to see what devices are on my network. Unfortunately much software makes it a pain to use link-local addresses but they're really convenient as they normally don't change across networks.
> Half of the hosts don't implement prefix withdrawal, and keep both their ULAs and the normal addresses. Congrats, now these hosts can't talk to each other due to the ULA addresses being less preferred.
I've had similar issues with crappy devices not relinquishing DHCPv4 IPs properly. Always fun trying to figure out why your laptop is dropped off your network after 20 minutes because it honors DHCP.
The lack of proper prefix widthdrawl sucks. Though it's something software should be able to handle by preferring ULA addresses when communicating locally.
> Plus I've never seen DHCP hostnames work
Over half the workstations at my office use DHCP hostnames and they work just fine. In fact I'll say exactly the opposite: I've never seen DHCP hostnames not work.
Over half the workstations at my office use DHCP hostnames and they work just fine. In fact I'll say exactly the opposite: I've never seen DHCP hostnames not work.
To be fair work is the wrong term, but more "used" as in be implemented and utilized.
> Now I just ping ff02::1 multicast to see what devices are on my network. Unfortunately much software makes it a pain to use link-local addresses but they're really convenient as they normally don't change across networks.
How does that help? I don't want a list of IPs, I want to reach my devices by name (which DHCP makes easy).
How does that help? I don't want a list of IPs, I want to reach my devices by name (which DHCP makes easy).
mDNS (formerly known as Bonjour and other things) uses multicast names to call devices by name on the local subnet. It works most of the time on most of the modern OSes.
> ping ff02::1 multicast
Wasn't this disabled for IPv4 for being a security concern? See the Linux net.ipv4.icmp_echo_ignore_broadcasts sysctl.
I wonder if this will stay enabled for IPv6.
Wasn't this disabled for IPv4 for being a security concern? See the Linux net.ipv4.icmp_echo_ignore_broadcasts sysctl.
I wonder if this will stay enabled for IPv6.
> Just skip DHCPV6, just use SLAAC. Plus I've never seen DHCP hostnames work.
Here's how a part of my IPv4 network looks in my router's control panel: https://imgur.com/a/xZDUfqw , I can easily set up permanent local IPv4 addresses for the fixed infrastructure, and I can easily see which hosts are alive.
Yes, it's not 100% perfect, but it works most of the time just fine. Even with crappy IoT devices.
Here's how it looks for IPv6 and SLAAC: https://imgur.com/a/DiUNqTC - good luck trying to make sense of it.
Here's how a part of my IPv4 network looks in my router's control panel: https://imgur.com/a/xZDUfqw , I can easily set up permanent local IPv4 addresses for the fixed infrastructure, and I can easily see which hosts are alive.
Yes, it's not 100% perfect, but it works most of the time just fine. Even with crappy IoT devices.
Here's how it looks for IPv6 and SLAAC: https://imgur.com/a/DiUNqTC - good luck trying to make sense of it.
I mean both are fairly complex tables. The ipv6 addresses are longer, but really I'd use hostnames in either case. Ipv4 includes the client id's, dhcp lease time, Mac addresses, etc.
I just wish routers had better / easier support for local DNS. Also a true tld reserved for internal network names would be awesome. Technically `.internal` is undefined.
That said, I do use ipv4 for easy local addresses just because local DNS is such a PITA to setup. Though I use ipv6 in my hosts file for setting reliable access to specific hosts where the ip doesn't change.
I just wish routers had better / easier support for local DNS. Also a true tld reserved for internal network names would be awesome. Technically `.internal` is undefined.
That said, I do use ipv4 for easy local addresses just because local DNS is such a PITA to setup. Though I use ipv6 in my hosts file for setting reliable access to specific hosts where the ip doesn't change.
> I'd use hostnames in either case
How? There is no way to associate hostnames with addresses in IPv6 that works unversally. Stateful IPv6 is _not_ _supported_ by Android, for example.
And since _each_ _device_ handles its own address selection, there's no central way to say "hey, this is an IP camera, let it have a static ::1:2:3:4 address suffix".
Moreover, with IPv6 I'm losing an ability to do quick checks of the network health.
How? There is no way to associate hostnames with addresses in IPv6 that works unversally. Stateful IPv6 is _not_ _supported_ by Android, for example.
And since _each_ _device_ handles its own address selection, there's no central way to say "hey, this is an IP camera, let it have a static ::1:2:3:4 address suffix".
Moreover, with IPv6 I'm losing an ability to do quick checks of the network health.
> How? There is no way to associate hostnames with addresses in IPv6 that works unversally.
It looks like SLAAC and RDNSS is supported by most modern OSes, including android.
It’s definitely much more painful currently, but no reason you couldn’t have your router broadcast RDNSS. Then in your routers local DNS registry associate IP camera at ::aac::eda3::1 to ‘ip-camera-1.internal’. In theory about as easy as configuring device at Mac ‘de:fe:34:21:00’ is set to IP 10.0.0.5 and host name.
In practice granted it looks like a PITA right now. Searching google hardly yields helpful or easy tutorials on this stuff. Many home WiFi routers are pretty behind too. Though pi hole looks to have some support for this stuff.
I wish DNS options were easier or better for configuring for small networks.
IMHO IPv6 can be pretty nice but really needs saner defaults and better software support. No wonder IPv6 has taken so long.
It looks like SLAAC and RDNSS is supported by most modern OSes, including android.
It’s definitely much more painful currently, but no reason you couldn’t have your router broadcast RDNSS. Then in your routers local DNS registry associate IP camera at ::aac::eda3::1 to ‘ip-camera-1.internal’. In theory about as easy as configuring device at Mac ‘de:fe:34:21:00’ is set to IP 10.0.0.5 and host name.
In practice granted it looks like a PITA right now. Searching google hardly yields helpful or easy tutorials on this stuff. Many home WiFi routers are pretty behind too. Though pi hole looks to have some support for this stuff.
I wish DNS options were easier or better for configuring for small networks.
IMHO IPv6 can be pretty nice but really needs saner defaults and better software support. No wonder IPv6 has taken so long.
RDNSS is simply a DNS server name, it doesn't do anything for the reverse process (host-to-server registration).
> Then in your routers local DNS registry associate IP camera at ::aac::eda3::1 to ‘ip-camera-1.internal’. In theory about as easy as configuring device at Mac ‘de:fe:34:21:00’ is set to IP 10.0.0.5 and host name.
I don't see how it works. RDNSS is purely unidirectional and doesn't affect the assigned IPv6 addresses.
> Then in your routers local DNS registry associate IP camera at ::aac::eda3::1 to ‘ip-camera-1.internal’. In theory about as easy as configuring device at Mac ‘de:fe:34:21:00’ is set to IP 10.0.0.5 and host name.
I don't see how it works. RDNSS is purely unidirectional and doesn't affect the assigned IPv6 addresses.
> Now I just ping ff02::1 multicast to see what devices are on my network.
Yeah, you see a bunch of MACs and... what next? How do you get the names?
Yeah, you see a bunch of MACs and... what next? How do you get the names?
> Congrats, now these hosts can't talk to each other due to the ULA addresses being less preferred.
What do you mean by this? Are you taking about mDNS still referencing the withdrawn prefix?
What do you mean by this? Are you taking about mDNS still referencing the withdrawn prefix?
If two hosts have both mutually accessible ULA and GUA addresses, they will prefer _GUAs_ to talk to each other. So the connection will be susceptible to the prefix withdrawal if the upstream goes down (BTW, IPv6 did nothing sane for multihoming either).
> Are you taking about mDNS still referencing the withdrawn prefix?
That too.
> Are you taking about mDNS still referencing the withdrawn prefix?
That too.
Oh, interesting. My machines have not had good mDNS support, so I have been hardcoding ULAs for LAN-only traffic.
> In 2024 it’s estimated that 20 billion devices use the Internet, yet the Internet’s IPv4 routing table only encompasses 3.03 billion addresses … sharing each individual IPv4 address across an average of 7 devices.
…but the graph below that text shows 40% of traffic is IPv6, so the v4 space is only shared across 12e9 devices?
In my experience the big holdouts these days are corporate networks. All my domestic ISPs (cell, home, data centre) provide IPv6 and most devices use it by default. Meanwhile at the office we’re struggling to bring up a new internal service because our v4 IPAM is a legacy mess where the most you can calve off is a “class A” /27.
…but the graph below that text shows 40% of traffic is IPv6, so the v4 space is only shared across 12e9 devices?
In my experience the big holdouts these days are corporate networks. All my domestic ISPs (cell, home, data centre) provide IPv6 and most devices use it by default. Meanwhile at the office we’re struggling to bring up a new internal service because our v4 IPAM is a legacy mess where the most you can calve off is a “class A” /27.
The types aren’t exclusive. In the US most ISPs are dual stack. That 60/40 split pretty closely aligns with traffic stats a dual stack operator sees in their network.
FWIW, domestic ISPs in the UK are lagging on IPv6; I'm with Vrigin Media and, afaict, there is no immediate plan to deploy it either.
Last time I called Virgin media to get from the loyal customer (extra high) rate to something closer to what new customers get they just said no.
I switched to Vodafone which is cheaper and double the speed and got me IPv6. I think it might just be Virgin sitting on a large amount of IPv4 addresses and not wanting to spend any money on supporting v6 when they can just overcharge their loyal customers.
I switched to Vodafone which is cheaper and double the speed and got me IPv6. I think it might just be Virgin sitting on a large amount of IPv4 addresses and not wanting to spend any money on supporting v6 when they can just overcharge their loyal customers.
Virgin neé ntl: has always been complete trash. Are they representative of UK ISPs in general? BT and Sky completed their v6 rollout years ago and they account for over half the market.
When I was in Cambridge Virgin Media used to throttle to dial-up speeds at peak times. Meanwhile, I was still getting advertising leaflets from them through the door trying to sign new people up. Active fraud selling people a service you know you can't provide, and had no timeline to fix.
On the upside, a lot of the UK is getting small fibre companies rolling out 1G symmetric lines all over the place now. I've got that in my new place and it's been great (IPv6, CGNAT IPv4 by default but you can pay £5 for a static IPv4 too).
On the upside, a lot of the UK is getting small fibre companies rolling out 1G symmetric lines all over the place now. I've got that in my new place and it's been great (IPv6, CGNAT IPv4 by default but you can pay £5 for a static IPv4 too).
Anecdata: having switched between Vodafone, Virgin and Sky as my last three ISPs, Virgin was by far the best.
Both BT and Sky are fully IPv6, many altnets are too, it's actually Virgen Media that is the problem in the UK. In the case of Sky they are now running MAP-T and starting the transition to IPv6 only.
Germany, Vodafone. They support it, so I could get v6, but chances are that that'll switch me to CGNAT for v4, so I'm not willing to risk it.
Weird that you have to do an extra step for IPv6. Other ISPs in Germany have enabled it for every customer at some point. Unless your router asks for IPv6 addresses, nothing really changes anyway. So maybe just enable IPv6 on your router and see what happens?
On a side note, there seem to be ways to get out of CGNAT when you got condemned to use it: It is sometimes an annoying source for client VPN instabilities and from what I heard, users can just ask to be switched over from DS-Lite to classic dual stack to improve application compatibility.
On a side note, there seem to be ways to get out of CGNAT when you got condemned to use it: It is sometimes an annoying source for client VPN instabilities and from what I heard, users can just ask to be switched over from DS-Lite to classic dual stack to improve application compatibility.
No, I have to ask customer service to enable it, my EdgeRouter X supports IPv6.
Must be an old contract, all new contracts appear to be CGNAT/native IPv6 across ISPs
If the US had the same IPv4 scarcity as the rest of the world (specifically, if major US ISPs were using CGNAT), the IPv6 transition would be happening much faster.
That's probably true for consumers. For large, global corporations, IPv6 is a million miles away. I've worked with several, and they all have poorly managed kit, vulnerabilities everywhere, poor documentation/diagrams, poor performance, millions of firewall rules, tons of vendors to connect with, outsourced wireless vendors, remote access solutions that are a byzantine security mess, ... IPv6 is suicidal for most large organizations beyond ok we can speak IPv6 for a small part of the infrastructure. Add to this the recent deluge of VPNs everywhere (probably due to WireGuard) and container networking, IPv6 would be a recipe for disaster. Security is difficult in this scenario, in part due to the people implementing this stuff don't have a good handle on what they are doing.
The addresses were allocated equally geographically, and then sold. The US will hit ipv4 scarcity when the US stops being the richest country.
Prior to the establishment of the RIRs (Regional Internet Registries) the IANA handled IPv4 allocations directly and without regard for geography. During that time most of the early adopters with US government, US Universities, and US Corporations. Several US Universities and Corporations (for easy examples, GE and MIT) simply asked early enough for IP addresses and got entire /8 allocations.
Sure, when the RIRs were built they were assigned roughly equal shares of the remainder of IPv4 space, but it certainly failed to account for those early years of early adopter allocations, which did accidentally favor the US heavily.
Sure, when the RIRs were built they were assigned roughly equal shares of the remainder of IPv4 space, but it certainly failed to account for those early years of early adopter allocations, which did accidentally favor the US heavily.
The internet stopped being a network of peers where everyone needed an address and is now a split into producers (a handful of large companies) and consumers (everyone else).
The consumers are not expected to need a public address where they can be reached - in fact, having a public address is actually a security and privacy risk.
The consumers are not expected to need a public address where they can be reached - in fact, having a public address is actually a security and privacy risk.
That was in fact one of the promises of IPv6: Restore the network of peers where every host is in principle a server and a client and communication between peers is unhindered unless a policy is enforced saying otherwise (on the machine, on a firewall, etc.).
> having a public address is actually a security and privacy risk.
Services can be turned off or a firewall instructed not to pass traffic from the internet (by default). That represents exactly the same attack surface as having a service enabled and nobody being able to get to it from the internet because of NAT.
The privacy risk is mitigated by RFC4941 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6". Granted that does not deal with the (delegated) prefix staying the same and when there are only one or very few users in that prefix, some individual behavior could be inferred. Because of that at least in Germany we have the peculiar horror of getting the IPv6 address and all delegated prefixes changed on every redial. That eliminates all privacy concerns while also continuing to make residential internet connections useless for hosting any services.
Anyway. The internet is already way down the road of functioning only as the delivery conduit for a few cloud / service providers mediating all user communication and access to content.
> having a public address is actually a security and privacy risk.
Services can be turned off or a firewall instructed not to pass traffic from the internet (by default). That represents exactly the same attack surface as having a service enabled and nobody being able to get to it from the internet because of NAT.
The privacy risk is mitigated by RFC4941 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6". Granted that does not deal with the (delegated) prefix staying the same and when there are only one or very few users in that prefix, some individual behavior could be inferred. Because of that at least in Germany we have the peculiar horror of getting the IPv6 address and all delegated prefixes changed on every redial. That eliminates all privacy concerns while also continuing to make residential internet connections useless for hosting any services.
Anyway. The internet is already way down the road of functioning only as the delivery conduit for a few cloud / service providers mediating all user communication and access to content.
> in Germany we have the peculiar horror of getting the IPv6 address and all delegated prefixes changed on every redial.
This is oh so very German.
In normal times it is massively overkill. I have to wonder if, heaven forbid, the things these sort of German things are meant to mitigate come to pass again if they will make any difference or if they are a largely symbolic act designed to demonstrate ideological opposition to such things.
This is oh so very German.
In normal times it is massively overkill. I have to wonder if, heaven forbid, the things these sort of German things are meant to mitigate come to pass again if they will make any difference or if they are a largely symbolic act designed to demonstrate ideological opposition to such things.
This seem to be common. My RSP (ISP) only offers a fixed IPv6 address/prefix on request -- otherwise they will just allocate one out of their pool as they do for dynamic IPv4 (although both dynamic IPv4 and IPv6 is fairly sticky so normally DHCP/PPPoE connections will get the same address previously used as long as it hasn't been reallocated). I personally have a static IPv4 address and a static IPv4 address/prefix from my RSP for my home network.
Got the same here in Norway. I've had the same dynamic IPv4 address from my ISP since I moved here over 6 years ago. I get a new IPv6 prefix every time the line goes down, modem needs reboot, moon is full etc.
My IPv6 prefix changes several times a day with no apparent reason.
> in fact, having a public address is actually a security and privacy risk.
I strongly disagree with this. Privacy (not that it's a big deal imo) is well handled by the temporary address extension, and security is not an issue if you run a firewall. And you should be running a firewall even if you use v4, because NAT is not an acceptable security measure.
I strongly disagree with this. Privacy (not that it's a big deal imo) is well handled by the temporary address extension, and security is not an issue if you run a firewall. And you should be running a firewall even if you use v4, because NAT is not an acceptable security measure.
Whilst I agree with you, I rather depressingly suspect a lot of people equate NAT with “security”.
Only CG-NAT provides any semblance of "privacy" from the perspective of the outside world, but is a hideous technology that shouldn't exist.
Normal NAT as seen with home internet routers provides zero privacy, because you still have a predictable public IP.
People also think that IPv4+NAT provides security, but IPv4 is such a tiny address space that all public IPs are scanned daily by various malicious bots. Meanwhile IPv6 is so enormous that unless you register your address in some public way, you're completely invisible to port-scanning bots by default!
Normal NAT as seen with home internet routers provides zero privacy, because you still have a predictable public IP.
People also think that IPv4+NAT provides security, but IPv4 is such a tiny address space that all public IPs are scanned daily by various malicious bots. Meanwhile IPv6 is so enormous that unless you register your address in some public way, you're completely invisible to port-scanning bots by default!
Yeah exactly.
I have a friend who works in the networking division of a telco in my country, their team had to spend significant time and effort educating a PM who was dead-to-rights convinced that IPv6 was “less secure” and seemed to think that IPv6 didn’t have subnets and that NAT’s were the same as firewalls and refused to be convinced otherwise.
People like that make any forward progress extremely difficult.
I have a friend who works in the networking division of a telco in my country, their team had to spend significant time and effort educating a PM who was dead-to-rights convinced that IPv6 was “less secure” and seemed to think that IPv6 didn’t have subnets and that NAT’s were the same as firewalls and refused to be convinced otherwise.
People like that make any forward progress extremely difficult.
It's such a perfect example of erroneous thinking that it should be included in psychology textbooks.
"A always comes with B, hence A is required to provide B" is obviously, trivially wrong, but a truly incredible number of people will dig their heels in and refuse to admit that "B can be provided in other ways".
In this case where things went wrong was that: "Before A the availability B was rare, and A requires B, and hence B become commonplace only because of A."
You can see how the association can be accidentally upgraded to an "if and only if" instead of merely "if".
"A always comes with B, hence A is required to provide B" is obviously, trivially wrong, but a truly incredible number of people will dig their heels in and refuse to admit that "B can be provided in other ways".
In this case where things went wrong was that: "Before A the availability B was rare, and A requires B, and hence B become commonplace only because of A."
You can see how the association can be accidentally upgraded to an "if and only if" instead of merely "if".
Security - not really, but to be honest CG-NAT is kind of nice for privacy. I don't have to worry about leaking a (by default) permanent identifier. Once/if I go full ipv6, I'll probably start using a VPN full time.
Conversely, CGNAT also means that if someone in your neighbourhood decided to be a malicious actor, you will likely be affected too.
For law enforcement purposes most CGNAT operators should keep a log of who had what address at what time. You can still get blocked by websites until you get a new address, though.
The IP that you use to connect outside is separate and not permanent by default. AFAIK both Windows 11 and Linux generate a new one every day.
AFAIK it is within the same /64, which for all tracking purposes means "the same ip". The CG-NAT ip on the other hand is not even unique at any particular moment, let alone permanently. Kind of like having your own free residential VPN.
> The consumers are not expected to need a public address where they can be reached - having a public address is actually a security and privacy risk.
100% of consumer routers and OS level firewalls deny new inbound connections by default. There are upsides and downsides to static vs dynamic ISP-provided addresses, but the only difference between IPv4 and IPv6 in this regard is that IPv6 has a vastly larger address space and offers an ISP far more capacity to randomize a customer's host address for a far lower cost than IPv4. CGNAT is available for 4 or 6 if such is desired.
100% of consumer routers and OS level firewalls deny new inbound connections by default. There are upsides and downsides to static vs dynamic ISP-provided addresses, but the only difference between IPv4 and IPv6 in this regard is that IPv6 has a vastly larger address space and offers an ISP far more capacity to randomize a customer's host address for a far lower cost than IPv4. CGNAT is available for 4 or 6 if such is desired.
The original “end-to-end” architecture of the Internet assumed that every device was uniquely addressed with its own IP address [...]
That may indeed have been an assumption of the original architecture, but it's orthogonal to the end-to-end argument in Internet design, which is about moving logic out of the network entirely and into applications (more precisely, about recognizing that the boundary between network and application is productively debatable, and had, up to the point where Saltzer and Clark and Reed wrote the paper, been defaulting too much towards the network). An end-to-end-architected networking application can be oblivious to its addressing, or even the network layer below it.
If anything, my intuition is that the unreasonable effectiveness of CGNAT --- which is exactly what Huston is writing about --- is strong evidence that the end-to-end paper was deeply correct.
That may indeed have been an assumption of the original architecture, but it's orthogonal to the end-to-end argument in Internet design, which is about moving logic out of the network entirely and into applications (more precisely, about recognizing that the boundary between network and application is productively debatable, and had, up to the point where Saltzer and Clark and Reed wrote the paper, been defaulting too much towards the network). An end-to-end-architected networking application can be oblivious to its addressing, or even the network layer below it.
If anything, my intuition is that the unreasonable effectiveness of CGNAT --- which is exactly what Huston is writing about --- is strong evidence that the end-to-end paper was deeply correct.
Isn't the encoded assumption here is that clients rarely act as servers? This may be either because that's outside the typical use case or because providers explicitly do not want them to, but this factor is the reason CGNAT can be viewed as "effective."
End-user retail endpoints can still act as servers, but the way you have them to that in 2024 is different (and yes, more complicated) than it was in 1996.
I’ve often wondered if going with 64-bit addresses with a dotted quad hex notation would have eased the roll-out. I remember a lot of resistance when IPv6 was first announced along the lines of “I can’t memorize/type in giant addresses and I don’t want to have to use DHCP and DNS everywhere.” It felt like IPv6 never recovered from a bad first impression.
I'm not sure I've ever heard this view expressed by serious, competent network engineers. I have heard it a lot from the home hobbyist though, but I'm not sure how much that demographic matters in the grand scheme of things.
I also find it really weird as the killer (only?) app for IPv6 is that home hobbyists can run servers with low overhead!
Additionally, like a sibling comment notes, a home hobbyist has full control over at least half, often more, of their addresses and can easily choose addresses for their network that are as short or shorter and easier to remember and organize vs a v4 network where you have no letters to work with much more strict subnet size rules, etc.
IPv6 is a dream for home hobbyists! The complaining from them about “unmemorable” addresses just makes no sense.
Additionally, like a sibling comment notes, a home hobbyist has full control over at least half, often more, of their addresses and can easily choose addresses for their network that are as short or shorter and easier to remember and organize vs a v4 network where you have no letters to work with much more strict subnet size rules, etc.
IPv6 is a dream for home hobbyists! The complaining from them about “unmemorable” addresses just makes no sense.
> I also find it really weird as the killer (only?) app for IPv6 is that home hobbyists can run servers with low overhead!
Well, the non-trivial percentage of large orgs that have literally run out of RFC 1918 space would disagree.
But yes, you're right. There's a weird Stockholm syndrome thing some people have with NAT.
Well, the non-trivial percentage of large orgs that have literally run out of RFC 1918 space would disagree.
But yes, you're right. There's a weird Stockholm syndrome thing some people have with NAT.
Yes, companies run out of RFC 1918 addresses, but no, they will continue to use public ranges for their internal networks.
>vs a v4 network where you have no letters to work with
It'd be hard to have so many devices that even in 10.0.0.0/8, you run into a need to have letters as part of the network addresses.
My home network is larger than most and I while I use multiple subnets for fun, I could it all of it into a single /24.
It'd be hard to have so many devices that even in 10.0.0.0/8, you run into a need to have letters as part of the network addresses.
My home network is larger than most and I while I use multiple subnets for fun, I could it all of it into a single /24.
It's not weird. Many ISPs have dynamic prefixes, and even with "just" 56 bits that prefix is long and not very memorable.
Thus ULA is a must on the inside, and DynDNS is still required for anything internet facing.
Thus ULA is a must on the inside, and DynDNS is still required for anything internet facing.
A more accurate way to describe this is that IPv4 prevents anyone who isn't a hobbyist or professional from running their own server.
Serious, competent network engineers are not created in vacuum from platonic ideals and TCP fragments. They're home hobbyists who grew up hating ipv6, and won't magically learn it overnight when their previous networking guy quits and they get handed the keys to the server cage
These people are neither competent nor serious.
In the real world, people who design and operate large networks are the very same people who staffed the working groups who designed IPv6. It's their design.
In the real world, people who design and operate large networks are the very same people who staffed the working groups who designed IPv6. It's their design.
A key aspect of IPv6 is that the address space is big enough that 'carving it up' for subnets is dramatically simpler even at the largest scales. You don't need to be frugal with network sizes, and you don't need central coordination to avoid conflicts. This is huge!
E.g.: If I want to deploy a cloud VPC (or vNET), then I have to go find "the guy with the spreadsheet" and peel off a tiny(!) private IPv4 address space. If he's away from his desk or on holidays, my 1-minute automation script will now take 1-10 working days until he's back and responding to requests. With IPv6 this just disappears as a bottleneck.
E.g.: If I want to deploy a cloud VPC (or vNET), then I have to go find "the guy with the spreadsheet" and peel off a tiny(!) private IPv4 address space. If he's away from his desk or on holidays, my 1-minute automation script will now take 1-10 working days until he's back and responding to requests. With IPv6 this just disappears as a bottleneck.
"IPv6 is great and easy to use, if you're one of the leading experts who designed it"
This is not the kind of glowing endorsement you think it is, if you're expecting your technology to see widespread adoption
This is not the kind of glowing endorsement you think it is, if you're expecting your technology to see widespread adoption
Half the US has already deployed it and 100% of the mobile carriers. I would say the detractors who continue to stomp their feet about not deploying IPv6 are holding a fake title of "Network Engineer". People need to grow up and do their job or get out.
The vast majority of ip4 only networks are enterprise, that’s where I hear the complaints from. The people who say autoconf (dhcp etc) is bad and that dns is bad.
Couldn't anyone in that position use 2xxx:yyyy:zzzz:ww::1, 2xxx:yyyy:zzzz:ww::2, etc. and get the same effect?
When AWS started charging for IPv4 addresses I started switching to IPv6. I spent a few days getting it all up and running. I thought it was OK but my router kept crashing every day, then I noticed I can't get working from some places like my office. Gave up, never again its just not worth it. I moved to another hosting service that didn't charge.
Is it possible that the problems came about because you were running dual networks and not IPv6-only?
> Gave up, never again its just not worth it.
Maybe when you upgrade your router to one that cares about IPv6 it will work. Never say never. Also...
> I moved to another hosting service that didn't charge.
That's not going to last. The price of having an IPv4 address must go up over time since demand will continue to increase and it will (already is at some places such as Hetzner and other managed hosts) cost more than IPv6 which is usually a free address.
> Gave up, never again its just not worth it.
Maybe when you upgrade your router to one that cares about IPv6 it will work. Never say never. Also...
> I moved to another hosting service that didn't charge.
That's not going to last. The price of having an IPv4 address must go up over time since demand will continue to increase and it will (already is at some places such as Hetzner and other managed hosts) cost more than IPv6 which is usually a free address.
Asus routers still ship with IPv6 disabled by default, to this day. It makes perfect business sense, as everything still works just as well with v4 but single stack is less complexity so less support costs, etc. I’ve been running my home LAN dual stack for close to a decade, so I have native v6, but then on the other hand I ignore it for my networking stuff, ie I only set an A record in my dynamic DNS and never bothered figuring out how to make phoning home from other networks work over v6. It’s just not a priority and my lack of deep v6 knowledge would make it likely less secure.
I've mentioned this previously. Without government-mandated standards, implementation could take years. We apply this approach to numerous areas; why should IP be an exception?
While legislation would be way to actually make IPv6 transition happen, what is the justification for such legislation and cost it would impose on the industry?
And that is the point of this article, for most participants of the internet the benefits don’t presently justify the involved cost.
Peer to peer networking is important to rare users like me so I can do things like host a private Minecraft server from my house for my brothers and I to play on, but this is not yet a problem for me on IPv4.
Interestingly a few years back while I was moving and had no internet for a few weeks I temporarily moved the Minecraft server to my brother’s house and we discovered he was on CG NAT which was a total nonissue before then.
I sent an email to the ISP saying we wanted to expose a port and asked how to do so and they changed my brother’s account to be given a public IP no questions asked or extra costs. And I found this policy okay because probably 99.999% of internet users don’t do anything over the internet where a public IP would make any difference to their life.
I expect once enough of the internet is on IPv6 the cost benefit pendulum will swing the other way, but we're not there yet and it’s not clear when it might happpen.
And that is the point of this article, for most participants of the internet the benefits don’t presently justify the involved cost.
Peer to peer networking is important to rare users like me so I can do things like host a private Minecraft server from my house for my brothers and I to play on, but this is not yet a problem for me on IPv4.
Interestingly a few years back while I was moving and had no internet for a few weeks I temporarily moved the Minecraft server to my brother’s house and we discovered he was on CG NAT which was a total nonissue before then.
I sent an email to the ISP saying we wanted to expose a port and asked how to do so and they changed my brother’s account to be given a public IP no questions asked or extra costs. And I found this policy okay because probably 99.999% of internet users don’t do anything over the internet where a public IP would make any difference to their life.
I expect once enough of the internet is on IPv6 the cost benefit pendulum will swing the other way, but we're not there yet and it’s not clear when it might happpen.
There's plenty of justification around the value of IPv6, but it will be lost on most users. But the same scenario has played out before where things that folks don't understand were enforced, like leaded to unleaded gasoline or removing CFCs.
Fastest way to get IPv6 going in the US is to mandate all government usage be IPv6 only by 20XX. Any supplier or vendor must work over IPv6. You'll see the industry fall in line very quickly, no one wants government money to be shut off.
Fastest way to get IPv6 going in the US is to mandate all government usage be IPv6 only by 20XX. Any supplier or vendor must work over IPv6. You'll see the industry fall in line very quickly, no one wants government money to be shut off.
>Peer to peer networking is important to rare users like me so I can do things like host a private Minecraft server from my house for my brothers and I to play on, but this is not yet a problem for me on IPv4.
It's a problem for me now on IPV4
It's a problem for me now on IPV4
Static IP here in Australia costs AUD 5 per month for residential users… I think it’s just a price signal to entirely disincentivise it to anyone who doesn’t need it.
In the US, if you want a static IP you often need to purchase a business connection, which is usually significantly more expensive (and residential connections are already expensive), and may not even be available if you live in a residential area.
IIRC, when talking to our (USA) ISP, we need to upgrade to a business plan before we can then pay an extra fee per month for the static IP.
A world of being told what to do was not the "dream" of freedom for the internet.
If you want the government to mandate standards, vote with your feet and move to China where it has been mandated.
I thought the point of the article is that perhaps IPv6 is ultimately unnecessary: worse is better?
Why are we engineers so attracted to authoritarianism? The idea of just telling everyone to use the new version seems attractive to me too. Then again I often deeply admire practical engineering compromises. (edited: clarified)
If you want the government to mandate standards, vote with your feet and move to China where it has been mandated.
I thought the point of the article is that perhaps IPv6 is ultimately unnecessary: worse is better?
Why are we engineers so attracted to authoritarianism? The idea of just telling everyone to use the new version seems attractive to me too. Then again I often deeply admire practical engineering compromises. (edited: clarified)
The government has more levers to pull than just a mandate requiring adoption.
For example:
- require support for ipv6 in order to qualify for government grants to ISPs to build or expand
- Require ipv6 support from any SaaS sold to the government
- require government websites to be served on ipv6, possibly exclusively on ipv6 by a certain deadline, although that might be too aggressive.
- grant tax exemptions on costs to upgrade equipment to support ipv6
- levy a tax on ipv4
None of those removes your freedom to use ipv4, they just provide incentives to use ipv6.
For example:
- require support for ipv6 in order to qualify for government grants to ISPs to build or expand
- Require ipv6 support from any SaaS sold to the government
- require government websites to be served on ipv6, possibly exclusively on ipv6 by a certain deadline, although that might be too aggressive.
- grant tax exemptions on costs to upgrade equipment to support ipv6
- levy a tax on ipv4
None of those removes your freedom to use ipv4, they just provide incentives to use ipv6.
Pick up the benefits of ending IPv4 development sooner.
One less thing to ship with every bit of network software.
One less learning outcome taught in every networking course.
One less piece of organisational complexity in every ISP.
Fewer rent seekers in the IP address space.
But these benefits are network effects and we only achieve them once IPv4 is relegated to the archaics of the internet tech stack.
One less thing to ship with every bit of network software.
One less learning outcome taught in every networking course.
One less piece of organisational complexity in every ISP.
Fewer rent seekers in the IP address space.
But these benefits are network effects and we only achieve them once IPv4 is relegated to the archaics of the internet tech stack.
Agreeing on a common standard is not authoritarianism.
You said "government-mandated" - do you think your words matter?
That doesn't sound like agreement.
Agreement is how we have arrived at the imperfect solution we have now... Agreement between various technical and non-technical parties.
That doesn't sound like agreement.
Agreement is how we have arrived at the imperfect solution we have now... Agreement between various technical and non-technical parties.
Conversely, blindly categorizing all government mandation as authoritarianism sounds like a highway to all kinds of logical fallacies! Is mandating a fair market (by e.g. punishing monopolies) authoritarian? A sensible person would answer no.
Similarly, mandating an Internet Protocol that doesn't require centralization (you know, NAT) and renting an address from the Big Boys (AWS etc) sounds like a perfectly sensible decision to me.
> Agreement is how we have arrived at the imperfect solution we have now...
I disagree. What we have now is not an explicit agreement, it's a status quo which can be broken by an external force.
Similarly, mandating an Internet Protocol that doesn't require centralization (you know, NAT) and renting an address from the Big Boys (AWS etc) sounds like a perfectly sensible decision to me.
> Agreement is how we have arrived at the imperfect solution we have now...
I disagree. What we have now is not an explicit agreement, it's a status quo which can be broken by an external force.
A sentence written by a pedant that doesn't help communicate.
Followed by another sentence.
Ending with a quote that implies a worldview that the government should use violence without any balance "it's a status quo broken by an external force".
Followed by another sentence.
Ending with a quote that implies a worldview that the government should use violence without any balance "it's a status quo broken by an external force".
I don't think you understand what "pedant" means.
We have agreed on a common standard. It’s IPv6.
Forcing people to use it is authoritarianism.
Forcing people to use it is authoritarianism.
You are also forced to use a seat belt. Calling it authoritarianism when we want to enforce a standard is absurd.
Seat belts have a reason. If I want to communicate with some computers using IPv4 or IPX, that’s my choice. Putting laws on what I can put inside of Ethernet is absolute stupidity
I fail to see how mandating ISPs to implement and use IPv6 is equivalent to "putting laws on what you can put inside of Ethernet"
Maybe don’t talk about stuff you don’t have any experience with then. Many ISP products are carrying Ethernet frames (metro Ethernet, the fabric at an exchange) or are even just leasing fiber.
In order to force IPv6 and ensure nobody is using IPv4, you absolutely are putting laws on what goes over those Ethernet frames.
In order to force IPv6 and ensure nobody is using IPv4, you absolutely are putting laws on what goes over those Ethernet frames.
Presumably the proposed law is about normal Internet service. If you have Internet then you have IP6. If you don't then what you have isn't Internet. If your company cannot provide IP6 then you are not an internet service provider because you do not provide Internet service.
Why do people immediately assume that any possible regulation will be the stupidest possible regulation? Corporate brainwashing?
Why do people immediately assume that any possible regulation will be the stupidest possible regulation? Corporate brainwashing?
Being forced to use a seat belt isn't a standard, it's actually authoritarianism. And largely used as a pretense to pull people over without probable cause, rather than for any other purpose. Mandating that manufacturers have seatbelts in cars is the regulation of commerce. Mandating that ISPs provide ip6 is also the regulation of commerce. Ip6 itself is a standard.
A standard is something that people have to adhere to in order to measure things in a portable way, or for general interop. It's not anything that one is told to do by a government.
A standard is something that people have to adhere to in order to measure things in a portable way, or for general interop. It's not anything that one is told to do by a government.
This seems like an extremely broad statement. You probably don't think all use of force is authoritarian, or not allowing any and all protocols to be used on the internet is force. Maybe, but not necessarily. Why specifically would retiring IPv4 be authoritarianism?
Governments _mandating_ it sure is.
As far as I know, the US federal government does have a mandate that agencies be ipv6-only by end of 2025. Systems that are not converted by then require justification for why they cannot do so along with a replacement plan. See https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-0...
The DoD mandated v6 a few years back. The US government could easily dictate that all of their supplied software had to support it.
I suspect that (nearly) all of the supplied software already supports it. Software support for ipv6 is nearly ubiquitous; configuration for ipv6 is the holdup.
IPv6 adoption will take place overnight when either google chrome, Android or iOS start showing a warning on IPv4-only networks. ISPs and tech companies will start to get flooded with support calls asking about it and will choose to roll out IPv6 to make the problem go away.
Chrome forced the web to go 100% https, the same thing will happen eventually with IPv6.
I have IPv6 disabled on my computer because it solves many mysterious service interruptions. Comcast claims to support it, but there have been many times when IPv6 was dog slow and IPv4 was very fast.
Comcast used to issue me an IPv6 block but silently stopped at some point. Others reported the same problem. Thankfully everything I use still supports IPv4 so I didn't notice until I went looking.
One day it'll be worth my time to figure out the problem, but I predict that day is far in the future.
One day it'll be worth my time to figure out the problem, but I predict that day is far in the future.
The premise is completely wrong here. IPv6 is not just an “incremental change” that would have represented an easy uptake. Instead, pretty much every practical detail of existing IPv4 infrastructure, both hardware and software, was broken. Massive swaths of extra management and security tools were rendered useless. It was a massive miscalculation.
In the meantime, we figured out how to make things work without the extra address space. And the dream of a point-to-point Internet turned out to be a terrible idea after all. IPv6 pushers love to hate on NAT, but it’s actually a really good design choice that’s fundamental to basic network security.
In the meantime, we figured out how to make things work without the extra address space. And the dream of a point-to-point Internet turned out to be a terrible idea after all. IPv6 pushers love to hate on NAT, but it’s actually a really good design choice that’s fundamental to basic network security.
NAT doesn't ever provide security, only pretending to.
I’ve seen this sentiment repeated over and over in this thread without a single explanation.
Please explain how NAT on IPv4, as used in practice, does not increase security vs connecting machines each directly to a publicly accessible Internet address?
I’m having a hard time understanding how this statement can possible be true.
Please explain how NAT on IPv4, as used in practice, does not increase security vs connecting machines each directly to a publicly accessible Internet address?
I’m having a hard time understanding how this statement can possible be true.
Here is the very simple but practical explanation why: https://0day.work/an-example-why-nat-is-not-security/
And more high-level explanation as well: https://www.f5.com/resources/white-papers/the-myth-of-networ...
And more high-level explanation as well: https://www.f5.com/resources/white-papers/the-myth-of-networ...
That's bullshit.
"Security" is not a binary switch. NAT is a useful tool in your security toolbox when you want a more nuanced take than either "ban all ports" or "let every port flap open on the internets, #yolo".
NAT is useless for that. Firewalls are the tool for blocking connections.
Why is there a difference in captcha exposure between IPv4 and IPv6 then? Maybe there is no actual security, but the people deploying these captchas seem to think there is a need to deploy them for IPv6 users.
All big German internet providers (DTAG, Telefonica, 1&1, Vodafone) are IPv6 Dual Stack or CGNAT'ed for many many years now. Same for all mobile providers.
So everybody is using IPv6 in their home networks without problems.
So everybody is using IPv6 in their home networks without problems.
Our local German teledata internet provider uses CGNAT, and it is a mess of random timeouts.
I could see that that's how IPv6 adoption happens.
ISPs realize that selling their old squatted IPv4s to Amazon/Google/Azure more than pays for the transition to IPv6 + CGNAT with a tidy profit on the side.
Then to save more money, they cheap out on the CGNAT so that IPv4 connections have poor performance.
Customers complain to the slow websites (since google/cloudflare sites all load quickly, it must be the site's fault) and they have to adopt IPv6 for that reason.
ISPs realize that selling their old squatted IPv4s to Amazon/Google/Azure more than pays for the transition to IPv6 + CGNAT with a tidy profit on the side.
Then to save more money, they cheap out on the CGNAT so that IPv4 connections have poor performance.
Customers complain to the slow websites (since google/cloudflare sites all load quickly, it must be the site's fault) and they have to adopt IPv6 for that reason.
Legacy account on Vodafone (from Kabel Deutschland days), no v6, no CGNAT.
Vodafone refused to enable dual stack on my DSL connection. I got to pick from either keeping dual stack with CGNAT or completely disabling IPv6 but get a reachable IPv4.
My mobile provider doesn't allow IPv6 connections.
So ironically, to be reachable from everywhere, I had to turn off IPv6.
My mobile provider doesn't allow IPv6 connections.
So ironically, to be reachable from everywhere, I had to turn off IPv6.
> The design of IPv6 was intentionally very conservative. To a first level of approximation IPv6 is simply “IPv4 with bigger addresses”.
I don't agree with this take. I think it's actually quite a bit more complex, and this is a large part of the reason adoption has been slow. In retrospect, I think it would have been better off in practice to just literally extend the size of IPv4 addresses, and make it as simple as converting all IPv4 systems to hold a larger address.
I don't agree with this take. I think it's actually quite a bit more complex, and this is a large part of the reason adoption has been slow. In retrospect, I think it would have been better off in practice to just literally extend the size of IPv4 addresses, and make it as simple as converting all IPv4 systems to hold a larger address.
I feel like the hard part there is actually accessing all the IPv4 systems to change how they handle addresses. I don't know the full scope of difference, but I feel like once you can do a software update to all of your devices, the cost of increased complexity in protocol would be relatively constant between a minimal and actual v6. You are just pushing different data through the update.
I think the article's diagnosis is spot on.
The urgency of IPv6 adoption was predicated on the assumption that every connected device, both server and client, needs a unique and stable IP address. Back when IPv6 was first discussed, you couldn't even host two HTTPS sites on the same IP/port combination! That was such a colossal waste of IP addresses.
Another thing that changed on the server side was that, thanks to AWS and the like, it became trivial to set up a massive private network. Nowadays you can have a cluster of thousands of virtual machines that communicate with one another entirely within a VPC. Only machines that need to communicate with external entities get a public IPv4 address. This kind of setup not only frees up a /20, but also has the benefit of being more secure.
Meanwhile, on the client side, the rise of mobile internet means that devices can no longer assume that it will have any given address for any length of time. Even if we had plenty of addresses to go around, like with IPv6, what can we do when the device moves across the country? It's easier to assign a new address than to try to route the old address to an entirely different ISP. Reducing the complexity of the routing table was one of the goals of IPv6, after all. Insisting on a unique and stable IP address for each mobile device would defeat that purpose.
As a result, most new applications are being built with the assumption that the IP address doesn't matter. You rent a few ports on someone else's IP for a few minutes to fire off a bunch of requests, just like you'd rent CPU cycles on someone else's machine to run some functions.
The urgency of IPv6 adoption was predicated on the assumption that every connected device, both server and client, needs a unique and stable IP address. Back when IPv6 was first discussed, you couldn't even host two HTTPS sites on the same IP/port combination! That was such a colossal waste of IP addresses.
Another thing that changed on the server side was that, thanks to AWS and the like, it became trivial to set up a massive private network. Nowadays you can have a cluster of thousands of virtual machines that communicate with one another entirely within a VPC. Only machines that need to communicate with external entities get a public IPv4 address. This kind of setup not only frees up a /20, but also has the benefit of being more secure.
Meanwhile, on the client side, the rise of mobile internet means that devices can no longer assume that it will have any given address for any length of time. Even if we had plenty of addresses to go around, like with IPv6, what can we do when the device moves across the country? It's easier to assign a new address than to try to route the old address to an entirely different ISP. Reducing the complexity of the routing table was one of the goals of IPv6, after all. Insisting on a unique and stable IP address for each mobile device would defeat that purpose.
As a result, most new applications are being built with the assumption that the IP address doesn't matter. You rent a few ports on someone else's IP for a few minutes to fire off a bunch of requests, just like you'd rent CPU cycles on someone else's machine to run some functions.
> Another thing that changed on the server side was that, thanks to AWS and the like, it became trivial to set up a massive private network. Nowadays you can have a cluster of thousands of virtual machines that communicate with one another entirely within a VPC. Only machines that need to communicate with external entities get a public IPv4 address. This kind of setup not only frees up a /20, but also has the benefit of being more secure.
This is something that people who are too deep in the weeds of legacy networking don't realize. The future is to not use IP at all within enterprise and not use the Internet at all for B2B communication. In fact the future is to not use any networking abstraction at the application layer.
To start with every device can be in VPCs with the same private /16 because they can easily communicate securely within the cloud environment via services like VPC lattice or using S3/API gateway both within and across companies. Let the cloud provider handle the undifferentiated heavy lifting of figuring out how to get data from one device to another. In time third parties will establish cross provider bridges.
Then you can start to ask yourself why your applications need the "networking" abstraction at all. If you want to send some bits to an application either within or across companies it should be just a matter of putting the bits in some location the receiving application has access to and the cloud providers can figure out how to actually make the bits accessible to the other application. Think writing to an S3 bucket using a VPC endpoint but with less HTTP/TCP/IP cruft in the middle.
As a benefit the identities on both sides will be established by the cloud providers so you don't need to worry your devices are reachable by malicious actors. Then you can start to get rid of all this cyber security nonsense that has grown up around the ridiculously insecure protocols that were developed in the 70s for connecting trusted machines and somehow are still in use today.
Internet service providers and cloud providers may or may not use IPv6 but enterprises, schools, and end users certainly won't need to.
This is something that people who are too deep in the weeds of legacy networking don't realize. The future is to not use IP at all within enterprise and not use the Internet at all for B2B communication. In fact the future is to not use any networking abstraction at the application layer.
To start with every device can be in VPCs with the same private /16 because they can easily communicate securely within the cloud environment via services like VPC lattice or using S3/API gateway both within and across companies. Let the cloud provider handle the undifferentiated heavy lifting of figuring out how to get data from one device to another. In time third parties will establish cross provider bridges.
Then you can start to ask yourself why your applications need the "networking" abstraction at all. If you want to send some bits to an application either within or across companies it should be just a matter of putting the bits in some location the receiving application has access to and the cloud providers can figure out how to actually make the bits accessible to the other application. Think writing to an S3 bucket using a VPC endpoint but with less HTTP/TCP/IP cruft in the middle.
As a benefit the identities on both sides will be established by the cloud providers so you don't need to worry your devices are reachable by malicious actors. Then you can start to get rid of all this cyber security nonsense that has grown up around the ridiculously insecure protocols that were developed in the 70s for connecting trusted machines and somehow are still in use today.
Internet service providers and cloud providers may or may not use IPv6 but enterprises, schools, and end users certainly won't need to.
IPv6 had this cool idea that each subscriber would get a /64, and devices within the subscriber's network would be assigned /128s with the last 64 bits matching their MAC addresses.
Except it turns out that most organizations see no need to give internal devices globally routable IP addresses, much less expose their MAC addresses. If anything, it's a vulnerability, not a feature.
On the other hand, going too far along with your idea would look like a dystopian future where everyone is corralled into one corporate walled garden or another. So it's understandable that there's a strong gut reaction against it. Fortunately, there are enough IPv4 addresses to support both corporate walled gardens and a reasonable number of independent operators.
Except it turns out that most organizations see no need to give internal devices globally routable IP addresses, much less expose their MAC addresses. If anything, it's a vulnerability, not a feature.
On the other hand, going too far along with your idea would look like a dystopian future where everyone is corralled into one corporate walled garden or another. So it's understandable that there's a strong gut reaction against it. Fortunately, there are enough IPv4 addresses to support both corporate walled gardens and a reasonable number of independent operators.
it is unfortunate that tcp and ip are as interlocked as they are, by which I mean, there is no way to keep your tcp connection while swapping out the underlying ip addresses.
This is not actually a real problem, we do just fine without it, it can be solved at higher or lower layers. But it would have been nice to have.
This is not actually a real problem, we do just fine without it, it can be solved at higher or lower layers. But it would have been nice to have.
> it is unfortunate that tcp and ip are as interlocked as they are, by which I mean, there is no way to keep your tcp connection while swapping out the underlying ip addresses.
Multipath/homing, with different IP addresses, exists with TCP and SCTP:
* https://en.wikipedia.org/wiki/Multipath_TCP
* https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
Multipath/homing, with different IP addresses, exists with TCP and SCTP:
* https://en.wikipedia.org/wiki/Multipath_TCP
* https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
MPTCP addresses this, Apple uses it (or used it, I haven't looked in a long time), and there's some way to enable it for applications on their OSes, but you also need to make it work on a server OS... I don't think it's been merged into anything but patches are around.
Yeah, it would have been nice to have, but that's all. Instead of requiring IPv6, the internet has evolved in a direction that tolerates disconnects and reduces its own IPv4 address consumption. It will probably work fine for the next 20 years at least.
In the 19th century, New Yorkers worried that the city would soon be buried in horse shit because of increasing demand for transportation. The horse shit apocalypse never materialized, because transportation evolved in a way that stopped relying on horses. Now we have a different problem, of course.
In the 19th century, New Yorkers worried that the city would soon be buried in horse shit because of increasing demand for transportation. The horse shit apocalypse never materialized, because transportation evolved in a way that stopped relying on horses. Now we have a different problem, of course.
Exactly this… which raises the question- do we need ipv6 at all?
> This is the same as looking at a linear trend line placed over the data series used in Figure 1, looking for the date when this trend line reaches 100%. Using a least-squares best fit for this data set from January 2020 to the present day, and using a linear trend line, we can come up with Figure 2.
> This exercise predicts that we’ll see completion of this transition in late 2045, or some 20 years into the future.
Anyone willing to place a bet on this?
> While the design of IPv6 consumed a lot of attention at the time, the concept of transition of the network from IPv4 to IPv6 did not.
> Given the runaway adoption of IPv4, there was a naive expectation that IPv6 would similarly just take off, and there was no need to give the transition much thought. In the first phase, we would expect to see applications, hosts and networks adding support for IPv6 in addition to IPv4, transforming the internet into a dual stack environment. In the second phase we could then phase out support for IPv4.
I really don't understand this, how do you not make a transition plan the #1 requirement for selecting the next IP. (But the article goes on to say...)
> This exercise predicts that we’ll see completion of this transition in late 2045, or some 20 years into the future.
Anyone willing to place a bet on this?
> While the design of IPv6 consumed a lot of attention at the time, the concept of transition of the network from IPv4 to IPv6 did not.
> Given the runaway adoption of IPv4, there was a naive expectation that IPv6 would similarly just take off, and there was no need to give the transition much thought. In the first phase, we would expect to see applications, hosts and networks adding support for IPv6 in addition to IPv4, transforming the internet into a dual stack environment. In the second phase we could then phase out support for IPv4.
I really don't understand this, how do you not make a transition plan the #1 requirement for selecting the next IP. (But the article goes on to say...)
> Anyone willing to place a bet on this?
Ill bet against it. The tail on this one is going to be super long.
There are embedded systems today that are shipping in things expected to last 30 years with IPv4 only.
The logistics of the bet are going to be hard. I do see a world where IPv6-only becomes the default for ISPs and IPv4 becomes an add-on you pay for either from your ISP or from another via a tunnel. Does that world mean v4 is dead yet?
Ill bet against it. The tail on this one is going to be super long.
There are embedded systems today that are shipping in things expected to last 30 years with IPv4 only.
The logistics of the bet are going to be hard. I do see a world where IPv6-only becomes the default for ISPs and IPv4 becomes an add-on you pay for either from your ISP or from another via a tunnel. Does that world mean v4 is dead yet?
The long tail doesn't matter. Once IPv4 traffic is a small fraction, the big transit providers will make it cost too much to bother with, and their customers (retail ISPs) will just cut it.
Only global IPv4 matters. If in fifty years there's still a device that insists on speaking IPv4 with the address 10.20.30.40 that will still work and it still won't matter to the Internet any more than it does now.
The appropriate comparison is leaded gasoline.
In my country this was never formally banned. You can't buy a new car which consumes it of course, they banned that, but the fuel itself is legal and for a while enthusiasts would travel to a retailer which still sold it, there might be one in the next town, or the next. Of course with fewer customers the price went up, further reducing customers and squeezing more retailers out, soon enough you might have an hour's drive to buy fuel. The wholesalers were next, if you sell a tanker of ordinary unleaded every five minutes, and a tanker of "high performance" unleaded every hour, why bother making the leaded fuel that shifts only one tanker per week across the whole market? It's not even worth reconfiguring your mixers to make it. So you mark it "No longer available" and gradually across the market the retailers can't buy more and there is no more leaded gasoline.
You can make your own leaded gasoline, but the volumes involved mean it no longer makes any meaningful difference, you could make your own lead paint too, if you're crazy, it doesn't make a noticeable difference to the world.
Only global IPv4 matters. If in fifty years there's still a device that insists on speaking IPv4 with the address 10.20.30.40 that will still work and it still won't matter to the Internet any more than it does now.
The appropriate comparison is leaded gasoline.
In my country this was never formally banned. You can't buy a new car which consumes it of course, they banned that, but the fuel itself is legal and for a while enthusiasts would travel to a retailer which still sold it, there might be one in the next town, or the next. Of course with fewer customers the price went up, further reducing customers and squeezing more retailers out, soon enough you might have an hour's drive to buy fuel. The wholesalers were next, if you sell a tanker of ordinary unleaded every five minutes, and a tanker of "high performance" unleaded every hour, why bother making the leaded fuel that shifts only one tanker per week across the whole market? It's not even worth reconfiguring your mixers to make it. So you mark it "No longer available" and gradually across the market the retailers can't buy more and there is no more leaded gasoline.
You can make your own leaded gasoline, but the volumes involved mean it no longer makes any meaningful difference, you could make your own lead paint too, if you're crazy, it doesn't make a noticeable difference to the world.
> The long tail doesn't matter.
We’re talking about the logistics of a bet, it’s the only thing that matters in this context.
The big transit providers pay very little to carry ipv4 prefixes. They will never even consider cutting it as long as there are any semi large content providers offering v4. Transit cores are prefix-free with segment routing so the cost is basically just the device that peers at the exchanges with other peers.
> The appropriate comparison is leaded gasoline.
It is not. The price dynamics make it so cheap to keep supporting ipv4 that it’s nothing like the unleaded switch. That’s before you even consider how dumb “banning the sale of new IPv4 devices” is.
We’re talking about the logistics of a bet, it’s the only thing that matters in this context.
The big transit providers pay very little to carry ipv4 prefixes. They will never even consider cutting it as long as there are any semi large content providers offering v4. Transit cores are prefix-free with segment routing so the cost is basically just the device that peers at the exchanges with other peers.
> The appropriate comparison is leaded gasoline.
It is not. The price dynamics make it so cheap to keep supporting ipv4 that it’s nothing like the unleaded switch. That’s before you even consider how dumb “banning the sale of new IPv4 devices” is.
> I really don't understand this, how do you not make a transition plan the #1 requirement for selecting the next IP.
To some extent, Postel's Law suggests the only viable transition plan for the internet is "no transition plan"; expect both to continue to exist as long as they both need to and do your best not to break things or step on each other's toes.
Relatedly, a slow "dual stack" IPv4 to IPv6 transition is as much validation for Postel's Law, and that is has been applied to a useful extreme, as anything else: traffic shifts as traffic needs to shift; the internet not only survives, it thrives; most users don't notice nor care.
To some extent, Postel's Law suggests the only viable transition plan for the internet is "no transition plan"; expect both to continue to exist as long as they both need to and do your best not to break things or step on each other's toes.
Relatedly, a slow "dual stack" IPv4 to IPv6 transition is as much validation for Postel's Law, and that is has been applied to a useful extreme, as anything else: traffic shifts as traffic needs to shift; the internet not only survives, it thrives; most users don't notice nor care.
This may be a random question, but do any of you have a working code (preferably C or Lua, without regexes but with regexes works too) for: 1) checking if a given string is a valid IPv6 address, and 2) checking if this IPv6 address is in the range? It should handle both IPv4 and IPv6. It must handle edge cases (number of chunks being 8, numbers must be less than 65535 if I am correct, then there is some stuff regarding ":::", etc.). There seemed to be too many edge cases, but maybe I was wrong.
The range check should be in the form of "isIPInRange(ip, cidr)", e.g. isIPInRange("192.168.0.255", "192.168.0.0/24").
It is trivial for IPv4, but not so trivial for IPv6.
If you are wondering why I am not asking LLM this, that is because when (at the time) I did attempt, it failed spectacularly, plus hey, it is HN, someone may find it useful and the more eyes the better anyways (to spot bugs, issues, what have you).
The range check should be in the form of "isIPInRange(ip, cidr)", e.g. isIPInRange("192.168.0.255", "192.168.0.0/24").
It is trivial for IPv4, but not so trivial for IPv6.
If you are wondering why I am not asking LLM this, that is because when (at the time) I did attempt, it failed spectacularly, plus hey, it is HN, someone may find it useful and the more eyes the better anyways (to spot bugs, issues, what have you).
You probably just shouldn't try to do string matching here and just use one of the conversion function to get them to binary, apply the mask, and see if they match
IPv4 has problems with the non-standard formats that use octal or combine octets. Like 192.168.1 is 192.168.0.1, 127.0.0.1 is 127.1.
My ISP is only couple years old. And yet, surprisingly to me, they don't support IPv6, only ipv4.
For my entire life, the networking nerds have been shaming us for not using IPv6. Back when I had a NeoPet in middle school, IPv6 was was "just around the corner." I'm now raising my own children and still listening to the same IPv6 talking points.
Every company I've ever worked for has completely disabled IPv6 on the corporate network. My own ISP still doesn't offer it. Disabling it is often the quickest fix for a variety of networking issues.
At some point we must admit failure. There is no conspiracy to limit IPv6 adoption. If the technology was truly useful, you'd see far more in our profession advocate for it.
Every company I've ever worked for has completely disabled IPv6 on the corporate network. My own ISP still doesn't offer it. Disabling it is often the quickest fix for a variety of networking issues.
At some point we must admit failure. There is no conspiracy to limit IPv6 adoption. If the technology was truly useful, you'd see far more in our profession advocate for it.
> Disabling it is often the quickest fix for a variety of networking issues.
In a way, you disabling it now is the reason why others are disabling it later. A lot of IPv6 deployment issues are precisely caused by middleboxes/clients disabling or misconfiguring it.
In a way, you disabling it now is the reason why others are disabling it later. A lot of IPv6 deployment issues are precisely caused by middleboxes/clients disabling or misconfiguring it.
Yes, and?
Don't make excuses for shitty technology. The mental model of what the "future Internet" (aka the one we're using now) would look like is completely insane in IPv6.
I am saying a lot of "IPv6 issues" are not because of the protocol itself, but rather it is self-inflicted pain.
You quickly assuming IPv6 is a "shitty technology" means that you are part of the problem. Congratulations, you just proved my point.
>the one we're using now
The one we are using now is held by a bandaid. It's insane that, for me to connect to other computer, I need a middleman (STUN or other coordination services) to help me with it.
You quickly assuming IPv6 is a "shitty technology" means that you are part of the problem. Congratulations, you just proved my point.
>the one we're using now
The one we are using now is held by a bandaid. It's insane that, for me to connect to other computer, I need a middleman (STUN or other coordination services) to help me with it.
> It's insane that, for me to connect to other computer, I need a middleman
It's not insane, it's the default and correct assumption. I certainly don't want random computers connecting to mine just because they want to.
STUN is a shitty solution to this problem, but IPv6 doesn't provide any solution at all, so a shitty solution wins here. Sorry.
It's not insane, it's the default and correct assumption. I certainly don't want random computers connecting to mine just because they want to.
STUN is a shitty solution to this problem, but IPv6 doesn't provide any solution at all, so a shitty solution wins here. Sorry.
> IPv6 doesn't provide any solution at all
1. Reject the IPv6 solution
2. Say IPv6 doesn't have a solution
3. ???
4. Profit
Sigh.
1. Reject the IPv6 solution
2. Say IPv6 doesn't have a solution
3. ???
4. Profit
Sigh.
My ISP has given me a quite stable /64 network that's lasted for months and months.
I am curious though: my IPv6 network begins with 2600::, which I feel is not an accident or mere coincidence. For a long time, Facebook would never "trust" my device, and I suspected it was because of the IPv6 thing.
Now, "2600" is actually a hex number and doesn't mean 2600 decimal, but 2600 is an interesting prefix for a stable address. Could it mean that my ISP has permanently branded me as some sort of "hacker", and "2600" is network admin code for "please don't trust these devices"?
We should compare notes and see if other HN users have come up with stable prefixes like this, or different prefixes that aren't "2600".
I am curious though: my IPv6 network begins with 2600::, which I feel is not an accident or mere coincidence. For a long time, Facebook would never "trust" my device, and I suspected it was because of the IPv6 thing.
Now, "2600" is actually a hex number and doesn't mean 2600 decimal, but 2600 is an interesting prefix for a stable address. Could it mean that my ISP has permanently branded me as some sort of "hacker", and "2600" is network admin code for "please don't trust these devices"?
We should compare notes and see if other HN users have come up with stable prefixes like this, or different prefixes that aren't "2600".
According to the IANA assignment list, 2600::/12 is assognrd to ARIN.
https://www.iana.org/assignments/ipv6-unicast-address-assign...
https://www.iana.org/assignments/ipv6-unicast-address-assign...
Yes, that's correct -- I'm in the USA, and not in Europe or Africa. What is your point with this? ARIN has, of course, delegated my assigned IPv6 network to my ISP; you do realize that this is SOP for ARIN?
The point was a prefix from 2600::/16 isn’t special; it’s just from one of the blocks assigned to ARIN. One ISP I know of with an allocation in that range is Verizon, which announces a number of prefixes over BGP in 2600:1000::/24
Uhm, anyone with an ISP in the United States is going to have a block delegated from ARIN. That's the whole point of ARIN, isn't it? Nothing they delegate is inherently special, because ARIN administers all of the allocations for their region.
I'm saying that perhaps the 2600::/16 delegation is especially reserved for a certain class of user in order to tag us as something. Surely, my own ISP holds more delegations than that slice alone. It's certainly standing out like a sore thumb to anyone analyzing logs. As I said, it can't be merely a coincidence.
Interestingly, I also subscribe to mobile voice/data service from the same ISP, and activating mobile data here at home gives me, sure enough, another 2600::* delegation.
I'm saying that perhaps the 2600::/16 delegation is especially reserved for a certain class of user in order to tag us as something. Surely, my own ISP holds more delegations than that slice alone. It's certainly standing out like a sore thumb to anyone analyzing logs. As I said, it can't be merely a coincidence.
Interestingly, I also subscribe to mobile voice/data service from the same ISP, and activating mobile data here at home gives me, sure enough, another 2600::* delegation.
nnnnnnn
I'd like to use ipv6, if only to avoid having to pay for an ipv4 address for some private vpcs (with public address for reasons). I remember having issues with fly.io as well, because they're ipv6 by default if I remember correctly.
Currently Denmark has worse support than I expected:
> Liste over danske udbydere (List of Danish providers)
> Internetudbydere på listen: 41 (ISPs on the list)
> Internetudbydere med fuld IPv6-understøttelse: 17 (41%) (ISPs with full IPv6)
> Internetudbydere med delvis IPv6-understøttelse: 10 (24%) (ISPs with partial IPv6)
> Internetudbydere uden IPv6-understøttelse: 14 (34%) (ISPs with no IPv6)
source: https://ipv6-adresse.dk/
Currently Denmark has worse support than I expected:
> Liste over danske udbydere (List of Danish providers)
> Internetudbydere på listen: 41 (ISPs on the list)
> Internetudbydere med fuld IPv6-understøttelse: 17 (41%) (ISPs with full IPv6)
> Internetudbydere med delvis IPv6-understøttelse: 10 (24%) (ISPs with partial IPv6)
> Internetudbydere uden IPv6-understøttelse: 14 (34%) (ISPs with no IPv6)
source: https://ipv6-adresse.dk/
I'll admit that while I run dual-stack for the public internet, I still haven't figured out a good way to manage my LAN with ipv6.
For ipv4, I have a DHCP server on the same machine as my DNSH server, which lets me configure my network in a single place. With IPv6 I'm still not sure exactly how to configure this. It seems like if I use SLAAC for a ULA, at least some hosts will still apply RFC 4941 (or maybe 8981; I'm not sure), which makes DNS unfeasible. So I guess maybe DHCPv6 is the answer (short of manually configuring each host)?
For ipv4, I have a DHCP server on the same machine as my DNSH server, which lets me configure my network in a single place. With IPv6 I'm still not sure exactly how to configure this. It seems like if I use SLAAC for a ULA, at least some hosts will still apply RFC 4941 (or maybe 8981; I'm not sure), which makes DNS unfeasible. So I guess maybe DHCPv6 is the answer (short of manually configuring each host)?
[deleted]
Most hosts will generate both a stable and a temporary address when using SLAAC. The temporary address will be used for outbound traffic but the stable address will accept incoming traffic.
So there usually is a stable ULA or link-local that you can put in a local DNS AAAA record.
The PITA is that many services prefer GUA over ULA if available and don't gradually fall back to ULA if the WAN goes down. And you will still need dynDNS to VPN into your network because ISPs are allergic to stable IPv6 prefixes.
So there usually is a stable ULA or link-local that you can put in a local DNS AAAA record.
The PITA is that many services prefer GUA over ULA if available and don't gradually fall back to ULA if the WAN goes down. And you will still need dynDNS to VPN into your network because ISPs are allergic to stable IPv6 prefixes.
As long as you have enterprise products like zscaler, that do not support IPv6. Or switches and routers that are broken in different ways with every update. Userproperties in Active Directory that are to short to insert an IPv6 address.
Why should any enterprise company move to it? Why should any enterprise (at least) double the cost by having to support two protocols when most problems can be solved by various types of NAT?
Why should any enterprise company move to it? Why should any enterprise (at least) double the cost by having to support two protocols when most problems can be solved by various types of NAT?
> As long as you have enterprise products like zscaler, that do not support IPv6
ZScaler is a burning piece of privacy-violating garbage that as a developer rather get rid of than have.
Nice for non-IT collegues who were previously protected by the corporate proxy server while working in the office, now work at home or other places, and are prone to scamming and visiting forbidden [by the employer] sites.
As a developer a system-wide MITM SSL-decrypting proxy server is a major pain in the ass. Every runtime of developer tools, python, Node, .NET, Docker, Linux (WSL) flavors, etc have their own way to trust root certificates, and as a web developer you do tend to touch a lot of different tools. Secondly, when you do a bit of devops, you can't even check basic things like checking if a website has the correct (valid) SSL certificate without RDP-ing to some server which doesn't have ZScaler installed.
Sorry for my rant. But I'm not allowed to disable ZScaler - but am forced to live with it.
ZScaler is a burning piece of privacy-violating garbage that as a developer rather get rid of than have.
Nice for non-IT collegues who were previously protected by the corporate proxy server while working in the office, now work at home or other places, and are prone to scamming and visiting forbidden [by the employer] sites.
As a developer a system-wide MITM SSL-decrypting proxy server is a major pain in the ass. Every runtime of developer tools, python, Node, .NET, Docker, Linux (WSL) flavors, etc have their own way to trust root certificates, and as a web developer you do tend to touch a lot of different tools. Secondly, when you do a bit of devops, you can't even check basic things like checking if a website has the correct (valid) SSL certificate without RDP-ing to some server which doesn't have ZScaler installed.
Sorry for my rant. But I'm not allowed to disable ZScaler - but am forced to live with it.
Fiber providers here are incapable of providing IPv6.
Frontier, Optyx, Sumo, Evolution, Intellipop, Starlight, Legacy, Yandoo, Voonami, Infinity all serve this area. Zero have IPv6.
Frontier, Optyx, Sumo, Evolution, Intellipop, Starlight, Legacy, Yandoo, Voonami, Infinity all serve this area. Zero have IPv6.
Should probably clarify the location of ‘here’
Does that change the point of the discussion? Because all of those ISPs are in multiple markets.
The point being that ISPs remain a primary stall-point of IPv6 adoption. There is eagerness to hand-wave that away - and that is part of the reason IPv6 stays underdeployed.
The point being that ISPs remain a primary stall-point of IPv6 adoption. There is eagerness to hand-wave that away - and that is part of the reason IPv6 stays underdeployed.
I’ve never heard of any of those.
Pardon if this is an ignorant question, but could the "backhaul providers" help expedite v6 by simply adding a small-but-annoying tax on carrying v4 traffic? I know it sounds ridiculous to want to pay more, but it might help "rip the band-aid" off if, in order to keep costs down, ISPs had to pay a little more for the deprecated protocol.
> The rather bizarre economics of financing 3G infrastructure meant that dual stack infrastructure in a 3G platform was impractical, so IPv4 was used to support the first wave of mobile services.
What's he referring to here?
What's he referring to here?
I've always wanted to give IPv6 more chances to see if I can take advantage of its features early, but every attempt has left me very disappointed. Issues I noticed during my recent research:
- GitHub does not support IPv6.
- Docker containers do not have IPv6 by default.
- Many programs default to listening on 0.0.0.0 or 127.0.0.1 when they start, which means they only listen on IPv4. On Linux, listening on :: defaults to listening on both IPv4 and IPv6 simultaneously, but few programs do this. Python asyncio even disabled this feature[1].
- I've always heard that using IPv6 can sometimes lead to high latency or low bandwidth on certain websites, or even resource loading failures. Why isn’t there a convenient tool to compare these differences? It would be great if browsers could switch between IPv4-only, IPv6-only, and dual-stack modes. I’d like to seriously compare the effects on some websites rather than being silently affected.
- Two large ISPs, Hurricane Electric and Cogent, do not have IPv6 peering[2], so they are not interconnected, and many other ISPs have similar issues.
- Very few VPS providers offer /64 IPv6 addresses, which would allow different containers to be assigned freely within a machine. Some only provide a single /128, while others offer very few addresses per machine.
- Many people might only know how to use iptables/nftables for firewalls and forget about IPv6, leading to situations where using IPv6 can bypass the firewall. I’m not talking about issues caused by the lack of NAT (NAT is not a good firewall!), but more generally about cases where you want to disable forwarding between two network interfaces.
I stumbled upon two old posts that I found quite amusing:
In 2011, someone said[3] “It's not terribly useful to have IPv6 only websites at the moment. Check back in 5-10 years though ;)”
In 2014, someone said[4] “The Internet is growing really fast, in a few years, the IPv6 network will be bigger than IPv4, so, with IPv4, you'll be out of the real Internet. Go ahead man! Upgrade your IP!! Change is a good thing.”
[1]: https://github.com/python/cpython/blob/5f5c0b9c23238dc0a1fdb...
[2]: https://adminhacks.com/broken-IPv6.html
[3]: https://www.reddit.com/r/ipv6/comments/gnh69/what_ipv6only_w...
[4]: https://askubuntu.com/questions/309461/how-to-disable-ipv6-p...
- GitHub does not support IPv6.
- Docker containers do not have IPv6 by default.
- Many programs default to listening on 0.0.0.0 or 127.0.0.1 when they start, which means they only listen on IPv4. On Linux, listening on :: defaults to listening on both IPv4 and IPv6 simultaneously, but few programs do this. Python asyncio even disabled this feature[1].
- I've always heard that using IPv6 can sometimes lead to high latency or low bandwidth on certain websites, or even resource loading failures. Why isn’t there a convenient tool to compare these differences? It would be great if browsers could switch between IPv4-only, IPv6-only, and dual-stack modes. I’d like to seriously compare the effects on some websites rather than being silently affected.
- Two large ISPs, Hurricane Electric and Cogent, do not have IPv6 peering[2], so they are not interconnected, and many other ISPs have similar issues.
- Very few VPS providers offer /64 IPv6 addresses, which would allow different containers to be assigned freely within a machine. Some only provide a single /128, while others offer very few addresses per machine.
- Many people might only know how to use iptables/nftables for firewalls and forget about IPv6, leading to situations where using IPv6 can bypass the firewall. I’m not talking about issues caused by the lack of NAT (NAT is not a good firewall!), but more generally about cases where you want to disable forwarding between two network interfaces.
I stumbled upon two old posts that I found quite amusing:
In 2011, someone said[3] “It's not terribly useful to have IPv6 only websites at the moment. Check back in 5-10 years though ;)”
In 2014, someone said[4] “The Internet is growing really fast, in a few years, the IPv6 network will be bigger than IPv4, so, with IPv4, you'll be out of the real Internet. Go ahead man! Upgrade your IP!! Change is a good thing.”
[1]: https://github.com/python/cpython/blob/5f5c0b9c23238dc0a1fdb...
[2]: https://adminhacks.com/broken-IPv6.html
[3]: https://www.reddit.com/r/ipv6/comments/gnh69/what_ipv6only_w...
[4]: https://askubuntu.com/questions/309461/how-to-disable-ipv6-p...
One of my biggest issue is: how do you even detect exfil when ICMP is mandatory in IPv6 for the other protocols to even just work?
IPv6 looks so Rube-Goldbergy to my eyes that if I squint just a little tiny bit and put a very thin thinfoil hat on, I could nearly swear this complexity is there by design. For example so backdoors allowing exfil through ICMP are impossible to detect.
IPv6 is chatty. So chatty.
There are networks where a single unaccounted for packet means something abnormal is going on (and at the very least requires enquiry): how does that work with IPv6?
An issue with these big design-by-committee thinggies is that often one or two in the committees are little rats working for the man.
IPv6 looks so Rube-Goldbergy to my eyes that if I squint just a little tiny bit and put a very thin thinfoil hat on, I could nearly swear this complexity is there by design. For example so backdoors allowing exfil through ICMP are impossible to detect.
IPv6 is chatty. So chatty.
There are networks where a single unaccounted for packet means something abnormal is going on (and at the very least requires enquiry): how does that work with IPv6?
An issue with these big design-by-committee thinggies is that often one or two in the committees are little rats working for the man.
ICMP is required for IPv4 to work correctly, too. It's often completely blocked by cargo culting net admins who then wonder why their things fail that ICMP would have fixed.
I have a laundry list of issues like this:
Firewalls stopped sending RST packets (or any other kind of error) by default on all ports more than a decade ago. This is great for Internet-facing security, but has converted from easily diagnosed instant failures on internal networks to 30 second timeouts... which are indistinguishable from "host is down".
Don't worry! Just ping the host... err... can't do that either because of overly paranoid admins like you mentioned.
Next, spend a week trying to figure out why packets seem to go only one way through a cloud VPN only to discover that Path MTU Discovery uses ICMP and without which VPNs are basically broken.
Fun.
Firewalls stopped sending RST packets (or any other kind of error) by default on all ports more than a decade ago. This is great for Internet-facing security, but has converted from easily diagnosed instant failures on internal networks to 30 second timeouts... which are indistinguishable from "host is down".
Don't worry! Just ping the host... err... can't do that either because of overly paranoid admins like you mentioned.
Next, spend a week trying to figure out why packets seem to go only one way through a cloud VPN only to discover that Path MTU Discovery uses ICMP and without which VPNs are basically broken.
Fun.
IPv4 is valuable, there are reasons to not be able to uniquely id/tag/censor every endpoint. It's much harder to block a country than a user.
GitHub and Microsoft Azure still aren't IPv6-ready.
Azure is... getting there. Slowly.
The Portal now loads for me on IPv6, which then blocks me from accessing certain PaaS resources because they only work with IPv4 rules in their firewalls.
Speaking of which, it grinds me gears that every Azure PaaS service implements firewall rules in a unique and special way. The syntax is different, the parameters are different, the capabilities are different, and the output logs are also incompatible just for extra fun.
The Portal now loads for me on IPv6, which then blocks me from accessing certain PaaS resources because they only work with IPv4 rules in their firewalls.
Speaking of which, it grinds me gears that every Azure PaaS service implements firewall rules in a unique and special way. The syntax is different, the parameters are different, the capabilities are different, and the output logs are also incompatible just for extra fun.
The last few parts of this article reminds me of what i had been working on for the past few years.
It's called "Named-Data Network".
It's called "Named-Data Network".
I'd be convinced that IPv6 is done when large companies deploy servers on IPv6 only without an IPv4 fall-back.
These charts that show IPv6 adoption really don't mean shit. The thing is: every single device out there isn't being used directly by a human bean (and a real hero.) They include things like sensors, smart lights, fridges, washing machines, a huge huge number of mobile devices, company networks, ... apparently even tooth brushes? Look at another sector and the story is ((quite horrible.)) I'm talking a regular fixed home network.
Start by looking at routers for IPv6 support. And what do you see? Total crap across the board. Here's some of the issues I've seen. Routers that have no IPv6 support (common for ISP provided routers.) Routers that have NO FIREWALL for IPv6. Routers that crash every 3 minutes after assigning an address. Routers that don't support the exact combination of network details to setup IPv6 on your network (there are multiple ways to deploy IPv6.)
What about if you want to use features like UPnP with IPv6 (something that would probably be useful for some software given that IPv6 is supposed to give you public addresses but firewall it on the router.) What I've found is there's really just one UPnP library that every router uses even though it sucks. miniupnpd. This is a library that can barely manage to handle different types of addresses. It's really a mixed bag whether an IPv6 firmware will have miniupnpd enabled and if its built for IPv6 (and if anyone bothered to test it.) The odds go down dramatically.
If you manage to get a router with IPv6 at home working alongside other useful Internet standards made for it (since 2010) color me impressed. You probably buy a lottery ticket at that point. Because if testing IPv6 deployments for the past 2 years has taught me anything: its that no one really cares about this shit. Present day, present time. You still hear people telling others to turn IPv6 off for some vague reason ('security', 'bad', 'problems.') These people don't really have a clue. It's all just a massive cope because they tried to get it to work and failed. And after the shit I've said I can't say I blame them. But I also want to note that their conclusions are BS.
Start by looking at routers for IPv6 support. And what do you see? Total crap across the board. Here's some of the issues I've seen. Routers that have no IPv6 support (common for ISP provided routers.) Routers that have NO FIREWALL for IPv6. Routers that crash every 3 minutes after assigning an address. Routers that don't support the exact combination of network details to setup IPv6 on your network (there are multiple ways to deploy IPv6.)
What about if you want to use features like UPnP with IPv6 (something that would probably be useful for some software given that IPv6 is supposed to give you public addresses but firewall it on the router.) What I've found is there's really just one UPnP library that every router uses even though it sucks. miniupnpd. This is a library that can barely manage to handle different types of addresses. It's really a mixed bag whether an IPv6 firmware will have miniupnpd enabled and if its built for IPv6 (and if anyone bothered to test it.) The odds go down dramatically.
If you manage to get a router with IPv6 at home working alongside other useful Internet standards made for it (since 2010) color me impressed. You probably buy a lottery ticket at that point. Because if testing IPv6 deployments for the past 2 years has taught me anything: its that no one really cares about this shit. Present day, present time. You still hear people telling others to turn IPv6 off for some vague reason ('security', 'bad', 'problems.') These people don't really have a clue. It's all just a massive cope because they tried to get it to work and failed. And after the shit I've said I can't say I blame them. But I also want to note that their conclusions are BS.
All routers I've ever encountered have a default deny rule for IPv6, replicating the port forwarding setup people have come to expect from NAT. Except you can use multiple Xboxes in the same network now, of course.
Even the mini router I bought for 15 bucks five years ago does IPv6 addressing just fine. Just announcing a prefix (or two, local network stuff over ULAs and all that) is enough to make SLAAC do its thing. Never had any problem with DHCPv6 PD for automatic subnetting either.
I haven't looked into UPnP on IPv6 much, but the ones that did UPnP all seem to do IPv6 fine after 2015 or so. I usually turn it off because I don't want random crap manage my firewall unauthenticated (and many router manufacturers have had vulnerable implementations that would accept UPnP packets from the internet so screw that).
Brands that I've successfully used IPv6 with without any hassle include TP-Link, D-Link (don't buy from them), AVM, Mikrotik, and Netgear.
The most annoying part I find about routers is actually that they don't let you disable ALGs anymore it seems. Every few years Samy Kamkar writes up a way to bypass most IPv4 firewalls by abusing the hackery we've accumulated around NAT and the easiest fix ("let FTP/SIP/H363/PPTP be broken on IPv4") doesn't seem to come with routers anymore.
It took a while, but router manufacturers seem to have realised that the world is moving towards "CGNAT or IPv6" and not having usable IPv6 breaks networks in those cases.
The most broken IPv6 deployments I've seen were from people who tried to turn it off though weird hacks like firewall rules which subsequently got IPv6 from their ISP. Had they actually disabled IPv6 they would've just been stuck OK IPv4 like regular, but their weird hacks made half the TCP connections need to time out before they could access the internet.
Even the mini router I bought for 15 bucks five years ago does IPv6 addressing just fine. Just announcing a prefix (or two, local network stuff over ULAs and all that) is enough to make SLAAC do its thing. Never had any problem with DHCPv6 PD for automatic subnetting either.
I haven't looked into UPnP on IPv6 much, but the ones that did UPnP all seem to do IPv6 fine after 2015 or so. I usually turn it off because I don't want random crap manage my firewall unauthenticated (and many router manufacturers have had vulnerable implementations that would accept UPnP packets from the internet so screw that).
Brands that I've successfully used IPv6 with without any hassle include TP-Link, D-Link (don't buy from them), AVM, Mikrotik, and Netgear.
The most annoying part I find about routers is actually that they don't let you disable ALGs anymore it seems. Every few years Samy Kamkar writes up a way to bypass most IPv4 firewalls by abusing the hackery we've accumulated around NAT and the easiest fix ("let FTP/SIP/H363/PPTP be broken on IPv4") doesn't seem to come with routers anymore.
It took a while, but router manufacturers seem to have realised that the world is moving towards "CGNAT or IPv6" and not having usable IPv6 breaks networks in those cases.
The most broken IPv6 deployments I've seen were from people who tried to turn it off though weird hacks like firewall rules which subsequently got IPv6 from their ISP. Had they actually disabled IPv6 they would've just been stuck OK IPv4 like regular, but their weird hacks made half the TCP connections need to time out before they could access the internet.
> I haven't looked into UPnP on IPv6 much
Added as an appendix in 2011:
* https://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1....
Added as an appendix in 2011:
* https://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1....
What’s funny is the last consumer router I bought had the opposite problem. It had a ridiculously low limit on DHCP leases, something like 32 devices. And one time, IPv4 routing just crashed completely and I had to reboot it. Meanwhile IPv6 was always rock stable. The crash was a weird one to debug at first since so many online properties work with IPv6, at first I blamed DNS
The ISP router I had a few years ago could be crashed by visiting 42.be (which is having https issues right now but it loads 1000 tiny image tiles from 1000 IPv6 addresses)
Strange, every router I've used in the last 10+ years has done IPv6 fine. Even the RSP/ISP supplied gear I've used at friends/family houses are all fine with IPv6. Where I live all fixed line RSP/ISPs (except for one) has IPv6 enabled and on request will sell RSP-supported routers with IPv6 enabled out of the box. I personally don't use RSP-supplied gear but I've used Ubiquiti, Microtik, Netgear, etc routers and they all work just fine with sane IPv6 defaults. I really have not come across a single case of a bad IPv6 routers -- even among RSP-supplied equipment.
> They include things like sensors, smart lights, fridges, washing machines,
Now you gave me an excellent reason to make my home network v6-only.
Now you gave me an excellent reason to make my home network v6-only.
It's ridiculous how slowly it goes.
I'm pretty naive about this stuff, but IMO IPv6 is a lot more empowering than v4. You aren't dependent on some owner of v4 addresses for access, you don't need to manage--and aren't forced into--NAT, and you (probably) get to use all of your ports.
My conspiracy theories about why v6 hasn't taken off are: people make money off v4 leases, and email spam blacklists become pretty useless in v6. But again, very naive here.
My conspiracy theories about why v6 hasn't taken off are: people make money off v4 leases, and email spam blacklists become pretty useless in v6. But again, very naive here.
The more likely reality is that we have a lot of v4-only hw in place with lifespan of 20+ years. Those devices won't go away.
Heck, I work on embedded, and having a dual-stack system is just a PITA to deal with. If v6 would have been fully retro-compatible this wouldn't have been something to think about, but you can't drop v4 and there's no future in sight where v6 will be the only choice (we'll have dual-stack for a looooong time), so we just push the problem up the chain.
There are plenty of systems being developed _now_ which are still v4 only as a result.
Heck, I work on embedded, and having a dual-stack system is just a PITA to deal with. If v6 would have been fully retro-compatible this wouldn't have been something to think about, but you can't drop v4 and there's no future in sight where v6 will be the only choice (we'll have dual-stack for a looooong time), so we just push the problem up the chain.
There are plenty of systems being developed _now_ which are still v4 only as a result.
Totally agree. I'm a little embarrassed by it tbh; to me it feels like a big failure of nerd governance. We should be able to manage this, but I think we're pretty close to having to admit that we can't.
In spite of its wider adoption issues, it's valuable for my personal infrastructure: each of my services/machine has an IPv6 globally routable address.
Why bother, when I could just do TLS SNI reverse proxying via nginx?
* Some services don't use TLS, or even TCP.
* A reverse proxy is yet another intermediary in the chain.
* Plain IPv6 routing is simpler than reverse proxying, and I already need a network layer anyway.
There are downsides:
* some software doesn't support IPv6. I haven't experienced this on the Linux servers I run.
* in a dual stack network, now you have two networks! I use NAT64/PREF64 like https://labs.ripe.net/author/ondrej_caletka_1/deploying-ipv6... to have most clients only be on IPv6. They get IPv4 connectivity over IPv6 via NAT64.
* If I'm in another country then I often don't have IPv6 connectivity. In this case I use any VPN that offers IPv6 (and have one available via my home, via Wireguard).
* Learning IPv6 takes time, but not much. It's one-off. It's not more complex than IPv4, but it is different. If anything, it's simpler. (SLAAC rather than DHCPv4; IP reachability rather than NAT/port forwarding).
Why bother, when I could just do TLS SNI reverse proxying via nginx?
* Some services don't use TLS, or even TCP.
* A reverse proxy is yet another intermediary in the chain.
* Plain IPv6 routing is simpler than reverse proxying, and I already need a network layer anyway.
There are downsides:
* some software doesn't support IPv6. I haven't experienced this on the Linux servers I run.
* in a dual stack network, now you have two networks! I use NAT64/PREF64 like https://labs.ripe.net/author/ondrej_caletka_1/deploying-ipv6... to have most clients only be on IPv6. They get IPv4 connectivity over IPv6 via NAT64.
* If I'm in another country then I often don't have IPv6 connectivity. In this case I use any VPN that offers IPv6 (and have one available via my home, via Wireguard).
* Learning IPv6 takes time, but not much. It's one-off. It's not more complex than IPv4, but it is different. If anything, it's simpler. (SLAAC rather than DHCPv4; IP reachability rather than NAT/port forwarding).
Anycast and SNI mean someone like cloud flare only needs one IPv4 for their entire public facing service?
Is that the gist?
Obviously I exaggerate but I think that's their point?
https://cr.yp.to/djbdns/ipv6mess.html
still as relevant as the day it was written
Time has not been kind to this article. It's basically a compete list of fallacies that people believe about ipv6.
Oh, is IPv6 now backwards compatible with IPv4? No? I guess not a complete list of fallacies.
IPv6 clients (or in theory any kind of IPv4 successor) can reach IPv4 servers via some kind of translation layer (for example NAT64) - so IPv6 is backwards-compatible with IPv4 in that direction.
The inverse direction (IPv4 client to IPv6 server) is however not possible, since IPv4 is not forward-compatible with any possible successor, because it is not possible to encode more information into 32-bit than 32-bit.
Yes, v6 is backwards compatible with v4 now, via dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6 and probably other methods I'm forgetting. In fact many of these were in there from the start, so it was always backwards compatible.
You could make a reasonable argument that it has too many ways of being backwards compatible, even.
You could make a reasonable argument that it has too many ways of being backwards compatible, even.
I can route to v4 endpoints on my v6-only network just fine. Shrugs
They aren’t compatible. There is a device in the middle doing a translation for you.
That’s like saying HTTP can talk to FTP servers as long as there is an HTTP to FTP proxy.
The only thing that makes them seem compatible is there is a well formed address space in v6 that clients send v4 requests to. But it’s still v6 and a 64 proxy needs to have an actual IPv4 address to translate the source to before sending it via v4 to the actual destination.
That’s like saying HTTP can talk to FTP servers as long as there is an HTTP to FTP proxy.
The only thing that makes them seem compatible is there is a well formed address space in v6 that clients send v4 requests to. But it’s still v6 and a 64 proxy needs to have an actual IPv4 address to translate the source to before sending it via v4 to the actual destination.
> They aren’t compatible. There is a device in the middle doing a translation for you.
Which was true of all the IPng candidates, and not just the one that ended up being chosen for "IPv6".
There is no way to expand the addresses space (as found in IPv4) to something greater that 32-bits in a compatible: new API calls, data structures, DNS records, etc, were always going to be needed.
To list "not compatible" as a con of IPng/IPv4 is non-sensical.
Which was true of all the IPng candidates, and not just the one that ended up being chosen for "IPv6".
There is no way to expand the addresses space (as found in IPv4) to something greater that 32-bits in a compatible: new API calls, data structures, DNS records, etc, were always going to be needed.
To list "not compatible" as a con of IPng/IPv4 is non-sensical.
I'm aware there's a middle box. My point is that the middle box is a compatibility layer which, by definition, has the effect of enabling compatibility (at least in one direction).
The usual "they should have designed it to be compatible" nonsense usually comes from the crowd with zero suggestions of how to have a 32-bit addressed device send to packets to something with an address outside its universe.
Point is that djb was as wrong then as they are now.
The usual "they should have designed it to be compatible" nonsense usually comes from the crowd with zero suggestions of how to have a 32-bit addressed device send to packets to something with an address outside its universe.
Point is that djb was as wrong then as they are now.
> They aren’t compatible. There is a device in the middle doing a translation for you.
The same could be said of the awful mess we have currently with IPv4 NAT almost everywhere on the current IPv4 network (and CG-NAT as well).
The same could be said of the awful mess we have currently with IPv4 NAT almost everywhere on the current IPv4 network (and CG-NAT as well).
It's even what the T stands for.
Well, finding out the author works at my alma mater the weirdest way possible: recognizing our Class B in the opening paragraph. I still catch myself typing 131.193 when I go to type in IP addresses on the numpad, just a force of habit.
Of course, my home network's IPv4 space uses the same 10 block as the subnets I worked with most of my time there.
Of course, my home network's IPv4 space uses the same 10 block as the subnets I worked with most of my time there.
Which is to say, not.
DJB point about the magic moment makes sense to me. What is the point of a separate network that has 33% adoption? It has virtually no impact to alleviate IP address exhaustion, and therefore there is no incentive.
The vast majority of that ~%40 of internet traffic is in direct disagreement with said prophecy though. Mobile carriers like T-Mobile, Verizon, AT&T, Telstra, Deutsch Telekom, Orange, (...you get the idea) all used pure IPv6 backbones with NAT64 edges to role out mobile telecommunications without needing double/CG-NAT or boatloads of public IPv4. Each connection made via IPv6 is transparently 1 less NAT session out a public v4 address and the IPv6 design greatly optimized the way the mobile network cores were built out. This is what has driven the growth of IPv6 on the internet (as more users switch to mobile) rather than an explosion of wireline and business users making the switch.
Where pressure is still lacking is in "small" enterprise type case (like most businesses, regional health systems, local government facilities, and so on) where the difference isn't really that much vs networks with 100 million or more clients riding). Only when corps get to the size of e.g. Microsoft do they really start seeing similar value at the moment. Everyone else can scrape by just getting that small bit of IPv4 and forgetting about it for now.
Where pressure is still lacking is in "small" enterprise type case (like most businesses, regional health systems, local government facilities, and so on) where the difference isn't really that much vs networks with 100 million or more clients riding). Only when corps get to the size of e.g. Microsoft do they really start seeing similar value at the moment. Everyone else can scrape by just getting that small bit of IPv4 and forgetting about it for now.
I have even implemented an IPv6-Only network. It fully works, including accessing IPv4 only websites like github.com via DNS64 and NAT64 at my router.
The only practically useful thing about my IPv6 enabled network is that I can run globally routable services on my lan, without NAT port mapping. Of course, only if the client is also IPv6.
Other than this one use case, IPv6 does nothing for me.
It doesn't work from most hotels, nor from my work lan, nor many other places because most "managed" networks are IPv4 only. It works better at Cafes because they are "unmanaged" and IPv6 is enabled by the most common ISPs, like ATT and Comcast and their provided routers.
Based on this experience, I think IPv6 is less valuable than us HN audience thinks it is. Private networks, NAT, Carrier Grade NAT are good enough, and internet really doesn't care about being completely peer-to-peer.
I think the adoption rate reflects this--it's a linear growth curve over the last 25 years. It should have been exponential.
I think cost of IPv4 reflects this--it is now below the peak, and has leveled off.
As surprising as it seems, IPv4 exhaustion has not been a serious problem. Internet marches on. IPv6 is still a solution looking for a problem, and IPv4 exhaustion wasn't one of them.