India is leading IPv6 migration with 61.67% adoption(aelius.com)
aelius.com
India is leading IPv6 migration with 61.67% adoption
https://www.aelius.com/njh/google-ipv6/
288 comments
github.com doesn't support IPv6 either, which is annoying because a lot of software uses GitHub for artifact distribution.
Yeah, and Heroku too. Don't know how they going now, but 5-7 years ago were their popularity was crazy.
In what way does getting your artefacts through ipv4 annoy you?
It means I can’t do a fully ipv6 backend, which is a bit irritating.
If you have an bunch of servers using ipv6 to avoid NAT issues.
ELI5: Why does IPv6 adoption matter? What would happen if these sites don't migrate to IPv6?
Because there are 'only' 2^32, roughly four billion, IPv4 addresses. There are also over eight billion people on this planet, and many of them have multiple computers (smartphones, tablets, laptops, desktops, etc).
As a 'temporary' measure, Network Address Translation (NAT) was introduced so people could get one public IPv4 address and have multiple machines on the Internet behind it.
The trade-off was the machines behind the NAT mechanism couldn't be reached from the Internet. This isn't a big deal for most consumption-based computing (fetching mail, watching videos), but there are use cases where you want to be able to talk to the other system, so yet another set of technologies had to be invented to allow punching holes through NAT (UPnP, NAT-PMP, PCP, STUN).
But we're at the point in some place where there aren't even enough IPv4 addresses to give to ISP customers even if they're using NAT. So you have a private IP address for your home system, and then your router gets a private IP address on its "public" WAN connection, and you end up going two layers of NAT. There is an entire segment of IPv4 addresses (100.64.0.0/10) reserved for telco use and doubel-NATing:
* https://en.wikipedia.org/wiki/Private_network#Dedicated_spac...
* https://en.wikipedia.org/wiki/IPv4_shared_address_space
We can continue this NAT-upon-NAT(-upon-NAT) silliness, or we can simply make the up-front investment and start pushing out IPv6 in more places. Your router still provides firewall protection, but reachability is a lot more straight-forward because the (potentially double) address translation goes away.
Edit: fix a bunch of typos.
As a 'temporary' measure, Network Address Translation (NAT) was introduced so people could get one public IPv4 address and have multiple machines on the Internet behind it.
The trade-off was the machines behind the NAT mechanism couldn't be reached from the Internet. This isn't a big deal for most consumption-based computing (fetching mail, watching videos), but there are use cases where you want to be able to talk to the other system, so yet another set of technologies had to be invented to allow punching holes through NAT (UPnP, NAT-PMP, PCP, STUN).
But we're at the point in some place where there aren't even enough IPv4 addresses to give to ISP customers even if they're using NAT. So you have a private IP address for your home system, and then your router gets a private IP address on its "public" WAN connection, and you end up going two layers of NAT. There is an entire segment of IPv4 addresses (100.64.0.0/10) reserved for telco use and doubel-NATing:
* https://en.wikipedia.org/wiki/Private_network#Dedicated_spac...
* https://en.wikipedia.org/wiki/IPv4_shared_address_space
We can continue this NAT-upon-NAT(-upon-NAT) silliness, or we can simply make the up-front investment and start pushing out IPv6 in more places. Your router still provides firewall protection, but reachability is a lot more straight-forward because the (potentially double) address translation goes away.
Edit: fix a bunch of typos.
Playing Nintendo Switch online doesn't work if you're double NAT'd unless you go through some router hoops. It seems small, but it's quite aggravating if you're not tech oriented like the majority of the people on this forum.
> NAT-upon-NAT(-upon-NAT)
But there is also a fundamental limit of 2^16 = 65536 concurrent connections, right?
But there is also a fundamental limit of 2^16 = 65536 concurrent connections, right?
Yes, from one NAT IP using the same protocol to a single public IP using a particular port. Change any of those and you can do 2^16 concurrent connections more per change.
In other words, NAT works on the five-tuple of: protocol, source IP, source port, destination IP and destination port.
In other words, NAT works on the five-tuple of: protocol, source IP, source port, destination IP and destination port.
> The trade-off was the machines behind the NAT mechanism couldn't be reached from the Internet
That can also be pretty awesome given that so many devices now may not work in the interest of their users.
It is a hassle for IOT, but we have long since then solutions for that and maybe those are better anyway.
My provider only supplies IPv6 and you always connect to IPv4 through a transport. That is sometimes down or has too many concurrent users. Makes the net almost unusable still. Perhaps I should learn Hindi.
That can also be pretty awesome given that so many devices now may not work in the interest of their users.
It is a hassle for IOT, but we have long since then solutions for that and maybe those are better anyway.
My provider only supplies IPv6 and you always connect to IPv4 through a transport. That is sometimes down or has too many concurrent users. Makes the net almost unusable still. Perhaps I should learn Hindi.
You need a firewall if your end points are publicly reachable, not NAT.
NAT still provides some layer of protection, especially if you don’t trust the firewall software.
This is going to open up a can of worms once everybody gets global addresses and can’t figure out how to configure their firewall.
This is going to open up a can of worms once everybody gets global addresses and can’t figure out how to configure their firewall.
It actually doesn't. NAT just changes the apparent source address of outbound connections; it doesn't do anything to inbound ones.
In any case, people manage to do both NAT and firewalls on v4 today so I don't see why they'd suddenly be unable to do firewalls in v6, especially since you don't have the complication of needing to figure out NAT as well.
The large address space also helps a lot, because it makes it much harder to find servers on v6 (including deliberately exposed servers, e.g. cameras or NASs that people want to access from a different network), compared to v4 where you can enumerate all active servers over the entire internet without much trouble.
In any case, people manage to do both NAT and firewalls on v4 today so I don't see why they'd suddenly be unable to do firewalls in v6, especially since you don't have the complication of needing to figure out NAT as well.
The large address space also helps a lot, because it makes it much harder to find servers on v6 (including deliberately exposed servers, e.g. cameras or NASs that people want to access from a different network), compared to v4 where you can enumerate all active servers over the entire internet without much trouble.
NAT prevents an external host from making arbitrary connections to a host behind the NAT without further configuration. This is something your average person doesn’t need to know or really care about. But once every device they have is globally routable they will have to care and ensure their machines are secure and behind a firewall. And if that firewall should fail then you’re sitting on the public network with your pants down.
Your other part is security through obscurity, and I can think of at least 2 ways to scan the entire address space in a short amount of time. So nope doesn’t count either.
Your other part is security through obscurity, and I can think of at least 2 ways to scan the entire address space in a short amount of time. So nope doesn’t count either.
It doesn't do that. How can rewriting the source address of outbound connections prevent inbound connections?
You're not going to exhaustively scan the entire v6 space in any short amount of time. It is possible to whittle down the space you need to scan, but only moderately. It's still rather unviable compared to v4.
You're not going to exhaustively scan the entire v6 space in any short amount of time. It is possible to whittle down the space you need to scan, but only moderately. It's still rather unviable compared to v4.
Pick any network doing NAT, attempt to make a connection. It will be denied. NAT devices are both firewalls and translators and if you don’t have a configuration for port forwarding, be it via established connection or manual configuration, the connection won’t get through. And importantly this is a configuration the user doesn’t touch.
And scanning IP spaces is insanely easy to parallelize and uses so few resources an arduino can be used to scan. Given enough nodes it’s instant. And with every windows box on the planet globally routable, bonets will never be stronger.
But let’s pretend this is true and say it takes too much time. What about when it doesn’t? What happens to your security via obscurity then?
And scanning IP spaces is insanely easy to parallelize and uses so few resources an arduino can be used to scan. Given enough nodes it’s instant. And with every windows box on the planet globally routable, bonets will never be stronger.
But let’s pretend this is true and say it takes too much time. What about when it doesn’t? What happens to your security via obscurity then?
I've tested it before, multiple times; NAT won't deny an inbound connection. A router that's NATing outbound connections will allow inbound connections through unless there's also a firewall. Of course it's very common for there to be a firewall as well, but they're still a separate thing to NAT.
> And scanning IP spaces is insanely easy to parallelize and uses so few resources an arduino can be used to scan. Given enough nodes it’s instant.
You're underestimating how big v6 is. Scanning a single /64 takes ~737 million terabytes of traffic. If you used a trillion Arduinos in parallel you could scan 2^40 /64s simultaneously, and it would only take 1870 years for the scan to complete, assuming that every single one of both the Arduinos and the target networks have a 100 Gbit/s internet connection each. Your power consumption would be... about the same as Italy's, which is actually the most reasonable part of all this (except I assumed the 100 GBit/s network connections would take no power).
> And with every windows box on the planet globally routable, bonets will never be stronger.
You're thinking about botnets that spread by brute force scanning, right? But as mentioned, this will be substantially more difficult on v6, to the point that network scanning won't be a very viable technique for spreading a botnet. On top of that, most Windows machines will be behind two separate firewalls, so I don't see how them being globally routable will make botnets stronger. Given that it'll be harder to find targetable hosts, I'd instead expect botnets to be weaker than ever.
Also, remember that a lot of botnets spread by exploiting servers that were deliberately exposed to the internet. Making these hard to find is the only defence they have, and it's not possible on v4. NAT can't help either, however it works.
An insecure, hard-to-find machine is still an insecure machine, but making it difficult to find vulnerable hosts makes it harder to build a botnet, which leads to a very real increase of security on the internet as a whole. Even if a few machines are found, nothing much happens to the overall security so long as it remains hard enough on average.
Think of it as being something like vaccination for the internet.
> And scanning IP spaces is insanely easy to parallelize and uses so few resources an arduino can be used to scan. Given enough nodes it’s instant.
You're underestimating how big v6 is. Scanning a single /64 takes ~737 million terabytes of traffic. If you used a trillion Arduinos in parallel you could scan 2^40 /64s simultaneously, and it would only take 1870 years for the scan to complete, assuming that every single one of both the Arduinos and the target networks have a 100 Gbit/s internet connection each. Your power consumption would be... about the same as Italy's, which is actually the most reasonable part of all this (except I assumed the 100 GBit/s network connections would take no power).
> And with every windows box on the planet globally routable, bonets will never be stronger.
You're thinking about botnets that spread by brute force scanning, right? But as mentioned, this will be substantially more difficult on v6, to the point that network scanning won't be a very viable technique for spreading a botnet. On top of that, most Windows machines will be behind two separate firewalls, so I don't see how them being globally routable will make botnets stronger. Given that it'll be harder to find targetable hosts, I'd instead expect botnets to be weaker than ever.
Also, remember that a lot of botnets spread by exploiting servers that were deliberately exposed to the internet. Making these hard to find is the only defence they have, and it's not possible on v4. NAT can't help either, however it works.
An insecure, hard-to-find machine is still an insecure machine, but making it difficult to find vulnerable hosts makes it harder to build a botnet, which leads to a very real increase of security on the internet as a whole. Even if a few machines are found, nothing much happens to the overall security so long as it remains hard enough on average.
Think of it as being something like vaccination for the internet.
> I've tested it before, multiple times; NAT won't deny an inbound connection.
Test it with a consumer level router, stock configuration. I'm not concerned with networks that have split NAT / firewall devices. These are setup by people that know what they're doing.
> A router that's NATing outbound connections will allow inbound connections through unless there's also a firewall.
Yes which is my chief complaint. Not getting rid of NAT, pushing the firewall to the client.
> Scanning a single /64 takes
Why are we the entirety of the 64 subnet? You can use some knowledge about networks to cut this down a lot. Just the one knowing a network is there is enough.
Then you're also assuming people won't group together on this. Lists will be sold in short order, making the search space even smaller.
You're still hiding security behind it being hard to scan because of a large number, so that will quickly be invalidated.
And then if someone say hides in the middle of their /64 and changes their address every hour the attack will then change and it will become focused with malware or other means, except there won't be a fronting NAT protecting them to stop inbound requests.
> Think of it as being something like vaccination for the internet.
What does this even mean? How does a computer get a vaccination?
Test it with a consumer level router, stock configuration. I'm not concerned with networks that have split NAT / firewall devices. These are setup by people that know what they're doing.
> A router that's NATing outbound connections will allow inbound connections through unless there's also a firewall.
Yes which is my chief complaint. Not getting rid of NAT, pushing the firewall to the client.
> Scanning a single /64 takes
Why are we the entirety of the 64 subnet? You can use some knowledge about networks to cut this down a lot. Just the one knowing a network is there is enough.
Then you're also assuming people won't group together on this. Lists will be sold in short order, making the search space even smaller.
You're still hiding security behind it being hard to scan because of a large number, so that will quickly be invalidated.
And then if someone say hides in the middle of their /64 and changes their address every hour the attack will then change and it will become focused with malware or other means, except there won't be a fronting NAT protecting them to stop inbound requests.
> Think of it as being something like vaccination for the internet.
What does this even mean? How does a computer get a vaccination?
What?! You don’t trust the firewalls software so you are good to trust the NAT software?
Windows firewall? no. iptables? yes. Why? because I know how to configure one and not the other. Also because of things like this:
https://www.enterprisenetworkingplanet.com/security/qa-behin...
https://www.enterprisenetworkingplanet.com/security/qa-behin...
Completely true, I wasn't too serious about that, just pointing out that there were unintended benefits.
> But we're at the point in some place where there aren't even enough IPv4 addresses to give to ISP customers even if they're using NAT.
Er, that's a slight exaggeration. It's not uncommon to have 2,000 or more NAT clients behind a single public IP address. 2K * 4B = 8 trillion possible hosts... about 1,000 hosts per living person.
Er, that's a slight exaggeration. It's not uncommon to have 2,000 or more NAT clients behind a single public IP address. 2K * 4B = 8 trillion possible hosts... about 1,000 hosts per living person.
Well, it has limits. You can hide 2000 people behind an address but they might have sporadic connection issues, long held connections such as SSH sessions will be very annoying to support [0] or the users will have to resort to frequent keepalives to make it work regardless, which produces more traffic to destinations you probably don't have in a cache. In some jurisdictions you have to log which customer used what IP (and port) at which point. You can do static assignments but you will have customers (customer homes, e.g. family with perhaps 10 devices or so could be realistic) for which 1000 ports just will not be enough do you will have to dynamically assign spare ports and log those. You might also get more support calls, because the NAT is dropping connections to radically in a peak e.g. a soccer match or whatever. Also the CG-NAT gateway isn't for free and the bigger it needs to be, the pricier it is. Also you might still need to buy some IPv4, perhaps more than you would need to buy if you deployed IPv6 and used it for the connections, where it is possible, taking e.g. almost the full load to Google/ YouTube and Facebook off your gateway.
[0] https://anderstrier.dk/2021/01/11/my-isp-is-killing-my-idle-...
[0] https://anderstrier.dk/2021/01/11/my-isp-is-killing-my-idle-...
I just found some of my old posts on my old site from 2003, where I complain about NAT and UPNP. It's nearly 20 years, and the problems have stayed the same :(
NAT was the bandaid that became the permanent solution. It was never meant to be permanent, but because of these, so many weird hacks and designs have been made to compensate for it.
NAT was the bandaid that became the permanent solution. It was never meant to be permanent, but because of these, so many weird hacks and designs have been made to compensate for it.
Totally silly question, but isn't the NAT-upon-NAT(-upon-NAT) a bit of protection in the sense of additional privacy, and hence a good thing? Doesn't this mean the website cannot directly tie back an incognito user back to a specific IP but instead to just a pool?
For a purely "consumer" internet, yes. But I'd like to think that at some point we move back to a more decentralised model, where addressibility in more contexts than a response to a request become important again. To some degree the NAT issues have even killed a lot of this, making P2P more difficult and unreliable than would be otherwise.
Depends, but really IPv6 and IPv4 seems to be more or less comparable in practice. If you use an app with a login, you are basically screwed anyway. Even on a random website, you can be reliably fingerprinted: https://amiunique.org/
> Doesn't this mean the website cannot directly tie back an incognito user back to a specific IP but instead to just a pool?
Do you have cookies on or off in your web browser settings? If they're enabled then you're being tracking regardless of your IP.
I have my router reboot every night and so I get both a new IPv4 address and a new IPv6 prefix everyday. If I have cookies disabled, then ad folks will have to find other ways to track me beside those two.
Do you have cookies on or off in your web browser settings? If they're enabled then you're being tracking regardless of your IP.
I have my router reboot every night and so I get both a new IPv4 address and a new IPv6 prefix everyday. If I have cookies disabled, then ad folks will have to find other ways to track me beside those two.
Yes, but you could also randomize your IPv6 address constantly too.
Downside of CGNAT and NAT at home is difficulty of getting some services to work, or hosting a server.
Downside of CGNAT and NAT at home is difficulty of getting some services to work, or hosting a server.
It still boils down to everyone gets an identifying number, whether it's an ipv4 address or an ipv6 block.
Any randomized ipv6 address from that block is still as "unique" an identifier as an ipv4 address.
Any randomized ipv6 address from that block is still as "unique" an identifier as an ipv4 address.
Also, creating/using P2P applications. I needed to look up UDP hole punching and now I wish I hadn't.
out of curiosity, what did you end up going with? I had to host a UDP game server recently and couldn't find a good solution. If only ngrok supported UDP...
It was just research. I'm interested in audio&video over IP, I already had a good grip on HLS, RTP, and a few others, and wanted to dive into WebRTC, RTSP, etc. I don't know but all of this feels like there's a simpler solution (like HLS vs DASH) waiting to be discovered.
DMZ it and firewall up the host.
ISPs log all of the translations and can reverse a (public IP, source port, time stamp) tuple to the user.
> ISPs log all of the translations
On my personal router?
On my personal router?
They don't need that much granularity; it is enough to being able to point fingers at someone responsible.
But otherwise, it is possible to enumerate devices behind NAT (obviously, only those that communicate with the world in front of NAT) and assign traffic to them.
But otherwise, it is possible to enumerate devices behind NAT (obviously, only those that communicate with the world in front of NAT) and assign traffic to them.
No, at their CGNAT layer. They know which customer it came from. They don’t care which device in your house it came from.
"a bit of protection in the sense of additional privacy, and hence a good thing?"
The more dysfunctional is your internet connection, the more prova you youve got
The more dysfunctional is your internet connection, the more prova you youve got
In your first line, I guess you mean to say ipv4 not ipv6.
there's also NAT64, 464XLAT that do ipv6 to ipv4 sorcery
Beyond an ELI5, but correct.
If you are on an IPv4-only or IPv6-only network, you can reach the other through various mechanisms.
A lot of mobile/cell networks are IPv6-only, and so the telcos need a way to allow clients to reach IPv4-only systems.
If you are on an IPv4-only or IPv6-only network, you can reach the other through various mechanisms.
A lot of mobile/cell networks are IPv6-only, and so the telcos need a way to allow clients to reach IPv4-only systems.
From a game developer/player perspective: there’s a crazy amount of complexity in connecting between two computers that wouldn’t need to be there in an ipv6 world.
See all the NAT, TURN, STUN nonsense that webrtc has to deal with: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/...
Today to use webrtc, u need a neutral server to help establish the connection like PeerJS does. This wouldn’t be needed in an ipv6 world. It’s nearly impossible to do pure peer to peer connections today.
Letting machines connect directly to each other in any context, and especially in the context of an online game, is a massive security and privacy risk.
No. Please stop spreading this nonsense that NAT is solution for security and privacy. NAT was solution for getting systems online without increasing address space. It served that well. Now it needs to die.
If you have security issues that is because you failed to configure your firewall properly. Besides Internet was always supposed to work the way IPv6 would allow.
If you have security issues that is because you failed to configure your firewall properly. Besides Internet was always supposed to work the way IPv6 would allow.
> If you have security issues that is because you failed to configure your firewall properly.
This works for us, but what about average people who have no idea what a firewall is?
This works for us, but what about average people who have no idea what a firewall is?
Make firewall accessible to average people. Create GUIs, guide them. I mean these are very basics of Internet.
All the major firewalls have GUIs. But try this with some of your non tech family, and tell me how difficult it was. Then imagine this on a global scale. Then imagine how many people are gonna disable said firewall to allow them to play some game or because something asked them too.
I didn't mention NAT. I'm comparing direct connections between peers with using a centralised server.
Enjoy playing an online shooter with extra 200ms of delay, or crappy calls on Teams where massive delay causes you to interrupt each other
Not all games use p2p for matches. Fortnite is the easiest example of one that’s not. Hell, games are not even built the same way anymore and what you think is a server is in reality a cluster of AWS services.
I play counter strike with a delay of around 10 ms with servers that are hosted hundreds of kilometres away.
You mean without? Well you're wrong. It's not a security concern at all. Allowing anyone from the outside to connect to any port they want is a security concern, simply because there's a lot of insecure software people run that doesn't account for malicious connections. However, allowing a user to intentionally let a piece of software listen for outside connections is in no way insecure.
> However, allowing a user to intentionally let a piece of software listen for outside connections is in no way insecure.
It is. Considering the kernel access often given to multiplayer games for anti cheat, and the abysmal attention to security and ability to write secure code by the average application developer, letting Internet randos send arbitrary instructions directly to your machine may not be the best idea.
It is. Considering the kernel access often given to multiplayer games for anti cheat, and the abysmal attention to security and ability to write secure code by the average application developer, letting Internet randos send arbitrary instructions directly to your machine may not be the best idea.
If the software is executing "arbitrary instructions" from remote sources, then its a malicious piece of software, or so horribly negligent to amount to the same thing. So I don't agree that direct connections are the problem - the badly written software is the problem.
> However, allowing a user to intentionally let a piece of software listen for outside connections is in no way insecure.
Unless you care about security of course. “A user” in your sentence can quite frequently be vulnerable or malicious software.
Unless you care about security of course. “A user” in your sentence can quite frequently be vulnerable or malicious software.
No, "a user" in my sentence is intended to mean a human. Its very possible to program software to require human approval for connections. Also, if malicious software is already running, then it will be able to make connections to remote servers that it wants, no need for it to passively listen. IPv6 does not make this problem worse.
It’s not nonsense though. The implementation of NAT literally implies a stateful firewall.
I want ipv4 dead as well but to bury your head in the sand and pretend NAT doesn’t offer the protections it does only hurts your argument.
> Besides Internet was always supposed to work the way IPv6 would allow.
Yep, but the real world - where all of the unpatched IoT devices are running - has NAT at basically every home protecting devices from unsolicited connections.
I want ipv4 dead as well but to bury your head in the sand and pretend NAT doesn’t offer the protections it does only hurts your argument.
> Besides Internet was always supposed to work the way IPv6 would allow.
Yep, but the real world - where all of the unpatched IoT devices are running - has NAT at basically every home protecting devices from unsolicited connections.
NAT doesn't imply stateful firewall at all. NAT is literally just rewriting IP addresses on incoming/outgoing packets. I could have a single machine behind a middlebox, and the middlebox could just rewrite the IP source/destination of egress/ingress packets, and that would be NAT - and I'd still be able to successfully receive incoming packets from the big bad web. In fact, you can do this without the middlebox using an iptables MASQUERADE rule.
But even then, the added security of a stateful firewall as provided by a router is dubious. You know what else has a "stateful firewall"? Your kernel's TCP/IP stack. It isn't gonna accept random connections from the Internet unless there is an application actively listening to a port and accepting packets. And I trust the Linux/NT/BSD kernel to be more secure with ensuring that than a binary firmware blob from a router manufacturer.
But even then, the added security of a stateful firewall as provided by a router is dubious. You know what else has a "stateful firewall"? Your kernel's TCP/IP stack. It isn't gonna accept random connections from the Internet unless there is an application actively listening to a port and accepting packets. And I trust the Linux/NT/BSD kernel to be more secure with ensuring that than a binary firmware blob from a router manufacturer.
Sorry, you’re very confused about the NAT that is widely deployed. It’s absolutely not 1:1 NAT because that buys effectively nothing from a scaling perspective.
> But even then, the added security of a stateful firewall as provided by a router is dubious. You know what else has a "stateful firewall"? Your kernel's TCP/IP stack. It isn't gonna accept random connections from the Internet unless there is an application actively listening to a port and accepting packets.
That’s the fucking problem. All kinds of vulnerable/misconfigured software just binds to 0.0.0.0:<whatever> and calls it good. My fridge does this, my washer does this, my TV does this. This is the world of IoT.
> And I trust the Linux/NT/BSD kernel to be more secure with ensuring that than a binary firmware blob from a router manufacturer
It’s not, it takes a single API call to have a program start listening because that’s the entire job of the kernel. You have to configure a firewall on top of it to make sure vulnerable software isn’t exposed to the internet.
> But even then, the added security of a stateful firewall as provided by a router is dubious. You know what else has a "stateful firewall"? Your kernel's TCP/IP stack. It isn't gonna accept random connections from the Internet unless there is an application actively listening to a port and accepting packets.
That’s the fucking problem. All kinds of vulnerable/misconfigured software just binds to 0.0.0.0:<whatever> and calls it good. My fridge does this, my washer does this, my TV does this. This is the world of IoT.
> And I trust the Linux/NT/BSD kernel to be more secure with ensuring that than a binary firmware blob from a router manufacturer
It’s not, it takes a single API call to have a program start listening because that’s the entire job of the kernel. You have to configure a firewall on top of it to make sure vulnerable software isn’t exposed to the internet.
The kind of NAT that's widely deployed doesn't act as a firewall though. It buys you nothing from a security perspective. It's entirely possible to connect inwards over a NATing router unless there's also an additional firewall configured.
Stateful NAT does imply state tracking, which is a major component needed to implement a stateful firewall, but it is not itself a stateful firewall.
Stateful NAT does imply state tracking, which is a major component needed to implement a stateful firewall, but it is not itself a stateful firewall.
"Beware of appeals to the 'real world'; and to what it supposedly demands. It is always an invitation to leave unchallenged the speaker's tacit assumptions."
Not demands. It’s just the reality of where we are. People who claim everything will improve by allowing p2p connections by default are woefully out of touch with the shit show that is IoT.
The IoT shitshow is never going to improve, if IoT device makers can't be made to stop offloading the cost of their laziness and bad systems thinking onto a network layer that was never intended, and is poorly suited, to be the ne plus ultra of device security.
NAT is not security. If some people need a relay because gamers commit harassment that can used on top of IPv6. Everyone else can connect directly to lower latency.
https://help.steampowered.com/en/faqs/view/1433-AD20-F11D-B7...
https://help.steampowered.com/en/faqs/view/1433-AD20-F11D-B7...
You can (and should) still have a firewall that only allows connections to specific ports when using IPv6.
Still you are revealing your IP address to the other parties, which will be more than happy to DoS you to force you to disconnect, exploit 0-days in the game networking code to crash your game or get your private info, know where you are located by IP geolocation...
The idea of P2P in competitive videogames strikes me as absolutely insane
The idea of P2P in competitive videogames strikes me as absolutely insane
When using NAT, you're revealing the IP address of your router. I don't know about you, but I don't have so many devices running on my home network that would drown out what I'm doing.
With NAT, you can still receive DoS attacks, still have your game networking exploited, and still be geolocated. The only remotely security-related benefit is that instead of your ports being exposed to the wild internet, they're exposed to your router which is more of a side-effect rather than an actual benefit. Its not a reason to not bother having a firewall.
With NAT, you can still receive DoS attacks, still have your game networking exploited, and still be geolocated. The only remotely security-related benefit is that instead of your ports being exposed to the wild internet, they're exposed to your router which is more of a side-effect rather than an actual benefit. Its not a reason to not bother having a firewall.
I didn't mention NAT at all. Practically all multiplayer games use a central server. It's impossible to know the IP addresses of your peers.
Nothing about IPv6 prevents continuing to do that when it makes sense (eg to prevent cheaters from dosing their opponents).
"The idea of P2P in competitive videogames strikes me as absolutely insane"
What's insane, is the idea that you want me to use and pay for some crappy AWS server that spies on my data instead of directly connecting to my friend using my own equipment
What's insane, is the idea that you want me to use and pay for some crappy AWS server that spies on my data instead of directly connecting to my friend using my own equipment
Well, have fun guessing 2^64 possibilities. YouTube lists even private videos "secured" using 11 BASE64 characters (66 bits in theory, but they seem to use just 64 bits). You can watch Tom Scott explain it: https://www.youtube.com/watch?v=gocwRvLhDf8
CG-NAT doesn't really prevent geolocation. Better services will still pin-point you to the nearest city. There are perhaps easier ways to get your private info or your money - phishing and ransomware seem to be still very popular. Don't have to hack games that only relatively few people have. It is more profitable to attack a bigger market or more wealthy institutions or companies in foreign countries. Also, if you hack the central game server, you will have a lot more victims... Choose your poison.
I guess, there are no games or other software that cannot be audited in high security installations. At home, having a work computer and a game computer (or a VM with GPU pass through or whatever) might be a safer choice in any case independent of IPv4 or IPv6 usage or the quality of your firewall.
CG-NAT doesn't really prevent geolocation. Better services will still pin-point you to the nearest city. There are perhaps easier ways to get your private info or your money - phishing and ransomware seem to be still very popular. Don't have to hack games that only relatively few people have. It is more profitable to attack a bigger market or more wealthy institutions or companies in foreign countries. Also, if you hack the central game server, you will have a lot more victims... Choose your poison.
I guess, there are no games or other software that cannot be audited in high security installations. At home, having a work computer and a game computer (or a VM with GPU pass through or whatever) might be a safer choice in any case independent of IPv4 or IPv6 usage or the quality of your firewall.
When it comes to DoS or geolocation, attackers can just as easily work with your router's address.
Getting rid of NAT doesn't mean that you have to let every machine connect to every other machine. It just means that if you choose to let machines connect, they can do so without their packets needing to be rewritten.
NAT and especially CGNAT has a tendancy to cause problems.
I vividly recall an incident where Jio's CGNAT was dropping idle TCP connections after 10 seconds of idle. (They fixed it, but I don't know if they fixed it for all destinations or only special destinations).
And, of course, I say dropping, rather than closing, because NAT usually doesn't send FINs to close sessions when they're dropped. So you only find out when you try to send more data. Some NATs don't even send RST when you send data on a connection it dropped, so you have to wait for a timeout.
There's also a capacity issue. If you're serving your website via a single IP (common with load balancers), you can only have 65535 connections from each client IP (assuming https on port 443 only, using non default ports is often a non-starter); if the user's ISP is sharing a very limited pool of IPs with a large number of users, it's conceivable that all the connections to your site could fill up.
I vividly recall an incident where Jio's CGNAT was dropping idle TCP connections after 10 seconds of idle. (They fixed it, but I don't know if they fixed it for all destinations or only special destinations).
And, of course, I say dropping, rather than closing, because NAT usually doesn't send FINs to close sessions when they're dropped. So you only find out when you try to send more data. Some NATs don't even send RST when you send data on a connection it dropped, so you have to wait for a timeout.
There's also a capacity issue. If you're serving your website via a single IP (common with load balancers), you can only have 65535 connections from each client IP (assuming https on port 443 only, using non default ports is often a non-starter); if the user's ISP is sharing a very limited pool of IPs with a large number of users, it's conceivable that all the connections to your site could fill up.
> if the user's ISP is sharing a very limited pool of IPs with a large number of users, it's conceivable that all the connections to your site could fill up.
Unless each of your users is establishing 600 connections to your site, this isn’t a realistic issue. I don’t know of ISPs that go beyond 1000:1 over-subscription.
Unless each of your users is establishing 600 connections to your site, this isn’t a realistic issue. I don’t know of ISPs that go beyond 1000:1 over-subscription.
[deleted]
I would argue that the main reason is that we are stuck with a centralized Internet with a somewhat large initial step to start a new service.
If everyone get IPv6 we are all able to be a first class citizen on the Internet, meaning I can run a webserver or whatever from home. Once I am ready I can move on to a hosting provider with all the extra costs and hassle it comes with.
Without IPv6, we are stuck with a two tier system of Internet users. Basically consumers and providers where the step to become a provider is larger than when you can simply start from home with whatever scrap you have in your garage.
IPv6 will also simplify a lot of things (being able to scrap NAT (note, you will still need a firewall) and avoid protocol issues for End-to-End services) but that is just a bonus.
IPv6 will also simplify a lot of things (being able to scrap NAT (note, you will still need a firewall) and avoid protocol issues for End-to-End services) but that is just a bonus.
We eventually run out of IPv4 addresses and have to switch anyway
That doesn't work as an explanation.
NAT was developed. CGNAT was developed. HTTP Host differentiation was developed. SNI was developed. STUN was developed. TURN was developed.
The main problem with IPv4 to IPv6 migration is the, frankly, overzealous utopia that "they will migrate anyway". Worse, it's very different that doesn't allow for a simple upgrade option of "IPv4, but longer addresses" because IPv6 is designed to be fundamentally different.
Which is more insulting considering that BGP was seamlessly upgraded from 65536 ASes to more than a million because they only changed the bits in an AS and nothing more. As a router developer, you only need to do the relatively minute changes of extended ASes than the (relative) mess that is IPv6.
NAT was developed. CGNAT was developed. HTTP Host differentiation was developed. SNI was developed. STUN was developed. TURN was developed.
The main problem with IPv4 to IPv6 migration is the, frankly, overzealous utopia that "they will migrate anyway". Worse, it's very different that doesn't allow for a simple upgrade option of "IPv4, but longer addresses" because IPv6 is designed to be fundamentally different.
Which is more insulting considering that BGP was seamlessly upgraded from 65536 ASes to more than a million because they only changed the bits in an AS and nothing more. As a router developer, you only need to do the relatively minute changes of extended ASes than the (relative) mess that is IPv6.
And now the internet got worse because you're no longer have technical freedom due to these NAT popping up everywhere. For example, previously if you want to release a video/voice chat app, you just release it and be done with it. Now it won't work like that due to NAT, so you'll have to maintain some STUN and TURN servers just to make your app usable to general public. Think about how many potential innovation got stifled because of added costs and complexity turned some people away before they even started.
I agree. It makes things much harder than it should be.
I wanted to try installing the module into my router so it would pass the WebRTC test for STUN/TURN and perhaps make video even more efficient to allow point to point connection instead of having everything be relayed through a tertiary server, but there was no documentation and having never set up a STUN/TURN server before I couldn't get it to work. So I am dependent on what a third party has set up to facilitate connectivity.
In the old days, you'd just connect to an IP address and that was it.
I wanted to try installing the module into my router so it would pass the WebRTC test for STUN/TURN and perhaps make video even more efficient to allow point to point connection instead of having everything be relayed through a tertiary server, but there was no documentation and having never set up a STUN/TURN server before I couldn't get it to work. So I am dependent on what a third party has set up to facilitate connectivity.
In the old days, you'd just connect to an IP address and that was it.
>NAT was developed. CGNAT was developed. HTTP Host differentiation was developed. SNI was developed. STUN was developed. TURN was developed
And every one of those has introduced its own security flaws and implementation bugs increasing the complexity of applications.
And every one of those has introduced its own security flaws and implementation bugs increasing the complexity of applications.
I'm advocating and helping networks to migrate to IPv6, but I'll say that IPv6 was rather a rats-nest design that shot itself in the foot. It's elegant sure, but as Torvalds would say to critics about his frequent use of goto, it's theoretically good but not sound engineering practice.
The thing is we would be addressing in 128-bit IP already if it was done the BGP way: just minimising the necessary changes to implement it. Look at the effectiveness of Itanium versus AMD64 at migrating customers: IPv6 feels like Itanium, while extended ASes work more like AMD64. Whoever designed IPv6 was focused too much at the theoreticals, than looking at what the real world is and then designing around it.
The thing is we would be addressing in 128-bit IP already if it was done the BGP way: just minimising the necessary changes to implement it. Look at the effectiveness of Itanium versus AMD64 at migrating customers: IPv6 feels like Itanium, while extended ASes work more like AMD64. Whoever designed IPv6 was focused too much at the theoreticals, than looking at what the real world is and then designing around it.
Can you suggest a way of extending v4's address space that works like BGP or AMD64 do?
I've asked a lot of people this question, and the only answers I've ever gotten are either impossible or already implemented by v6. Perhaps you will be the person to finally explain how to do it -- but as far as I can tell, it's just not possible, and I don't think it's fair to criticise v6 for not doing the impossible.
I've asked a lot of people this question, and the only answers I've ever gotten are either impossible or already implemented by v6. Perhaps you will be the person to finally explain how to do it -- but as far as I can tell, it's just not possible, and I don't think it's fair to criticise v6 for not doing the impossible.
Do we have anything for IPv4 similar to AMD64?
Or are we forever stuck with either going all in to IPv6 or the current hybrid?
Or are we forever stuck with either going all in to IPv6 or the current hybrid?
Nope, but we're deep in IPv6 anyways so the best course of action is to finish that, just be careful of the pitfalls and not devolving into silliness like this peering fight: https://www.theregister.com/2018/08/28/ipv6_peering_squabble...
IPv6 implementations are everywhere so the extra changes don't really impact networks.
Regardless of monentary charges (and I'm very aware of them, APNIC is even considering grants to help in IPv6 because it's in limbo for so long), even if we activate IPv6 synchronously there's still many, many problems with it, even when you permanently dual-stack it.
One is connectivity. Even theoretically we should have the same network connectivity (so to speak), you can feel the pettiness when Hurricane-Electric and Cogent fought exclusively on IPv6 (https://www.theregister.com/2018/08/28/ipv6_peering_squabble...) I can't believe I'm saying this, but IPv6 isn't free (or at least costs the same as IPv4).
Second is security. Yes, the world is no longer scannable, but consumer routers are a dud when it comes to IPv6 security. This router (https://pierrekim.github.io/blog/2021-01-12-fiberhome-ont-0d...) has serious problems at IPv6 security, and because it's suffix is always at ::0000:0000:0000:0001 and you've eliminate around 18 bits more because of how networks are laid, you've got yourself an IPv6 botnet, which speaking by, how do you block them? A /64 would be a good start, but OVH provides a single address per server (https://www.ovhcloud.com/vps/compare/). That's it. Don't forget that fiasco with MAC addresses (https://datatracker.ietf.org/doc/html/rfc8981), but at least that's solved.
Third, IPv6 should just work as you said. I wish that's true, but embedded devices will trip you up badly. Some don't fallback to IPv4 and instead try and try again using IPv6. This would be a concern while transitioning, but even after that, some would be still stuck because their servers are only operating on IPv4!
Implementing IPv6 is not free lunch if you know the gritty details.
One is connectivity. Even theoretically we should have the same network connectivity (so to speak), you can feel the pettiness when Hurricane-Electric and Cogent fought exclusively on IPv6 (https://www.theregister.com/2018/08/28/ipv6_peering_squabble...) I can't believe I'm saying this, but IPv6 isn't free (or at least costs the same as IPv4).
Second is security. Yes, the world is no longer scannable, but consumer routers are a dud when it comes to IPv6 security. This router (https://pierrekim.github.io/blog/2021-01-12-fiberhome-ont-0d...) has serious problems at IPv6 security, and because it's suffix is always at ::0000:0000:0000:0001 and you've eliminate around 18 bits more because of how networks are laid, you've got yourself an IPv6 botnet, which speaking by, how do you block them? A /64 would be a good start, but OVH provides a single address per server (https://www.ovhcloud.com/vps/compare/). That's it. Don't forget that fiasco with MAC addresses (https://datatracker.ietf.org/doc/html/rfc8981), but at least that's solved.
Third, IPv6 should just work as you said. I wish that's true, but embedded devices will trip you up badly. Some don't fallback to IPv4 and instead try and try again using IPv6. This would be a concern while transitioning, but even after that, some would be still stuck because their servers are only operating on IPv4!
Implementing IPv6 is not free lunch if you know the gritty details.
tell me you're bad at math without telling me you're bad at math.
IPv4 address space exhaustion. NAT breaks end-to-end connectivity, making entire classes of applications difficult to deploy, and this is made worse when the NAT gateway is not under a user's control. NAT gateway deployed by ISPs represent a violation of the end-to-end principle and have to be even more complex and stateful than the NAT gateways users often deploy. If you are looking for a specific problem NAT introduces, one good one is that NAT forces users and application developers to use protocols that the NAT gateway properly supports (e.g. TCP, UDP) and to only use those protocols in ways that are "NAT-friendly" (e.g. easy-to-track client-server sessions that are initiated from the private side the gateway) or else to use some NAT-specific protocol as a crutch (UPnP/IGD, STUN, etc.). When both ends of a two-party protocol are behind NAT gateways it can become even more painful and possibly require a third party to be introduced to an application that is otherwise unnecessary for the application.
So at a minimum IPv6 gets us back to the end-to-end principle where Internet peers connect directly to each other without having to negotiate with the network itself. There are a few other advantages, like the fact that users can get large, publicly-routed addresses spaces for their own use (e.g. ISPs giving users a /56 prefix), simplified bridging of private networks (very low probability of collisions in the private IPv6 range), simplified router configuration (link-local addresses are always available so there is no need to assign numbers to every link), and other assorted niche benefits. In theory IPv6 should mean routers become more efficient because it is easier to aggregate prefixes, which should generally benefit Internet users by reducing latency (though at this point there is not much room left for improvement there).
So at a minimum IPv6 gets us back to the end-to-end principle where Internet peers connect directly to each other without having to negotiate with the network itself. There are a few other advantages, like the fact that users can get large, publicly-routed addresses spaces for their own use (e.g. ISPs giving users a /56 prefix), simplified bridging of private networks (very low probability of collisions in the private IPv6 range), simplified router configuration (link-local addresses are always available so there is no need to assign numbers to every link), and other assorted niche benefits. In theory IPv6 should mean routers become more efficient because it is easier to aggregate prefixes, which should generally benefit Internet users by reducing latency (though at this point there is not much room left for improvement there).
Amazon enabled IPv6 for various CDN endpoints serving images and static assets this year. At least they've made progress.
A few years ago when forcing Reddit to IPv6 through /etc/hosts many pages resulted in 500 errors, but they gradually fixed them.
A few years ago when forcing Reddit to IPv6 through /etc/hosts many pages resulted in 500 errors, but they gradually fixed them.
You're right about other sites, but Hotstar does support IPv6:
$ dig +short AAAA www.hotstar.com
www.hotstar.com-sni.edgekey.net.
e35862.dscj.akamaiedge.net.
2600:140f:7800::1730:f420
2600:140f:7800::1730:f421
2600:140f:7800::17d7:d7b9
2600:140f:7800::17d7:d7a9
2600:140f:7800::1730:f449Some of those sites have mobile apps on the Apple app store. How does not supporting IPv6 on their site reconcile with Apple's requirement that apps that support networking work when on an IPv6-only network?
I would have thought that an app that is purportedly an app for site X but that cannot actually talk to site X when on an IPv6-only network would fail that requirement, but maybe I'm overestimating what Apple actually checks. Are they only checking that the app will correctly attempt an IPv6 connection to the site?
I would have thought that an app that is purportedly an app for site X but that cannot actually talk to site X when on an IPv6-only network would fail that requirement, but maybe I'm overestimating what Apple actually checks. Are they only checking that the app will correctly attempt an IPv6 connection to the site?
The App Store only requires Apps to work on networks employing DNS64/NAT64 [0].
That means the app internally needs to be able to handle IPv6 addresses and not hardcore any IPv4 addresses as those can’t be reached. There’s no requirement that the service underlying the app is directly reachable via IPv6.
0: https://developer.apple.com/support/ipv6/
That means the app internally needs to be able to handle IPv6 addresses and not hardcore any IPv4 addresses as those can’t be reached. There’s no requirement that the service underlying the app is directly reachable via IPv6.
0: https://developer.apple.com/support/ipv6/
Once upon a time I had an original iPhone and a router that did nor have ipv6, but the App Store worked. So I don’t understand your "ipv4 addresses can’t be reached" part.
On some people's phones IPv4 addresses can't be reached. Their carrier doesn't bother moving IPv4 over a network that doesn't need IPv4. It does translation at the edge, and the iPhone is OK with that.
Apple's requirement is that even though you know your server is definitely 10.20.30.40† on the public network, and you hate IPv6 you must not hard code 10.20.30.40 inside the app and ship that to the App Store.
Once you reluctantly change it to a DNS name ten-twenty-thirty-forty.fuck-off-apple.example that resolves to 10.20.30.40 - Apple allows that.
Because now when your app is used on some IPv6-only carrier network, the carrier goes "ten-twenty-thirty-forty.fuck-off-apple.example ?" and it gets 10.20.30.40 and it says that's an IPv4 address, don't use those around here, and it adds a translator step, it gives the phone an IPv6 address for ten-twenty-thirty-forty.fuck-off-apple.example and the phone connects to that address, which is a translator that connects to 10.20.30.40 on the IPv4 Internet.
This stuff happens all the time and you don't notice. But if Apple allowed app vendors to just scribble IPv4 addresses inside their app software it would break.
† No that isn't a public IP address. It's an example.
Apple's requirement is that even though you know your server is definitely 10.20.30.40† on the public network, and you hate IPv6 you must not hard code 10.20.30.40 inside the app and ship that to the App Store.
Once you reluctantly change it to a DNS name ten-twenty-thirty-forty.fuck-off-apple.example that resolves to 10.20.30.40 - Apple allows that.
Because now when your app is used on some IPv6-only carrier network, the carrier goes "ten-twenty-thirty-forty.fuck-off-apple.example ?" and it gets 10.20.30.40 and it says that's an IPv4 address, don't use those around here, and it adds a translator step, it gives the phone an IPv6 address for ten-twenty-thirty-forty.fuck-off-apple.example and the phone connects to that address, which is a translator that connects to 10.20.30.40 on the IPv4 Internet.
This stuff happens all the time and you don't notice. But if Apple allowed app vendors to just scribble IPv4 addresses inside their app software it would break.
† No that isn't a public IP address. It's an example.
> † No that isn't a public IP address. It's an example.
“The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3) are provided for use in documentation.”
— RFC 5737, IPv4 Address Blocks Reserved for Documentation https://www.rfc-editor.org/rfc/rfc5737.html
“The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3) are provided for use in documentation.”
— RFC 5737, IPv4 Address Blocks Reserved for Documentation https://www.rfc-editor.org/rfc/rfc5737.html
Noted, but 10.20.30.40 kinda trips off the tongue.
So did 1.1.1.1, which led to a lot of trouble when it started being widely used.
Unlike 1.1.1.1, 10.20.30.40 is reserved in RFC1918, you mustn't use it on the Network. So I don't have to care
(No I don't use RFC1918 addressing at home; Yes, every machine in my home has public IPv4 and/or IPv6 addresses; No that doesn't make it "really easy to break in" because having an address is not the same thing as being accessible)
(No I don't use RFC1918 addressing at home; Yes, every machine in my home has public IPv4 and/or IPv6 addresses; No that doesn't make it "really easy to break in" because having an address is not the same thing as being accessible)
Why is it crazy? They don't gain anything by supporting IPv6.
If you can do direct consumer mobile phone IPv6 to server IPv6 there are benefits in latency, throughput, congestion control, analytics and so on. A better user experience. Depending on the hosting setup and networks, this may or may not be significant.
carrier NAT is unlikely to introduce measurable latency, especially in wireless networks. I agree that IPv6 allows for better user tracking, probably that's one of the reasons to adopt it. For example iPhones are virtually indistinguishable from each other, so the only reliable way to track them is cookie or IP address.
It costs money to buy and maintain CG NAT infrastructure. Local authorities will demand you log who had what IP address at the time of interest.
IPv4 or CGNAT costs are not optional. You will have to pay them regardless of if you deploy IPv6 or not.
IPv4 and CGNAT costs scale with usage. The more traffic you offload to IPv6, the less CGNAT capacity you need and the less IPv4 space you need; you need enough IPv4 addresses so you can give out unique IP:Ports for all concurrent connections to popular destination IP:Ports.
None of those are arguments for why IPv4 or CGNAT costs are optional; you cannot run an ISP without IPv4 or CGNAT, therefore the IPv4 or CGNAT costs are not optional. You will incur them regardless of if you deploy IPv6 or not.
If you deploy IPv6, you might not deploy CGNAT, but unless you are dual stacking, something functionally equivalent is required.
As to scaling costs, IPv6 offload isn’t a 1:1 replacement for IPv4 or CGNAT capacity. You need enough capacity to carry the IPv6 traffic over IPv4 in case your IPv6 transport, transit or peers fail. Again, not optional.
If you deploy IPv6, you might not deploy CGNAT, but unless you are dual stacking, something functionally equivalent is required.
As to scaling costs, IPv6 offload isn’t a 1:1 replacement for IPv4 or CGNAT capacity. You need enough capacity to carry the IPv6 traffic over IPv4 in case your IPv6 transport, transit or peers fail. Again, not optional.
Parent commenter wasn't saying that CG NAT costs could be avoided entirely. Deploying IPv6 gets Netflix, YouTube, Facebook and other popular traffic to connect directly. That means less racks of CG NAT.
Like I said, you can only avoid CGNAT costs if you accept the failure modes inherent if/when your IPv6 fails.
Thus in a properly designed network these are not optional costs.
Thus in a properly designed network these are not optional costs.
You do avoid some of the cost, because you can direct a significant amount of your traffic over v6 and not need to CGNAT it.
The failure mode for your v6 failing is the same as it is for v4 failing in a v4-only ISP: stuff breaks. If you want to fix that you need a redundant failover setup, which is the same thing you need in v4 except cheaper because it doesn't need to do CGNAT.
The failure mode for your v6 failing is the same as it is for v4 failing in a v4-only ISP: stuff breaks. If you want to fix that you need a redundant failover setup, which is the same thing you need in v4 except cheaper because it doesn't need to do CGNAT.
> You need enough capacity to carry the IPv6 traffic over IPv4 in case your IPv6 transport, transit or peers fail. Again, not optional.
Surely you need enough IPv6 capacity incase your IPv4 transit fails as well. If JIO could have built enough IPv4 capacity to run their network over IPv4, they would have, but they can't, so they've been pushing IPv6 hard.
Surely you need enough IPv6 capacity incase your IPv4 transit fails as well. If JIO could have built enough IPv4 capacity to run their network over IPv4, they would have, but they can't, so they've been pushing IPv6 hard.
You are likely to be unable to source the missing IPv4 traffic over IPv6.
I’m not familiar with JIO’s setup, but that’s an interesting question. If their IPv6 was down, would their network still be able to deliver? Would they run out of CGNAT capacity or IPv4 translations?
I’m not familiar with JIO’s setup, but that’s an interesting question. If their IPv6 was down, would their network still be able to deliver? Would they run out of CGNAT capacity or IPv4 translations?
Less racks of CG NAT. Deploying IPv6 gets Netflix, YouTube, Facebook and other popular traffic to connect directly.
Wouldn't that cost be easy to pass along to the customers though? Assuming the authorities aren't discriminating against a single ISP, then all the ISP's can just raise their price at the same time.
Or have I been living with Canadian ISPs too long and that sort of thing doesn't happen in the rest of the world?
Or have I been living with Canadian ISPs too long and that sort of thing doesn't happen in the rest of the world?
It's super weird you think passing costs onto consumers makes the problem go away. When a company passes costs to their consumers, consumers buy their product less, so that company loses money anyway.
Sorry, i am concerned about me, the consumer, loosing money
You do lose money because they raised the prices.
CGNAT is a consumer nightmare that makes them a second class citizen dependent on large providers to offer services.
I all the studies I have seen, ipv6 enabled networks outperform ipv4 only networks in term of latency.
Improved latency mean improved responsiveness, and that in turn has companies claiming improved user retention and sales.
If you need an argument to support ipv6, those seems like good reasons to support ipv6.
Improved latency mean improved responsiveness, and that in turn has companies claiming improved user retention and sales.
If you need an argument to support ipv6, those seems like good reasons to support ipv6.
I can’t see any difference in latency in the services I use between IPv4 and IPv6.
What I want to know is do all these studies take into consideration the “happy eyeballs” algorithm that prefers IPv6 over IPv4 in web browser requests, thus delaying the IPv4 request?
What I want to know is do all these studies take into consideration the “happy eyeballs” algorithm that prefers IPv6 over IPv4 in web browser requests, thus delaying the IPv4 request?
The latency in question has to do with routers. IPv6 packets have a simpler header that does not force routers to recompute a checksum for each hop, and IPv6 allows better route aggregation which reduces the CPU overhead of route selection in some cases.
I am unaware of any router forwarding IPv4 packets slower than IPv6 packets. Can you back up this claim with any sources?
Route aggregation or selection does not impact forwarding performance on a router.
Route aggregation or selection does not impact forwarding performance on a router.
I've heard this claim too: apparently Facebook tested a lot of routers, and they consistently routed v6 ~500us faster than v4. v6 has no checksum, so routers don't need to recalculate it when they decrement the TTL header, and it does make sense that removing a step would help. Unfortunately my source for this is "I heard it from someone that works at Facebook".
In practice this is only a small part of final performance, so you need to do end-to-end measurements to get a proper idea of what people will experience. Both Facebook[1] and Apple[2] have done that, showing 10% faster page loads and 40% faster connection establishment respectively on v6. Even if that was solely down to routing policies, it's still a measurable difference.
[1] https://engineering.fb.com/2015/09/14/networking-traffic/ipv...
[2] https://www.sidn.nl/en/news-and-blogs/apple-connections-esta...
In practice this is only a small part of final performance, so you need to do end-to-end measurements to get a proper idea of what people will experience. Both Facebook[1] and Apple[2] have done that, showing 10% faster page loads and 40% faster connection establishment respectively on v6. Even if that was solely down to routing policies, it's still a measurable difference.
[1] https://engineering.fb.com/2015/09/14/networking-traffic/ipv...
[2] https://www.sidn.nl/en/news-and-blogs/apple-connections-esta...
A few years old but here you go:
https://www.retevia.net/fast/
In some cases, yes, the routing table size will impact performance; for example if the FIB is too big to fit in TCAM:
https://labs.apnic.net/?p=520
Note that this particular incident was caused by deaggregation of routes announced by Verizon, and that had the routes been properly aggregated it could have been avoided (though normal routing table growth would have eventually caused the problem anyway).
https://www.retevia.net/fast/
In some cases, yes, the routing table size will impact performance; for example if the FIB is too big to fit in TCAM:
https://labs.apnic.net/?p=520
Note that this particular incident was caused by deaggregation of routes announced by Verizon, and that had the routes been properly aggregated it could have been avoided (though normal routing table growth would have eventually caused the problem anyway).
Oh, come on!
Geoff’s article on TCAM exhaustion is almost 10 years old. No BGP router in the default free zone has had a 512k route limit in years. Modern routers typically scale to millions of routes.
The incident in question was the result of misconfiguration and/or ISPs trying to run old routers past their usable life.
The whole thing was completely avoidable and not related to IPv4 vs IPv6 forwarding performance.
As to the IPv6 latency article, it can best be summarized as IPv6 sometimes has lower latency than IPv4, except when it doesn’t.
In no shape, way or form does the article claim that IPv6 forwarding performance is better than IPv4 forwarding performance.
There’s some hand waving about NAT, but it also notes that increasing the number of NAT levels improved latency!
The simplest explanation is that the differences come down to different routing policies in IPv4 and IPv6. Thus it depends on where you stand as to what you see.
Geoff’s article on TCAM exhaustion is almost 10 years old. No BGP router in the default free zone has had a 512k route limit in years. Modern routers typically scale to millions of routes.
The incident in question was the result of misconfiguration and/or ISPs trying to run old routers past their usable life.
The whole thing was completely avoidable and not related to IPv4 vs IPv6 forwarding performance.
As to the IPv6 latency article, it can best be summarized as IPv6 sometimes has lower latency than IPv4, except when it doesn’t.
In no shape, way or form does the article claim that IPv6 forwarding performance is better than IPv4 forwarding performance.
There’s some hand waving about NAT, but it also notes that increasing the number of NAT levels improved latency!
The simplest explanation is that the differences come down to different routing policies in IPv4 and IPv6. Thus it depends on where you stand as to what you see.
The pain is most felt by the ISPs which need to supply lots of ip addresses to their customers, while you need only few ip addresses for running an internet service (compared to the number of users/customers). There is little improvement in user experience and you need to change a lot of infrastructure to also support ipv6 addresses. So websites don't do it, sadly.
The main reason for this is Jio, a new mobile phone network that began in 2010s. They built a 4G only network (not 5G) and used IPv6 from day 1 for their phones. Reference: https://conference.apnic.net/50/assets/files/APCS790/Harness...
[deleted]
[deleted]
IPv6 is a perfect example of where a legislator can make a positive market impact. I like market principles, but relying on market alone for this just leads to local optimum (squeezing every last drop from IPv4 with various hacks).
Just mandate that every ISP must provide IPv6 for new contracts within a year and then for all existing contract within two - or whatever reasonable timeline - and be done with it.
Just mandate that every ISP must provide IPv6 for new contracts within a year and then for all existing contract within two - or whatever reasonable timeline - and be done with it.
Didn't the US government require that all cloud services provided to and by the government be done over IPv4 and IPv6 some time ago?
In opening another tab to answer my own question, I see that they've broadened the scope and that the US government networks should be IPv6-only, with some caveats I'm sure, by 2023: https://fedtechmagazine.com/article/2021/03/how-make-progres...
In opening another tab to answer my own question, I see that they've broadened the scope and that the US government networks should be IPv6-only, with some caveats I'm sure, by 2023: https://fedtechmagazine.com/article/2021/03/how-make-progres...
The cynic in me wants to know if all government cloud services support IPv6 as mandated, on paper only or in practice? :)
The linked article isn’t as ambitious as to claim IPv6-only government networks by 2023, only that new systems should support IPv6 by 2023.
I’d also be very surprised if the government was able to hit any of the IPv6-only targets put forth in the article.
The linked article isn’t as ambitious as to claim IPv6-only government networks by 2023, only that new systems should support IPv6 by 2023.
I’d also be very surprised if the government was able to hit any of the IPv6-only targets put forth in the article.
Forcing IPv6 upon ISPs by decree will only make them do the very least possible in order to be able to check a box.
To truly drive IPv6 adoption there has to be a real need for IPv6 and/or a revenue driver.
Very large ISPs and mobile carriers need IPv6 because they are simply running out of IPv4 addresses, even non-public IPv4 addresses!
This still does not mean they can go IPv6-only, they still need IPv4 and translation technologies to reach the Internet.
The core problem of IPv6 adoption is that insensitive do not align across the whole Internet ecosystem.
To truly drive IPv6 adoption there has to be a real need for IPv6 and/or a revenue driver.
Very large ISPs and mobile carriers need IPv6 because they are simply running out of IPv4 addresses, even non-public IPv4 addresses!
This still does not mean they can go IPv6-only, they still need IPv4 and translation technologies to reach the Internet.
The core problem of IPv6 adoption is that insensitive do not align across the whole Internet ecosystem.
"Forcing IPv6 upon ISPs by decree will only make them do the very least possible in order to be able to check a box."
Which is more than they are doing now.
What real-world issues do you forcee. IPv6 either works, or doesn't
Which is more than they are doing now.
What real-world issues do you forcee. IPv6 either works, or doesn't
> IPv6 either works, or doesn't
Oh, you sweet summer child! :)
IPv6 “just works” only if you completely control the routing stack end-to-end.
Once end user equipment and hosts are introduced into the network all bets are off.
In a mobile network, where the carrier controls what user terminals are allowed on the network, it is at least nominally possible to achieve “just works” status.
So, in the real world, forcing IPv6 would result in IPv6 being supported only in a particular configuration used in a particular way. Everybody will be told to go pound sand and no effort will be made to keep IPv6 working or prevent breakage.
Oh, you sweet summer child! :)
IPv6 “just works” only if you completely control the routing stack end-to-end.
Once end user equipment and hosts are introduced into the network all bets are off.
In a mobile network, where the carrier controls what user terminals are allowed on the network, it is at least nominally possible to achieve “just works” status.
So, in the real world, forcing IPv6 would result in IPv6 being supported only in a particular configuration used in a particular way. Everybody will be told to go pound sand and no effort will be made to keep IPv6 working or prevent breakage.
"Websites larger than X have to be IPv6-only" would probably do the trick to force adoption.
Right now though, we'd be more in need of "websites and -services larger than X have to support IPv6".
Right now though, we'd be more in need of "websites and -services larger than X have to support IPv6".
This is a nonstarter. Forcing services to go IPv6-only would deprive the majority of Internet users of their services.
I can just about imagine the shitstorm and political blowback that would entail.
Even just forcing IPv6 support would be a tough row to hoe.
I can just about imagine the shitstorm and political blowback that would entail.
Even just forcing IPv6 support would be a tough row to hoe.
If announced with a sufficient amount of time and credibility, it would force ISPs to implement it.
It would potentially help them to take it more seriously if there were planned outage windows (i.e. "IPv6-only for 1 day after the law was passed, then IPv6-only for 1 week 6 months after, then permanently IPv6-only after 2 years").
ISPs would probably just take the 1-day outage and ignore customer complaints for a day. By the time the week long outage would come closer without the date being delayed, they'd start taking the issue seriously.
It would potentially help them to take it more seriously if there were planned outage windows (i.e. "IPv6-only for 1 day after the law was passed, then IPv6-only for 1 week 6 months after, then permanently IPv6-only after 2 years").
ISPs would probably just take the 1-day outage and ignore customer complaints for a day. By the time the week long outage would come closer without the date being delayed, they'd start taking the issue seriously.
Announced by who? The United World Government?
And who exactly are you forcing? Now it’s ISPs, in your previous comment is was websites.
Anyway, it’s not enough to force one participant. If you are going IPv6-only by decree, you have to replace all end user devices too.
Who is going to pay for all the new routers, game consoles, nanny cams, etc? I’m sure that container ships’ worth of PS5s is going to go well over in the appropriations committee.
The truth is, it’s too late in the game for an IPv6 flag day. Too many people and too much money involved.
And who exactly are you forcing? Now it’s ISPs, in your previous comment is was websites.
Anyway, it’s not enough to force one participant. If you are going IPv6-only by decree, you have to replace all end user devices too.
Who is going to pay for all the new routers, game consoles, nanny cams, etc? I’m sure that container ships’ worth of PS5s is going to go well over in the appropriations committee.
The truth is, it’s too late in the game for an IPv6 flag day. Too many people and too much money involved.
> Announced by who? The United World Government?
Yes, also known as the US government, because that's where those services are located, and who ultimately controls 99% of the Internet through .com/.net/.org.
"Domains with more than (some definition of "big") under .com/.net/.org must not point to nameservers announcing A records for any of the subdomains. DNS server operators serving more than X clients must report aggregate statistics."
Is it practical? Realistic? A good idea? Probably neither. But it would be a feasible way to ensure IPv6 support, with worldwide effects.
> Now it’s ISPs, in your previous comment is was websites.
The government forces website operators to offer only IPv6. As a result, ISPs that don't support IPv6 are about as useful as a provider that drops a wet string at your doorstep. Thus, in order to be useful and deliver a service worth paying for to your customers, ISPs would be forced to support IPv6, even without a legal mandate.
Due to the dominance of US web services, the US doing this would force this upon ISPs worldwide.
> you have to replace all end user devices
In most cases, not the devices, only the software, or rather, the configuration on it.
> container ships’ worth of PS5s
The PS4 and 5 support IPv6 according to what I found. https://toreanderson.github.io/2021/02/23/ipv6-support-in-th...
Most importantly, in the proposed model, Sony would most likely fall under "larger than X" if services were included, i.e. they'd have to switch to IPv6-only too (and issue updates to support that or leave their users stranded).
Maybe add an exemption for services supporting systems last sold more than X years ago.
Yes, also known as the US government, because that's where those services are located, and who ultimately controls 99% of the Internet through .com/.net/.org.
"Domains with more than (some definition of "big") under .com/.net/.org must not point to nameservers announcing A records for any of the subdomains. DNS server operators serving more than X clients must report aggregate statistics."
Is it practical? Realistic? A good idea? Probably neither. But it would be a feasible way to ensure IPv6 support, with worldwide effects.
> Now it’s ISPs, in your previous comment is was websites.
The government forces website operators to offer only IPv6. As a result, ISPs that don't support IPv6 are about as useful as a provider that drops a wet string at your doorstep. Thus, in order to be useful and deliver a service worth paying for to your customers, ISPs would be forced to support IPv6, even without a legal mandate.
Due to the dominance of US web services, the US doing this would force this upon ISPs worldwide.
> you have to replace all end user devices
In most cases, not the devices, only the software, or rather, the configuration on it.
> container ships’ worth of PS5s
The PS4 and 5 support IPv6 according to what I found. https://toreanderson.github.io/2021/02/23/ipv6-support-in-th...
Most importantly, in the proposed model, Sony would most likely fall under "larger than X" if services were included, i.e. they'd have to switch to IPv6-only too (and issue updates to support that or leave their users stranded).
Maybe add an exemption for services supporting systems last sold more than X years ago.
This is hilarious!
I sincerely wish the US would try a stunt like this, if not for anything else then for the entertainment aspect. I emphatically don’t think it would work out as you’d expect.
I sincerely wish the US would try a stunt like this, if not for anything else then for the entertainment aspect. I emphatically don’t think it would work out as you’d expect.
Don't force IPv6. Make IPv4 illegal. Now they can't half-ass the IPv6 support.
Hard pass. Nobody wants more government involvement. Not to mention the unspeakable amount of waste and chaos this would entail.
If regulation is to be attempted, we gotta do it right. Can't leave loopholes around to make things cheaper for them and worse for everybody else. They should have literally no choice but the right one. Waste and chaos don't matter. Do things right or give up.
Letting them keep IPv4 resulted in them dragging their ass, implementing NAT everywhere and killing end-to-end conectivity on the internet, repurposing IPv4 as a reputation system, god knows what else. We gotta get rid of it.
Letting them keep IPv4 resulted in them dragging their ass, implementing NAT everywhere and killing end-to-end conectivity on the internet, repurposing IPv4 as a reputation system, god knows what else. We gotta get rid of it.
Good regulation is really, really hard. Who do you trust enough to even attempt it?
Waste and chaos matter. Or how is your pandemic going?
Waste and chaos matter. Or how is your pandemic going?
If anything, this pandemic proves just how unprepared the world is for such events despite historical knowledge of pandemics. The right thing to do is to devote resources towards preparation for a future pandemic. This is going to cost a lot of money. They won't want to do it.
Simpler: put a cap on the number of IPv4 addresses that can be transferred per quarter, and lower that cap each quarter.
This just cements the IPv4 incumbents as winners.
I think you might be overlooking network effects (pun intended).
Yes, the current incumbents will buy up all the IPv4 addresses they can before trading stops. That will cement them as the permanent winners for IPv4 services.
But with IPv4 addresses no longer tradable, hosting companies and ISPs will have no choice but to adopt IPv6 if they want to grow. New hosting companies and ISPs will be IPv6-only.
I'd expect at that point most large mobile networks, which are largely IPv6 already with IPv6 compatibility bolted on so customers can reach IPv4-only sites, to go IPv6-only.
There will be legacy applications that still need a real IPv4 address on the server side. The current incumbents will end up cemented as the winners of that service.
Yes, the current incumbents will buy up all the IPv4 addresses they can before trading stops. That will cement them as the permanent winners for IPv4 services.
But with IPv4 addresses no longer tradable, hosting companies and ISPs will have no choice but to adopt IPv6 if they want to grow. New hosting companies and ISPs will be IPv6-only.
I'd expect at that point most large mobile networks, which are largely IPv6 already with IPv6 compatibility bolted on so customers can reach IPv4-only sites, to go IPv6-only.
There will be legacy applications that still need a real IPv4 address on the server side. The current incumbents will end up cemented as the winners of that service.
You assume new entrants or smaller entities would have a fighting chance in this scenario. They would not.
The incumbents would become king makers. They would decide which services would be allowed on the IPv4 Internet, which would be the only Internet, and which services would be allowed to prosper.
The incumbents would either acquire all successful startups and smaller companies or clone their services.
New entrants would wither on the wine on this obscure IPv6-only network that hardly anybody knows about or is able to access.
This would also kill off IPv6 completely. The incumbents would have a collective interest in maintaining and propping up their position. IPv6 would be a threat to this, so it would be given the axe.
This isn’t some far out fantasy either. This is how mobile phone services worked during the SMS era before the Internet was a thing.
The incumbents would become king makers. They would decide which services would be allowed on the IPv4 Internet, which would be the only Internet, and which services would be allowed to prosper.
The incumbents would either acquire all successful startups and smaller companies or clone their services.
New entrants would wither on the wine on this obscure IPv6-only network that hardly anybody knows about or is able to access.
This would also kill off IPv6 completely. The incumbents would have a collective interest in maintaining and propping up their position. IPv6 would be a threat to this, so it would be given the axe.
This isn’t some far out fantasy either. This is how mobile phone services worked during the SMS era before the Internet was a thing.
IPv6 is a bad technical standard to begin with (which is on of the reasons behind slow adoption). Forcing it with legislation would only make everyone involved to hate it more.
> IPv6 is a bad technical standard to begin with
Can you expound on why you think this is the case?
Can you expound on why you think this is the case?
Not GP, but I think IPv6 is generally fine. The big issue is around mid sized enterprises, where multi homing becomes a need and for so long PI address space was reserved for peering-sizes entities. This makes sense from the perspective of reducing routing table size, but to date there’s no good way to do multihoming with multiple PA blocks (there are ways, but they all suck).
The IETF really needs to fix this issue in particular, it’s the last big hurdle in seeing adoption IMO.
The IETF really needs to fix this issue in particular, it’s the last big hurdle in seeing adoption IMO.
What would a good solution to that even look like? Giving every mid-sized company it's own PI block would massively bloat the routing table so that's not going to happen. The solution space that's left basically comes down to some form of NAT/NPT or multi-home support at the endpoints. The IETF's preferred solution is the latter which seems reasonable to me.
I fully agree that giving PI blocks out like candy is not the ideal solution - but the solutions for dealing with multiple PA spaces are woefully inadequate right now. I’d really like to see the IETF step in here and come up with some workable proposals before we ruin IPv6 while it’s still possible to fix these issues.
> but to date there’s no good way to do multihoming with multiple PA blocks (there are ways, but they all suck).
Is using ULA and NPTv6 any worse than using NAT44?
Is using ULA and NPTv6 any worse than using NAT44?
It’s not - but that doesn’t mean it’s a good solution. Clients should be able to know their globally routable address and ULA with NPTv6 seriously fucks with that, so I’m not a fan.
PI was never reserved for peering sized entities... just get PI space.
Depending on the tech skills of the organizations, your ISP(s) may have to run BGP on your behalf--even if the IPv6 is yours. (Not sure if that's even a thing.)
I'm not the person you are responding to, but from what I understand the main issues are:
ipv6 is not backwards compatible with ipv4.
Consequently adding support for ipv6 requires a dual stack solution (since supporting ipv4 is a must).
An alternative solution to the problem of the limited number of ipv4 addresses has been reliance on NATs. This is much simpler than supporting ipv6 and is already widely adopted everywhere, and so that's what people are choosing to do.
The obvious conclusion (from a casual observer like myself): the successor to ipv4 has to be backwards compatible with it, similar to how UTF-8 is backwards compatible with ASCII.
EDIT: I should note that I am not a network engineer, so if anything I have written is incorrect, I hope someone corrects me.
ipv6 is not backwards compatible with ipv4.
Consequently adding support for ipv6 requires a dual stack solution (since supporting ipv4 is a must).
An alternative solution to the problem of the limited number of ipv4 addresses has been reliance on NATs. This is much simpler than supporting ipv6 and is already widely adopted everywhere, and so that's what people are choosing to do.
The obvious conclusion (from a casual observer like myself): the successor to ipv4 has to be backwards compatible with it, similar to how UTF-8 is backwards compatible with ASCII.
EDIT: I should note that I am not a network engineer, so if anything I have written is incorrect, I hope someone corrects me.
> ipv6 is not backwards compatible with ipv4.
I've seen this objection, and I do not see how it could be otherwise.
If all the code out there was for 32-bit-only addresses (of IPv4), then expanding the addresses space to something >32 bits would entailed updating every single IP-capable code. Which is exactly that needed to be done for IPv6: every device needed to have code updated (and this included 'hardware code' of things like ASICs).
I've seen this objection, and I do not see how it could be otherwise.
If all the code out there was for 32-bit-only addresses (of IPv4), then expanding the addresses space to something >32 bits would entailed updating every single IP-capable code. Which is exactly that needed to be done for IPv6: every device needed to have code updated (and this included 'hardware code' of things like ASICs).
Again, I am not a network engineer and so I am a little of my depth. But I will respond in the hopes someone will educate me if I am wrong.
While UTF-8 is backwards compatible with ASCII, it did of course require programmers to add support for it just like you are suggesting any successor to IPV4 would. But once that support was added, ASCII could be treated as part of UTF-8 standard.
From what I understand, this is not the case with IPV6 and IPV4. The former requires its own software stack and the IPV6 standard was written (from what I have read) without any attempt to make it possible for IPV4 and IPV6 addresses to coexist in the same software stack easily.
While UTF-8 is backwards compatible with ASCII, it did of course require programmers to add support for it just like you are suggesting any successor to IPV4 would. But once that support was added, ASCII could be treated as part of UTF-8 standard.
From what I understand, this is not the case with IPV6 and IPV4. The former requires its own software stack and the IPV6 standard was written (from what I have read) without any attempt to make it possible for IPV4 and IPV6 addresses to coexist in the same software stack easily.
The problem is packets flow both ways in a network.
It's not like an actual pipe where one end doesn't care where the other end is. The recipient of a packet has to know where to send the reply.
So while a host with a larger address could easily talk to a legacy host with an older, smaller address, the legacy host couldn't reply because it wouldn't know how to address it.
It's not like an actual pipe where one end doesn't care where the other end is. The recipient of a packet has to know where to send the reply.
So while a host with a larger address could easily talk to a legacy host with an older, smaller address, the legacy host couldn't reply because it wouldn't know how to address it.
Yes, and all software had to be rewritten to use UTF-8. If you tried sending UTF-8 bits through an ASCII-only system, you'd display a bunch of garbage and even cause larger issues (as some bit sequences could have been interpreted as control/escape characters).
So, just like expanding address space (IP: 32-bit to 128-bit; ASCII: 8-bit/1-byte to multi-byte), you had to rewrite all the software to handle things.
So, just like expanding address space (IP: 32-bit to 128-bit; ASCII: 8-bit/1-byte to multi-byte), you had to rewrite all the software to handle things.
Actually, IPv4 address can be mapped to the IPv6 address space and routed across an IPv6-only network; you have stateless NAT gateways at the edges. That allows network operators to manage a single-stack network while still giving users an IPv4 network. 464XLAT adds one more component to the picture, which is a stateful NAT gateway that allows a network operator to provide limited IPv4 service without giving each user a public IPv4 address. For reference:
https://en.wikipedia.org/wiki/IPv4_mapped_address#IPv4-mappe...
https://en.wikipedia.org/wiki/IPv4_mapped_address#IPv4-mappe...
It's too late to discuss alternatives to IPv6, so I haven't spend time collecting what I think wrong with it (and below just random thoughts).
The main reason I don't like it - it is much more complex than IPv4 and this complexity provides from little to now real benefits (but a lot of advertised by IPv6 evangelists). The only reason networks migrate to IPv6 is the scarcity of IPv4 addresses, not other features which was envisioned as improvements over IPv4, but on practice turned out to be not very useful.
128bit per address from which usable only 64bit looks like a waste of resources (CPU/RAM) to me. Idea was to embed MAC-address in lower 64bit, but it turned out to be a bad idea because of privacy implications and for most end-user devices lower 64bit are now random. Given that /64 prefix in most cases used by single host a 64bit address would be sufficient. If we had 64bit addresses we would save RAM for routers and OS kernels and simplify implementation (64bit integers are available in practically all modern programming languages and 64bit operations are fast, while 128bit is a slower extension which is not universally available).
For me IPv6 is an example of the second-system effect: https://en.wikipedia.org/wiki/Second-system_effect
The main reason I don't like it - it is much more complex than IPv4 and this complexity provides from little to now real benefits (but a lot of advertised by IPv6 evangelists). The only reason networks migrate to IPv6 is the scarcity of IPv4 addresses, not other features which was envisioned as improvements over IPv4, but on practice turned out to be not very useful.
128bit per address from which usable only 64bit looks like a waste of resources (CPU/RAM) to me. Idea was to embed MAC-address in lower 64bit, but it turned out to be a bad idea because of privacy implications and for most end-user devices lower 64bit are now random. Given that /64 prefix in most cases used by single host a 64bit address would be sufficient. If we had 64bit addresses we would save RAM for routers and OS kernels and simplify implementation (64bit integers are available in practically all modern programming languages and 64bit operations are fast, while 128bit is a slower extension which is not universally available).
For me IPv6 is an example of the second-system effect: https://en.wikipedia.org/wiki/Second-system_effect
In my experience IPv6 is much simpler to deal with than IPv4; in fact the large address space with a 64-bit prefix as the network number greatly simplifies management and configuration and theoretically improves the CPU performance of routers by allowing allowing more aggressive route aggregation. When ISPs give /56 prefixes to users, users can easily set up subnets according to their own needs without requiring extra coordination and without breaking end-to-end connectivity. You are wrong that /64 prefixes are usually assigned to a single host; in fact the number of Internet-connected devices in a typical home has grown over time and can easily be a dozen or more.
If I were running an ISP, I would migrate the backbone network to IPv6 and just use embedded IPv4 addresses to avoid the headaches that come with router-to-router IPv4 links. With IPv6 you always have a link-local address on every port that can be used by routing protocols without relying on proprietary solutions that are not interoperable between vendors or having to assign an IPv4 address (and hoping that you assigned a large enough subnet for future growth). It is much easier to scale up an IPv6-only network and much easier to connect one IPv6-only network to another.
Of course IPv6 is not perfect. SLAAC did not really work out as planned and now we are stuck with an annoying mix of SLAAC and DHCPv6. Reverse-DNS is still a bit of a pain. IPSec is not what it should have been and too many IPv6 standards rely on IPSec for security/authentication. Even so, the core of IPv6 is a huge improvement over IPv4 for individual users, small network operators, large network operators, and the Internet as a whole.
If I were running an ISP, I would migrate the backbone network to IPv6 and just use embedded IPv4 addresses to avoid the headaches that come with router-to-router IPv4 links. With IPv6 you always have a link-local address on every port that can be used by routing protocols without relying on proprietary solutions that are not interoperable between vendors or having to assign an IPv4 address (and hoping that you assigned a large enough subnet for future growth). It is much easier to scale up an IPv6-only network and much easier to connect one IPv6-only network to another.
Of course IPv6 is not perfect. SLAAC did not really work out as planned and now we are stuck with an annoying mix of SLAAC and DHCPv6. Reverse-DNS is still a bit of a pain. IPSec is not what it should have been and too many IPv6 standards rely on IPSec for security/authentication. Even so, the core of IPv6 is a huge improvement over IPv4 for individual users, small network operators, large network operators, and the Internet as a whole.
> In my experience IPv6 is much simpler to deal with than IPv4
My experience is the complete opposite. Lot of software is still very immature when it comes to IPv6. A prime example is that I had to abandon pfSense because it just didn't handle prefix delegation. And no, switching ISP is not an option for me.
I'm now on OpenWRT which is miles better, but getting IPv6 to play nice is still lot more work. For example there were a lot more steps to getting split-horizon DNS working compared to regular IPv4.
> Even so, the core of IPv6 is a huge improvement over IPv4 for individual users, small network operators, large network operators, and the Internet as a whole.
Maybe in another decade or two when IPv6 and the ecosystem around it has matured a bit. Though it still seems to have a lot of moving parts compared to IPv4, thus requiring more to keep track of.
My experience is the complete opposite. Lot of software is still very immature when it comes to IPv6. A prime example is that I had to abandon pfSense because it just didn't handle prefix delegation. And no, switching ISP is not an option for me.
I'm now on OpenWRT which is miles better, but getting IPv6 to play nice is still lot more work. For example there were a lot more steps to getting split-horizon DNS working compared to regular IPv4.
> Even so, the core of IPv6 is a huge improvement over IPv4 for individual users, small network operators, large network operators, and the Internet as a whole.
Maybe in another decade or two when IPv6 and the ecosystem around it has matured a bit. Though it still seems to have a lot of moving parts compared to IPv4, thus requiring more to keep track of.
It shouldn't be any harder to get split-horizon DNS working on v6... and in fact v6 should eliminate the need for it in the first place, since the IP of a computer is just its IP.
All 128 bits are usable, it's not limited to just 64.
A total length of 64 bits would be too small for the eventual size of the internet. Our choice was between deploying something with too many addresses or something with too few addresses, and the former is by far better than the latter. We do not want to be going through another IP family transition to increase the bit length again, so we need to get it right the first time.
v6 mostly just took v4 and made the addresses longer, so I'm not sure it's reasonable to describe it as bloated. About the only thing it actually adds over v4 is SLAAC (and IPsec, but that was immediately backported to v4).
A total length of 64 bits would be too small for the eventual size of the internet. Our choice was between deploying something with too many addresses or something with too few addresses, and the former is by far better than the latter. We do not want to be going through another IP family transition to increase the bit length again, so we need to get it right the first time.
v6 mostly just took v4 and made the addresses longer, so I'm not sure it's reasonable to describe it as bloated. About the only thing it actually adds over v4 is SLAAC (and IPsec, but that was immediately backported to v4).
> A total length of 64 bits would be too small for the eventual size of the internet.
Even home consumers are getting at least a /64. Unless you're expecting consumers to start having ~2^64 devices, it doesn't seem like anyone is concerned with the public internet needing more than ~2^64 addresses.
Even home consumers are getting at least a /64. Unless you're expecting consumers to start having ~2^64 devices, it doesn't seem like anyone is concerned with the public internet needing more than ~2^64 addresses.
Don't think in terms of addresses. In a hierarchically-allocated and aggregated space like IP addresses, there's a massive difference between 64 bits of address space and 2^64 usable addresses.
By the time you've gone through six levels of allocations (IANA -> RIR -> ISP -> Customer -> Network -> Device) the vast majority of the total address space will be unused -- or rather: used for the purpose of aggregation, but not used for end machines. A 64-bit address space might only reasonably be able to handle something like 2^40-2^48 devices in total, which isn't that much more than we already have today.
> Unless you're expecting consumers to start having ~2^64 devices
You'd definitely need something longer than 64 bits long, long before this point.
By the time you've gone through six levels of allocations (IANA -> RIR -> ISP -> Customer -> Network -> Device) the vast majority of the total address space will be unused -- or rather: used for the purpose of aggregation, but not used for end machines. A 64-bit address space might only reasonably be able to handle something like 2^40-2^48 devices in total, which isn't that much more than we already have today.
> Unless you're expecting consumers to start having ~2^64 devices
You'd definitely need something longer than 64 bits long, long before this point.
If ISPs are allocating /64s or more to end consumers, how is this different from a 64 bit address space where they handed out a single address to each consumer?
In terms of rate of consumption of the overall address space, it's not. But consumers have started to have more than one device at home -- in fact almost everybody has an entire network with multiple machines these days, so a single address isn't sufficient.
v6 has enough space to give everybody multiple networks, not just multiple addresses (and those networks are always big enough for however many devices you end up attaching to them).
v6 has enough space to give everybody multiple networks, not just multiple addresses (and those networks are always big enough for however many devices you end up attaching to them).
To illustrate the scale, 2^32:
* is roughly equal to 4 300 000 000 (4e9, 4B)
* it is also the maximum number of IPv4 addresses
Going back to math class:
* 2^64 = 2^(32+32) = 2^32 * 2^32 = (4B) * (IPv4 Internet)
So a single /64 IPv6 subnet can hold four billion IPv4 Internets worth of systems.
* is roughly equal to 4 300 000 000 (4e9, 4B)
* it is also the maximum number of IPv4 addresses
Going back to math class:
* 2^64 = 2^(32+32) = 2^32 * 2^32 = (4B) * (IPv4 Internet)
So a single /64 IPv6 subnet can hold four billion IPv4 Internets worth of systems.
The point was whether 128 bit addresses are actually required - someone was claiming that 64 bit addresses would have also been exhausted, and I pointed out that the current strategy for handing out IPv6 is anyway using up the address space at a similar pace to the situation where we had a 64 bit address and were handing out /64 addresses to individual consumers. There were even some comments claiming certain ISPs are handing out /56 spaces to end consumers.
Ethernet MACs have 48-bit addresses, and I don't think we've run out of those, and I also don't think is anyone is even worrying about running out of those, so 64-bit IP addresses probably would have been sufficient.
But given all the drama with IPv6, I think it was reasonable to go with 128-bit addresses just so we don't have to go through all of this again.
On a related note, messing up the assignment of IPv6 address was actually accounted for. If you look at any unicast address that's currently live, you'll see that it begins with a "2". This is because addresses are only being assigned from 2000::/3:
* https://www.iana.org/assignments/ipv6-address-space/ipv6-add...
If, for some reason, we realize there's a mistake in how things were done with that space, it will be declared legacy/deprecated, and IANA will start over with addresses from 4000::/3. If that is screwed up, then 6000::/3 will be next, then 8000::/3, a000::/3, and finally c000::/3.
So the Internet community has six tries to get IPv6 addressing correct.
But given all the drama with IPv6, I think it was reasonable to go with 128-bit addresses just so we don't have to go through all of this again.
On a related note, messing up the assignment of IPv6 address was actually accounted for. If you look at any unicast address that's currently live, you'll see that it begins with a "2". This is because addresses are only being assigned from 2000::/3:
* https://www.iana.org/assignments/ipv6-address-space/ipv6-add...
If, for some reason, we realize there's a mistake in how things were done with that space, it will be declared legacy/deprecated, and IANA will start over with addresses from 4000::/3. If that is screwed up, then 6000::/3 will be next, then 8000::/3, a000::/3, and finally c000::/3.
So the Internet community has six tries to get IPv6 addressing correct.
[deleted]
> 128bit per address from which usable only 64bit looks like a waste of resources (CPU/RAM) to me.
I would recommend you check out Tom Coffeen, who wrote a book on IPv6 address planning for O'Reilly. Even with half the bits going to the subnet, there is a astronomical amount of addresses available:
* https://www.youtube.com/watch?v=7Tnh4upTOC4&t=27m
I would recommend you check out Tom Coffeen, who wrote a book on IPv6 address planning for O'Reilly. Even with half the bits going to the subnet, there is a astronomical amount of addresses available:
* https://www.youtube.com/watch?v=7Tnh4upTOC4&t=27m
This seems to be particularly because of Reliance Jio (the largest Mobile network in India?)
https://conference.apnic.net/50/assets/files/APCS790/Harness...
The adoption timeline matches Google's stats here
The adoption timeline matches Google's stats here
I believe so. They use a dual stack model and last I checked Airtel doesn’t support IPv6 yet and neither does Vi which leaves Jio to be the only ones contributing to the stats.
Airtel does dual stack model. I've been using it for about 2 years now.
Airtel doesn't seem to support IPv6 for their broadband services yet, at least in my state. Have you experienced this with broadband or mobile services?
You are right. Only mobile services support IPv6, not their broadband.
Airtel mobile supports IPv6
If anything this message says something about the abysmal state of IPv6.
Ultimately the goal of IPv6 is to end IP scarcity. But it can only do this if close to 100% of users and services use IPv6. Seeing it like that it doesn't really matter much if IPv6 adoption is 30% or 60% or 90%. In none of these situations would an ISP connect its customers via IPv6 only or would anyone provide any service that requires IPv6.
I really wonder how IPv6 should ever become mainstream without any deployment strategy. "Let's tell everyone that IPv6 is nice and we need it due to lack of v4 addresses" obviously hasn't worked for more than 20 years.
Ultimately the goal of IPv6 is to end IP scarcity. But it can only do this if close to 100% of users and services use IPv6. Seeing it like that it doesn't really matter much if IPv6 adoption is 30% or 60% or 90%. In none of these situations would an ISP connect its customers via IPv6 only or would anyone provide any service that requires IPv6.
I really wonder how IPv6 should ever become mainstream without any deployment strategy. "Let's tell everyone that IPv6 is nice and we need it due to lack of v4 addresses" obviously hasn't worked for more than 20 years.
> In none of these situations would an ISP connect its customers via IPv6 only or would anyone provide any service that requires IPv6.
It's so much cheaper and faster already today that it makes sense to do v6-only internally and deliver IPv6 to the large fraction of customers who can have IPv6 and deploy a transform layer for the (gradually shrinking) class of have-nots.
Your IPv4-only competitors are spending more money to deliver a worse service. Maybe they'll wake up and realise, but the story of the past couple of decades suggests most such outfits are not too bright and when offered IPv6 on new links they'll smugly decline. Meanwhile you get to keep the difference. Your competitor thinks this service costs 86¢ per dollar revenue and you're only spending 84¢ per dollar revenue that's a lot of extra profitability.
Fighting this is a losing battle, and I imagine that decades from now somebody is going to write a book about how it was cognitively possible for "leaders" to champion an idea that couldn't possibly work, that they intellectually knew couldn't work, and all the actual evidence said wasn't working, and yet they believed in it anyway. Or that book might be about climate change denial, either way.
Eventually by the way - and 90% global is close to and even perhaps at the threshold where that's plausible for some of them - many general ISPs won't bother providing actual IPv4 networking. If you want IPv4 you're a niche customer, go find a bespoke IPv4 Internet Service Provider. If you're IPv6 capable but you want to reach an IPv4 host you'll go via a translation box automatically. As the interest in global IPv4 shrinks, the transit companies will lose interest in that service too, and eventually - decades from now - the IPv4 Internet literally goes away, the RIRs stop "managing" the now largely unused space and the residual pockets of IPv4 cease to interoperate.
It's so much cheaper and faster already today that it makes sense to do v6-only internally and deliver IPv6 to the large fraction of customers who can have IPv6 and deploy a transform layer for the (gradually shrinking) class of have-nots.
Your IPv4-only competitors are spending more money to deliver a worse service. Maybe they'll wake up and realise, but the story of the past couple of decades suggests most such outfits are not too bright and when offered IPv6 on new links they'll smugly decline. Meanwhile you get to keep the difference. Your competitor thinks this service costs 86¢ per dollar revenue and you're only spending 84¢ per dollar revenue that's a lot of extra profitability.
Fighting this is a losing battle, and I imagine that decades from now somebody is going to write a book about how it was cognitively possible for "leaders" to champion an idea that couldn't possibly work, that they intellectually knew couldn't work, and all the actual evidence said wasn't working, and yet they believed in it anyway. Or that book might be about climate change denial, either way.
Eventually by the way - and 90% global is close to and even perhaps at the threshold where that's plausible for some of them - many general ISPs won't bother providing actual IPv4 networking. If you want IPv4 you're a niche customer, go find a bespoke IPv4 Internet Service Provider. If you're IPv6 capable but you want to reach an IPv4 host you'll go via a translation box automatically. As the interest in global IPv4 shrinks, the transit companies will lose interest in that service too, and eventually - decades from now - the IPv4 Internet literally goes away, the RIRs stop "managing" the now largely unused space and the residual pockets of IPv4 cease to interoperate.
> It's so much cheaper and faster already today that it makes sense to do v6-only internally
Absolutely not. Routers, OSes and applications still have much better support for IPv4 than IPv6.
Replacing large routers, fighting bugs and running pure IPv6 on internal networks is very expensive.
Absolutely not. Routers, OSes and applications still have much better support for IPv4 than IPv6.
Replacing large routers, fighting bugs and running pure IPv6 on internal networks is very expensive.
There haven't been ipv4-only routers sold in such a long time that they've been retired from service by now. v6 was a new router feature something like 15 or 20 years ago (and same for operating systems).
As 2fastpost wrote, basic IPv6 support is far from enough.
Also I'm not talking about routers worth 50 euro/$, but DC and carrier grade, worth 500K euro/$
Also I'm not talking about routers worth 50 euro/$, but DC and carrier grade, worth 500K euro/$
Do many reasonably recent 500k routers have bad ipv6 support?
ISPs and many enterprise sized orgs have been running v6 for a long time, so it's not like it's a checkbox feature that hasn't had a lot of testing.
ISPs and many enterprise sized orgs have been running v6 for a long time, so it's not like it's a checkbox feature that hasn't had a lot of testing.
The question is: Do many reasonably recent 500k routers have more bugs or performance limitations around IPv6 than IPv4?
Of course they do. They are hugely complex systems and troubleshooting and tuning is prioritized based on customers needs.
Of course they do. They are hugely complex systems and troubleshooting and tuning is prioritized based on customers needs.
IPv6 support is such a low bar. Now try IPv6 support and feature complete without bugs and get back to me. I’ll wait.
Can we have source to go with the IPv6 is “cheaper and faster” claim? Like actual facts stated in dollars and milliseconds.
I’m also going to humor you on the IPv6-only thing. Can you actually point to a single ISP that is even considering IPv6-only?
I’m also going to humor you on the IPv6-only thing. Can you actually point to a single ISP that is even considering IPv6-only?
Apple claimed [0] "If you look at the last month of connections made worldwide by Apple devices, we see that IPv6 now accounts for 26% of all connections made. Twenty percent of the time, the connection could have used IPv6, but the server didn't have it enabled. And when IPv6 is in use, the median connection setup is 1.4 times faster than IPv4. This is primarily due to reduced NAT usage and improved routing." Also [1] "As of June 1, 2016, all apps submitted to the App Store must support IPv6-only networks." I guess, that is a good point for performance and revenue stream security.
Of course, IPv6 has problems in some parts of the world. IPv6-only usually means, there is IPv4 on some central gateway but your clients don't get any IPv4 assigned. There is a number of really big networks doing just that e.g. most of the mobile operators in the USA.
[0] https://developer.apple.com/videos/play/wwdc2020/10111/ [1] https://developer.apple.com/support/ipv6/
Of course, IPv6 has problems in some parts of the world. IPv6-only usually means, there is IPv4 on some central gateway but your clients don't get any IPv4 assigned. There is a number of really big networks doing just that e.g. most of the mobile operators in the USA.
[0] https://developer.apple.com/videos/play/wwdc2020/10111/ [1] https://developer.apple.com/support/ipv6/
The Apple claim is so hand wavy as to be meaningless.
Without any hard data and like-to-like comparisons, the most that can be said is that IPv4 and IPv6 have different routing policies and this may attribute the differences in latency. As such what and where you test will affect your results.
That being said, Apple’s IPv6 policy is probably the best thing being done to encourage adoption.
However, they are not adopting the policy due to performance reasons, but due to necessity given who their ultimate customers are (cell phone companies).
IPv6-only as a term has been heavily abused. A truly IPv6-only network has no access to IPv4 resources. If it does, it isn’t really IPv6-only and relies upon IPv4 addresses and NAT to work.
Without any hard data and like-to-like comparisons, the most that can be said is that IPv4 and IPv6 have different routing policies and this may attribute the differences in latency. As such what and where you test will affect your results.
That being said, Apple’s IPv6 policy is probably the best thing being done to encourage adoption.
However, they are not adopting the policy due to performance reasons, but due to necessity given who their ultimate customers are (cell phone companies).
IPv6-only as a term has been heavily abused. A truly IPv6-only network has no access to IPv4 resources. If it does, it isn’t really IPv6-only and relies upon IPv4 addresses and NAT to work.
What did we read right here on HN recently about IP blocks changing hands for about $40 per address? IPv6 addresses are approximately 100% cheaper than that.
But it doesn't stop there, you also no longer need subnet planning -- where under IPv4 it's very important whether this new subnet is 60 machines or 64 machines, in IPv6 you don't care and so nobody needs to manage that. Which translates to lower costs in your network team. Negligible when your "network team" is just the CTO doing a Google search, but significant at scale.
Your route costs fall too. Because of exhaustion (and because years ago nobody had any idea what they were doing, not having had an Internet before) IPv4 is now badly fragmented, which means a trivial route ("All the East Coast stuff") may become six or sixteen or sixty separate address blocks, but IPv6 blocks were deliberately assigned so as to reduce fragmentation, chances are "All the East Coast stuff" is one or two blocks.
As to speed, Facebook reports IPv6 is about 10% faster for them.
They did exactly what I described, they're v6-only internally and have translation at the edge for "legacy" IPv4 clients.
But it doesn't stop there, you also no longer need subnet planning -- where under IPv4 it's very important whether this new subnet is 60 machines or 64 machines, in IPv6 you don't care and so nobody needs to manage that. Which translates to lower costs in your network team. Negligible when your "network team" is just the CTO doing a Google search, but significant at scale.
Your route costs fall too. Because of exhaustion (and because years ago nobody had any idea what they were doing, not having had an Internet before) IPv4 is now badly fragmented, which means a trivial route ("All the East Coast stuff") may become six or sixteen or sixty separate address blocks, but IPv6 blocks were deliberately assigned so as to reduce fragmentation, chances are "All the East Coast stuff" is one or two blocks.
As to speed, Facebook reports IPv6 is about 10% faster for them.
They did exactly what I described, they're v6-only internally and have translation at the edge for "legacy" IPv4 clients.
> What did we read right here on HN recently about IP blocks changing hands for about $40 per address? IPv6 addresses are approximately 100% cheaper than that.
This is just silly. If you are an ISP then you already have an IPv4 allocation.
If you don’t then you join the waiting list and/or apply for a /24.
Once you have your allocation, RIR fees are the same regardless of IPv4 or IPv6 allocations.
> But it doesn't stop there, you also no longer need subnet planning -- where under IPv4 it's very important whether this new subnet is 60 machines or 64 machines, in IPv6 you don't care and so nobody needs to manage that. Which translates to lower costs in your network team. Negligible when your "network team" is just the CTO doing a Google search, but significant at scale.
If you believe this is in any way meaningful then I have a bridge to sell you.
> Your route costs fall too. Because of exhaustion (and because years ago nobody had any idea what they were doing, not having had an Internet before) IPv4 is now badly fragmented, which means a trivial route ("All the East Coast stuff") may become six or sixteen or sixty separate address blocks, but IPv6 blocks were deliberately assigned so as to reduce fragmentation, chances are "All the East Coast stuff" is one or two blocks.
You can’t buy smaller routers just because you deploy IPv6, so I have no idea what cost saving there are to be had here.
> As to speed, Facebook reports IPv6 is about 10% faster for them.
I fail to see how this is universally applicable to all ISPs.
> They did exactly what I described, they're v6-only internally and have translation at the edge for "legacy" IPv4 clients.
Having an IPv6 core is not the same thing as being IPv6-only.
Speaking of IPv6-only, you have yet to name even a single ISP that is even considering going IPv6-only. Cat got your tongue?
This is just silly. If you are an ISP then you already have an IPv4 allocation.
If you don’t then you join the waiting list and/or apply for a /24.
Once you have your allocation, RIR fees are the same regardless of IPv4 or IPv6 allocations.
> But it doesn't stop there, you also no longer need subnet planning -- where under IPv4 it's very important whether this new subnet is 60 machines or 64 machines, in IPv6 you don't care and so nobody needs to manage that. Which translates to lower costs in your network team. Negligible when your "network team" is just the CTO doing a Google search, but significant at scale.
If you believe this is in any way meaningful then I have a bridge to sell you.
> Your route costs fall too. Because of exhaustion (and because years ago nobody had any idea what they were doing, not having had an Internet before) IPv4 is now badly fragmented, which means a trivial route ("All the East Coast stuff") may become six or sixteen or sixty separate address blocks, but IPv6 blocks were deliberately assigned so as to reduce fragmentation, chances are "All the East Coast stuff" is one or two blocks.
You can’t buy smaller routers just because you deploy IPv6, so I have no idea what cost saving there are to be had here.
> As to speed, Facebook reports IPv6 is about 10% faster for them.
I fail to see how this is universally applicable to all ISPs.
> They did exactly what I described, they're v6-only internally and have translation at the edge for "legacy" IPv4 clients.
Having an IPv6 core is not the same thing as being IPv6-only.
Speaking of IPv6-only, you have yet to name even a single ISP that is even considering going IPv6-only. Cat got your tongue?
I think the main thrust of your objection is that you believe I was claiming this makes sense for any ISP when I was instead saying it makes sense for lots of companies providing services on the Internet
Still, while we're here:
> This is just silly. If you are an ISP then you already have an IPv4 allocation.
Due to exhaustion in fact you can't get new allocations in IPv4 in most of the developed world. If you want to expand, you're going to need to buy addresses on the open market for that sort of $40 price we talked about.
> ... Once you have your allocation, RIR fees are the same regardless of IPv4 or IPv6 allocations.
Nope. Let's take ARIN, suppose you're a large international company, hundreds of local corporate networks. With IPv4 this is quite a struggle, maybe you can get away with a /17 for which ARIN will charge you $4000 per year.
But with IPv6 this is easy, you'll qualify for their "3X-small" category with a /40 at only $250 per year, even if you choose a relatively wasteful address layout.
It gets worse! Unless you already had that /17 from years ago, chances are you had to cobble the addresses together from several distinct allocations. ARIN charges $150 per block aggregated in this way, if you need a dozen blocks that's $1800 extra because of the fragmentation. In contrast IPv6 isn't fragmented, it was deliberately allocated sparsely so it's easy to give you adjacent blocks to grow. Not that they'll need to when you're just an international company with a few hundred sub-networks, IPv6 is so wide.
Still, while we're here:
> This is just silly. If you are an ISP then you already have an IPv4 allocation.
Due to exhaustion in fact you can't get new allocations in IPv4 in most of the developed world. If you want to expand, you're going to need to buy addresses on the open market for that sort of $40 price we talked about.
> ... Once you have your allocation, RIR fees are the same regardless of IPv4 or IPv6 allocations.
Nope. Let's take ARIN, suppose you're a large international company, hundreds of local corporate networks. With IPv4 this is quite a struggle, maybe you can get away with a /17 for which ARIN will charge you $4000 per year.
But with IPv6 this is easy, you'll qualify for their "3X-small" category with a /40 at only $250 per year, even if you choose a relatively wasteful address layout.
It gets worse! Unless you already had that /17 from years ago, chances are you had to cobble the addresses together from several distinct allocations. ARIN charges $150 per block aggregated in this way, if you need a dozen blocks that's $1800 extra because of the fragmentation. In contrast IPv6 isn't fragmented, it was deliberately allocated sparsely so it's easy to give you adjacent blocks to grow. Not that they'll need to when you're just an international company with a few hundred sub-networks, IPv6 is so wide.
Well, yeah, if you start by quoting a message explicitly making statements about ISPs and then opining on that, why act surprised that others think you are talking about ISPs?
As to the RIR fee thing, yeah, you are right about the ARIN thing. It differs by RIR and region, tho.
You are wrong about the allocation thing, tho. You can get new IPv4 allocations, even in ARINland, by joining the waitlist or to support a IPv6 deployment.
As to the RIR fee thing, yeah, you are right about the ARIN thing. It differs by RIR and region, tho.
You are wrong about the allocation thing, tho. You can get new IPv4 allocations, even in ARINland, by joining the waitlist or to support a IPv6 deployment.
RE: v6-only ISP, there's this crazy story that came up last IPv6 article: https://old.reddit.com/r/ipv6/comments/n5y5oo/update_on_not_...
Most likely fake. Posted from a throwaway account with no posting history before or since. ISP not named, no details given, no proof.
I bet the managers who are running IPv4-only places know what's coming, they just hope to get lucky and see it delayed long enough that they get another job someone else is holding the bag.
"Ultimately the goal of IPv6 is to end IP scarcity"
That is a goal, and perhaps the primary goal, but there are other goals as well. IPv6 makes the Internet itself more efficient by reducing routing overhead and it simplifies network management.
Of course, what will ultimately force ISPs and services to switch to IPv6 is IPv4 address space exhaustion. As the price of a public IPv4 address rises people will begin to more seriously consider an IPv6-only approach, even if it means losing a few users (especially since ISPs will have to make IPv6 available once such services become popular). It has taken longer than expected as various approaches have squeezed the last bits of utility out of IPv4, but it will eventually happen as several billion more people are connected to the Internet.
That is a goal, and perhaps the primary goal, but there are other goals as well. IPv6 makes the Internet itself more efficient by reducing routing overhead and it simplifies network management.
Of course, what will ultimately force ISPs and services to switch to IPv6 is IPv4 address space exhaustion. As the price of a public IPv4 address rises people will begin to more seriously consider an IPv6-only approach, even if it means losing a few users (especially since ISPs will have to make IPv6 available once such services become popular). It has taken longer than expected as various approaches have squeezed the last bits of utility out of IPv4, but it will eventually happen as several billion more people are connected to the Internet.
AFAICT, IPv4 addresses are currently going for about US$ 40/IP. At some point if ISPs run out of addresses and need more, it may be cheaper to simply implement IPv6 with a one-time, up-front project than having to go back to the well/market for more IPv4 blocks.
Similarly for hosting providers: as IPv4 addresses get more expensive, they may have to start charging their customers more and more for each one, at which point the customers may simply go only-/mostly-IPv6.
Similarly for hosting providers: as IPv4 addresses get more expensive, they may have to start charging their customers more and more for each one, at which point the customers may simply go only-/mostly-IPv6.
That's not how it works.
A single ISP can't do anything about the situation. They can provide IPv6 to their customers, but they still need IPv4 so their customers so they have a usable internet connection. It doesn't help them at all.
Which is part of the problem here: As long as IPv6 is not implemented by everybody the people who do implement it have no advantage.
A single ISP can't do anything about the situation. They can provide IPv6 to their customers, but they still need IPv4 so their customers so they have a usable internet connection. It doesn't help them at all.
Which is part of the problem here: As long as IPv6 is not implemented by everybody the people who do implement it have no advantage.
An ISP probably already has IPv4 addresses, but needs more addresses for basic connectivity. They can become IPv6-only and then use their IPv4 block/s for CGNAT. The money would go to either buying more addresses or more CGNAT.
This is how a lot of mobile/cell telcos already work. A T-Mobile presentation from 2018 (PDF):
* https://pc.nanog.org/static/published/meetings/NANOG73/1645/...
This is how a lot of mobile/cell telcos already work. A T-Mobile presentation from 2018 (PDF):
* https://pc.nanog.org/static/published/meetings/NANOG73/1645/...
Running an IPv6 core and offering IPv4-as-a-service doesn’t really make you IPv6-only.
I'm not sure what you're referring to.
Here's a dude from T-Mobile explaining how they have (in 2017) over ten million end-customer devices without any IPv4 addresses assigned:
* https://www.youtube.com/watch?v=nNMNglk_CvE
For reaching services that are IPv6 only they use(d) DNS64 (with and without 464XLAT).
Here's a dude from T-Mobile explaining how they have (in 2017) over ten million end-customer devices without any IPv4 addresses assigned:
* https://www.youtube.com/watch?v=nNMNglk_CvE
For reaching services that are IPv6 only they use(d) DNS64 (with and without 464XLAT).
IPv6-only as a term has been heavily abused. A truly IPv6-only network has no access to IPv4 resources. If it does, it isn’t really IPv6-only and relies upon IPv4 addresses and NAT to work.
The problem with the above is that it isn’t a viable solution.
You cannot just deploy IPv6, take your IPv4 ball and go home.
ISPs will still need those IPv4 addresses, no matter how much they cost. ISPs may delay by deploying CGNAT, but once those IPv4 addresses run out there is no other option than to get out your checkbook or scale back your business.
Likewise with hosters. There is no choice but to use IPv4, damn the cost. It simply isn’t viable to go IPv6-only, as IPv4 is where the money/customers are.
This will not change until IPV6 somehow reaches critical mass.
You cannot just deploy IPv6, take your IPv4 ball and go home.
ISPs will still need those IPv4 addresses, no matter how much they cost. ISPs may delay by deploying CGNAT, but once those IPv4 addresses run out there is no other option than to get out your checkbook or scale back your business.
Likewise with hosters. There is no choice but to use IPv4, damn the cost. It simply isn’t viable to go IPv6-only, as IPv4 is where the money/customers are.
This will not change until IPV6 somehow reaches critical mass.
> ISPs will still need those IPv4 addresses, no matter how much they cost. ISPs may delay by deploying CGNAT, but once those IPv4 addresses run out there is no other option than to get out your checkbook or scale back your business.
Yes, that's what I'm saying. At some point going IPv6-only and paying for (CG)NAT64 may be cheaper than trying to buy more and more IPv4 addresses. ISPs would already have IPv4 addresses, but they'd simply use them for reaching the 'legacy' Internet, and they wouldn't be assigned to people's routers WAN interface.
> Likewise with hosters. There is no choice but to use IPv4, damn the cost.
It will probably not be the hosting company paying for the IPv4, but rather it will be the end customer, and they may not want to pay.
The first address may be free, but if you want multiple, then you could be charged for the 'extra' ones. Depending on the number of public services needed, some people may find it cheaper to use the IPv4 address(es) on the front-end of a load balancer and have their actual system be IPv6.
Yes, that's what I'm saying. At some point going IPv6-only and paying for (CG)NAT64 may be cheaper than trying to buy more and more IPv4 addresses. ISPs would already have IPv4 addresses, but they'd simply use them for reaching the 'legacy' Internet, and they wouldn't be assigned to people's routers WAN interface.
> Likewise with hosters. There is no choice but to use IPv4, damn the cost.
It will probably not be the hosting company paying for the IPv4, but rather it will be the end customer, and they may not want to pay.
The first address may be free, but if you want multiple, then you could be charged for the 'extra' ones. Depending on the number of public services needed, some people may find it cheaper to use the IPv4 address(es) on the front-end of a load balancer and have their actual system be IPv6.
You are confusing IPv6-only and running an IPv6 core. Those are not equivalent.
>It will probably not be the hosting company paying for the IPv4, but rather it will be the end customer, and they may not want to pay.
Of coarse it will be the hosting company paying for the IPv4 addresses as they will be the ones owning them.
Of coarse the end customers will complain and not want to pay, but pay they will as they have no other choice.
It’s neither here nor there whether the end customers run IPv4 or IPv6 internally, it’s the public IPv4 addresses that matter.
>It will probably not be the hosting company paying for the IPv4, but rather it will be the end customer, and they may not want to pay.
Of coarse it will be the hosting company paying for the IPv4 addresses as they will be the ones owning them.
Of coarse the end customers will complain and not want to pay, but pay they will as they have no other choice.
It’s neither here nor there whether the end customers run IPv4 or IPv6 internally, it’s the public IPv4 addresses that matter.
There are btw. IPv6 only hosters out there, e.g. https://ungleich.ch/en-us/cms/ but other are offering IPv6-only as a cheaper option. Yes, it is not totally mainstream yet.
I know there are IPv6 only hosters out there.
However, as I stated previously, they are only for niche uses such as hobby projects or internal services, not for use by the general public.
They will remain so until IPv6 reaches critical mass.
However, as I stated previously, they are only for niche uses such as hobby projects or internal services, not for use by the general public.
They will remain so until IPv6 reaches critical mass.
[deleted]
The problem with IPv6 is the yield curve. Adopting IPv6 currently yields you some good PR, extra maintenance costs from troubleshooting minor compatibility problems right now, and a great advantage of not losing IPv6-only customers at some distant time in the future, when IPv6-only hosts become a thing.
So, from a business perspective, the optimal strategy is to delay the transition (and the ongoing maintenance costs) until IPv6-only customers become a quantifiable number (e.g. you could say that in 5 years about 5-10% of your target audience would not have IPv4, so switching to IPv6 would increase your sales by X%). You can't blame businesses for doing that. You don't play by these rules, you end up one of those companies blogging how they are forced to shut down despite having a marvelous and very sophisticated product.
That said, you can change it very easily. Just offer IPv6 traffic at a slightly lower rate than IPv4. So every IPv6 packet costs you less than the IPv4 one. For unlimited connections, offer some rebate based on the fraction of IPv6 packets, or something. This will immediately put the incentives in the right places and the switch will happen at exponential rate.
So, from a business perspective, the optimal strategy is to delay the transition (and the ongoing maintenance costs) until IPv6-only customers become a quantifiable number (e.g. you could say that in 5 years about 5-10% of your target audience would not have IPv4, so switching to IPv6 would increase your sales by X%). You can't blame businesses for doing that. You don't play by these rules, you end up one of those companies blogging how they are forced to shut down despite having a marvelous and very sophisticated product.
That said, you can change it very easily. Just offer IPv6 traffic at a slightly lower rate than IPv4. So every IPv6 packet costs you less than the IPv4 one. For unlimited connections, offer some rebate based on the fraction of IPv6 packets, or something. This will immediately put the incentives in the right places and the switch will happen at exponential rate.
>That said, you can change it very easily. Just offer IPv6 traffic at a slightly lower rate than IPv4.
How many cents per month will make you or anybody care?
ISPs don’t even pay for the majority of their bandwidth, they get it for free via settlement free peering. Where’s the rebate going to come from that?
On the fraction of bandwidth ISPs pay for, the wholesale rates are less than 5 cents per Mbps. On average a subscriber uses a few Mbps on average.
Would 15 cents per month really motivate you to go all in on IPv6?
On average bandwidth costs for an ISP are single digit percentages or less of all costs. Even if their wholesalers would fully discount all their IPv6 traffic (why would they do that?!) there’s only so much there to work with.
How many cents per month will make you or anybody care?
ISPs don’t even pay for the majority of their bandwidth, they get it for free via settlement free peering. Where’s the rebate going to come from that?
On the fraction of bandwidth ISPs pay for, the wholesale rates are less than 5 cents per Mbps. On average a subscriber uses a few Mbps on average.
Would 15 cents per month really motivate you to go all in on IPv6?
On average bandwidth costs for an ISP are single digit percentages or less of all costs. Even if their wholesalers would fully discount all their IPv6 traffic (why would they do that?!) there’s only so much there to work with.
> India is leading IPv6 migration with 61.67% adoption
This data doesn't show that at all. It's based on traffic to Google. According to this, IPv6 adoption in China is just over 2%.
Which of course has absolutely nothing to do with reality.
This data doesn't show that at all. It's based on traffic to Google. According to this, IPv6 adoption in China is just over 2%.
Which of course has absolutely nothing to do with reality.
True. All three major mobile carriers in mainland China have deployed Dual Stack. And the government is pushing for IPv6-only stack by 2030, with pilot starting as early as 2025.
An idea (perhaps silly one) that I had to boost IPv6 adoption - remember the old web 1.0? Interesting web sites and stuff you don't easily find today? Let's create a unique experience that's only accessible on sites that are IPv6 only. Not to exclude people - even with IPv4 only from your ISP you can tunnel in. Ideas?
Not an entirely new idea...
https://itwire.com/business-technology/good-news-bad-news-an...
> And the free porn? According to Labovitz, it's just one incentive being offered to promote IPV6 "...IPv6 proponents offer free high quality IPv6 porn (the porn-free, IPV4 home page is https://www.ipv6porn.co.nz/ )
https://itwire.com/business-technology/good-news-bad-news-an...
> And the free porn? According to Labovitz, it's just one incentive being offered to promote IPV6 "...IPv6 proponents offer free high quality IPv6 porn (the porn-free, IPV4 home page is https://www.ipv6porn.co.nz/ )
There are some experiments https://www.doesnotwork.eu/ (here are more details: https://xn--ondej-kcb.caletka.cz/dl/slidy/20180824-SNT2018-E...)
It is good for testing stuff.
It is good for testing stuff.
Do you mean restricting new web features to IPv6 sites? Or something else?
With the amount of people coming online, India also probably needs it the most
They don't have giant DARPA allocated IP4 blocks handed out for free to companies and universities in the early days of the internet either.
Exactly. And as a developing country, they (hard guess) do not have the widespread pre-existing infrastructure like developed countries; and therefore can easier to adopt to it.
Another factor - mobile has a way greater market share in India, than mobile has in Europe. It’s easier to enforce IPv6 as a mobile carrier
(https://gs.statcounter.com/platform-market-share/desktop-mob...)
Another factor - mobile has a way greater market share in India, than mobile has in Europe. It’s easier to enforce IPv6 as a mobile carrier
(https://gs.statcounter.com/platform-market-share/desktop-mob...)
How does China manage?
Layers upon layers of NAT from what I hear.
they are trying to catch up:
https://www.scmp.com/tech/policy/article/3143180/china-hatch...
https://www.scmp.com/tech/policy/article/3143180/china-hatch...
The interesting question is, does India have enough critical mass to actually launch local IPv6-only services?
A large carrier could even use IPv6 as a competitive moat by offering/sponsoring/investing in popular local IPv6-only services.
Competitor’s customers would be locked out because they don’t have IPv6, not because they were blocked. Kinda hard for competitors to cry foul to the regulator, since the only reason their customers can’t reach the service is that they themselves haven’t been keeping up with the times.
A large carrier could even use IPv6 as a competitive moat by offering/sponsoring/investing in popular local IPv6-only services.
Competitor’s customers would be locked out because they don’t have IPv6, not because they were blocked. Kinda hard for competitors to cry foul to the regulator, since the only reason their customers can’t reach the service is that they themselves haven’t been keeping up with the times.
[deleted]
OT: does IPv6 make it easier/harder for websites to track you?
IPv6 has a few extensions, that have been implemented in just about every OS, to make things more private. [0][1][2]
To put it simply, badly implemented IPv6 makes it easier, but all the ways to make it on-par with IPv4 have been widely deployed since 2016.
[0] https://datatracker.ietf.org/doc/html/rfc4941
[1] https://datatracker.ietf.org/doc/html/rfc7217
[2] https://datatracker.ietf.org/doc/html/rfc7721
To put it simply, badly implemented IPv6 makes it easier, but all the ways to make it on-par with IPv4 have been widely deployed since 2016.
[0] https://datatracker.ietf.org/doc/html/rfc4941
[1] https://datatracker.ietf.org/doc/html/rfc7217
[2] https://datatracker.ietf.org/doc/html/rfc7721
>To put it simply, badly implemented IPv6 makes it easier, but all the ways to make it on-par with IPv4 have been widely deployed since 2016.
Not really. According to the wikipedia article[1], you still have an unique address per device. It rotates daily, but you still can uniquely identify a device on a daily basis. This wouldn't be possible with ivp4 with NAT.
[1] https://en.wikipedia.org/wiki/IPv6#Stateless_address_autocon...
Not really. According to the wikipedia article[1], you still have an unique address per device. It rotates daily, but you still can uniquely identify a device on a daily basis. This wouldn't be possible with ivp4 with NAT.
[1] https://en.wikipedia.org/wiki/IPv6#Stateless_address_autocon...
If you read RFC7721 which I linked above, you'll find that "SLAAC temporary addresses" is the bare minimum (from 2012), but not the recommended process (over a decade later). And is therefore not what most platforms use today.
> DHCPv6 temporary addresses have the same properties as SLAAC temporary addresses (see Section 4.6). On the other hand, the properties of DHCPv6 non-temporary addresses typically depend on the specific DHCPv6 server software being employed. Recent releases of most popular DHCPv6 server software typically lease random addresses with a similar lease time as that of IPv4. Thus, these addresses can be considered to be "stable, semantically opaque". [DHCPv6-IID] specifies an algorithm that can be employed by DHCPv6 servers to generate "stable, semantically opaque" addresses. [0]
The very last line of that Wikipedia paragraph points you to RFC8064 [1], which is a standard, and completely obsoletes the early "SLAAC temporary addresses", and makes the rest of the paragraph nothing but historical information. (The mention of Windows XP should stand out as a red flag, there.)
> By default, nodes SHOULD NOT employ IPv6 address generation schemes that embed a stable link-layer address in the IID.
[0] https://datatracker.ietf.org/doc/html/rfc7721#section-4.7
[1] https://datatracker.ietf.org/doc/html/rfc8064
> DHCPv6 temporary addresses have the same properties as SLAAC temporary addresses (see Section 4.6). On the other hand, the properties of DHCPv6 non-temporary addresses typically depend on the specific DHCPv6 server software being employed. Recent releases of most popular DHCPv6 server software typically lease random addresses with a similar lease time as that of IPv4. Thus, these addresses can be considered to be "stable, semantically opaque". [DHCPv6-IID] specifies an algorithm that can be employed by DHCPv6 servers to generate "stable, semantically opaque" addresses. [0]
The very last line of that Wikipedia paragraph points you to RFC8064 [1], which is a standard, and completely obsoletes the early "SLAAC temporary addresses", and makes the rest of the paragraph nothing but historical information. (The mention of Windows XP should stand out as a red flag, there.)
> By default, nodes SHOULD NOT employ IPv6 address generation schemes that embed a stable link-layer address in the IID.
[0] https://datatracker.ietf.org/doc/html/rfc7721#section-4.7
[1] https://datatracker.ietf.org/doc/html/rfc8064
Is there a tl;dr description as to how the current address generation/randomization process works?
It is mostly laid out in this [0] document.
+ secret_key is at least 128 bits, be cryptographically generated, and as difficult to access as the system allows. It cannot be re-used for any other purpose.
+ F is at least SHA-1, but should probably be SHA-256 or above. It can be any cryptographically secure hash function that returns 64 or more bits. (And MD5 is explicitly banned).
+ Client_DUID is the Client Identifier sent to the DHCP.
+ IAID is the 32bit integer from the IA_NA option sent to the DHCP.
And then, once you have that randomised ID:
+ IPV6_ADDR starts out as RID.
+ IPV6_ADDR_HI is the upper bound of leaseable addresses.
+ IPV6_ADDR_LOW is the lower bound of leaseable addresses.
If this produces an address that is invalid or already leased, increment Counter and try again.
The result is that addresses in the same prefix are completely dissimilar, and opaque. When the system rolls the address, there is no way to predict what the next address will be, or what the previous address was.
Windows, Android, macOS, and Linux tend to roll to a new IPv6 address either on system restart, or on an hourly basis, depending on settings.
Thus, on par with current IPv4 addresses for tracking.
[0] https://datatracker.ietf.org/doc/html/draft-ietf-dhc-stable-...
RID = F(Prefix | Client_DUID | IAID | Counter | secret_key)
+ secret_key is at least 128 bits, be cryptographically generated, and as difficult to access as the system allows. It cannot be re-used for any other purpose.
+ F is at least SHA-1, but should probably be SHA-256 or above. It can be any cryptographically secure hash function that returns 64 or more bits. (And MD5 is explicitly banned).
+ Client_DUID is the Client Identifier sent to the DHCP.
+ IAID is the 32bit integer from the IA_NA option sent to the DHCP.
And then, once you have that randomised ID:
if(IPV6_ADDR < IPV6_ADDR_LOW || IPV6_ADDR > IPV6_ADDR_HI){
IPV6_ADDR = IPV6_ADDR_LOW + IPV6_ADDR % \
(IPV6_ADDR_HI - IPV6_ADDR_LOW + 1);
}
+ IPV6_ADDR starts out as RID.
+ IPV6_ADDR_HI is the upper bound of leaseable addresses.
+ IPV6_ADDR_LOW is the lower bound of leaseable addresses.
If this produces an address that is invalid or already leased, increment Counter and try again.
The result is that addresses in the same prefix are completely dissimilar, and opaque. When the system rolls the address, there is no way to predict what the next address will be, or what the previous address was.
Windows, Android, macOS, and Linux tend to roll to a new IPv6 address either on system restart, or on an hourly basis, depending on settings.
Thus, on par with current IPv4 addresses for tracking.
[0] https://datatracker.ietf.org/doc/html/draft-ietf-dhc-stable-...
Assuming your ISP gives you a /64 (and not /128), easier. With ipv4, all the traffic coming out of your house is from one ip, so the ip provides household level granularity. With ipv6 each device has a distinct address, which means the ip provides device-level granularity.
That’s not true, all serious devices (except maybe IoT crapware) implement privacy extensions, so your computers and devices make requests from different, randomised address (within your allocated subnet obviously).
They don't make literally every single request from a different address off a fully shared prefix (as if you just randomize the final bits but also maintain some unique prefix bits, you still lost), so it is still worse than IPv4 with NAT, much worse than CGNAT, and AFAIK in most cases isn't much (if at all) better than assigning everyone a unique sticky address.
NAT is no longer a thing, all devices just have a globally unique IP. So your IP allow is a pretty strong indicator, it seems like that alone would make tracking easier.
There’s nothing in IPv6 to prevent tracking or offer more anonymity.
There’s nothing in IPv6 to prevent tracking or offer more anonymity.
That's not quite true. IPv6 has privacy extensions which generate randomized suffixes. A website would still be able to track you with the common prefix. Tracking the prefix is more or less the same as tracking an IPv4 address. If you're worried about tracking than you're better off using a VPN than a NAT gateway (both of which is also possible with IPv6).
As I recall, this was seen as a concern in the early days so "privacy extensions" were added to the implementation standard for IPv6. Macintosh, Windows, iOS, and Android all rotate their auto-configured IPv6 addresses at a regular interval. It used to be a day but I think I've seen it as short as an hour: https://www.internetsociety.org/blog/2014/12/ipv6-privacy-ad...
NAT can be used in conjunction with IPv6 for security purposes. It is still a thing
It was never a thing. NAT isn't security.
How do you think NAT gives you security?
Without active measures to allow it, you can't reach ports on a machine behind NAT.
If I accidentally run an SSH server where user 'root' and an empty password gives you root access, you still won't be able to get in.
Accidentally configuring port forwarding is a lot harder than accidentally disabling an on-host firewall.
If I accidentally run an SSH server where user 'root' and an empty password gives you root access, you still won't be able to get in.
Accidentally configuring port forwarding is a lot harder than accidentally disabling an on-host firewall.
This is not actually true. NAT rewrites the apparent source address of outbound connections, which has no impact on inbound connections -- any inbound connection that worked before you started NATing your outbound connections will continue to work after you start doing so.
You need a firewall for security, and NAT doesn't do anything in that regard other than make it harder to understand what's going on.
You need a firewall for security, and NAT doesn't do anything in that regard other than make it harder to understand what's going on.
You can just as easily run a firewall as a NAT, in fact most home routers support both. And, just like NAT, by default they don't allow any connections from the outside.
And here I am with a brand new Frontier fiber install and not only do they not offer IPv6, not only do they not allow me access to their 6rd relays because those are “legacy” from AT&T, but they also fucking block protocol 41 so I can’t even use a tunnel broker.
How google would start a wave of ip6 migration: give a search penalty for being ip4 only.
In theory, having IPv6 website enabled should give a slight boost to the ranking if the latency is lower.
But still Google crawls dualstack sites with IPv4 so it is yet to be seen.
But still Google crawls dualstack sites with IPv4 so it is yet to be seen.
How would this benefit Google?
Did the https migration benefit Google?
https://developers.google.com/search/blog/2014/08/https-as-r...
https://developers.google.com/search/blog/2014/08/https-as-r...
Less individual users behind NAT so they can track them better?
Between search, gmail, YouTube, maps, Chrome and Android I don’t think Google needs help tracking anybody on the planet.
Even so, IPv6 privacy extensions more or less bring things up to par with NAT in terms of trackability.
I guess there could be some small benefit, but very few it applied to would be outside the Google dragnet to begin with.
Even so, IPv6 privacy extensions more or less bring things up to par with NAT in terms of trackability.
I guess there could be some small benefit, but very few it applied to would be outside the Google dragnet to begin with.
Any particular reason China's adoption rate is so low?
A few years ago, IPv6 in China was reserved to universities and it bypassed the golden shield (at least censorship, added packet loss on long-running connections, added latency, ...).
2.28% is already impressive if the situation is still the same nowadays.
2.28% is already impressive if the situation is still the same nowadays.
They use massive amounts of NAT instead AIUI.
[deleted]
jio effect
Ah yes… the IPv6 migration. Been hearing about this for two decades now. The reason it isn’t ubiquitous in 2021 is because there are fundamental issues with the protocol, not least of which is incompatibility with what the entire rest of the world is current running. If we are ever going to get the world on the same protocol, we need something new.
Nah, as protocol the IPv6 is fine.
What is not fine is the real-world implementations. ISPs that give you a /64 subnet? ISPs that insist, that with IPv6 you must use their CPE as a router, where you have almost zero control? ISPs that give you /56, but prefix delegation on the router they force on you is broken?
There's so much brokenness, that even as a IPv6 fan, I keep my IPv4 addresses. And if it means DS-Lite or IPv4, then IPv4 is it.
What is not fine is the real-world implementations. ISPs that give you a /64 subnet? ISPs that insist, that with IPv6 you must use their CPE as a router, where you have almost zero control? ISPs that give you /56, but prefix delegation on the router they force on you is broken?
There's so much brokenness, that even as a IPv6 fan, I keep my IPv4 addresses. And if it means DS-Lite or IPv4, then IPv4 is it.
Do you mind describing what those issues are? Or linking some reading about it?
Originally published in 2002 (inspired from djb's proposal on AutoIPv6):
https://cr.yp.to/djbdns/ipv6mess.html
https://cr.yp.to/djbdns/ipv6mess.html
https://www.amazon.in
https://www.paytm.com
https://twitter.com
https://www.flipkart.com
https://www.hotstar.com
https://www.primevideo.com
https://news.ycombinator.com
https://www.reddit.com
Edit: Removed google.co.in, the website[1] reported it that it does not support ipv6, Now I tried again and google is in green.
[1] https://ipv6-test.com/validate.php