IPv6 just turned 30 and still hasn't taken over the world(theregister.com)
theregister.com
IPv6 just turned 30 and still hasn't taken over the world
https://www.theregister.com/2025/12/31/ipv6_at_30/
1,193 comments
> - I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.
What happens when multiple devices in your /8 want to listen on port 80 and 443 on the public address? Only one of them can. Now you're running a proxy.
> - Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.
It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall. NAT is usually configured as part of your firewall, but is not a firewall.
> - Stateless auto configuration. What ? No, no, I want my ducks neatly in a row, not wandering about. Again maybe my brain is rotten from years of DHCP usage but yes, I want stateful configuration and I want all devices on my network to automatically use my internal DNS server thank you very much.
DHCPv6
> - My ISP gives me a /64, what am I supposed to do with that anyways?
What are you supposed to do with a /8? Do you have several million computers?
> - What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.
What happens if your ISP changes your IPv4 address?
What happens when multiple devices in your /8 want to listen on port 80 and 443 on the public address? Only one of them can. Now you're running a proxy.
> - Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.
It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall. NAT is usually configured as part of your firewall, but is not a firewall.
> - Stateless auto configuration. What ? No, no, I want my ducks neatly in a row, not wandering about. Again maybe my brain is rotten from years of DHCP usage but yes, I want stateful configuration and I want all devices on my network to automatically use my internal DNS server thank you very much.
DHCPv6
> - My ISP gives me a /64, what am I supposed to do with that anyways?
What are you supposed to do with a /8? Do you have several million computers?
> - What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.
What happens if your ISP changes your IPv4 address?
Wow. It's like your reply is doing an impression of IPv6! (I'm just teasing. I hope you are having a happy new year.)
Not GP, but:
> What happens when multiple devices in your /8 want to listen on port 80 and 443 on the public address? Only one of them can. Now you're running a proxy.
I don't want any of my devices listening on the public address, much less multiple.
> It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall. NAT is usually configured as part of your firewall, but is not a firewall.
That's a non sequitur. I can have a both a firewall and a NAT. The two layers are better than one because at least my address is shouldn't be routable even if I failed to configure my firewall correctly.
> DHCPv6 Okay? DHCPv4
> What are you supposed to do with a /8? Do you have several million computers? That's GP's point. Running out of address space is not a problem even on IPv4 with NAT.
> What happens if your ISP changes your IPv4 address? Well, an ostensible advantage of IPv6 is publicly routable addresses. I know how to configure my internal IPv4 network with host table entries and so on. If I move to IPv6 then my "internal" network address space is at the whim of my ISP.
Not GP, but:
> What happens when multiple devices in your /8 want to listen on port 80 and 443 on the public address? Only one of them can. Now you're running a proxy.
I don't want any of my devices listening on the public address, much less multiple.
> It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall. NAT is usually configured as part of your firewall, but is not a firewall.
That's a non sequitur. I can have a both a firewall and a NAT. The two layers are better than one because at least my address is shouldn't be routable even if I failed to configure my firewall correctly.
> DHCPv6 Okay? DHCPv4
> What are you supposed to do with a /8? Do you have several million computers? That's GP's point. Running out of address space is not a problem even on IPv4 with NAT.
> What happens if your ISP changes your IPv4 address? Well, an ostensible advantage of IPv6 is publicly routable addresses. I know how to configure my internal IPv4 network with host table entries and so on. If I move to IPv6 then my "internal" network address space is at the whim of my ISP.
Been having a nice break over the new year, thank you :)
I can't argue with sticking on IPv4 when you have no need for IPv6. However, people saying no NAT means no firewall really bothers me because it's just wrong and usually gets thrown around as part of a point around "who needs IPv6 anyway".
The two layers IMO don't make a practical difference. A deny by default firewall will fail closed, unless poorly configured. A poorly configured firewall for IPv4 with NAT can still leave machines exposed. This is not an IPv4/IPv6 problem this is down to your router. However you do expose what used to be private addresses with IPv6, but there's not much to do with the address that couldn't be done with your IPv4 address assuming sane firewalls that both stacks run.
On the other side of the coin IPv6 being ubiquitous would make my life much easier. I self host a few things across a few different machines. IPv6 offers me a much simpler solution, both to managing firewalls and not needing to fight over port 80/443, but also because I can't get a public IPv4 address from my ISP without spending ungodly amounts of money. They support IPv6 but many of the services I host don't support it. I have to use a second site + machine, wireguard tunnels, and nginx socket proxies to expose stuff publicly (this is cheaper than the public IPv4 address from my ISP).
My point about DHCPv6 is to say that if you want to use DHCP in IPv6 you can. It's right there, it's just not the default.
IPv6 doesn't make things substantially harder, just different. But people don't want to learn new things because, to be fair, they don't need them. But people who do need IPv6 are stuck behind garbage ISPs and this "not my problem" attitude throwing around ignorant arguments. Complaints about long addresses really get me too :), use a DNS.
I can't argue with sticking on IPv4 when you have no need for IPv6. However, people saying no NAT means no firewall really bothers me because it's just wrong and usually gets thrown around as part of a point around "who needs IPv6 anyway".
The two layers IMO don't make a practical difference. A deny by default firewall will fail closed, unless poorly configured. A poorly configured firewall for IPv4 with NAT can still leave machines exposed. This is not an IPv4/IPv6 problem this is down to your router. However you do expose what used to be private addresses with IPv6, but there's not much to do with the address that couldn't be done with your IPv4 address assuming sane firewalls that both stacks run.
On the other side of the coin IPv6 being ubiquitous would make my life much easier. I self host a few things across a few different machines. IPv6 offers me a much simpler solution, both to managing firewalls and not needing to fight over port 80/443, but also because I can't get a public IPv4 address from my ISP without spending ungodly amounts of money. They support IPv6 but many of the services I host don't support it. I have to use a second site + machine, wireguard tunnels, and nginx socket proxies to expose stuff publicly (this is cheaper than the public IPv4 address from my ISP).
My point about DHCPv6 is to say that if you want to use DHCP in IPv6 you can. It's right there, it's just not the default.
IPv6 doesn't make things substantially harder, just different. But people don't want to learn new things because, to be fair, they don't need them. But people who do need IPv6 are stuck behind garbage ISPs and this "not my problem" attitude throwing around ignorant arguments. Complaints about long addresses really get me too :), use a DNS.
>IPv6 doesn't make things substantially harder, just different. But people don't want to learn new things
I learn new things all the time. IPv6 is much more complicated, and importantly, more complicated than it needs to be. There is really no reason for most devices to be publicly reachable. Everyone keeps holding this up as a positive, but it's absolutely not. Most devices aren't servers. Yes, a firewall can prevent these connections, but the whole standard is built around this use case most people don't need most of the time.
Private IP space is incredibly useful. I build it and set it up -- my ISP does not have control. This is _gone_ with IPv6 and it makes things much more complicated than they need to.
I learn new things all the time. IPv6 is much more complicated, and importantly, more complicated than it needs to be. There is really no reason for most devices to be publicly reachable. Everyone keeps holding this up as a positive, but it's absolutely not. Most devices aren't servers. Yes, a firewall can prevent these connections, but the whole standard is built around this use case most people don't need most of the time.
Private IP space is incredibly useful. I build it and set it up -- my ISP does not have control. This is _gone_ with IPv6 and it makes things much more complicated than they need to.
> There is really no reason for most devices to be publicly reachable. Everyone keeps holding this up as a positive, but it's absolutely not. Most devices aren't servers.
Ever tried to call someone over the internet? Well, now you need a publicly reachable device.
Please, stop spreading this ignorance. You rely on your devices being reachable from the internet every single day, you're just not aware of it, because you're using a barely-working pile of duct tape and string that sort-of allows peer to peer connections to happen, after some arcane STUN/TURN/whatever magic.
If you wanted to send someone a file in the Olden Days, you'd just click on their IRC username, the client would open a connection to them and you'd send the file. Now you need to use iCloud or some nonsense, because apparently people believe that peer-to-peer connections aren't needed and shouldn't even work.
Ever tried to call someone over the internet? Well, now you need a publicly reachable device.
Please, stop spreading this ignorance. You rely on your devices being reachable from the internet every single day, you're just not aware of it, because you're using a barely-working pile of duct tape and string that sort-of allows peer to peer connections to happen, after some arcane STUN/TURN/whatever magic.
If you wanted to send someone a file in the Olden Days, you'd just click on their IRC username, the client would open a connection to them and you'd send the file. Now you need to use iCloud or some nonsense, because apparently people believe that peer-to-peer connections aren't needed and shouldn't even work.
I’m wondering, wouldn’t a default deny inbound firewall still need hole punching with IPv6? You wouldn’t need STUN to find your global address but if you use varying ports you’d need to communicate the port first, and you’d also need to time the simultaneous open. So a coordinating party is still needed somewhere. Getting rid of TURN relays (if you’re affected by symmetric NATs) is of course a huge plus.
No, you'd have something like UPnP open a port on the firewall, I imagine. It depends on the setup, which can now be much more flexible, since the firewall can run on the machine itself. You also have the benefit that multiple machines can listen on the same port, so you don't need a proxy any more.
>Ever tried to call someone over the internet? Well, now you need a publicly reachable device.
Uhh... Is this the '90s? People don't type in IP addresses (or phone numbers, back in the day) to connect with other people anymore. They connect to a common, publicly reachable server that deals with peers being behind NAT.
Uhh... Is this the '90s? People don't type in IP addresses (or phone numbers, back in the day) to connect with other people anymore. They connect to a common, publicly reachable server that deals with peers being behind NAT.
Most video calling software uses STUN NAT hole punching and not central relay servers. You are definitely publicly routed when you call through Google Meet or WhatsApp or FaceTime
https://atscaleconference.com/calling-relay-infrastructure-a...
if i read this right, whatsapp calls go thru relay servers?
if i read this right, whatsapp calls go thru relay servers?
To be fair, I think Google Meet with multiple participants still uses a relay server, instead of N^2 streams, but I may be wrong.
Now you've got significant additional latency, which is why this is very often not what actually occurs in these situations if it's at all avoidable.
It doesn't really matter. Any communications provider must keep call records for the FSB, so routing them through central servers and recording there is the only option anyway.
Of course it matters. STUN isn't theoretical, it's in actual, practical use across a great many things. There's plenty of things that aren't "calls" in a telecommunications sense. Discord, Telegram, Zoom, Slack, Jitsi, and far more. And there are plenty of other things entirely that use the same tactics to get direct peer-to-peer connections.
>Discord, Telegram, Zoom, Slack, Jitsi
All of them are blocked for not complying with government's regulations where I live.
All of them are blocked for not complying with government's regulations where I live.
May I introduce you to our Lord and Savior the Domain Name System.
How do you think this works, exactly?
No it is not:
IPv4 header: https://upload.wikimedia.org/wikipedia/commons/thumb/6/60/IP...
IPv6 header: https://bitjunkie.org/wp-content/uploads/2023/10/ipv6-Header...
Notice how the IPv6 header is simpler? That’s because it is. It has normal working semantics, got rid of fragmentation, TTL is replaced by hop limit, and link-local addresses actually work as intended. The addresses look scary != more complicated. Please stop perpetuating this myth.
IPv4 header: https://upload.wikimedia.org/wikipedia/commons/thumb/6/60/IP...
IPv6 header: https://bitjunkie.org/wp-content/uploads/2023/10/ipv6-Header...
Notice how the IPv6 header is simpler? That’s because it is. It has normal working semantics, got rid of fragmentation, TTL is replaced by hop limit, and link-local addresses actually work as intended. The addresses look scary != more complicated. Please stop perpetuating this myth.
If IPv6 were just an improved header and a longer address I'd be perfectly happy with it. I wasn't discussing either point you raised.
That is literally all it is. There is nothing else to it. You get P2P connections and a longer address. The rest is what they removed from the protocol, not what was added.
SLAAC is a huge and complex part of IPv6. Higher reliance on ICMPv6 is also a big part of it. Networking stacks for IPv6 are also more complex, especially if you want to support SLAAC, requiring things like multiple IPs on every machine by default, and so on. The very fact that you have to choose between static IP, SLAAC, and DHCPv6 is another complication - if the choice is even there, as some major devices don't support DHCPv6 (Android).
SLAAC is stupid simple. The router just sends out its address, the netmask and optionally DNS servers. You can configure each host on your network to use the MAC address based suffix, a privacy one (random and changes several times an hour), or a static suffix. This is way simpler than DHCP which is stateful and requires multiple back and forths with the DHCP server.
And yes each host/interface can have more than one address which is amazing compared to having to create virtual interfaces for IPv4. You can literally just add more addresses.
Oh and when working with Docker or other container systems you can just use a link-local subnet instead of setting up a virtual network which makes things so much easier and nicer. There it really is zero configuration, not even firewall rules. It takes less effort to do this than to use IPv4.
And yes each host/interface can have more than one address which is amazing compared to having to create virtual interfaces for IPv4. You can literally just add more addresses.
Oh and when working with Docker or other container systems you can just use a link-local subnet instead of setting up a virtual network which makes things so much easier and nicer. There it really is zero configuration, not even firewall rules. It takes less effort to do this than to use IPv4.
> SLAAC is a huge and complex part of IPv6.
Complex? Could you elaborate what exactly is complex about SLAAC? Are you referring to the various address generation modes?
Complex? Could you elaborate what exactly is complex about SLAAC? Are you referring to the various address generation modes?
SLAAC doesn't exist with IPv4. If you want SLAAC, you have to run v6. Nobody forces you to use SLAAC. It's not an argument against the use of v6.
> Private IP space is incredibly useful. I build it and set it up -- my ISP does not have control. This is _gone_ with IPv6 and it makes things much more complicated than they need to.
Not in the least; IPv6 has private address space just like IPv4.
Not in the least; IPv6 has private address space just like IPv4.
> Private IP space is incredibly useful ... This is _gone_ with IPv6
No, it's not. Learn about ULAs:
https://en.wikipedia.org/wiki/Unique_local_address
No, it's not. Learn about ULAs:
https://en.wikipedia.org/wiki/Unique_local_address
> Private IP space is incredibly useful. I build it and set it up -- my ISP does not have control.
You can have that with IPv6, too. You can even get your own ULA prefix that (hopefully [1]) only you will ever use: https://ula.ungleich.ch/
[1]: Technically, it doesn’t prevent anybody else from using the same space as you. (And you can’t advertise it, of course.)
You can have that with IPv6, too. You can even get your own ULA prefix that (hopefully [1]) only you will ever use: https://ula.ungleich.ch/
[1]: Technically, it doesn’t prevent anybody else from using the same space as you. (And you can’t advertise it, of course.)
> the whole standard is built around this use case most people don't need most of the time.
This seems to be a function of when it was developed, starting in the early 90s before the internet as we know it today, particularly the web, even existed. Security wasn’t seen the same way then, because the threats we have today simply didn’t exist.
Not every company in the world had its own private networks, so there weren’t even good examples to follow. The result was a system designed in the effective equivalent of a vacuum, without regard for how the internet would actually end up being used. The result is the situation you described.
This seems to be a function of when it was developed, starting in the early 90s before the internet as we know it today, particularly the web, even existed. Security wasn’t seen the same way then, because the threats we have today simply didn’t exist.
Not every company in the world had its own private networks, so there weren’t even good examples to follow. The result was a system designed in the effective equivalent of a vacuum, without regard for how the internet would actually end up being used. The result is the situation you described.
> This is _gone_ with IPv6
Incorrect. There is the ULA range, fc00::/7, which is not routable and can be used in the same place you'd use 192.168.0.0/16 or similar.
You can even do something like fc00::192:168:0:0/120 if you really want.
> There is really no reason for most devices to be publicly reachable.
If you want things to work in one direction only, you really want television or radio. This is how most people really treat the Internet, unfortunately.
Incorrect. There is the ULA range, fc00::/7, which is not routable and can be used in the same place you'd use 192.168.0.0/16 or similar.
You can even do something like fc00::192:168:0:0/120 if you really want.
> There is really no reason for most devices to be publicly reachable.
If you want things to work in one direction only, you really want television or radio. This is how most people really treat the Internet, unfortunately.
> I learn new things all the time. IPv6 is much more complicated, and importantly, more complicated than it needs to be. There is really no reason for most devices to be publicly reachable.
Sigh. This myth really won't die.
Publicly addressable ≠ publicly reachable.
With my last ISP I had IPv6: every device (including my printer) on my local network had a public IPv6 address, but exactly zero were reachable thanks to the stateful packet inspection (SPI) on my Asus.
Sigh. This myth really won't die.
Publicly addressable ≠ publicly reachable.
With my last ISP I had IPv6: every device (including my printer) on my local network had a public IPv6 address, but exactly zero were reachable thanks to the stateful packet inspection (SPI) on my Asus.
You’re either arguing about semantics or missed the point they were trying to make. If it doesn’t have to be publicly reachable, why should it be publicly addressable in the first place? I can’t think of any common requirement that will be afforded to users having devices that will never need to be publicly reachable be publicly addressable. Considering most peoples use cases solely involve home networks of devices that they definitely do not want to be publicly reachable, why is needing to explicitly disallow that better for them?
In non-abstract terms, I just don’t see how that works better.
In non-abstract terms, I just don’t see how that works better.
> I can’t think of any common requirement that will be afforded to users having devices that will never need to be publicly reachable be publicly addressable.
Because you do not know ahead of time which devices may have such a need, and by allowing for the possibility you open up more flexibility.
> [Residential customers] don't care about engineering, but they sure do create support tickets about broken P2P applications, such as Xbox/PS gaming applications, broken VoIP in gaming lobbies, failure of SIP client to punch through etc. All these problems don't exist on native routed (and static) IPv6.
> In order for P2P to work as close as possible to routed IPv6 in NATted IPv4, we had to deploy a bunch of workarounds such as EIM-NAT to allow TCP/UDP P2P punching to work both ways, we had to allow hairpinning on the CGNAT device to allow intra-CGNAT traffic to work between to CGNAT clients, as TURN can only detect the public-facing IP:Port, hairpinning allow 100.64.0.0/10 clients to talk to each other over the CGNATted public IP:Port.
* https://blog.ipspace.net/2025/03/response-end-to-end-connect...
By having (a) a public address, and (b) a CPE that supports PCP/IGD hole punching, you eliminate a whole swath of infrastructure (ICE/TURN/etc) and kludges.
When it was first released, Skype was peer-to-peer, but because of NAT "super nodes" had to be invented in their architecture so that the clients/peers could have someone to 'bounce' off of to connect. But because of the prevalence of NAT, central servers are now the norm.
A lot of folks on HN complain about centralization and concentration on the Internet, but how can it be otherwise when folks push back against technologies that would allow more peer-to-peer architectures?
Because you do not know ahead of time which devices may have such a need, and by allowing for the possibility you open up more flexibility.
> [Residential customers] don't care about engineering, but they sure do create support tickets about broken P2P applications, such as Xbox/PS gaming applications, broken VoIP in gaming lobbies, failure of SIP client to punch through etc. All these problems don't exist on native routed (and static) IPv6.
> In order for P2P to work as close as possible to routed IPv6 in NATted IPv4, we had to deploy a bunch of workarounds such as EIM-NAT to allow TCP/UDP P2P punching to work both ways, we had to allow hairpinning on the CGNAT device to allow intra-CGNAT traffic to work between to CGNAT clients, as TURN can only detect the public-facing IP:Port, hairpinning allow 100.64.0.0/10 clients to talk to each other over the CGNATted public IP:Port.
* https://blog.ipspace.net/2025/03/response-end-to-end-connect...
By having (a) a public address, and (b) a CPE that supports PCP/IGD hole punching, you eliminate a whole swath of infrastructure (ICE/TURN/etc) and kludges.
When it was first released, Skype was peer-to-peer, but because of NAT "super nodes" had to be invented in their architecture so that the clients/peers could have someone to 'bounce' off of to connect. But because of the prevalence of NAT, central servers are now the norm.
A lot of folks on HN complain about centralization and concentration on the Internet, but how can it be otherwise when folks push back against technologies that would allow more peer-to-peer architectures?
> by allowing for the possibility you open up more flexibility.
The problem is that flexibility is often the enemy of security, and that’s certainly true here. Corporate networks don’t want to allow even the possibility of devices that are supposed to be private being publicly addressable. Arguing that it’s “simpler” or “more flexible” is like arguing that we don’t need firewalls, for the same reasons. And in fact, that argument used to be made quite regularly. It’s just that no-one who deals with security has ever taken it seriously.
The problem is that flexibility is often the enemy of security, and that’s certainly true here. Corporate networks don’t want to allow even the possibility of devices that are supposed to be private being publicly addressable. Arguing that it’s “simpler” or “more flexible” is like arguing that we don’t need firewalls, for the same reasons. And in fact, that argument used to be made quite regularly. It’s just that no-one who deals with security has ever taken it seriously.
It's baffling to argue that NAT is the real driver of centralization for internet technologies.
It surely was a big factor.
When internet finally became popular, hosting a website on your own machine already became infeasible.
When internet finally became popular, hosting a website on your own machine already became infeasible.
What do you mean by popular? I hosted a site on a home machine in the early teens. If you don't know how to do that with NAT, you should not have a web server under your control exposed to the internet.
The early teens didn’t have huge proliferation of ISPs using CGNATs.
These days ISP can’t get hold of new IPv4 blocks, and increasingly don’t provide public IP addresses to residential routers, not without having to pay extra for that lowly single IPv4 address.
Hosting a website behind a NAT isn’t as trivial as it used to be, and for many it’s now impossible without IPv6.
These days ISP can’t get hold of new IPv4 blocks, and increasingly don’t provide public IP addresses to residential routers, not without having to pay extra for that lowly single IPv4 address.
Hosting a website behind a NAT isn’t as trivial as it used to be, and for many it’s now impossible without IPv6.
> It's baffling to argue that NAT is the real driver of centralization for internet technologies.
It doesn't help.
It doesn't help.
What is then?
Capitalism, essentially. Companies can make more money from centralized control over systems than from truly distributed systems, and customers are suckers for the simplicity of delegating their needs to single providers.
The reason Google bought and destroyed dejanews.com, for example (try visiting that site) was to weaken one of the distributed sources of competition. Similar for RSS.
The reason Google bought and destroyed dejanews.com, for example (try visiting that site) was to weaken one of the distributed sources of competition. Similar for RSS.
I'd like to know the average number of broadband customers that make support tickets because of NAT. I'll bet it's far less than 1%. And you really think NAT, rather than SV betting huge on cloud services and surveillance capitalism, was the reason that everything is centralized? Come on...
>>Yes, a firewall can prevent these connection
>Publicly addressable ≠ publicly reachable.
I already addressed this, and I know how firewalls work. It would be nice if on a per-device basis I could opt into a choice to be publicly addressable. Instead, the entire standard is built around this.
>Publicly addressable ≠ publicly reachable.
I already addressed this, and I know how firewalls work. It would be nice if on a per-device basis I could opt into a choice to be publicly addressable. Instead, the entire standard is built around this.
You literally can. You can just use local link addresses, IPv6 routers are guarantee not to forward those packets out of the network, or forward traffic into the network addresses to one of those IPs. Devices within the network can all still talk to each other.
If you really want to do the full Monty, add a NAT to your IPv6 router to have it translate to the local-link addresses, just like it would on IPv4.
I would highlight this is also identical to IPv4, which notably is also a standard built around the idea that every device in the world can, and should, be given a publicly addressable IP. Many large corporations and universities with /8 IP blocks do exactly this. Unfortunately when they originally wrote the IPv4 standard they slightly underestimated how many devices would eventually connect to the internet.
If you really want to do the full Monty, add a NAT to your IPv6 router to have it translate to the local-link addresses, just like it would on IPv4.
I would highlight this is also identical to IPv4, which notably is also a standard built around the idea that every device in the world can, and should, be given a publicly addressable IP. Many large corporations and universities with /8 IP blocks do exactly this. Unfortunately when they originally wrote the IPv4 standard they slightly underestimated how many devices would eventually connect to the internet.
If you disable the firewall with a “master disable” I suspect IPv6 routes through on at least some routers. Meanwhile if the NAT is disabled, it almost surely takes the route with it, and even if it somehow routes thorugh you probably won’t get a DHCP lease from your ISP for more than a device or two.
> you do expose what used to be private addresses with IPv6
its been 10 years since i first rolled my eyes at ipv6 due to this problem. youre saying its still a problem, over a decade later? ugh. bring on ipv7 or ipv8.
its been 10 years since i first rolled my eyes at ipv6 due to this problem. youre saying its still a problem, over a decade later? ugh. bring on ipv7 or ipv8.
Not really, privacy extensions are usually on by default, at least on Windows and Linux. This means temporary ipv6 addresses will be used for outbound traffic and rotated regularly (usually every 24h by default, if I'm not mistaken). And if you're worried about tracking, we have lost this war ages ago, ipv6 wouldn't meaningfully change that.
> its been 10 years since i first rolled my eyes at ipv6 due to this problem.
You might find this comment [0] informative.
You might also be interested to know that the ULA space was defined and reserved in October, 2005. If you of ten years ago had done a little more research, you'd have discovered that the problem had been solved ~ten years prior.
[0] <https://news.ycombinator.com/item?id=46468426>
You might find this comment [0] informative.
You might also be interested to know that the ULA space was defined and reserved in October, 2005. If you of ten years ago had done a little more research, you'd have discovered that the problem had been solved ~ten years prior.
[0] <https://news.ycombinator.com/item?id=46468426>
A NAT is part of a firewall, not a separate thing, so if the firewall is misconfigued, then your NAT may not be working either.
On not running out of (private) IPs, I guess you've never had the fun of having to deal with overlapping ranges (because it isn't the number of IPs that's the issue, it's how the ranges are allocated). While this can still happen on IPv6, there are so many more subnets that this is far less likely.
Also, a key thing that IPv6 makes obvious (which is also true to some extent of IPv4, but that most systems try to avoid showing) is that each link can have multiple IPs (there will be at least one link-local address), and so while your ISP can provide you a public range, you don't need to use it if you do not want to, you can always use an Unique Local Address (ULA - https://en.wikipedia.org/wiki/Unique_local_address), which reduce the chance of overlapping ranges.
On not running out of (private) IPs, I guess you've never had the fun of having to deal with overlapping ranges (because it isn't the number of IPs that's the issue, it's how the ranges are allocated). While this can still happen on IPv6, there are so many more subnets that this is far less likely.
Also, a key thing that IPv6 makes obvious (which is also true to some extent of IPv4, but that most systems try to avoid showing) is that each link can have multiple IPs (there will be at least one link-local address), and so while your ISP can provide you a public range, you don't need to use it if you do not want to, you can always use an Unique Local Address (ULA - https://en.wikipedia.org/wiki/Unique_local_address), which reduce the chance of overlapping ranges.
Why do you think NAT is part of a firewall? NAT and firewall are two completely separate things that can exist independently of each other.
Also overlapping ranges are an orthogonal issue that can occur with IPv6 private network range as well.
IPv6 brings not only bigger address range but also a big bag of other things that one cannot ignore, are complicated and which are often a source of problems. That's why people stick with IPv4 even at the cost of NAT, because the number of things they have to care about is much smaller.
Also overlapping ranges are an orthogonal issue that can occur with IPv6 private network range as well.
IPv6 brings not only bigger address range but also a big bag of other things that one cannot ignore, are complicated and which are often a source of problems. That's why people stick with IPv4 even at the cost of NAT, because the number of things they have to care about is much smaller.
> NAT and firewall are two completely separate things that can exist independently of each other.
This is kind of like saying that web browsers don't have to have a graphical interface. Or that a web browser doesn't necessarily support HTTPS. It's correct, but not practically correct.
The reality is that essentially all NAT software you'll actually encounter will be integrated into a stateful firewall because the two systems share so many functions that most projects and products that do one will also do the other. If you have a system with NAT set up and there is no packet filtering, it's most often because you've intentionally gone and disabled all the packet filtering, not because you need separate software for it.
It is important to understand that NAT doesn't have any inherent security to it, but criticizing people for talking like NAT is a feature built into firewalls when NAT is overwhelmingly a feature built into firewalls is a pretty unfair reading when we're talking about general deployments. Even with the technical audience of HN, we're not discussing carrier grade NAT here or other highly specialized or exceptional deployments.
This is kind of like saying that web browsers don't have to have a graphical interface. Or that a web browser doesn't necessarily support HTTPS. It's correct, but not practically correct.
The reality is that essentially all NAT software you'll actually encounter will be integrated into a stateful firewall because the two systems share so many functions that most projects and products that do one will also do the other. If you have a system with NAT set up and there is no packet filtering, it's most often because you've intentionally gone and disabled all the packet filtering, not because you need separate software for it.
It is important to understand that NAT doesn't have any inherent security to it, but criticizing people for talking like NAT is a feature built into firewalls when NAT is overwhelmingly a feature built into firewalls is a pretty unfair reading when we're talking about general deployments. Even with the technical audience of HN, we're not discussing carrier grade NAT here or other highly specialized or exceptional deployments.
SNAT absolutely has intrinsic features that are utilized for security purposes.
This isn't to disagree with your main point. Many people in this topic have an oddly narrow definition "firewall" that tends to fall along the lines of "whatever makes me right and you wrong".
A statefull SNAT implementation itself has most of the characteristics of a "firewall".
This isn't to disagree with your main point. Many people in this topic have an oddly narrow definition "firewall" that tends to fall along the lines of "whatever makes me right and you wrong".
A statefull SNAT implementation itself has most of the characteristics of a "firewall".
> SNAT absolutely has intrinsic features that are utilized for security purposes.
Yes, but those features aren't there because they're security features. They're incidental to how NAT functions. It's not inherently secure. The intention of the design is to permit hosts on a network that is not Internet-routable to be able to send traffic that is Internet-routable. That's not a security feature. That's allowing traffic to pass that would ordinarily get black-holed.
> A statefull SNAT implementation itself has most of the characteristics of a "firewall".
Sure, but you should recognize that that's the same as saying a stateful SNAT implementation is an incomplete stateful firewall.
If your goal is to use private addresses, you should use NAT. The point is that if your goal is security, then you should configure a firewall.
Don't expect software that isn't designed to provide you security to provide you with any security.
Yes, but those features aren't there because they're security features. They're incidental to how NAT functions. It's not inherently secure. The intention of the design is to permit hosts on a network that is not Internet-routable to be able to send traffic that is Internet-routable. That's not a security feature. That's allowing traffic to pass that would ordinarily get black-holed.
> A statefull SNAT implementation itself has most of the characteristics of a "firewall".
Sure, but you should recognize that that's the same as saying a stateful SNAT implementation is an incomplete stateful firewall.
If your goal is to use private addresses, you should use NAT. The point is that if your goal is security, then you should configure a firewall.
Don't expect software that isn't designed to provide you security to provide you with any security.
SNAT is often a feature built on a network stack that also provides other "firewall" functionalities like filtering packets. Configuring SNAT is configuring a firewall? Or is only dropping packets a firewall? Or does the device need "firewall" printed on it? Does a device that has "firewall" printed on it still count as a firewall if it's not configured to filter packets? What type of filtering makes it a firewall? If an SNAT implementation drops packets is it a firewall? Is a linux/windows/bsd box with multiple interfaces a firewall? What if I slap "firewall" label on the box; a firewall now?
SNAT can be used to mask source IP and that can absolutely be utilized strategically as a layer of "security".
SNAT can be used to mask source IP and that can absolutely be utilized strategically as a layer of "security".
If your ISP delivered you a packet with a destination address of 192.168.0.5, there's a good chance your router would deliver it to that device without consulting the port forwarding table. In this way, NAT isn't a firewall and you're relying on your ISP's routing policy as your actual firewall.
If my ISP sent me a billion dollars I would be a billionaire.
What's represents a "good chance" the router is so grossly misconfigured as to allow inbound traffic no destined for the IP assigned to the WAN interface to be routed to one of the internal interfaces? I wouldn't be surprised, but what's a "good chance"? Is there data on this?
A typical, correctly configured SNAT implementation would most likely have the characteristics commonly attributed to a "firewall". An incorrectly configured network device may not have the characteristics commonly attributed to a "firewall", regardless of its ability to actually inspect and drop packets(which just about every commonly used OS network stack can do out of the box).
But even an SNAT implementation without typical "firewall" characteristics has intrinsic characteristics related to security; such as source IP masking. Which doesn't even need to be private.
What's represents a "good chance" the router is so grossly misconfigured as to allow inbound traffic no destined for the IP assigned to the WAN interface to be routed to one of the internal interfaces? I wouldn't be surprised, but what's a "good chance"? Is there data on this?
A typical, correctly configured SNAT implementation would most likely have the characteristics commonly attributed to a "firewall". An incorrectly configured network device may not have the characteristics commonly attributed to a "firewall", regardless of its ability to actually inspect and drop packets(which just about every commonly used OS network stack can do out of the box).
But even an SNAT implementation without typical "firewall" characteristics has intrinsic characteristics related to security; such as source IP masking. Which doesn't even need to be private.
> when NAT is overwhelmingly a feature built into firewalls
This is just not correct. NAT and firewall are simply orthogonal concepts and can and often are deployed separately. A simple example is your average small SOHO router, which usually has NAT but quite a lot of them lack a firewall.
This is just not correct. NAT and firewall are simply orthogonal concepts and can and often are deployed separately. A simple example is your average small SOHO router, which usually has NAT but quite a lot of them lack a firewall.
> if the firewall is misconfigued, then your NAT may not be working either.
But in that case, it's very obvious because your access to the WAN side of your router won't work from anywhere except the router itself.
I like this "fail-secure" nature of NAT. If your firewall fails on a network with globally-routable IPv6 addresses, it might not be so obvious as traffic might still flow through.
But in that case, it's very obvious because your access to the WAN side of your router won't work from anywhere except the router itself.
I like this "fail-secure" nature of NAT. If your firewall fails on a network with globally-routable IPv6 addresses, it might not be so obvious as traffic might still flow through.
It provides no security by itself. There have been (and still are) countless vulnerable Internet reachable NAT routers which can easily be exploited to provide access to the whole private network behind it. NAT by itself can't be relied on to provide any security – you need correctly configured firewalls for that. An ISP provider might provide a sensibly configured firewall with the home router, but they may also be operating an easily exploitable backdoor into your private network.
Practically speaking, even without any firewall, NAT provides some level of security. If I can't route to your network, I can't access it. Yes, theoretically someone may establish a route to an RFC-1918 address block across the Internet or within your ISP, but doing so without ISP cooperation is unlikely. To say it is "easily" exploitable is an over-exaggeration.
>If I move to IPv6 then my "internal" network address space is at the whim of my ISP.
This is a major problem to me before I'd go wholesale IPv6 at home as the primary way I address and connect to hosts
I have IPv6 enabled, but it's just all defaults. My traffic is going out over the internet on IPv6, my home automation stuff in the house using Matter is on IPv6, but for the few server-types that I have in the house they are still identifiable by me by their IPv4, and my addressing to get into my network from outside is via my ISP's IPv4 address
There really needs to be a universal way to bring IPv6 addresses to your ISP, so they're portable like a phone number. Both so that I can take them with me if I switch providers and so that my ISP can't arbitrarily change them from underneath me
This is a major problem to me before I'd go wholesale IPv6 at home as the primary way I address and connect to hosts
I have IPv6 enabled, but it's just all defaults. My traffic is going out over the internet on IPv6, my home automation stuff in the house using Matter is on IPv6, but for the few server-types that I have in the house they are still identifiable by me by their IPv4, and my addressing to get into my network from outside is via my ISP's IPv4 address
There really needs to be a universal way to bring IPv6 addresses to your ISP, so they're portable like a phone number. Both so that I can take them with me if I switch providers and so that my ISP can't arbitrarily change them from underneath me
With IPv6, it's common to have multiple addresses on an interface.
So on options is to assign yourself an [RFC 4193](https://datatracker.ietf.org/doc/html/rfc4193) fc00::/7 random prefix that you use for local routing that is stable, while the ISP prefix can be used for global routing.
Then you don't need to renumber your local network regardless of what your ISP does.
So on options is to assign yourself an [RFC 4193](https://datatracker.ietf.org/doc/html/rfc4193) fc00::/7 random prefix that you use for local routing that is stable, while the ISP prefix can be used for global routing.
Then you don't need to renumber your local network regardless of what your ISP does.
What if I want my devices visible on the public internet? Then I'm tied to my ISP's addresses. Or, I have to maintain both addressing schemes
That's why I mentioned multiple addresses. The public addresses (assigned using SLAAC or DHCPv6) are for global reachability, while you use the local prefix for stable addresses within your network.
If you want stable global addresses, you should request an AS number and prefix, and choose a provider that allows you to announce it with BGP.
If you want stable global addresses, you should request an AS number and prefix, and choose a provider that allows you to announce it with BGP.
> and choose a provider
Lots of people don't have much choice.
Frankly, my IoT washing machine having a public IP address sounds like it'll get shut off when I don't let it online or don't pay my subscription fee.
Lots of people don't have much choice.
Frankly, my IoT washing machine having a public IP address sounds like it'll get shut off when I don't let it online or don't pay my subscription fee.
> Lots of people don't have much choice.
Yeah but it's not like IPv4 is any better at giving you a stable public address.
Yeah but it's not like IPv4 is any better at giving you a stable public address.
Funfact my washing machine has a public ipv6 address, but egress/ingress conns to the WAN are blocked. works great.
This is also the case with IPv4.
> There really needs to be a universal way to bring IPv6 addresses to your ISP...
There is. It's "Provider-Independent" address space.
It's used sparingly because widespread use of it would explode the size of routing tables.
I think you could also "simply" [0] become your own AS/LIR/whatever and negotiate with your ISP to route your prefix/subnet/whatever to your site (or some box in a colo somewhere that you attach to your site with some sort of tunnel).
[0] It is my understanding that it is often not at all simple to do this.
There is. It's "Provider-Independent" address space.
It's used sparingly because widespread use of it would explode the size of routing tables.
I think you could also "simply" [0] become your own AS/LIR/whatever and negotiate with your ISP to route your prefix/subnet/whatever to your site (or some box in a colo somewhere that you attach to your site with some sort of tunnel).
[0] It is my understanding that it is often not at all simple to do this.
I doubt this will ever happen, as it would make things extremely easy for spammers and scammers.
Why? You could easily block their range and it'd be blocked no matter where they went
IPv6 is already a nightmare for dealing with scammers and spammers. It's very often I get weirdly blocked because someone has abused my ISP's (AT&T) IPv6 block that I'm on and Wikipedia or whoever has blocked an entire /48 or something and it's virtually impossible to get a delegation outside of that range
IPv6 is already a nightmare for dealing with scammers and spammers. It's very often I get weirdly blocked because someone has abused my ISP's (AT&T) IPv6 block that I'm on and Wikipedia or whoever has blocked an entire /48 or something and it's virtually impossible to get a delegation outside of that range
> That's a non sequitur. I can have a both a firewall and a NAT. The two layers are better than one because at least my address is shouldn't be routable even if I failed to configure my firewall correctly.
You have two layers of indirection and one layer of security. If you failed to configure your firewall correctly, you would be better off without NAT because you would become aware of it quicker and not rely on NAT.
NAT doesn't really do anything other than address conservation because of NAT-punching techniques like STUN/TURN/UPnP, which are nessisary because NAT's features are bugs.
You have two layers of indirection and one layer of security. If you failed to configure your firewall correctly, you would be better off without NAT because you would become aware of it quicker and not rely on NAT.
NAT doesn't really do anything other than address conservation because of NAT-punching techniques like STUN/TURN/UPnP, which are nessisary because NAT's features are bugs.
> I can have a both a firewall and a NAT. The two layers are better than one because at least my address is shouldn't be routable even if I failed to configure my firewall correctly.
That's not true. When you configure just NAT (with e.g. nftables on Linux), the NATed devices are still reachable from the outside, you just have to add an entry to your routing table to reach that internal address space using the router.
That's not true. When you configure just NAT (with e.g. nftables on Linux), the NATed devices are still reachable from the outside, you just have to add an entry to your routing table to reach that internal address space using the router.
"Just add an entry to your routing table" ... it's virtually impossible to do that for RFC-1918 addresses across the internet. It will be filtered at the ISP border or an upstream. Is it theoretically possible? Yes. Is it an actual risk? Probably not.
Well, if you're other customer of the ISP on the same network, then that may get more interesting... (or inside VPS provider's network)
> Well, an ostensible advantage of IPv6 is publicly routable addresses. I know how to configure my internal IPv4 network with host table entries and so on. If I move to IPv6 then my "internal" network address space is at the whim of my ISP.
This is not quite correct. You have two simple options for avoiding this: DNS and SLAAC. By giving all of your hosts dns names you don’t have to care about the individual addresses much. If they change just update the dns zone.
The second is to configure a Unique Local Address for each host using SLAAC. Have your router announce a prefix inside of fd00::/7 so that every one of your computers ends up with a private address as well as the public one. This is like using a reserved private address in IPv4, such as 10.0.0.0/8, except that there are a lot more possible networks. There is only one 10.0.0.0/8, but the convention with IPv6 ULAs is to generate 40 random bits and use them to make a /40. Add 16 more bits for a subnet id to create a /64 that your router will advertise as a prefix. This is probably overkill for most of us, but it does enable us to merge networks without causing address collisions. You can keep using them no matter what happens. Even changing ISP won't change these addresses.
Of course the third option is to buy IP transit service instead of internet access service. You can then go to your local RIR and ask them to assign you your own address block. Announcing that address block using BGP gives you a permanent block of routable addresses that follows you from ISP to ISP. But most people find that to be a bit of a hassle compared to consumer–grade internet service.
This is not quite correct. You have two simple options for avoiding this: DNS and SLAAC. By giving all of your hosts dns names you don’t have to care about the individual addresses much. If they change just update the dns zone.
The second is to configure a Unique Local Address for each host using SLAAC. Have your router announce a prefix inside of fd00::/7 so that every one of your computers ends up with a private address as well as the public one. This is like using a reserved private address in IPv4, such as 10.0.0.0/8, except that there are a lot more possible networks. There is only one 10.0.0.0/8, but the convention with IPv6 ULAs is to generate 40 random bits and use them to make a /40. Add 16 more bits for a subnet id to create a /64 that your router will advertise as a prefix. This is probably overkill for most of us, but it does enable us to merge networks without causing address collisions. You can keep using them no matter what happens. Even changing ISP won't change these addresses.
Of course the third option is to buy IP transit service instead of internet access service. You can then go to your local RIR and ask them to assign you your own address block. Announcing that address block using BGP gives you a permanent block of routable addresses that follows you from ISP to ISP. But most people find that to be a bit of a hassle compared to consumer–grade internet service.
> By giving all of your hosts dns names you don’t have to care about the individual addresses much. If they change just update the dns zone
"just" update the zone? Yikes. I prefer to not take that downtime in the first place. (And I know from experience, I've written hooks for dhcpcd that automatically reconfigure my zone file, firewall rules, rad.conf, etc, if I get a new network prefix! But I don't pretend that this is a workable approach for everyone.)
> The second is to configure a Unique Local Address for each host using SLAAC
Yes, this is the way. Where you used to use RFC1918 addresses, just use ULA. It's simple and fits the mental model you used to have with IPv4. You don't even need NAT, just give both the GUA and ULA addresses to each host, and use the ULA everywhere you want LAN-like semantics.
"just" update the zone? Yikes. I prefer to not take that downtime in the first place. (And I know from experience, I've written hooks for dhcpcd that automatically reconfigure my zone file, firewall rules, rad.conf, etc, if I get a new network prefix! But I don't pretend that this is a workable approach for everyone.)
> The second is to configure a Unique Local Address for each host using SLAAC
Yes, this is the way. Where you used to use RFC1918 addresses, just use ULA. It's simple and fits the mental model you used to have with IPv4. You don't even need NAT, just give both the GUA and ULA addresses to each host, and use the ULA everywhere you want LAN-like semantics.
“There is only one 10.0.0.0/8”
Also:
- There are 16 172.{16-31}.0.0/16s (I used 172.23 because Docker uses one of these)
- There are 256 192.168.{0-255}.0/8s
And that’s just what RFC1918 gives us. There are other private subnets defined in newer RFCs.
I like IPv6 but it caused issues with browsers accepting my Letsencrypt certs on my website, so my website is now IPv4 only.
“Announcing that address block using BGP gives you a permanent block of routable addresses that follows you from ISP to ISP.”
Enough people have done this that BGP networking has become a real mess at the ISP level. Can BGP really handle every person in the world doing this?
Also:
- There are 16 172.{16-31}.0.0/16s (I used 172.23 because Docker uses one of these)
- There are 256 192.168.{0-255}.0/8s
And that’s just what RFC1918 gives us. There are other private subnets defined in newer RFCs.
I like IPv6 but it caused issues with browsers accepting my Letsencrypt certs on my website, so my website is now IPv4 only.
“Announcing that address block using BGP gives you a permanent block of routable addresses that follows you from ISP to ISP.”
Enough people have done this that BGP networking has become a real mess at the ISP level. Can BGP really handle every person in the world doing this?
Class B or the 12 block is 172.16.0.0/12. So: 10/8, 172.16/12, 192.168/16.
Yes, I know that there are other private subnets in IPv4. My comparison was specifically between IPv6 ULAs and 10.0.0.0/8 specifically because of the size. You won’t have to renumber your networks when you grow in size because 2⁷² addresses is enough for just about any organization.
> Can BGP really handle every person in the world doing this?
Eh, probably not. I did say that it wasn’t for everyone. You have to fill out a form, and then they announce to the world that you did it. And if you configure your BGP announcements wrong you’ll get laughed at by everyone who watches those things. Most people can’t handle it.
On the other hand, the VP of Network Operations at the ISP I used once promised that they’ll honor BGP announcements even from residential customers. I guess once it’s automated that it doesn’t cost them anything extra. Could be a fun hobby.
And if enough people do it then we can simply improve BGP. Anything we invent we can improve, right?
> Can BGP really handle every person in the world doing this?
Eh, probably not. I did say that it wasn’t for everyone. You have to fill out a form, and then they announce to the world that you did it. And if you configure your BGP announcements wrong you’ll get laughed at by everyone who watches those things. Most people can’t handle it.
On the other hand, the VP of Network Operations at the ISP I used once promised that they’ll honor BGP announcements even from residential customers. I guess once it’s automated that it doesn’t cost them anything extra. Could be a fun hobby.
And if enough people do it then we can simply improve BGP. Anything we invent we can improve, right?
> That's a non sequitur. I can have a both a firewall and a NAT. The two layers are better than one because at least my address is shouldn't be routable even if I failed to configure my firewall correctly.
You talk about NAT like it's a single thing: it is not. There are at least three major varieties of NAT:
* https://blog.ipspace.net/2011/12/is-nat-security-feature/
See also various 'cones' that add complexity to getting things to work (and for which kludges like ICE/TURN/etc had to be invented):
* https://en.wikipedia.org/wiki/Network_address_translation#Me...
See also RFC 4787 which distinguishes between NAT mapping and NAT filtering. Also, also see perhaps "NAT Traversal Mess":
* https://blog.ipspace.net/2025/04/response-nat-traversal/
You talk about NAT like it's a single thing: it is not. There are at least three major varieties of NAT:
* https://blog.ipspace.net/2011/12/is-nat-security-feature/
See also various 'cones' that add complexity to getting things to work (and for which kludges like ICE/TURN/etc had to be invented):
* https://en.wikipedia.org/wiki/Network_address_translation#Me...
See also RFC 4787 which distinguishes between NAT mapping and NAT filtering. Also, also see perhaps "NAT Traversal Mess":
* https://blog.ipspace.net/2025/04/response-nat-traversal/
The RFC for NAT was extremely specific: this was only about creating more addresses, NOT security.
Because your devices are routable. You can’t be on the Internet without an IP. They just have some ephemeral addresses. But randomizing port numbers (that is NAT) is not a good security mechanism.
Because your devices are routable. You can’t be on the Internet without an IP. They just have some ephemeral addresses. But randomizing port numbers (that is NAT) is not a good security mechanism.
> The RFC for NAT was extremely specific: this was only about creating more addresses, NOT security.
It should also be noted that "NAT" is not some monolithic thing either, there are three 'major' varieties:
* https://blog.ipspace.net/2011/12/is-nat-security-feature/
It should also be noted that "NAT" is not some monolithic thing either, there are three 'major' varieties:
* https://blog.ipspace.net/2011/12/is-nat-security-feature/
Just FYI you can do ULA + NAT with IPv6 and get the same thing as RFC1918 + NAT on v4.
>I don't want any of my devices listening on the public address, much less multiple.
That is good for you, but given the option between an address scheme that requires a proxy and one that does not, I would prefer the latter.
>I can have a both a firewall and a NAT. The two layers are better than one because at least my address is shouldn't be routable even if I failed to configure my firewall correctly.
Why? NAT is a network tool. Firewall is a security control.
That is good for you, but given the option between an address scheme that requires a proxy and one that does not, I would prefer the latter.
>I can have a both a firewall and a NAT. The two layers are better than one because at least my address is shouldn't be routable even if I failed to configure my firewall correctly.
Why? NAT is a network tool. Firewall is a security control.
>I don't want any of my devices listening on the public address, much less multiple.
If you don't listen to public ports on IPv4, then there is no point in touting any of the benefits of IPv4. Even if you think NAT is good, you're not using it in the first place so why care about it?
You basically ruined your entire case with that sentence.
If you don't listen to public ports on IPv4, then there is no point in touting any of the benefits of IPv4. Even if you think NAT is good, you're not using it in the first place so why care about it?
You basically ruined your entire case with that sentence.
Great response. Your last point is particularly convincing and I never thought of it before. Even better, what happens if you use a failover WAN on your router?
> I don't want any of my devices listening on the public address, much less multiple.
Just because you don't shouldn't mean other people get denied this.
Just because you don't shouldn't mean other people get denied this.
> It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall. NAT is usually configured as part of your firewall, but is not a firewall.
Expanding on this. NAT as deployed in most soho/residential settings requires a stateful firewall to track connections + port mapping logic.A stateful firewall is also used for IPv6 edge security and using the same basic posture (out allow, in established/related only) except the only difference is it isn't also doing an address mapping. Nobody is out there saying folks should run a wide open IPv6 edge, and as far as I'm aware no one is shipping IPv6 ready consumer routers that do that (but I'm prepared to be proven wrong in the responses).
Expanding on this. NAT as deployed in most soho/residential settings requires a stateful firewall to track connections + port mapping logic.A stateful firewall is also used for IPv6 edge security and using the same basic posture (out allow, in established/related only) except the only difference is it isn't also doing an address mapping. Nobody is out there saying folks should run a wide open IPv6 edge, and as far as I'm aware no one is shipping IPv6 ready consumer routers that do that (but I'm prepared to be proven wrong in the responses).
"What happens when multiple devices in your /8 want to listen on port 80 and 443 on the public address?"
This is a feature not a flaw. The average person doesn't have anything acting as a server, and that's a good thing, because the only servers they'd have would be embedded garbage in poorly maintained or completely abandoned IOT devices with incompetent code that should not be publicly exposed, ever, in anything but a call out model.
This is a feature not a flaw. The average person doesn't have anything acting as a server, and that's a good thing, because the only servers they'd have would be embedded garbage in poorly maintained or completely abandoned IOT devices with incompetent code that should not be publicly exposed, ever, in anything but a call out model.
Firewall is a feature. Forced NAT that noone in the above described situation wants is just a flaw. And the other solution where you're forced to buy a fucking "public" number out of a grossly insufficient pool of those for $5/month for each of the NATted machines and your router, is a crime against humanity.
I'm naive with network security, so this is a honest question looking for a practical honest answer: Would my grandma's computer, with its old version of windows, be more or less safe with a NAT without DMZ configured?
Using a normal ISP issued router, wouldn’t make a lick of difference if it was IPv4 with a NAT or IPv6 without a NAT. They’re all configured out-of-the-box with a default deny firewall. I’m not actually aware of any residential grade router that doesn’t come configured like this.
Of course if the router is misconfigured, then all bets are off. But that’s true regardless of IPv4 vs IPv6, because people will just compromise your router first and use that as a launch pad for the rest of your network. Just like to do today with plenty of old residential routers.
Of course if the router is misconfigured, then all bets are off. But that’s true regardless of IPv4 vs IPv6, because people will just compromise your router first and use that as a launch pad for the rest of your network. Just like to do today with plenty of old residential routers.
You're not wrong, yet there's still no compelling reason to make an extra effort to switch to ipv6 when the limitations of ipv4 don't personally affect you.
But at this point you can just leave the factory settings on your devices, which mostly enable IPv6 by default anyways...
> What happens when multiple devices in your /8 want to listen on port 80 and 443 on the public address? Only one of them can. Now you're running a proxy.
I want to be running a proxy in that scenario, because I don't want any of it accidentally exposed.
> It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall. NAT is usually configured as part of your firewall, but is not a firewall.
Yes, but it's arguably helpful to have configuration mistakes still leave your internal network unexposed. It's harder to accidentally expose resources when your ISP won't route to them.
I want to be running a proxy in that scenario, because I don't want any of it accidentally exposed.
> It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall. NAT is usually configured as part of your firewall, but is not a firewall.
Yes, but it's arguably helpful to have configuration mistakes still leave your internal network unexposed. It's harder to accidentally expose resources when your ISP won't route to them.
> > - My ISP gives me a /64, what am I supposed to do with that anyways?
> What are you supposed to do with a /8? Do you have several million computers?
Except you can subnet an IPv4 /8. You can't subnet an IPv6 /64. For whatever stupid reason, and despite having 18 quintillion available addresses in a /64, you can't actually do anything useful with it other than yeet a bunch of devices on the same LAN segment.
(At least on pfSense, and when I looked into it some, that's apparently IPv6 design for some reason)
> What are you supposed to do with a /8? Do you have several million computers?
Except you can subnet an IPv4 /8. You can't subnet an IPv6 /64. For whatever stupid reason, and despite having 18 quintillion available addresses in a /64, you can't actually do anything useful with it other than yeet a bunch of devices on the same LAN segment.
(At least on pfSense, and when I looked into it some, that's apparently IPv6 design for some reason)
Your ISP gives you a IPv4 /32 which you don’t have a prayer of subnetting, you have to NAT.
With a IPv6 /64 you can (1) NAT, or (2) better, subnet it and use DHCPv6.
The only thing significant about /64 is that’s the smallest unit for SLAAC.
With a IPv6 /64 you can (1) NAT, or (2) better, subnet it and use DHCPv6.
The only thing significant about /64 is that’s the smallest unit for SLAAC.
> The only thing significant about /64 is that’s the smallest unit for SLAAC.
...which means you can't subnet it because you have to assume SLAAC might happen since that's the only thing ipv6 requires. Ergo, an ISP only giving you a /64 means you have to nat if you want subnets, and if you have to nat why wouldn't you use ipv4 instead where it's so much simpler?
...which means you can't subnet it because you have to assume SLAAC might happen since that's the only thing ipv6 requires. Ergo, an ISP only giving you a /64 means you have to nat if you want subnets, and if you have to nat why wouldn't you use ipv4 instead where it's so much simpler?
Android only supports slaac.
Strangely it supports DHCPv6 as a server but not as a client.
It's not strange. It's Google's plan to push ISPs into supporting SLAAC and giving you at least /64 instead of giving you a single /128 address.
It is not a bad thing actually.
It is not a bad thing actually.
I haven't looked at pfsense UI, but you can happily hand out a prefix to a device, which can then hand out its own prefixes. I do it with my k8s clusters, which means the node themseves have enough IPs addresses to launch their own routable k8s clusters.
Thats why its recommended that ISPs give /56 by default (and up to /48 if requested). This way you can do plenty of effortless subnetting. If your ISP is only giving you /64 even after you requested a larger subnet he is doing IPv6 WRONG.
You can totally subnet from /64, you just can't use SLAAC. The packet header doesn't care about your address allocation scheme.
At the same time SLAAC is the reason your ISP doesn't give you a /128.
At the same time SLAAC is the reason your ISP doesn't give you a /128.
Of course you can subnet ipv6, in fact I run several ipv6 subnets at home. You have to delegate a different prefix to each subnet.
They said that you can't subnet a /64, not that you can't subnet in IPv6. And while technically you can subnet even a /64, it's not supported by SLAAC, which means that, for example, you can't get an Android phone to work with auto-assigned addresses in a /80 IPv6 network.
>What happens if your ISP changes your IPv4 address?
Absolutely nothing, because the private IPs behind the NAT are agnostic of the public IP.
Absolutely nothing, because the private IPs behind the NAT are agnostic of the public IP.
Actually, all your open connections break (including outbound ones, inbound ones via UPnP which is commonly on by default, etc.)
No, my connections time out for a brief period of seconds or minutes and then everything is fine for the next two years (until my ISP cycles my IP out again) and I don't actually need to do anything to resolve this. I wouldn't even know when my IPv4 address changed because the impact is so minor. uPnP may be on by default but that doesn't mean most people are actually using it for anything.
And what do you think when ipv6 changes addresses? Notably, even less.
When my IPv6 changes my prefix changes and then my internal devices have new IP addresses and I don't know what those IPs are.
That is what link local addresses are for - which you can access your devices on just fine, and don't change. And bonus points - aren't externally routable either.
They are also much shorter. [https://en.wikipedia.org/wiki/Link-local_address]
One really nice thing about IPv6 is you can (and do) have many addresses, all of which work.
for example, you can add a manual fe80::5 address to one machine, and fe80::9 on another - and use those to access those machines on the local network. And not have to worry about that being externally addressable, or having conflicts, etc.
And they won't change when your external addresses change either (unless there is some weird software bug in your OS or something).
Though you probably want to use a unique local address range instead [https://en.wikipedia.org/wiki/Unique_local_address] as they're more equivalent to the 10.0.0.0/16 type behavior you're expecting.
They are also much shorter. [https://en.wikipedia.org/wiki/Link-local_address]
One really nice thing about IPv6 is you can (and do) have many addresses, all of which work.
for example, you can add a manual fe80::5 address to one machine, and fe80::9 on another - and use those to access those machines on the local network. And not have to worry about that being externally addressable, or having conflicts, etc.
And they won't change when your external addresses change either (unless there is some weird software bug in your OS or something).
Though you probably want to use a unique local address range instead [https://en.wikipedia.org/wiki/Unique_local_address] as they're more equivalent to the 10.0.0.0/16 type behavior you're expecting.
> > - My ISP gives me a /64, what am I supposed to do with that anyways?
> What are you supposed to do with a /8? Do you have several million computers?
The /8 was for private addresses, so "free" and uncontested, while the /64 is a public resource. Looking at it as extraneous or over provided is understandable IMHO, even if mathematically it's not supposed to get depleted.
At least it's not doing anything helpful for OP.
> What are you supposed to do with a /8? Do you have several million computers?
The /8 was for private addresses, so "free" and uncontested, while the /64 is a public resource. Looking at it as extraneous or over provided is understandable IMHO, even if mathematically it's not supposed to get depleted.
At least it's not doing anything helpful for OP.
The IPv4 10.0.0.0/8 (along with the other private ranges) runs into lots of problems when connecting two private networks (e.g. VPNs, VMs/docker, hotspotting), whereas that /64 will not conflict with anyone.
Yes, I can’t even use many 10.x subnets at home because my work VPN configures a huge routing table including many of them.
Basically I had no choice but to redo my home network if I wanted to use my new work laptop at home (and I work 100% remote).
Basically I had no choice but to redo my home network if I wanted to use my new work laptop at home (and I work 100% remote).
I "solved" this by running a separate VLAN for work machines that provides addresses in a slightly weird /24 carved out of the 172.16.0.0/12 [0] range. Is it as collision-resistant as a ULA address? No. But -sadly- I've yet to see an Enterprise VPN that wasn't run as an IPv4-only thing, so it's the best I can do.
[0] Or whatever the netmask actually is. I'm never sure about the 172.16.x.x space.
[0] Or whatever the netmask actually is. I'm never sure about the 172.16.x.x space.
I'd be tempted to shove that VPN into a network namespace together with jool, and NAT64 their 10.x subnets into, let's say, 2001:db8:a:b::/96, so that their 10.1.2.3 becomes 2001:db8:a:b::10.1.2.3. Then there's no overlap as viewed from outside the namespace.
And if you ever need to use another VPN that also clashes on 10.x, you can do the same thing but map that one into 2001:db8:a:c::/96. Then you've got 2001:db8:a:b::10.1.2.3 and 2001:db8:a:c::10.1.2.3, neither of which clash with either each other or your 10.1.2.3.
And if you ever need to use another VPN that also clashes on 10.x, you can do the same thing but map that one into 2001:db8:a:c::/96. Then you've got 2001:db8:a:b::10.1.2.3 and 2001:db8:a:c::10.1.2.3, neither of which clash with either each other or your 10.1.2.3.
I hadn’t really thought about that. That’s an actual, real (though still fairly minor) benefit.
> DHCPv6
Not supported by >50% of mobile devices
Not supported by >50% of mobile devices
TLS SNI routing has fixed the multiple authorities listening on one IPv4 address port 443.
Most ISP’s implement IPv6 by using the single IPv4 address as a v6 prefix. This results in the entire LAN needing to change local addresses every time the public IP changes. In practice this means a single brief power outage causes hundreds of devices to break instead of none.
Generally speaking ipv6 is useless for most home network users.
Overlapping 10/8 with corporate networks is not a problem, wireguard has solved this in all cases I’ve run into.
Most ISP’s implement IPv6 by using the single IPv4 address as a v6 prefix. This results in the entire LAN needing to change local addresses every time the public IP changes. In practice this means a single brief power outage causes hundreds of devices to break instead of none.
Generally speaking ipv6 is useless for most home network users.
Overlapping 10/8 with corporate networks is not a problem, wireguard has solved this in all cases I’ve run into.
> It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall.
Your router will open up any port for an ephemeral forwarding if the traffic looks like that forwarding is warranted. Any application can open arbitrary inbound pathways. "Application" also includes the Javascript you run in your Browser. Which is externally controlled.
Security folks call those techniques "hole punching" but they are how NAT is expected to work.
Security folks call those techniques "hole punching" but they are how NAT is expected to work.
> With NAT, I absolutely know my ESP32 is not vulnerable and exposed
I mean thats not actually true, uPnP will open ports up, as will misconfiguration.
The firewall is still the same in ipv6 vs 4, and has the same problems.
I mean thats not actually true, uPnP will open ports up, as will misconfiguration.
The firewall is still the same in ipv6 vs 4, and has the same problems.
Correct me if I'm wrong, but UPnP requires my ESP32 to initiate communication. Whereas giving it an IPv6 address would expose it to the entire www even before it attempts communication.
> Correct me if I'm wrong, but UPnP requires my ESP32 to initiate communication.
Not quite. Using UPnP, any host on your internal network can open a port for any other host. You may be thinking of NAT-PMP.
Additionally, by default UPnP mappings don't expire (unlike NAT-PMP mappings), so if a host crashes with an open port and your ESP32 inherits its IPv4 address, it will be exposed to the Internet.
Not quite. Using UPnP, any host on your internal network can open a port for any other host. You may be thinking of NAT-PMP.
Additionally, by default UPnP mappings don't expire (unlike NAT-PMP mappings), so if a host crashes with an open port and your ESP32 inherits its IPv4 address, it will be exposed to the Internet.
Actually I've never heard of NAT-PMP, so I'm just wrong ))
Thank you. I never considered the reused address vulnerability.
Thank you. I never considered the reused address vulnerability.
NAT is way harder to screw up than a firewall, especially in cases where the defaults were left untouched. Also what the other commenter said about your internal addresses being at the mercy of the ISP.
> > - What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.
>
> What happens if your ISP changes your IPv4 address?
To my internal net: nothing. All my internal addresses stay the same. All my firewall settings remain the same. Just to the outside world I come from elsewhere (which is good for my privacy, not sufficient obviously, though)
However if my IPv6 prefix changes all my IP based access control, which is a layer I use to limit what Internet of Shit devices can do, breaks. I could go to fe80 addresses for my local network, but those won't work across different network segments.
To my internal net: nothing. All my internal addresses stay the same. All my firewall settings remain the same. Just to the outside world I come from elsewhere (which is good for my privacy, not sufficient obviously, though)
However if my IPv6 prefix changes all my IP based access control, which is a layer I use to limit what Internet of Shit devices can do, breaks. I could go to fe80 addresses for my local network, but those won't work across different network segments.
You should use unique local addresses (ULAs, fc00::/7) not link-local addresses (fe80::/10) for this. Choose a random prefix and advertise it in your network (you can use some website like https://www.unique-local-ipv6.com if you want).
This prevents clashing subnets when using VPN like it sometimes happens with IPv4.
This prevents clashing subnets when using VPN like it sometimes happens with IPv4.
> - I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.
That's great until you need to connect to a work/client VPN that decided to also use 10.0.0.0/8.
> - Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.
Even on IPv4, having normal addresses for all your computers makes life so much nicer. Perhaps-trivial example, but one that matters to me: if two people live in one house and a third person lives in a different house, can they all play a network game together? IPv4 sucks at this.
That's great until you need to connect to a work/client VPN that decided to also use 10.0.0.0/8.
> - Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.
Even on IPv4, having normal addresses for all your computers makes life so much nicer. Perhaps-trivial example, but one that matters to me: if two people live in one house and a third person lives in a different house, can they all play a network game together? IPv4 sucks at this.
> That's great until you need to connect to a work/client VPN that decided to also use 10.0.0.0/8.
There's numerous other reserved IPv4 blocks that can be used: https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4. Would definitely not recommend to use 10/8 for private networks.
There's numerous other reserved IPv4 blocks that can be used: https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4. Would definitely not recommend to use 10/8 for private networks.
Landed on 172.16/22 for this reason however it's not uncommon how an enterprise to use all 3 private classes. One place I worked used 192.168 for management, 10 for servers, and 172 for wifi
Using 2 different classes has been a pretty common setup for wifi and wireless in my experience
Using 2 different classes has been a pretty common setup for wifi and wireless in my experience
> - My ISP gives me a /64, what am I supposed to do with that anyways?
There is recommendation (SHOULD, not MUST in RFC lingo) for ISPs to provide at least /56 to clients, but most domestic ISPs ignore this recommendation.
> - What happens if my ISP decides to change my prefix ?
> I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know.
Your ISP has paid 40€ for your IPv4 address. That's a cost they're most probably passing on to you.
> Every host routable from anywhere on the Internet? No thanks.
Every time you start a videoconference, there is a couple of seconds' pause while the peers perform NAT traversal.
Your ISP has paid 40€ for your IPv4 address. That's a cost they're most probably passing on to you.
> Every host routable from anywhere on the Internet? No thanks.
Every time you start a videoconference, there is a couple of seconds' pause while the peers perform NAT traversal.
> - It's hard to remember IPv6 addresses. The prospect of reconfiguring all my router and firewall rules looks rather painful.
fd00::1 is pretty easy to remember. It's your network, give yourself a sane and short prefix.
fd00::1 is pretty easy to remember. It's your network, give yourself a sane and short prefix.
That's a gripe I have with IPv6. There are too damn many special networks and addresses!
With IPv4 I can easily remember 10.0.0.0/8 and 192.168.0.0/16, but I can't remember the other one off the top of my head. (172.16.0.0/12 I think?). Multicast is 224.x.x.x/x IIRC, but definitely need to look that one up when I need it.
IPv6 has SO many special networks. Network. Public. Multicast. Link local. (Which isn't like an IPv4 link local, but apparently it can actually be on the LAN? IDK - I was just learning about it earlier today.) And every interface seems to have about 5 different addresses of each type.
With IPv4 I can easily remember 10.0.0.0/8 and 192.168.0.0/16, but I can't remember the other one off the top of my head. (172.16.0.0/12 I think?). Multicast is 224.x.x.x/x IIRC, but definitely need to look that one up when I need it.
IPv6 has SO many special networks. Network. Public. Multicast. Link local. (Which isn't like an IPv4 link local, but apparently it can actually be on the LAN? IDK - I was just learning about it earlier today.) And every interface seems to have about 5 different addresses of each type.
Amusingly, there a lot more special IPv4 networks that you just don't know about too. e.g. Link local IPv4 is 169.254.0.0/16. It just isn't auto-configured on every IPv4 interface by default, like fe80::/10 is on IPv6 interfaces, and the TCP/IP stacks on most platforms do not enforce the link-local properties of it in IPv4 like they do in IPv6.
It's like the difference between HTML and a strictly typed language. Permissiveness and flexibility is both a blessing and a curse. As with a lot of things, which thing it is in any given situation depends greatly on the situation.
It's like the difference between HTML and a strictly typed language. Permissiveness and flexibility is both a blessing and a curse. As with a lot of things, which thing it is in any given situation depends greatly on the situation.
For almost all cases, there is absolutely zero need to ever remember addresses, or dealing with them directly. Give your devices proper names, and your router’s DNS will handle resolution automatically.
There is no point in your network having sequential addresses, so you don’t need DHCP; routers advertise configuration, clients know where to look for it.
IPv6 is amazing, if you let it handle connectivity without trying to micromanage it.
There is no point in your network having sequential addresses, so you don’t need DHCP; routers advertise configuration, clients know where to look for it.
IPv6 is amazing, if you let it handle connectivity without trying to micromanage it.
I think this is the big hangup. Wanting to micromanage each and every address. Instead of letting it just manage itself. Reminds me on some level of the pet vs cattle of containers and servers. Mental switch is needed. And many are resistant towards this.
One thing I've noticed is if people have spent a long time learning something they are incredibly reluctant to switch to something that no longer requires that knowledge. It's like driving an automatic car when you've already learnt to drive manual. I see this pattern everywhere and people are definitely reluctant to give up their hard-earned v4 knowledge.
Remembering IP addresses... How quaint!
Remembering IP addresses... How quaint!
Sounds like me. My concern,
if one just forgets everything, how does one know if their router, firewall, etc are too permissive? Security is still my responsibility.
And one still needs to pay attention for ipv4, so what is the benefit? A simultaneous half-vigilant, half-careless stance is not workable.
And one still needs to pay attention for ipv4, so what is the benefit? A simultaneous half-vigilant, half-careless stance is not workable.
What do you mean by "give your devices proper names"?
probably hostnames. So you can easily connect to them via mDNS <hostname>.local
Does Android do mDNS?
Just plain old hostnames really.
Hostnames are either in a static hosts file, which you need to distribute to your machines somehow (probably using older names or raw addresses, which you do not know, because need the names in the first place), or a DNS, and for most people the DNS is under ISP's control.
Even if you have your own DNS server out there somewhere, you still need to allow a bit of DNS hijacking from your ISP in order to receive that verification SMS and enter the code into the ISP's log-in page.
DNS is a great thing, but just too much of a pain to configure.
Even if you have your own DNS server out there somewhere, you still need to allow a bit of DNS hijacking from your ISP in order to receive that verification SMS and enter the code into the ISP's log-in page.
DNS is a great thing, but just too much of a pain to configure.
Any bog-Standard home router will resolve hostnames on your LAN, and that’s everything you require in most cases. No ISP involvement at all.
Not every bog standard home router can do ndp proxying.
mDNS handles this too and is zero-configuration.
Does your Android phone do mDNS?
Yes? At least on GrapheneOS (Android 16 QPR2) it works
You forgot 127.0.0.0/8 for loopback, 100.64.0.0/10 for CG-NAT, and 203.0.113.0/24 and 0.0.0.0/8
Why do you need to remember that when you can look it up?
Important part is knowing there are special networks.
Important part is knowing there are special networks.
> IPv6 has SO many special networks. Network. Public. Multicast. Link local.
IPv4 has those exact same ones: link-local (169.254/16), multicast (224/4), public, private (RFC 1918).
* https://en.wikipedia.org/wiki/Reserved_IP_addresses
IPv6 is (IMHO) simpler: 2001::/32 and anything else (either link-local (fe80), multicast (ff00), and ULA (fc)). So either it starts with a "2" or an "f".
IPv4 has those exact same ones: link-local (169.254/16), multicast (224/4), public, private (RFC 1918).
* https://en.wikipedia.org/wiki/Reserved_IP_addresses
IPv6 is (IMHO) simpler: 2001::/32 and anything else (either link-local (fe80), multicast (ff00), and ULA (fc)). So either it starts with a "2" or an "f".
but not on the same computer.
and the application does not have to figure out which one it has to use.
Yes on the same computer. Pretty much every multicast-capable host has a unicast address and has multicast groups that they join when they get an IP address. [0] Edge routers almost always have -at minimum- a global address and a "site-local" address. Any host that has multiple active interfaces can have multiple "categories" of addresses assigned to it.
You might also be unaware of the fact that network interfaces can usually be assigned multiple IPv4 addresses, just like they can be assigned multiple IPv6 addresses.
> ...the application does not have to figure out which one it has to use.
You might be surprised to learn that that's the job of the routing table on the system. Applications can influence the choices made by the system by binding to a specific source address, but the default behavior used by nearly everything is to let the system handle all that for you.
[0] You appear to be unaware that multicast addresses aren't assigned to a host. I suspect you're unaware that IPv6 removed the special-case "broadcast" address. It's now treated as what it actually is; the "all hosts" multicast address.
You might also be unaware of the fact that network interfaces can usually be assigned multiple IPv4 addresses, just like they can be assigned multiple IPv6 addresses.
> ...the application does not have to figure out which one it has to use.
You might be surprised to learn that that's the job of the routing table on the system. Applications can influence the choices made by the system by binding to a specific source address, but the default behavior used by nearly everything is to let the system handle all that for you.
[0] You appear to be unaware that multicast addresses aren't assigned to a host. I suspect you're unaware that IPv6 removed the special-case "broadcast" address. It's now treated as what it actually is; the "all hosts" multicast address.
Thank You. You summarise it really well. Kind of surprised this is top comment given HN ( in terms comments )tends to be very pro IPV6.
It's time for IPv5, I know its been taken so may be IPv7.
It's time for IPv5, I know its been taken so may be IPv7.
exactly.
ipv6 just gives you two configurations to maintain, two firewalls to write rules for and cross-leaks that are hard to understand.
I make my internal network ipv4 only, I have a lovable static config, one firewall to maintain. I also use vlans to separate into "can get out", "can only get out through a whitelist proxy", and "can't get out ever". and I am very happy.
I just don't understand how people can just plug every device they own into a promiscuous ipv4 and ipv6 router and contribute to profiling, television snooping, vacuum cleaner house mapping, data leaks, botnets and more...
ipv6 just gives you two configurations to maintain, two firewalls to write rules for and cross-leaks that are hard to understand.
I make my internal network ipv4 only, I have a lovable static config, one firewall to maintain. I also use vlans to separate into "can get out", "can only get out through a whitelist proxy", and "can't get out ever". and I am very happy.
I just don't understand how people can just plug every device they own into a promiscuous ipv4 and ipv6 router and contribute to profiling, television snooping, vacuum cleaner house mapping, data leaks, botnets and more...
I do the opposite. IPv6-only in my LAN and Kubernetes Cluster and NAT46/NAT64 for external ipv4-only egress/ingress. Makes it much easier than both dualstack or IPv4 alone.
> - I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.
10/8 is great until two organizations with 10.0.0.0/24 in their OSPF or IS-IS topologies are brought together via a merger/acquisition. Then you can end up with NAT with-in an organization itself. (Internal split-horizon DNS here we come.)
10/8 is great until two organizations with 10.0.0.0/24 in their OSPF or IS-IS topologies are brought together via a merger/acquisition. Then you can end up with NAT with-in an organization itself. (Internal split-horizon DNS here we come.)
> Maybe I've been irreparably corrupted by being behind NAT for too long
Bangs head against desk
NAT per se does not prevent an outside host from connecting to a host on your local network.
Bangs head against desk
NAT per se does not prevent an outside host from connecting to a host on your local network.
> NAT per se does not prevent an outside host from connecting to a host on your local network.
Yep, and a firewall per se does not prevent an outside host from connecting to a host on your local network. You can bang your head all day long, the side effect of NAT is to only allow incoming traffic that refers to an established connection that was initiated from the local network. How is this different from a firewall that does
Allow established, related
Allow outbound
Deny inbound
Yep, and a firewall per se does not prevent an outside host from connecting to a host on your local network. You can bang your head all day long, the side effect of NAT is to only allow incoming traffic that refers to an established connection that was initiated from the local network. How is this different from a firewall that does
Allow established, related
Allow outbound
Deny inbound
No, the side effect of NAT is that outbound connections made from your network look like they come from the router's WAN IP. It doesn't filter incoming traffic.
If it did then you might have a point, but since it doesn't it's very different from a firewall that's configured to do that.
If it did then you might have a point, but since it doesn't it's very different from a firewall that's configured to do that.
> No, the side effect of NAT is that outbound connections made from your network look like they come from the router's WAN IP.
That's the primary function of NAT, not a side effect.
> It doesn't filter incoming traffic.
Of course it does, it drops any incoming traffic for which it cannot find a corresponding connection. How is this not a filter?
I know that internally these two are vastly different. The reality is that NAT is used as protection for millions of home networks.
That's the primary function of NAT, not a side effect.
> It doesn't filter incoming traffic.
Of course it does, it drops any incoming traffic for which it cannot find a corresponding connection. How is this not a filter?
I know that internally these two are vastly different. The reality is that NAT is used as protection for millions of home networks.
It really doesn't, it's just that in 99% of SO/HO setups it's the firewall that's also doing the NAT. NAT by itself just mangles packets.
And again, yes, by the original definition of NAT in RFC1631, you are technically correct, which as we all know is the best kind of correctness and will move things forward. However, here in the real world, practically all NAT implementations are stateful and ignore (effectively: drop) incoming packets for which no corresponding connection can be found, meaning they do "NAT filtering" as "defined" (it's not really defined there) by RFC4787. When we say "this box here is doing NAT" everyone expects this behavior. To call this "NAT and firewall" is pointless semantics, and even the people writing RFCs agree here, which is quite something. You will see that RFC4787 says "This section describes various filtering behaviors observed in NATs", and they also say that NATs provide "firewall behaviors" without calling it "a firewall".
> ignore (effectively: drop)
Well, no. They do ignore them, but that's not effectively a drop. It's an ignore. It just means that they don't edit the packet. Whether it gets dropped or not depends completely on the routing and firewalling parts of the router.
People do generally expect a NATing router to firewall inbound connections, but it's important to realize that you won't get that behavior from NAT. You must have a firewall, which is a separate thing.
Well, no. They do ignore them, but that's not effectively a drop. It's an ignore. It just means that they don't edit the packet. Whether it gets dropped or not depends completely on the routing and firewalling parts of the router.
People do generally expect a NATing router to firewall inbound connections, but it's important to realize that you won't get that behavior from NAT. You must have a firewall, which is a separate thing.
I guess technically you are right, in that NAT doesn't prevent connections, it enables connections. But in the situation where you would have a NAT, behind a residential router, an outside host cannot connect to an arbitrary host on my internal network.
On a publicly routed PC, I can call `listen` and an outside host can connect to me.
On a PC behind a NAT - if I don't set up port forwarding - I can call `listen` and nobody from outside can connect to me.
So one could say, going from publicy routed to behind a NAT means that only allowed incoming connections are possible. Or am I missing something and you can really, from the outside, open a connection to a PC on a residential network which is behind a simple NAT (TCP server listening on that PC)?
On a publicly routed PC, I can call `listen` and an outside host can connect to me.
On a PC behind a NAT - if I don't set up port forwarding - I can call `listen` and nobody from outside can connect to me.
So one could say, going from publicy routed to behind a NAT means that only allowed incoming connections are possible. Or am I missing something and you can really, from the outside, open a connection to a PC on a residential network which is behind a simple NAT (TCP server listening on that PC)?
Yeah, you really can do that.
The only caveat is that if you're using RFC1918, it greatly limits who can connect -- only your ISP, or another customer connected to the same shared VLAN your router is, or anyone that can physically attach to that network (or anybody in a position to order, blackmail or social engineer those three groups or their employees) can do it, because they're the only people that can set a route to your router for RFC1918 destinations.
Other than that, the connection will just head right on through your router. NAT's whole thing is to change the source address of your outbound connections. Inbound ones (when they don't match port forward rules) are ignored by it, which means they get routed by the router in exactly the same way they would if the router wasn't doing NAT.
At best you could argue that RFC1918 blocks connections, which would be somewhat closer to true, but... well, it doesn't. If you actually want to stop all connections from outside your network, you've always had to do it with a firewall on the router.
And of course, I said "if". You can NAT on public IP space. On residential connections you're unlikely to have public IP space on v4, but that's just a consequence of v4 being exhausted.
The only caveat is that if you're using RFC1918, it greatly limits who can connect -- only your ISP, or another customer connected to the same shared VLAN your router is, or anyone that can physically attach to that network (or anybody in a position to order, blackmail or social engineer those three groups or their employees) can do it, because they're the only people that can set a route to your router for RFC1918 destinations.
Other than that, the connection will just head right on through your router. NAT's whole thing is to change the source address of your outbound connections. Inbound ones (when they don't match port forward rules) are ignored by it, which means they get routed by the router in exactly the same way they would if the router wasn't doing NAT.
At best you could argue that RFC1918 blocks connections, which would be somewhat closer to true, but... well, it doesn't. If you actually want to stop all connections from outside your network, you've always had to do it with a firewall on the router.
And of course, I said "if". You can NAT on public IP space. On residential connections you're unlikely to have public IP space on v4, but that's just a consequence of v4 being exhausted.
There have been incredibly clever attacks based on tricking intervening routers into routing the traffic to the target gateway, but more prosaicly my next hop ISP is itself a threat I worry about.
Every single time. But that actually gives a simple answer for why IPv6 is still not commonly used. People can’t wrap their heads around the (simple) fact that NAT is orthogonal to firewalls - and IPv6 has more difficult concepts to offer.
If you'd bothered to read the Original Post, you'd know that the author already answered that.
If you'd bothered to understand the context of my comment you wouldn't have left your comment and we wouldn't have had this obnoxious discussion.
IPv6 also makes it unfeasible to scan the whole address space, unlike IPv4 which is regularly scanned.
ASN addresses are public information.
An ASN with a /32 allocation (the smallest for ISPs) is four billion /64s. It takes dozens of yottabytes of traffic to exhaustively scan one single /64. The entire v4 space takes 0.00000001 yottabytes, or about 110 GB/port in more understandable units.
There's a ton of things you can do to cut down on the scan space for v6, but it's still far huger than v4 can be.
There's a ton of things you can do to cut down on the scan space for v6, but it's still far huger than v4 can be.
Will be amazed if the parent comment stays at #1
I share some of the same thoughts
IPv6 should be optional, not mandatory
I disable IPv6 whenever and wherever I can
Gateway is always IPv4 only
No "smartphone" gets direct connection to the internet
IPv6 can be useful. For example, cjdns
I like having the option to use it, but it should not be mandatory
I share some of the same thoughts
IPv6 should be optional, not mandatory
I disable IPv6 whenever and wherever I can
Gateway is always IPv4 only
No "smartphone" gets direct connection to the internet
IPv6 can be useful. For example, cjdns
I like having the option to use it, but it should not be mandatory
>I don't use IPv6 because it solves a problem that I don't have
At least here in the U.S., my observation has been it's usually a bit faster and has more efficient routes than IPv4. I assume part of that is using newer equipment and architecture than practical for IPv4 and ability to have more granular routes.
I regularly see 1-2ms improvement to first hop outside my ISP network (10ms vs 12ms)
Remembering addresses is a solved problem with DNS.
At least here in the U.S., my observation has been it's usually a bit faster and has more efficient routes than IPv4. I assume part of that is using newer equipment and architecture than practical for IPv4 and ability to have more granular routes.
I regularly see 1-2ms improvement to first hop outside my ISP network (10ms vs 12ms)
Remembering addresses is a solved problem with DNS.
Practically every single device or program that is connected in that ipv4 network will have a built in tunnel into the garden, with nat traversal being standard practice for everything. Your fridge, car, door lock, light fixture, all the applications on the phone, everything can and likely is a whole into the garden where someone can get full access. There are quite a few companies who has lost millions because they assumed that the garden was safe from threats within.
Other points aside, I didn’t think ISPs were meant to issue space as small as a 64.
> cue 500 replies of people telling you to eat your vegetables and wear the IPv6 hair shirt
Gee thanks, network experts, for solving a problem I don't have and making me pay for it!
Gee thanks, network experts, for solving a problem I don't have and making me pay for it!
> It's hard to remember IPv6 addresses.
Never understood why they decided to include letters instead of keeping it numeric.
Hell, going from 199.120.121.122 to 199.120.121.122.123 will have expanded IPv4 by 254 times. It took us, what? 40 years to exhaust Ipv4... Just increasing it by 254 alone is insane large amount.
Belgium used this solution for their number plates They used to have a 6 letters/digit mix. Like abc-001 type of number plate. It started to run out, so they simply created a expansion, so new number plates started with 1-abc-001 in 2010, ... and in 2021 did 2-abc-def ( they did not run out of 1, they seem to simply use the first number to indicate the decade more and more). At that rate, Belgium will run out of numbers in they year 11990 ...
Ipv4 is easy to work with, easy to remember, write down, read ... Ipv6 is always a struggle. And yea, the idea that every device may need its own IP from your provider, is just insane.
I have so much more issues configuring things with IPv6, vs just basic IPv4+NATS. Its simply, its easy...
And maybe some people do not have this issue, but our provider gives DYNAMIC IPv6, so the pre-fix keeps altering! What makes configuring things on a NAS even more hell.
O and that :: range modifier is so fun. And the whole pre-fix and post-fix structure...
I hate it. Its complex for my little brain as i do not work daily with it, and whenever i need to deal with Ipv6, i need to relearn the quirks of it every time because of issues like the whole pre-fix/post-fix, dynamic pre-fix etc. Where as IPv4 ... so easy.
Never understood why they decided to include letters instead of keeping it numeric.
Hell, going from 199.120.121.122 to 199.120.121.122.123 will have expanded IPv4 by 254 times. It took us, what? 40 years to exhaust Ipv4... Just increasing it by 254 alone is insane large amount.
Belgium used this solution for their number plates They used to have a 6 letters/digit mix. Like abc-001 type of number plate. It started to run out, so they simply created a expansion, so new number plates started with 1-abc-001 in 2010, ... and in 2021 did 2-abc-def ( they did not run out of 1, they seem to simply use the first number to indicate the decade more and more). At that rate, Belgium will run out of numbers in they year 11990 ...
Ipv4 is easy to work with, easy to remember, write down, read ... Ipv6 is always a struggle. And yea, the idea that every device may need its own IP from your provider, is just insane.
I have so much more issues configuring things with IPv6, vs just basic IPv4+NATS. Its simply, its easy...
And maybe some people do not have this issue, but our provider gives DYNAMIC IPv6, so the pre-fix keeps altering! What makes configuring things on a NAS even more hell.
O and that :: range modifier is so fun. And the whole pre-fix and post-fix structure...
I hate it. Its complex for my little brain as i do not work daily with it, and whenever i need to deal with Ipv6, i need to relearn the quirks of it every time because of issues like the whole pre-fix/post-fix, dynamic pre-fix etc. Where as IPv4 ... so easy.
> Hell, going from 199.120.121.122 to 199.120.121.122.123 will have expanded IPv4 by 254 times. It took us, what? 40 years to exhaust Ipv4... Just increasing it by 254 alone is insane large amount.
In it's original design, SIPP, the design that was chosen for IPng had 'only' 64-bits, but it was decided that it would be impossible do another transition, and going to 128 would be better future-proofing:
* https://datatracker.ietf.org/doc/html/rfc1752#section-9
So 199.120.121.122 could have grown to 199.120.121.122.152.183.166.197, which I do not think would have made a practical difference to those who complain about "hard to remember" addresses.
And it took 40 years to exhaust IPv4 because NAT was invented (RFC 1631), and now we're stuck with that kludge and have to have all sorts of workaround for it (ICE/TURN/STUN). IMHO it has also has contributed to the centralization of the Internet because doing P2P is just a pain in the ass.
In it's original design, SIPP, the design that was chosen for IPng had 'only' 64-bits, but it was decided that it would be impossible do another transition, and going to 128 would be better future-proofing:
* https://datatracker.ietf.org/doc/html/rfc1752#section-9
So 199.120.121.122 could have grown to 199.120.121.122.152.183.166.197, which I do not think would have made a practical difference to those who complain about "hard to remember" addresses.
And it took 40 years to exhaust IPv4 because NAT was invented (RFC 1631), and now we're stuck with that kludge and have to have all sorts of workaround for it (ICE/TURN/STUN). IMHO it has also has contributed to the centralization of the Internet because doing P2P is just a pain in the ass.
I think that hex digits are inherently hard to remember also because they are unpronounceable.
The letters are hex digits, and make it more compact, regular. That’s the good part.
But I agree, using a reserved byte to select internet, say 0 for original, next two hundred for each region, with the rest for planets/moons/nearby stars, would have been easier to understand.
But I agree, using a reserved byte to select internet, say 0 for original, next two hundred for each region, with the rest for planets/moons/nearby stars, would have been easier to understand.
> That’s the good part.
Disagree. We are trained on numbers from kindergarten. It's used everywhere (e.g. see a number, store it in short-term memory and input it into calculator). Hex digits are completely different and we don't have developer neural paths for that. They are also unpronounceable.
Disagree. We are trained on numbers from kindergarten. It's used everywhere (e.g. see a number, store it in short-term memory and input it into calculator). Hex digits are completely different and we don't have developer neural paths for that. They are also unpronounceable.
I have developed neural paths for them. 00 is black, 80, grey, FF white. They can always be two padded digits instead of one to three, therefore more regular and compact. Letters are pronounced just fine.
For example, I'd prefer c0a8.0001 to 192.168.0.1/16 notation. The limitation is that the netmask delimiter can only split by nibble.
For example, I'd prefer c0a8.0001 to 192.168.0.1/16 notation. The limitation is that the netmask delimiter can only split by nibble.
> - I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.
Remember, mate, with a /64 you can host your own ISP. You can finally have real Internet access! (Oh, wait -- it's not actually your /64 and your local ISP[s] wouldn't route it to you if it were, so you really can't.)
> - Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.
Oh, come on. Just look around. Almost everyone here agrees: NAT isn't a security function. Furthermore: NAT is literally the devil and has been for all of the decades you've been using it. Just think of all the stuff it breaks! Like FTP! (Remember how broken FTP was with NAT back in 1995? Or, *shudder*, h.323?)
Besides, with a /64, you can even have every computer on your network changing addresses for every IP connection! Doesn't that kind of obscurity sound nice? (Except... No, that doesn't sound nice at all. That just sounds bizarre and weird -- like dancing about architecture, or maybe some analogy about babies and bathwater.)
> - Stateless auto configuration. What ? No, no, I want my ducks neatly in a row, not wandering about. Again maybe my brain is rotten from years of DHCP usage but yes, I want stateful configuration and I want all devices on my network to automatically use my internal DNS server thank you very much.
Have you ever considered the concept of giving each machine two different IPv6 addresses? One for you to control, and one for your ISP to be in charge of. That'd be quite lovely, wouldn't it? (Except: Now you have two problems.)
> - It's hard to remember IPv6 addresses. The prospect of reconfiguring all my router and firewall rules looks rather painful.
Yeah, well. Uh. Have you tried looking into using ULA addresses like fe80::? (It's awesome! It's got all the hypothetical network convergence problems that an RFC 1918 10/8 has with which to bite you in the mysterious future, except it's also hexadecimal! And unlike the grossly prevalent DHCP system that your 10/8 LAN uses today, nobody can agree on how to centrally assign these addresses to devices!)
> - What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.
Look, man. Let me just move these goalposts for you. The real problem here is that people, like you, need to adopt IPv6. So adopt it already. Your router's implicitly always-on stateful firewall will just take care of it, just like it has almost certainly both incidentally and irrevocably done for your entire history of using NAT with IPv4. And the advantage to you is... you have that big, beautiful /64 to play with however you want (except: it isn't yours, so you don't), free of the chains of that ugly hack of NAT.
(See? That wasn't so hard! The goalposts are heavy, but they can still be moved easily-enough. These new chains are better than the old chains, anyway. The chains of IPv4 NAT were getting a little bit old and dusty, and learning which /64 your ISP will decide to number your LAN with this week is like opening a surprise box! Unless your ISP provides a /56 or something instead! Don't you like surprises? Hey, did I mention ULA? It's always important to mention ULA at least thrice because maybe you want at least two sets of LAN addresses for everything!
(All snark aside: ULA+DHCP+local NAT doesn't sound so bad at all. fd00::3 instead of 10.0.0.3? Gateway at fd00::1 instead of 10.0.0.1? Singular static LAN addresses if we feel like it -- without them being world-known, and regardless of which residential ISP we're using at the moment? People can get used to that. And it would at least present a familiar set of problems that would respond to a familiar set of solutions -- plus, with bonus nachos consisting of a whole dynamic /64 to play with if we ever feel like using that for some reason.
But AFAICT nobody does it that way because NAT is in and of itself some kind of evil thing even when it is under our direct control, so we're just stuffed. Thus, instead of local NAT, we get some combination of prefix bingo, global per-device identifiers or bizarro randomness, and/or overlayed logical networks with local ULA+public Internet addresses for the same friggin' doorbell.
And that shit is simply weird.
As a response to the weirdness, we get the resultant and inevitable pushback that all weird shit deserves.))
Remember, mate, with a /64 you can host your own ISP. You can finally have real Internet access! (Oh, wait -- it's not actually your /64 and your local ISP[s] wouldn't route it to you if it were, so you really can't.)
> - Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.
Oh, come on. Just look around. Almost everyone here agrees: NAT isn't a security function. Furthermore: NAT is literally the devil and has been for all of the decades you've been using it. Just think of all the stuff it breaks! Like FTP! (Remember how broken FTP was with NAT back in 1995? Or, *shudder*, h.323?)
Besides, with a /64, you can even have every computer on your network changing addresses for every IP connection! Doesn't that kind of obscurity sound nice? (Except... No, that doesn't sound nice at all. That just sounds bizarre and weird -- like dancing about architecture, or maybe some analogy about babies and bathwater.)
> - Stateless auto configuration. What ? No, no, I want my ducks neatly in a row, not wandering about. Again maybe my brain is rotten from years of DHCP usage but yes, I want stateful configuration and I want all devices on my network to automatically use my internal DNS server thank you very much.
Have you ever considered the concept of giving each machine two different IPv6 addresses? One for you to control, and one for your ISP to be in charge of. That'd be quite lovely, wouldn't it? (Except: Now you have two problems.)
> - It's hard to remember IPv6 addresses. The prospect of reconfiguring all my router and firewall rules looks rather painful.
Yeah, well. Uh. Have you tried looking into using ULA addresses like fe80::? (It's awesome! It's got all the hypothetical network convergence problems that an RFC 1918 10/8 has with which to bite you in the mysterious future, except it's also hexadecimal! And unlike the grossly prevalent DHCP system that your 10/8 LAN uses today, nobody can agree on how to centrally assign these addresses to devices!)
> - What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.
Look, man. Let me just move these goalposts for you. The real problem here is that people, like you, need to adopt IPv6. So adopt it already. Your router's implicitly always-on stateful firewall will just take care of it, just like it has almost certainly both incidentally and irrevocably done for your entire history of using NAT with IPv4. And the advantage to you is... you have that big, beautiful /64 to play with however you want (except: it isn't yours, so you don't), free of the chains of that ugly hack of NAT.
(See? That wasn't so hard! The goalposts are heavy, but they can still be moved easily-enough. These new chains are better than the old chains, anyway. The chains of IPv4 NAT were getting a little bit old and dusty, and learning which /64 your ISP will decide to number your LAN with this week is like opening a surprise box! Unless your ISP provides a /56 or something instead! Don't you like surprises? Hey, did I mention ULA? It's always important to mention ULA at least thrice because maybe you want at least two sets of LAN addresses for everything!
(All snark aside: ULA+DHCP+local NAT doesn't sound so bad at all. fd00::3 instead of 10.0.0.3? Gateway at fd00::1 instead of 10.0.0.1? Singular static LAN addresses if we feel like it -- without them being world-known, and regardless of which residential ISP we're using at the moment? People can get used to that. And it would at least present a familiar set of problems that would respond to a familiar set of solutions -- plus, with bonus nachos consisting of a whole dynamic /64 to play with if we ever feel like using that for some reason.
But AFAICT nobody does it that way because NAT is in and of itself some kind of evil thing even when it is under our direct control, so we're just stuffed. Thus, instead of local NAT, we get some combination of prefix bingo, global per-device identifiers or bizarro randomness, and/or overlayed logical networks with local ULA+public Internet addresses for the same friggin' doorbell.
And that shit is simply weird.
As a response to the weirdness, we get the resultant and inevitable pushback that all weird shit deserves.))
Half your complaints don't make sense, but most importantly if you think NAT isn't a problem and is under your control you must have never experienced the growing plague of CGNAT.
If the NAT function is running on a box that I can walk over and kick, then it is absolutely under my control. :)
CGNAT is a different discussion entirely. Neither the presence nor absence of upstream CGNAT changes my thoughts on locally-administrated NAT for my own LAN in IPv6 land.
CGNAT is a different discussion entirely. Neither the presence nor absence of upstream CGNAT changes my thoughts on locally-administrated NAT for my own LAN in IPv6 land.
When people complain about NAT they're mostly worried about NAT they don't control. CGNAT, or trying to deliver something that works on normal consumer computers without an expert user.
That's one perspective.
From my own perspective: I've been hearing people complain about local one-to-many NAT for a very long time, starting 30 or so years ago when fairly-regular people started introducing internet connections to their small networks.
These days, I hear about IPv6 being awesome mostly because it can used to eliminate the need for one-to-many NAT at the local border.
And that sounds great, in concept, except: This elimination introduces new issues that people didn't experience in their previous world of local NAT.
---
CGNAT is its own thing that was broadly introduced relatively recently. It can be similar in operation, but is generally very dissimilar in terms of scale and our ability to control its operation as end-users.
And people know it's different. We even use a different term to disambiguate it from other, more-local, types of NAT that are popularly implemented at the border between their LAN and the Internet: We call one of these things "NAT," and the other of these things "CGNAT".
---
And to be very clear: If I've ever meant to write about CGNAT, then I'd have done so -- and it would be obvious.
I'm very reluctant to defend a position that I have not presented, as entertaining such strawman arguments brings me to feel the opposite of satisfaction.
I'm richly disinterested in such discourse.
From my own perspective: I've been hearing people complain about local one-to-many NAT for a very long time, starting 30 or so years ago when fairly-regular people started introducing internet connections to their small networks.
These days, I hear about IPv6 being awesome mostly because it can used to eliminate the need for one-to-many NAT at the local border.
And that sounds great, in concept, except: This elimination introduces new issues that people didn't experience in their previous world of local NAT.
---
CGNAT is its own thing that was broadly introduced relatively recently. It can be similar in operation, but is generally very dissimilar in terms of scale and our ability to control its operation as end-users.
And people know it's different. We even use a different term to disambiguate it from other, more-local, types of NAT that are popularly implemented at the border between their LAN and the Internet: We call one of these things "NAT," and the other of these things "CGNAT".
---
And to be very clear: If I've ever meant to write about CGNAT, then I'd have done so -- and it would be obvious.
I'm very reluctant to defend a position that I have not presented, as entertaining such strawman arguments brings me to feel the opposite of satisfaction.
I'm richly disinterested in such discourse.
Well I didn't misinterpret on purpose. It's not obvious in the other direction because there are many types of NAT and that is one of them. And yes lots of people do call it "NAT".
And it means you left a very important argument in favor of IPv6 unmentioned.
> This elimination introduces new issues that people didn't experience in their previous world of local NAT.
I didn't see you list any downsides of removing NAT in your earlier post, just mock the upsides. But maybe I misinterpreted part of the sarcasm.
And it means you left a very important argument in favor of IPv6 unmentioned.
> This elimination introduces new issues that people didn't experience in their previous world of local NAT.
I didn't see you list any downsides of removing NAT in your earlier post, just mock the upsides. But maybe I misinterpreted part of the sarcasm.
[deleted]
> In short, so far, ignorance is bliss.
This isn't ignorance. This is an example of a little knowledge is a dangerous thing.
Ignorance is the internet just works the way it's meant to work for everyone. That's only practically possible with IPv6 these days. Your limited use case and privileged circumstances (ie. you even get a publicly routable v4 address) do not mean anything for someone who just wants things to work.
This isn't ignorance. This is an example of a little knowledge is a dangerous thing.
Ignorance is the internet just works the way it's meant to work for everyone. That's only practically possible with IPv6 these days. Your limited use case and privileged circumstances (ie. you even get a publicly routable v4 address) do not mean anything for someone who just wants things to work.
It's hard to adopt something that schools don't teach. I know someone who graduated from UCI with a CompSci degree with a specialization in networking, just before the COVID19 pandemic began. He recalled that the networking courses he took did not cover IPv6 at all, except to describe the address format (i.e. 128 bits, written as hexadecimal, colon-separated). Everything he learned about IPv6, he had to learn on his own or on the job. A standard that has been published for over two decades, heavily used for over a decade, and critical in the worldwide growth of the Internet, was treated as an afterthought by one of the premier universities in the US.
Obvious disclaimer: This is a sample size of 1, and an anecdote is not data, yada yada. I'm not involved in academia, and have no insight into the adoption of IPv6 in CompSci networking curricula on a broader level.
Obvious disclaimer: This is a sample size of 1, and an anecdote is not data, yada yada. I'm not involved in academia, and have no insight into the adoption of IPv6 in CompSci networking curricula on a broader level.
Meanwhile, I was taught and practiced IPv6 in 2003-5 in engineering school (France).
As of 2024, IPv6 deployment in France was >97% mobile and >98% residential due to not being required for obtaining a 5G radio license (and then v6 simply carried downward to being available on 4G) + every ISP that provides FTTH also providing v6.
https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arc...
Over here IPv6 JustWorks to the point of absolute boredom.
As of 2024, IPv6 deployment in France was >97% mobile and >98% residential due to not being required for obtaining a 5G radio license (and then v6 simply carried downward to being available on 4G) + every ISP that provides FTTH also providing v6.
https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arc...
Over here IPv6 JustWorks to the point of absolute boredom.
I was taught IPv6 in the mid 2000s too, in Italy.
But penetration there is just about 15% or so :/
But penetration there is just about 15% or so :/
Is it commonly used within small/medium/large businesses?
German situation is mostly/rarely/never. Small businesses have their DSL line where their cheapo router will announce an IPv6 prefix which almost all ISPs over here provide. Medium to large businesses usually have some braindead security policies that include switching off all IPv6 functionality in devices.
Don’t get me started on security policies of large German (non-tech adjacent) companies - so many of them are still stuck in the 90s
Are they still faxing?
I work for an insurtech (!), and something like 90% of our communications with mortgage companies is via fax. I kid you not.
Is there actual ink being printed onto paper or is fax just used as email with extra steps?
On our end, it's all electronic - we never print anything out. So yeah, on our side, "email with extra steps". But I have no idea how the mortgage companies handle it on their end.
Ink on paper, where I work. There have been court decisions that have seen Fax as "remote copying". And said that those remote copies only had any legal value if there was an actual paper original. Thus the workflow always has to involve paper that is then archived as paper in a folder...
I once had to print a form and fax to a company with a signature and the instructions said specifically that "signing with a computer and sending digitally is not allowed".
I just signed with macOS Preview, applied some random noise filter and used a one-off online fax service. ¯\_(ツ)_/¯
I just signed with macOS Preview, applied some random noise filter and used a one-off online fax service. ¯\_(ツ)_/¯
> Medium to large businesses usually have some braindead security policies
what's the argument behind that? are they scared they might configure their firewall bad and have no NAT to safe them from accidentally making all devices public?
what's the argument behind that? are they scared they might configure their firewall bad and have no NAT to safe them from accidentally making all devices public?
It comes from the same place as "passwords expire every 30 days".
People don't understand something and just apply the most annoying rule possible.
The craziest one I saw in Germany was "cookies are allowed, localStorage is not", that was for our app. CTO overrode the CISO on the spot and called him an idiot for making rules he doesn't understand. Interesting day.
People don't understand something and just apply the most annoying rule possible.
The craziest one I saw in Germany was "cookies are allowed, localStorage is not", that was for our app. CTO overrode the CISO on the spot and called him an idiot for making rules he doesn't understand. Interesting day.
Usually there is no official justification given, just a list (in excel...) of security requirements that have to be ticked off. One of them is "Disable IPv6".
I've heard some ex-post justifications, make of them what you will: Existing infrastructure like firewalls, VPNs and routers might not be able to handle IPv6 properly. Address distribution in IPv6 is unpredictable. No inhouse knowledge of IPv6. Everything has an address in IPv6, so the whole internet can access it. No NAT in IPv6, so it is insecure. IPv6 makes things slow.
I've heard some ex-post justifications, make of them what you will: Existing infrastructure like firewalls, VPNs and routers might not be able to handle IPv6 properly. Address distribution in IPv6 is unpredictable. No inhouse knowledge of IPv6. Everything has an address in IPv6, so the whole internet can access it. No NAT in IPv6, so it is insecure. IPv6 makes things slow.
Tbh it’s is a huge PITA with little practical benefit. IPv6 is the Perl 6 of networking.
Many of the big benefits are things that don’t deliver anything that folks are lacking. You also need to understand how you fit in the overall universe more.
Many of the big benefits are things that don’t deliver anything that folks are lacking. You also need to understand how you fit in the overall universe more.
An example for a small environment: I've got the whole homelab on unique ipv6 range. Whatever VPN connection happens to another network, I'll never have range collisions or need any fancy rewriting. Also the DNS will point at a specific address on my network, never at a random 192.168.x.x in a network I happen to be connected to.
You’re not wrong, but I have been running complicated multi-site VPNs with a small homelab multi-subnet / VLAN setup for 25 years and still have yet to have a collision.
My home network is dual-stack these days, but because my IPv6 prefix is dynamically delegated by my ISP, I actually use site-private IPv6 addresses for all my internal servers and infrastructure.
The thing is though, I don’t even need IPv6. Comcast Business broke my delegation for six+ months and I literally didn’t even notice.
IPv6 tried to do way too much. The second system syndrome was strong. It’s no wonder folks are annoyed at the complexity, and as long as IPv4 continues to works for them, they aren’t particularly pressed to adopt it.
My home network is dual-stack these days, but because my IPv6 prefix is dynamically delegated by my ISP, I actually use site-private IPv6 addresses for all my internal servers and infrastructure.
The thing is though, I don’t even need IPv6. Comcast Business broke my delegation for six+ months and I literally didn’t even notice.
IPv6 tried to do way too much. The second system syndrome was strong. It’s no wonder folks are annoyed at the complexity, and as long as IPv4 continues to works for them, they aren’t particularly pressed to adopt it.
> You’re not wrong, but I have been running complicated multi-site VPNs with a small homelab multi-subnet / VLAN setup for 25 years and still have yet to have a collision.
And I've been in corporate IT networks with mergers/acquisitions where both organizations involved had 10.0.0.0/24. Ever have NAT inside a company? Fun stuff. (Thrown in some internal-only split-horizon DNS too.)
Then there's the fact that in the COVID period we had IPs for VPN clients (172.*) in the same range as what some developers used for their Docker stuff. Hilarity.
And I've been in corporate IT networks with mergers/acquisitions where both organizations involved had 10.0.0.0/24. Ever have NAT inside a company? Fun stuff. (Thrown in some internal-only split-horizon DNS too.)
Then there's the fact that in the COVID period we had IPs for VPN clients (172.*) in the same range as what some developers used for their Docker stuff. Hilarity.
Only one has to change, the smaller one presumably. Do it on the weekend, done. Planned ahead, easier than crowdstrike.
Even supposedly prosumer gear sucks at ipv6. The ubiquiti situation was awful about a year ago. I got a dynamic prefix and wanted to setup ULA. Maybe I was dumb, but I couldn't find any way to do it.
Heck, I couldnt even see which prefix I was handled, nor could I see any ipv6 address anywhere in the gui. This was with a self hosted up to date controller though. YMMV.
Heck, I couldnt even see which prefix I was handled, nor could I see any ipv6 address anywhere in the gui. This was with a self hosted up to date controller though. YMMV.
Ubiquiti software was uniquely awful at IPv6 for a very, very long time. It's one of the reasons I abandoned it for OpenWRT and Mikrotik.
> never at a random 192.168.x.x in a network I happen to be connected to.
That’s a pretty good benefit, I hadn’t considered that!
That’s a pretty good benefit, I hadn’t considered that!
Eh, I've been thus far unimpressed.
Part of it being that a lot of ISP's don't have static prefixes, they do get rotated pretty often and have no guarantee of CIDR size that you're going to get. By default my ISP will only give a single /64. You have to go out of your way to request more subnets and there's no guarantee that the ISP will honor that request.
It's really problematic to try and base a non trivial network setup, when you have no guarantee of how many subnets you can run. Today I've got 256. Tomorrow it might be 16. Or 2. Maybe just 1 again. ISP's can be weird when they smell monetization dollars in the water.
So I have to run a ULA in parallel to the publicly accessible networks specifically for internal routing, and then use a DNS server to try and correct it. Which works great! ...except when you run into this little niche operating system called Android. Which by default doesn't obey a network provided DNS server if you've got privacy DNS enabled. So if I've got guests over and I want them on a network in my place to access some sort of internal resource, then I've got to walk them through disabling privacy DNS.
Either that or I need to go out and buy a domain... for my internal network...and then get a TLS certification for my private internal domain.
I get how IPv6 can be great. But a lot of the advantages are also overhead I don't want to deal with.
Short hand is a good example; I've lost count at the number of times I've typo'd short hand addresses because my eyes skip over a colon. At this point I've gotten into the habit of just writing out the whole address, leading 0's included because the time saved from not making a mistake reading the address often faster overall then making mistakes with shorthand.
Part of it being that a lot of ISP's don't have static prefixes, they do get rotated pretty often and have no guarantee of CIDR size that you're going to get. By default my ISP will only give a single /64. You have to go out of your way to request more subnets and there's no guarantee that the ISP will honor that request.
It's really problematic to try and base a non trivial network setup, when you have no guarantee of how many subnets you can run. Today I've got 256. Tomorrow it might be 16. Or 2. Maybe just 1 again. ISP's can be weird when they smell monetization dollars in the water.
So I have to run a ULA in parallel to the publicly accessible networks specifically for internal routing, and then use a DNS server to try and correct it. Which works great! ...except when you run into this little niche operating system called Android. Which by default doesn't obey a network provided DNS server if you've got privacy DNS enabled. So if I've got guests over and I want them on a network in my place to access some sort of internal resource, then I've got to walk them through disabling privacy DNS.
Either that or I need to go out and buy a domain... for my internal network...and then get a TLS certification for my private internal domain.
I get how IPv6 can be great. But a lot of the advantages are also overhead I don't want to deal with.
Short hand is a good example; I've lost count at the number of times I've typo'd short hand addresses because my eyes skip over a colon. At this point I've gotten into the habit of just writing out the whole address, leading 0's included because the time saved from not making a mistake reading the address often faster overall then making mistakes with shorthand.
> So I have to run a ULA in parallel to the publicly accessible networks specifically for internal routing, and then use a DNS server to try and correct it. Which works great! ...except when you run into this little niche operating system called Android. Which by default doesn't obey a network provided DNS server if you've got privacy DNS enabled. So if I've got guests over and I want them on a network in my place to access some sort of internal resource, then I've got to walk them through disabling privacy DNS.
This also sounds like it would be a problem for v4? I'm not clear on how this is a v6 problem. If I'm picturing it correctly, it's a difference of handing the guests a local v4 address vs disabling privacy DNS and handing them a DNS name. I'd think the latter would be easier
Using a public domain for TLS certs for private networking is pretty standard in /r/selfhosted and /r/homelab at least.
Fair point on ISPs handing out /64 prefixes, but this is the first I've heard of them varying the prefix length once you know what you've got. I don't doubt it though
This also sounds like it would be a problem for v4? I'm not clear on how this is a v6 problem. If I'm picturing it correctly, it's a difference of handing the guests a local v4 address vs disabling privacy DNS and handing them a DNS name. I'd think the latter would be easier
Using a public domain for TLS certs for private networking is pretty standard in /r/selfhosted and /r/homelab at least.
Fair point on ISPs handing out /64 prefixes, but this is the first I've heard of them varying the prefix length once you know what you've got. I don't doubt it though
> Either that or I need to go out and buy a domain... for my internal network...and then get a TLS certification for my private internal domain.
TBF, if you are on HN that should be extremely simple for you. I use a subdomain of my primary email domain I own, and use LetsEncrypt to issue TLS certs on my internal network. Well beyond the means of my mom and sister, but probably pretty easy for most people here.
TBF, if you are on HN that should be extremely simple for you. I use a subdomain of my primary email domain I own, and use LetsEncrypt to issue TLS certs on my internal network. Well beyond the means of my mom and sister, but probably pretty easy for most people here.
What about the benefit of there being enough addresses?
That particular benefit has no value if you still need to support v4.
It's almost a self-inflicted tragedy of the commons or reverse network-effect.
Adopting IPv6 doesn't alleviate the pain of IPv4 exhaustion if you still need to support dual-stack.
It's almost a self-inflicted tragedy of the commons or reverse network-effect.
Adopting IPv6 doesn't alleviate the pain of IPv4 exhaustion if you still need to support dual-stack.
It still helps. I have a 1U in a colo which gives me a /64 for ipv6 and ~5 addresses for ipv4. I just set up a dual stack kubernetes cluster on 6 virtual machines. When I want to ssh into one of the machines, my options are either:
Also being able to generate unique ULA subnets is super nice.
1. Use IPv6 which works and goes directly to the virtual machine because each virtual machine grabs its own address from one of my 18446744073709551616 addresses.
2. Use IPv4 and either have to do a jumphost or do port forwarding, giving each virtual machine its own port which forwards to port 22 on the virtual machine.
3. Use a VPN.
Also being able to generate unique ULA subnets is super nice.
Really using port 22 is very ill advised anyway because you will get constant nuisance brute force attacks (accomplishing nothing because you're using keys or certificates I hope) but still eating up cycles for the crypto handshake.
By that same logic, using IPv4 is ill-advised because I could easily give the ssh endpoints their own IPv6 addresses, avoiding the need to hide behind non-standard ports. Scanning through 18446744073709551616 addresses is going to be a lot slower than scanning through 65536 ports.
You don't put your server IP in your DNS? You type the IPv6 address every time?
A lot of servers expose something public so they can be found. Otherwise what's the point of being publicly accessible?
A lot of servers expose something public so they can be found. Otherwise what's the point of being publicly accessible?
You can't just list out all the DNS names. The three ways that names get discovered are:
1. You listen on IPv4 and someone probes all the IPv4 space and your server announces "Hi, I am web123.example.com" or similar in its responsible
2. You have HTTPS on the server and the HTTPS address ends up in the certificate transparency logs.
3. You have a public service on that server and announce the address somewhere.
But when you have billions of IP addresses, why does SSH need to listen on the same address as HTTPS or anything you're running publicly? It's also infeasible to probe the entirety of IPv6 space the way you can probe all of IPv4, even though we're only assigning addresses in 3/65535 of it right now.
1. You listen on IPv4 and someone probes all the IPv4 space and your server announces "Hi, I am web123.example.com" or similar in its responsible
2. You have HTTPS on the server and the HTTPS address ends up in the certificate transparency logs.
3. You have a public service on that server and announce the address somewhere.
But when you have billions of IP addresses, why does SSH need to listen on the same address as HTTPS or anything you're running publicly? It's also infeasible to probe the entirety of IPv6 space the way you can probe all of IPv4, even though we're only assigning addresses in 3/65535 of it right now.
I've had SSH open on a static v6 that isn't even SLAAC or temporary, it's not my/58::1 but not far off and in DNS, and I have not in 8 years seen a single scan or connection attempt over IPv6 (other than myself). This is not to say there is no risk, but it really is a night and day difference.
Really? I get somewhere in the region of none to barely any, depending on the server.
I mean, yes, you'll get a constant stream of them on IPv4, but why would you run a server on v4 unless you absolutely needed to? The address space is so small you can scan every IP in 5 minutes per port, and if you have my v4 address you can enumerate every single server I'm running just by scanning 65k ports.
Meanwhile, on v6, even the latter of those takes a thousand years. How would people even find the server?
I mean, yes, you'll get a constant stream of them on IPv4, but why would you run a server on v4 unless you absolutely needed to? The address space is so small you can scan every IP in 5 minutes per port, and if you have my v4 address you can enumerate every single server I'm running just by scanning 65k ports.
Meanwhile, on v6, even the latter of those takes a thousand years. How would people even find the server?
If you are an ISP running dual stack ipv4 with NAT plus ipv6, the more connections happen via ipv6 and the more traffic happens via ipv6, the better, because it doesn't have to go through the NAT infrastructure which is more expensive, and cost scales with traffic (each packet needs its header to be modified) and number of parallel open connections (each public v4 address gives you only 65k port numbers, plus this mapping needs to be stored in RAM and databases).
NAT accelerated hardware exists almost everywhere now. But yes NAT is a pita overall. CGNAT is even more of a problem.
I was mostly thinking about CGNAT instead of NAT around your home network.
There is a talk by Dmitriy Melnik at RIPE 91 about the costs for ISPs to not adopt ipv6 vs to adopt ipv6 (relevant stuff starts at 9:55).
https://ripe91.ripe.net/programme/meeting-plan/sessions/37/8...
There is a talk by Dmitriy Melnik at RIPE 91 about the costs for ISPs to not adopt ipv6 vs to adopt ipv6 (relevant stuff starts at 9:55).
https://ripe91.ripe.net/programme/meeting-plan/sessions/37/8...
Not really, this is only true for mobile devices.
7621 devices include hardware NAT. And anything Qualcomm in the recent past does. Most home WiFi 5 and above routers can do hardware NAT just fine. Hardware NAT allows for using cheap and old cpus for CPE. ISP hardware is a different story. Some decent routers that can do that which don’t cost a lot.
https://www.reddit.com/r/openwrt/comments/1lopamn/current_hi...
https://www.reddit.com/r/openwrt/comments/1lopamn/current_hi...
> Not really, this is only true for mobile devices.
Tell that to my fixed line provider, with their CGNAT ... And its just about every provider in Germany pulling that crap. O, and dynamic IPv6 pre-fix also, because can't have you run any servers!
Yes, plenty of ways to bypass it but when you have ISP's still stuck in 1990's attitude, with dynamic IPv4/IPv6, limited upload (1/3 to 1/5 of your download), etc ...
Tell that to my fixed line provider, with their CGNAT ... And its just about every provider in Germany pulling that crap. O, and dynamic IPv6 pre-fix also, because can't have you run any servers!
Yes, plenty of ways to bypass it but when you have ISP's still stuck in 1990's attitude, with dynamic IPv4/IPv6, limited upload (1/3 to 1/5 of your download), etc ...
> Adopting IPv6 doesn't alleviate the pain of IPv4 exhaustion if you still need to support dual-stack.
Sure it does: the more server-side stuff has IPv6 the fewer IPv4 addresses you need.
If you have money (or were around early in the IPv4 land grab) you have plenty of IPv4 addresses so can give each customer one to for NATing. But if you don't have money to spend (many community-based ISPs) you have to start sharing addresses (16:1 to 64:1 is common in MAP-T deployments). You also have to spend CapEx on CG-NAT hardware to handle traffic loads.
Some of the highest bandwidth loads on the Internet are for video, and Youtube/Google, Netflix, and MetaBook all support IPv6: that's a lot of load that can skip the CG-NAT if the client is given a IPv6 address.
If you can go from 1:1 to 16:1 (or higher) because so few things use IPv4 that means every ISPs can reduce their legacy addressing needs.
Sure it does: the more server-side stuff has IPv6 the fewer IPv4 addresses you need.
If you have money (or were around early in the IPv4 land grab) you have plenty of IPv4 addresses so can give each customer one to for NATing. But if you don't have money to spend (many community-based ISPs) you have to start sharing addresses (16:1 to 64:1 is common in MAP-T deployments). You also have to spend CapEx on CG-NAT hardware to handle traffic loads.
Some of the highest bandwidth loads on the Internet are for video, and Youtube/Google, Netflix, and MetaBook all support IPv6: that's a lot of load that can skip the CG-NAT if the client is given a IPv6 address.
If you can go from 1:1 to 16:1 (or higher) because so few things use IPv4 that means every ISPs can reduce their legacy addressing needs.
On company/university wifi networks, v6 cuts your v4 DHCP pool address usage by something like 70%, without hurting connectivity to v4 hosts.
You can run a V6 first network with a tiny bit of v4 sprinkled in on the edge where it's needed. The tech to do this is mature and well understood.
The widespread deployment of NAT and VPNs has counter acted the market forces that were assumed to make IPv6 appealing.
> The widespread deployment of NAT and VPNs has counter acted the market forces that were assumed to make IPv6 appealing.
Tell that to everyone who is behind CG-NAT and has issues with (e.g.) video games. Or all the (small(er)) ISPs that have to layout CapEx for translation boxes.
Tell that to everyone who is behind CG-NAT and has issues with (e.g.) video games. Or all the (small(er)) ISPs that have to layout CapEx for translation boxes.
Honestly the games issue might be out of day. Game devs have access to great services to punch through NAT at this point.
Tech finds a way…
Tech finds a way…
Which has led to every game needing a central server running, forcing centralization where p2p used to work great. Also how Skype was able to scale on a budget, something now blocked, forcing you to raise money for more ideas than before. Running a matrix(?) node should be as simple as clicking install and it's just there, next time you're with your friends, nfc tap or whatever and your servers talk to each other directly forever going forward. But nope, there always is a gatekeeper now and they need money and that poisons everything.
I don’t think VOIP was a major factor in game centralization. The big one was selling cosmetics (easily unlock able server-side in community servers), and to some extent being able to police voice chat more. Major game publishers didn’t want to be in the news about the game with the most slurs or child grooming or what not.
Central servers are useful for more than just NAT hole-punching. They’re also great as a centralized database of records and statistics as well as a host for anti-cheating services and community standards enforcement.
Peer to Peer games with no central authority would be so rife with cheating that you’d only ever want to play with friends, not strangers. That sucks!
Peer to Peer games with no central authority would be so rife with cheating that you’d only ever want to play with friends, not strangers. That sucks!
> Peer to Peer games with no central authority would be so rife with cheating that you’d only ever want to play with friends, not strangers. That sucks!
Back in the the day RtCW had a server anyone could run and you could give out the address:
* https://en.wikipedia.org/wiki/Return_to_Castle_Wolfenstein
There was a server that a ISP / cable company in the southern US ran that I participate in and it was a great community with many regulars.
P2P can be awesome with the right peers.
Back in the the day RtCW had a server anyone could run and you could give out the address:
* https://en.wikipedia.org/wiki/Return_to_Castle_Wolfenstein
There was a server that a ISP / cable company in the southern US ran that I participate in and it was a great community with many regulars.
P2P can be awesome with the right peers.
If you can run your own server then that's still a central server. That still lets a community of people work with a central authority. It's just a different authority from the game's publisher.
In that sense, Mastodon is a centralized service because it's on someone's computer. That's not really what people mean by central. They mean we're increasingly reliant on game companies for networking infrastructure.
Is that all IPV4s fault? I don't think so. But it complicates things
Is that all IPV4s fault? I don't think so. But it complicates things
I think you're muddling things up more than they need to be. A peer-to-peer game is one in which players connect directly to each other but neither is the host and there is no dedicated server. Game state is maintained separately on each player's computer and kept in sync by the netcode. Since there is no single source of truth for the game-state, so players are free to cheat by modifying the game's code to lie on their behalf. There is also the side issue of bugs in the game code causing the game-states to become irreparably desynchronized.
All of these issues are solved by having a central server for both players to connect to. Whether that server is owned by the game's publisher or by an open-source community is irrelevant from a technology standpoint. However, the prevalence of IPv4 networks and stateful NAT firewalls is relevant because it privileges those central servers over true peer-to-peer connections.
All of these issues are solved by having a central server for both players to connect to. Whether that server is owned by the game's publisher or by an open-source community is irrelevant from a technology standpoint. However, the prevalence of IPv4 networks and stateful NAT firewalls is relevant because it privileges those central servers over true peer-to-peer connections.
Most people can't run their own server, because they aren't on a public IP!
Cool. You decided you don't care about that, but what if I do?
Don't put words into my mouth! I never said I didn't care about peer to peer networking and peer to peer gaming. I said it sucks if your only option to avoid cheating is to play with friends.
If you only care about gaming with friends, then peer to peer is an excellent way to do that (assuming the game doesn't have any synchronization issues, which some peer to peer games do).
If you only care about gaming with friends, then peer to peer is an excellent way to do that (assuming the game doesn't have any synchronization issues, which some peer to peer games do).
So we acknowledge v4 and CG-NAT are a problem but don't want to use the already available solution because game developers took it upon themselves to DEFEAT NAT :)
That just reminded me of a peer protocol I worked on a long time ago that used other hosts to try to figure out which hosts were getting translated. Kind of like a reverse TOR. If that was detected, the better peering hosts would send them each other's local and public addresses so they could start sending UDP packets to each other, because the NAT devices wouldn't expect the TCP handshake first and so while the first few rounds didn't make it through, it caused the NAT device(s) to create the table entries for itself.
Was it Hamachi that was the old IPX-over-IP tunneling? I'm fairly sure it used similar tricks. IPX-over-IP is also done on DOSBOX, which incidentally made it possible to play Master of Orion 2 with friends in other continents.
That just reminded me of a peer protocol I worked on a long time ago that used other hosts to try to figure out which hosts were getting translated. Kind of like a reverse TOR. If that was detected, the better peering hosts would send them each other's local and public addresses so they could start sending UDP packets to each other, because the NAT devices wouldn't expect the TCP handshake first and so while the first few rounds didn't make it through, it caused the NAT device(s) to create the table entries for itself.
Was it Hamachi that was the old IPX-over-IP tunneling? I'm fairly sure it used similar tricks. IPX-over-IP is also done on DOSBOX, which incidentally made it possible to play Master of Orion 2 with friends in other continents.
> That just reminded me of a peer protocol I worked on a long time ago that used other hosts to try to figure out which hosts were getting translated. Kind of like a reverse TOR. If that was detected, the better peering hosts would send them each other's local and public addresses so they could start sending UDP packets to each other,
Sounds similar to STUN, really.
Sounds similar to STUN, really.
If that's the VOIP thing, yes, lots of people came to similar methods. That particular thing was for exchanging state, not VOIP or tunneling, so as long as participant groups overlapped it didn't really need a fixed server to be the middle which was handy for our purposes, although long network interruptions could make reconvergence take a while.
Does make me chuckle that so many people had to be working around NAT for so long and then people are like "NAT is way better than the thing that makes us not have to deal with the problem at all." Just had a bit of NAT PTSD remembering an unrelated, but livid argument between some network teams about how a tool defeating their NAT policies was malware. They had overlapping 10.x.y.z blocks, because of course they did :)
Does make me chuckle that so many people had to be working around NAT for so long and then people are like "NAT is way better than the thing that makes us not have to deal with the problem at all." Just had a bit of NAT PTSD remembering an unrelated, but livid argument between some network teams about how a tool defeating their NAT policies was malware. They had overlapping 10.x.y.z blocks, because of course they did :)
I can spin up a NAT puncher today without having to depend on anybody. Can't say the same for IPv6.
Nat hole punching works... most of the time. There are many edge cases and weird/broken networks which you just can't work around in standard ways. You get to see all kinds of broken setups if you work at VoIP providers. That's why everyone will use a central proxy server as the last resource - you'll mostly notice it only because of a higher ping.
Isn't CGnat due to IPv6 use on the mobiles? You could quit and say that's an IPv6 problem that didn't get solved in the IPv6 engineering
IPv6 is used on mobile networks since there aren't enough IPv4 addresses. Some of these mobile networks are so big there aren't even enough private IPv4 addresses for their CG-NAT private side to fit, leaving the only clean solution being NAT64/DNS64.
Why would CGNAT be deployed as a response to IPv6 on mobile? I don't understand the logic there. CGNAT is deployed due to a shortage of publicly routable IPv4 addresses. IPv6 was introduced due to having much larger publicly routable space.
Because the internet as a whole is ipv4. The mobiles are IPv6. The ipv4 internet does not care about any server running on any mobile device.
Thus, CG Nat was invented so that IPv6 could talk to IPv4 and get the information from it.
Thus, CG Nat was invented so that IPv6 could talk to IPv4 and get the information from it.
No, CGNAT (Carrier-Grade NAT - https://en.wikipedia.org/wiki/Carrier-grade_NAT) is an IPv4 only thing. https://www.rfc-editor.org/rfc/rfc6598 specifies they should use 100.64.0.0/10 for it, to avoid conflicting with the pre-existing private-use ranges. IPv6 removes the need for using CGNAT, as each home router is allocated a public IP (rather than a CGNAT IP) on its public link.
Oh so cgnat exists for ipv4 addresses to talk to IPv6 servers? Is that what you are telling me?
Because all of the www is in IPv6, and cgnat actually excuses for ipv4 cable users to use the bedrock internet servers and services?
Bullshit. Cgnat is a hack for ipv6 to talk to the ipv4 universe.
Because if there were magically enough iov4 addresses for mobiles, would cgnat exist? No, it wouldn't.
Because all of the www is in IPv6, and cgnat actually excuses for ipv4 cable users to use the bedrock internet servers and services?
Bullshit. Cgnat is a hack for ipv6 to talk to the ipv4 universe.
Because if there were magically enough iov4 addresses for mobiles, would cgnat exist? No, it wouldn't.
No, CGNAT has absolutely nothing to do with IPv6. CGNAT is nothing more than ISPs not providing a public IP to the gateway on your LAN (i.e. your router). To avoid conflicts with existing ranges, a new ranges for that purpose was allocated. There are different technologies to enable IPv4<->IPv6, none of which care about the existence of CGNAT.
No, NAT64 was invented so v6-only hosts could access v4-only resources. CGNAT was invented so v4 hosts can have a v4 address without having to purchase limited public address space.
IPv4 addresses are still expensive. NAT is a value add for a lot of cloud platforms.
IPv6 has arguably done more to counteract market forces related to IPv4 address exhaustion.
IPv6 has arguably done more to counteract market forces related to IPv4 address exhaustion.
It's my dream that one day I'll be able to run an AWS VPC that only has IPv6 for the private subnets and then I'll never have to worry about managing the address space or how many IP addresses each ALB consumes.
That is a collective problem, though, not an individual one. I have always been able to get enough v4 addresses for all my needs.
Yep, iot would be a tremendously worse security problem if everyone wasn't actually operating a household subnet without knowing it.
When your washing machine, fridge, etc all come with ipv6 5g modems is when your house becomes part of the future IT battlescape between lots of different entities that do not wish you well.
When your washing machine, fridge, etc all come with ipv6 5g modems is when your house becomes part of the future IT battlescape between lots of different entities that do not wish you well.
No, because sensibly configured routers would still block incoming traffic regardless of NAT.
If your dishwasher has a 5G antenna + modem built-in and connects to the manufacturer’s own wireless account then your router doesn’t enter the picture. The dishwasher can happily serve you ads and conduct routine surveillance all day long and the only thing you can do is cut power to the device (until they start including a battery backup for that stuff).
True, but the dishwasher should have its own firewall regardless, and assuming it'll be on IPv4 behind a firewalled NAT is by itself an implementation error.
My point is that you don't control what network the dishwasher is on, the manufacturer does. The dishwasher connects to its own cellular network so that you cannot block any of its ads or prevent it from spying on you.
I’m assuming you don’t know how iPv6 works. With SLAAC every device usually rotates the v6 address every few hours and maintains multiple of these. Each subnet for each customer is huge. With rotating MAC it’s virtually impossible to maintain a connection with an IPv6 only device by just IP address. It’s one of the features of IPv6 that such attacks are not going to be feasible.
I am truely a beginner. I am also annoyed by rotating identifiers for devices on the network since it increases the overhead to differentiate for the purpose of firewall rules. Maybe v6 has an identifier better than MAC that can be handled expeditiously for DNS and IP controls?
Why? My router won’t even let me DMZ a single ipv6 device or open all ports to a single ipv6 device. It will only let me open one port at a time.
different routers have different options, but all of them have come with a pretty strong firewall out of the box, turned on by default, for the last 10 years.
different routers have different options, but all of them have come with a pretty strong firewall out of the box, turned on by default, for the last 10 years.
There’s zero benefit to you because the carrier is NATing you for other purposes.
They get better network management.
They get better network management.
Enough addresses for what? Nobody needs or even wants all of their devices to have globally routable addresses.
> Enough addresses for what? Nobody needs or even wants all of their devices to have globally routable addresses.
They do if they have applications, such as Xbox/PS gaming applications, broken VoIP in gaming lobbies, failure of SIP client to punch through etc. And if an ISP does not have, or cannot afford, to get enough IPv4 to hand each of their customers at least one to assign to the CPE's WAN port, you're now talking about CG-NAT, which a whole other level of breakage.
They do if they have applications, such as Xbox/PS gaming applications, broken VoIP in gaming lobbies, failure of SIP client to punch through etc. And if an ISP does not have, or cannot afford, to get enough IPv4 to hand each of their customers at least one to assign to the CPE's WAN port, you're now talking about CG-NAT, which a whole other level of breakage.
Enough addresses for proper P2P connectivity, which is kinda useful for newfangled things like video chat?
We’re supposedly mere years away from superintelligence, but it’s still literally impossible to just send a file between two clients without configuring intermediate network hardware or performing some hack to get around NAT (which can still fail and then require an intermediate server) if both clients are behind CGNAT.
It’s genuinely disheartening to see so many people here not even begin to try to understand how much we’re missing by not having effortless end-to-end connectivity, in favor of expensive cloud services. This literally used to be what the “Internet” is - we’re definitionally not on one without this.
It’s genuinely disheartening to see so many people here not even begin to try to understand how much we’re missing by not having effortless end-to-end connectivity, in favor of expensive cloud services. This literally used to be what the “Internet” is - we’re definitionally not on one without this.
Everyone who says this is obviously a web developer.
That's a pretty bold claim. IMO IPv6 is not hard at all, and delivers significant benefit when dealing with anything outside your local network.
I absolutely love the things that IPv6 delivers and employ it on purpose.
The world very clearly doesn’t revolve around what HN users “love”.
I think the western world very much revolves around:
* The internet
* Linux servers
* Automation
I get your point, but it falls on deaf ears to me since most people don’t feel the benefits until some passionate nerd makes something that scratches an itch.
For a practical example: peer-to-peer sharing like Airdrop is much easier to implement in a world with ipv6.
* The internet
* Linux servers
* Automation
I get your point, but it falls on deaf ears to me since most people don’t feel the benefits until some passionate nerd makes something that scratches an itch.
For a practical example: peer-to-peer sharing like Airdrop is much easier to implement in a world with ipv6.
The world at large doesn't care what I love, correct. But my users care about whether they have to remember that they're supposed to use port bla instead of the standard port foo, which is a common scenario with v4. Not enough addresses, and / or you can't get them to the VM or container or VPN client or whatever that needs them.
IPv6 can often fix these kinds of issues.
Does the world at large care? No.
Do I care? Yes.
Do my users care? Yes, albeit indirectly.
Does my organization care? Yes, in the sense that it removes friction from what it needs the employees to do.
And that's all the justification that's needed, I'd say. The world very clearly doesn't need to revolve around what I love for IPv6 to be a good thing.
Does the world at large care? No.
Do I care? Yes.
Do my users care? Yes, albeit indirectly.
Does my organization care? Yes, in the sense that it removes friction from what it needs the employees to do.
And that's all the justification that's needed, I'd say. The world very clearly doesn't need to revolve around what I love for IPv6 to be a good thing.
This is so right.
No One believes us on hacker News. It feels very gaslighty. I have never talked to an IT engineer in person that thought IP version 6 in the data center or in the corporate network was a good idea.
No One believes us on hacker News. It feels very gaslighty. I have never talked to an IT engineer in person that thought IP version 6 in the data center or in the corporate network was a good idea.
I recently passed the CCNA again and they really spend a lot more time on IPv6 compared to 15 years ago. It inspired me to go all in this time and configured my home network with a PD allocation from my ISP. I also came up with some fun labs and even got a IPv6 sage T-shirt from Hurricane Electric.
Any recommended courses? I'm a SWE and never felt compelled for the CCNA but my intersection with networking-related problems seems to continuously increase and I would like to up my game before getting in over my head at work.
I just bought the official exam guide found Neil Anderson’s videos helpful. One thing that bugged me a bit was they spent a little too much time on their WiFi, including the obsolete Airie OS.
This doesn’t hold up. Schools can’t teach everything, especially in a field where innovation happens in the workplace, not the classroom. Should I have learned about LLMs when I was an undergraduate 20 years ago?
This is just further proof that university educations are still not job training. The sooner we disabuse ourselves of that perception the better off society will be.
Higher education is about creating a breadth of knowledge, not specific marketable skills. CompSci is a research field, not job training.
If your friend wanted to learn specific job skills a technical college would be the appropriate setting.
I realize this misperception is perpetuated by the job market but I’m still not surprised at the education provided by UCI and don’t fault them for providing it.
This is just further proof that university educations are still not job training. The sooner we disabuse ourselves of that perception the better off society will be.
Higher education is about creating a breadth of knowledge, not specific marketable skills. CompSci is a research field, not job training.
If your friend wanted to learn specific job skills a technical college would be the appropriate setting.
I realize this misperception is perpetuated by the job market but I’m still not surprised at the education provided by UCI and don’t fault them for providing it.
They taught us, they also taught ipv4 in the old "separate address per host" way instead of jumping to NAT, but I think ipv6 is inherently more complicated than ipv4 for the average use case. It's not just a thinking shift.
Separate from that, deliberate decisions were made to make it a "clean slate" without consideration for existing ipv4 hosts. Guess they were hoping the separate stacks would go away eventually, but in hindsight, no way.
Separate from that, deliberate decisions were made to make it a "clean slate" without consideration for existing ipv4 hosts. Guess they were hoping the separate stacks would go away eventually, but in hindsight, no way.
> ... but I think ipv6 is inherently more complicated than ipv4 for the average use case. It's not just a thinking shift.
IPv6 isn't all that complicated for most common use cases. Its fundamental concepts and rules are simple. It also obviates the necessity of the complicated workaround called NAT, without which IPv4 is impractical these days.
It's more like the imperial vs metric system debate. If the world hadn't seen IPv4, I believe that we'd all be using IPv6 without any complaints. The real problem is that IPv6 isn't taught well.
> Separate from that, deliberate decisions were made to make it a "clean slate" without consideration for existing ipv4 hosts. Guess they were hoping the separate stacks would go away eventually, but in hindsight, no way.
I'm not sure what to make of this. The presence of the IPv4 stack isn't what blocks the adoption of IPv6 - at least not technically. They can coexist on the same host and function concurrently without interfering with each other. It was designed to operate like that. The actual blocker is the attitude that people hold towards IPv6 - "We have IPv4 that works already. Why should we care about an alternative?". You can see that expressed on this discussion thread itself.
There is one crucial detail that the IPv6 detractors neglect - the scarcity of IPv4 addresses means that IPv4 address blocks are now heavily coveted and therefore subject to moneyed interests. That isn't very good for the health of the open internet, digital rights and equity. They're thinking about individual trees and losing sight of the whole damn forest. IPv6 isn't a solution looking for a problem. It's the solution for a problem that people simply ignore.
IPv6 isn't all that complicated for most common use cases. Its fundamental concepts and rules are simple. It also obviates the necessity of the complicated workaround called NAT, without which IPv4 is impractical these days.
It's more like the imperial vs metric system debate. If the world hadn't seen IPv4, I believe that we'd all be using IPv6 without any complaints. The real problem is that IPv6 isn't taught well.
> Separate from that, deliberate decisions were made to make it a "clean slate" without consideration for existing ipv4 hosts. Guess they were hoping the separate stacks would go away eventually, but in hindsight, no way.
I'm not sure what to make of this. The presence of the IPv4 stack isn't what blocks the adoption of IPv6 - at least not technically. They can coexist on the same host and function concurrently without interfering with each other. It was designed to operate like that. The actual blocker is the attitude that people hold towards IPv6 - "We have IPv4 that works already. Why should we care about an alternative?". You can see that expressed on this discussion thread itself.
There is one crucial detail that the IPv6 detractors neglect - the scarcity of IPv4 addresses means that IPv4 address blocks are now heavily coveted and therefore subject to moneyed interests. That isn't very good for the health of the open internet, digital rights and equity. They're thinking about individual trees and losing sight of the whole damn forest. IPv6 isn't a solution looking for a problem. It's the solution for a problem that people simply ignore.
The IPv6 spec was being modified up through 2017. It has more kinds of addresses that behave in fancier ways, with one host having multiple. The very first thing you see with ipv6 is your nice memorable ipv4 addr replaced with a long hex string with some ::s thrown in. Local DNS is commonly recommended with ipv6 for that reason, which maybe is just some misguided advice because it sounds crazy. I guess you could assign and memorize ULAs?
NAT is technically complicated if you're looking inside it, but most people aren't, and for them it's really easier to think about. You've got a public and a private, and there's a very strong default that private isn't exposed. People screw up firewall rules all the time or routers have bad defaults, but it takes more deliberate action to publicly expose a port over NAT. Plus you don't need privacy addresses that way (introduced to ipv6 in 2007). I know "NAT isn't security" but for most people, it is.
Still not even sure what the accepted default firewall behavior is in ipv6, cause some people say "ipv6 lets any device do p2p by its own choice" and then when you ask about security, "your router firewall should always default-deny anyway," so which one is it?
> The presence of the IPv4 stack isn't what blocks the adoption of IPv6
It is. Like they say, most technical problems are really people problems, especially this one.
NAT is technically complicated if you're looking inside it, but most people aren't, and for them it's really easier to think about. You've got a public and a private, and there's a very strong default that private isn't exposed. People screw up firewall rules all the time or routers have bad defaults, but it takes more deliberate action to publicly expose a port over NAT. Plus you don't need privacy addresses that way (introduced to ipv6 in 2007). I know "NAT isn't security" but for most people, it is.
Still not even sure what the accepted default firewall behavior is in ipv6, cause some people say "ipv6 lets any device do p2p by its own choice" and then when you ask about security, "your router firewall should always default-deny anyway," so which one is it?
> The presence of the IPv4 stack isn't what blocks the adoption of IPv6
It is. Like they say, most technical problems are really people problems, especially this one.
> Local DNS is commonly recommended with ipv6 for that reason, which maybe is just some misguided advice because it sounds crazy.
Many (most?) SOHO routers already run a combined DHCP and DNS server called 'dnsmasq', which supports DHCPv6. IIRC, dnsmasq automatically adds DNS records for hosts to which it gives out a lease. Android computers don't use DHCPv6, so this won't help you access them by name, but how often do you care to directly access an Android computer?
Many (most?) SOHO routers already run a combined DHCP and DNS server called 'dnsmasq', which supports DHCPv6. IIRC, dnsmasq automatically adds DNS records for hosts to which it gives out a lease. Android computers don't use DHCPv6, so this won't help you access them by name, but how often do you care to directly access an Android computer?
I wasn't under the impression that SOHO routers normally have DHCPv6 enabled by default. At least checked mine now and it doesn't.
> I wasn't under the impression that SOHO routers normally have DHCPv6 enabled by default.
The fellow I replied to indicated that running a local DNS server on one's LAN "sounds crazy".
My commentary was intended to indicate that it's very common in SOHO networks to already be running a DNS server that automatically adds hostname->address mappings of DHCP clients on that network. It also mentioned that DHCPv6 support is supported by the combined DHCP+DNS daemon used by many (most?) SOHO routers.
My commentary was not intended to indicate that DHCPv6 support is on by default on many or most SOHO routers, only that it's likely to be supported, and that -if supported- it is very, very likely to put hostname->AAAA mappings of DHCPv6 clients into its DNS server, just as it adds hostname->A mappings for DHCPv4 clients.
The fellow I replied to indicated that running a local DNS server on one's LAN "sounds crazy".
My commentary was intended to indicate that it's very common in SOHO networks to already be running a DNS server that automatically adds hostname->address mappings of DHCP clients on that network. It also mentioned that DHCPv6 support is supported by the combined DHCP+DNS daemon used by many (most?) SOHO routers.
My commentary was not intended to indicate that DHCPv6 support is on by default on many or most SOHO routers, only that it's likely to be supported, and that -if supported- it is very, very likely to put hostname->AAAA mappings of DHCPv6 clients into its DNS server, just as it adds hostname->A mappings for DHCPv4 clients.
Ah, I understand. Well having dnsmasq fully automatically run DNS isn't crazy at all if you're using DHCPv6. If you're not, it sounds unreasonable for you to need to spin up your own DNS server.
> If you're not, it sounds unreasonable for you to need to spin up your own DNS server.
If you're using a SOHO router, you're very likely to already be using dnsmasq; a DNS server. In that configuration, if you're using DHCP then you get your hostnames in DNS for free.
If you're not using DHCP and don't have a DNS server running on your network that you have figured out how to update with host IP addresses, then it's on you to select memorable static addresses. [0] This is a long-standing baseline fact of IP addressing for LANs and other private networks.
[0] Nothing prevents you from assigning addresses to your LAN machines in the fd00::/64 prefix starting from 1 (that is, fd00::1) and going up. The fd00::/8 space is for uncoordinated network-local addressing.
If you're using a SOHO router, you're very likely to already be using dnsmasq; a DNS server. In that configuration, if you're using DHCP then you get your hostnames in DNS for free.
If you're not using DHCP and don't have a DNS server running on your network that you have figured out how to update with host IP addresses, then it's on you to select memorable static addresses. [0] This is a long-standing baseline fact of IP addressing for LANs and other private networks.
[0] Nothing prevents you from assigning addresses to your LAN machines in the fd00::/64 prefix starting from 1 (that is, fd00::1) and going up. The fd00::/8 space is for uncoordinated network-local addressing.
ipv6 would have been a breaking change anyway, just take the opportunity to push through any changes that they want to make
Helsinki CS masters had ipv6 20 years ago, but nobody listened at the lectures because all of our home LANs ran ipv4
You have it backwards, education always lags industry adoption. (*Assuming it's a software engineering-focused curriculum.)
Programs will teach Docker only years after it is adopted.
Same with AWS, JavaScript, etc.
If it’s not adopted by industry, it won’t be taught about in schools.
Programs will teach Docker only years after it is adopted.
Same with AWS, JavaScript, etc.
If it’s not adopted by industry, it won’t be taught about in schools.
I got taught IPv6 in 1995. At that time they said it was super important because it would replace IPv4 within a year lolololol
I can’t think of any technology where mass adoption was driven by knowledge forcibly inserted into students’ brains by schools… if anything, adoption comes when people realize their out-of-touch curriculum is no longer relevant.
To be clear, degree programs have value, but it’s not in future-proofing students against needing to learn things after they leave school. Ideally it should prepare them and encourage them to do so.
To be clear, degree programs have value, but it’s not in future-proofing students against needing to learn things after they leave school. Ideally it should prepare them and encourage them to do so.
>> I know someone who graduated from UCI with a CompSci degree with a specialization in networking, just before the COVID19 pandemic began. He recalled that the networking courses he took did not cover IPv6 at all...
I am not doubting you, but I feel this story is too hard to believe without adding further nuances...
MIT 6.829 teaches IPv6 since 2002: https://ocw.mit.edu/courses/6-829-computer-networks-fall-200...
In Portugal and other countries, there are subjects on Computer Science before College or University, and they teach it on High School...
I am not doubting you, but I feel this story is too hard to believe without adding further nuances...
MIT 6.829 teaches IPv6 since 2002: https://ocw.mit.edu/courses/6-829-computer-networks-fall-200...
In Portugal and other countries, there are subjects on Computer Science before College or University, and they teach it on High School...
The issue is that it’s not taught with IPv6 first. Networking courses do all kinds of stuff using IPv4 to demonstrate various protocols on top (e.g. http, tcp, icmp, etc).
Then there is usually a chapter on IPv6 that just briefly covers the differences.
I.e. the exercises all tend to use IPv4 as the foundation so people don’t practice v6
Then there is usually a chapter on IPv6 that just briefly covers the differences.
I.e. the exercises all tend to use IPv4 as the foundation so people don’t practice v6
But TCP or HTTP don’t care about the underlying transport. They’re higher level protocols that are payloads to either IPv4 or IPv6. It’s irrelevant what the transport is when dissecting HTTP and very little time should be spent on it.
IPv4 is, for all intents and purposes, still the default transport. It’s also simpler than IPv6 in some regards. When teaching layer 3, it makes sense to teach both, and teach IPv4 first. Though I fully agree that they should be taught with equal emphasis. I don’t doubt there’s a good number of programs out there that don’t into sufficient detail on IPv6.
IPv4 is, for all intents and purposes, still the default transport. It’s also simpler than IPv6 in some regards. When teaching layer 3, it makes sense to teach both, and teach IPv4 first. Though I fully agree that they should be taught with equal emphasis. I don’t doubt there’s a good number of programs out there that don’t into sufficient detail on IPv6.
No, this is wrong and it’s why academia is failing.
IP addresses show up everywhere when you are working with both TCP and HTTP. Sockaddr is all over sockets programming, IPs show up in HTTP headers, etc.
They absolutely care about the underlying protocol because the underlying protocol is how you address the other end.
IP addresses show up everywhere when you are working with both TCP and HTTP. Sockaddr is all over sockets programming, IPs show up in HTTP headers, etc.
They absolutely care about the underlying protocol because the underlying protocol is how you address the other end.
Well it makes sense, no one uses ipv6 anyhow. Most I know are waiting for ipv8.
I've been of the opinion this is one of those "the art advances one funeral at a time." A lot of people are married to IPv4 and its arcane warts and really, really do not want to deal with IPv6 even though most of the core concepts are almost exactly the same thing, except better. I can't imagine anyone who dealt with V4 multicast ever wanting to go back, and I bet they've memory-holed parts of V4 that simply can't be used anymore and so have been turned off for decades(RIP to RIP). Has anyone seen the automated address assignment in V4 ever work? The usual hint it even exists is that if you see one of those addresses it means something is messed up in your Windows host or the DHCP server died.
People complain about dual stacks and all that but with a modicum of planning it is minimal extra effort. Anything made in the last decade has V4/V6 support and unless you're messing with low level network code, it's often difficult to even know which way you're being routed. Network devices pretty much all support using groups of names or addresses and not hard coded dotted-quad config statements now, and have for a while. And that was good practice on V4 networks too.
Part of it is probably that remembering various V4 magic is easy enough to do but feels complicated enough to be an accomplishment. In V6, there is no point in doing most of that because the protocol has so much more automation of addressing schemes. But if you like those addressing schemes, V6 can do them even better. You can do all sorts of crazy address translation on either the network or host id portion, like giving an internal network a ULA that is magically translated to a public network prefix without any stateful tracking unless that is desirable.
I feel there is some analog to DNS in that regard, people who have gotten used to DNS don't give a damn about host IP addresses but some people seem to really like the idea of a fixed address statement. People also seem to be stuck on the idea that NAT creates some kind of security when that's really the stateful tracking that is required for many-to-few translations (thus making firewalls a common place to implement it), not the translation itself. Similar to certificates/pki versus shared keys, yes, one is more upfront effort but that's because it's solving the problem of the Sisyphean task that is the other.
edit: This all reminded me that we lived with dual stacks before, in the IP and IPX days, or DECnet, and that GE Ether-whatever, and those had less in common. IPX mostly died with Netware but it had a number of advantages that wouldn't be bolted on top of IP for years, some of which are present in IPv6. I rather liked IPX and had history gone differently that it used 48-bit addressing would be causing us to discuss whether or not EUID was a mistake or not :)
People complain about dual stacks and all that but with a modicum of planning it is minimal extra effort. Anything made in the last decade has V4/V6 support and unless you're messing with low level network code, it's often difficult to even know which way you're being routed. Network devices pretty much all support using groups of names or addresses and not hard coded dotted-quad config statements now, and have for a while. And that was good practice on V4 networks too.
Part of it is probably that remembering various V4 magic is easy enough to do but feels complicated enough to be an accomplishment. In V6, there is no point in doing most of that because the protocol has so much more automation of addressing schemes. But if you like those addressing schemes, V6 can do them even better. You can do all sorts of crazy address translation on either the network or host id portion, like giving an internal network a ULA that is magically translated to a public network prefix without any stateful tracking unless that is desirable.
I feel there is some analog to DNS in that regard, people who have gotten used to DNS don't give a damn about host IP addresses but some people seem to really like the idea of a fixed address statement. People also seem to be stuck on the idea that NAT creates some kind of security when that's really the stateful tracking that is required for many-to-few translations (thus making firewalls a common place to implement it), not the translation itself. Similar to certificates/pki versus shared keys, yes, one is more upfront effort but that's because it's solving the problem of the Sisyphean task that is the other.
edit: This all reminded me that we lived with dual stacks before, in the IP and IPX days, or DECnet, and that GE Ether-whatever, and those had less in common. IPX mostly died with Netware but it had a number of advantages that wouldn't be bolted on top of IP for years, some of which are present in IPv6. I rather liked IPX and had history gone differently that it used 48-bit addressing would be causing us to discuss whether or not EUID was a mistake or not :)
Ipv6 was a protocol engineered in isolation from the social / political environment it had to be adopted in.
A successor to ipv4 wasnt a technical issue. duh, use longer addresses. The problem was social.
It's a miracle it was used at all
What's annoying about ipv6 discussions is that the ipv6 people are incredibly condescending when the problems of its adoption were engineered by them.
A successor to ipv4 wasnt a technical issue. duh, use longer addresses. The problem was social.
It's a miracle it was used at all
What's annoying about ipv6 discussions is that the ipv6 people are incredibly condescending when the problems of its adoption were engineered by them.
Exactly. IPv6 was developed in the ivory towers where it was still assumed that everyone wanted to be a full participant of the internet.
But the social/political environment was that everyone just wants to be a passive consumer, paying monthly fees to centralized hosts to spoon-feed them content through an algorithm. For that, everyone being stuck behind IPv4 CG-NAT and not being able to host anything without being gatekept by the cloud providers is actually a feature and not a bug.
But the social/political environment was that everyone just wants to be a passive consumer, paying monthly fees to centralized hosts to spoon-feed them content through an algorithm. For that, everyone being stuck behind IPv4 CG-NAT and not being able to host anything without being gatekept by the cloud providers is actually a feature and not a bug.
We've seen only the world where everything has been adopted to IPv4. p2p technologies strive even under it, but they could really shine with the ability to connect directly between devices. Imagine BitTorrent on steroids, where you don't have peers with assigned IPv4 and seedboxes and everybody else. Torrents are generally faster than usual channels to download things, but with ipv6 it would be far faster than now.
Cloudless cameras streaming to your phone without Chinese vendor clouds, e2e encrypted emails running on your phone without snooping by marketing people and three-leter agencies, content distribution network without vendor lock-ins. The possibilities are impressive if we have a way to do it without TURN servers that cost money and create a technical and legal bottlenecks.
We can't say nobody wants that world because we've never tried it in the first place. I definitely would like to see that.
Cloudless cameras streaming to your phone without Chinese vendor clouds, e2e encrypted emails running on your phone without snooping by marketing people and three-leter agencies, content distribution network without vendor lock-ins. The possibilities are impressive if we have a way to do it without TURN servers that cost money and create a technical and legal bottlenecks.
We can't say nobody wants that world because we've never tried it in the first place. I definitely would like to see that.
Don't you think everyone should have the option to be a full participant? Being locked behind cloud providers and multiple layers of NAT with IPv4 means that can never happen, even if consumers want it to.
I was lucky enough to experience the 90's internet where static IP addresses were common. I had a /24 (legacy "class C" block) routed to my home, and still do.
I was lucky enough to experience the 90's internet where static IP addresses were common. I had a /24 (legacy "class C" block) routed to my home, and still do.
> Exactly. IPv6 was developed in the ivory towers where it was still assumed that everyone wanted to be a full participant of the internet.
IPv6 was developed in the open on mailing lists that anyone could subscribe to:
Just like all current IETF discussions are in the open and free for all to participate. If you don't like the direction things are going in participate: as Gandhi did (not) say, “Be the change you want to see in the world.”
One of the co-authors on that RFC worked at BBN: you know, the folks that actually built the first the routers (IMPs) that created the ARPA/Internet in the first place. I would hazard to guess they have know something about network operations.
* https://www.goodreads.com/book/show/281818.Where_Wizards_Sta...
> But the social/political environment was that everyone just wants to be a passive consumer, paying monthly fees to centralized hosts to spoon-feed them content through an algorithm.
Disagree, especially with the hoops that users and developers have to jump through to deal with (CG-)NAT:
> [Residential customers] don't care about engineering, but they sure do create support tickets about broken P2P applications, such as Xbox/PS gaming applications, broken VoIP in gaming lobbies, failure of SIP client to punch through etc. All these problems don't exist on native routed (and static) IPv6.
* https://blog.ipspace.net/2025/03/response-end-to-end-connect...
IPv6 was developed in the open on mailing lists that anyone could subscribe to:
The criteria presented here were culled from several sources,
including "IP Version 7" [1], "IESG Deliberations on Routing and
Addressing" [2], "Towards the Future Internet Architecture" [3], the
IPng Requirements BOF held at the Washington D.C. IETF Meeting in
December of 1992, the IPng Working Group meeting at the Seattle IETF
meeting in March 1994, the discussions held on the Big-Internet
mailing list (big-internet-at-munnari.oz.au, send requests to join to
big-internet-request-at-munnari.oz.au), discussions with the IPng Area
Directors and Directorate, and the mailing lists devoted to the
individual IPng efforts.
Just like all current IETF discussions are in the open and free for all to participate. If you don't like the direction things are going in participate: as Gandhi did (not) say, “Be the change you want to see in the world.”
One of the co-authors on that RFC worked at BBN: you know, the folks that actually built the first the routers (IMPs) that created the ARPA/Internet in the first place. I would hazard to guess they have know something about network operations.
* https://www.goodreads.com/book/show/281818.Where_Wizards_Sta...
> But the social/political environment was that everyone just wants to be a passive consumer, paying monthly fees to centralized hosts to spoon-feed them content through an algorithm.
Disagree, especially with the hoops that users and developers have to jump through to deal with (CG-)NAT:
> [Residential customers] don't care about engineering, but they sure do create support tickets about broken P2P applications, such as Xbox/PS gaming applications, broken VoIP in gaming lobbies, failure of SIP client to punch through etc. All these problems don't exist on native routed (and static) IPv6.
* https://blog.ipspace.net/2025/03/response-end-to-end-connect...
Well, with such a description of the 'vices' of IPv6 vs the 'virtues' of IPv4 count me as one who considers himself in full support of the ivory towered greybeards who decided the 'net was meant to be more than a C&C network for sheeple. Once I got a /56 delegated by my IAP - which coincided with me digging down the last 60 metres of fibre conduit after which our farm finally got a real network connection instead of the wires-on-poles best-effort ADSL connection we had before that - I implemented IPv6 in nearly all - but not all - services. Not all of them, no, because IPv6 can make life harder than it needs to be. Internally some services still run IPv4 only and will probably remain doing so but everything which is meant to be reachable from outside can be reached through both IPv4 as well as IPv6. I recently started adding SIP services which might be the first instance of something which I'll end up going IPv6-only due to the problems caused by NATting the SIP control channels as well as the RTP media channels, something reminiscent of how FTP could make life difficult for those on the other side of firewalls and NAT routers. With IPv6 I do not need NAT so as long as the SIP clients support it I should be OK. Now that last bit, client support... yes, that might be a problem sometimes.
The problem of IPv6 adoption in the US was largely engineered by major ISPs not caring while hardware manufacturers take their cues from major ISPs.
IPv4 link local addressing is awesome for direct PC to PC connectivity with no hassle
So like plugging two laptops together? Honestly curious, I can't recall ever seeing anyone using it and the situations that it seems like it should be good for, like initial configuration of stuff coming out of the box, instead come with instructions for setting specific IPv4 addressing or use DHCP. Possibly a lack of some LLNMR equivalent at the time.
link-local is mandatory for ipv6 to work. Technically everybody you have ever seen is using it. It is unlikely that you know somebody without a cellphone. And as far as I know, all cellphone networks are ipv6 first.
https://en.wikipedia.org/wiki/Link-local_address#IPv6
https://en.wikipedia.org/wiki/Link-local_address#IPv6
Did you reply to the wrong comment? I know link-local works in IPV6, we were discussing IPv4.
80% of my career knowledge as a devops engineer, systems administrator, and IT engineer has been on the job training. That's just how it works.
The real reason is IT people hate ipv6. They want NAT. They don't want all the security holes and extra complexity. I don't want having to work with a network stack that is poorly supported by some switches and routers.
The real reason is IT people hate ipv6. They want NAT. They don't want all the security holes and extra complexity. I don't want having to work with a network stack that is poorly supported by some switches and routers.
> Everything he learned about IPv6, he had to learn on his own or on the job.
Replace "IPv6" in that sentence with any practical knowledge or skill and it's probably true for my entire master's degree....
Replace "IPv6" in that sentence with any practical knowledge or skill and it's probably true for my entire master's degree....
Weird, I graduated from RIT in 2009 with a B.S. in Applied Networking and Systems Administration and we covered IPV6 quite a bit
I certainly can validate this anecdote, I also had to learn almost everything about IPv6 myself.
IPv6 was superceded by NAT a long time ago. It will die a slw and quiet death which is why it is now being ignored by training facilities and experts worldwide.
Oh no, somebody should warn all the ISPs deploying IPv6-native connections with v4 reachable over some fallback technology (464XLAT, DS-Lite, NAT64 etc.) to their hundreds of millions if not billions of customers!
--Sent from my IPv6
--Sent from my IPv6
The only ISPs issuing IPv6 only connections are mobile device operators and Telcos. THey are a small subset of ISPs in the world and IPv6 only connections will never gain any traction outside of that world.
I agree it will not die so I retract that statement, but it will never fully replace IPv4 in standard wired internet connections.
I agree it will not die so I retract that statement, but it will never fully replace IPv4 in standard wired internet connections.
Digital Ocean didn’t even have an ipv6 address on by default in the droplet I created last week. It’s just a switch to flip, but I’ll bet the support costs of hobbyists/enthusiasts not realizing they needed to also write firewall rules, make sure ports weren’t open for databases and things like that for ipv6.
My memory of IPv6 is getting waves of support tickets from people who took their (already questionable) practice of blocking ICMP on IPv4, blocked ICMPv6, and then got confused when IPv6 stopped working.
The legacy of the Ping of Death and redirect abuse still looms over people that may not have been born yet :)
It's a "just doesn't work" experience every time that I try it and I don't experience any value from it, it's not like there isn't anything I can connect to on IPv6 that I can't connect to on IPv4.
My ISP has finally mastered providing me with reliable albeit slow DSL. Fiber would change my life, there just isn't any point in asking for IPv6.
Also note those bloated packets are death for many modern applications like VoIP.
My ISP has finally mastered providing me with reliable albeit slow DSL. Fiber would change my life, there just isn't any point in asking for IPv6.
Also note those bloated packets are death for many modern applications like VoIP.
Exactly. Spectrum delivers good IPv6 service in my area. I tried it when I upgraded my gateway. All of my devices are assigned 4 IPv6 IPs, hostnames are replaced by auto assigned stuff from the ISP, and lots of random things don’t work.
I went from being pumped to learn more to realizing I’m going to invest a lot of time and I could not identify and tangible benefit.
I went from being pumped to learn more to realizing I’m going to invest a lot of time and I could not identify and tangible benefit.
The biggest tangible benefit is you don't need to worry about NAT port mapping any more. Every device can have a public address, and you can have multiple servers exposing services on the same port without a conflict.
(The flip side is having a network-level firewall is more important than ever.)
You also don't have to worry about running a DHCP server anymore, at least on small networks. The simplicity of SLAAC is a breath of fresh air, and removes DHCP as a single point of failure for a network.
(The flip side is having a network-level firewall is more important than ever.)
You also don't have to worry about running a DHCP server anymore, at least on small networks. The simplicity of SLAAC is a breath of fresh air, and removes DHCP as a single point of failure for a network.
So the benefit is that you dont need to worry about NAT for a couple of port forwarded services you may use (which might well even use UPnP for auto setup), but the tradeoff is you now need to think about full individual firewall protection for every device on your network?
I'll take full security by default and forward a couple of ports thankyou!
I'll take full security by default and forward a couple of ports thankyou!
Few people care about exposing a server in the first place, even fewer care about multiple servers on a single port.
> All of my devices are assigned 4 IPv6 IPs
Loopback, link local and network assigned. What's that problem? Your ipv4 hosts are can reach themselves through millions of addresses already.
> hostnames are replaced by auto assigned stuff from the ISP
Hostnames replaced? IPv6 doesn't do DNS...
> lots of random things don’t work.
Lots of random things also don't work on ipv4. :)
Loopback, link local and network assigned. What's that problem? Your ipv4 hosts are can reach themselves through millions of addresses already.
> hostnames are replaced by auto assigned stuff from the ISP
Hostnames replaced? IPv6 doesn't do DNS...
> lots of random things don’t work.
Lots of random things also don't work on ipv4. :)
You can maybe connect to everyone over IPv4, but chances are that that path is strictly worse (in terms of latency, P2P reachability, congestion et.c) than a v6 one would be.
For example, two IPv6 peers can often trivially reach each other even behind firewalls (using UDP hole punching). For NAT, having too restrictive a NAT gateway on either side can easily prevent reachability.
For example, two IPv6 peers can often trivially reach each other even behind firewalls (using UDP hole punching). For NAT, having too restrictive a NAT gateway on either side can easily prevent reachability.
I have tailscale on all my mobile/portable devices I use away from home. It punches holes so I don't have to, even makes DNS work for my tailnet in a way I've never been able to get to work the way I want the normal way.
Yes, Tailscale is great, and it does manage to traverse pretty much every firewall or NAT in my experience as well. Quite often, it even does so using IPv6 :)
> those bloated packets are death for many modern applications like VoIP.
Huh? The packet sizes aren’t that much different and VOIP is hardly a taxing application at this point anyway. VOIP needs barely over dial-up level bandwidth.
Huh? The packet sizes aren’t that much different and VOIP is hardly a taxing application at this point anyway. VOIP needs barely over dial-up level bandwidth.
It's not the bandwidth it's the latency. Because of the latency you need to pack a small amount of data in VoIP packets so the extra header size of IPv6 stings more than it would for ordinary http traffic
https://www.nojitter.com/telecommunication-technology/ipv6-i...
https://www.nojitter.com/telecommunication-technology/ipv6-i...
I have a lot of trouble believing IPv6 matters here. Your link only talks about bandwidth (an extra 8kbps) and doesn’t even mention latency.
Edit: NAT also adds measurable latency. If anything I’d think avoiding NAT might actually make IPv6 lower latency than IPv4 on average.
Edit: NAT also adds measurable latency. If anything I’d think avoiding NAT might actually make IPv6 lower latency than IPv4 on average.
Last time I looked at Digital Ocean they had completely missed the purpose of IPv6 and would only assign a droplet a /124 and even then only as a fixed address like they were worried we are going to run out of addresses.
But really what's the point of giving half an internet worth of addresses to every machine? I never understood that part of IPv6.
I think it would have been better having shorter addresses and not waste so many on every endpoint.
I think it would have been better having shorter addresses and not waste so many on every endpoint.
Because 2^128 is too big to be reasonably filled even if you give a ip address to every grain of sand. 64 bits is good enough for network routing and 64 bits for the host to auto configure an ip address is a bonus feature. The reason why 64 bits is because it large enough for no collisions with picking a ephemeral random number or and it can fit your 48 bit mac address if you want a consistent number.
With a fixed size host identifier compared to a variable size ipv4 host identifier network renumbering becomes easier. If you separate out the host part of the ip address a network operator can change ip ranges by simply replacing the top 64 bits with prefix translation and other computers can still be routed to with the unique bottom 64 bits in the new ip network.
This is what you do if you start with a clean sheet and design a protocol where you don't need to put address scarcity as the first priority.
With a fixed size host identifier compared to a variable size ipv4 host identifier network renumbering becomes easier. If you separate out the host part of the ip address a network operator can change ip ranges by simply replacing the top 64 bits with prefix translation and other computers can still be routed to with the unique bottom 64 bits in the new ip network.
This is what you do if you start with a clean sheet and design a protocol where you don't need to put address scarcity as the first priority.
Thanks for this. It's pointless to argue, but I wonder if shifting from 32 to 64 bits, instead 128, would have seen faster uptake.
Aside, isn't embedding MAC addrs in ones IP address a bad idea?
Aside, isn't embedding MAC addrs in ones IP address a bad idea?
Yeah, the current system is really weird, with many address assigning services refusing to create smaller pools. I really hope that's fixed one day. We already got an RFC saying effectively "going back to classful ranges was stupid" https://datatracker.ietf.org/doc/html/rfc6177 (for over a decade...)
Point of fact it's giving 4 billion Internets worth of addresses to every local subnet.
You will sometimes see admins complain that IPv6 demands that you allow ICMP (at least the TOOBIG messages) through the firewall because they're worried that people on the internet will start doing pingscans of their network. This is because they do not understand what 2^64 is.
You will sometimes see admins complain that IPv6 demands that you allow ICMP (at least the TOOBIG messages) through the firewall because they're worried that people on the internet will start doing pingscans of their network. This is because they do not understand what 2^64 is.
And won't that allow pingscans?
Do the math on 2^64 possible host addresses, multiply by the length of an IPv6 ICMP ECHOREQUEST, and then divide by available bandwidth to determine how long it might take you to scan a single subnet.
Hint: the ICMPv6 packet is no shorter than 48 bytes and there are 1.8446744e+19 addresses to scan.
Hint: the ICMPv6 packet is no shorter than 48 bytes and there are 1.8446744e+19 addresses to scan.
"Simple" VPS providers like DigitalOcean, etc. really need to get the hell onboard with network virtualization. It's 2026, I don't want to be dealing with individual hosts just being allocated a damned /64 either. Give me a /48, attach it to a virtual network, let me split it into /64's and attach VM's to it - if I want something other than SLACC addresses (or multiple per VM) then I can deal with manually assigning them.
To be fair, the "big" cloud providers can't seem to figure this shit out, either. It's mind boggling, I'm not saying I've gone through the headache of banging out all the configuration to get FRRouting and my RouterOS gear happily doing the EVPN-VXLAN dance; but I'm also not Amazon, Google, or Microsoft...
To be fair, the "big" cloud providers can't seem to figure this shit out, either. It's mind boggling, I'm not saying I've gone through the headache of banging out all the configuration to get FRRouting and my RouterOS gear happily doing the EVPN-VXLAN dance; but I'm also not Amazon, Google, or Microsoft...
Do you think anything other than trivial internal networking is a common requirement on DO? I’m not saying it’s not, I really don’t know— I haven’t been in the production end of things for a while and when I was, everyone was basically using AWS et. al. for non-trivial applications. They make it easy enough to set up a private ipv4 subnet to connect your internal services. Does that not satisfy you use case or are you just avoiding tooling that might be obsolete sooner than ipv6?
I use IPv6 on my authoritative DNS servers and that's basically it. To your point keeping it disabled on all my hobby crap keeps everything simple for me. If someone can not reach IPv4 then something is broken on their end.
IMO ipv6 is a perfect example of why interface designers can be valuable on technical projects. One of the genius things about ipv4 is it’s a pre-chunked number you can shout across the room or keep in your head as you run down the hall to your keyboard. IPv6 addresses simply don’t have that feature. If they had kept the 4-chunk format and made it alphanumeric, or added a chunk and made it hexadecimal, or something along those lines, I think they could have reasonably alleviated the problem of running out of addresses while not making the addresses SO unfriendly to remember.
But when designers bring things like that up, you get “it’s really not that complicated,” or “I explained this to my 200 year old grandmother over tea/my 16 month old child over the course of a diaper change/my non-technical wife that I intellectually respect less than I should/etc. and they wrote a book on it the next day,” kind of crap. Human factors engineering. Ergonomics matter in technical products.
But when designers bring things like that up, you get “it’s really not that complicated,” or “I explained this to my 200 year old grandmother over tea/my 16 month old child over the course of a diaper change/my non-technical wife that I intellectually respect less than I should/etc. and they wrote a book on it the next day,” kind of crap. Human factors engineering. Ergonomics matter in technical products.
NAT doesn't solve everything, and creates a whole new class of problems that you can just avoid by adopting IPv6 natively. And it's definitely not being ignored at larger companies.
In particular, just off the top of my head...
- T-Mobile US doesn't even assign clients an IPv4 address anymore. Their entire network is IPv6 native.
- Many cloud providers charge extra for IPv4 addresses, but give IPv6 addresses out for free.
In particular, just off the top of my head...
- T-Mobile US doesn't even assign clients an IPv4 address anymore. Their entire network is IPv6 native.
- Many cloud providers charge extra for IPv4 addresses, but give IPv6 addresses out for free.
For trivial cases NAT is easy, for complex situations it's a nightmare. I've been fighting a lonely battle against multiple-NAT VPNs as being the solution to the wrong problem for longer than I care to remember, and I'm tired boss. A few years ago we had a client site go offline because a local network guy just didn't like IPv6 and turned it off, not realizing that a huge amount of stuff was happening automatically and that's why he hadn't been needing to work on it.
This is not even funny to read, given huge networks like T-Mobile USA being IPv6-only.
Yep, mobile device space ISPs again which is what keeps being argued. IPv6 only connections will never gain full traction outside of the mobile marketplace.
They are using IPv6 as a fancy transport protocol for IPv4 NAT.
By being IPv6-only they are effectively making their users to preferentially connect over native IPv6 though.
Personal anecdote, but once you have IPv6 setup properly (meaning your devices prefer IPv6 over IPv4) 70-80% of your internet traffic will be IPv6.
The NAT64 is really just there for the holdouts.
Personal anecdote, but once you have IPv6 setup properly (meaning your devices prefer IPv6 over IPv4) 70-80% of your internet traffic will be IPv6.
The NAT64 is really just there for the holdouts.
I run dual stack at home with dns64/nat64. I average 50/50 traffic v4/v6. Web browsing gets skewed v6 but large file transfers and some streaming pushed it back to 50/50 overall. My family would revolt if I went v6 only so I'm not sure I'd say its just there for holdouts. Major annoyances include any old device and my hue bridge.
That's a bit like saying AC electricity was just a fancy way of delivering what customers really wanted, DC energy.
I'm sure that DC customers used their Edison DC equipment for decades after the grid went AC only; but in the long run the newer, flexible, lower overhead system became the default for new equipment and the compatibility cludges were abandoned.
I'm sure that DC customers used their Edison DC equipment for decades after the grid went AC only; but in the long run the newer, flexible, lower overhead system became the default for new equipment and the compatibility cludges were abandoned.
Well, yes. Except that AC came to dominance much faster than IPv6, the AC/DC war lasted less than 10 years, with the AC quickly coming to domination. Because AC provides a clear performance advantage over DC.
This is not really true of IPv6. It _still_ has tons of actual operational issues, and in the best case, it does not provide any tangible improvements over IPv4+NAT for the vast majority of users.
For example, in-flight entertainment works by assigning you an IPv4 address and allowlisting it in the gateway rules. This does not work with IPv6 because of privacy addresses and SLAAC. You might think that you just need to do stateful DHCPv6, but Android doesn't support it. Heck, even simple DHCPv6 PD automatic configuration is _still_ not a standard ( https://datatracker.ietf.org/doc/rfc9762/ )!
So to this day, some of the most visited sites like amazon.com, ebay.com, tiktok.com, slack.com or even github.com do not support IPv6. I also keep providing this example, year after year: there are no public VoIP SIP providers in the US that simply _support_ IPv6. Go on, try to find one.
This is not really true of IPv6. It _still_ has tons of actual operational issues, and in the best case, it does not provide any tangible improvements over IPv4+NAT for the vast majority of users.
For example, in-flight entertainment works by assigning you an IPv4 address and allowlisting it in the gateway rules. This does not work with IPv6 because of privacy addresses and SLAAC. You might think that you just need to do stateful DHCPv6, but Android doesn't support it. Heck, even simple DHCPv6 PD automatic configuration is _still_ not a standard ( https://datatracker.ietf.org/doc/rfc9762/ )!
So to this day, some of the most visited sites like amazon.com, ebay.com, tiktok.com, slack.com or even github.com do not support IPv6. I also keep providing this example, year after year: there are no public VoIP SIP providers in the US that simply _support_ IPv6. Go on, try to find one.
High voltage AC actually gives more overhead than the same voltage DC.
HVDC is enormously expensive even today and completely impractical for bulk transport 100 years ago. You can't look just at corona, capacitive etc. losses of HVAC, you need to factor in the entire economic equation. The total overhead of AC (cost of equipment + energy lost for the lifetime of the line) is still lower for overground transport over reasonable distances and will remain so for the foreseeable future.
I don't think they even had a way to do dc-dc voltage step-up and step-down at high power and efficiency, needed semiconductors for that to do high speed switching in buck and boost converters
No; most sites I reach from the phone seem to be reached via IPv6. E.g. hitting whatismyip.org exposes an IPv6 (though mentions an IPv4 because they're trying to discover that, too).
Some sites do not support IPv6; for those indeed there's a XLAT464 service.
It was?
Isn’t it what all the cell phones networks use these days? And most ISP’s?
They may hand the end user device a IPv4 address but don’t they actually use IPv6?
Isn’t it what all the cell phones networks use these days? And most ISP’s?
They may hand the end user device a IPv4 address but don’t they actually use IPv6?
Yes as I said in a sibling post the telcos are the only ones using it, and that is the only reason that graphs like the google client one exist. That is only because it already exists and is cheaper than using NAT when you have hundreds of millions of clients.
IPv6 only ISPs will never leave the mobile space.
IPv6 only ISPs will never leave the mobile space.
Maybe in the US. I've seen IPv6-only connections via DS-Lite in more than one other country on wired home ISPs.
“The largest ISPs are the only ones using it” is another way of describing it as ubiquitous.
I disagree. If they were the largest ISPs then adoption would already be over 50% instead of stalling below it.
I would say its more "Wireless only ISPs are the only ones using it"
I would say its more "Wireless only ISPs are the only ones using it"
> I would say its more "Wireless only ISPs are the only ones using it"
So… the largest ISPs.
Recent number show about 94% of Americans have cell phones and 92% of American households have Internet connections. In raw numbers, that’s about 300M cell phones and 111M households.
If zero fixed ISPs support IPv6, that’d still be about 75% of total Internet connections that do.
So… the largest ISPs.
Recent number show about 94% of Americans have cell phones and 92% of American households have Internet connections. In raw numbers, that’s about 300M cell phones and 111M households.
If zero fixed ISPs support IPv6, that’d still be about 75% of total Internet connections that do.
> So… the largest ISPs.
Yep, a few gatekeepers of a single device space.
Your numbers are wrong, seee the google graph everybody is pointing to:
https://www.google.com/intl/en/ipv6/statistics.html
Yep, a few gatekeepers of a single device space.
Your numbers are wrong, seee the google graph everybody is pointing to:
https://www.google.com/intl/en/ipv6/statistics.html
Name a large isp not using V6
AWS charges for ipv4 addresses but ipv6 addresses are free. ipv4 with NAT doesn't supercede ipv6, it just extends its life.
What are you even basing that on? Here are some facts:
- You have to pay money to get a static IPv4 address for cloud machines on eg AWS. Anything needing a static IPv4 will cost more and more as demand increases. NAT doesn’t exactly fix that.
- Mainstream IoT protocols have a hard dependency on IPv6 (eg Matter/Thread). Not to mention plenty of 5g deployments.
- Many modern networks quietly use IPv6 internally. I mean routing is simpler without NAT.
So it almost definitely won’t die. It’s more likely it’ll slowly and quietly continue growing behind the scenes, even if consumers are still seeing IPv4 on their home networks.
- You have to pay money to get a static IPv4 address for cloud machines on eg AWS. Anything needing a static IPv4 will cost more and more as demand increases. NAT doesn’t exactly fix that.
- Mainstream IoT protocols have a hard dependency on IPv6 (eg Matter/Thread). Not to mention plenty of 5g deployments.
- Many modern networks quietly use IPv6 internally. I mean routing is simpler without NAT.
So it almost definitely won’t die. It’s more likely it’ll slowly and quietly continue growing behind the scenes, even if consumers are still seeing IPv4 on their home networks.
IPv4 addresses have been dropping in price for a few years and are cheaper in real terms than at my point in the last 15
> IPv4 addresses have been dropping in price for a few years and are cheaper in real terms than at my point in the last 15
More IPv6 deployments may (ironically?) help reduce IPv4 prices as you can get IPv6 'for free' and have Internet connectivity (and not have to worry about exhaustion in any practical way). Doing CG-NAT could reduce the number IPv4 addresses you need to acquire.
More IPv6 deployments may (ironically?) help reduce IPv4 prices as you can get IPv6 'for free' and have Internet connectivity (and not have to worry about exhaustion in any practical way). Doing CG-NAT could reduce the number IPv4 addresses you need to acquire.
IPv4 addresses are basically free - indeed they are a profit centre. At $20 an address that’s $2 a year at most (10% ROI) where many charge 20 times that ($5/month isn’t unheard of)
Matter/Thread use private IPv6 addresses so it's just an implementation detail. Nobody is exposing light switches to the public Internet.
NAT fixes it in the sense that blocks become available when providers switch to CGNAT.
People love this graph and regularly tout it as if it explains full internet usage. Especially when they dont bother to add any explanation or comment alongside it.
This graph is mainly due to the fact that telcos use IPv6 for mobile devices, nothing more. Over time you will see that graph flatline and peter out as mobile device uage reaches critical mass.
This graph is mainly due to the fact that telcos use IPv6 for mobile devices, nothing more. Over time you will see that graph flatline and peter out as mobile device uage reaches critical mass.
In US even desktops have 45% adoption rate: https://radar.cloudflare.com/explorer?dataSet=http&groupBy=i...
afaik every single major US fixed line ISP is rolling out ipv6.
afaik every single major US fixed line ISP is rolling out ipv6.
Yep, every ISP and every device supports IPv6 and has done for ages.
Show me one where they have disabled IPv4 and only use IPv6 that is not a mobile device or Telco ISP.
Show me one where they have disabled IPv4 and only use IPv6 that is not a mobile device or Telco ISP.
It seems more the other end of the stick: the IPv4 side of the graph is mainly held up due to corporations. The consumer internet continues to switch, but corporate VPNs are going to continue to drag down the numbers until corporations get charged enough for IPv4 address space that bottom lines start to notice.
Yes good point, I agree that IPv4 addresses are going to become a commodity in the future and their value will start to increase dramatically to the point where it is only corporations which can afford to use them. IPv6 use may well start to spike again if that happens.
Every major ISP in the US, India, and most of the rest of Asia that I’ve seen is handing out and using IPv6 now too.
Hell, chances are if you got a new router (like any new client) for your ISP, you’d be on v6 too.
Hell, chances are if you got a new router (like any new client) for your ISP, you’d be on v6 too.
Yep, and even with all those countries with their billions of mobile devices IPv6 use still hasnt even reached 50%.
Pretty much all ISPs hand out both IPv6 and IPv4 addresses to their clients, this is nothing new. When they start only issueing IPv6 IPs is when it would start truly taking off, but it will never get to that point and it will never happen.
Pretty much all ISPs hand out both IPv6 and IPv4 addresses to their clients, this is nothing new. When they start only issueing IPv6 IPs is when it would start truly taking off, but it will never get to that point and it will never happen.
It feels like you are constantly moving goal posts here. Your original statement was it will die a slow and quiet death. Are you now saying that this mobile use case will start to switch back to IPv4? It may not kill IPv4, like was initially planned, but it's not going away.
Apologies maybe slow death was the wrong phrase. I did mean that, but only in the non-mobile space. Obviously mobile device networks have made good use of IPv6 and will continue to.
However In another thread it was argued that when IPv4 addresses become very expensive, that could trigger a big shift to IPv6. I agree with this statement and so IMO it is possible that IPv6 may well become ubiquitous in the future.
However In another thread it was argued that when IPv4 addresses become very expensive, that could trigger a big shift to IPv6. I agree with this statement and so IMO it is possible that IPv6 may well become ubiquitous in the future.
When usage is increasing rapidly and is literally ~ 50% of the entire planet right now, how is ANY kind of 'death' a useful descriptor?
IPv4 is the one that descriptor belongs on, eh?
IPv4 is the one that descriptor belongs on, eh?
No I dont agree at all.
Usage is in no way 'rapidly increasing', in fact the google graph everyone is touting around shows that it has taken over 10 years to not even get to 50%. It also shows it is slowing down, the curve is starting to become less steep.
When Maximum possible IPv6 usage is not even at 50% after over a decade and the usage curve is slowing, how can you possibly say that IPv4 is dying and IPv6 usage is rapidly increasing?
Usage is in no way 'rapidly increasing', in fact the google graph everyone is touting around shows that it has taken over 10 years to not even get to 50%. It also shows it is slowing down, the curve is starting to become less steep.
When Maximum possible IPv6 usage is not even at 50% after over a decade and the usage curve is slowing, how can you possibly say that IPv4 is dying and IPv6 usage is rapidly increasing?
Oh, now it’s a problem because it’s been about a decade?
So what, another decade and we should be mostly done?
What do you think is a reasonable amount of time to redo the entire world’s networking infrastructure across 200+ countries and 8 something billion people, exactly?
This is an absurd argument, you know that right?
So what, another decade and we should be mostly done?
What do you think is a reasonable amount of time to redo the entire world’s networking infrastructure across 200+ countries and 8 something billion people, exactly?
This is an absurd argument, you know that right?
> Oh, now it’s a problem because it’s been about a decade?
No, but taking over a decade to not even be half adopted does not count as rapid in my opinion.
> So what, another decade and we should be mostly done?
No, as I have said many many times, the graph is slowing.
> What do you think is a reasonable amount of time to redo the entire world’s networking infrastructure
We dont need to, thats the point. All networking equipment in the world already supports IPv6, so why isnt it at 100% usage and IPv4 is turned off already?
>This is an absurd argument, you know that right?
Who is the fool, the person saying what they think or the person continuing to participate in an argument they consider absurd?
You dont need to make everybody in the world agree with what you are saying, it is ok to have differing opinions. You know that right?
I am done now. I accept that you disagree with me and thats fine. Can you afford the same decency or will you continue to tell me I'm wrong?
No, but taking over a decade to not even be half adopted does not count as rapid in my opinion.
> So what, another decade and we should be mostly done?
No, as I have said many many times, the graph is slowing.
> What do you think is a reasonable amount of time to redo the entire world’s networking infrastructure
We dont need to, thats the point. All networking equipment in the world already supports IPv6, so why isnt it at 100% usage and IPv4 is turned off already?
>This is an absurd argument, you know that right?
Who is the fool, the person saying what they think or the person continuing to participate in an argument they consider absurd?
You dont need to make everybody in the world agree with what you are saying, it is ok to have differing opinions. You know that right?
I am done now. I accept that you disagree with me and thats fine. Can you afford the same decency or will you continue to tell me I'm wrong?
According to APNIC labs, IPv6 adoption in India is ~79% and in China it is ~53%.
Those are the only two countries that could plausibly have billions of mobile devices and they appear to have reached 50%.
India: https://stats.labs.apnic.net/ipv6/CN?c=IN&x=1&v=1&p=1&r=1&w=...
China: https://stats.labs.apnic.net/ipv6/CN?c=CN&x=1&v=1&p=1&r=1&w=...
Those are the only two countries that could plausibly have billions of mobile devices and they appear to have reached 50%.
India: https://stats.labs.apnic.net/ipv6/CN?c=IN&x=1&v=1&p=1&r=1&w=...
China: https://stats.labs.apnic.net/ipv6/CN?c=CN&x=1&v=1&p=1&r=1&w=...
Wow, billions of devices per country and they have still only reached 50%.
Damn, the jealousy (?) is palpable. You know you will have literally zero impact on adoption no matter how snarky you are, right?
Jealousy? I think you may need to expand your vocabulary a bit!
I have an opinion on something, I assume thats ok? You seem to be here trying to prove me wrong, and also commenting on my tone of reply.
Im not trying to tell you that you are wrong, only stating what I think. If you dont like my opinion, feel free to ignore it. You are not forced to comment.
I have an opinion on something, I assume thats ok? You seem to be here trying to prove me wrong, and also commenting on my tone of reply.
Im not trying to tell you that you are wrong, only stating what I think. If you dont like my opinion, feel free to ignore it. You are not forced to comment.
Looks like it’s right at 50% and rapidly increasing.
[https://www.google.com/intl/en/ipv6/statistics.html]
What exactly are you going on about? 5-10 years for the old devices to be EOL’d, and we’ll likely be at 95%.
[https://www.google.com/intl/en/ipv6/statistics.html]
What exactly are you going on about? 5-10 years for the old devices to be EOL’d, and we’ll likely be at 95%.
The trend on that graph is slowing, and when we reach criticl mass on the number of mobile devices the graph will be flat.
There is no chance we will be at 95% usage in 5 years or so.
If you like, we can make a wager?
There is no chance we will be at 95% usage in 5 years or so.
If you like, we can make a wager?
It was simply to point out that you are objectively incorrect. No commentary was necessary. My phone and home broadband both use IPv6 primarily.
If you were correct, that graph would have been over 50% ages ago.
As it is, that graph is showing how adoption is slowing and has been for the last 10 years.
Hardly anybodies physical internet connection is using IPv6 primarily worldwide, those numbers are all mobile device space.
As it is, that graph is showing how adoption is slowing and has been for the last 10 years.
Hardly anybodies physical internet connection is using IPv6 primarily worldwide, those numbers are all mobile device space.
> Over time you will see that graph flatline and peter out as mobile device uage reaches critical mass.
...what? The majority of people access the Internet from their phone, and not only since yesterday either. Are you arguing that this is temporary fad somehow?
...what? The majority of people access the Internet from their phone, and not only since yesterday either. Are you arguing that this is temporary fad somehow?
I am arguing that at some point there wont be any more people without phones, meaning it has reached critical mass and so IPv6 adoption will stall. The number of smartphones in the world will not keep on going up forever.
That would only happen if all of v6's growth is coming from mobile users, no mobile networks are growing/deployed without v6, and also no users are dropping their wired connections.
You can look at the AS breakdowns on APNIC's stats and see that ASs that serve non-mobile customers are getting v6, and that some ASs for mobile users aren't. So no, it won't stall.
Slow down perhaps, but it has to slow down at some point or it'll go above 100%.
You can look at the AS breakdowns on APNIC's stats and see that ASs that serve non-mobile customers are getting v6, and that some ASs for mobile users aren't. So no, it won't stall.
Slow down perhaps, but it has to slow down at some point or it'll go above 100%.
I don't like to admit this, but at this point honestly I think ipv6 is largely a failure, and I say this as someone that wrote a blog post for APNIC on how to turn on ipv6.
I'll get endless pushback for this, but the reality is that adoption isn't at 100%, it very closely needs to be, and there are still entire ISPs that only assign ipv4, to say nothing of routers people are buying and installing that don't have ipv6 enabled out of the box.
A much better solution here would have been an incredibly conservative "written on a napkin" change to ipv4 to expand the number of available address space. It still would have been difficult to adopt, but it would have the benefit of being a simple change to a system everyone already understands and on top of a stack that largely already exists.
I'm not proposing to abandon ipv6, but at this point I'm really not sure how we proceed here. The status quo is maintaining two separate competing protocols forever, which was not the ultimate intention.
I'll get endless pushback for this, but the reality is that adoption isn't at 100%, it very closely needs to be, and there are still entire ISPs that only assign ipv4, to say nothing of routers people are buying and installing that don't have ipv6 enabled out of the box.
A much better solution here would have been an incredibly conservative "written on a napkin" change to ipv4 to expand the number of available address space. It still would have been difficult to adopt, but it would have the benefit of being a simple change to a system everyone already understands and on top of a stack that largely already exists.
I'm not proposing to abandon ipv6, but at this point I'm really not sure how we proceed here. The status quo is maintaining two separate competing protocols forever, which was not the ultimate intention.
> A much better solution here would have been an incredibly conservative change to ipv4 to expand the number of available address space
"And what do you base this belief on?
Fact is you'd run into exactly the same problems as with IPv6. Sure, network-enabled software might be easier to rewrite to support 40-bit IPv4+, but any hardware-accelerated products (routers, switches, network cards, etc.) would still need replacement (just as with IPv6), and you'd still need everyone to be assigned unique IPv4+ addresses in order to communicate with each other (just as with IPv6)."[0]
0: https://news.ycombinator.com/item?id=37120422
"And what do you base this belief on?
Fact is you'd run into exactly the same problems as with IPv6. Sure, network-enabled software might be easier to rewrite to support 40-bit IPv4+, but any hardware-accelerated products (routers, switches, network cards, etc.) would still need replacement (just as with IPv6), and you'd still need everyone to be assigned unique IPv4+ addresses in order to communicate with each other (just as with IPv6)."[0]
0: https://news.ycombinator.com/item?id=37120422
> Fact is you'd run into exactly the same problems as with IPv6.
If you treat IPv4 addresses as a routable prefix (same as today), then the internet core routers don't change at all.
Only the edge equipment would need to be IPv4+ aware. And even that awareness could be quite gradual, since you would have NAT to fall back on when receiving an IPv4 classic packet at the network. It can even be customer deployed. Add an IPv4+ box on the network, assign it the DMZ address, and have it hand out public IPV4+ addresses and NAT them to the local IPv4 private subnet.
IPv6 seems to be a standard that suffered from re-design by committee. Lots of good ideas were incorporated, but it resulted in a stack that had only complicated backwards compatibility. It has taken the scale of mobile carriers to finally make IPv6 more appealing in some cases than IPv4+NAT, but I think we are still a long way from any ISP being able to disable IPv4 support.
If you treat IPv4 addresses as a routable prefix (same as today), then the internet core routers don't change at all.
Only the edge equipment would need to be IPv4+ aware. And even that awareness could be quite gradual, since you would have NAT to fall back on when receiving an IPv4 classic packet at the network. It can even be customer deployed. Add an IPv4+ box on the network, assign it the DMZ address, and have it hand out public IPV4+ addresses and NAT them to the local IPv4 private subnet.
IPv6 seems to be a standard that suffered from re-design by committee. Lots of good ideas were incorporated, but it resulted in a stack that had only complicated backwards compatibility. It has taken the scale of mobile carriers to finally make IPv6 more appealing in some cases than IPv4+NAT, but I think we are still a long way from any ISP being able to disable IPv4 support.
> Only the edge equipment would need to be IPv4+ aware.
"Only"? That's still the networking stack of every desktop, laptop, phone, printer, room presentation device, IoT thing-y. Also every firewall device. Then recompile every application to use the new data structures with more bits for addresses.
And let's not forget you have to update all the DNS code because A records are hardcoded to 32-bits, so you need a new record type, and a mechanism to deal with getting both long and short addresses in the reply (e.g., Happy Eyeballs). Then how do you deal with a service that only has a "IPv4+" address but application code that is only IPv4-plain?
Basically all the code and infrastructure that needed to be updated and deployed for IPv6 would have to be done for IPv4+.
"Only"? That's still the networking stack of every desktop, laptop, phone, printer, room presentation device, IoT thing-y. Also every firewall device. Then recompile every application to use the new data structures with more bits for addresses.
And let's not forget you have to update all the DNS code because A records are hardcoded to 32-bits, so you need a new record type, and a mechanism to deal with getting both long and short addresses in the reply (e.g., Happy Eyeballs). Then how do you deal with a service that only has a "IPv4+" address but application code that is only IPv4-plain?
Basically all the code and infrastructure that needed to be updated and deployed for IPv6 would have to be done for IPv4+.
But the desktop/laptop/phone/printer was the EASIEST thing to change in that 30 year history. And it would have been the easiest thing to demand a change req from a company for.
Yes: but the process would have been exactly the same whether for a hypothetical IPv4+ or the IPng/IPv6 that was decided on; pushing new code to every last corner of the IP universe.
How could it have been otherwise given the original network structures were all of fixed lengths of 32 bits?
How could it have been otherwise given the original network structures were all of fixed lengths of 32 bits?
The new code would have been vastly simpler. IPv6 is second system syndrome personified.
What we needed was the equivalent of ASCII->UTF8.
What we needed was the equivalent of ASCII->UTF8.
If we have IPv4 address 1.2.3.4, and the hypothetical IPv4+ adds 1.2.3.4.1.2.3.4 (or longer), how would a IPv4-only router handle 1.2.3.4.1.2.3.4? If an IPv4-only host or application gets a DNS response with 1.2.3.4.1.2.3.4, how is it supposed to use it?
As I see it, the transition mechanism for some IPv4+ that 'only' has longer addresses is exactly the same as for IPv6: new code paths that use new data structures, with a gradual rollout with tech refreshes and code updates where hosts slowly go from IPv4-only to IPv4-and-IPv4+ at different rates in different organizations.
If you think it's somehow different, can you explain how it is so? What proposal available (especially when IPng was being decided on in the 1990s) would have allowed for a transition that is different than the one described above (gradual, uncoördinated rollout)?
* https://datatracker.ietf.org/doc/html/rfc1726
* https://datatracker.ietf.org/doc/html/rfc1752
As I see it, the transition mechanism for some IPv4+ that 'only' has longer addresses is exactly the same as for IPv6: new code paths that use new data structures, with a gradual rollout with tech refreshes and code updates where hosts slowly go from IPv4-only to IPv4-and-IPv4+ at different rates in different organizations.
If you think it's somehow different, can you explain how it is so? What proposal available (especially when IPng was being decided on in the 1990s) would have allowed for a transition that is different than the one described above (gradual, uncoördinated rollout)?
* https://datatracker.ietf.org/doc/html/rfc1726
* https://datatracker.ietf.org/doc/html/rfc1752
The proposal is that IPv4+ would be interpretable as an IPv4 packet. Either the IP header is extended, or we add another protocol layer for the IPv4+ bits (IPv4+ is another envelope for the user payload).
DNS is like today: A and AAAA records for IPv4 and IPv4+ respectively.
Core routers do not need to know about IPv4+, and might never know.
The transition is similar to 6to4. The edge router does translation to allow IPv4+ hosts to connect to IPv4 hosts. IPv4 hosts are unable to connect to IPv4+ directly (only via NAT). So it has the similar problem to IPv6 that you ideally want all servers to have a full IPv4 address.
What you don't have is a completely parallel addressing system, requirements to upgrade all routers (only edge routers for 4+ networks), requirements to have your ISP cooperate (they can just give you an IPv4 and you handle IPv4+ with your own router), and no need that the clients have two stacks operating at once.
It's essentially a better NAT, one where the clients behind other NATs can directly connect, and where the NAT gradually disappears completely.
DNS is like today: A and AAAA records for IPv4 and IPv4+ respectively.
Core routers do not need to know about IPv4+, and might never know.
The transition is similar to 6to4. The edge router does translation to allow IPv4+ hosts to connect to IPv4 hosts. IPv4 hosts are unable to connect to IPv4+ directly (only via NAT). So it has the similar problem to IPv6 that you ideally want all servers to have a full IPv4 address.
What you don't have is a completely parallel addressing system, requirements to upgrade all routers (only edge routers for 4+ networks), requirements to have your ISP cooperate (they can just give you an IPv4 and you handle IPv4+ with your own router), and no need that the clients have two stacks operating at once.
It's essentially a better NAT, one where the clients behind other NATs can directly connect, and where the NAT gradually disappears completely.
As someone with non-ascii and non-latin-1 characters in my surname, I can tell you that the ascii->utf8 migration still hasn’t finished.
Just a few weeks ago I ordered something from JBL US and somehow on the UPS sticker an "Á" became a caret "^"
shrug
Most of the world is a circus.
shrug
Most of the world is a circus.
If you hand UTF-8 that actually uses anything added by utf-8 to something that can only render ASCII, the text will be garbled. People can read garbled text ok if it’s a few missing accented characters in a western language, but it’s no good for Japanese or Arabic.
In networking terms, this is like a protocol which can reach ipv4 hosts only but loses packets to the ipv4+ hosts randomly depending on what it passes through. Who would adopt a networking technology that fails randomly?
In networking terms, this is like a protocol which can reach ipv4 hosts only but loses packets to the ipv4+ hosts randomly depending on what it passes through. Who would adopt a networking technology that fails randomly?
And in 30 years, all of that has basically already happened and afoption is still absymal.
v6 has nearly 3 billion users. How is that abysmal?
We've never done something like the v4->v6 migration before, on this sort of scale. It's not clear what the par time for something like this is. Maybe 30 years is a normal amount of time for it to take?
We've never done something like the v4->v6 migration before, on this sort of scale. It's not clear what the par time for something like this is. Maybe 30 years is a normal amount of time for it to take?
HTTP->HTTPS was this kind of scale, and it was smooth because they changed as little as possible while also being very careful about default behaviors.
3 billion people sorta use ipv6, but not really, cause almost all of those also rely on ipv4 and no host can really go ipv6-only. Meanwhile, many sites are HTTPS-only.
3 billion people sorta use ipv6, but not really, cause almost all of those also rely on ipv4 and no host can really go ipv6-only. Meanwhile, many sites are HTTPS-only.
And because it's a layer 7 thing, so it only required updating the server and client software, not the OS... and only the client and server endpoints and not the routers in between... and because we only have two browser vendors who between them can push the ecosystem around, and maybe half a dozen relevant web server daemons.
Layer 3 of the Internet is the one that requires support in all software and on all routers in the network path, and those are run by millions of people in hundreds of countries with no central entity that can force them to do anything.
HTTP->HTTPS is only similar in terms of number of users, not in terms of the deployment itself. The network effects for IP are much stronger than for HTTP.
They don't "sorta" use v6, they're properly using it, and you can certainly go v6-only. I'm posting from a machine with no v4. Also, if you want to go there: HTTPS was released before IPv6, and yet still no browser is HTTPS only, despite how much easier it is to deploy it.
Layer 3 of the Internet is the one that requires support in all software and on all routers in the network path, and those are run by millions of people in hundreds of countries with no central entity that can force them to do anything.
HTTP->HTTPS is only similar in terms of number of users, not in terms of the deployment itself. The network effects for IP are much stronger than for HTTP.
They don't "sorta" use v6, they're properly using it, and you can certainly go v6-only. I'm posting from a machine with no v4. Also, if you want to go there: HTTPS was released before IPv6, and yet still no browser is HTTPS only, despite how much easier it is to deploy it.
I know they aren't very comparable in a technical way, but look at the mindset. IPv6 included decisions that knowingly made it more different from v4 than strictly needed, cause they wanted it to be perfect day 1. If they did HTTPS like this, it'd be tied to HTTP/2.
Most browsers now discourage plain HTTP with a warning. Any customer-facing server basically needs to use HTTPS now. And you're rare if you actually have no ipv4, not even via a tunnel.
Most browsers now discourage plain HTTP with a warning. Any customer-facing server basically needs to use HTTPS now. And you're rare if you actually have no ipv4, not even via a tunnel.
HTTP has the leeway to do that because they have an easier technical job deploying updates.
If they only got one shot at changing HTTP, do you think they would have tied TLS to HTTP/2 or given up on HTTP/2 altogether?
If they only got one shot at changing HTTP, do you think they would have tied TLS to HTTP/2 or given up on HTTP/2 altogether?
The compromised "ipv4+" idea a bunch of people keep asking for wouldn't require changing the spec down the road. ISPs would just need to clean up their routes later, and SLAAC could still exist as an optional (rather than default) feature for anyone inclined to enable later. Btw, IPv6 spec was only finalized in 2017, wasn't exactly one-shot.
I don't know if HTTP's job is easier. Maybe on the client side, since there were never that many browsers, but you have load-balancers, CDNs, servers, etc. HTTP/2 adoption is still dragging out because of how many random things don't support it. Might be a big reason why gRPC isn't so popular too.
I don't know if HTTP's job is easier. Maybe on the client side, since there were never that many browsers, but you have load-balancers, CDNs, servers, etc. HTTP/2 adoption is still dragging out because of how many random things don't support it. Might be a big reason why gRPC isn't so popular too.
> HTTP->HTTPS was this kind of scale, and it was smooth because they changed as little as possible while also being very careful about default behaviors.
HTTP->HTTPS is not equivalent in any way. The payload in HTTP and HTTPS are exactly the same; HTTPS simply adds a wrapper (e.g., stunnel can be used with an HTTP-only web server). Further HTTP(S) is only on the end points, and specifically in the application layer: your OS, switch, firewall, CPE, ISP router(s), etc, all can be left alone.
If you're not running a web browser or web server (i.e., FTP, SMTP, DNS, database) then there are zero changes that need to be made to any code on a system. This is not true for changing the number of bits the addressing space: every piece of code that calls socket(), bind(), connect(), etc, has to be touched.
Whereas the primary purpose of IPng was to expand the address space, which means your OS, switch, firewall, CPE, ISP router(s), etc, all have to be modified to handle more address bits in the Layer 3 protocol data unit.
Plus stuff at the application layer like DNS (since A records are 32-bit only, you need an entire new network type): entire new library functions had to be created (e.g., gethostbyname() replaced by getaddrinfo()).
I hear people say the IETF/IP Wizards of the 1990s should have "just" picked an IPng that was a larger address space, but don't explain how IPv4 and hypothetical IPv4+ would actually work. Instead of 1.1.1.1, a packet comes in with 1.1.1.1.1.1.1.1: how would a non-IPv4+ router know what to do with that? How would non-updated routers and firewalls be able to handle longer addresses? How would non-updated DNS code be able to handle new record types with >32 bits?
HTTP->HTTPS is not equivalent in any way. The payload in HTTP and HTTPS are exactly the same; HTTPS simply adds a wrapper (e.g., stunnel can be used with an HTTP-only web server). Further HTTP(S) is only on the end points, and specifically in the application layer: your OS, switch, firewall, CPE, ISP router(s), etc, all can be left alone.
If you're not running a web browser or web server (i.e., FTP, SMTP, DNS, database) then there are zero changes that need to be made to any code on a system. This is not true for changing the number of bits the addressing space: every piece of code that calls socket(), bind(), connect(), etc, has to be touched.
Whereas the primary purpose of IPng was to expand the address space, which means your OS, switch, firewall, CPE, ISP router(s), etc, all have to be modified to handle more address bits in the Layer 3 protocol data unit.
Plus stuff at the application layer like DNS (since A records are 32-bit only, you need an entire new network type): entire new library functions had to be created (e.g., gethostbyname() replaced by getaddrinfo()).
I hear people say the IETF/IP Wizards of the 1990s should have "just" picked an IPng that was a larger address space, but don't explain how IPv4 and hypothetical IPv4+ would actually work. Instead of 1.1.1.1, a packet comes in with 1.1.1.1.1.1.1.1: how would a non-IPv4+ router know what to do with that? How would non-updated routers and firewalls be able to handle longer addresses? How would non-updated DNS code be able to handle new record types with >32 bits?
HTTP->HTTPS looks easy in hindsight, but there were plenty of ways it could have gone wrong. They took the path of least resistance, unlike ipv6. I know they're different layers ofc.
To answer the last question, routers would need IPv4+ support, just like ipv6 which already happened. The key is it's much easier for users to switch after. No dual stack, you get the same address, routes, DNS, and middleboxes like NAT initially. ISPs can't hand out longer addrs like /40 until things like DNS are upgraded in-place to support that, but again those are pretty invisible changes throughout the stack.
To answer the last question, routers would need IPv4+ support, just like ipv6 which already happened. The key is it's much easier for users to switch after. No dual stack, you get the same address, routes, DNS, and middleboxes like NAT initially. ISPs can't hand out longer addrs like /40 until things like DNS are upgraded in-place to support that, but again those are pretty invisible changes throughout the stack.
> To answer the last question, routers would need IPv4+ support, just like ipv6 which already happened.
So exactly like IPv6: you need to roll out new code everywhere.
> The key is it's much easier for users to switch after. No dual stack, you get the same address, routes, DNS, and middleboxes like NAT initially. ISPs can't hand out longer addrs like /40 until things like DNS are upgraded in-place to support that, but again those are pretty invisible changes throughout the stack.
So exactly like IPv6: you need to roll out new code everywhere.
Would organization have rolled out in IPv4+ any differently than IPv6? Some early, some later, some questioning the need at all. It's the exact same coördination / herding cats problem.
So exactly like IPv6: you need to roll out new code everywhere.
> The key is it's much easier for users to switch after. No dual stack, you get the same address, routes, DNS, and middleboxes like NAT initially. ISPs can't hand out longer addrs like /40 until things like DNS are upgraded in-place to support that, but again those are pretty invisible changes throughout the stack.
So exactly like IPv6: you need to roll out new code everywhere.
Would organization have rolled out in IPv4+ any differently than IPv6? Some early, some later, some questioning the need at all. It's the exact same coördination / herding cats problem.
It's a simple toggle on vs asking orgs to redo their entire network. In both cases you need routers and network stacks to support the new packet format, but that isn't the hard part of ipv6, we already got there and people still aren't switching.
Sorry, I'm still not seeing how a IPv4+ would be any less complicated (or as simple) as IPv6. In either case you would still have to:
* roll out new code everywhere
* enable the protocol on your routers
* get address block(s) assigned to you
* put those blocks into BGP
* enable the protocol on middleware boxes
* have translation boxes for new-protocol hosts talk to old-protocol-only hosts
* enable the protocol on end hosts
And just because you do it, does not mean anyone else would do in the same timeframe (or ever). You're back in the chicken-and-egg of whether servers/services do it first ("where are the clients?"), or end-devices ("where are the services?").
* roll out new code everywhere
* enable the protocol on your routers
* get address block(s) assigned to you
* put those blocks into BGP
* enable the protocol on middleware boxes
* have translation boxes for new-protocol hosts talk to old-protocol-only hosts
* enable the protocol on end hosts
And just because you do it, does not mean anyone else would do in the same timeframe (or ever). You're back in the chicken-and-egg of whether servers/services do it first ("where are the clients?"), or end-devices ("where are the services?").
No, routers would have to be fixed anyway, because even if you put extra bits into extension header we have 30 years of experience that routers and ISPs will regularly fuck around with those extra bits - it's related to why we have TLS GREASE option.
Application rework would be exactly the same as with v6, because the issue was not with v6 but with BSD Sockets API exposing low-level details to userland.
Application rework would be exactly the same as with v6, because the issue was not with v6 but with BSD Sockets API exposing low-level details to userland.
> Only the edge equipment would need to be IPv4+ aware. And even that awareness could be quite gradual, since you would have NAT to fall back on when receiving an IPv4 classic packet at the network. It can even be customer deployed. Add an IPv4+ box on the network, assign it the DMZ address, and have it hand out public IPV4+ addresses and NAT them to the local IPv4 private subnet.
Congratulations, you’ve re-invented CGNAT, with none of the benefits, and the additional hassle of it being an entirely new protocol!
No. No “extra bits” on an IPv4 address would have ever worked. NAT itself is a bug. Suggesting that as an intentional design is disingenuous.
Congratulations, you’ve re-invented CGNAT, with none of the benefits, and the additional hassle of it being an entirely new protocol!
No. No “extra bits” on an IPv4 address would have ever worked. NAT itself is a bug. Suggesting that as an intentional design is disingenuous.
I have not "reinvented CGNAT". It is hierarchal public addressing similar to IPv4 and IPv6.
The edge router has an IPv4+ subnet (either a classic v4 address, or part of a v4+ address). It maintains an L2 routing table with ARP+, and routes IPv4+ packets to the endpoint without translation. Private subnetting and NAT is only needed to support legacy IPv4 clients.
CGNAT pools IPv4 public addresses and has an expanded key for each connection, and translates either 4 to 6 or into a private IPv4 subnet. My proposal needs no pooling and only requires translation if the remote host is IPv4 classic and the edge router is not assigned a full IPv4+/24.
The edge router has an IPv4+ subnet (either a classic v4 address, or part of a v4+ address). It maintains an L2 routing table with ARP+, and routes IPv4+ packets to the endpoint without translation. Private subnetting and NAT is only needed to support legacy IPv4 clients.
CGNAT pools IPv4 public addresses and has an expanded key for each connection, and translates either 4 to 6 or into a private IPv4 subnet. My proposal needs no pooling and only requires translation if the remote host is IPv4 classic and the edge router is not assigned a full IPv4+/24.
Not just the edge router. Every router between the ISP edge and the destination edge.
And since the goal is “backwards-compatability”, you’d always need to poll, because a “legacy” IPv4 client would also be unable to send packets to the IPv4+ destination. Or receive packets with an IPv4+ source address.
And it would be an absolute nightmare to maintain. CGNAT + a quasi backwards-compatible protocol where the backwards-compatability wouldn’t work in practice.
So you would have exactly the same problem as IPv6. I can say the same about v4 and v6 today. You could just turn off IPv4 on the internet, and we’d only need to do translation on the edge for the legacy clients that would still use IPv4. You can even put IPv4 addresses in IPv6 packets!
And since the goal is “backwards-compatability”, you’d always need to poll, because a “legacy” IPv4 client would also be unable to send packets to the IPv4+ destination. Or receive packets with an IPv4+ source address.
And it would be an absolute nightmare to maintain. CGNAT + a quasi backwards-compatible protocol where the backwards-compatability wouldn’t work in practice.
So you would have exactly the same problem as IPv6. I can say the same about v4 and v6 today. You could just turn off IPv4 on the internet, and we’d only need to do translation on the edge for the legacy clients that would still use IPv4. You can even put IPv4 addresses in IPv6 packets!
I think you've actually reinvented 6to4, or something morally very close to it.
Each v4 address has a corresponding /48 of IPv6 tunnelled to it. The router with that IP receives the tunnelled v6 packets, extracts them and routes them on natively to the end host. This is something that v6 already does, so you don't need to make posts complaining about how dumb they were for not doing it.
Each v4 address has a corresponding /48 of IPv6 tunnelled to it. The router with that IP receives the tunnelled v6 packets, extracts them and routes them on natively to the end host. This is something that v6 already does, so you don't need to make posts complaining about how dumb they were for not doing it.
That's quite true, but in this counterfactual, IPv4+ doesn't pretend that 6to4 is just a transition mechanism to an all-IPv6 future. That is, IPv4+ is as-if 6to4 was the default, preferred, or only mechanism, and core routers were never demanded to upgrade.
It's an edge based solution similar to NAT, but directly addressable. And given that it extends IPv4, I think it would have been much more "marketable" than IPv6 was.
But again, this is all counterfactual. The IETF standardized IPv6, and 30 years on it's still unclear that we will deprecate IPv4 anytime soon.
It's an edge based solution similar to NAT, but directly addressable. And given that it extends IPv4, I think it would have been much more "marketable" than IPv6 was.
But again, this is all counterfactual. The IETF standardized IPv6, and 30 years on it's still unclear that we will deprecate IPv4 anytime soon.
But we do want a v6-only future, right? We don't want to be running both protocols forever, which is what you'd be asking for.
I agree with that belief, and I've been saying it for over 20 years.
I base it on comparing how the IPv2 to IPv4 rollout went, versus the IPv4 to IPv6 rollout. The fact that it was incredibly obvious how to route IPv2 over IPv4 made it a no-brainer for the core Internet to be upgraded to IPv4.
By contrast it took over a decade for IPv6 folks to accept that IPv6 was never going to rule the world unless you can route IPv4 over it. Then we got DS-Lite. Which, because IPv6 wasn't designed to do that, adds a tremendous amount of complexity.
Will we eventually get to an IPv6 only future? We have to. There is no alternative. But the route is going to be far more painful than it would have been if backwards compatibility was part of the original design.
Of course the flip side is that some day we don't need IPv4 backwards compatibility. But that's still decades from now. How many on the original IPv6 will even still be alive to see it?
I base it on comparing how the IPv2 to IPv4 rollout went, versus the IPv4 to IPv6 rollout. The fact that it was incredibly obvious how to route IPv2 over IPv4 made it a no-brainer for the core Internet to be upgraded to IPv4.
By contrast it took over a decade for IPv6 folks to accept that IPv6 was never going to rule the world unless you can route IPv4 over it. Then we got DS-Lite. Which, because IPv6 wasn't designed to do that, adds a tremendous amount of complexity.
Will we eventually get to an IPv6 only future? We have to. There is no alternative. But the route is going to be far more painful than it would have been if backwards compatibility was part of the original design.
Of course the flip side is that some day we don't need IPv4 backwards compatibility. But that's still decades from now. How many on the original IPv6 will even still be alive to see it?
The IPv2 to IPv4 migration involved sysadmins at less than 50 institutions (primarily universities and research labs), updating things they considered to be a research project, that didn’t have specialised network hardware that knew anything about IP, and any networked software was primarily written either by the sysadmins themselves or people that one of them could walk down the corridor to the office of. Oh, and several months of downtime if someone was too busy to update right now was culturally acceptable. It’s not remotely the same environment as existed at the time of IPv6 being designed
Hardware would catch up. And IPv4 would never go away. If you connect to 1.1.1.1 it would still be good ole IPv4. You would only have in addition the option to connect to 1.1.1.1.1.1.1.2 if the entire chain supports it. And if not, it could still be worked around through software with proxies and NAT.
So... just a less ambitious IPv6 that would still require dual-stack networking setups? The current adoption woes would've happened regardless, unless someone comes up with a genius idea that doesn't require any configuration/code changes.
I disagree. The current adoption woes are exactly because IPv6 is so different from IPv4. Everyone who tries it out learns the hard way that most of what they know from IPv4 doesn't apply. A less ambitious IPv4 is exactly what we need in order to make any progress
It’s not _that_ different. Larger address space, more emphasis on multicast for some basic functions. If you understand those functions in IPv4, learning IPv6 is very straightforward. There’s some footguns once you get to enterprise scale deployments but that’s just as true of IPv4.
Lol! IPv4 uses zero multicast (I know, I know, technically there's multicast, but we all just understand broadcast). The parts of an IPv4 address and their meaning have almost no correlation to the parts of an IPv6 address and their meaning. Those are pretty fundamental differences.
IP addresses in both protocols are just a sequence of bits. Combined with a subnet mask (or prefix length, the more modern term for the same concept) they divide into a network portion and a host portion. The former tells you what network the host is on, the latter uniquely identifies the host on that network. This is exactly the same for both protocols.
Or what do you mean by “parts of an IPv4 address and their meaning”?
That multicast on IPv4 isn’t used as much is irrelevant. It functions the same way in both protocols.
Or what do you mean by “parts of an IPv4 address and their meaning”?
That multicast on IPv4 isn’t used as much is irrelevant. It functions the same way in both protocols.
IPv4 uses ARP which is just a half baked multicast. IPv6 is much better designed.
The biggest difference is often overlooked because it's not part of the packet format or anything: IPv4 /32s were not carried over to IPv6. If you owned 1.1.1.1 on ipv4, and you switch to ipv6, you get an entirely different address instead of 1.1.1.1::. Maaybe you get an ipv6-mapped-ipv4 ::ffff:1.1.1.1, but that's temporary and isn't divisible into like 1.1.1.1.2.
And then all the defaults about how basically everything works are different. Home router in v6 mode means no DHCP, no NAT, and hopefully yes firewall. In theory you can make it work a lot like v4, but by default it's not.
And then all the defaults about how basically everything works are different. Home router in v6 mode means no DHCP, no NAT, and hopefully yes firewall. In theory you can make it work a lot like v4, but by default it's not.
multicast has been dead for years
> The current adoption woes are exactly because IPv6 is so different from IPv4. Everyone who tries it out learns the hard way that most of what they know from IPv4 doesn't apply.
In my experience the differences are just an excuse, and however similar you made the protocol to IPv4 the people who wanted an excuse would still manage to find one. Deploying IPv6 is really not hard, you just have to actually try.
In my experience the differences are just an excuse, and however similar you made the protocol to IPv4 the people who wanted an excuse would still manage to find one. Deploying IPv6 is really not hard, you just have to actually try.
Part of the ipv6 ambition was fixing all the suboptimally allocated ipv4 routes. They considered your idea and decided against it for that reason. But had they done it, we would've already been on v6 for years and had plenty of time to build some cleaner routes too.
I think they also wanted to kill NAT and DHCP everywhere, so there's SLAAC by default. But turns out NAT is rather user-friendly in many cases! They even had to bolt on that v6 privacy extension.
I think they also wanted to kill NAT and DHCP everywhere, so there's SLAAC by default. But turns out NAT is rather user-friendly in many cases! They even had to bolt on that v6 privacy extension.
What do you mean by suboptimal allocation?
The ipv4 routing table contains many individual /24 subnets that cannot be summarized, causing bloat in the routing tables.
With ipv6, that can be simplified with just a couple of /32 or /48 prefixes per AS.
With ipv6, that can be simplified with just a couple of /32 or /48 prefixes per AS.
This, because a bunch of random /24s were sold off to different ISPs, because of address scarcity.
> I disagree. The current adoption woes are exactly because IPv6 is so different from IPv4.
How is IPv6 "so different" than IPv4 when looking at Layer 3 and above?
(Certainly ARP vs ND is different.)
How is IPv6 "so different" than IPv4 when looking at Layer 3 and above?
(Certainly ARP vs ND is different.)
I didn't say it was different 'when looking at layer 3 and above". I said it's different from IPv4. At the IP layer.
At the IP layer just being different is 90% of the trouble. Being less ambitious would have some upsides and downsides but not seriously change that.
> I said it's different from IPv4. At the IP layer.
In what way? Longer addresses? In what way is it "so different" that people are unable to handle whatever differences you are referring to?
We used to have IPv4, NetBEUI, AppleTalk, IPX all in regular use in the past: and that's just on Ethernet (of various flavours), never mind different Layer 2s. Have network folks become so dim over the last few years that they can't handle a different protocol now?
In what way? Longer addresses? In what way is it "so different" that people are unable to handle whatever differences you are referring to?
We used to have IPv4, NetBEUI, AppleTalk, IPX all in regular use in the past: and that's just on Ethernet (of various flavours), never mind different Layer 2s. Have network folks become so dim over the last few years that they can't handle a different protocol now?
But that is a bug in history. IPv6 was standardized BEFORE NAT.
“most what they know from IPv6” is just NAT.
> A less ambitious IPv4 is exactly what we need in order to make any progress
but we’re already making very good progress with IPv6? Global traffic to Google is >50% IPv6 already.
“most what they know from IPv6” is just NAT.
> A less ambitious IPv4 is exactly what we need in order to make any progress
but we’re already making very good progress with IPv6? Global traffic to Google is >50% IPv6 already.
Current statistics are that a bit over 70% of websites are IPv4 only. A bit under 30% allow IPv6. IPv6 only websites are a rounding error.
Therefore if I'm on an IPv6 phone, odds are very good that my traffic winds up going over IPv4 internet at some point.
We're 30 years into the transition. We are still decades away from it being viable for servers to run IPv6 first. You pretty much have to do IPv4 on a server. IPv6 is an afterthought.
Therefore if I'm on an IPv6 phone, odds are very good that my traffic winds up going over IPv4 internet at some point.
We're 30 years into the transition. We are still decades away from it being viable for servers to run IPv6 first. You pretty much have to do IPv4 on a server. IPv6 is an afterthought.
> We are still decades away from it being viable for servers to run IPv6 first.
Just put Cloudflare in front of it. You don’t need to use IPv4 on servers AT ALL. Only on the edge. You can easily run IPv6-only internally. It’s definitely not an afterthought for any new deployments. In fact there’s even a US gov’t mandate to go IPv6-first.
It’s the eyeballs that need IPv4. It’s a complete non-issue for servers.
Just put Cloudflare in front of it. You don’t need to use IPv4 on servers AT ALL. Only on the edge. You can easily run IPv6-only internally. It’s definitely not an afterthought for any new deployments. In fact there’s even a US gov’t mandate to go IPv6-first.
It’s the eyeballs that need IPv4. It’s a complete non-issue for servers.
"Just put Cloudflare in front of it"
Why do I have to get some third party involved??
Listen, you can be assured that the geek in me wants to master IPv6 and run it on my home network and feel clever because I figured it out, but there's another side of me that wants my networking stuff to just work!
Why do I have to get some third party involved??
Listen, you can be assured that the geek in me wants to master IPv6 and run it on my home network and feel clever because I figured it out, but there's another side of me that wants my networking stuff to just work!
If you don’t want to put Cloudflare in front of it, you can dual-stack the edge and run your own NAT46 gateway, while still keeping the internal network v6 only.
You have a point. But you still need DNS to an IPv4 address. And the fact that about 70% of websites are IPv4 only means that if you're setting up a new website, odds are good that you won't do IPv6 in the first pass.
Cloudflare proxy automatically creates A and AAAA records. And you can’t even disable AAAA ones, except in the Enterprise plan. So if you use Cloudflare, your website simply is going to be accessible over both protocols, irrespective of the one you actually choose. Unless you’re on Enterprise and go out of your way to disable it.
Pretty sure NAT was standardized before IPv6.
NAT is RFC 1631.
IPv6 is RFC 1883.
Admitted, that was very basic NAT.
NAT is RFC 1631.
IPv6 is RFC 1883.
Admitted, that was very basic NAT.
RFC 1631 is a memo, not a standard.
Actually, my bad. NAT was NEVER standardized. Not only NAT was never standardized, it’s never even been on standards track. RFC 3022 is also just “Informational”
Plus, RFC 1918 doesn’t even mention NAT
So yes, NAT is a bug in history that has no right to exist. The people who invented it clearly never stopped to think on whether they should, so here we are 30 years later.
Actually, my bad. NAT was NEVER standardized. Not only NAT was never standardized, it’s never even been on standards track. RFC 3022 is also just “Informational”
Plus, RFC 1918 doesn’t even mention NAT
So yes, NAT is a bug in history that has no right to exist. The people who invented it clearly never stopped to think on whether they should, so here we are 30 years later.
That doesn't really mean much. Basic NAT wasn't eligible to be on the standards track as it isn't a protocol. Same reason firewall RFCs are informational or BCP.
The protocols involving NAT are what end up on the standards track like FTP extensions for NAT (RFC 2428), STUN (RFC 3489), etc.
The protocols involving NAT are what end up on the standards track like FTP extensions for NAT (RFC 2428), STUN (RFC 3489), etc.
If only the inventors of NAT had patented it and then refused to license it!
Sort of. I think people would understand
201.20.188.24.6
And most of what they know about how it works clicks in their mind. It just has an extra octet.
I also think hardware would have been upgraded faster.
201.20.188.24.6
And most of what they know about how it works clicks in their mind. It just has an extra octet.
I also think hardware would have been upgraded faster.
It would've been even easier and lasted longer to use two bytes of hex at the start. That would've expanded the Internet to 65536x its current space.
Something like aaff:a.b.c.d
Leaving off the prefix: could just mean strictly IPv4.
Something like aaff:a.b.c.d
Leaving off the prefix: could just mean strictly IPv4.
In IPv6, this is spelled ::ff00:a.b.c.d
It didn’t speed up adoption and people then tried most of the other solutions people are going to suggest for IPv4+. Want the IPv4 address as the network address instead? That’s 2002:a.b.c.d/48 - many ISPs didn’t deploy that either
It didn’t speed up adoption and people then tried most of the other solutions people are going to suggest for IPv4+. Want the IPv4 address as the network address instead? That’s 2002:a.b.c.d/48 - many ISPs didn’t deploy that either
I think making the extra hex at the end is better, that way its like we are subdividing our existing networks without moving them around
Think of it like phone numbers. For decades people have accepted gradual phone number prefix additions. I remember in rural Ireland my parents got an extra digit in the late 70s, two more in the 90s, and it was conceptually easy. It didn't change how phones work, turn your phone into a party line or introduce letters or special characters into the rotary dial, or allow you to skip consecutive similar digits.
For people who deal with ip addresses, the switch from ipv4 to ipv6 means moving from 4 digits (1.2.3.4) to this:
Plus switching completely to ipv6 overnight means throwing away all your current knowledge of how to secure your home network. For lazy people, ipv4 NAT "accidentally" provides firewall-like features because none of your home ipv4 addresses are public. People are immediately afraid of ipv6 in the home and now they need to know about firewalls. With ipv4, firewalls were simple enough. "My network starts with 192.168, the Internet doesn't". You need to learn unlearn NAT and port forwarding and realise that with already routable ipv6 addresses you just need a firewall with default deny, and then add rules that "unlock" traffic on specific ports to specific addresses. Of course more complexity gets in the way... devices use "Privacy Extensions" and change their addresses, so making firewall rules work long-term, you should use the device's MAC Address. Christ on a bike.
I totally see why people open this bag of crazy shit and say to themselves "maybe next time I buy a new router I'll do this, but right now I have a home with 4 phones, 3 TVs, 2 consoles, security cameras, and some god damn kitchen appliances that want to talk to home connect or something". Personally, I try to avoid fucking with the network as much as possible to avoid the wrath of my wife (her voice "Why are you breaking shit for ideological reasons? What was broken? What new amazing thing can I do after this?").
For people who deal with ip addresses, the switch from ipv4 to ipv6 means moving from 4 digits (1.2.3.4) to this:
2001:0db8:0000:0000:0008:0800:200c:417a
2001:db8:0:0:8:800:200c:417a
2001:db8::8:800:200c:417a
Plus switching completely to ipv6 overnight means throwing away all your current knowledge of how to secure your home network. For lazy people, ipv4 NAT "accidentally" provides firewall-like features because none of your home ipv4 addresses are public. People are immediately afraid of ipv6 in the home and now they need to know about firewalls. With ipv4, firewalls were simple enough. "My network starts with 192.168, the Internet doesn't". You need to learn unlearn NAT and port forwarding and realise that with already routable ipv6 addresses you just need a firewall with default deny, and then add rules that "unlock" traffic on specific ports to specific addresses. Of course more complexity gets in the way... devices use "Privacy Extensions" and change their addresses, so making firewall rules work long-term, you should use the device's MAC Address. Christ on a bike.
I totally see why people open this bag of crazy shit and say to themselves "maybe next time I buy a new router I'll do this, but right now I have a home with 4 phones, 3 TVs, 2 consoles, security cameras, and some god damn kitchen appliances that want to talk to home connect or something". Personally, I try to avoid fucking with the network as much as possible to avoid the wrath of my wife (her voice "Why are you breaking shit for ideological reasons? What was broken? What new amazing thing can I do after this?").
> Yes, the ipv6 examples are all the _same address_. This is _horrible_.
Try `ping 16909060` some day :-)
Try `ping 16909060` some day :-)
I used it to get around proxies back in the 2000s
What is confusing about that? That's like complaining that you can write an IPv4 address as 001.002.003.004 or 1.2.3.4. Even the :: isn't much different from being able to write 127.0.0.1 as 127.1 (except it now becomes explicit that you've elided the zeroes).
While it's possible to write an ipv4 address in a bunch of different ways (it's just a number, right?) nobody does it because ipv4 standard notation is easy to remember. Ipv6 is not, and none of these attempts to simplify it really work because they change the "format". I understand it and you understand it, but the point here is that it's unfriendly to anyone who isn't familiar with it.
These are all the same address too:
1.2.3.4, 16909060, 0x1020304, 0100401404, 1.131844, 1.0x20304, 1.0401404, 1.2.772, 1.2.0x304, 1.2.01404, 1.2.3.0x4, 1.2.0x3.4, 1.2.0x3.0x4, 1.0x2.772, 1.0x2.0x304, 1.0x2.01404, 1.0x2.3.4, 1.0x2.3.0x4, 1.0x2.0x3.4, 1.0x2.0x3.0x4, 0x1.131844, 0x1.0x20304, 0x1.0401404, 0x1.2.772, 0x1.2.0x304, 0x1.2.01404, 0x1.2.3.4, 0x1.2.3.0x4, 0x1.2.0x3.4, 0x1.2.0x3.0x4, 0x1.0x2.772, 0x1.0x2.0x304, 0x1.0x2.01404, 0x1.0x2.3.4, 0x1.0x2.3.0x4, 0x1.0x2.0x3.4, 0x1.0x2.0x3.0x4
v6 has optional leading zeros and ":: splits the address in two where it appears". v4 has field merging, three different number bases, and it has optional leading zeros too but they turn the field into octal!
v6 has optional leading zeros and ":: splits the address in two where it appears". v4 has field merging, three different number bases, and it has optional leading zeros too but they turn the field into octal!
"Why are you breaking shit for ideological reasons? What was broken? What new amazing thing can I do after this?"
LOL. Yup. What can I do after this? The answer is basically "nothing really" or "maybe go find some other internet connection that also has IPv6 and directly connect to one of my computers inside the network (which would have been firewalled I'd hope so I'd, what, have to punch open a hole in the firewall so my random internet connection's IPv6 can have access to the box? how does that work? I could have just VPN'd in with the IPv4 world).
Seriously though, how do I "cherry pick hole punch" random hotel internet connections? It's moot anyway because no hotel on earth is dishing out publicly accessable IPv6 addresses to guests....
LOL. Yup. What can I do after this? The answer is basically "nothing really" or "maybe go find some other internet connection that also has IPv6 and directly connect to one of my computers inside the network (which would have been firewalled I'd hope so I'd, what, have to punch open a hole in the firewall so my random internet connection's IPv6 can have access to the box? how does that work? I could have just VPN'd in with the IPv4 world).
Seriously though, how do I "cherry pick hole punch" random hotel internet connections? It's moot anyway because no hotel on earth is dishing out publicly accessable IPv6 addresses to guests....
[deleted]
The main thing is keeping current addresses, not having both an ipv4 and ipv6 address.
Just like for an apartment you append something like 5B. And for a house you don't need that.
Just like for an apartment you append something like 5B. And for a house you don't need that.
[deleted]
Hardware support for ipv6 hasn't been the limiting factor in a long time. Users higher on the stack don't want to adopt something that makes so many unnecessary changes.
You’re focusing on the technical difficulty of implementing it in software. This is not the problem. IPv6 support is now present in almost every product, but people still refuse to set it up because it’s so different to what they’re used to (I’m not arguing whether the changes are good - they’re just changes). IPv4+ would’ve solved this social problem.
There’s absolutely, utterly zero chance IPv4+ would be adopted. CGNAT is the solution to the social problem.
I don’t even buy your way of thinking - unlike an “engineering” solution or an “incentives” solution, the problem with “social solutions I speculate about” is: they offer nothing until implemented. They are literally all the same, no difference between the whole world of social solutions, until they are adopted. They are meaningless. They’re the opposite of plans.
Like what’s the difference between IPv4+, which doesn’t exist, and “lets pass a law that mandates ipv6 support”? Nothing. This is what the mockery of “just pass a law” is about. I don’t like those guys, but they are right: it’s meaningless.
I don’t even buy your way of thinking - unlike an “engineering” solution or an “incentives” solution, the problem with “social solutions I speculate about” is: they offer nothing until implemented. They are literally all the same, no difference between the whole world of social solutions, until they are adopted. They are meaningless. They’re the opposite of plans.
Like what’s the difference between IPv4+, which doesn’t exist, and “lets pass a law that mandates ipv6 support”? Nothing. This is what the mockery of “just pass a law” is about. I don’t like those guys, but they are right: it’s meaningless.
This is a good point. The same “why should I migrate” would affect it. However, it being so close to the predecessor, it would be much easier to do so, catching way more people who are on the fence.
The IPv4+ could pass through a router that doesn't know about it - the cloud host that receives that packet could interpret it in a special way, in fact you could stuff additional data into the next layer of the stack for routing - it's not like many services beyond TCP would need to support the scheme.
> The IPv4+ could pass through a router that doesn't know about it
It couldn't do that reliably. We don't have any flags left for that that. Options are not safe. We've got one reserved flag which is anyways set to 0, so that's not safe either.
It couldn't do that reliably. We don't have any flags left for that that. Options are not safe. We've got one reserved flag which is anyways set to 0, so that's not safe either.
> We don't have any flags left for that that.
There's the reserved bit (aka the evil bit[1]). Are you saying gear out there drops packets with reserved bit set to 1? Wouldn't surprise me, just curious.
Seems like IPv4+ would have been a good time to use that bit. Any IPv4+ packets could have more flags in the + portion of the header, if needed.
[1]: https://en.wikipedia.org/wiki/Evil_bit
There's the reserved bit (aka the evil bit[1]). Are you saying gear out there drops packets with reserved bit set to 1? Wouldn't surprise me, just curious.
Seems like IPv4+ would have been a good time to use that bit. Any IPv4+ packets could have more flags in the + portion of the header, if needed.
[1]: https://en.wikipedia.org/wiki/Evil_bit
That bit is currently defined as "Bit 0: reserved, must be zero", so there will be network gear out there, that either drops the packet otherwise or resets the bit to 0 when forwarding.
That makes it effectively impossible to ever use then, so a waste of a bit. Too bad they made that mistake when writing the spec. Would have been better if they specified it like most APIs, ie ignore if you get it, carry it if you forward, and set it to zero if you send it.
It depends what you want to achieve. If we had some feature which is actually incompatible and needed everything else to set it to 0, then it would be perfect. It's not a mistake when you don't predict the future.
This whole discussion reminds me of the beautiful design of UTF-8. They used the lower bits to be ASCII which made backwards compatibility so much easier. It also reminds me of the failure of Intels Itanium and the success of AMD x64. Engineers often want to abandon backwards compatibility to make a new "beautiful" design, but it's the design that has full backwards compatibility that's actual impressive.
It reminds me of python 3. Basically, a huge chunk of people (in my case, scientific programming) get an enormous mess and nothing at all of value until... 3.6 maybe (the infix matrix mult operator). Stunningly, people weren't enthused about this deal.
So well said! Those are great comparisons.
It would maybe be okay at the router to break some things, but ffs even in software I have to choose? Why do I need both ping and ping6 this is stupid!! They really screwed up by making it a breaking change to the OS and not just internet routing.
They didn't screw up. They made it a breaking change to OSs because it had to be a breaking change to OSs. If anyone screwed up here, it was the people who made v4, not the ones that made v6.
For ping, I think it originally had different binaries because ICMPv4 and ICMPv6 are different protocols, but Linux has had a dual-stack `ping` binary for a very long time now. You can just use `ping` for either address family.
For ping, I think it originally had different binaries because ICMPv4 and ICMPv6 are different protocols, but Linux has had a dual-stack `ping` binary for a very long time now. You can just use `ping` for either address family.
The whole ping vs ping6 seems more likely than lazy developers.
The only solution is a gov't mandate. China went from almost no adoption to leading the world in adoption (77% of all Chinese internet users) in a few years because they explicitly prioritized it in their last 5-year-plan.
The ISPs aren't gonna do it on their own.
The ISPs aren't gonna do it on their own.
US government has finally learnt from how vendors break the mandates and there's now IPv6 mandate if you want to sell to federal government, and waivers are only available for buyers not vendors, and individually every time.
I wouldn't say "failure". There are many, many IPv6 client devices out there, mostly on mobile networks. And it works great and they do well and the tools all support it very well.
But IPv4 will never, ever die. The rise of NAT as a pervasive security paradigm[1] basically neuters the one true advantage IPv6 brought to the table by hiding every client environment behind a single address, and the rise of "cloud everything" means that no one cares enough about reaching peer devices anyway. Just this morning my son asked me to share a playlist, so of course I just send him a link to a YouTube Music URL. Want to work on a spreadsheet for family finances with your spouse in the next room? It lives in a datacenter in The Dalles.
[1] And yes, we absolutely rely as a collective society on all our local devices being hidden. Yes, I understand how it works, and how firewalls could do this with globally writable addresses too, yada yada. But in practice NAT is best. It just is.
But IPv4 will never, ever die. The rise of NAT as a pervasive security paradigm[1] basically neuters the one true advantage IPv6 brought to the table by hiding every client environment behind a single address, and the rise of "cloud everything" means that no one cares enough about reaching peer devices anyway. Just this morning my son asked me to share a playlist, so of course I just send him a link to a YouTube Music URL. Want to work on a spreadsheet for family finances with your spouse in the next room? It lives in a datacenter in The Dalles.
[1] And yes, we absolutely rely as a collective society on all our local devices being hidden. Yes, I understand how it works, and how firewalls could do this with globally writable addresses too, yada yada. But in practice NAT is best. It just is.
> I wouldn't say "failure". There are many, many IPv6 client devices out there, mostly on mobile networks.
Honestly it's a huge success due to this fact alone.
IPv6 is failure only if you measure success by replacing IPv4 or if you called "time" on it before the big mobile providers rolled it out. The fact that all mobile phones support it and many mobile networks exclusively deploy it tells you what you really need to know.
IPv6 is a backbone of the modern Internet for clients, even if your servers don't have to care about it due to nat64.
Honestly it's a huge success due to this fact alone.
IPv6 is failure only if you measure success by replacing IPv4 or if you called "time" on it before the big mobile providers rolled it out. The fact that all mobile phones support it and many mobile networks exclusively deploy it tells you what you really need to know.
IPv6 is a backbone of the modern Internet for clients, even if your servers don't have to care about it due to nat64.
The IETF explicitly says the goal of IPv6 is to replace IPv4, not to run alongside it. We're very far from that goal. https://datatracker.ietf.org/doc/html/rfc8200#page-4
Yep, just call it IPv8 and make it double the length of IPv4.
Ultimately, an address system that replaces “1.1.1.1” with “JEDBSO:7372B6D6A:727:8:72829:762927” or whatever just isn’t viable.
Even AWS doesn’t let you use IPv6 with anything… and they charge you for using IPv4 now.
Ultimately, an address system that replaces “1.1.1.1” with “JEDBSO:7372B6D6A:727:8:72829:762927” or whatever just isn’t viable.
Even AWS doesn’t let you use IPv6 with anything… and they charge you for using IPv4 now.
I toyed with using ipv6 in my local network just to learn it and what a headache that was. Ultimately not worth the hassle. I can remember most of the important device ipv4 on my network, I can't say the same for v6.
because you dont need to. Thats what (m)DNS is for.
AWS supports IPv6 on a number their services now: https://aws.amazon.com/vpc/ipv6/
For example there are options to use their hosted memcache/redis service IPv6-only: https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/netw...
Shocking it took them so long but, hey, it's there now.
Shocking it took them so long but, hey, it's there now.
This is the first time I've heard this critique. I think most people don't care if their IP address is easily human readable/memorizable. In my experience when people do deal with ipv4/v6 addresses directly, they just copy-paste.
Man, readability of IP numbers is a important thing. You are not always in a situation where you can simply copy the address.
I can tell you what is what simply from the Ipv4 address, but when its IPv6, my dyslexia is going to kick my behind.
Readability reduces errors, and IPv6 is extreme unreadable. And we have not talked yet about pre-fix, post-fix, that range :: indicator, ... Reading a Ipv6 network stack is just head pain inducing, where as Ipv4 is not always fun but way more readable.
They where able to just extend IPv4 with a extra range, like 1.192.120.121.122, 2.... and you have another 255 Ipv's ... They did the same thing for the Belgium number plates (1-abc-001) and they will run out in the year 11990 somewhere lol...
The problem is, that Ipv6 is over engineered, and had no proper transition from Ipv4 > Ipv6 build in, and that is why 30 years later, we are still dealing with the fallout.
I can tell you what is what simply from the Ipv4 address, but when its IPv6, my dyslexia is going to kick my behind.
Readability reduces errors, and IPv6 is extreme unreadable. And we have not talked yet about pre-fix, post-fix, that range :: indicator, ... Reading a Ipv6 network stack is just head pain inducing, where as Ipv4 is not always fun but way more readable.
They where able to just extend IPv4 with a extra range, like 1.192.120.121.122, 2.... and you have another 255 Ipv's ... They did the same thing for the Belgium number plates (1-abc-001) and they will run out in the year 11990 somewhere lol...
The problem is, that Ipv6 is over engineered, and had no proper transition from Ipv4 > Ipv6 build in, and that is why 30 years later, we are still dealing with the fallout.
Genuinely speaking, that sounds like a process issue if you really can't copy/paste. Perhaps you don't have control over whichever scenario you're talking about but not describing, but data entry is famously error prone regardless of it being 12 characters or 32, and if you're trying to focus on reliability, avoiding errors, you should be avoiding it at all costs.
Sure most people don't care, just the ones who have to figure out why it's not working, and man does it suck for them.
I can keep a v4 in my head, briefly. v6 not so much. Or shout one across a room to someone.
Of course that’s due to the relatively small amount of information it contains and having a larger address space is always going to break that.
Of course that’s due to the relatively small amount of information it contains and having a larger address space is always going to break that.
Do you live under a rock? The memorability of ipv4 was one of the major issues brought up from the very beginning.
Circa 1999 I was working for Cisco as a sysadmin. I got my CCNP through internal training and considered making a career of network administration, but ipv6 changed my mind. It seemed so much more difficult and unpleasant to deal with. I didn't want that to be my day to day work.
I think the same thing happens on a different scale with ISPs. They don't want to deal with it until they have to for largely the same reason.
I think the same thing happens on a different scale with ISPs. They don't want to deal with it until they have to for largely the same reason.
> It seemed so much more difficult and unpleasant to deal with.
In my experience it’s much easier and much more pleasant do deal with. Every VLAN is a /64 exactly. Subnetting? Just increment on a nibble boundary. Every character can be split 16 ways. It’s trivial.
You don’t even need to use a subnet calculator for v6, because you can literally do that in your head.
Network of 2a06:a003:1234:5678::555a:bcd7/64? Easy - the first 4 octets.
Network of 10.254.158.58/27? Your cheapest shotgun and one shell please.
In my experience it’s much easier and much more pleasant do deal with. Every VLAN is a /64 exactly. Subnetting? Just increment on a nibble boundary. Every character can be split 16 ways. It’s trivial.
You don’t even need to use a subnet calculator for v6, because you can literally do that in your head.
Network of 2a06:a003:1234:5678::555a:bcd7/64? Easy - the first 4 octets.
Network of 10.254.158.58/27? Your cheapest shotgun and one shell please.
"Hey Bob, what network is that machine on?"
"Easy,2a06:a003:1234:5678"
"2806:8003: and then what, I forgot the rest?"
"Easy,2a06:a003:1234:5678"
"2806:8003: and then what, I forgot the rest?"
If you want you can check free app to calculate it -> https://alertsleep.com/tools/subnet-calculator
remembering 10.254.158.58. Easy - the first 4 octets.
remembering 2a06:a003:1234:5678::555a:bcd7/64. Your cheapest shotgun and one shell please.
remembering 2a06:a003:1234:5678::555a:bcd7/64. Your cheapest shotgun and one shell please.
If you have a /48 assigned, you’ll burn the prefix in your brain. Leaves 16 bits for the network address.
e.g. you’ll get 2a06:a003:1234::/48 from the ISP - what you’ll really need to remember is the 2a06:a003:1234:xxxx::/64 part. And I use the VLAN id for the xxxx part. Trivial.
e.g. you’ll get 2a06:a003:1234::/48 from the ISP - what you’ll really need to remember is the 2a06:a003:1234:xxxx::/64 part. And I use the VLAN id for the xxxx part. Trivial.
and xx is birtday ?
At first I though so too but IPv6 is actually easier. instead of CIDR you always have 64 bits for network and 64 for host. You get a public /48 IPv6 prefix that allows for 16 bits of subnets and then the host addresses can just start at 1 if you really want. So addresses can be prefix_1_1 if you want. And the prefix is easy to memorize since it never changes.
I DO think using 64 bits for hosts was stupid but oh well.
I DO think using 64 bits for hosts was stupid but oh well.
That seems oddly rigid though. I need to known in advance which networks will definitely never need subnetting so I can assign them a /64.
Why have so, so many address bits and then give us so few for subnetting? People shame ISPs endlessly for only giving out /56s instead of /48s, pointing at the RFCs and such. But we still have 64 entire bits left over there on the right! For what? SLAAC? Was DHCP being stateful really such a huge problem that it deserves sacrificing half of our address bits?
Why have so, so many address bits and then give us so few for subnetting? People shame ISPs endlessly for only giving out /56s instead of /48s, pointing at the RFCs and such. But we still have 64 entire bits left over there on the right! For what? SLAAC? Was DHCP being stateful really such a huge problem that it deserves sacrificing half of our address bits?
> That seems oddly rigid though.
We're past that for a decade, but various services have not caught up yet https://datatracker.ietf.org/doc/html/rfc6177
We're past that for a decade, but various services have not caught up yet https://datatracker.ietf.org/doc/html/rfc6177
The actual intention has always been that there be no hard-
coded boundaries within addresses, and that Classless Inter-
Domain Routing (CIDR) continues to apply to all bits of the
routing prefixes.> I DO think using 64 bits for hosts was stupid but oh well.
Hey man, if I want to assign an address for each individual transistor in my system, that's my business.
Hey man, if I want to assign an address for each individual transistor in my system, that's my business.
Or do funny things like encode RGB values https://hackaday.com/2018/12/24/ipv6-christmas-display-uses-...
I actually think it would have had a better chance of success if ipv6 had embraced the breaking changes to add some killer feature that would have made it worthwhile to upgrade even for entities who didn't need to worry about running out of ipv4 addresses.
I'm not sure what that feature would be though.
I'm not sure what that feature would be though.
This is actually unwanted in a dual-stack world. Once you have divergent behaviors on your networks, you have a complex/weakened security model.
Networking should be boring.
Networking should be boring.
IPv6's failure was mostly caused by the IETF's ivory tower dwellers, who seem to generally have no practical experience or understanding whatsoever of how networks are actually built and run today, especially at the small to mid scale.
Small site multihoming, for example, is an absolute disaster. Good luck if you're trying to add a cellular backup to your residential DSL connection.
IETF says you should either have multiple routers advertising multiple provider-assigned prefixes (a manageability nightmare), or that you should run BGP with provider independent address space; have fun getting your residential ISP or cellular carrier onboard with this idea.
Small site multihoming, for example, is an absolute disaster. Good luck if you're trying to add a cellular backup to your residential DSL connection.
IETF says you should either have multiple routers advertising multiple provider-assigned prefixes (a manageability nightmare), or that you should run BGP with provider independent address space; have fun getting your residential ISP or cellular carrier onboard with this idea.
IETF has a history of being hostile to network operators. I mean actual network operators - not the people who show up at conferences or work the mailing list who just happen to get a paycheck from a company that runs a network (and have zero production access / not on call / not directly involved in running shit). It's gotten better in the last few years in certain areas (and credit to the people who have been willing to fight the good fight). But it's very much a painful experience where you see good ideas shot down and tons of people who want to put their fingerprint on drafts/proposals - it's still a very vendor heavy environment.
Even the vendor representatives are mostly getting paid to post on mailing lists and show up at conferences.
They're not building products, and they're not supporting, visiting or even talking to their customers. Design-by-committee is a full time job that people actually building things for a living tend to not have time for.
They're not building products, and they're not supporting, visiting or even talking to their customers. Design-by-committee is a full time job that people actually building things for a living tend to not have time for.
IPv6 was a total failure of imagination.
The fact is that already in 1993 routing tables were just too big, and the fact is that having a "flat" address space was always going to mean huge routing tables, and the fact is that because IPv6 is still "flat" routing tables only got larger.
The fix would have been to have a subset of the address space that is routed as usual for bootstrapping ex-router address->AS number mapping, and then do all other routing on the basis of AS numbers _only_. This would have allowed us to move prefix->AS number mappings into.. well, DNS or something like it (DNS sucks for prefix mapping, but it could have been extended to not suck for prefix mapping), and all routing would be done based on AS numbers, making routing tables in routers _very small_ by comparison to now. Border routers could then have had tiny amounts of RAM and worked just fine. The IP packets could have borne AS numbers in addition to IP addresses, and all the routers in the middle would use only the AS numbers, and all the routers at the destination AS would know the routes to the destination IPs.
But, no. Great missed chance.
Well, we still could do this with IPv6, but it would be a lot of heavy lifting now.
EDIT: Ah, I see draft-savola-multi6-asn-pi existed.
EDIT: Ah, see also LISP [https://www.rfc-editor.org/rfc/rfc6830]. But LISP is essentially dead.
The fact is that already in 1993 routing tables were just too big, and the fact is that having a "flat" address space was always going to mean huge routing tables, and the fact is that because IPv6 is still "flat" routing tables only got larger.
The fix would have been to have a subset of the address space that is routed as usual for bootstrapping ex-router address->AS number mapping, and then do all other routing on the basis of AS numbers _only_. This would have allowed us to move prefix->AS number mappings into.. well, DNS or something like it (DNS sucks for prefix mapping, but it could have been extended to not suck for prefix mapping), and all routing would be done based on AS numbers, making routing tables in routers _very small_ by comparison to now. Border routers could then have had tiny amounts of RAM and worked just fine. The IP packets could have borne AS numbers in addition to IP addresses, and all the routers in the middle would use only the AS numbers, and all the routers at the destination AS would know the routes to the destination IPs.
But, no. Great missed chance.
Well, we still could do this with IPv6, but it would be a lot of heavy lifting now.
EDIT: Ah, I see draft-savola-multi6-asn-pi existed.
EDIT: Ah, see also LISP [https://www.rfc-editor.org/rfc/rfc6830]. But LISP is essentially dead.
> a cellular backup to your residential DSL connection
Hmm, what's the problem? I suppose your home devices should never be exposed to the public internet, and should only be accessible via a VPN like Wireguard. NAT64 is a thing if your home network is IPv4.
BTW what's the trouble with multi-homing? Can't an interface have two separate IPv6 addresses configured on it, the same way as IPv4 addresses?
Hmm, what's the problem? I suppose your home devices should never be exposed to the public internet, and should only be accessible via a VPN like Wireguard. NAT64 is a thing if your home network is IPv4.
BTW what's the trouble with multi-homing? Can't an interface have two separate IPv6 addresses configured on it, the same way as IPv4 addresses?
> BTW what's the trouble with multi-homing? Can't an interface have two separate IPv6 addresses configured on it, the same way as IPv4 addresses?
Yes, an interface can hsve two separate IPv6 addresses, but that doesn't make it easy.
If you do the easy and obvious thing of setting up two routers to advertise their prefix with your preferred priority when they're available (and advertise it as unavailable when they're not), your devices are likely to configure themselves for addresses on both prefixes, which is great.
Then when you open a new tcp connection (for example), they'll pick a source address more or less randomly... There's a RFC suggestion to select the source address with the largest matching prefix with the destination address, which is useful if the prefix is pretty long, but not so useful when the prefix is 2001:: vs 2602::
Anyway, once the source address is selected, the machine will send the packet to whichever router most recently sent an announcement. Priorities only count among prefixes in the same announcement. If you manage to get a connection established, future packets will use the same source address, but will be sent as appropriate for the most recently received advertisement.
This is pretty much useless, if you want it to work well, you're better off with NAT66 and a smart NAT box.
Yes, an interface can hsve two separate IPv6 addresses, but that doesn't make it easy.
If you do the easy and obvious thing of setting up two routers to advertise their prefix with your preferred priority when they're available (and advertise it as unavailable when they're not), your devices are likely to configure themselves for addresses on both prefixes, which is great.
Then when you open a new tcp connection (for example), they'll pick a source address more or less randomly... There's a RFC suggestion to select the source address with the largest matching prefix with the destination address, which is useful if the prefix is pretty long, but not so useful when the prefix is 2001:: vs 2602::
Anyway, once the source address is selected, the machine will send the packet to whichever router most recently sent an announcement. Priorities only count among prefixes in the same announcement. If you manage to get a connection established, future packets will use the same source address, but will be sent as appropriate for the most recently received advertisement.
This is pretty much useless, if you want it to work well, you're better off with NAT66 and a smart NAT box.
This so, and this is the same if you use IPv4. IPv6 does not bring any regression here; sadly, no progress either. If you have a server that listens to requests though, such as an HTTP server, I don't see how this setup would be grossly inadequate for the purpose.
I would experiment with advertising two default routes, one with a significantly higher metric than the other. Most / all outgoing traffic would go through one link then. If you want to optimally load both uplinks, you likely need a more intelligent (reverse) load balancer.
I would experiment with advertising two default routes, one with a significantly higher metric than the other. Most / all outgoing traffic would go through one link then. If you want to optimally load both uplinks, you likely need a more intelligent (reverse) load balancer.
> If you have a server that listens to requests though, such as an HTTP server, I don't see how this setup would be grossly inadequate for the purpose.
That's the problem. It sounds like it would work if you do this. The documentation suggests multi homing like this would work. When your server gets a request, it sends back the response from the address it received on... but the problem is what router it sends to; when it sends to the correct router, everything is good, when it sends to the wrong router, that router's ISP should drop the packets, because they come from a prefix they don't know about.
> I would experiment with advertising two default routes, one with a significantly higher metric than the other.
Sounds like it would work, but as far as I've found, the priority metric only works if the prefixes are in the same advertisement. If each router advertises its own prefix, the actual metric used is most recent advertisement wins as default route.
That's the problem. It sounds like it would work if you do this. The documentation suggests multi homing like this would work. When your server gets a request, it sends back the response from the address it received on... but the problem is what router it sends to; when it sends to the correct router, everything is good, when it sends to the wrong router, that router's ISP should drop the packets, because they come from a prefix they don't know about.
> I would experiment with advertising two default routes, one with a significantly higher metric than the other.
Sounds like it would work, but as far as I've found, the priority metric only works if the prefixes are in the same advertisement. If each router advertises its own prefix, the actual metric used is most recent advertisement wins as default route.
Thanks for the details. Sounds more like OS level support being crap to me. The OS could and should maintain IPv6 preference tables.
As I recall, I tried Windows, Linux, and FreeBSD and it was circa 2020. 25 years in, bad OS support for a supposed feature means the feature doesn't work.
> BTW what's the trouble with multi-homing? Can't an interface have two separate IPv6 addresses configured on it, the same way as IPv4 addresses?
Because it breaks your network when that router goes away. Your switch ACLs, firewall rules, and DNS records all become invalid because they contain addresses that no longer exist, that your devices continue trying to reach anyway.
Because it breaks your network when that router goes away. Your switch ACLs, firewall rules, and DNS records all become invalid because they contain addresses that no longer exist, that your devices continue trying to reach anyway.
Had to move away from pfSense due to this. It just wasn't possible to stop it giving my devices its public IP as DNS.
So every time I got a new prefix, machines would lose connectivity, usually until I rebooted them.
Switched to OpenWRT which respected my ULA.
So every time I got a new prefix, machines would lose connectivity, usually until I rebooted them.
Switched to OpenWRT which respected my ULA.
Ah, I understand what you likely mean saying "small site multihoming": not a Web site (where it would be trivial), but e.g. a small office.
But with multi-homing you would need to actively test which of your uplinks has Internet access anyway, won't you? And you would have to react somehow when one of your uplinks goes down.
It's easiest to do by abstracting your site away. Make it use a LAN, and do port-forwarding and proxying through a box that knows about the multiple uplinks, and handles the switch-over when one of them goes down. I don't see how it might be easier with IPv4 than with IPv6.
I still assume that you don't want the internals of your office network directly accessible via the public Internet, even when you easily can; VPNs exist for a reason.
But with multi-homing you would need to actively test which of your uplinks has Internet access anyway, won't you? And you would have to react somehow when one of your uplinks goes down.
It's easiest to do by abstracting your site away. Make it use a LAN, and do port-forwarding and proxying through a box that knows about the multiple uplinks, and handles the switch-over when one of them goes down. I don't see how it might be easier with IPv4 than with IPv6.
I still assume that you don't want the internals of your office network directly accessible via the public Internet, even when you easily can; VPNs exist for a reason.
In the IPv4 world, it's easy. Just use NAT, and forward everything over your preferred bearer. Have your router ping 8.8.8.8 or something periodically from that WAN interface to verify reachability. If your preferred link goes down, make your backup link the primary route, clear your NAT translation table, and your local devices remain mostly oblivious that anything happened.
> It's easiest to do by abstracting your site away. Make it use a LAN, and do port-forwarding and proxying through a box that knows about the multiple uplinks, and handles the switch-over when one of them goes down. I don't see how it might be easier with IPv4 than with IPv6.
In the IPv6 world, this is pretty much what you have to do. A whole lot of extra complexity and expense that you didn't have previously.
> It's easiest to do by abstracting your site away. Make it use a LAN, and do port-forwarding and proxying through a box that knows about the multiple uplinks, and handles the switch-over when one of them goes down. I don't see how it might be easier with IPv4 than with IPv6.
In the IPv6 world, this is pretty much what you have to do. A whole lot of extra complexity and expense that you didn't have previously.
Extra complexity and expense? You're describing basically the same thing they are. A router that does NAT and decides which link to send the packets over based on connection testing.
And IPv6 has the benefit of a significantly simpler 1:1 NAT.
And IPv6 has the benefit of a significantly simpler 1:1 NAT.
NPTv6 is rarely used, and so its real world implementations tend to be poorly tested and buggy.
The answer in this case ends up being solutions like explicit web proxies, or alternatively a VPN concentrator or the like from which you can receive a routable prefix delegation, and then run multiple tunnels to satisfy your own availability or policy routing needs. Either way, you’re building some complex infrastructure to overcome regressions imposed upon you at layer 3.
The answer in this case ends up being solutions like explicit web proxies, or alternatively a VPN concentrator or the like from which you can receive a routable prefix delegation, and then run multiple tunnels to satisfy your own availability or policy routing needs. Either way, you’re building some complex infrastructure to overcome regressions imposed upon you at layer 3.
You should be using dynamic DNS and firewall rules should be on the subnet boundary in this scenario, any decent firewall (including referee PFsense/OpnSense) support ACLs that follow IPv6 address changes.
> You should be using dynamic DNS
That doesn't solve the problem. DNS remains broken until each and every device, assuming VERY generously that it is capable of dynamic DNS at all, realises that one of its prefixes has disappeared and it updates its DNS records. With DNS TTL and common default timeouts for prefix lifetime and router lifetime, that can take anywhere from 30 minutes to 30 days.
> and firewall rules should be on the subnet boundary in this scenario, any decent firewall (including referee PFsense/OpnSense) support ACLs that follow IPv6 address changes.
This requires you to assign one VLAN per device, unless perhaps you've got lots of money, space, and power to buy high end switches that can do EVPN-VXLAN so that you can map MAC addresses to SGTs and filter on those instead.
That doesn't solve the problem. DNS remains broken until each and every device, assuming VERY generously that it is capable of dynamic DNS at all, realises that one of its prefixes has disappeared and it updates its DNS records. With DNS TTL and common default timeouts for prefix lifetime and router lifetime, that can take anywhere from 30 minutes to 30 days.
> and firewall rules should be on the subnet boundary in this scenario, any decent firewall (including referee PFsense/OpnSense) support ACLs that follow IPv6 address changes.
This requires you to assign one VLAN per device, unless perhaps you've got lots of money, space, and power to buy high end switches that can do EVPN-VXLAN so that you can map MAC addresses to SGTs and filter on those instead.
> each and every device ... updates its DNS records.
What device on your office LAN should maintain its own DNS records? Advertise your own caching DNS server over DHCP(6), give its responses a short TTL (10 sec), make it expire the relevant entries, or the whole cache, when one of your links goes down. I suppose dnsmasq should handle this easily.
It seems that the discussion turned away from a multi-homed setup (pooling the bandwidths of two normally reliable links) to an HA/failover setup (with two unreliable links, each regularly down).
What device on your office LAN should maintain its own DNS records? Advertise your own caching DNS server over DHCP(6), give its responses a short TTL (10 sec), make it expire the relevant entries, or the whole cache, when one of your links goes down. I suppose dnsmasq should handle this easily.
It seems that the discussion turned away from a multi-homed setup (pooling the bandwidths of two normally reliable links) to an HA/failover setup (with two unreliable links, each regularly down).
Every device.
It either needs to be able to update DNS by itself (a la Active Directory), or it needs to be able to give the DHCP server a sensible hostname in order for DHCP to make this update on its behalf, which most IoT devices cannot.
It either needs to be able to update DNS by itself (a la Active Directory), or it needs to be able to give the DHCP server a sensible hostname in order for DHCP to make this update on its behalf, which most IoT devices cannot.
The amount of ignorance in these ipv6 posts is astounding (seems to be one every two months). It isn't hard at all, I'm just a homelabber and I have a dual-stack setup for WAN access (HE Tunnel is set up on the router since Bell [my isp] still doesn't give ipv6 address/prefixes to non-mobile users), but my OpenStack and ceph clusters are all ipv6 only, it's easy peasy. Plus subnetting is a heck of a lot less annoying that with ipv4, not that that was difficult either.
“it’s easy peasy” says guy who demonstrably already knows and has time to learn a bunch of shit 99.9% of people don’t have the background or inclination to.
People like you talking about IPv6 have the same vibe as someone bewildered by the fact that 99.9% of people can’t explain even the most basic equation of differential or integral calculus. That bewilderment is ignorance.
People like you talking about IPv6 have the same vibe as someone bewildered by the fact that 99.9% of people can’t explain even the most basic equation of differential or integral calculus. That bewilderment is ignorance.
These people apparently had the time and inclination to learn a bunch of shit about IPv4, though.
"Easy" is meant in that context. The people acting like the IPv4 version is easy.
So your second paragraph doesn't fit the situation at all.
"Easy" is meant in that context. The people acting like the IPv4 version is easy.
So your second paragraph doesn't fit the situation at all.
"The shit about IPv4" was easy to learn and well documented and supported.
"The shit about IPv6" is a mess of approaches that even the biggest fanboys can't agree on and are even less available on equipment used by people in prod.
IPv6 has failed wide adoption in 30 decades, calling it "easy" is outright denying the reality and shows the utter dumb obliviousness of people trying to push it and failing to realize where the issues are.
"The shit about IPv6" is a mess of approaches that even the biggest fanboys can't agree on and are even less available on equipment used by people in prod.
IPv6 has failed wide adoption in 30 decades, calling it "easy" is outright denying the reality and shows the utter dumb obliviousness of people trying to push it and failing to realize where the issues are.
Could you share a list of IPv6 issues that IPv4 does not exhibit? Something that becomes materially harder with IPv6? E.g., "IPv6 addresses are long and unwieldy, hard to write down or remember". What else?
Traffic shapping in v6 is harder than v4. At least it was for me, because NDP messages were going into the shaping queue, but then getting lost since the queue only had a 128 bit address field, and 128 bits isn't actually enough for local addresses. When the traffic shaping allowed traffic immediately, the NDP traffic would be sent, but if it needed to be queued, the adapter index would get lost (or something) and the packets disappeared. So I'd get little bursts of v6 until NDP entries timed out and small queues meant a long time before it would work again.
Not an issue in ipv4 because ARP isn't IPv4 so IP traffic shaping ignores it automatically.
Not an issue in ipv4 because ARP isn't IPv4 so IP traffic shaping ignores it automatically.
Software support is a big one. I ran pfSense. It did not support changing IPv6 prefixes. It still barely does. So something as simple has having reliable IPv6 connectivity and firewall rules with pfSense was impossible just a few years ago for me.
Android doesn't support DHCPv6 so I can't tell it my preferred NTP server, and Android silently ignores your local DNS server if it is advertised with a IPv4 address and the Android device got a IPv6 address.
Without DHCPv6 then dynamic DNS is required for all servers. Even a 56 bit prefix is too much to remember, especially when it changes every week. So then you need to install and configure a dynamic DNS client on all servers in your network.
Android doesn't support DHCPv6 so I can't tell it my preferred NTP server, and Android silently ignores your local DNS server if it is advertised with a IPv4 address and the Android device got a IPv6 address.
Without DHCPv6 then dynamic DNS is required for all servers. Even a 56 bit prefix is too much to remember, especially when it changes every week. So then you need to install and configure a dynamic DNS client on all servers in your network.
"I already know enough to be productive, can the rest of the world please freeze and stop changing?"
This is not even that unreasonable. Sadly, the number of IP devices in the world by now far exceeds the IPv4 address space, and other folks want to do something about that. They hope the world won't freeze but would sort of progress.
This is not even that unreasonable. Sadly, the number of IP devices in the world by now far exceeds the IPv4 address space, and other folks want to do something about that. They hope the world won't freeze but would sort of progress.
Network engineering is a profession requiring specific education. At a high level it’s not different from calculus. You learn certain things and then you learn how to apply them in the real life situations.
It’s not hard for people who get an appropriate education and put some effort into it. Your lack of education is not my ignorance.
It’s not hard for people who get an appropriate education and put some effort into it. Your lack of education is not my ignorance.
Dude.
The difficulty of setting IPv6 up at your house vs. the needs of a multi-homed, geographically diverse enterprise couldn't be more dissimilar.
I'd lay off the judgment a bit.
The difficulty of setting IPv6 up at your house vs. the needs of a multi-homed, geographically diverse enterprise couldn't be more dissimilar.
I'd lay off the judgment a bit.
I'd gladly listen about the difficulties of setting up enterprise networks! No irony; listening to experts is always enlightening.
BTW a homelab often tries to imitate more complex setups, in order to be a learning experience. Can these difficulties be modelled there?
BTW a homelab often tries to imitate more complex setups, in order to be a learning experience. Can these difficulties be modelled there?
company where i work has deployments across the world with few hundreds of thousands of hardware hosts (in datacenters), vms and containers + deployments in a few clouds. also a bunch of random hardware from multitude of vendors. multiple lines for linking datacenters and clouds. also some lines to more specific service providers that we are using.
all of it ipv4 based. ipv6 maybe in distant future somewhere on the edge in case our clients will demand in.
inside our network - probably not going to happen
all of it ipv4 based. ipv6 maybe in distant future somewhere on the edge in case our clients will demand in.
inside our network - probably not going to happen
I find this completely fine. I don't see much (if any) upside in migrating a large existing network to anything new at all, as long as the currently deployed IPv4 is an adequate solution inside it (and it obviously is).
Public-interfacing parts can (and should) support IPv6, but I don't see much trouble exposing your public HTTP servers (and maybe mail servers) using IPv6, because most likely your hosting / cloud providers do 99.9% of it already, out of the box (unless it's AWS, haha), and the rare remaining cases, like, I don't know, a custom VPN gateway, are not such a big deal to handle.
Public-interfacing parts can (and should) support IPv6, but I don't see much trouble exposing your public HTTP servers (and maybe mail servers) using IPv6, because most likely your hosting / cloud providers do 99.9% of it already, out of the box (unless it's AWS, haha), and the rare remaining cases, like, I don't know, a custom VPN gateway, are not such a big deal to handle.
vast majority of our stuff is self hosted. http servers in a way are the least important way for our clients to work with us.
amount of work to support ipv6 on the edge will be very big and none of our clients asked for it as far as i know.
the only time we discussed it, it's when we were getting fedramp certification. because of this https://www.gsa.gov/directives-library/internet-protocol-ver...
amount of work to support ipv6 on the edge will be very big and none of our clients asked for it as far as i know.
the only time we discussed it, it's when we were getting fedramp certification. because of this https://www.gsa.gov/directives-library/internet-protocol-ver...
I ran network team at an organization with hundreds of thousands hardware hosts in tens-of-megawatts large data centers, millions of VMs and containers, links between data centers, links to ISPs and IXes. We ran out of RFC1918 addresses at around 2011-2012 and went IPv6-only. IPv4 is delivered as a service to nodes requiring it via an overlay network. We intentionally simplified network design by doing so.
This is neither hard nor expensive.
This is neither hard nor expensive.
This is one of the only scenarios in which it’s actually easy.
different environments. for us at this point of time it will be expensive without added benefit.
I should have been gentler and less arrogant, yes. Sincerely though, please explain how ipv6 is in anyway more difficult than a properly set up ipv4 enterprise. What tools are not available?
I left my job as a NE/architect over a 15 years ago, but the show stopper back then revolved around how to handle routing with firewalling. Firewalling being biggest roadblock due to needing traffic symmetry. I'm doing my best to remember why we stopped at just providing v6 at the edge for site-specific Internet hosted services and never pushed it further.
Mind you, our team discussed this numerous times over a few years and never came up with a solution that didn't look like it would require us to completely fork-lift what we were doing. The whole team was FOR getting us to v6, so there was no dogmatic opposition.
Consider this:
25k employee company. Four main datacenter hubs spread out across the USA with 200 remote offices evenly dual-homed into any two of the four.
All four of the DCs had multi-ISP Internet access advertising their separate v4 blocks and hosting Internet services. The default-route was redistributed into the IGP from only two locations, site A and B. e.g. two of the four DCs were egress for Internet traffic from the population of users and all non-internet-facing servers. IGP metrics were gently massaged as to fairly equally use of both sites.
All outbound traffic flowed naturally out of the eastern or western sites based on IGP metrics. This afforded us a tertiary failover for outbound traffic in the event that both of the Internet links into one of the two egress sites was down. e.g., if both of site A's links (say, level-3 and att) were down, the route through site A was lost, and all the egress traffic was then routed out site B (and vice-versa). This worked well with ipv4 because we used NAT to masquerade all the internal v4 space as site X's public egress block. Therefore all the return traffic was routed appropriately.
BGP advertisements were either as-path prepended or supernetted (don't remember which) such that if site A went down, site B, C, or D would get its traffic, and tunnel it via GRE to the appropriate DC hub's external segment.
The difficulty was that traffic absolutely had to flow symmetrically because of the firewalls in place, and easily could for v4 because NAT was happening at every edge.
With v6 it just didn't seem like there was any way to achieve the same routing architecture / flexibility, particularly with multi-homing into geographically disparate sites.
I'm not sure anymore where we landed, but I remember it being effectively insurmountable. I don't think it was difficult for Internet-hosted services, but the effort seemed absolutely not worth it for everything on the inside of the network.
Mind you, our team discussed this numerous times over a few years and never came up with a solution that didn't look like it would require us to completely fork-lift what we were doing. The whole team was FOR getting us to v6, so there was no dogmatic opposition.
Consider this:
25k employee company. Four main datacenter hubs spread out across the USA with 200 remote offices evenly dual-homed into any two of the four.
All four of the DCs had multi-ISP Internet access advertising their separate v4 blocks and hosting Internet services. The default-route was redistributed into the IGP from only two locations, site A and B. e.g. two of the four DCs were egress for Internet traffic from the population of users and all non-internet-facing servers. IGP metrics were gently massaged as to fairly equally use of both sites.
All outbound traffic flowed naturally out of the eastern or western sites based on IGP metrics. This afforded us a tertiary failover for outbound traffic in the event that both of the Internet links into one of the two egress sites was down. e.g., if both of site A's links (say, level-3 and att) were down, the route through site A was lost, and all the egress traffic was then routed out site B (and vice-versa). This worked well with ipv4 because we used NAT to masquerade all the internal v4 space as site X's public egress block. Therefore all the return traffic was routed appropriately.
BGP advertisements were either as-path prepended or supernetted (don't remember which) such that if site A went down, site B, C, or D would get its traffic, and tunnel it via GRE to the appropriate DC hub's external segment.
The difficulty was that traffic absolutely had to flow symmetrically because of the firewalls in place, and easily could for v4 because NAT was happening at every edge.
With v6 it just didn't seem like there was any way to achieve the same routing architecture / flexibility, particularly with multi-homing into geographically disparate sites.
I'm not sure anymore where we landed, but I remember it being effectively insurmountable. I don't think it was difficult for Internet-hosted services, but the effort seemed absolutely not worth it for everything on the inside of the network.
I want to send my ssh via my low latency reliable connection, I want to route my streaming via another connection. That’s just a routing rule and srcnat in ipv4
That’s before you go on to using PBR. I want to route traffic with different dscp via different routes.
Ultimately I want the rout g to be handled by the network, not by the client.
IPv4 and nat makes that a breeze.
That’s before you go on to using PBR. I want to route traffic with different dscp via different routes.
Ultimately I want the rout g to be handled by the network, not by the client.
IPv4 and nat makes that a breeze.
How is it not a routing rule with ipv6? Firewalls and routers typically support dynamic prefixes (even Vyos, pfSense, openSense do).
How do I tell my phone that I want to send traffic to server A via isp1 and server B via isp2
On your router?
edit Less flippantly, what are you wanting to base the routing rule on? What's your ipv4 routing rule?
DSCP is allowed in ipv6.
https://www.juniper.net/documentation/us/en/software/junos/c...
edit Less flippantly, what are you wanting to base the routing rule on? What's your ipv4 routing rule?
DSCP is allowed in ipv6.
https://www.juniper.net/documentation/us/en/software/junos/c...
Without nat, my understanding is the right way in v6 is to issue addresses of every network and then send a message to each end device asking it to use a specific ip address to route traffic and hope every client implements RFC 4191 in the right way.
There's a few options I'm aware of.
The "proper" way would be to get your own ASN and use BGP to route the traffic.
If you're wanting to use a secondary WAN link as a backup for when the other goes down you could have the backup link's LAN have a lower priority. (So I guess hope everything implements RFC 4191 like you said).
You can use NAT66/NPTv6 if you want (though it's icky I guess).
How are you doing it currently?
The "proper" way would be to get your own ASN and use BGP to route the traffic.
If you're wanting to use a secondary WAN link as a backup for when the other goes down you could have the backup link's LAN have a lower priority. (So I guess hope everything implements RFC 4191 like you said).
You can use NAT66/NPTv6 if you want (though it's icky I guess).
How are you doing it currently?
Nat 4, it’s trivial. But IPv6 tell me how terrible nat is despite it being the only solution in both the v6 and v4 world.
Sadly my 4g provider will not peer via bgp with me, even if I could provide an AS and Sufficiently large IP range.
I think my home ISP will actually peer with me, but I’d have to tunnel to them over my non-fibre connection, and there’s reduced resilience in that case.
At work that wouldn’t help at all, there are very few providers for many of our branch offices.
So once again ipv6 only works with “icky” nat, or on simple 1990s style connections, and not in the real world of multiple providers. Now sure I can do npt which means I don’t need to keep track of state, but then if I didn’t keep track of state I lose the benefits of a stateful firewall.
As such the only benefits of nat on v6 is that source ports will never need to change even if client 1 and client 2 both send to server 1 port 1234 from source port 5555. This helps with a handful of crappy protocols which embed the layer 4 data (port number) in a layer 6 or 7 protocol.
Sadly my 4g provider will not peer via bgp with me, even if I could provide an AS and Sufficiently large IP range.
I think my home ISP will actually peer with me, but I’d have to tunnel to them over my non-fibre connection, and there’s reduced resilience in that case.
At work that wouldn’t help at all, there are very few providers for many of our branch offices.
So once again ipv6 only works with “icky” nat, or on simple 1990s style connections, and not in the real world of multiple providers. Now sure I can do npt which means I don’t need to keep track of state, but then if I didn’t keep track of state I lose the benefits of a stateful firewall.
As such the only benefits of nat on v6 is that source ports will never need to change even if client 1 and client 2 both send to server 1 port 1234 from source port 5555. This helps with a handful of crappy protocols which embed the layer 4 data (port number) in a layer 6 or 7 protocol.
> any decent firewall (including referee PFsense/OpnSense) support ACLs that follow IPv6 address changes
In the case of pfSense this is a recent change. It was not supported when I migrated away from it less than five years ago.
In the case of pfSense this is a recent change. It was not supported when I migrated away from it less than five years ago.
I've been thinking we could simply extend the ipv4 address to be 11 bytes by (ab)using the options field. That is, add an option that holds more bytes for the source and destination address, which are to be appended to the address already present in the header.
I am thinking that since an option starts with 2 bytes and everything must be padded to a multiple of 4 bytes, we can add 16 bytes to the packet, which would hold 7 extra address bytes per source and destination, giving us 11 byte addresses. ISPs would be given a bunch of 4-byte toplevel addresses and can generate 7-byte suffixes dynamically for their subscribers, in a way that is almost the same as CGNAT used today but without all the problems that has.
Most routers will only need to be updated to pass along the option and otherwise route as normal, because the top level address is already enough to route the packet to the ISP's routers. Then only at the edge will you need to do extra work to route the packet to the host. Not setting the option would be equivalent to setting it to all 0s, so all existing public hosts will be automatically addressable with the new scheme.
There will of course need to be a lot more work done for DNS, DHCP, syntax in programs, etc, but it would be a much easier and more gradual transition than IPv6 is demanding.
I am thinking that since an option starts with 2 bytes and everything must be padded to a multiple of 4 bytes, we can add 16 bytes to the packet, which would hold 7 extra address bytes per source and destination, giving us 11 byte addresses. ISPs would be given a bunch of 4-byte toplevel addresses and can generate 7-byte suffixes dynamically for their subscribers, in a way that is almost the same as CGNAT used today but without all the problems that has.
Most routers will only need to be updated to pass along the option and otherwise route as normal, because the top level address is already enough to route the packet to the ISP's routers. Then only at the edge will you need to do extra work to route the packet to the host. Not setting the option would be equivalent to setting it to all 0s, so all existing public hosts will be automatically addressable with the new scheme.
There will of course need to be a lot more work done for DNS, DHCP, syntax in programs, etc, but it would be a much easier and more gradual transition than IPv6 is demanding.
I don't think so. It would be more confusion because no one will know if a network is ipv4 or ipv4+, leading to edge case bugs and confusion and people will similarly be lazy and choose to only implement ipv4 knowing it will always be reverse compatible and the cost is transferred to the consumer.
Plus, it's only 2048x the address space. It's within the realm of possibility that we will need to upgrade again once this place is swarming with robots.
Plus, it's only 2048x the address space. It's within the realm of possibility that we will need to upgrade again once this place is swarming with robots.
x2048 is a lot though! Maybe we should let the robots figure out their own solution, rather than trying to make every atom on Earth individually addressable :)
ipv6 adoption is still steadily rising. Not as fast as anyone hoped, but at least steadily. There is no way it can be abandoned at this point even if we wanted to.
I wonder if it could still be usurped by another standard that is somehow more popular. If adoption of that leapfrogs over IPV6 then maybe it will have just been a waypoint along the way.
What would a new standard do that would make it more popular? IPv6, for all its faults, is designed to be the last Internet Protocol we will ever need.
In the new standard every publicly routable packet will include a cryptographically signed passport number of the responsible person.
Then the government could, for example, limit criminals' access to the internet by mandating that their packets be dropped on most major ISPs, or at least deprioritised.
Then the government could, for example, limit criminals' access to the internet by mandating that their packets be dropped on most major ISPs, or at least deprioritised.
Funny enough I actually looked at a scheme for corporate networks where your personal corporate ID is encoded as part of the host bits of the IPv6 packet and policy could be applied based on who you are instead of what machine it is (or both). It was kind of neat but the complexity was too high for it to gain traction, and also it turns out that most corporate networks are allergic to IPv6 and government networks doubly so.
It will not. People underestimate the amount of effort went into IPv6 implementations.
This absolutely can and should happen
Stripped of all the other baggage that came with it (e.g. SLAAC, IPsec, etc) IPv6 is an incredibly conservative addressing extension. The only thing even more conservative than v6 would have been to drop the lower 64 bits of the address and the associated EUI-64 local addressing scheme. Which... to be fair, that turned out to be a very bad idea, but the length of the field isn't what was holding up v6 adoption.
I suspect by "incredibly conservative" you mean "backwards compatible", which... no. You can't make an addressing extension backwards compatible with hardware that doesn't read all of the address. Of course, we did that anyway with CGNAT, and predictably it causes huge problems with end-to-end connectivity, which is the whole point of IPv6. You're probably thinking more along the lines of an explicit "extension addressing header" for v4. Problem is, that'd mean a more awkward version of IPv6's /64 address split[0], combined with all sorts of annoying connectivity problems. The same corporate middleboxes that refuse to upgrade to IPv6 also choke on anything that isn't TCP traffic to ports 80 and 443. So you'd need Happy Eyeballs style racing between CGNAT IPv4 and "extended IPv4".
Also, that would just be a worse version of 6in4. Because they also thought of just tunneling IPv6 traffic in IPv4 links. I don't think you understand how incredibly conservative IPv6 actually is.
The problem with "incredibly conservative" IP extensions is that nothing beats the conservatism of doing literally nothing. IT infrastructure is never ripped out and replaced unless there is a business case for doing so. The current problem with IPv6 adoption is that nobody has yet said "let's stop processing IPv4 traffic", they've only said "let's get more dual-stack hosts online", which is a process that only asymptotes to 100% IPv6, and never reaches it.
IPv4 was not the first version of the Internet protocol. That honor goes to Network Control Protocol (NCP). The reason why we don't have an asymptotic long tail of Internet hosts still demanding NCP connectivity is because this was back when "having a connection to the Internet" meant "having a connection to ARPANET". The US military could just refuse to process NCP packets and actively did this to force people onto IPv4. Now imagine if someone big like Google said "we're going to stop accepting IPv4 connections" - people would jump onto v6 immediately.
[0] Let's say we add a 32-bit extension header onto IPv4
I suspect by "incredibly conservative" you mean "backwards compatible", which... no. You can't make an addressing extension backwards compatible with hardware that doesn't read all of the address. Of course, we did that anyway with CGNAT, and predictably it causes huge problems with end-to-end connectivity, which is the whole point of IPv6. You're probably thinking more along the lines of an explicit "extension addressing header" for v4. Problem is, that'd mean a more awkward version of IPv6's /64 address split[0], combined with all sorts of annoying connectivity problems. The same corporate middleboxes that refuse to upgrade to IPv6 also choke on anything that isn't TCP traffic to ports 80 and 443. So you'd need Happy Eyeballs style racing between CGNAT IPv4 and "extended IPv4".
Also, that would just be a worse version of 6in4. Because they also thought of just tunneling IPv6 traffic in IPv4 links. I don't think you understand how incredibly conservative IPv6 actually is.
The problem with "incredibly conservative" IP extensions is that nothing beats the conservatism of doing literally nothing. IT infrastructure is never ripped out and replaced unless there is a business case for doing so. The current problem with IPv6 adoption is that nobody has yet said "let's stop processing IPv4 traffic", they've only said "let's get more dual-stack hosts online", which is a process that only asymptotes to 100% IPv6, and never reaches it.
IPv4 was not the first version of the Internet protocol. That honor goes to Network Control Protocol (NCP). The reason why we don't have an asymptotic long tail of Internet hosts still demanding NCP connectivity is because this was back when "having a connection to the Internet" meant "having a connection to ARPANET". The US military could just refuse to process NCP packets and actively did this to force people onto IPv4. Now imagine if someone big like Google said "we're going to stop accepting IPv4 connections" - people would jump onto v6 immediately.
[0] Let's say we add a 32-bit extension header onto IPv4
"Stripped of all the other baggage that came with it..."
But that baggage is a huge part of the problem. Almost nothing you know about IPv4 applies when you switch to IPv6, and most of us found that out the hard way when we tried to make the switch. Leaves a pretty bad taste in your mouth.
But that baggage is a huge part of the problem. Almost nothing you know about IPv4 applies when you switch to IPv6, and most of us found that out the hard way when we tried to make the switch. Leaves a pretty bad taste in your mouth.
I mean this is just wrong. Routing and switching behave exactly the same in V6 vs V4. Details on how you get an IP and what it looks like changed but there's TONS of knowledge shared between the two.
When I configure a new router at my home, routing is barely a blip on the radar. I mean, everything that's not local goes upstream. Switches just swich, I plug in cables and they work.
The things I need to think about are precisely the things that changed radically. Firewall rules aren't the same due to prefix changes and no NAT. DHCP isn't the same, DNS isn't quite the same, distributing NTP servers isn't the same.
Almost nothing of what I knew about configuring my home router for IPv4 has transferred to IPv6 configuration.
The things I need to think about are precisely the things that changed radically. Firewall rules aren't the same due to prefix changes and no NAT. DHCP isn't the same, DNS isn't quite the same, distributing NTP servers isn't the same.
Almost nothing of what I knew about configuring my home router for IPv4 has transferred to IPv6 configuration.
Yes, the only key difference is that NAT is gone.
Also a nitpick: switching is irrelevant here, that’s L2. L2 doesn’t even know what’s an IP address :)
There was some dude on YouTube that resurrected the first Ethernet bridge (which was built for thicknet) - I recall even that worked with IPv6.
Also a nitpick: switching is irrelevant here, that’s L2. L2 doesn’t even know what’s an IP address :)
There was some dude on YouTube that resurrected the first Ethernet bridge (which was built for thicknet) - I recall even that worked with IPv6.
"Details on how you get an IP and what it looks like changed but..."
This is exactly what I'm talking about. When you have problems with your IP network, that's the first thing you try and figure out, "what's my address? Why is that my address? Did it change? If so, why? Are other devices able to get packets? What are their addresses? Why can those addresses get packets but this address can't?"
This is exactly what I'm talking about. When you have problems with your IP network, that's the first thing you try and figure out, "what's my address? Why is that my address? Did it change? If so, why? Are other devices able to get packets? What are their addresses? Why can those addresses get packets but this address can't?"
> The current problem with IPv6 adoption is that nobody has yet said "let's stop processing IPv4 traffic"
Mobile carriers have done that between consumer devices and network towers. That forced a lot of innovation (including tools like better DNS64 and "happy eyeballs" protocols) and network stack hardening.
The roll out of out CGNAT in some cases is "let's drop IPv4 traffic randomly" and "happy eyeballs" in consumer devices is transparently driving a lot of consumer traffic to IPv6.
This is why mobile and consumer devices are leading the pack on IPv6 adoption.
It's maybe not all of Google that next needs to say "we're going to stop accepting IPv4 traffic", it's maybe more specifically GCP (and AWS and Azure) that need to do that to drive the non-consumer IPv6 push we need. The next best thing would be for all the cloud providers to at least start raising IPv4 address prices until their clients start to feel them.
Mobile carriers have done that between consumer devices and network towers. That forced a lot of innovation (including tools like better DNS64 and "happy eyeballs" protocols) and network stack hardening.
The roll out of out CGNAT in some cases is "let's drop IPv4 traffic randomly" and "happy eyeballs" in consumer devices is transparently driving a lot of consumer traffic to IPv6.
This is why mobile and consumer devices are leading the pack on IPv6 adoption.
It's maybe not all of Google that next needs to say "we're going to stop accepting IPv4 traffic", it's maybe more specifically GCP (and AWS and Azure) that need to do that to drive the non-consumer IPv6 push we need. The next best thing would be for all the cloud providers to at least start raising IPv4 address prices until their clients start to feel them.
> The current problem with IPv6 adoption is that nobody has yet said "let's stop processing IPv4 traffic"…
One of the giant CDNs translates all IPv4 traffic to IPv6 at the edge (stateless NAT46) and is IPv6-only in its core network (for one of its primary product networks; like everybody they have multiple networks.)
One of the giant CDNs translates all IPv4 traffic to IPv6 at the edge (stateless NAT46) and is IPv6-only in its core network (for one of its primary product networks; like everybody they have multiple networks.)
Multiple networks do the same - Both T-Mobile (at least in EU) and Orange no longer actually support v4 other than through funky 464 and by funky I mean really funky at times.
Truth is there are too many devices that only speak IPv4 or have untested IPv6 stack. People still can’t even agree on how ipv6 address is represented.
People have totally agreed on how IPv6 addresses are represented.
I think this is defeatist talk where it’s not warranted. I remember IPX networks in the 90s were still a thing because people believed they could eke out a little more performance for their games. It’s taking a long time to move to IPv6 in some parts of the world. eg: anyone who doesn’t feel the pain of the IPv4 address crunch likely due to having a large chunk to begin with. Many influential organizations in North America definitely fall in that category.
IPv6 is a success IMHO because it is used in so many places. Google’s IPv6 traffic graph shows close to 50% adoption and still trending up. We can’t possibly expect the world to be near 100% overnight… the internet is a big place with the whole spectrum of humans influencing IT; There will always be someone who will cling to IPv4 for dear life.
IPv6 is a success IMHO because it is used in so many places. Google’s IPv6 traffic graph shows close to 50% adoption and still trending up. We can’t possibly expect the world to be near 100% overnight… the internet is a big place with the whole spectrum of humans influencing IT; There will always be someone who will cling to IPv4 for dear life.
> I'm not proposing to abandon ipv6, but at this point I'm really not sure how we proceed here. The status quo is maintaining two separate competing protocols forever, which was not the ultimate intention.
The end game will be a cryptographically large address space allocated based on some cryptographic operation, rather than a committee carving up the space arbitrarily.
Tor already does this, addresses allocation is not a problem. I think they used to use hashes, but now use Ed25519 public keys. Obviously, Tor is not suitable for most tasks. No one should have to pay for the extra latency if they don't need the anonymity.
The real problem is routing in these address spaces, and there have been a few projects like CJDNS which try to solve it.
The end game will be a cryptographically large address space allocated based on some cryptographic operation, rather than a committee carving up the space arbitrarily.
Tor already does this, addresses allocation is not a problem. I think they used to use hashes, but now use Ed25519 public keys. Obviously, Tor is not suitable for most tasks. No one should have to pay for the extra latency if they don't need the anonymity.
The real problem is routing in these address spaces, and there have been a few projects like CJDNS which try to solve it.
Imagine every address along a major road is 3 digits, and some shortsighted post office code assumes 3. Your business is 845 Oak St. One day they say hey, this road is getting too long, let's update that code to support 10 digits and we never worry about this again.
Oh and btw, your address is now 9245593924 Oak St.
Oh and btw, your address is now 9245593924 Oak St.
This feels a lot like the arguing that went on during the transition to Python 3. The Python 2.7 hangers-on were so preoccupied with themselves that they didn't notice that the pool of people interested in having the argument at all was getting smaller and smaller.
Until somebody turned off the lights, that is. It is not much fun arguing with yourself in the dark.
I think that's what needed and needs to be done here. I will agree with the IPv4 advocates on one thing: IPv6 adoption has been slow in part because it doesn't work like IPv4 + kludges. That is the point. Clinging to IPv4 standard practices while you switch is just going to make you miserable.
In 2006, the hesitation to go to IPv6 made sense. Support was spotty. In 2026 it does not. IPv6 support is now more than adequate, and a clean cut will force the stragglers to get their asses in gear in a hurry ("fix your IPv6 support RFN or enjoy nobody using your product"). Change is painful, learning new stuff when you were getting by just fine on the old stuff is painful, I get it. But it will happen whether you like it or not. Why not just get it over with?
I finally made the switch to IPv6 last year, and I wouldn't go back.
The pain of change is real, but mercifully, it doesn't last. Within a year this debate will seem quaint.
Until somebody turned off the lights, that is. It is not much fun arguing with yourself in the dark.
I think that's what needed and needs to be done here. I will agree with the IPv4 advocates on one thing: IPv6 adoption has been slow in part because it doesn't work like IPv4 + kludges. That is the point. Clinging to IPv4 standard practices while you switch is just going to make you miserable.
In 2006, the hesitation to go to IPv6 made sense. Support was spotty. In 2026 it does not. IPv6 support is now more than adequate, and a clean cut will force the stragglers to get their asses in gear in a hurry ("fix your IPv6 support RFN or enjoy nobody using your product"). Change is painful, learning new stuff when you were getting by just fine on the old stuff is painful, I get it. But it will happen whether you like it or not. Why not just get it over with?
I finally made the switch to IPv6 last year, and I wouldn't go back.
The pain of change is real, but mercifully, it doesn't last. Within a year this debate will seem quaint.
As of 2024, literally none of the customers deploying the robots I worked on had ipv6 support on their networks. (We seriously considered switching to ipv6 for our backend controller-to-device network since it would inherently avoid conflicts that way - but none of the hardware devices had ipv6 support yet either, even the ones that were linux boxes underneath; turned out that network namespaces were a better approach to that problem anyway.) These were pretty technophilic areas (within otherwise "traditional" companies - the crossover between "wanting robots" and "being able to afford robots" is a little weird :-) and none of them were even talking about ipv6, to the point that we took "add configuration for ipv6 to the management console in a hurry because a customer wants it" off of our threat-to-schedule list entirely.
I get the feeling it's another 5-10 years before "not getting around to ipv6" will actually be a mistake in that space...
I get the feeling it's another 5-10 years before "not getting around to ipv6" will actually be a mistake in that space...
I would say this analogy is not properly when talking about IPv4 to IPv6 transition. Moving from Python 2.7 to 3 is a pure software problem while moving IPv4 to IPv6 is hardware, software, and logistics problem.
There are number of embedded OSes and devices that do not have firewalls nor the ability to disable network ports. Example of these invisible world items are motors, servos, PLCs, and label printers that get configured over IP. These devices do the bare minimum to get the IP stack up and running. These UI tools also need to be updated for allowing configuring an IPv6 address.
I would love to leave IPv4 and move fully to IPv6. Currently it is not cost effect to do so at scale. Companies do not want to spend money on the extra hardware to allow their IPv4 devices to talk IPv6 when they can save that money and keep running IPv4. Nor do they want to spend money on newer hardware. I still have clients running Windows XP Embedded, hopefully air gaped, in the automation world.
*You would be surprised on the number of large corporate IT managers that rather have a completely open label printer connected directly to their network instead of bridged behind a state full firewall running Windows or Linux hosting the main product.
There are number of embedded OSes and devices that do not have firewalls nor the ability to disable network ports. Example of these invisible world items are motors, servos, PLCs, and label printers that get configured over IP. These devices do the bare minimum to get the IP stack up and running. These UI tools also need to be updated for allowing configuring an IPv6 address.
I would love to leave IPv4 and move fully to IPv6. Currently it is not cost effect to do so at scale. Companies do not want to spend money on the extra hardware to allow their IPv4 devices to talk IPv6 when they can save that money and keep running IPv4. Nor do they want to spend money on newer hardware. I still have clients running Windows XP Embedded, hopefully air gaped, in the automation world.
*You would be surprised on the number of large corporate IT managers that rather have a completely open label printer connected directly to their network instead of bridged behind a state full firewall running Windows or Linux hosting the main product.
I can't use vlans because my isp only gives me a /64.
So I either need to use ipv6 + kludges or ipv4 + kludges. ipv4 is obviously easier and more reliable at that point, it's a no brainer.
Any sort of hot spot / bridge faces the same problem.
Now RFC 9663 is supposed to help here but guess what? It's only like a year old and barely exists. Not 20 years.
It's not that change is painful, it's the ipv6's original design of a shallow depth network was just... bad. Bolting on RFCs to fix it is taking a long time.
So I either need to use ipv6 + kludges or ipv4 + kludges. ipv4 is obviously easier and more reliable at that point, it's a no brainer.
Any sort of hot spot / bridge faces the same problem.
Now RFC 9663 is supposed to help here but guess what? It's only like a year old and barely exists. Not 20 years.
It's not that change is painful, it's the ipv6's original design of a shallow depth network was just... bad. Bolting on RFCs to fix it is taking a long time.
>In 2026 it does not. IPv6 support is now more than adequate,
Youtuber apalrd periodically revisits the Ubiquiti Unifi devices to see if they finally support IPv6 and he concluded it still doesn't work correctly.
The linked comment from Ubiquiti acknowledges they're still trying to improve the situation : https://www.youtube.com/watch?v=KZpJvpm1Ris&lc=UgwXlto--2NbO...
EDIT add: A lot of home users also like Ubiquiti ecosystem for local recording security cameras without a cloud subscription. Another competitor like Reolink with local capability also doesn't support IPv6: https://support.reolink.com/hc/en-us/articles/900000645446-D...
The practical home usage of deploying IPv6 depends on combination of the ISP, the devices you want to use, software stack, etc.
Youtuber apalrd periodically revisits the Ubiquiti Unifi devices to see if they finally support IPv6 and he concluded it still doesn't work correctly.
The linked comment from Ubiquiti acknowledges they're still trying to improve the situation : https://www.youtube.com/watch?v=KZpJvpm1Ris&lc=UgwXlto--2NbO...
EDIT add: A lot of home users also like Ubiquiti ecosystem for local recording security cameras without a cloud subscription. Another competitor like Reolink with local capability also doesn't support IPv6: https://support.reolink.com/hc/en-us/articles/900000645446-D...
The practical home usage of deploying IPv6 depends on combination of the ISP, the devices you want to use, software stack, etc.
There's transition tech for 4to6 to handle embedded devices, though.
Obviously the gateway or router missing proper v6 support is an issue and a bit surprising ubt hasn't done a good job.
Even my mid range TP-Link Archer I had 10 years ago properly supported IPv6
Obviously the gateway or router missing proper v6 support is an issue and a bit surprising ubt hasn't done a good job.
Even my mid range TP-Link Archer I had 10 years ago properly supported IPv6
I think the big difference is that python 3 took over rather quickly once it hit a threshold. There was a clearer path for adoption too: as more major packages started supporting python3, adoption accelerated and eventually python2 support was dropped. For IPv6 it's a lot less straightforward. You could cling on to IPv4 with basically 0 practical downsides in the current ecosystem as everything that supports IPv6 also supports IPv4, and IPv6 only networking basically doesn't exist. Even mobile users with only IPv6 adresses get to use IPv4-only services through some translation layer that every ISP has to provide when running IPv6.
I don't see the difference. You are describing the adoption curve (a logistic function) for almost anything.
As with IPv4/IPv6, with Python 2.7/3 you had, even at the very end, a group of stubborn maintainers who didn't put in the effort to transition.
The hard end of Python 2.7 support took care of all that in a hurry.
As with IPv4/IPv6, with Python 2.7/3 you had, even at the very end, a group of stubborn maintainers who didn't put in the effort to transition.
The hard end of Python 2.7 support took care of all that in a hurry.
> In 2026 it does not.
There are no ISP providing ipv6 for home and mobile users here in hong kong
There are no ISP providing ipv6 for home and mobile users here in hong kong
The hardware support is very likely already there.
That is an unusual luxury, especially mobile providers still using IPv4.
Mobile providers have been the first and most aggressive to migrate to IPv6. Probably helped along by the cost and difficulty of running CGNATs when your network clients are constantly moving around. At least in the UK all the mobile providers are IPv6, and I think a handful are IPv6 only.
Mobile providers have been the first and most aggressive to migrate to IPv6. Probably helped along by the cost and difficulty of running CGNATs when your network clients are constantly moving around. At least in the UK all the mobile providers are IPv6, and I think a handful are IPv6 only.
I live in the USA and my ISP doesn't support ipv6
I think it's different. Python 3 had a couple slightly annoying quirks that were resolved and once we got past that hurdle conversion was pretty seamless. I've been doing IPv6 in one form or another since, oh, 2010 or thereabouts, and it still remains pretty opaque and a pain in the ass compared to IPv4.
I do use it often, at least for Internet communication (I haven't checked recently to see what my traffic split is between v4/v6, but it's probably on the verge of tilting in favor of v6, if not already there), but I just can't see using it for my internal network anytime soon.
I do use it often, at least for Internet communication (I haven't checked recently to see what my traffic split is between v4/v6, but it's probably on the verge of tilting in favor of v6, if not already there), but I just can't see using it for my internal network anytime soon.
I'm not sure you understand what you're proposing. If you end IPv4 support on your product, all you're doing is banning the users on ISPs that don't have IPv6 support.
The people feeling the pain would not be in any position to fix the problem, and their experience will be that your site is down which leads to support burden and reputation risk for your product. If your support tells me to switch ISPs I'm going to roll my eyes and find another product that works.
The people feeling the pain would not be in any position to fix the problem, and their experience will be that your site is down which leads to support burden and reputation risk for your product. If your support tells me to switch ISPs I'm going to roll my eyes and find another product that works.
No, but imagine if Google, Meta and Netflix all publicly agreed to stop supporting IPv4 in X years.
_Everybody_ would rush and make sure to switch everything to IPv6.
_Everybody_ would rush and make sure to switch everything to IPv6.
Just thinking of the mountains of ewaste that decision would produce makes me ill.
There is very little hardware that would actually be ipv6 incompatible.
We're talking network equipment from 15+ years ago, which is also obsolete because it's 1Gbps at 10x the power usage of a 10gbps switch.
What about end user hardware? Chromecasts, TVs, IoT-whatevers, POS machines, kiosks, signage, etc.
Almost every network in existence runs on layers of tunnelling, so you can run arbitrary protocols over fixed hardware. We tunnel IP over Ethernet and then we don't have to replace our switches to use new IP versions or features. Most clouds use VXLAN. Many ISPs actually tunnel your IPv4 traffic over a purely-IPv6-only network, to a specific device whose job is to deal with legacy IPv4. The reverse is also possible if you have a network that can only handle IPv4.
If they set the deadline in 10 years, there would be (smaller) mountains generated in that period anyway.
[deleted]
I interpreted it to be about vendor contracts. Suppose you're setting up a new thing and you have a choice of vendors. They're all about the same but one of them supports IPv6. You're more likely to pick that one.
> still hasn't taken over the world
Maybe not in the strict sense, but it kind of has.
In the enterprises I've worked in the past decade with IPv6 running, at least 75% of the Internet traffic is IPv6. In my discussions with other engineers managing large networks, they seem to be seeing more or less that same figure.
The problem is that virtually nobody knows IPv6. I regularly bring up IPv6 in engineers' circles and I'm often the only one who knows much about it. And so, I have doubts about it's long-term future, except for edge cases. I figure some clever scheme utilizing IPv4 and probably NAT will come around at some point.
Maybe not in the strict sense, but it kind of has.
In the enterprises I've worked in the past decade with IPv6 running, at least 75% of the Internet traffic is IPv6. In my discussions with other engineers managing large networks, they seem to be seeing more or less that same figure.
The problem is that virtually nobody knows IPv6. I regularly bring up IPv6 in engineers' circles and I'm often the only one who knows much about it. And so, I have doubts about it's long-term future, except for edge cases. I figure some clever scheme utilizing IPv4 and probably NAT will come around at some point.
IPv4s are about to be bought, held, portfoilo'ed, speculated, and rented/mortgaged/sold like real estate. Companies like IPXO are already doing it. The costs of public IPv4's are going to go up for no technical reason because a new distinct ownership layer is springing up between you and the ISP. You're going to start renting them or paying a holder for the right to use them (on top of your ISP to transport it) at some point. And you can continue to do that, or get IPv6's for free.
Just to be pedantic, it's "illegal" to hoard IPv4 or to buy it for any purpose other than using it directly. But yeah, in the real world it may become more financialized than it already is. OTOH if prices keep dropping maybe they won't bother.
Ford Motor Company has both a /8 and a /9. They own over 16 million ip addresses.
Relatedly, I've been seeing some people buying up old domains and squatting on them with AI generated content. Not even ads, but content that seems like something that might actually show up in a rare Google search query. Not really sure what the play is or why this is better than advertising the domain for sale (do registrars punish overt squatting these days?).
IPv4s have been bought and sold for years
https://auctions.ipv4.global/prior-sales
Prices have been going down in nonimal terms for years, let alone real terms. In terms of investment they're a terrible asset.
https://auctions.ipv4.global/prior-sales
Prices have been going down in nonimal terms for years, let alone real terms. In terms of investment they're a terrible asset.
IPv6 and CGNAT growth has finally started to suppress IPv4 prices. There was a huge pump when hyperscalers decided they needed more. But IPv6 keeps growing and is the majority of traffic in many networks. If you own significantly more IPv4 addresses today than you need, I would dump them on the market yesterday. Spend some of the profits to move to IPv6 if still needed.
nice. I wish I could buy an address instead of renting from aws...
It seems like the addresses cost about $20 each, and can be rented out for ~$5/year.
That doesn't seem terrible.
That doesn't seem terrible.
How does one get an IPv6 allocation for free? Or, do you mean the ULA space? Because the latter doesn't really count.
You just ask your RIR. For example: https://www.arin.net/resources/guide/ipv6/first_request/
Looks like that's only for organizations. Even "end users" have to meet the requirements:
>Have an IPv4 assignment from ARIN or one of its predecessors
>Intend to immediately be IPv6 multi-homed
>Have 13 end sites (offices, data centers, etc.) within one year
>Use 2,000 IPv6 addresses within one year
>Use 200 /64 subnets within one year
Seems like they discourage individuals from getting allocations for their own personal use.
>Have an IPv4 assignment from ARIN or one of its predecessors
>Intend to immediately be IPv6 multi-homed
>Have 13 end sites (offices, data centers, etc.) within one year
>Use 2,000 IPv6 addresses within one year
>Use 200 /64 subnets within one year
Seems like they discourage individuals from getting allocations for their own personal use.
Yeah. If you're not an ISP or other LIR yourself, the correct path is to ask your ISP or a third-party ISP for a provider-independent allocation. This costs a nominal fee, about $50 per year.
I only know anything about RIPE policies but I gather the PI address processes and fees are very similar between RIPE and ARIN. RIPE has many members that are willing to handle address allocations for the RIPE fee plus 20% (so 60€ per year) and without bundling any other services.
I only know anything about RIPE policies but I gather the PI address processes and fees are very similar between RIPE and ARIN. RIPE has many members that are willing to handle address allocations for the RIPE fee plus 20% (so 60€ per year) and without bundling any other services.
I'd really like minimum service requirements to be mandated by law.
E.G. Comcast should be REQUIRED to give my OWN router a /56 or better, not a /60 because they waste a whole nibble of netmask at the cable modem which will _never_ talk to anything other than Comcast or my own Gateway.
E.G. Comcast should be REQUIRED to give my OWN router a /56 or better, not a /60 because they waste a whole nibble of netmask at the cable modem which will _never_ talk to anything other than Comcast or my own Gateway.
In the end you're still just asking for a block, you don't pay for it. There are requirements which vary from RIR to RIR, sure, but there were requirements for requesting blocks in IPv4 as well originally.
Ultimately, as a regular person requesting IPv6 space you'd just ask your ISP, which can get practically as much as they want for free by submitting these kinds of requests. Meanwhile, for IPv4 space they're going to have a harder and harder time getting you additional space and chances are be unwilling to give it free/cheap.
Ultimately, as a regular person requesting IPv6 space you'd just ask your ISP, which can get practically as much as they want for free by submitting these kinds of requests. Meanwhile, for IPv4 space they're going to have a harder and harder time getting you additional space and chances are be unwilling to give it free/cheap.
> as a regular person requesting IPv6 space you'd just ask your ISP
In real life these requests don't lead to IPv6 allocation, no matter how they're asked or how often. Here are a few of the responses I've received just this year.
Past that: Over 15yrs of asking various ISPs (large and small) to make allocations available, none of us ever budged the IPv6 needle.
In real life these requests don't lead to IPv6 allocation, no matter how they're asked or how often. Here are a few of the responses I've received just this year.
"At this time we are not able to provide a IPv6 unfortunately."
"We regret to inform you that, at this time, we do not offer IPv6 support."
"I wanted to inform you that IPv6 is currently not available"
Past that: Over 15yrs of asking various ISPs (large and small) to make allocations available, none of us ever budged the IPv6 needle.
My mobile operator and my ISP at home both provide IPv6 connectivity without me asking. All I had to do was to enable IPv6 on my router.
> My mobile operator and my ISP at home both provide IPv6 connectivity without me asking. All I had to do was to enable IPv6 on my router.
I think this is representative of every IPv6 deployment. You get it or you don't. If it isn't available to you, asking won't make any difference.
FTR we have 6 wireline ISP here. Cable has IPv6, the 5 fiber operators do not.
I think this is representative of every IPv6 deployment. You get it or you don't. If it isn't available to you, asking won't make any difference.
FTR we have 6 wireline ISP here. Cable has IPv6, the 5 fiber operators do not.
right above that is says: "If you meet any of the criteria below, you qualify to receive IPv6 address space:" (emphasis added)
Unless they're very lax about what constitutes multi homed I meet zero of those requirements.
Does me renting a server in a DC count as multi homing? Bridging my network to my friend's place over wireguard? Doubtful tbh
Does me renting a server in a DC count as multi homing? Bridging my network to my friend's place over wireguard? Doubtful tbh
Typically, multi-homing means having an ASN and using BGP, or having multiple providers with BGP announce your prefix. So, a server in a DC might count, if you can get them to announce your prefix, though they'll probably want to announce their own prefix and give you a chunk of it. Your home network probably isn't going to be announcing your prefix.
It really depends on what you're trying to achieve by having a direct IPv6 allocation...
It really depends on what you're trying to achieve by having a direct IPv6 allocation...
Maybe I just want a /48 or something, to do whatever with.
If, as ARIN claims, ipv6 scarcity is not an issue then it's very frustrating to deny me the ability to get my own chunk of space for my own purposes.
It shouldn't matter what I plan to do with it.
If, as ARIN claims, ipv6 scarcity is not an issue then it's very frustrating to deny me the ability to get my own chunk of space for my own purposes.
It shouldn't matter what I plan to do with it.
I hear what you're saying but if you aren't going to publicly route those IPs, ARIN has allocated fd00::/8 for that use. If you are going to publicly route your IPs, ARIN has no problem allocating you the space.
this depends on your RIR. RIPE has far less strict requirements.
A link to a non-commercial guide for IPv6 allocation would be appreciated here.
I've written such a guide: https://jlsksr.de/docs/isp-guide/
The official docs of the RIRs are "non-commercial guides for IPv6 allocation", too.
The official docs of the RIRs are "non-commercial guides for IPv6 allocation", too.
I'm a networking noob, but would it be possible to extend DNS/HTTPS so as to allow a URL to point to a port other than 443? Doing so would allow each IP address to serve multiple websites/computers making the pool of addresses at least thousands of times larger.
As others have mentioned, there's SNI and host headers to have multiple sites on port 443, but there is also the SVCB/HTTPS aliases (https://www.rfc-editor.org/rfc/rfc9460) which will allow having the plain domain alias to other hosts including ones with embedded port numbers. Non-browser support is pretty lacking though.
That’s sort of what HTTP is already doing though no?
Multiple websites can have the exact same DNS record and live on the same physical server / IP address, but the HTTP(S) request must specify what host name it is actually requesting, so the server knows how to serve it.
Multiple websites can have the exact same DNS record and live on the same physical server / IP address, but the HTTP(S) request must specify what host name it is actually requesting, so the server knows how to serve it.
It is already possible using the Host header and TLS SNI. But traffic still flows through port 443.
We own our own IPv4 and IPv6 ranges, which is nice. There already is a holder for the US: ARIN.net and I hear it's a pretty spendy annual fee for most orgs (we're legacy. we've had ours for decades)
Now all we need is for someone to make a crypto currency so you can fractionally own IPv4 addresses.
Presumably this would be port-based fractional and 443/tcp would cost a premium.
I was thinking it was more of a "more than 50%" ownership controls the routing tables. Love the chaos.
It's already possible to "split" a frontend HTTP server on a given IP and port to arbitrary backend IPs and ports via the Host header and reverse proxies.
> Maybe not in the strict sense, but it kind of has.
I challenge you to find:
1. A hotel in the US that provides IPv6. I have NEVER been in one, and I once stayed in a hotel (in Mountain View, CA) that was giving out public IPv4 addresses.
2. An easier task: a SIP provider that has IPv6 (in the US). You know, for the VoIP that is supposed to be a poster child of end-to-end connectivity.
I challenge you to find:
1. A hotel in the US that provides IPv6. I have NEVER been in one, and I once stayed in a hotel (in Mountain View, CA) that was giving out public IPv4 addresses.
2. An easier task: a SIP provider that has IPv6 (in the US). You know, for the VoIP that is supposed to be a poster child of end-to-end connectivity.
> In the enterprises I've worked in the past decade with IPv6 running
What about those without IPv6 running?
Anyway, in the enterprises I've worked in the past decade - of course, another anecdote - not once has anyone ever specified an IPv6 address of anything. Inside the organization or outside of it.
What about those without IPv6 running?
Anyway, in the enterprises I've worked in the past decade - of course, another anecdote - not once has anyone ever specified an IPv6 address of anything. Inside the organization or outside of it.
why would an enterprise turn to IPv6?
everything fit's nicely in the 10.0.0.0/8 range
in my many decades of enterprise infrastructure, no-one has ever mentioned IP6 either.
why would they, whats the business case?
everything fit's nicely in the 10.0.0.0/8 range
in my many decades of enterprise infrastructure, no-one has ever mentioned IP6 either.
why would they, whats the business case?
The problem with private address ranges is that everyone thinks they're available. In a large enough enterprise you're bound to have conflicts. They usually pop up at the most inconvenient time and suddenly you're cosplaying ARIN in your IT department.
> everything fit's nicely in the 10.0.0.0/8 range
Except during a merger/acquisition and both companies have 10.0.0.0/24 in their OSPF or IS-IS topology.
Except during a merger/acquisition and both companies have 10.0.0.0/24 in their OSPF or IS-IS topology.
> everything fit's nicely in the 10.0.0.0/8 range
Except for when it doesn't.
If you just use that space as a flat range, it is almost certainly more than enough. But if you split it up in multiple levels of subnets, you can run into difficulties balancing having enough subnets and having enough space in each subnet.
Except for when it doesn't.
If you just use that space as a flat range, it is almost certainly more than enough. But if you split it up in multiple levels of subnets, you can run into difficulties balancing having enough subnets and having enough space in each subnet.
240/4 is private and more than sufficient.
It is not private, it is merely "reserved". If/when that range opens up for Internet address, you'll be in a world of hurt for having used it.
IPv6 is much more stable on what you can use. fc00::/7 is actually private use.
IPv6 is much more stable on what you can use. fc00::/7 is actually private use.
That will never ever happen. Making 240/4 public will break Amazon (and many others) which do use it privately. The software updates to route it across the net would have been taxing. When making it public was suggested years ago, IETF saw the proposition as encouraging IPv4 and refused to entertain it.
In short: The market has already decided and it's private. It's far from the first time an unofficial arrangement is the de facto standard.
In short: The market has already decided and it's private. It's far from the first time an unofficial arrangement is the de facto standard.
We burned thru pretty much all of our public /8, RFC1918, and have begun digging into RFC6589 (a /10 I didn’t even know existed prior to job). Still shocks me. Hardly an expert in the space, but I think the issue comes from subnetting to distribute ranges to teams that need a consistent IP address space for some project or another. Lots of inefficiency & hoarding over time. We’ve had legitimate outages and impending platform death staved off by last minute horse-trading & spooky technical work due to such things. IPV6 has always been a distant aspiration.
Grow large enough and you hit the limit pretty fast. NAT complicates things.
The best one is async routing. You have a NAT, they have a NAT, you VPN together and think you have different IP address ranges, but unknown to the operator there's a little internal network with an overlap at the end of some slow line that is now getting flooded with internal traffic that's trying to go to a completely different network.
I've worked for companies with over 50,000 employees and they didn't seem to need it. Now, sure, there are larger companies, or ones that employ huge farms of machines, but those are the exception rather than the rule.
you haven't had to set up intercompany vpns I see
Indeed I have not. But I suspect most people, and most companies, have not either.
I don't claim IPv6 isn't used anywhere, or even that it's not used a lot.
I don't claim IPv6 isn't used anywhere, or even that it's not used a lot.
Pretty much every fortune 500 company does, which counts for millions of people on their networks every day. The troubleshooting calls for VPN routing vs internal LAN routing are fun endeavors of who is actually willing to take responsibility for things they don't understand.
Somehow still easier than v6.
I've spent half a year getting nowhere on a discussion involving VPN-ing parts of the company just to have connectivity for specific services where part of the problem was lots and lots of overlapping 10./8 allocations - partially because everyone setting a "VPC" or some local dc network was doing individual 10./8, often "in name of simplicity".
With subnetting needs, possibly dealing with VPNs to other networks that might use 10./8, ISPs that might use 10./8 instead of CGNAT space (100.64./10), even the total incompetence of some contractors was not reducing how IPv4 was a problem.
And that's before you hit the part where Microsoft products have been IPv6 First since ~2008 and there are entire feature sets that are very interesting to bigger companies (like well integrated always-on vpn for laptops) that require working v6
With subnetting needs, possibly dealing with VPNs to other networks that might use 10./8, ISPs that might use 10./8 instead of CGNAT space (100.64./10), even the total incompetence of some contractors was not reducing how IPv4 was a problem.
And that's before you hit the part where Microsoft products have been IPv6 First since ~2008 and there are entire feature sets that are very interesting to bigger companies (like well integrated always-on vpn for laptops) that require working v6
It is not in the least easier than v6. IPv6 isn't even difficult.
Unless you get to big. Or you merge with another company and have to combine your internal networks and oops, all the subnets are overlapping. Or you need to serve mobile clients who get better connectivity over v6.
if both you and companies you have site to site vpn with have IPv6 there is no IP conflict or NAT to worry about.... and that's about end of the advantages
one poorly made decision and oops you're out of 10/8 addresses
if you've never run in to this, then sorry, you've not been in an enterprise, you're in a mom 'n pop shop cosplaying as enterprise.
if you've never run in to this, then sorry, you've not been in an enterprise, you're in a mom 'n pop shop cosplaying as enterprise.
> not once has anyone ever specified an IPv6 address of anything. Inside the organization or outside of it.
If you deploy IPv6 correctly, you shouldn't have to disclose IPv6 addresses to users inside or out -- DNS keeps the address literals abstract, hidden from users.
If you deploy IPv6 correctly, you shouldn't have to disclose IPv6 addresses to users inside or out -- DNS keeps the address literals abstract, hidden from users.
I am on my company's VPN right now and I get a 0/10 at test-ipv6.com
>Maybe not in the strict sense, but it kind of has.
>In the enterprises I've worked in the past decade with IPv6 running, at least 75% of the Internet traffic is IPv6.
Nobody cares about those. What matters is if my device has an IPv6 address assigned.
>In the enterprises I've worked in the past decade with IPv6 running, at least 75% of the Internet traffic is IPv6.
Nobody cares about those. What matters is if my device has an IPv6 address assigned.
Ok then: most people in the US do. The rest of the world is looking increasingly ipv6 too: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
India is 71% IPv6 (probably thanks to Jio), China has it in its 5 year plan, Europe is doing well, etc
> at least 75% of the Internet traffic is IPv6.
> Nobody cares about [that]. What matters is if my device has an IPv6 address assigned.
This seems to be the weird dichotomy in these comments. Some people are arguing from the position that is absolutely everywhere and is doing great.
Others are saying since their machine doesn’t show it it’s dead and no one cares.
Is there a term for this? A successful failure? A failed success?
Kind of odd.
> Nobody cares about [that]. What matters is if my device has an IPv6 address assigned.
This seems to be the weird dichotomy in these comments. Some people are arguing from the position that is absolutely everywhere and is doing great.
Others are saying since their machine doesn’t show it it’s dead and no one cares.
Is there a term for this? A successful failure? A failed success?
Kind of odd.
It is why the Google IPv6 stats fluctuate between weekends/holidays and weekdays. IPv6 is much more prevalent on home and mobile networks so increase on non-work dyas. Companies have IPv4 networks that they don't want to upgrade. We have dichotomy where 50% of clients have IPv6, but most of the small sites do not.
The other thing I have seen is that engineers make things complicated. Normal person has IPv6 enabled by default or enables it in router, and it just works and they never notice. Engineers want to configure things manually, but IPv6 is hard if fight against the dynamic defaults.
The other thing I have seen is that engineers make things complicated. Normal person has IPv6 enabled by default or enables it in router, and it just works and they never notice. Engineers want to configure things manually, but IPv6 is hard if fight against the dynamic defaults.
Maybe the False Consensus Effect?
https://en.wikipedia.org/wiki/False_consensus_effect
https://en.wikipedia.org/wiki/False_consensus_effect
Anecdotal stalemate.
I use this argument, because HN also tries to do the reverse when someone suggests a protocol/addition/replacement to either TCP or HTTP. Then suddenly it's important what shitty company networks do. It's still not.
75% or 99% does not matter. Until you can't forget about IPv4, IPv6 us useless.
The fact that this comments section indicates such a yawning chasm of gaps in knowledge (much less, understanding) - in a forum whose users are generally known to be more technically savvy than most - is exactly why IPv6 is still not widely adopted. There is confusion about the less obvious benefits, confusion about how it works, confusion about the dangers (how do I adjust my well honed IPv4 spidey senses?), and confusion about how I transition my current private network. An epic failure of change management.
Here’s a prediction. Linux on the desktop will have >50% penetration well before IPv6 does.
Here’s a prediction. Linux on the desktop will have >50% penetration well before IPv6 does.
IPv6 already hit 50% https://www.google.com/intl/en/ipv6/statistics.html
It's so funny to see predictions that aged worse than milk. Ipv6 adoption isn't up to individuals, it's up to ISPs. We consumers aren't supposed to know about ipv6. The change will be silent and continuous.
“Given addresses” != adoption. Hell, I had to disable it in osx because it breaks the damn hotspot connection functionality. Wasn’t using it, it’s just there, breaking shit and being useless.
Google's stats are tracking the percentage of people that reach Google over IPv6. That means they've not just been given addresses, but they configured them and are actively using them. How can that possibly not count as "adoption"?
That’s Apple’s fault. Why are you blaming it on IPv6? Oh, because Apple can do no wrong.
Measly 30 years after it was approved. We will likely get AGI before we finish the transition.
> The fact that this comments section indicates such a yawning chasm of gaps in knowledge (much less, understanding) - in a forum whose users are generally known to be more technically savvy than most - is exactly why IPv6 is still not widely adopted.
No, it isn't. Everyone here has the causality backwards. We don't know it because we've never needed to know it, and we've never needed to know it because it's not really required for anything (i.e. the cost of adopting/learning it > benefit).
This has been a frustrating HN discussion to read, to be honest, because the consensus view strikes me as so off base. It's not that IPv6 has been miscommunicated, or that it hasn't been taught enough to undergrads. It's that it has been designed with virtually no incentives to encourage people to actually adopt it, with the entirely predictable consequence that no one adopted it. Therefore, none of us need to know it, schools don't need to teach it, etc.
Folk are internalising the wrong lesson here. Incentives matter. No amount of mandated IPv6 instruction or well-intentioned blog posts explaining IPv6 are going to change anyone's incentive structure. And then when those things fail, there's a predictable and tiresome tendency to blame the users for not switching.
If you want people to adopt new tech, make it actually do something new. Give people some reason to want to switch. "It mostly does the same thing as the old tech did, but it also takes effort and money to learn it / switch to it" is a terrible pitch, with entirely predictable consequences, and it's far too common in technical circles.
No, it isn't. Everyone here has the causality backwards. We don't know it because we've never needed to know it, and we've never needed to know it because it's not really required for anything (i.e. the cost of adopting/learning it > benefit).
This has been a frustrating HN discussion to read, to be honest, because the consensus view strikes me as so off base. It's not that IPv6 has been miscommunicated, or that it hasn't been taught enough to undergrads. It's that it has been designed with virtually no incentives to encourage people to actually adopt it, with the entirely predictable consequence that no one adopted it. Therefore, none of us need to know it, schools don't need to teach it, etc.
Folk are internalising the wrong lesson here. Incentives matter. No amount of mandated IPv6 instruction or well-intentioned blog posts explaining IPv6 are going to change anyone's incentive structure. And then when those things fail, there's a predictable and tiresome tendency to blame the users for not switching.
If you want people to adopt new tech, make it actually do something new. Give people some reason to want to switch. "It mostly does the same thing as the old tech did, but it also takes effort and money to learn it / switch to it" is a terrible pitch, with entirely predictable consequences, and it's far too common in technical circles.
> with the entirely predictable consequence that no one adopted it
As the sibling comment pointed out: it's very close to 50% adoption, you just don't see it https://www.google.com/intl/en/ipv6/statistics.html
As the sibling comment pointed out: it's very close to 50% adoption, you just don't see it https://www.google.com/intl/en/ipv6/statistics.html
> There is confusion about the less obvious benefits, confusion about how it works, confusion about the dangers (how do I adjust my well honed IPv4 spidey senses?), and confusion about how I transition my current private network
Could you be specific about what the misconceptions are?
Could you be specific about what the misconceptions are?
I had Copilot produce this for you based on the comments in this discussion (as at just before the timestamp of this comment).
https://copilot.microsoft.com/shares/656dEMHWyFye5cCeicgGv
https://copilot.microsoft.com/shares/656dEMHWyFye5cCeicgGv
Interesting that this is getting downvoted. I truly wonder why. One of the things LLMs are good at is summarising and extracting key points. Or should I have gone to the trouble to do this myself - read the entire comment thread and manually summarise - when the person I was replying to hadn’t done that? My comment was meant in good faith: “here’s the info you wanted and how you can easily get them yourself next time”.
1. People come here for discussions with real people. The other night I was at a party and we had a great time playing chess and board games. It would be weird if someone started using stockfish, even if it is a better player. Everything stockfish does, it already knows. It doesn't learn or explore the game-space.
2. The response is still too wordy, generic, and boring. So LLMs are not really better players, at least for now.
3. With LLMs, you can produce a ton of text much faster than it can be read. Whereas the dynamic is reversed for ordinary writing. By writing this by hand, I am doing you a favor by spending more time on this comment than you will. But by reading your LLM output I am doing you a favor by spending more time reading than you did generating.
You could probably get away with using an LLM here by copying the response and then cutting down 90% of it. But at that point it would be better to just restate the points yourself in your own words.
2. The response is still too wordy, generic, and boring. So LLMs are not really better players, at least for now.
3. With LLMs, you can produce a ton of text much faster than it can be read. Whereas the dynamic is reversed for ordinary writing. By writing this by hand, I am doing you a favor by spending more time on this comment than you will. But by reading your LLM output I am doing you a favor by spending more time reading than you did generating.
You could probably get away with using an LLM here by copying the response and then cutting down 90% of it. But at that point it would be better to just restate the points yourself in your own words.
So cheap questions where the answers could be readily had are not downvoted even though the answers to their question are right here in the discussion. Whereas because I did not do the legwork that my correspondent would not do, I am penalised. That’s what I’m hearing.
EDITED TO ADD:
> by reading your LLM output I am doing you a favor by spending more time reading than you did generating
How could my respondent (presumably on whose behalf you are making the argument) possibly be doing me a favour when they asked the question? Is it each of our responsibility to go to some lengths to spoon feed one another when others don’t deign to feed themselves?
EDITED TO ADD:
> by reading your LLM output I am doing you a favor by spending more time reading than you did generating
How could my respondent (presumably on whose behalf you are making the argument) possibly be doing me a favour when they asked the question? Is it each of our responsibility to go to some lengths to spoon feed one another when others don’t deign to feed themselves?
And yet the llm did a better work of disparaging everyone comments as uniformed, which they are btw.
You're not offering anything of value. We all can ask some LLM about stuff we want to know. It's like in the past, when someone would post a link to search results as a reply.
[deleted]
One would think that in 30 years there will be some sort of best practises established. Some articles to refer people to. Or at least some people to share their experience and answer practical questions.
And yet there is still only "you doing it wrong, and I won't tell you how to do it right"
And yet there is still only "you doing it wrong, and I won't tell you how to do it right"
IPv6 existence is questioned not because people fail to configure it. It’s because they do not understand the problems it solves. Those problems are so large they’re invisible at the individual human scale. You either know them (which is not a secret) or invent superficial charges against the design.
No. People fail to configure it. Then start to question why this piece of garbage exist.
It doesn't matter what problems it supposed to solve if it doesn't work.
It doesn't matter what problems it supposed to solve if it doesn't work.
Here's a counter: people don't need to configure it. They just need to connect to the network and the network is smart enough that it's essentially plug and play.
Maybe your magic ipv6 configures everything.
My have certain shortcomings: it doesn't assign dns names to hosts and doesn't configure firewall rules
My have certain shortcomings: it doesn't assign dns names to hosts and doesn't configure firewall rules
> such a yawning chasm of gaps in knowledge ... in a forum whose users are generally known to be more technically savvy
There is a heck of a Dunning–Kruger joke to be made here.
There is a heck of a Dunning–Kruger joke to be made here.
No. It's not adopted everywhere because it's awful. At least on the data center side.
I get so many Second System Syndrome vibes off of IPv6. Surely other people must be picking it up too.
Future proofing it by jumping straight to 128 bits instead of 64. 64 would have been fine. Even with a load factor of 1:1000 by assigning semantics to ranges of IP addresses, 64 bit addressing is still enough addresses for 10 million devices per person.
If we become a galactic empire, we will have to replace the Web anyway because every interaction will have to be a standalone app or edge networking that doesn’t need to hear back from the central office for minutes, hours, days anyway. We could NAT every planet and go on forever.
Future proofing it by jumping straight to 128 bits instead of 64. 64 would have been fine. Even with a load factor of 1:1000 by assigning semantics to ranges of IP addresses, 64 bit addressing is still enough addresses for 10 million devices per person.
If we become a galactic empire, we will have to replace the Web anyway because every interaction will have to be a standalone app or edge networking that doesn’t need to hear back from the central office for minutes, hours, days anyway. We could NAT every planet and go on forever.
The point is not really to support a galactic empire, the idea is that you have a network part and an interface part, each is 64 bits. The "network" part is used by routers, the interface part is to identify the device on the endpoint. Each interface have an identifier that is world unique (usually based on the MAC address), each network is also unique. Usually, your ISP gives you a /48 prefix, so you have 16 bits for potentially 64k internal networks. This way, you don't need something like DHCP to get an address, you just take it and you won't have conflicts.
But because you have two independent unique parts, you need twice as many bits, so 64+64=128 bits. It simplifies routing and address allocation, at the cost of 16 bytes per packet compared to 64 bit addresses.
That we could use IPv6 on galactic empires is an added bonus, but not really the reason.
But because you have two independent unique parts, you need twice as many bits, so 64+64=128 bits. It simplifies routing and address allocation, at the cost of 16 bytes per packet compared to 64 bit addresses.
That we could use IPv6 on galactic empires is an added bonus, but not really the reason.
Bypassing the router to get to the device directly via IP sounds like insanity. Like a forever-open port.
You are not bypassing the router, the devices need to get their packets from somewhere, and it is only like a forever-open port if the router/firewall decides it is.
My ISP router supports IPv6 but blocks all incoming connections by default, which is kind of like what NAT does as a side effect.
It sounds like insanity because we tend to assume that no NAT means no firewall, because NAT has some firewall-like properties, and on the most basic networks, that's the only "firewall" there is. But none of the security features of "NAT as a firewall" are exclusive to IPv4, in fact, IPv6 has an advantage because the much larger address space makes a full scan practically impossible.
My ISP router supports IPv6 but blocks all incoming connections by default, which is kind of like what NAT does as a side effect.
It sounds like insanity because we tend to assume that no NAT means no firewall, because NAT has some firewall-like properties, and on the most basic networks, that's the only "firewall" there is. But none of the security features of "NAT as a firewall" are exclusive to IPv4, in fact, IPv6 has an advantage because the much larger address space makes a full scan practically impossible.
> You are not bypassing the router, the devices need to get their packets from somewhere, and it is only like a forever-open port if the router/firewall decides it is.
This trips up a lot of people, and I think it's because NAT was probably their first real exposure to networking. When that happens, you end up building all your mental models around NAT as the baseline, even though NAT itself is really just a workaround for address space limitations.
What's interesting is that someone with no networking background who thinks of it like a postal system (packets are letters that get forwarded through various routing centers from source to destination) would actually have a more accurate mental model of how IP networking fundamentally works. The NAT-centric view we all learned first can actually make the basics harder to understand, not easier.
This trips up a lot of people, and I think it's because NAT was probably their first real exposure to networking. When that happens, you end up building all your mental models around NAT as the baseline, even though NAT itself is really just a workaround for address space limitations.
What's interesting is that someone with no networking background who thinks of it like a postal system (packets are letters that get forwarded through various routing centers from source to destination) would actually have a more accurate mental model of how IP networking fundamentally works. The NAT-centric view we all learned first can actually make the basics harder to understand, not easier.
Whether the packets forward it’s still leaking your network topology to attackers which is so boneheaded I don’t know where to start.
Anti nat advocates seem to fall into the “the network shouldnt provide a stateful firewall” camp, because once you have a stateful firewall then nat is a trivial amount of extra bytes and very few issues with modern protocols (ones which don’t embed layer 3 addressing in layer 6/7 messages)
I like the end-to-end principle. Good times.
>Anti nat advocates seem to fall into the “the network shouldnt provide a stateful firewall” camp
Eh, what?
My entire justification for getting rid of NAT is *because* a default-deny-inbound firewall policy should exist, and NAT is a network patch that functions as a hacky firewall at the consumer level.
Eh, what?
My entire justification for getting rid of NAT is *because* a default-deny-inbound firewall policy should exist, and NAT is a network patch that functions as a hacky firewall at the consumer level.
It's a big privacy problem too. Basing your IP address on your Mac address doesn't help in that regard either. Times have changed a lot since IPv6 was invented.
> Basing your IP address on your Mac address doesn't help in that regard either.
This hasn’t been the case for 20 years. Privacy Extensions solved that, and every SLAAC implementation supports them.
This hasn’t been the case for 20 years. Privacy Extensions solved that, and every SLAAC implementation supports them.
> Future proofing it by jumping straight to 128 bits instead of 64. 64 would have been fine. Even with a load factor of 1:1000 by assigning semantics to ranges of IP addresses, 64 bit addressing is still enough addresses for 10 million devices per person.
128 bit is like the least of adoption issues and basically meaningless difference vs 64.
But it shows weird priorities when they decided 128 then immediately wasted half of it on host part just to achieve "globally unique" host part that isn't really all that useful characteristic of the protocol.
128 bit is like the least of adoption issues and basically meaningless difference vs 64.
But it shows weird priorities when they decided 128 then immediately wasted half of it on host part just to achieve "globally unique" host part that isn't really all that useful characteristic of the protocol.
IP addresses were always meant to be globally reachable. Of course, NAT has corrupted this - which is why NAT is a scourge.
And so are firewalls?
firewalls are a choice that the enduser makes.
non-routed prefixes are a limitation imposed by the ISP the the user can't address.
non-routed prefixes are a limitation imposed by the ISP the the user can't address.
> to achieve "globally unique" host part that isn't really all that useful characteristic of the protocol.
That's the essential part of self-configured addresses in IPv6 that does away with DHCP in most cases. DHCP is a stateful system that has to track every device's addresses individually. You don't need that with IPv6 thanks to this.
That's the essential part of self-configured addresses in IPv6 that does away with DHCP in most cases. DHCP is a stateful system that has to track every device's addresses individually. You don't need that with IPv6 thanks to this.
And yet DHCPv6 is pretty much the standard because you need to push other things into client.
Need I remind you that option to push DNS server (which is pretty fucking important option!) was added to IPv6 standard only in 2007 ?
Like, someone decided "yeah have that magical stateless autoconfig thing" and didn't figure out that basic options like DNS, or less common but still VERY useful like the PXE stuff, or NTP server, routes and dozen others DHCP does? (there are security implications too but DHCP wasn't great here too)
IPv6 in its original format was a joke and stateless configuration is more or less pointless excercise aside from link-local adresses but those could be only exception where stateless runs
Need I remind you that option to push DNS server (which is pretty fucking important option!) was added to IPv6 standard only in 2007 ?
Like, someone decided "yeah have that magical stateless autoconfig thing" and didn't figure out that basic options like DNS, or less common but still VERY useful like the PXE stuff, or NTP server, routes and dozen others DHCP does? (there are security implications too but DHCP wasn't great here too)
IPv6 in its original format was a joke and stateless configuration is more or less pointless excercise aside from link-local adresses but those could be only exception where stateless runs
The NTP server thing was especially egregious given that the transition to everything being under TLS was underway and clocks matter in that situation.
64 bits would have been much easier to read and transcribe. It does matter.
I kinda think we could fix/save IPv6 by taking away almost everything but the 128-bit address extension.
The truth is nothing needed fixing, or we wouldn't have been in this position 30 years later
Disagree. APINIC got screwed on the IP allocation side, they're the RIR with the largest population but they have a tiny amount of IPs compared to ARIN. India and China have billions of people and not enough v4 space for them. If we go back and reallocate legacy blocks maybe you could make the system work but that would be a big fight with the legacy networks.
v6 restores the end-to-end principle and reduces network complexity once you go v6 only. Not more NAT traversal problems, no need to deal with STUN/TURN, small networks get even simpler with no need for a statefull DHCP server.
Sticking with only v4 space also artificially increases the cost of starting new networks and services because you have to buy space from the entrench IP save owners (unless we change the rules are start charging fees to legacy networks and reclaiming unused or poorly utilized space). Those higher barriers to entry hurt innovation and competition.
So v6 solves several technical and policies issues with the Internet, and maybe that's why we haven't seen speedy adoption. Because people have networks that exist today, some have paid a lot of money for IPv4 space and they want to make the most of that investment.
They don't really have an incentive to implement V6 unless things start to break without it.
I don't think v6 has been a failure half of all internet traffic runs on it! It powers the major cell phone networks, and large tech companies like meta have even gone v6 only in their data centers.
v6 restores the end-to-end principle and reduces network complexity once you go v6 only. Not more NAT traversal problems, no need to deal with STUN/TURN, small networks get even simpler with no need for a statefull DHCP server.
Sticking with only v4 space also artificially increases the cost of starting new networks and services because you have to buy space from the entrench IP save owners (unless we change the rules are start charging fees to legacy networks and reclaiming unused or poorly utilized space). Those higher barriers to entry hurt innovation and competition.
So v6 solves several technical and policies issues with the Internet, and maybe that's why we haven't seen speedy adoption. Because people have networks that exist today, some have paid a lot of money for IPv4 space and they want to make the most of that investment.
They don't really have an incentive to implement V6 unless things start to break without it.
I don't think v6 has been a failure half of all internet traffic runs on it! It powers the major cell phone networks, and large tech companies like meta have even gone v6 only in their data centers.
> reduces network complexity once you go v6 only
What networks are v6 only today?
> So v6 solves several technical and policies issues with the Internet,
If it's not used it doesn't solve anything
> They don't really have an incentive to implement V6 unless things start to break without it
Exactly my point
What networks are v6 only today?
> So v6 solves several technical and policies issues with the Internet,
If it's not used it doesn't solve anything
> They don't really have an incentive to implement V6 unless things start to break without it
Exactly my point
> What networks are v6 only today?
Mostly mobile networks.
> If it's not used it doesn't solve anything
It's used by literally billions of devices.
Mostly mobile networks.
> If it's not used it doesn't solve anything
It's used by literally billions of devices.
Yet almost all websites I visit on the daily still dont support IPv6. Discord, probably the biggest chat platform in the world refuses to use Ipv6 because it bypasses rate limiting and IP bans. I don't think i've ever seen a video game ever support IPv6. Using different scopes (for say, failover/load balancing) doesn't work with Ipv6 because computers are configured to ignore local-scoped addresses when sending packets over Ipv6 so you just get downtime instead of having your router handle a failover. Or pay up for BGP. DHCPv6 might as well not work at all (at least SLAAC was decently easy to setup once you wrangle a full allocation from your ISP).
Besides all of those, you are still most likely going to encounter network slowdowns when you have IPv6 because it's gonna try IPv6 and fail to load the target website since even website that have an AAAA record are usually inaccessible over v6 for some reason. Oh and firewall is a set of separate configurations on v4 and v6 (iptables vs ip6tables, having to reconfigure it on nftables for both, etc..) at least ufw handles it nicely nowadays. I had IPv6 enabled for a month about three months ago and all I experienced was slowdowns (due to websites having to fall back to v4) and things not working (such as my failover setup - global scope vs local scope). It's back to disabled in my home network.
Besides all of those, you are still most likely going to encounter network slowdowns when you have IPv6 because it's gonna try IPv6 and fail to load the target website since even website that have an AAAA record are usually inaccessible over v6 for some reason. Oh and firewall is a set of separate configurations on v4 and v6 (iptables vs ip6tables, having to reconfigure it on nftables for both, etc..) at least ufw handles it nicely nowadays. I had IPv6 enabled for a month about three months ago and all I experienced was slowdowns (due to websites having to fall back to v4) and things not working (such as my failover setup - global scope vs local scope). It's back to disabled in my home network.
T-Mobile and Meta are two I know about.
Don't think the problem is 64 vs 128. I don't think the problem is end users either, the vast majority of which don't even know what the IP protocol is in the first place (nor should they). The fault I think is on ISPs.
I use hyperoptic in the UK, if you replace the original router (which reserves the external 443 port for itself, i.e. no one sophisticated would keep it), there seems to be no way to get a v6 address. This is pure incompetence and carelessness. Like ISPs allowing their network to send packets spoofing IPs from outside their network. Add to that foreign ISPs (which means that even if your own network supports v6, you need v4 support when you are on holidays/travelling), and you have a situation where v4 cannot simply be switched off.
So for a website, what is the point of supporting v6 if v4 is never going away?
I use hyperoptic in the UK, if you replace the original router (which reserves the external 443 port for itself, i.e. no one sophisticated would keep it), there seems to be no way to get a v6 address. This is pure incompetence and carelessness. Like ISPs allowing their network to send packets spoofing IPs from outside their network. Add to that foreign ISPs (which means that even if your own network supports v6, you need v4 support when you are on holidays/travelling), and you have a situation where v4 cannot simply be switched off.
So for a website, what is the point of supporting v6 if v4 is never going away?
It's understandable that IPv6 would be ambitious rather than incremental given the cost of rolling out a new protocol; the bells-and-whistles IPv6 design is probably just a relatively small constant factor more expensive than the simplest possible address space expansion. Viewed that way, you only get the one chance to update the protocol, you might as well fix whatever you can.
It's not Second System Syndrome. Nearly every complaint against IPv6 is downstream of the decision to enforce a global centralized namespace for an end-to-end principle many don't care for.
e.g. Getting a unique address would be way more risky with 64 bits (there's a reason UUIDs are 128 bits too!), even before considering the network:interface split.
e.g. Getting a unique address would be way more risky with 64 bits (there's a reason UUIDs are 128 bits too!), even before considering the network:interface split.
> Future proofing it by jumping straight to 128 bits instead of 64.
It's hard to disagree with your point since 64 would definitely have been better than the 32 we have. I'm not convinced the choice of going for 128 bits posed any real challenge to adoption though.
It's hard to disagree with your point since 64 would definitely have been better than the 32 we have. I'm not convinced the choice of going for 128 bits posed any real challenge to adoption though.
The irony that I forgot to voice is that if we had gone 64 and feeder features we’d be farther along in adoption now and probably be consuming the address space at least a fraction as fast as people feared.
By raising the barrier to entry so high we guaranteed the features would likely never be needed.
By raising the barrier to entry so high we guaranteed the features would likely never be needed.
They did have a proposal for 64bit...was ipv7.
They also had IPv9 with 20 byte addresses (160 bits) though some of that was consumed for common prefix announcing "this is a TUBA address". It was even something that was already supported by some hardware and software, as it was just dropping IP and replacing it with CLNP and transporting TCP and UDP over it (I think the most complex part was adapting ICMP-based tools).
how would you do SLAAC with 64 bits?
Was DHCP so bad? It carries information important to using such a device anyway.
well, its not without issues. the actual motivation was not that dhcp is the suxxors, but to promote a model where the assigned prefix was free and highly dynamic.
the goal being to support a model where one could support multiple prefixes to handle the common case of multiple internet connections. more importantly to allow providers to shuffle the address space around without having to coordinate with the end organization. this was perceived to be necessary to prevent the v6 address space from accruing segmentation.
the goal being to support a model where one could support multiple prefixes to handle the common case of multiple internet connections. more importantly to allow providers to shuffle the address space around without having to coordinate with the end organization. this was perceived to be necessary to prevent the v6 address space from accruing segmentation.
It's funny the "handle the common case of multiple internet connections" just doesn't work at all with ipv6 yet works much better under IPv4 NAT. With IPv6 each machine gets it's own routing table due to having two addresses which means I can't failover on the router when an ISP goes down. Machine will keep trying to use the ISP that is having 100% packet loss. I can't prioritize sending traffic out of one ISP because I'd need to configure it on each machine due to them having their own routing table. With IPv4 the router can handle those rules since its doing NAT for all machines in the network so it gets to choose.
Well that was a failed idea which has since been abandoned by anyone trying to remain half sane while deploying IPv6.
+1, the majority of corporate networks I have seen used DHCPv6 or similar anyway
The same way you do it now. The router announces a prefix, and devices negotiate unique addresses.
Keep in mind that SLAAC isn't. Modern IPv6 stacks use privacy addresses, so they still need to run the address collision detection.
There's also a proposal to have SLAAC with longer prefixes, because otherwise you need to use DHCP-PD if you want to have subnetting in IPv6.
Keep in mind that SLAAC isn't. Modern IPv6 stacks use privacy addresses, so they still need to run the address collision detection.
There's also a proposal to have SLAAC with longer prefixes, because otherwise you need to use DHCP-PD if you want to have subnetting in IPv6.
You don't, and that's fine.
Everything I know about IPv6 comes from this one blog post: https://apenwarr.ca/log/20170810. It’s from 2017, when IPv6 adoption was 17% according to https://www.google.com/intl/en/ipv6/statistics.html; today it’s close to 50%.
I'd assume a lot of this is because of mobile devices of some type. Getting legacy network operators like cable providers to supply IPv6 has been hell.
Eyeball networks and cloud providers have been implementing IPv6. In the US all major phone carriers are v6 only with XLAT, the large residential ISP all have implemented v6 (Charter/Spectrum, Comcast/Xfinity, altice/optimum). The lagging networks are smaller residential ISP and enterprise networks.
In Asia they've implemented v6 everywhere pretty much because their v4 allocation is woefully insufficient. APNIC has like 4 billion people in it but less IP space than ARIN, with a population of less than 500 million.
In Asia they've implemented v6 everywhere pretty much because their v4 allocation is woefully insufficient. APNIC has like 4 billion people in it but less IP space than ARIN, with a population of less than 500 million.
Just because the ISPs have implemented IPv6 doesn't mean anyone's home router is using it, let alone all the devices in the home WiFi
Well the data shows they are in fact using it. Most people use their ISP router which in these carriers would be setup by default to use v6, plus any router bought in the last 10 years would support v6 and probably use it by default.
I'm on a large ISP provider and they do not have IPv6 in my area, a new build with fiber to a access point that turns it to cable on the house. So there's that.
Ah RFoG. It's a weird technology choice. I think it's supposed to be transitional so they get the fiber in the ground now and then can later come back and rip out all the DOCSIS equipment and replace it with *PON
Obviously they are. Most people use the equipment provided by their ISP without ever changing any settings.
If the ISP is IPv6-first, you bet that their customers are using it in their home WiFi.
If the ISP is IPv6-first, you bet that their customers are using it in their home WiFi.
> Getting legacy network operators like cable providers to supply IPv6 has been hell.
In my experience it's actually the large enterprises that are having issues.
In my experience it's actually the large enterprises that are having issues.
Is that worldwide adoption or adoption in the US? China went from almost nothing to 77% adoption is just a few years because they included it in their last 5-year-plan. How much of that adoption would be explained by China alone
Google's stats are Google International, i.e. everywhere Google provides service. Whether that includes China depends on the whims of the Politbüro.
That's the best thing I've read all year. Ok, it's the best thing I've read last year too. I kinda knew all this stuff but I never knew how it all happened. I never thought of MAC as unnecessary in an IPv6 world.
Came to post that blog. It's awesome. Everyone should read it.
> For many, the decision of which protocol to use was easy because IPv6 didn't add features that represented major improvements.
This is the obvious and only key to this puzzle.
We tech nerds have this mad idea that everyone will want to spend time and money adapting to new standards because they're technically better in some abstract way, and so we do absolutely no work to create incentives for anyone to switch. Often, the new standard is not (yet) even functionally equivalent to the old one (e.g. Wayland), just to make doubly sure the switch will be as difficult and undesirable for end users as possible.
And when the absolutely inevitable consequences occur - stakeholders do not want to invest in switching to or developing for new standards that give them zero incentive to do so - there's a silly finger pointing game, as though everyone was supposed to switch, and they've failed to do so. Which is, of course, absurd. People don't owe us compliance.
Do not expect to be able to successfully shift behaviour unless you give people incentives - reasons they would want to switch, not just reasons you want them to switch.
This is the obvious and only key to this puzzle.
We tech nerds have this mad idea that everyone will want to spend time and money adapting to new standards because they're technically better in some abstract way, and so we do absolutely no work to create incentives for anyone to switch. Often, the new standard is not (yet) even functionally equivalent to the old one (e.g. Wayland), just to make doubly sure the switch will be as difficult and undesirable for end users as possible.
And when the absolutely inevitable consequences occur - stakeholders do not want to invest in switching to or developing for new standards that give them zero incentive to do so - there's a silly finger pointing game, as though everyone was supposed to switch, and they've failed to do so. Which is, of course, absurd. People don't owe us compliance.
Do not expect to be able to successfully shift behaviour unless you give people incentives - reasons they would want to switch, not just reasons you want them to switch.
If it ain't broken, don't fix it. Life is short
IPv6 has already won on mobile and been gaining fast traction in IoT space with Matter. The reason IPv4 is still around everywhere else is because we came up with ingeniuous techniques that squeezed the heck out of IPv4 address space. Also, IPv4 addresses are easier to type. That's pretty much it.
I had mentioned some of that in my post: https://ssg.dev/ipv6-for-the-remotely-interested-af214dd06aa...
I had mentioned some of that in my post: https://ssg.dev/ipv6-for-the-remotely-interested-af214dd06aa...
Yes, they are easier to type, and to remember, and it turns out, that's actually a big deal! When you are troubleshooting network problems, it's really nice to take everything but simple raw addresses out of the picture. It's really nice to be able to look at an address and instantly recognize if it's on the same (V)LAN as you are expecting, if it's unique, if it changed from what it was last time you checked, if it's an address for a VPN interface, if the packet you are sniffing is for this host or that host, if DNS is resolving correctly, etc., etc.
I agree that it's a big deal. IPv6 has some "well-known short addresses" to alleviate this issue like accesing well-known broadcast addresses etc with `fe80::` prefix, but it's sad that they don't have one for the gateway (something like `fe80::1`). I know that there's a reason for that like supporting multiple network connections, but just have a shortcut for the "first gateway" at least which is the most common.
You can do the exact same thing in V6 if you want, there are so many extra bits you can have DHCPv6 or assigned addresses pack all kinds of things in there. With ULAs there are 16-bits for network ID, which is so sparse you can type the VLAN ID in decimal and ignore that you're losing the overhead. People will often put in joke address like deadbeef that can be fit into hex (the 40-bit global ID should be random but for hobbyist purposes most people are willing to suffer re-numbering it in the unlikely event their homelab is bought out by IBM). If you'd rather eat into the interface id portion, you can technically do whatever you want in there although packing too much in may locally cause problems in some routers if you try to treat it like additional network id bits. It's the equivalent to have both middle bytes of 10.x.y.z available for whatever while still having a few hundred billion available subnets.
Just as an example google's public DNS is 2001:4860:4860::8888 because their v4 dns is 8.8.8.8.
Just as an example google's public DNS is 2001:4860:4860::8888 because their v4 dns is 8.8.8.8.
Everyone who says this is a web developer. I have yet to actually meet someone with networking experience who has this opinion.
The reason it's not winning in the other places is because Network engineers hate IP version 6 as a rule .
It makes sense that it's won on mobile. In that scenario, NATs are stupid and lots of addresses are needed.
In the data center, fewer addresses are needed and NATs are vital for security.
The reason it's not winning in the other places is because Network engineers hate IP version 6 as a rule .
It makes sense that it's won on mobile. In that scenario, NATs are stupid and lots of addresses are needed.
In the data center, fewer addresses are needed and NATs are vital for security.
Could you please elaborate on what's wrong with it compared to 4?
Where IPv6 is struggling the most is corporate networks. There are many network admins that are afraid of IPv6 and don't want to learn about it, so they just block it at the gateway.
>won on mobile and been gaining fast traction in IoT space
The two worst uses of the internet.
The two worst uses of the internet.
I dunno. A library with a great big chunk of all human knowledge, in my pocket at all times? That sounds like a freaking miracle to me.
My ISP refuses to give you a static IPv6 prefix unless you're a business customer, despite having an "unlimited" amount of them. This results in me not bothering to set it up properly and focusing on IPv4 still.
Do you have a static IPv4, presumably a single IP?
I find it useful, mine does change periodically, but I just have a script that Updates DNS when it changes:
I find it useful, mine does change periodically, but I just have a script that Updates DNS when it changes:
nsupdate -v -y "${KEY_ALGO}:${KEY_NAME}:${KEY_SECRET}" <<EOF
server $DNS_SERVER
zone $ZONE
update delete $RECORD AAAA
update add $RECORD 300 AAAA $CURRENT_IP
show
send
EOF
I don't have a static IPv4 address and I have to use a DDNS built into the Caddy plugin on my OPNSense router. From what I understand, you can't get a static "local" (I know, IPv6 has no direct equivalent) address to use for a reverse proxy — at least not in an easy manner. I might be completely wrong but that's why I don't bother with IPv6.
You’re looking for a Unique Local Address there. It’s a non-externally-routable address that you can use for internal connections.
https://en.wikipedia.org/wiki/Unique_local_address
https://en.wikipedia.org/wiki/Unique_local_address
Yep. ULA addresses are the equivalent of 10.0.0.0/8, 192.168.0.0/24, and 172.16.0.0/12 space. [0] And you can use them to do NAT, just like with IPv4.
The huge difference from the IPv4 world is that the procedure for generating your /48 ULA prefix ensures that it's very, very unlikely that you will get the same prefix as anyone else. So, if everyone follows the procedure, pretty much noone has to worry about colliding with anyone else's network.
Following the procedure has benefits. For example, VPN providers who want to use IPv6 NAT can do that without interfering with the LAN addressing of the host they're deployed to... companies that merge their networking infrastructure together can spend far less (or even zero) time on internal network renumbering... [1] etc, etc, etc.
[0] And link-local addresses are the equivalent of 169.254.0.0/16 space.
[1] Seriously, like a year after one BigCo merger I was subject to, IT had still not fully merged together the two company's networks, and was still in the process of relocating or decommissioning internal systems in order to deal with IPv4 address space constraints. Had they both used ULA everywhere it was possible to do so, they could have immediately gotten into the infosec compliance and cost-cutting part of the network merging, rather than still being mired in the technical and political headaches forced upon them by grossly insufficient address space.
The huge difference from the IPv4 world is that the procedure for generating your /48 ULA prefix ensures that it's very, very unlikely that you will get the same prefix as anyone else. So, if everyone follows the procedure, pretty much noone has to worry about colliding with anyone else's network.
Following the procedure has benefits. For example, VPN providers who want to use IPv6 NAT can do that without interfering with the LAN addressing of the host they're deployed to... companies that merge their networking infrastructure together can spend far less (or even zero) time on internal network renumbering... [1] etc, etc, etc.
[0] And link-local addresses are the equivalent of 169.254.0.0/16 space.
[1] Seriously, like a year after one BigCo merger I was subject to, IT had still not fully merged together the two company's networks, and was still in the process of relocating or decommissioning internal systems in order to deal with IPv4 address space constraints. Had they both used ULA everywhere it was possible to do so, they could have immediately gotten into the infosec compliance and cost-cutting part of the network merging, rather than still being mired in the technical and political headaches forced upon them by grossly insufficient address space.
Problem with ULA is that it's functionally useless on a dual-stack network, because clients will attempt to use IPv4 before they attempt to use ULA.
https://blog.apnic.net/2022/05/16/ula-is-broken-in-dual-stac...
https://blog.apnic.net/2022/05/16/ula-is-broken-in-dual-stac...
> Problem with ULA is that it's functionally useless on a dual-stack network.
Nope, it works just fine. I use it for stable local addressing and LAN host AAAA records and let my ISP-delegated global prefix drift as my ISP wishes it to.
And -as it happens- the prose in that article about source address selection is incorrect.
On Linux, source address preference appears to be application-specific. For example, curl prefers IPv6 addresses, and falls back to IPv4 if the v6 connection fails. I checked just now by removing my globally-assigned IPv6 address, and capturing the traffic created by executing 'curl https://www.google.com'. I know for a fact that BIND 9 prefers non-link-local IPv6 source addresses over IPv4 addresses because until I set up my home-built router to reject Internet-bound traffic coming from my ULA, a sufficiently-long failure of the DHCPv6 server run by my ISP would cause name resolution to get very, very, very slow when the global prefix expired and BIND started using its host's ULA as a source address and my router dutifully relayed that traffic into my ISP's black hole. I'm certain that very many applications unconditionally prefer non-link-local IPv6 addresses over IPv4 ones. You might also care to pay attention to this comment and its publication date: [0]
OTOH, Firefox prefers IPv4 connections in that scenario and doesn't even attempt a v6 connection. I assume Chrome is the same way.
And, that article suggests GUA space as a replacement for ULA space:
> All of these are serious pitfalls that arise when attempting to use ULA. The simple and more elegant answer is to simply leverage GUAs.
Which... uh... no. I'd have to go through my local RIR to get an allocation, and then negotiate with my ISP to get it routed. Given that I'd have to go through ARIN because I'm in the US, and I have a boring residential account with my ISP, neither of those things will ever happen. The entire point of ULA is that no coordination with external entities is required to do network-local addressing.
Also, the documentation that that article links to to discourage people from deploying NAT66 is almost literally "It's exactly as complicated as NAT44. Why do it when you can get global IPv6 addresses?!?", which isn't a useful complaint when your intent is to exactly replicate what you get from IPv4 NAT in an IPv6 world. I agree that globally-routable addresses are better, but if your site admin demands (for whatever reason) that you not have them, then -because of the collision-avoidance property of the ULA prefix generation procedure- you're better off than with IPv4 NAT.
[0] <https://blog.apnic.net/2022/05/16/ula-is-broken-in-dual-stac...>
Nope, it works just fine. I use it for stable local addressing and LAN host AAAA records and let my ISP-delegated global prefix drift as my ISP wishes it to.
And -as it happens- the prose in that article about source address selection is incorrect.
On Linux, source address preference appears to be application-specific. For example, curl prefers IPv6 addresses, and falls back to IPv4 if the v6 connection fails. I checked just now by removing my globally-assigned IPv6 address, and capturing the traffic created by executing 'curl https://www.google.com'. I know for a fact that BIND 9 prefers non-link-local IPv6 source addresses over IPv4 addresses because until I set up my home-built router to reject Internet-bound traffic coming from my ULA, a sufficiently-long failure of the DHCPv6 server run by my ISP would cause name resolution to get very, very, very slow when the global prefix expired and BIND started using its host's ULA as a source address and my router dutifully relayed that traffic into my ISP's black hole. I'm certain that very many applications unconditionally prefer non-link-local IPv6 addresses over IPv4 ones. You might also care to pay attention to this comment and its publication date: [0]
OTOH, Firefox prefers IPv4 connections in that scenario and doesn't even attempt a v6 connection. I assume Chrome is the same way.
And, that article suggests GUA space as a replacement for ULA space:
> All of these are serious pitfalls that arise when attempting to use ULA. The simple and more elegant answer is to simply leverage GUAs.
Which... uh... no. I'd have to go through my local RIR to get an allocation, and then negotiate with my ISP to get it routed. Given that I'd have to go through ARIN because I'm in the US, and I have a boring residential account with my ISP, neither of those things will ever happen. The entire point of ULA is that no coordination with external entities is required to do network-local addressing.
Also, the documentation that that article links to to discourage people from deploying NAT66 is almost literally "It's exactly as complicated as NAT44. Why do it when you can get global IPv6 addresses?!?", which isn't a useful complaint when your intent is to exactly replicate what you get from IPv4 NAT in an IPv6 world. I agree that globally-routable addresses are better, but if your site admin demands (for whatever reason) that you not have them, then -because of the collision-avoidance property of the ULA prefix generation procedure- you're better off than with IPv4 NAT.
[0] <https://blog.apnic.net/2022/05/16/ula-is-broken-in-dual-stac...>
Note that although the policy is that you choose a random prefix, nothing actually enforces this and nothing stops you using fd00::1, fd00::2, etc just like 10.0.0.1 etc.
I technically have a dynamic IPv4 address from my ISP. I've had the same for five years now, across multiple power outages.
I also have a dynamic IPv6 prefix. That one changes at least once a week, regardless.
I also have a dynamic IPv6 prefix. That one changes at least once a week, regardless.
My ISP is xfinity. They say the same thing but my IPv6 address hasn't changed any more frequently than my IPv4. In my experience it changing isn't any more annoying than my v4 changing so I'm not sure why people still get up in arms about it.
In about a year of treating my comcast-assigned ipv6 address as static, it changed once.
Sadly, this happened despite me specifically requesting the same address as always. That caused me some grief. But it's not common.
Sadly, this happened despite me specifically requesting the same address as always. That caused me some grief. But it's not common.
On the other end of the connection, there are physical servers and routers. Every once in a while they change how things are connected/deployed for maintenance, upgrades, etc.
Pretty much, I have my cable modem on continuous power and it will keep the same address pretty much forever. Two times it changed is when I had a 48 hour power outage and shut everything down, and the other time was maintenance at the cable companies side where they rebooted their equipment.
My xfinity ipv4 changes once every few years, if that. I treat it as static and update things if or when it changes, which fortunately isn’t too much work. I never requested anything special regarding it, and I have a normal/non-business account. I wonder why some change often and others don’t?
I had Xfinity for 4 years and my IP changed once in that time! Now I have fiber from centurylink, and it changes anytime I need to reboot the fiber modem or my firewall. Different companies, same metro area though. That too makes me wonder about how both manage their allocations give the difference in IP assignments.
This should be illegal. Yes, in this case, I'm not saying that as a figure of speech. ISPs are a utility, and building that kind of artificial scarcity into something that is really damned near infinite is highly anti-consumer.
Get a virtual server and do the things on it that you'd want a static address for. Use a VPN connection back to your home to merge it with your network. This is a great way to deal with CGNAT.
My ISP (naming no names...erum...Spectrum) refuses to even admit they know what IPv6 is. It's like asking the NSA what Menwith Hill is for...
https://www.spectrum.net/support/internet/ipv6
https://www.spectrum.net/support/internet/ipv6-faq
> IPv6 is available today with an IPv6 capable modem in the majority of Spectrum’s footprint.
https://www.spectrum.net/support/internet/ipv6-faq
> IPv6 is available today with an IPv6 capable modem in the majority of Spectrum’s footprint.
I've had v6 on spectrum for 5 years
I recently moved house and looked at a new offer from a new ISP for a long term lockin but a cheap price. They used CG-NAT. I instead chose one which gives me as many ipv4s or ipv6s as I can reasonably use, doesn't oversubscribe its upsteam connectivity etc.
For home internet service I would prefer to pay extra for a better service, it's too important to try to penny-pinch 0.1% of my income on it.
But then I live in a capitalist country where there's competition, I believe some countries you don't get a choice.
For home internet service I would prefer to pay extra for a better service, it's too important to try to penny-pinch 0.1% of my income on it.
But then I live in a capitalist country where there's competition, I believe some countries you don't get a choice.
FYI it's practically impossible not to oversubscribe your upstream connectivity unless they either spend way too much money or offer very slow service to users. Consider ten thousand users with 1G connections - should they have 10 terabit upstream?
The more practical thing to look for is that they aim to upgrade it based on need, instead of arbitrarily throttling the users.
The more practical thing to look for is that they aim to upgrade it based on need, instead of arbitrarily throttling the users.
100g interconnects are very cheap, but I'm more talking about oversubscription in the ISP network -- as they have multiple peering and transit arrangements it's clear that if you have 10,000gbit worth of customers, you don't need 10tbit of connectivity for each transit provider.
Where I live the cable system is fine, and the cellular system is fine... until one goes down, then the other gets flooded with traffic and stops working leaving no internet at all.
For those in the UK who want a static IPv4 or IPv6 block AAISP offer a L2TP service for £2/month. It's limited to 3 megabit/s but might be enough for some use cases.
Same here, I had a working IPv6 setup previously with my DSL provider, but now that I moved to a fibre connection, the new one refuses to support it.
But do they give you PD?
My prefix is tied to the mac address of the device that's connected to the PON.
My prefix is tied to the mac address of the device that's connected to the PON.
It was doomed the moment you had to maintain two separate stacks, each with its own address, firewall rules and so on.
It should have been ipv4 with extra optional bits, so you could have the same rules and everything for both stacks.
I turn it off because it's a risk having one of either stacks malconfigured.
IPv6 should've been a superset of IPv4, as in addresses are shared, not that you have a separate IPv4 and IPv6 address for your server.
It should have been ipv4 with extra optional bits, so you could have the same rules and everything for both stacks.
I turn it off because it's a risk having one of either stacks malconfigured.
IPv6 should've been a superset of IPv4, as in addresses are shared, not that you have a separate IPv4 and IPv6 address for your server.
That’s why my home network is IPv6 only. NAT64 and DNS64 and 464XLAT work very well, and you only need to configure IPv4 once: in your router, where you need special configuration anyways.
What do you do about IoT devices?
Why would that be a desirable quality? Wifi devices (using Matter or not) live on the same network as my PC - meaning a compromised lightbulb (or one that hasn't been updated) can be used to infiltrate and attack my home computers.
Thread+ Matter, despite using a different radio, suffers from the same issue, since a border router is on the Wifi network, a smart bulb using Thread can theoretically access my PC.
Yes, I'm sure there are ways to fix this, but why have the problem in the first place?
Zigbee is entirely incompatible networking standard, and doesn't have this problem.
Thread+ Matter, despite using a different radio, suffers from the same issue, since a border router is on the Wifi network, a smart bulb using Thread can theoretically access my PC.
Yes, I'm sure there are ways to fix this, but why have the problem in the first place?
Zigbee is entirely incompatible networking standard, and doesn't have this problem.
[deleted]
for me, I don't need to even setup NAT64. My ISP provides it for me free.
Another day, another Godwin's law of networking.
>It was doomed the moment you had to maintain two separate stacks
Pray, tell me, how are we supposed to extend IPv4 with another {insert a number here} bits without creating a new protocol (that neccessitates running two stacks)?
Suppose that you have an old computer that understands only 32 bit addresses -- good ol' IPv4. Let's name it 192.168.10.10.
It then receives a packet from another computer with hypothetical "IPv4+" support, 172.12.10.98.12.4.24.31... ...Wait a minute, it can't, because your old computer understands only 32 bit addresses!
What if we really forced it to receive the packet anyway? It will see that the packet is from 172.12.10.98, because once again, it understands 32 bit addresses only.
It then sends back the reply to... you guessed it, 172.12.10.98. Not 172.12.10.98.12.4.24.31.
Yeah,172.12.10.98.12.4.24.31 will never get its reply back.
Do you see why any "IPv4 with extra octets" proposal are doomed to begin with now?
>It was doomed the moment you had to maintain two separate stacks
Pray, tell me, how are we supposed to extend IPv4 with another {insert a number here} bits without creating a new protocol (that neccessitates running two stacks)?
Suppose that you have an old computer that understands only 32 bit addresses -- good ol' IPv4. Let's name it 192.168.10.10.
It then receives a packet from another computer with hypothetical "IPv4+" support, 172.12.10.98.12.4.24.31... ...Wait a minute, it can't, because your old computer understands only 32 bit addresses!
What if we really forced it to receive the packet anyway? It will see that the packet is from 172.12.10.98, because once again, it understands 32 bit addresses only.
It then sends back the reply to... you guessed it, 172.12.10.98. Not 172.12.10.98.12.4.24.31.
Yeah,172.12.10.98.12.4.24.31 will never get its reply back.
Do you see why any "IPv4 with extra octets" proposal are doomed to begin with now?
It wouldn't be able to receive it. That simple. Which is not a problem, any server would still have an old ipv4 address (172.12.10.98 from your example), like they currently do and probably will for decades.
Devil's advocate. There could be a extension for ipv4 stacks. Ipv4 stacks would need to be modified to include the extension in any reply to a packet received with one. It would also be a dns modification to append the extension if is in the record. Ipv6 stacks would either internally reconstruct the packet as if it were ipv6.
It would be easy to make such an extension, but you're going to hit the same problem v6 did: no v4 stacks use your extension.
How will you fix that? By gradually reinventing v6, one constraint at a time. You're trying to extend v4, so you can't avoid hitting all of the same limits v6 did when it tried to do the same thing. In the end you'll produce something that's exactly as hard to deploy as 6to4 is, but v6 already did 6to4 so you achieved nothing.
How will you fix that? By gradually reinventing v6, one constraint at a time. You're trying to extend v4, so you can't avoid hitting all of the same limits v6 did when it tried to do the same thing. In the end you'll produce something that's exactly as hard to deploy as 6to4 is, but v6 already did 6to4 so you achieved nothing.
Having just optional field in the ipv4 header with extra address bits would leave all the stack source code with just some 100 lines of extra code. Would mean, you can have one stack that handles just both. Make special addresses where the additional bits are all 0, which means the field is not there at all. These addresses could reach ipv4 only addresses and could be reached from them.
When you really want to make sure these devices aren't parsing ipv4+ packets, change the checksum-code for all packages that contain the optional field. That would mean all ipv4 only devices would ignore ipv4+ packages. Instead you could change the version to 5 for all with optional address bits.
This is stuff that could be implemented in any ipv4 stack in some days of work.
IPv6 is overengineered, thats the reason why it's not adopted after 30 years.
This is stuff that could be implemented in any ipv4 stack in some days of work.
IPv6 is overengineered, thats the reason why it's not adopted after 30 years.
You clearly do not understand networking. Or else you won't make such a statement:
>This is stuff that could be implemented in any ipv4 stack in some days of work.
The sysadmins across the world, who had to deal with decades-old, never-updated devices facepalmed in unison.
At least the other comment agreed that "IPv4+" hosts will never be able to talk to IPv4 hosts.
>IPv6 is overengineered, thats the reason why it's not adopted after 30 years.
It is already adopted in many countries. Don't blame the protocol for your countrymen's incompetence.
>This is stuff that could be implemented in any ipv4 stack in some days of work.
The sysadmins across the world, who had to deal with decades-old, never-updated devices facepalmed in unison.
At least the other comment agreed that "IPv4+" hosts will never be able to talk to IPv4 hosts.
>IPv6 is overengineered, thats the reason why it's not adopted after 30 years.
It is already adopted in many countries. Don't blame the protocol for your countrymen's incompetence.
And 2 listeners
I remember 10+ years ago we were going to run out of IPv4 addresses and it was the next Y2K unless you adopted IPv6. I was able to get IPv6 for my servers and home, and I thought I was safe!
> "In fact, IPv4's continued viability is largely because IPv6 absorbed that growth pressure elsewhere – particularly in mobile, broadband, and cloud environments," he added. "In that sense, IPv6 succeeded where it was needed most, and must be regarded as a success."
Apparently it turns out IPv6 wasn't for me any way!
> "In fact, IPv4's continued viability is largely because IPv6 absorbed that growth pressure elsewhere – particularly in mobile, broadband, and cloud environments," he added. "In that sense, IPv6 succeeded where it was needed most, and must be regarded as a success."
Apparently it turns out IPv6 wasn't for me any way!
My prediction [0]: It will take roughly 100 years for IPv6 to be ubiquitous enough to shut off IPv4. That's not intended as hyperbole, if anything it's an understatement.
Because, it's not going away: You can talk all you want about how IPv6 should have been a more straightforward expansion of the address size, but this is all in the rear-view mirror at this point. IPv6 is going to be with us forever, you may as well get used to it. It's already everywhere in 5G deployments, ISP's like Comcast use it for 100% of their out-of-band management, China is making huge progress moving to it as part of their 5-year plan, India is progressing nicely in their transition, the list goes on. We're already way too far along in the transition to abandon it in favor of something else.
But it's not going to happen any quicker than we've seen, either: There's no urgency (no "must-have" use case) except for what organizations are imposing on themselves. Yeah, IPv4 addresses are more expensive, but you don't really need many of them as a business (you can get by with a small handful of public ones, and just using L7 load balancers and SNI for everything) nor as an ISP (CGNAT can get you a long way.)
So we have a situation where things are migrating very slowly, mainly only in places where it makes sense (mobile deployments, home ISP's where the users don't actually administer the network), and generally mostly for new deployments. This is a recipe for IPv4 to be around for a very, very long time. We're used to technology moving at breakneck pace, but that's only the case for the higher-level stuff. The core infrastructure like the internet protocol is likely the textbook example of slow-and-steady, and a case where it's actually not crazy to think of centuries-long timeframes for things.
[0] Barring any unforeseen black-swan events like a world war destroying all technology and having to rebuild from scratch or something. Or a competent international agreement to aggressively migrate to it (I don't know which is more likely.)
Because, it's not going away: You can talk all you want about how IPv6 should have been a more straightforward expansion of the address size, but this is all in the rear-view mirror at this point. IPv6 is going to be with us forever, you may as well get used to it. It's already everywhere in 5G deployments, ISP's like Comcast use it for 100% of their out-of-band management, China is making huge progress moving to it as part of their 5-year plan, India is progressing nicely in their transition, the list goes on. We're already way too far along in the transition to abandon it in favor of something else.
But it's not going to happen any quicker than we've seen, either: There's no urgency (no "must-have" use case) except for what organizations are imposing on themselves. Yeah, IPv4 addresses are more expensive, but you don't really need many of them as a business (you can get by with a small handful of public ones, and just using L7 load balancers and SNI for everything) nor as an ISP (CGNAT can get you a long way.)
So we have a situation where things are migrating very slowly, mainly only in places where it makes sense (mobile deployments, home ISP's where the users don't actually administer the network), and generally mostly for new deployments. This is a recipe for IPv4 to be around for a very, very long time. We're used to technology moving at breakneck pace, but that's only the case for the higher-level stuff. The core infrastructure like the internet protocol is likely the textbook example of slow-and-steady, and a case where it's actually not crazy to think of centuries-long timeframes for things.
[0] Barring any unforeseen black-swan events like a world war destroying all technology and having to rebuild from scratch or something. Or a competent international agreement to aggressively migrate to it (I don't know which is more likely.)
I’m honestly a bit surprised that the move to v6 has even been this strong considering the arguably-small-but-clearly-significant-enough downsides.
The world could pretty easily run on heavily NATed v4 for a long, long time.
The world could pretty easily run on heavily NATed v4 for a long, long time.
It kind of has. The majority of internet traffic is IPv6. The three biggest internet hub regions (USA, Europe, China) have IPv6 mandates. Most apps support IPv6. Google and Apple force them to, od they get kicked off the app store. Almost all mobile networks (which means almost all end devices) are IPv6-only, with slow inefficient tunneling for IPv4. The price of IPv4 addresses is declining.
At what point will we be allowed to say IPv6 hasn't failed? When the IPv4 internet finally switches off for good? It feels like no achievement is high enough for those who don't like IPv6 to change their minds. I would've thought making up 50% of internet traffic and 50% of end devices being on IPv6-only networks would be good Schelling points, but evidently they're not!
At what point will we be allowed to say IPv6 hasn't failed? When the IPv4 internet finally switches off for good? It feels like no achievement is high enough for those who don't like IPv6 to change their minds. I would've thought making up 50% of internet traffic and 50% of end devices being on IPv6-only networks would be good Schelling points, but evidently they're not!
> At what point will we be allowed to say IPv6 hasn't failed?
"IPv6 ... still hasn't taken over the world [after thirty years of deployment]." is a very different statement than "IPv6 has failed.".
Noone who has successfully extracted their head from their ass says that IPv6 has failed. It's widely deployed on the Internet, and on who knows how many corporate intranets and SOHO/home LANs.
IMO, it's stupid to ever consider turning off IPv4. There surely exist useful systems out there that will never be updated to work with IPv6.
I see IPv6 as an "IPv4 address pressure relief system". In the future, SOHO/home LANs can run servers on IPv6, datacenters can run servers mostly on IPv6 but also v4 if they really want, and SOHO/home networks can be behind an IPv4 CGN because all of their unsolicited inbound traffic will come over IPv6.
"IPv6 ... still hasn't taken over the world [after thirty years of deployment]." is a very different statement than "IPv6 has failed.".
Noone who has successfully extracted their head from their ass says that IPv6 has failed. It's widely deployed on the Internet, and on who knows how many corporate intranets and SOHO/home LANs.
IMO, it's stupid to ever consider turning off IPv4. There surely exist useful systems out there that will never be updated to work with IPv6.
I see IPv6 as an "IPv4 address pressure relief system". In the future, SOHO/home LANs can run servers on IPv6, datacenters can run servers mostly on IPv6 but also v4 if they really want, and SOHO/home networks can be behind an IPv4 CGN because all of their unsolicited inbound traffic will come over IPv6.
>IPv6 ... still hasn't taken over the world [after thirty years of deployment]." is a very different statement than "IPv6 has failed.".
It's incredibly likely that the GP was referring to comments in this thread, which were indeed claiming that IPv6 has failed, despite the fact that its deployment has been steadily climbing up worldwide.
By the way...
>In the future, SOHO/home LANs can run servers on IPv6
The future is now. My web server is IPv6 only precisely due to the same reason you mentioned: my ISP has put me under a CGNAT. People can still connect to my website through the Cloudflare reverse proxy though (which I have only enabled for IPv4, IPv6 users get to enjoy direct connection).
It's incredibly likely that the GP was referring to comments in this thread, which were indeed claiming that IPv6 has failed, despite the fact that its deployment has been steadily climbing up worldwide.
By the way...
>In the future, SOHO/home LANs can run servers on IPv6
The future is now. My web server is IPv6 only precisely due to the same reason you mentioned: my ISP has put me under a CGNAT. People can still connect to my website through the Cloudflare reverse proxy though (which I have only enabled for IPv4, IPv6 users get to enjoy direct connection).
> The future is now.
One part of it is for some-to-many folks, yes, and the third is here for a distressingly large number of people (without the solid support of the second part). Do note that the future I outlined has three parts. ;)
One part of it is for some-to-many folks, yes, and the third is here for a distressingly large number of people (without the solid support of the second part). Do note that the future I outlined has three parts. ;)
I've been native IPv6 at home for a few years now. That worked flawlessly until a recent Windows 11 update somehow broke IPv6 in ways that I don't entirely understand. All the other Linux and Apple and et cetera things in my house are fine, but the Win11 laptop just refuses to handle certain IPv6 ranges (specifically including the address that the host interface for one of my web servers falls in). 100% contained within the Win11 device and TBH I can't be bothered to dig into it further so I just proxy through some other device that does work. (Guessing it'll get fixed a month/year/decade or so from now.)
I agree it's not a failure, but after 3 decades it's still frustratingly annoying to use at times.
I agree it's not a failure, but after 3 decades it's still frustratingly annoying to use at times.
I had a much less annoying time with ipv6 on windows after I explicitly disabled all ipv6 tunnel interfaces.
https://learn.microsoft.com/en-us/troubleshoot/windows-serve...
https://learn.microsoft.com/en-us/troubleshoot/windows-serve...
> I agree it's not a failure, but after 3 decades it's still frustratingly annoying to use at times.
Anyone sane would call a standard that remains annoying to use after 30 years a failure.
Anyone sane would call a standard that remains annoying to use after 30 years a failure.
I agree. Windows is a failure.
Maybe a different take, but as someone that manages a large public API that allows anonymous access, IPv6 has been a nightmare to try and enforce rate limits on. We've found different ISPs assign IPv6 addresses differently - some give a /64 to every server, some give /64 to an entire data center. It seems there is no standard and everyone just makes up what they think will work. This puts us in an awkward place where we need abuse protections, but have to invest into more complicated solutions that were needed for IPv4. Or we give up and just say if you want to use IPv6, you have to authenticate.
Does anyone have any success stories from the server side handling a situation like this? Looks like cloudflare switched to some kind of custom dynamic rate limiting based on like addresses, but it's unrealistic to expect everyone to be able to do such a thing.
Does anyone have any success stories from the server side handling a situation like this? Looks like cloudflare switched to some kind of custom dynamic rate limiting based on like addresses, but it's unrealistic to expect everyone to be able to do such a thing.
The ISPs assigning only /64s to whole data centers are not following the standards and best practices. For rate limiting I would block at the /64 level. Just like if someone is behind a CG-NAT they might run into ip reputation issues. They need to complain to their carrier about the poor service/configuration or switch providers.
Common practice is to block no finer than /64s. If you treat an IPv6 /64 like an IPv4 /32, you should be off to the races.
I was in college when v6 was going through the RFC process. In my networking class we had to learn Netware (IPX) and v6, which have both turned out to be equally irrelevant, for different reasons. At this stage, I fully expect to retire having never deployed a single resource using v6.
I think 30 years should be much more than enough to realise the idiocy of proposing a non-backward-compatible standard to the general public.
We replaced VHS with DVDs. It took 42 years before we gave up on VHS. DVDs have been around for 29 years but were mostly replaced with BDs before disappearing off the shelves in favor of streaming.
We replaced records with tapes, tapes with more tapes, and more tapes with CDs before they, too, disappeared from the shelves in favor of streaming. Except that some stalwarts have successfully resurrected vinyl.
We replaced AM with FM, and analog radio with digital radio, then streaming. We replaced broadcast analog TV with digital, then cable and satelite, then streaming. Mostly.
None of these changes were backwards compatible, and all of them were meant for the general public. They took a while. They were successful.
We replaced records with tapes, tapes with more tapes, and more tapes with CDs before they, too, disappeared from the shelves in favor of streaming. Except that some stalwarts have successfully resurrected vinyl.
We replaced AM with FM, and analog radio with digital radio, then streaming. We replaced broadcast analog TV with digital, then cable and satelite, then streaming. Mostly.
None of these changes were backwards compatible, and all of them were meant for the general public. They took a while. They were successful.
The quality jump from vhs to dvd was massive. In comparison v6 doesn't offer much above v4
Yes, I've never played a DVD or CD on my Bluray player. That just didn't works.
Anyone who bought DVD player immediately had the benefits of better quality. The same applies to all other examples.
The problem with IPv6 is that you don't get benefits. If the designed protocol needs an equivalent of big bang, it's doomed. ASCII->UTF8 didn't need big bang. x86 to Itanium needed big bang.
The problem with IPv6 is that you don't get benefits. If the designed protocol needs an equivalent of big bang, it's doomed. ASCII->UTF8 didn't need big bang. x86 to Itanium needed big bang.
[deleted]
You'd think it would be long enough for people to realize that v6 is backwards compatible! Yet no, here we are, constantly dealing with people making the same damn claim that it isn't every single time a v6 story is posted.
v6 is about as backwards compatible with v4 as it's possible to be. If you have a way to make it more backwards compatible then I'd love to hear it, but when I ask this all I ever get are things that don't work, or things that v6 already does.
v6 is about as backwards compatible with v4 as it's possible to be. If you have a way to make it more backwards compatible then I'd love to hear it, but when I ask this all I ever get are things that don't work, or things that v6 already does.
No, it's not. If I have an ipv6 network, an ipv4 address is invalid. It's that simple.
It's not that simple at all. For one thing, having a v6 network doesn't mean you can't have a v4 network. You can run v4 in exactly the same way you currently do, with exactly the same software, and it'll work no worse than it already does.
But for another, the v4 space is available as a subset of the v6 space:
But for another, the v4 space is available as a subset of the v6 space:
$ ping 64:ff9b::8.8.8.8
PING 64:ff9b::8.8.8.8(64:ff9b::808:808) 56 data bytes
64 bytes from 64:ff9b::808:808: icmp_seq=1 ttl=113 time=9.82 ms
The point of backwards compatibility would be to allow IPv4 devices to work on an IPv6 network. Not to run a parallel stack.
127.0.0.1 needed to be a valid IPv6 address, along with all the others. Pick a particular prefix, say 0...* and any address with that would be extended to 128 bits. That would have been backwards compatible.
127.0.0.1 needed to be a valid IPv6 address, along with all the others. Pick a particular prefix, say 0...* and any address with that would be extended to 128 bits. That would have been backwards compatible.
No, that would be forwards compatibility. v4 doesn't have forwards compatibility with any address protocol that uses addresses bigger than 32 bits, and it never will regardless of how that protocol is designed because the flaw is in v4's design.
There is no possible way to design an address protocol with bigger addresses than v4 that a) makes v4 forward compatible with it, and b) can actually work. Feel free to suggest one.
> .0.0.1 needed to be a valid IPv6 address, along with all the others. Pick a particular prefix, say 0...* and any address with that would be extended to 128 bits
That prefix is ::ffff:0:0/96. 127.0.0.1 is ::ffff:127.0.0.1 (::ffff:7f00:1). 30 years and you still haven't realized v6 has this?
There is no possible way to design an address protocol with bigger addresses than v4 that a) makes v4 forward compatible with it, and b) can actually work. Feel free to suggest one.
> .0.0.1 needed to be a valid IPv6 address, along with all the others. Pick a particular prefix, say 0...* and any address with that would be extended to 128 bits
That prefix is ::ffff:0:0/96. 127.0.0.1 is ::ffff:127.0.0.1 (::ffff:7f00:1). 30 years and you still haven't realized v6 has this?
No, it’s not—IPv6 networks are totally capable of providing IPv4 as a service. SIIT-DC, 464XLAT, MAP-T
It's often impossible to make backwards-compatible changes to a format which wasn't designed to allow for future changes and which is designed to be as space-efficient as possible.
That doesn't mean that the limits of the old design won't hit anyway and force a switch off it.
That doesn't mean that the limits of the old design won't hit anyway and force a switch off it.
IPv4 allows future changes. There are some reserved bits in the header that could change a big part of it.
v4 supports extension headers and over a thousand bytes of arbitrary payload so if the only thing you needed was a couple of bits in the packet, there was never any issue with finding them.
The problem is that you can't use those bits to expand v4's address space, without taking all of the same steps v6 needed to do. v4 has no mechanism to get v4 hosts to understand extra address bits, wherever you put them.
Oh, that and the fact that IP addresses are stored in many more places than just the v4 packet header. Consider DNS, DHCP, ARP, gethostbyname(), struct sockaddr_in, databases using VARCHAR(15), etc etc etc. The packet header is only a tiny part of the story.
The problem is that you can't use those bits to expand v4's address space, without taking all of the same steps v6 needed to do. v4 has no mechanism to get v4 hosts to understand extra address bits, wherever you put them.
Oh, that and the fact that IP addresses are stored in many more places than just the v4 packet header. Consider DNS, DHCP, ARP, gethostbyname(), struct sockaddr_in, databases using VARCHAR(15), etc etc etc. The packet header is only a tiny part of the story.
The problem is that IPv4 has no provisions to be forward-compatible with anything with a larger address space. Thus whatever replacement you can think of will have the same problems as IPv6.
I use multiple Google accounts to segregate the data that gets collected on each one - as I don't like having, say, TV logged in to the same account where I send my emails from. One of them, which I use exclusively for Gemini, was banned today (I violated no policies, Google just doesn't like the way I try to sanitize its access I guess).
Now, I can simply restart my router (or cycle airplane mode on mobile) and get a new IPv4 that probably was used by bazillion people before me, or even along with me, and get a new account. So Google has to be very careful here, with IP-linked bans in order to not just ban the whole load of unconnected people just because they used the same IPv4 as me.
With IPv6, they could just ban my entire family and any guests that might have connected to my WiFi, forever.
I like the limitations of IPv4, thank you.
Now, I can simply restart my router (or cycle airplane mode on mobile) and get a new IPv4 that probably was used by bazillion people before me, or even along with me, and get a new account. So Google has to be very careful here, with IP-linked bans in order to not just ban the whole load of unconnected people just because they used the same IPv4 as me.
With IPv6, they could just ban my entire family and any guests that might have connected to my WiFi, forever.
I like the limitations of IPv4, thank you.
Doesn’t IPv6 have random, anonymous addresses (RFC 4941)? Further, user fingerprinting flourishes without IP addresses.
> Doesn’t IPv6 have random, anonymous addresses
Only for the device identifier part of the address. Prefix that the ISP will allocate will remain static, unless ISP does rotate the prefix too, which they don't really have a need to, unless for privacy reasons. And knowing ISPs and demand for privacy, it's highly unlikely to happen.
> Further, user fingerprinting flourishes without IP addresses.
It does, but is still hard to do. Static IP prefix is going to make the heuristics much, much better.
Besides, evading most of the fingerprinting techniques is not that complicated - most of it is in the hands of the client. IPv6 adds something out of the hands of the client.
Only for the device identifier part of the address. Prefix that the ISP will allocate will remain static, unless ISP does rotate the prefix too, which they don't really have a need to, unless for privacy reasons. And knowing ISPs and demand for privacy, it's highly unlikely to happen.
> Further, user fingerprinting flourishes without IP addresses.
It does, but is still hard to do. Static IP prefix is going to make the heuristics much, much better.
Besides, evading most of the fingerprinting techniques is not that complicated - most of it is in the hands of the client. IPv6 adds something out of the hands of the client.
Many ISPs do rotate the prefixes that they assign to customers. There’s plenty of people on here complaining about it as a reason not to use IPv6.
The problem is google
Yes, it is. But it's not just Google. User fingerprinting is already a massive market and is growingly user hostile. There's at least one HN post each month of someone losing access to their account for no real reason and no way to get it back.
I don't want internet infrastructure to support this behavior. On contrary, I want it to resist it, and IPv4 does, to some extent, while IPv6 makes it much easier.
I don't want internet infrastructure to support this behavior. On contrary, I want it to resist it, and IPv4 does, to some extent, while IPv6 makes it much easier.
I'm genuinely wondering if western governments (UK) will start issuing ipv6 addresses out to citizens as their digital id so they can track them online and offline.
Only half joking, some UK MPs might actually consider this a reasonable thing considering how many ipv6s there are.
Only half joking, some UK MPs might actually consider this a reasonable thing considering how many ipv6s there are.
That wouldn't work anyway. IPv6 addresses aren't routable on an address-by-address basis.
Whether it's workable or not it's besides the point when certainly the UK gov gets it in mind to implement.
Yeah but the digital ID could be the 64bit suffix of the IP. Kind of like that horrendous and moronic idea of using the MAC address as the suffix.
But Mobile IP could do it https://www.rfc-editor.org/rfc/rfc6275
It's not at all clear to me that Mobile IP would be viable at the scale of a modern wireless service provider. It amounts to routing all traffic to/from the mobile device through a machine on the network of its "home" IP address. Without some fairly invasive routing shenanigans, this would be disastrously bad for users traveling far from their home network (e.g. a user gone on vacation).
Not that it matters, really. As far as I'm aware, there were never any substantial deployments of this protocol.
Not that it matters, really. As far as I'm aware, there were never any substantial deployments of this protocol.
I was more responding to OP's tongue in cheek comment about government assigned addresses
Since ipv6 is just a 128-address, you could say any unique national ID is already an assigned ipv6. Heck, if you assign your services a UUID, you have also already assigned them an ipv6.
What makes an ipv6 useful is that you can route to it. Since you will never be connected to the network. The network will never be able to route packets to you, making the whole thing a little pointless.
What makes an ipv6 useful is that you can route to it. Since you will never be connected to the network. The network will never be able to route packets to you, making the whole thing a little pointless.
We're not routable yet. Fairly certain people are trying to create computer/brain interfaces...
I'm thinking the gov issuing you an ipv6 address that you must use to connect to the internet. But it's also you're id too, since nearly all services are either online or getting pushed that way.
I'm thinking the gov issuing you an ipv6 address that you must use to connect to the internet. But it's also you're id too, since nearly all services are either online or getting pushed that way.
Contrary to some other comments: no, IPV6 hasn't taken over the world at all.
In my case, I administrate a small server at home, where I self host many services that are made available to myself, friends and families, over the internet.
In that context, IPv6, is SADLY (please note that I have NOTHING against IPv6), a limitation, even a nightmare to use.
Some programs do not handle IPv6 at all. Game servers for instance, do not support it, the one that I think about is: Arma 3. But there are many others
In 2025 (and 2026 too?), 4G (5G?) operators do not all route over IPv6 -> which means that if your domain only has a AAAA record, some people using 4G will not be able to access ANY of your services. This issue forced me to beg my ISP to obtain an IPv4 "fullstack" as they call it.
Without that IPv4 you have to go through some kind of tunneling (like Cloudflare) -> and guess what? Cloudflare sometimes crashes (it happened super recently remember?) and in that situation -> ALL your services accessible through the tunnel are "down" for your users. Plus, it is EXTREMELY unsatisfying to rely on an external private-owned service for a selfhosting project.
In almost ALL context IPv6 is seen as optional, additional, additional configuration and is NEVER the default. NEVER. Which means: more configuration, possibly more struggle.
In my case, I administrate a small server at home, where I self host many services that are made available to myself, friends and families, over the internet.
In that context, IPv6, is SADLY (please note that I have NOTHING against IPv6), a limitation, even a nightmare to use.
Some programs do not handle IPv6 at all. Game servers for instance, do not support it, the one that I think about is: Arma 3. But there are many others
In 2025 (and 2026 too?), 4G (5G?) operators do not all route over IPv6 -> which means that if your domain only has a AAAA record, some people using 4G will not be able to access ANY of your services. This issue forced me to beg my ISP to obtain an IPv4 "fullstack" as they call it.
Without that IPv4 you have to go through some kind of tunneling (like Cloudflare) -> and guess what? Cloudflare sometimes crashes (it happened super recently remember?) and in that situation -> ALL your services accessible through the tunnel are "down" for your users. Plus, it is EXTREMELY unsatisfying to rely on an external private-owned service for a selfhosting project.
In almost ALL context IPv6 is seen as optional, additional, additional configuration and is NEVER the default. NEVER. Which means: more configuration, possibly more struggle.
>ALL your services accessible through the tunnel are "down" for your users
Not all.
I operate site with IPv6 only origins behind cloudflare.
During the outage I manged to login to the dashboard after some time and remove cloudflare for nearly 2 hours, and traffic level stayed close to 50% during the IPv6 only period.
Nobody complained: those who did not have working IPv6 probably blamed it on cloudflare.
Not all.
I operate site with IPv6 only origins behind cloudflare.
During the outage I manged to login to the dashboard after some time and remove cloudflare for nearly 2 hours, and traffic level stayed close to 50% during the IPv6 only period.
Nobody complained: those who did not have working IPv6 probably blamed it on cloudflare.
> traffic level stayed close to 50% during the IPv6 only period.
> Nobody complained: those who did not have working IPv6 probably blamed it on cloudflare.
You described a situation where the outage resulted in 50% of your customers were unable to reach you and you were unable to do anything about it. I don’t think this story is a win for IPv6, regardless of whether your customers blame CloudFlare or not.
> Nobody complained: those who did not have working IPv6 probably blamed it on cloudflare.
You described a situation where the outage resulted in 50% of your customers were unable to reach you and you were unable to do anything about it. I don’t think this story is a win for IPv6, regardless of whether your customers blame CloudFlare or not.
Compared to 0% like others?
50% is a very substantial retention rate.
50% is a very substantial retention rate.
Would hand been 100% if his site supported ipv4 natively instead of relying on CloudFlare to do the translation.
The story here is not “ipv6 made my site resilient to CloudFlare outage”. It’s “50% of my customers can’t reach my site even when I turn off CloudFlare”.
The story here is not “ipv6 made my site resilient to CloudFlare outage”. It’s “50% of my customers can’t reach my site even when I turn off CloudFlare”.
>if his site supported ipv4 natively
And it's becoming difficult for people to do so precisely because of IPv4 addresses running out...
And it's becoming difficult for people to do so precisely because of IPv4 addresses running out...
This has nothing to do with anything inherent to IPv6 and everything to do with the failure of organizations to timely implement it.
I didn’t say it was an issue inherent to IPv6. But it is a practical issue with IPv6.
> In almost ALL context IPv6 is seen as optional, additional, additional configuration and is NEVER the default.
Weird. The past two ISPs I've had (Comcast and Monkeybrains) both had IPv6 enabled by default. I've looked at a bunch of SOHO networking gear and IPv6 is on by default. On every Linux and Windows system I've touched in the past ten, fifteen years you have to go significantly out of your way to disable IPv6.
> Some programs do not handle IPv6 at all. Game servers for instance, do not support it...
Depends on the game server. Many I run absolutely do.
Your complaints smell like you tried to run an IPv6-only client network, which would be an absolute nightmare. That's just a stupid thing for a SOHO network (and the networks that serve most corporate client hosts) to do. IPv4-only Internet hosts exist, so it's a no-brainer to provide IPv4 connectivity to clients.
On the other hand, running IPv6-only infrastructure networks can make a ton of sense. One very large such operator is Comcast, a US ISP.
Weird. The past two ISPs I've had (Comcast and Monkeybrains) both had IPv6 enabled by default. I've looked at a bunch of SOHO networking gear and IPv6 is on by default. On every Linux and Windows system I've touched in the past ten, fifteen years you have to go significantly out of your way to disable IPv6.
> Some programs do not handle IPv6 at all. Game servers for instance, do not support it...
Depends on the game server. Many I run absolutely do.
Your complaints smell like you tried to run an IPv6-only client network, which would be an absolute nightmare. That's just a stupid thing for a SOHO network (and the networks that serve most corporate client hosts) to do. IPv4-only Internet hosts exist, so it's a no-brainer to provide IPv4 connectivity to clients.
On the other hand, running IPv6-only infrastructure networks can make a ton of sense. One very large such operator is Comcast, a US ISP.
Most 4G networks are actually IPv6-only, with IPv4 traffic being routed through inefficient tunnel systems. This is why Apple and Google require all mobile apps to use IPv6.
Certainly not all networks. Optus (Australia's #2 carrier) for example does not support IPv6 at all on their mobile network.
I have fiber to my house and no native IPv6 support. I did some research and it seems there is a way to enable IPv6, but it’s janky and just tunnels over IPv4 so what’s the point?
I would love for IPv6 to actually take off but somehow it feels like we are still a decade away from ubiquitous adoption.
I would love for IPv6 to actually take off but somehow it feels like we are still a decade away from ubiquitous adoption.
I have Verizon Fios and after they upgraded my network speed from 1G to 2.5G and ONT to some "next gen" one I lost IPv6 support because supposedly this newer ONT does not support it, lol. Verizon is going backwards.
so it turned into a good ol' legacy problems
idk if arma3 does server discovery, but in case of manual ip input there some kind of OS-networking-level adapter should help. Usecase seems too obvious for something like that not to exist
idk if arma3 does server discovery, but in case of manual ip input there some kind of OS-networking-level adapter should help. Usecase seems too obvious for something like that not to exist
https://www.google.com/intl/en/ipv6/statistics.html it's still going up (we are in some sort of cyclic downturn right now that I don't understand).
Next year that chart will finally cross 50%. It was a mere 30% in 2030. Developing country mobile phone networks will continue to push it higher.
All we need to do is start having rich governments mandate IPv6, and also mandate IPv4 downtime as a punishment for those that don't comply / chaos engineering for the system as a whole. Then we can quickly finish the job.
Next year that chart will finally cross 50%. It was a mere 30% in 2030. Developing country mobile phone networks will continue to push it higher.
All we need to do is start having rich governments mandate IPv6, and also mandate IPv4 downtime as a punishment for those that don't comply / chaos engineering for the system as a whole. Then we can quickly finish the job.
> we are in some sort of cyclic downturn right now that I don't understand
consumer networks have significantly higher adoption rates compared to corporate/edu, and people are on vacations during summer
consumer networks have significantly higher adoption rates compared to corporate/edu, and people are on vacations during summer
Ah OK, there are workday/weekend and vacation/no-vacation cycles. Gotcha.
Well, to the extent the rich country laggards are institutional, then regulation should be more effective!
Well, to the extent the rich country laggards are institutional, then regulation should be more effective!
Correct me if I'm wrong, doesn't it make you leak your IP outside local network? I'd say this is a great turn off especially nowadays when it will be used for sure for tracking
I'm not sure what you mean by "leak your IP" since IP address is always how you communicate. I guess you mean you no longer have a 192.168 or a 10. address that is "hidden" from the Internet for whatever value that has? One nice thing about IPv6 is your local client can continually change their address if they so want (and this is actually a common feature) to disrupt tracking. Sure you have the same prefix, but that's exactly the same boat you were in with IPv4 and NAT.
So this 'feature' is just a fix for the issue with tracking that would not be there with ipv4 beside that my internal ip's are changing every day to bring more confusion into my internal net. nice!
You are being tracked on IPv4 via the gateway address. It's no different. Changing your local IPv4 address does absolutely nothing, while changing the local IPv6 address does almost nothing. Hooray.
Oh but it is different. It for example doesn't leak how many unique devices there are on your network.
This might be very useful in a world that is moving towards authoritarian tech dystopia at mind-boggling speeds.
Yes, yes, we have privacy extensions, but you can still group those through higher-level fingerprinting. You don't get mixed traffic.
Yes, yes, we have privacy extensions, but you can still group those through higher-level fingerprinting. You don't get mixed traffic.
> beside that my internal ip's are changing every day to bring more confusion into my internal net. nice!
You can set it up so your devices can have two IPv6 addresses. The shifting address for external traffic, and a static one for local traffic. I think this is the default in many linux distros now.
You can set it up so your devices can have two IPv6 addresses. The shifting address for external traffic, and a static one for local traffic. I think this is the default in many linux distros now.
my mistake, sorry. I meant MAC - but I learned it is no longer the case (at least not always). There used to be the standard that your IPv6 is concatenation of your MAC and part of router's external IP.
The problem with IPv6 jokes is that very few people are making them.
I started looking at self-hosting many applications at home once I realized that IPv6 could enable me to do that securely without any complicated router/firewall configuration that would need to be maintained.
The only wrinkle I ran into is that apparently ISPs are still reluctant to give out static IPv6 prefixes to residential customers. So you still need some kind of DDNS setup, which is lame.
The only wrinkle I ran into is that apparently ISPs are still reluctant to give out static IPv6 prefixes to residential customers. So you still need some kind of DDNS setup, which is lame.
IPv6 continues to rumble along, gaining market share, because China. Increasing IPv6 adoption was in the 14th Five Year Plan, and about 75% of mobile in China is now IPv6.
IPv6 is an inequality issue. Far too many luddites refuse to learn it because IPv4 works well enough for them. I think it would be a totally different story if the majority of US/European people ended up with CGNAT.
Nothing have given me more issues than ipv6. Every time I've tried to use it, it gives me so much headache I just give up. I'm not even sure my ISP supports it. My router doesn't get an ipv6, and called my IPS. After going through 3 different people over 2 hours I just gave up. I just hope I get put behind CGNAT...
In my country, the last big _mobile_ internet provider finished its move to IPv6.
Land lines internet have been IPv6 for more than a decade.
While developping custom IPv6 internet software I am not blocked by NAT anymore, real p2p fiesta, everything works as intended.
The real challenge now is IPv6 with fixed mobile internet address (not random as it is is now, it should be device uniq). That to replace for good the phone numbers (the challenge of international roaming... which is already done for phone numbers). The idea would be to avoid a third party centralized internet account->ipv6 mapping.
Land lines internet have been IPv6 for more than a decade.
While developping custom IPv6 internet software I am not blocked by NAT anymore, real p2p fiesta, everything works as intended.
The real challenge now is IPv6 with fixed mobile internet address (not random as it is is now, it should be device uniq). That to replace for good the phone numbers (the challenge of international roaming... which is already done for phone numbers). The idea would be to avoid a third party centralized internet account->ipv6 mapping.
Yesterday I was required to turn on IPv6 on my router, while setting up some IoT things using Matter over Thread. Apparently that protocol uses IPv6 and doesn't work if your router is only routing IPv4.
There is a rich history of IoT devices using IPv6 to communicate among themselves without relying on the cloud. I think Nest started this trend. One Nest device sends a specific RA to make itself the router of all other Nest devices. All other devices can configure themselves thanks to SLAAC. The benefit of v6 is that there are so many addresses out there that the Nest device can just pick an arbitrary ULA and there won’t be collisions.
Don’t know about Matter though. If it requires the user to turn on IPv6 then it’s a user experience downgrade. It should just use IPv6 internally as an implementation detail.
Don’t know about Matter though. If it requires the user to turn on IPv6 then it’s a user experience downgrade. It should just use IPv6 internally as an implementation detail.
That's incorrect. Matter-over-Thread absolutely does NOT require IPv6 on your router. Even Matter-over-WiFi will happily work in IPv4-only networks, as long as your router does not filter the IPv6 announcements.
Some routers can work as _relays_ between the Thread network and WiFi, but this is entirely optional.
Some routers can work as _relays_ between the Thread network and WiFi, but this is entirely optional.
iirc some of the matter devices want/need connection to the mothership outside. hence ipv6 on router
this is one of reasons why i stick to z-wave. totally self contained.
Is there yet answer to question "how to get random self-assigned addresses into dns records, firewall rules and switch acls?" ?
802.1x instead of switch ACLs
SSSD (Linux) or Active Directory (Windows) or other more custom solutions for dynamic DNS
Firewalls rules that use those dynamic DNS names
Bonus: the relatively recent RFC 9686 that I hope will get some good traction: https://datatracker.ietf.org/doc/rfc9686/
Bonus: the relatively recent RFC 9686 that I hope will get some good traction: https://datatracker.ietf.org/doc/rfc9686/
Dynamic DNS, DHCP, and static assignment are all still part of IPv6. Putting single IPs in switch ACLs is an anti pattern. Consider zero trust or working with whole subnets(they're plentiful in v6) instead.
Every IPv6 networker fan has rabidly torn me to pieces when I asked how to deploy DHCPv6.
Apparently it's "not how it's done" and we're "doing it wrong".
My SOHO equipment doesn't really support it either, so it's just as well, staying on IPv4 which does DHCP and solves that problem.
Apparently it's "not how it's done" and we're "doing it wrong".
My SOHO equipment doesn't really support it either, so it's just as well, staying on IPv4 which does DHCP and solves that problem.
> DHCP
Not if you're on Android. https://issuetracker.google.com/issues/36949085
Not if you're on Android. https://issuetracker.google.com/issues/36949085
Bless them for not allowing it.
How do you setup dynamic dns in your network? Which software do you use?
Turn off temp addresses. If your prefix changes then use ULA addresses.
I suppose I could have said how.
Windows in powershell:
Windows in powershell:
SetNetIPv6Protocol -UseTemporaryAddresses Disabled
SetNetIPv6Protocol -RandomizeIdentifiers Disabled
sysctl net.ipv6.conf.all.use_tempaddr=0
ip6-privacy=0
ifconfig em0 inet6 -temporaryYeah. ULA and nat66 would work nicely. Except you would get murdered for asking about nat66.
I'm convinced half the ipv6 subreddit is made of people who don't actually like ipv6 and are trying to subvert it. The advice they give sometimes is just insane. "Just get a new ISP bro..."
I think a lot of people assume privacy addresses are required. You can just not mess with them. Privacy is dead anyway.
I think a lot of people assume privacy addresses are required. You can just not mess with them. Privacy is dead anyway.
"Build yourself an IPAM solution, at great operational cost and complexity."
DJB understood the problem decades ago. https://cr.yp.to/djbdns/ipv6mess.html
Not really. DJB’s clearly a very, very smart person, but he missed the mark on almost all of that. The problems he described which are real have been satisfactorily solved; they weren’t intractable. The rest turned out to be non-issues.
Also, his proposed alternative solution (essentially expecting someone to change all software and hardware in the world first, and then have a flag day with zero operational experience) was completely non-workable. Well, actually the document is so vague that you could interpret his “solution” in like three additional different ways, but none of them make much sense.
Intriguing take that he "missed the mark", yet we are still utterly dependant and reliant on IPv4 30 years later since v6, the situation he essentially predicted. How much longer until IPv6 becomes the incumbent?
IPv6 is already here if you're not in the US. I moved house last month and consumer ISPs don't offer a (real) IPv4 connection in my country any more; you get an IPv6 connection and your router does MAP-E if you want to send data over IPv4.
I want to echo this comment. I am on Map-e in Asia and it is very difficult to get an exclusive ipv4 address without paying extra money.
And I want to connect to my machines without some stupid vpn or crappy cloud reverse tunneling service. Not everyone in the world wants to subscribe to some stupid SaaS service just to get functionality that comes by default with ipv6.
I think Silicon Valley is in a thought bubble and for people there ipv4 is plentiful and cheap. So good for them. However, the more these SaaS services delay ipv6 support, the more I pray to any deity out there I can move off these services permanently.
And I want to connect to my machines without some stupid vpn or crappy cloud reverse tunneling service. Not everyone in the world wants to subscribe to some stupid SaaS service just to get functionality that comes by default with ipv6.
I think Silicon Valley is in a thought bubble and for people there ipv4 is plentiful and cheap. So good for them. However, the more these SaaS services delay ipv6 support, the more I pray to any deity out there I can move off these services permanently.
IMO we need to rethink routing for IPv6 so we can finally reduce pressure on router tables and finally cause pressure to ditch IPv4. Here are some of my thoughts on that elsewhere in this thread: https://news.ycombinator.com/item?id=46471898
But here's a more thought-out design:
- register a well-known IPv6 prefix with 20 bits reserved for AS number
- so we'd have ${well_known_prefix}:${AS_number}:${customer_prefix}:${end_entity} (not necessarily that format for display, but just for the purpose of getting the idea across here)
- have DNS servers return AAAA RRs with the AS number filled in
- DNS servers should either have the correct AS numbers filled in their zones, or possibly could subscribe to the RPKI and use the RPKI for mapping ${well_known_prefix}:${all_zero_AS}:${customer_prefix}:* to AS numbers, then fill them in (this would require live signing if using DNSSEC, which is f-i-n-e fine)
- if there are multiple AS numbers for a $customer_prefix, then return multiple AAAA RRs, or if EDNS0 indicates client support for it, one AAAA RR and N RRs of a new type that carry only the AS numbers
- update core routers to route these prefixes based on the AS number in the address
- update edge routers to replace the sender's AS number in its address if its address is below the $well_known_prefix -- this takes care of the return path
- update internal routers to use only the $customer_prefix and the $end_entity for routing for this $well_known_prefix
- end entities should ignore the AS number when receiving packets, thus allowing multi-homing (i.e., let source and destination IPv6 addresses match ${well_known_prefix}:*:${customer_prefix}:${end_entity} for socket 5-tuples)
- for backwards compatibility end entities should map these addresses back to whatever the application used in its calls to bind() and connect() (i.e., if the app found an AAAA with the AS number filled in and used it for connect(), but the ${customer_prefix} is multi-homed, then accept packets from all those homes) (apps should make sure to use TLS / QUIC for security, naturally)
- when an end-entity sees a change in AS number for a peer's address matching a socket 5-tuple then update the peer's AS number / address in the 5-tuple -- this allows for migration and better path finding
I think something like this could be deployed with relatively little effort.
But here's a more thought-out design:
- register a well-known IPv6 prefix with 20 bits reserved for AS number
- so we'd have ${well_known_prefix}:${AS_number}:${customer_prefix}:${end_entity} (not necessarily that format for display, but just for the purpose of getting the idea across here)
- have DNS servers return AAAA RRs with the AS number filled in
- DNS servers should either have the correct AS numbers filled in their zones, or possibly could subscribe to the RPKI and use the RPKI for mapping ${well_known_prefix}:${all_zero_AS}:${customer_prefix}:* to AS numbers, then fill them in (this would require live signing if using DNSSEC, which is f-i-n-e fine)
- if there are multiple AS numbers for a $customer_prefix, then return multiple AAAA RRs, or if EDNS0 indicates client support for it, one AAAA RR and N RRs of a new type that carry only the AS numbers
- update core routers to route these prefixes based on the AS number in the address
- update edge routers to replace the sender's AS number in its address if its address is below the $well_known_prefix -- this takes care of the return path
- update internal routers to use only the $customer_prefix and the $end_entity for routing for this $well_known_prefix
- end entities should ignore the AS number when receiving packets, thus allowing multi-homing (i.e., let source and destination IPv6 addresses match ${well_known_prefix}:*:${customer_prefix}:${end_entity} for socket 5-tuples)
- for backwards compatibility end entities should map these addresses back to whatever the application used in its calls to bind() and connect() (i.e., if the app found an AAAA with the AS number filled in and used it for connect(), but the ${customer_prefix} is multi-homed, then accept packets from all those homes) (apps should make sure to use TLS / QUIC for security, naturally)
- when an end-entity sees a change in AS number for a peer's address matching a socket 5-tuple then update the peer's AS number / address in the 5-tuple -- this allows for migration and better path finding
I think something like this could be deployed with relatively little effort.
I question the premise that it’s not taking over. Our logs are at least 50% ipv6 now. A few years ago I feel like a barely saw it.
Every day I thank NAT that I don't have to memorize IPv6 addresses. I can barely manage my IPv4 numbers.
IPv6 seems to be a great fit for 1) mobile devices, 2) massive data centers and 3) literally nothing else.
I have met zero network engineers who wanted to put IP version 6 in their network. It causes all sorts of problems and presents all sorts of security risks without much benefit other than the obvious one. In the data center, NAT is a feature, not a bug.
Instead, they provision IPv6-enabled load balancers and pass traffic back to load bearing servers using ipv4 instead.
It's a classic example of "this is the next best thing everyone should use it" which achieves some adoption but it's not really the next best thing. It's not the be all end all it purports to be.
We should just admit to ourselves that we need one kind of ip stack in some situations and another in another.
I have met zero network engineers who wanted to put IP version 6 in their network. It causes all sorts of problems and presents all sorts of security risks without much benefit other than the obvious one. In the data center, NAT is a feature, not a bug.
Instead, they provision IPv6-enabled load balancers and pass traffic back to load bearing servers using ipv4 instead.
It's a classic example of "this is the next best thing everyone should use it" which achieves some adoption but it's not really the next best thing. It's not the be all end all it purports to be.
We should just admit to ourselves that we need one kind of ip stack in some situations and another in another.
20 years ago there were a lot of peer to peer applications. For example, Skype used to bounce calls across peers. Now, all calls gets routed through big-brother Microsoft.
NAT and American assymmetric bandwidth ISPs both killed this business model and now we are stuck with tech monopolies like Cloudflare. I see this ipv4-only strategy as another monopoly tactic to kill competition.
And in Asia, it is getting more difficult not to get stuffed behind a double NAT (CGNAT), which means you can't even play games without using big-brother rent-seeker services (no port-forwarding/upnp). But at least here you get ipv6 for free and everything just works.
NAT and American assymmetric bandwidth ISPs both killed this business model and now we are stuck with tech monopolies like Cloudflare. I see this ipv4-only strategy as another monopoly tactic to kill competition.
And in Asia, it is getting more difficult not to get stuffed behind a double NAT (CGNAT), which means you can't even play games without using big-brother rent-seeker services (no port-forwarding/upnp). But at least here you get ipv6 for free and everything just works.
NAT is the reason for IPV6 not taking over.
Also it acts as a nice security perimeter. If all IoT devices in a home were exposed to internet, It would be absolute mess.
Also it acts as a nice security perimeter. If all IoT devices in a home were exposed to internet, It would be absolute mess.
Setting up a firewall with an IPv6 deny inbound policy takes about 30 seconds. How is this an absolute mess?
NAT doesn't act as a security perimeter, and not having NAT doesn't mean that your devices are exposed to the Internet.
NAT is about dealing with address space shortages, not security.
NAT is about dealing with address space shortages, not security.
This gaslighting keeps being repeated, but fact of the matter is that any consumer/home network will be exposed to the internet if they're using SOHO equipment via IPv6 and won't be via IPv4.
And huge % of SOHO routers won't even allow configuring IPv6 firewall which makes security a disaster.
And huge % of SOHO routers won't even allow configuring IPv6 firewall which makes security a disaster.
I have never seen a single router that supports IPv4 NAT, IPv6, and not an IPv6 firewall. I’m skeptical that they exist.
Look harder - maybe start with equipment that ISPs give out as their internet boxes.
If you look hard enough you will find some, but it's not common.
Half of the Internet is using v6. If a lack of firewall was as common or as dangerous as people think, the supposed security disaster would have already happened. It hasn't.
Half of the Internet is using v6. If a lack of firewall was as common or as dangerous as people think, the supposed security disaster would have already happened. It hasn't.
> any consumer/home network will be exposed to the internet if they're using SOHO equipment via IPv6 and won't be via IPv4.
Only if the ISP does no egress filtering. Most mobile carriers I’ve used deny inbound connections.
Only if the ISP does no egress filtering. Most mobile carriers I’ve used deny inbound connections.
I don't think "IPv6 is safe because ISP is blocking all your ingress traffic" is a positive argument for an IP standard that's supposed to enable every device to be routable on the internet without things like NAT.
(Also, why the fsck would I want to have an ISP that does that?)
(Also, why the fsck would I want to have an ISP that does that?)
It keeps getting repeated precisely because it isn't gaslighting. And yet we still see people claiming that NAT is security.
The only reason those networks aren't exposed to the whole Internet on v4 is because they're using RFC1918, not because of NAT -- but that still leaves them exposed to some outside networks, so routers come with firewalls, which act as an actual security boundary.
And they won't be exposed on v6, because those exact same firewalls work their magic on v6 too.
NAT doesn't provide and isn't needed for security. Its main security contribution is to confuse people about how secure their network is.
The only reason those networks aren't exposed to the whole Internet on v4 is because they're using RFC1918, not because of NAT -- but that still leaves them exposed to some outside networks, so routers come with firewalls, which act as an actual security boundary.
And they won't be exposed on v6, because those exact same firewalls work their magic on v6 too.
NAT doesn't provide and isn't needed for security. Its main security contribution is to confuse people about how secure their network is.
NAT effectively stops inbound connectivity at the NAT edge. A system could be a dozen hops beyond that and no inbound traffic can reach it.
IPv6 (without any NAT) means that the source and destination are fully routable.
How folks DON'T see this as a functional component of security is beyond me.
IPv6 (without any NAT) means that the source and destination are fully routable.
How folks DON'T see this as a functional component of security is beyond me.
I'd expect folks would see the behavior you're describing here as being part of security.
However, NAT in the real world doesn't work the way you're describing here. My position is based on how NAT actually behaves, not on incorrect descriptions of how it behaves.
Or perhaps you could explain how NAT stops inbound connectivity at the NAT edge? I've tested and it doesn't, so I don't think it's possible to explain how it does, but I'm open to being wrong on that if anybody could actually explain it in a way that doesn't contract actual observed behavior.
However, NAT in the real world doesn't work the way you're describing here. My position is based on how NAT actually behaves, not on incorrect descriptions of how it behaves.
Or perhaps you could explain how NAT stops inbound connectivity at the NAT edge? I've tested and it doesn't, so I don't think it's possible to explain how it does, but I'm open to being wrong on that if anybody could actually explain it in a way that doesn't contract actual observed behavior.
Look I get where you're going with this. I do. All things being equal, a device that routes packets will route packets whether or not a NAT is in place. That's not the issue at hand.
The situation is simply that except in the rarest of cases, you're not going to be able to manipulate routing to achieve getting a packet with a RFC1918 (let's be real here, this is what we're talking about 99.9% of the time) destination address to go anywhere, much less to the target. Or more broadly, getting a packet addressed for a target behind a NAT to route TO a NAT gateway. Not to mention that if somehow it did get through, return packets are almost guaranteed to end up NAT'd, preventing traffic flow. So there's that.
On the Internet, even if your ISP didn't drop your packets outright, the routers wouldn't have the faintest idea how to route your packets to your victim.
Not Internet? Ok, let's say you're on a corporate network. You're a user and not a network admin.
Your company has a VPN to a partner company, and you're both using various subnets in 10/8. The partner has provided 192.168.1.0/24 of 1:1 NAT addresses so your two companies can share data, etc.
But there is no route in the IGP to the partner company's 10/8 network, only a block of 192.168.1.x addresses, none of which you are able to use. A magic fairy tells you that partner's payroll server has admin/admin credentials at 10.5.5.5. How are you going to get across the VPN to that address?
You won't, because you can't. Because there's no route, and in the case of a VPN, the interesting traffic probably doesn't include that IP even if you got a packet that far.
It's all simply a question of routing. Whether your traffic is being dropped by a firewall or dropped by a router, it's still being dropped.
FWIW I was a network engineer and architect at a massive enterprise for almost 15 years, and my team had management over all our Internet circuits, NAT, our WAN, etc. At the time I left we probably had >200k 1:1 NAT addresses; mostly across B2B links for management access of our devices on customer premises. It was an enormous PITA.
The situation is simply that except in the rarest of cases, you're not going to be able to manipulate routing to achieve getting a packet with a RFC1918 (let's be real here, this is what we're talking about 99.9% of the time) destination address to go anywhere, much less to the target. Or more broadly, getting a packet addressed for a target behind a NAT to route TO a NAT gateway. Not to mention that if somehow it did get through, return packets are almost guaranteed to end up NAT'd, preventing traffic flow. So there's that.
On the Internet, even if your ISP didn't drop your packets outright, the routers wouldn't have the faintest idea how to route your packets to your victim.
Not Internet? Ok, let's say you're on a corporate network. You're a user and not a network admin.
Your company has a VPN to a partner company, and you're both using various subnets in 10/8. The partner has provided 192.168.1.0/24 of 1:1 NAT addresses so your two companies can share data, etc.
But there is no route in the IGP to the partner company's 10/8 network, only a block of 192.168.1.x addresses, none of which you are able to use. A magic fairy tells you that partner's payroll server has admin/admin credentials at 10.5.5.5. How are you going to get across the VPN to that address?
You won't, because you can't. Because there's no route, and in the case of a VPN, the interesting traffic probably doesn't include that IP even if you got a packet that far.
It's all simply a question of routing. Whether your traffic is being dropped by a firewall or dropped by a router, it's still being dropped.
FWIW I was a network engineer and architect at a massive enterprise for almost 15 years, and my team had management over all our Internet circuits, NAT, our WAN, etc. At the time I left we probably had >200k 1:1 NAT addresses; mostly across B2B links for management access of our devices on customer premises. It was an enormous PITA.
I get all of that... but it just sounds like you're arguing that either using RFC1918, or someone's inability to route to your router, is a firewall. Neither of these things are NAT! Nor will either of them protect you from all inbound connections, so neither of them count as firewalls either (although I'll grant that they limit the number of people that could make such a connection).
You can't trust an attacker to politely not send you packets that you think they can't send you. They can run `ip route add 10.5.5.5 dev vpn`/`via <next-hop>` just fine if they happen to be in the right place to do it, and your NAT won't help you.
The reason the packets are being dropped does matter. The issue at hand is all the people thinking that v6 is insecure because NAT is a security barrier; they're wrong, because it's not a security barrier, and if they continue to misattribute their security to it then they're going to keep reaching the wrong conclusions about v6.
You can't trust an attacker to politely not send you packets that you think they can't send you. They can run `ip route add 10.5.5.5 dev vpn`/`via <next-hop>` just fine if they happen to be in the right place to do it, and your NAT won't help you.
The reason the packets are being dropped does matter. The issue at hand is all the people thinking that v6 is insecure because NAT is a security barrier; they're wrong, because it's not a security barrier, and if they continue to misattribute their security to it then they're going to keep reaching the wrong conclusions about v6.
> I get all of that... but it just sounds like you're arguing that either using RFC1918, or someone's inability to route to your router, is a firewall.
Yes and no. The effect is the same; packets are dropped. If you have no path to a target and no way to create one, it's a security barrier.
> Neither of these things are NAT!
You're right. They're a *result* of having a NAT boundary.
> They can run `ip route add 10.5.5.5 dev vpn`/`via <next-hop>` just fine if they happen to be in the right place to do it, and your NAT won't help you.
'If they happen to be in the right place to do it' is doing a LOT of heavy lifting here. You'd have to have root access on a compromised host, e.g., a linux system, immediately adjacent to the router/firewall/VPN doing NAT. And boy would that be a stupid design for an enterprise, and it would never happen at the Internet edge. So we're talking about the edgiest of edge case unicorns.
Even if you had all that go right, return packets are going to be addressed wrong (NAT) so you'd have to figure out how to deal with that.
Your stance seems to boil down to security being an active security measure - e.g. packet filter policy. My stance is that NAT and the reality of network design naturally results in preventing unwanted traffic flows, effectively producing the same result.
I'm not saying firewalls aren't critical, just that NAT does create a barrier, and v6 advocates always blare on that it doesn't.
Yes and no. The effect is the same; packets are dropped. If you have no path to a target and no way to create one, it's a security barrier.
> Neither of these things are NAT!
You're right. They're a *result* of having a NAT boundary.
> They can run `ip route add 10.5.5.5 dev vpn`/`via <next-hop>` just fine if they happen to be in the right place to do it, and your NAT won't help you.
'If they happen to be in the right place to do it' is doing a LOT of heavy lifting here. You'd have to have root access on a compromised host, e.g., a linux system, immediately adjacent to the router/firewall/VPN doing NAT. And boy would that be a stupid design for an enterprise, and it would never happen at the Internet edge. So we're talking about the edgiest of edge case unicorns.
Even if you had all that go right, return packets are going to be addressed wrong (NAT) so you'd have to figure out how to deal with that.
Your stance seems to boil down to security being an active security measure - e.g. packet filter policy. My stance is that NAT and the reality of network design naturally results in preventing unwanted traffic flows, effectively producing the same result.
I'm not saying firewalls aren't critical, just that NAT does create a barrier, and v6 advocates always blare on that it doesn't.
I love IPv6 but organizations seem to struggle with it. My ISP, for example, had issues routing it after a backend update so they decided to just turn it off. I'm now stuck on CGNAT IPv4 which results in constant captchas :/
Meanwhile, there is a whole grey market built around this. People sell “CGNAT mobile proxies” that ride on carrier and ISP NAT, and the whole point is that they are a pain to block without nuking huge ISP ranges. So they get marketed as a convenient way to dodge shadowbans, spam filters, and basically any abuse defense that relies on IP reputation.
> the whole point is that they are a pain to block
What makes them a pain to block? Angry users or some central database that lists these addresses as "do not block"?
What makes them a pain to block? Angry users or some central database that lists these addresses as "do not block"?
It would be nice if we had a blackout CGNAT day where a bunch of major sites don't serve traffic to people behind CGNAT to give the ISPs a bit of a scare.
This is a win for the consumer though, we don't want to be tracked, your inability for abuse prevention is my ability to stay hidden in the crowd. Why should I care?
Heh, if you think your ISP wouldn't sell port connection timing data to advertisers then you've missed all the history of them selling everything else. CGNAT is not a VPN.
my ISP is bound by my countries privacy regulation, I replace the trust of one party with every website i visit that could be located in fascist regimes without such laws.
IPv6 was obsolete by the mid-2000s, majorly due to the advent of roaming. It was designed on the rather fanciful assumption that its deployment would simply supersede IPv4, that every software/hardware vendor would cooperate, and we'd have a pure v6 network which would also replace the traditional L2/L3 layers.
Ofcourse legacy compatibility trumps all, along with the ubiquity of NATs and roaming and we're now just in the sunk-cost phase, being left saddled with a horribly bloated protocol (128-bit addresses was a marketing choice; not engineering) that solves no problems.
Ofcourse legacy compatibility trumps all, along with the ubiquity of NATs and roaming and we're now just in the sunk-cost phase, being left saddled with a horribly bloated protocol (128-bit addresses was a marketing choice; not engineering) that solves no problems.
What's up with those comments? Am I still on HackerNews or did I visit Reddit with some HackerNews theme applied?
Internet engineers pre-2000 had some idealistic, heavly mathematically proven ideas that still seem revolutionary today. Due to human nature, not everything got through, but IPv6 is the best of what we have and creating another standard would be XKCD 927.
Under every IPv6 discussion people all of sudden have the urge to manually assign numbers, need to remember their cousin's phone IP and MAC address, forget firewalls exists, argue that ISP fiddling with TCP+UDP selling it as "Internet" is a good thing or that "sender" field on the envelope is a huge privacy issue.
Internet engineers pre-2000 had some idealistic, heavly mathematically proven ideas that still seem revolutionary today. Due to human nature, not everything got through, but IPv6 is the best of what we have and creating another standard would be XKCD 927.
Under every IPv6 discussion people all of sudden have the urge to manually assign numbers, need to remember their cousin's phone IP and MAC address, forget firewalls exists, argue that ISP fiddling with TCP+UDP selling it as "Internet" is a good thing or that "sender" field on the envelope is a huge privacy issue.
I can't help but think that numbering all the devices was the wrong idea from the beginning. You don't want to talk to devices, you want to talk to (and offer) services. You probably need something like an AS number to make global routing efficient, but 32 bits would be plenty for that. A packet could be (destination AS, stream ID, encrypted( payload )) and DNS would give you a capability (destination AS, stream ID, keys) for a service. You send a packet to that stream asking to open a connection and providing a capability to reply (with a capability for the specific stream). Your network up to the AS level should have an opportunity to augment the stream IDs in whatever way is convenient for its routing. No one reveals any topology information, network neutrality and a degree of privacy is guaranteed at the protocol level, only really serious multipeer networks need to assign addresses above layer 2, and I think it would be reasonably easy to come up with an edges first incentive compatible transition plan (which is where ipv6 went wrong).
(This is of course an incomplete and poorly thought out proposal, you don't need to dogpile me about that.)
(This is of course an incomplete and poorly thought out proposal, you don't need to dogpile me about that.)
How many people here have put IPv6 addresses into the root DNS servers for their glue records? Curious how this [1] set of charts has evolved. For some reason I have only ever used IPv4 root glue records and never really gave it much thought otherwise.
[1] - https://nlnetlabs.nl/downloads/publications/ipv6/v6rootglue....
[1] - https://nlnetlabs.nl/downloads/publications/ipv6/v6rootglue....
Evolution is the survival of good enough. IPv4 is good enough.
> but IPv6 is better
It doesn't solve any life-changing problem.
> but IPv6 is better
It doesn't solve any life-changing problem.
[deleted]
and it never will, because IPv4 has become a defacto reputation system for the exact same reason that IPv6 was created: a limited supply. It wouldn't surprise me to see the continued balkanization of the internet that there is a particular underclass of exclusively IPv6 traffic, but its not going to take over everything because once decentralized systems are now in the hands of a few decisionmakers in the case of, say, email.
IPv6 is the poster child for the second system effect (or solution) [1].
IPv4 really only had 3 problems that anybody cared about:
1. Address space size;
2. Roaming; and
3. Reliable connectionless delivery; and
4. The problems created by the at most once delivery under TCP when what we really needed was at least once delivery in many, many cases.
Even the address space size problem is less of an issue than originally predicted because of improvements in NAT, up to and including cgNAT for cellular network providers (which also somewhat addressed (2) in a limited way).
Interestingly, some of the larger companies have networks simply too large for the 10.0.0.0/8 address space.
By "roaming" I mean maintaining a consistent connection while moving between networks.
(4) has kinda fallen on QUIC (now HTTP3) but this should really be core TCP/IP Layer 3.
You could also say that TCP congestion control is pretty outdated. It's not surprising. It was designed at a time before megabit (let alone gigabit) networks. And, more importantly, latency kills throughput. Some efforts have been made on this, such as Google's BBR [2], but other problems remain like MTU windows being too small for modern networks.
So what did IPv6 do? It only solved one problem, address space, and it did it in a way that kinda created new problems. First, the address space is too large (128 bits) and the last 64 bits are kinda reserved for the job that a 16 port used to do. And why was that? Originally, it was intended that the lower 64 bits were derived from a 48 bit MAC address (as used by Ethernet and later Wifi) but they realized this was a huge privacy problem so it never happened.
[1]: https://en.wikipedia.org/wiki/Second-system_effect
[2]: https://github.com/google/bbr
[2]: https://community.cisco.com/t5/networking-knowledge-base/und...
IPv4 really only had 3 problems that anybody cared about:
1. Address space size;
2. Roaming; and
3. Reliable connectionless delivery; and
4. The problems created by the at most once delivery under TCP when what we really needed was at least once delivery in many, many cases.
Even the address space size problem is less of an issue than originally predicted because of improvements in NAT, up to and including cgNAT for cellular network providers (which also somewhat addressed (2) in a limited way).
Interestingly, some of the larger companies have networks simply too large for the 10.0.0.0/8 address space.
By "roaming" I mean maintaining a consistent connection while moving between networks.
(4) has kinda fallen on QUIC (now HTTP3) but this should really be core TCP/IP Layer 3.
You could also say that TCP congestion control is pretty outdated. It's not surprising. It was designed at a time before megabit (let alone gigabit) networks. And, more importantly, latency kills throughput. Some efforts have been made on this, such as Google's BBR [2], but other problems remain like MTU windows being too small for modern networks.
So what did IPv6 do? It only solved one problem, address space, and it did it in a way that kinda created new problems. First, the address space is too large (128 bits) and the last 64 bits are kinda reserved for the job that a 16 port used to do. And why was that? Originally, it was intended that the lower 64 bits were derived from a 48 bit MAC address (as used by Ethernet and later Wifi) but they realized this was a huge privacy problem so it never happened.
[1]: https://en.wikipedia.org/wiki/Second-system_effect
[2]: https://github.com/google/bbr
[2]: https://community.cisco.com/t5/networking-knowledge-base/und...
Not a counter-point, but: the other day I rebuilt my personal server, finishing by pointing the reserved IP at the new box. I then had a period of confusion because I was still seeing old content, because my browser (etc) was obviously querying the AAA record first, which I hadn't updated.
(a while ago I needed to contact support to get an IPv6 allocation at home, but that was a very quick interaction at the time)
(a while ago I needed to contact support to get an IPv6 allocation at home, but that was a very quick interaction at the time)
Browsers add an additional layer of fun where they can cache an IP address long past the TTL as long as the old IP keeps responding correctly.
Is there an obvious reason why it would not have worked to just say that all ipv4 addresses are ipv6 addresses with an implicit leading 96 zero bits?
This is already a thing in IPv6 pretty much.
You can write applications IPv6-only and support IPv4 via IPv4-mapped addresses (::ffff:1.2.3.4 for the IPv4 1.2.3.4). The host still needs to be dualstacked for that to work though.
In case the host is IPv6-only you can use NAT64 (or similar technologies), where the IPv4-space is embedded behind some other prefix, but the application just talks plain IPv6 and doesn't have to care too much what happens in the background.
I’ve asked both ChatGPT and other users and the consensus is “NO YOU CAN’T BECAUSE YOU’D HAVE TO REWRITE THE SOFTWARE”
As if IPv6 doesn’t require a full rewrite too. So basically, no there’s no reason. They just wanted to be edgy and use hexadecimal and they’ve ruined everything.
As if IPv6 doesn’t require a full rewrite too. So basically, no there’s no reason. They just wanted to be edgy and use hexadecimal and they’ve ruined everything.
It's hard to believe there are people that think letters in an IP have a meaningful impact.
"edgy"? Come on.
And if they used decimal I bet the complaints they didn't use hex would be just as loud and just as certain, since an IP address in dotted decimal is 50% longer than in hex.
On top of that, hex would make IPv4 a lot easier to use because of how subnets get optimized. Instead of constantly rounding to weird multiples of 8 or 16 or 32 you'd only have to deal with one hex digit at a time. And in most deployments you could skip the address math entirely by sizing your subnets 4 bits at a time: /16, /20, /24, /28.
"edgy"? Come on.
And if they used decimal I bet the complaints they didn't use hex would be just as loud and just as certain, since an IP address in dotted decimal is 50% longer than in hex.
On top of that, hex would make IPv4 a lot easier to use because of how subnets get optimized. Instead of constantly rounding to weird multiples of 8 or 16 or 32 you'd only have to deal with one hex digit at a time. And in most deployments you could skip the address math entirely by sizing your subnets 4 bits at a time: /16, /20, /24, /28.
That's in there. ::ffff:0:0/96 and 2002::/16 are for v4 addresses in different circumstances, but that doesn't address the issue of routing so there are capabilities like NAT64 that allow network operators to map their IPv4 networks via routers and it mostly works. There were exceptions, software that cares about lower level network functionality tend to break.
NAT64 works much better for 6->4 connection scenarios than vice versa, but 4->6 with specific connection pairs and careful split DNS is possible.
NAT64 works much better for 6->4 connection scenarios than vice versa, but 4->6 with specific connection pairs and careful split DNS is possible.
For anyone who thinks IPv6 is without merit, I recommend reading up on the various challenges of NAT traversal [1]. In cases where CGNAT is deployed in particular, there are scenarios where the only way to make everyday P2P connections work is to route traffic through a 3rd party - which can impact latency and bandwidth.
While IPv6 doesn’t make establishing a P2P connection trivial (there are still firewalls to contend with) - it does simplify things dramatically. And as someone who is behind CGNAT, I am very grateful for the existence of IPv6.
[1] https://tailscale.com/blog/how-nat-traversal-works
While IPv6 doesn’t make establishing a P2P connection trivial (there are still firewalls to contend with) - it does simplify things dramatically. And as someone who is behind CGNAT, I am very grateful for the existence of IPv6.
[1] https://tailscale.com/blog/how-nat-traversal-works
IPv6-only is the future for mobile phones, and mobile devices are the future of the internet.
And it is consumer devices (and IoT devices) which are the most numerous and also the most price sensitive, and this is where IPv4 is disappearing first.
And it is consumer devices (and IoT devices) which are the most numerous and also the most price sensitive, and this is where IPv4 is disappearing first.
Simple reason it didn't take over: the lack of backwards compatibility with ipv4. Yes, it would have marred the beauty of the new specification. But we will continue paying the price for another 30 years.
I don't know about anyone else's reasoning but personally IPV4 works just fine for 100% of my use cases.
I don't have anything against it per-say but I have no reason to use it either.
I don't have anything against it per-say but I have no reason to use it either.
I was expecting Google's IPv6 availability monitor[1] to show a crossover to a (slim) majority of their users accessing their services over IPv6 sometime soon, though it's sort of fascinating how close it gets to 50% recently without ever actually crossing over:
[1] - https://www.google.com/intl/en/ipv6/statistics.html
[1] - https://www.google.com/intl/en/ipv6/statistics.html
Heh, 49.84% on Aug 2nd. Pretty sure it'll cross 50% in 2026, even if only for a few peaks.
true. I am CSE student in third year, and just started learning about networking.
We just take the sheer amount of engineering that went to designing network protocols for granted.
We just take the sheer amount of engineering that went to designing network protocols for granted.
I think this is the same as : we are a big company that does banking and payment processing for decades. We were planning to switch to golang/rust/C/python whatever for a long time but we still use age old java that has been patched several times with known security risks and no longer supported. Unless we have a huge problem we don’t see the need to fix something that is broken but not fallen apart yet.
My gut is that this is for the best; I haven't fully fleshed it out but it feels like the practical goal of "decentralizing power" and e.g. ISPs and other powerful entities exploiting end users is easier in an IPv6 regime, and has been practically thwarted somewhat by IPv4.
I'm reminded of way back in the day when they wanted charge per user or per device in households.
I'm reminded of way back in the day when they wanted charge per user or per device in households.
It's reaching around 50% adoption according to Google stats? Steady growth, though still annoyingly slow. It will need a few more decades at this rate.
My criteria for success, which is the goals that were set forth for IPng was to no longer depend or rely on IP. It didn't even achieve the goal of averting the issue of impending address exhaustion.
IPv6 is the protocol of the future. And will be.
I'd love to have ipv6. The idea every device in my network can have its own unique worldwide address is awesome.
Having said that I still want to have a router with routing rules and firewalls and a network range I can divide into separate protected networks but in reality your home ISP will most likely give you a router with a /64 address.
Having said that I still want to have a router with routing rules and firewalls and a network range I can divide into separate protected networks but in reality your home ISP will most likely give you a router with a /64 address.
You're aware of DHCPv6 Prefix Delegation? The two US-based ISPs I've used in the past ~twenty years (Comcast and Monkeybrains) use it to provide IPv6 service and permit your DHCPv6 client to request a /60 prefix to use as you see fit. It's not a /56, but it's also very much not a /64.
I'd expect "Give home users a /60 via DHCPv6-PD" to be considered "best current practice" in the ISP "community"... so if I switched to another ISP that claimed to provide IPv6 addresses, "ask for a PD-assigned /60" would be the first thing I'd try.
I'd expect "Give home users a /60 via DHCPv6-PD" to be considered "best current practice" in the ISP "community"... so if I switched to another ISP that claimed to provide IPv6 addresses, "ask for a PD-assigned /60" would be the first thing I'd try.
Solution looking for a problem is why. No value is why.
Breaks NAT privacy and the extensions do not do enough.
Top down pushed solution NOBODY WANTS.
Breaks NAT privacy and the extensions do not do enough.
Top down pushed solution NOBODY WANTS.
I run an IPv6 only VPS as a side project to keep an eye on what doesn't work. My most recent discovery: I tried moving from `lego` to the new native ACME `nginx` support. `nginx` refuses to talk to letsencrypt on IPv6; it's not a letsencrypt flaw because it works perfectly on the same server with `lego`.
Dual stack is a hack and binding to an interface like localhost or a single interface does not support dual stack . So your L6 code has to be modified and re tested to support L3 changes .
Even if ipv6 was just as simple , the cost of rebuild , retest and re-deploy is enough of a barrier against migration
Even if ipv6 was just as simple , the cost of rebuild , retest and re-deploy is enough of a barrier against migration
Dual stack is a natural part of migrating between two protocols, because it's the most compatible way of handling both of them. You don't need to use dual stack to use both v4 and v6, but you'll probably choose to the instant you hit even the most minor incompatibility.
Your L6 code should work perfectly fine if you wrote it properly in the first place. If you pass "localhost" to getaddrinfo() with flags=AI_PASSIVE, it returns a list of socket addresses to listen on, and all you need to do is pass those to socket(). You don't need to look inside the sockaddrs and they might as well be opaque data to you, so it doesn't matter what L3 protocol they represent.
Your L6 code should work perfectly fine if you wrote it properly in the first place. If you pass "localhost" to getaddrinfo() with flags=AI_PASSIVE, it returns a list of socket addresses to listen on, and all you need to do is pass those to socket(). You don't need to look inside the sockaddrs and they might as well be opaque data to you, so it doesn't matter what L3 protocol they represent.
Most listeners I’ve seen assume a single FD. It’s IPv6 snobbery to say “you should have written your code to expect IPv6 upgrade 20 years ago”
That's kind of my point though: it didn't need to be written to expect a v6 upgrade, because the socket API is family-agnostic.
20 years ago, getaddrinfo() was 7 years old. You should have been using it already by then.
20 years ago, getaddrinfo() was 7 years old. You should have been using it already by then.
Google's ipv6 stats[0] are stuck in Dec 17.
However, extrapolation suggests the 50% mark might have finally been crossed around year end.
0. https://www.google.com/intl/en/ipv6/statistics.html
However, extrapolation suggests the 50% mark might have finally been crossed around year end.
0. https://www.google.com/intl/en/ipv6/statistics.html
I have noticed that on my last Windows computer (Windows 10) and my current computer (Windows 11) IPv6 works great for a little while after a reboot, but then just seems to die. I have my house and all internal automation configured for IPv6 first and its great on all my Linux computers and phones.
IMHO:
And it will not be, as long as
* (S|D)NAT are not first class citizen in IPV6 Standards and Implementation * there's no mapping of the IPv4 Adresspace into the v6 space, so people can reroute stuff which is needed.
because only then, we can a) migrate b) rebuild the same structures.
because people will never let go of something.
And it will not be, as long as
* (S|D)NAT are not first class citizen in IPV6 Standards and Implementation * there's no mapping of the IPv4 Adresspace into the v6 space, so people can reroute stuff which is needed.
because only then, we can a) migrate b) rebuild the same structures.
because people will never let go of something.
> as long as [...] (S|D)NAT are not first class citizen in IPV6 Standards and Implementation
Yeah, I mostly agree... IMO, a ULA (equivalent to RFC1918, so 192.168.x.x and so forth) is the only sane way to set up your IPv6 network at home, unless you're one of the wizards who owns their own prefix. Dynamic prefix delegation just breaks too many things when the prefix changes, and I really wish NPTv6 was more supported and ubiquitous, because it solves the problem in the most elegant way IMO.
> there's no mapping of the IPv4 Adresspace into the v6 space
Uh, what? What do you think ::ffff:1.2.3.4 is?
https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5....
https://datatracker.ietf.org/doc/html/rfc4038#section-4.2
Yeah, I mostly agree... IMO, a ULA (equivalent to RFC1918, so 192.168.x.x and so forth) is the only sane way to set up your IPv6 network at home, unless you're one of the wizards who owns their own prefix. Dynamic prefix delegation just breaks too many things when the prefix changes, and I really wish NPTv6 was more supported and ubiquitous, because it solves the problem in the most elegant way IMO.
> there's no mapping of the IPv4 Adresspace into the v6 space
Uh, what? What do you think ::ffff:1.2.3.4 is?
https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5....
https://datatracker.ietf.org/doc/html/rfc4038#section-4.2
You don't need NPTv6 to use ULA. Just use both ULA and the dynamic prefix from your ISP. The latter is handled automatically by DHCPv6-PD, and if you're only using it for outbound connections then it changing isn't going to break anything.
I'd say this is actually elegant, compared to NPTv6 which is a kludge and will break things (and isn't well-supported anyway).
I'd say this is actually elegant, compared to NPTv6 which is a kludge and will break things (and isn't well-supported anyway).
I definitely do both ULA and GUA at home, but this only really works well to the degree that the OS will prefer the ULA when connecting to things. Like if I want to put hostnames in netgroups, I need reverse DNS to work (which only works if the client is using the ULA address I expect.) In fact the whole idea of reverse lookups working and having expected hostnames show up where you want them to (logs, etc) really depends on not only using ULA for connections, but using the stable address and not the privacy address, which can also cause issues.
For the most part it works today, if I stick to using ULA’s only in my zone file, and configure hosts to prefer the DHCPv6-provided ULA for connections in the ULA subnet, it’s fine. But suddenly if you connect to somehost.local instead of somehost.fqdn, the machine picks a GUA source address and you’re back to being unpredictable.
So although I say I want to use NPTv6 and be ULA-only, I don’t actually do that today, so I’m not super familiar with the downsides to the approach. But it does sound a lot cleaner to me in theory.
> if you're only using it for outbound connections then it changing isn't going to break anything.
A prefix change absolutely does break things in a lot of setups though. It happens something like:
- Your router reboots unexpectedly (no time to rescind the RA)
- Router comes up and gets a new prefix, starts advertising it
- Clients are brain dead and continue using the old prefix when making outbound connections.
I’ve had this happen and both Apple devices and Linux devices (I had no Windows machines) kept using the old prefix until I went around and rebooted them. So connecting to any IPv6 WAN address would fail, and only IPv4 was saving me from my internet being down until I went and manually rebooted everything.
There have since been RFC’s that come up with recommendations for routers to keep a stateful log of old prefixes, so that they can rescind them (advertise a zero TTL) when a new prefix arrives… but afaict none of them actually do this.
For the most part it works today, if I stick to using ULA’s only in my zone file, and configure hosts to prefer the DHCPv6-provided ULA for connections in the ULA subnet, it’s fine. But suddenly if you connect to somehost.local instead of somehost.fqdn, the machine picks a GUA source address and you’re back to being unpredictable.
So although I say I want to use NPTv6 and be ULA-only, I don’t actually do that today, so I’m not super familiar with the downsides to the approach. But it does sound a lot cleaner to me in theory.
> if you're only using it for outbound connections then it changing isn't going to break anything.
A prefix change absolutely does break things in a lot of setups though. It happens something like:
- Your router reboots unexpectedly (no time to rescind the RA)
- Router comes up and gets a new prefix, starts advertising it
- Clients are brain dead and continue using the old prefix when making outbound connections.
I’ve had this happen and both Apple devices and Linux devices (I had no Windows machines) kept using the old prefix until I went around and rebooted them. So connecting to any IPv6 WAN address would fail, and only IPv4 was saving me from my internet being down until I went and manually rebooted everything.
There have since been RFC’s that come up with recommendations for routers to keep a stateful log of old prefixes, so that they can rescind them (advertise a zero TTL) when a new prefix arrives… but afaict none of them actually do this.
huh, i was NOT aware of that. NICE!
now applications (including DNS/NAT) have to support it
i also forgot something (but not against your comment):
* there needs to be guidelines how applications should differentiate between used ipadresses (link, site, global and so on)
now applications (including DNS/NAT) have to support it
i also forgot something (but not against your comment):
* there needs to be guidelines how applications should differentiate between used ipadresses (link, site, global and so on)
Unfortunately, TIL that Linux doesn't use DNSv6 if DNSv4 is available ;(
https://github.com/systemd/systemd/issues/16322
https://github.com/systemd/systemd/issues/16322
That seems to be about resolved, part of systemd, not Linux?
it's resolved in the sense of "won't fix".
systemd is part of Linux Distros?
systemd is part of Linux Distros?
I didn't say it was resolved, I said it's about a piece of software which is called "resolved" which is one of many programs belonging to "systemd". It's a program which handles DHCP and DNS I believe.
And systemd is part of some Linux distros, yes. But not all. And Linux, the kernel, is agnostic towards IPv4 vs. IPv6 as far as I know.
So saying "Linux prefers IPv4 DNS" and linking to a github issue about "resolved" doesn't make much sense.
And systemd is part of some Linux distros, yes. But not all. And Linux, the kernel, is agnostic towards IPv4 vs. IPv6 as far as I know.
So saying "Linux prefers IPv4 DNS" and linking to a github issue about "resolved" doesn't make much sense.
IPv6 might not have taken over the world, but it sure seems to be getting forced on the world.
Even more than IPv4, not knowing enough about IPv6 can introduce a lot of unintended issue, consequence and even security gaps in your assumptions.
Maybe there was an IPv7 or 8 that will be more palatable.
Even more than IPv4, not knowing enough about IPv6 can introduce a lot of unintended issue, consequence and even security gaps in your assumptions.
Maybe there was an IPv7 or 8 that will be more palatable.
It’s all fun and games until your ISP changes your prefix and breaks all your firewall/routing rules. I tried to adopt IP6 with Spectrum internet, but every time the cable modem reboots, my prefix changes and breaks everything. No thanks.
My work has IPv6, and my home has IPv6.
If I need to connect to my home Fedora machine from work, a simple "ssh fed.nono.io" works just fine — I don't need to activate my Wireguard VPN; I don't need to worry about address space collisions.
If I need to connect to my home Fedora machine from work, a simple "ssh fed.nono.io" works just fine — I don't need to activate my Wireguard VPN; I don't need to worry about address space collisions.
That is because your provider is nice and gives you a static pre-fix. Around here, all the providers give dynamic IPv6 pre-fixes to prevent people from running servers. This is partially why some see Ipv6 as a advantage, and others see it as nothing but trouble. We still have the whole Ipv4 CGNAT disadvantage, with the added complexity of Ipv6 on top.
The article itself is fairly short & fluffy.
Vs. real meat is in the comments on the Register's site.
Vs. real meat is in the comments on the Register's site.
> IPv6 was not backward-compatible with IPv4
I don't think there is any way it could have been.
I don't think there is any way it could have been.
Matter iot devices are IPv6 only.
Apple TV, Amazon Echo/eero, Google Nest are all Thread/Matter hub.
Ikea just started to selling cheap Thread devices. It will soon be mainstream to have IPv6 devices in your home network.
Apple TV, Amazon Echo/eero, Google Nest are all Thread/Matter hub.
Ikea just started to selling cheap Thread devices. It will soon be mainstream to have IPv6 devices in your home network.
IPv4 should have been converted directly to IPv6. Every IPv4 address should have been given an equivalent IPv6 address. 192.168.1.1 becomes 2001:00C0:00A8:0000:0000:0000:0001:0001 or 2001:00C0:00A8::0001:0001.
that exists - ::ffff:0:0/96 space. It even supports dots.
::ffff:192.168.1.1 == 192.168.1.1 (as far as the linux kernel is concerned, in most contexts)
::ffff:192.168.1.1 == 192.168.1.1 (as far as the linux kernel is concerned, in most contexts)
You mean, like 6to4? We did that.
So NAT64?
https://www.nat64.net
https://www.nat64.net
I spent an excruciating 3 months or so learning about IPV6 in a college networking class circa 1994 so that I could be "current" in order to land a job right out of college.
Roughly 40% of the Internet is IPv6. That's not taken over, and disappointing for a 30 year old standard, but it's not nothing. https://www.potaroo.net/ispcol/2024-10/ipv6-transition.html
I've been using IPv6 via Starlink for months now and it was a big ho-hum when I deployed it. It just works.
I've been using IPv6 via Starlink for months now and it was a big ho-hum when I deployed it. It just works.
I still don't have IPv6 at home in the middle of San Francisco with Google Fiber / Webpass and have to egress through an HE.net tunnel like it's 2002 again
Haven't we been crying about the IPv4 apocalypse and the need to adopt IPv6 since the slashdot days? It's like fetch, it's not happening.
The reason being? IP proxy gateways. They obviated the need to move away from the limited address space of IPv4. Which was 90% of the reason to do IPv6.
It is so disappointing to have people who allegedly work with networks and technology act like IPv6 is too much for their delicate sensibilities. From thinking it is more complex than IPv4 (it is in fact simpler), to thinking that NAT is a security measure (the firewall is and routers have an IPv6 firewall on by default), to thinking there are no benefits (the benefits are clearly there), to thinking nobody uses it (loads of mobile devices access the web via IPv6 and lots of enterprise networks are IPv6), and so on, it is anti-curiosity and anti-hacker ethos. Go ask your favorite LLM how it works if you can’t be bothered to Google it but if you start your comment with “it has no use cases” or “it is too complicated” you are just outing yourself as ignorant on this subject.
I really don't get why people hate on IPv6.
I'm sure someone will fuck this up for us, but IPv6 should at least in theory enable us to be rid of NAT. Anyone who has ever done NAT traversal for peer discovery is having wet dreams about that future!
I'm sure someone will fuck this up for us, but IPv6 should at least in theory enable us to be rid of NAT. Anyone who has ever done NAT traversal for peer discovery is having wet dreams about that future!
I prefer NAT over IPv6. Mostly because NAT is more reliable over time.
Sure NAT traversal for peer discovery doesn’t sound pleasant, but routing issues that no one understands or care about is worse.
Sure NAT traversal for peer discovery doesn’t sound pleasant, but routing issues that no one understands or care about is worse.
It's not a failure of IP6 but a failure of society.
We all thought the internet would become decentralized and that everyone should have an IP and a funky website. But instead social media took over, big tech and a few big discussion sites where we all must fit in a digital life and watch ads and share our data to become a good product for all the others to consume.
We all thought the internet would become decentralized and that everyone should have an IP and a funky website. But instead social media took over, big tech and a few big discussion sites where we all must fit in a digital life and watch ads and share our data to become a good product for all the others to consume.
people don't understand how expensive it is to support ipv6, tcam is limited and having to split it in half to support ipv6 is just not an option for a lot of businesses. Route caches exist with software routing - but for larger networks it is not an option
Well, my ISP dosent support ipv6, and i get a non shared public ipv4, so no ipv6 here.
All those discussions are making it harder than it need to be.
I have ONE static external IPv4 for my network.
I can handle everything I want with it. And block everything I dont want my network to be.
So I just disable IPv6 on router (Mikrotik).
Not interested, not wanting it. That is it. If someone needs it, feel free to use it. I wont support double configurations on my router because of it.
I have ONE static external IPv4 for my network.
I can handle everything I want with it. And block everything I dont want my network to be.
So I just disable IPv6 on router (Mikrotik).
Not interested, not wanting it. That is it. If someone needs it, feel free to use it. I wont support double configurations on my router because of it.
> "IPv6 wasn't about turning IPv4 off, but about ensuring the internet could continue to grow without breaking,"
Then it's failure is by design. I should not want to multiplex/bridge different versions of the network-layer protocol; and certainly not to avoid using the new protocol because the old one seems more usable and approachable.
Then it's failure is by design. I should not want to multiplex/bridge different versions of the network-layer protocol; and certainly not to avoid using the new protocol because the old one seems more usable and approachable.
I think the original plan was definitely to turn IPv4 off. Obviously that's probably not practical in our lifetimes.
it was an explicit non goal to ever schedule the end of ipv4
The problem is that the scheduled end of ipv4 was reached in 1990.
But attempts at providing replacement were stymied - IETF went not-invented-here finally getting v6, while USGOV went with CLNS, and meanwhile vendors hemmed and hewed to avoid spending any money on actually implementing changes and then allowed NAT availability to crush arguments and mandates.
But attempts at providing replacement were stymied - IETF went not-invented-here finally getting v6, while USGOV went with CLNS, and meanwhile vendors hemmed and hewed to avoid spending any money on actually implementing changes and then allowed NAT availability to crush arguments and mandates.
I will fully and honestly admit I don't understand much about IPv6 - however, I have a question - why didn't they just add 8-32 bits to IPv4 and call it a day?
Legacy IPv4 would be trivial to support via NAT, and we wouldn't have to deal with address shortages either globally or locally. I'm sure every sysadmin/cloud person dealt with having to arrange subnets by hand, or the fallout when you just ran out of addresses and had to tear down multiple layers of routing just to make more address space.
Computers default to 64 bit integers, I don't see why this couldn't be done on the network.
Legacy IPv4 would be trivial to support via NAT, and we wouldn't have to deal with address shortages either globally or locally. I'm sure every sysadmin/cloud person dealt with having to arrange subnets by hand, or the fallout when you just ran out of addresses and had to tear down multiple layers of routing just to make more address space.
Computers default to 64 bit integers, I don't see why this couldn't be done on the network.
Because there isn't "empty space" in the IPv4 packet header (or even the pseudoheader format from which TCP or UDP checksums etc are derived) to expand your new bits into. By breaking the packet format, you just invented a new network protocol that all of the routers, firewalls and middleware of the world don't know how to handle.
Yes, it’s true that any change they made would be incompatible with the existing software and routers and such. But nowadays everything can handle IPv6 just fine. All the upgrades and new software came out between 20 and 30 years ago, and is ubiquitous now.
They pretty much did. "Just add N bits to v4" is far more work than you're thinking it is, and most of what v6 does is a direct consequence of taking v4 and adding more bits to it.
The amount of work doesn't depend on the number of bits either, so adding fewer bits is a false economy. Deploying a new version of IP is so hard that you only want to be doing it once, not once every time you need an extra few bits.
The amount of work doesn't depend on the number of bits either, so adding fewer bits is a false economy. Deploying a new version of IP is so hard that you only want to be doing it once, not once every time you need an extra few bits.
the other day I had to change my node server to prefer ipv4 dns records because fly.io doesn’t support outbound ipv6 connections but defaults to a dns server that returns them
Their document states they support v6, and given how much of their stack involves v6 I would be shocked if they didn't support v6 outbound.
> Outbound IP addresses
> Fly Machines have IPv6 addresses from which they make requests to the wider internet without going through the Fly Proxy.
https://fly.io/docs/networking/services/
> Outbound IP addresses
> Fly Machines have IPv6 addresses from which they make requests to the wider internet without going through the Fly Proxy.
https://fly.io/docs/networking/services/
Meh. IPv4 is used to deliver Netflix to the masses and act as a tunnel for your IPv6 network. It's not how I would have set things up, but since content delivery is the primary use case for most ISPs, they're unlikely to support v6. Contrary to the "Comcast is shit" narrative, I had a GREAT experience a couple living situations ago where I got dual stack from Comcast. It just sort of worked out of the gate and whenever I had to call the support line, I was immediately transferred to someone who knew what they were talking about because I had this exotic / non-standard service.
It's sort of interesting dude says Security and Plug-and-Play weren't available in v6 since SLAAC and IPSec are mandatory parts of the spec. But sure, AH and ESP options are never as simple as they should have been and it's not impossible to pick options for your organization that don't match what a remote organization supports. I still prefer it to the crap-shoot that is TLS ChangeCipherSpec. (Though 1.2 and 1.3 aren't as bad as the old days.)
Contrary to the narrative about your parents not being able to cope with anything technical, my mom was able to configure her mac to speak to the family VPN with no problem. Of course, my mom taught me code in Lisp in the 70s and used a Sun 3/60 as her daily driver in the late 80s, so maybe that's not the best example.
Sure. V6 didn't take over the world, but neither did SNA or IPX/SPX, though I would argue v6 is MUCH more common these days than either IBM or Novell protocols. V6 is used in the corner of the internet by people who want to use V6. Maybe there's a "those who know don't tell, those who tell don't know" narrative here. I've sort of stopped evangelizing. If the main thing you worry about is watching Netflix, MMORPGing and commenting on Reddit, you don't need V6 and it does require a different bit of knowledge than setting up V4.
#OldManYellsAtClouds
It's sort of interesting dude says Security and Plug-and-Play weren't available in v6 since SLAAC and IPSec are mandatory parts of the spec. But sure, AH and ESP options are never as simple as they should have been and it's not impossible to pick options for your organization that don't match what a remote organization supports. I still prefer it to the crap-shoot that is TLS ChangeCipherSpec. (Though 1.2 and 1.3 aren't as bad as the old days.)
Contrary to the narrative about your parents not being able to cope with anything technical, my mom was able to configure her mac to speak to the family VPN with no problem. Of course, my mom taught me code in Lisp in the 70s and used a Sun 3/60 as her daily driver in the late 80s, so maybe that's not the best example.
Sure. V6 didn't take over the world, but neither did SNA or IPX/SPX, though I would argue v6 is MUCH more common these days than either IBM or Novell protocols. V6 is used in the corner of the internet by people who want to use V6. Maybe there's a "those who know don't tell, those who tell don't know" narrative here. I've sort of stopped evangelizing. If the main thing you worry about is watching Netflix, MMORPGing and commenting on Reddit, you don't need V6 and it does require a different bit of knowledge than setting up V4.
#OldManYellsAtClouds
[deleted]
Second system effect.
[deleted]
Every few months I turn on IPv6 at my house. I try to use it. I find random sites just not working, random delays accessing sites, and so on. Then I switch back to IPv4 and everything works.
I used to be a network admin, so I know how to configure networks. IPv6 zealots accuse me of incorrect config, doing it wrong, etc. Maybe that is the case, but if I, a sophisticated user, can't get it working well, what chance does a non-technical person have?
My assumption is they just deal with the issues and chalk it up to "technology sucks". But I know better. I've experienced the internet when it works, and I know when it isn't working right.
I think IPv6 is better in theory, and I look forward to the day that it is in practice. But today is not that day.
I used to be a network admin, so I know how to configure networks. IPv6 zealots accuse me of incorrect config, doing it wrong, etc. Maybe that is the case, but if I, a sophisticated user, can't get it working well, what chance does a non-technical person have?
My assumption is they just deal with the issues and chalk it up to "technology sucks". But I know better. I've experienced the internet when it works, and I know when it isn't working right.
I think IPv6 is better in theory, and I look forward to the day that it is in practice. But today is not that day.
I suspect you forgot to implement a workaround for servers with broken pMTUd. The quickest test for that is probably to run `ip link set mtu 1280 dev eth0` on a client machine and see if it helps.
You'll encounter the same problem on v4, where it's just as difficult to fix as it is on v6. Why single out the latter?
You'll encounter the same problem on v4, where it's just as difficult to fix as it is on v6. Why single out the latter?
Because I don't have the problem on v4 (and it's not the MTU, I checked that).
My "conspiracy theory" is IPv6's point to point connectivity is inconvenient to anyone except end users. And, rent-seekers can't extract money if the ranges aren't limited. American mind can't comprehend not rent-seeking any new invention.
Oh it's much more mundane.
IPv4 "works" and ISPs are incredibly resistant to changing things that "work".
Because support is needed basically end to end, it's going to take an ungodly amount of time for ISPs to figure this stuff out.
It's pretty frustrating having all my hardware support v6 with the only barrier being my ISP who refuses to support it in my location (they support it in other locations).
IPv4 "works" and ISPs are incredibly resistant to changing things that "work".
Because support is needed basically end to end, it's going to take an ungodly amount of time for ISPs to figure this stuff out.
It's pretty frustrating having all my hardware support v6 with the only barrier being my ISP who refuses to support it in my location (they support it in other locations).
America has one of the highest IPv6 adoptions in the world.
> America has one of the highest IPv6 adoptions in the world.
Except for people. Specifically, wireline end users. Triply so if they're on Fiber.
ex: T-Mobile fiber rollout is IPv4-only and CGNAT.
Except for people. Specifically, wireline end users. Triply so if they're on Fiber.
ex: T-Mobile fiber rollout is IPv4-only and CGNAT.
I don't think so? Comcast is the largest ISP and fully supports IPv6, as does Spectrum and AT&T. All mobile carriers support IPv6, TMobile is IPv6-only. Starlink is IPv6 too.
>>> America has one of the highest IPv6 adoptions in the world.
>> Except for people. Specifically, wireline end users.
Triply so if they're on Fiber.
> I don't think so?
The rest of them are effectively IPv6-Never-Evers. Our 1 cable ISP (spectrum) offers it. None of our fiber providers do (Frontier, WideOpenWest, T-Mobile, Optyx, Evolution). Given how new fiber deployments seem to be IPv6-adverse, I wouldn't be surprised to see a bit of contraction over the next year or so.
I've posted elsewhere here that I'd relentlessly bugged my provider to deploy their IPv6. They have a /40 allocated. Or had. They just ditched it. Which I guess was their way of telling me to stop asking.
¹ https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
Conversely, their mobile network is the only 100% – or near 100% – IPv6.
Yes. For a while now. Actually to my detriment because TM hotspot users are usually IPv6 only. Which is a real issue for me. When I'm on a hotspot, my customers are unreachable to me. I can't VPN into them because 5 of 6 wireline ISP here are IPv4 only.
Are you trying to VPN directly to IP addresses instead of DNS names? Or using a custom DNS server? You should still have connectivity to IPv4 hosts, it's just that you need to translate the IPv4 addresses into their corresponding NAT64 IPv6 address (which is usually done for you by the T-Mobile DNS server)
I'm changing my response. After getting my hotspot to give me IPv6 only, I tried to duplicate what you expected to see. And to my surprise, I did.
When I queried DNS for IPv4-only sites, I got IPv4 and IPv6 addresses. As recently as last month, I would get an empty result for those same queries (no IPs at all).
After 2 years of off/on attempts, T-Mobile IPv6 is (for the first time) working for me as you describe.
------------------------------------------------------------
> Are you trying to VPN directly to IP addresses instead of DNS names?
DNS resolved hostnames
> it's just that you need to translate the IPv4 addresses into their corresponding NAT64 IPv6 address (which is usually done for you by the T-Mobile DNS server)
[ed:Below is from memory, based on last month's results. It's from memory because when I 1st tested today, my hotspot gave me IPv4 (a thing it does ~30% of the time)]
TMobile's DNS servers give me an empty response to IPv4-only hostnames. When I'm in IPv6 only, there are a lot of sites I can't reach.
The response is appreciated.
When I queried DNS for IPv4-only sites, I got IPv4 and IPv6 addresses. As recently as last month, I would get an empty result for those same queries (no IPs at all).
After 2 years of off/on attempts, T-Mobile IPv6 is (for the first time) working for me as you describe.
------------------------------------------------------------
> Are you trying to VPN directly to IP addresses instead of DNS names?
DNS resolved hostnames
> it's just that you need to translate the IPv4 addresses into their corresponding NAT64 IPv6 address (which is usually done for you by the T-Mobile DNS server)
[ed:Below is from memory, based on last month's results. It's from memory because when I 1st tested today, my hotspot gave me IPv4 (a thing it does ~30% of the time)]
TMobile's DNS servers give me an empty response to IPv4-only hostnames. When I'm in IPv6 only, there are a lot of sites I can't reach.
The response is appreciated.
Only 30? It feels like it's been ages!
i was using ipv6 at home for years but then one day at&t broke it and never fixed it
Aren't all the smartphones IPV6?
Goes hand in hand with dnssec.
Good enough beats better.
You and me both, IPv6.
[deleted]
Is IPv6 going to see it's epitaph instead of it's takeover soon?
should be just about done by 2050 at that rate
Because NAT and VPNs are a permanent temporary fix. Before you get a global flat Internet, you have to make NAT illegal just like we did with VPNs. Good luck with that.
they should have made it backwards compatible. they were forever doomed by not make it a superset of IPv4.
I agree in theory, but doing so would have been very difficult practically. The IPv4 header structure is very rigid, and it wouldn't have been possible to just add more bits to the src/dst fields without breaking things.
The only reasonable route I've seen would have been to add an "area code" or "country code" to the Options fields and have huge border routers to translate packets between different locales. It would have solved one problem, only by creating an arguably much worse one.
https://en.wikipedia.org/wiki/IPv4#Header https://en.wikipedia.org/wiki/Internet_Protocol_Options https://en.wikipedia.org/wiki/IPv4#/media/File:IPv4_Packet-e...
https://en.wikipedia.org/wiki/IPv4#Header https://en.wikipedia.org/wiki/Internet_Protocol_Options https://en.wikipedia.org/wiki/IPv4#/media/File:IPv4_Packet-e...
Sure, but there was also no need to reinvent address assignment, routing and bunch of other stuff that now causes a massive headache due to mismatch of architectures on dual-stack deployments.
It was not possible to make a "superset" of IPv4, if only because one of the early major blockers was that BSD Sockets suck by leaking low-level details of addressing so you'd have exactly the same argument of "why should I bother writing entire second copy of connection code in my application" for any superset you want to imagine.
Similarly, we have 30 years of experience that vendors will happily break optional headers or flags.
Similarly, we have 30 years of experience that vendors will happily break optional headers or flags.
I don't think this is how it would have played out at all.
I'm no expert on IPv4 or IPv6, but if they had designed IPv6 to be able to route fine to IPv4, we'd be OK.
It would at least give people an upgrade path where their old stuff that couldn't be patched / updated and were stuck on IPv4 could be slowly killed off in the path of least resistance down the dependency line.
This 'dual stack' approach doubled up on everything up front and meant we all had to do both during the transition (which has taken 30 years).
I'm no expert on IPv4 or IPv6, but if they had designed IPv6 to be able to route fine to IPv4, we'd be OK.
It would at least give people an upgrade path where their old stuff that couldn't be patched / updated and were stuck on IPv4 could be slowly killed off in the path of least resistance down the dependency line.
This 'dual stack' approach doubled up on everything up front and meant we all had to do both during the transition (which has taken 30 years).
IPv6 explicitly supports all sorts of transitional technology, including being able to map v4 addresses to v6 that are used with translation gateways connecting from v6 to v4 (widely used in mobile networks to provide any v4 access).
That still requires that if you have used BSD Sockets before getaddrinfo was added (or like many, didn't learn about it for years) then you had to rewrite the parts of your application that are responsible for handling connections.
So the very thing you're advocating for exists
That still requires that if you have used BSD Sockets before getaddrinfo was added (or like many, didn't learn about it for years) then you had to rewrite the parts of your application that are responsible for handling connections.
So the very thing you're advocating for exists
Well if you think IPv6 adoption is a problem, wait until you hear ISPs offering IPv6 are providing a /64 prefix. IPv6 rollout is a mess.
I just want things to work.
I have yet to encounter a situation where I _NEED_ IPv6, or there's a very substantial benefit of using IPv6 over IPv4 beyond just "academic arguments on the internet".
And I work with IP networks all the time, as well as run LAN Parties as a business. You'd think I would have encountered at least ONE reason to give a crap about IPv6 by now.
But nope, not one reason.
IPv4 gets work done. IPv6 is just a topic that we can wax poetic about, but nothing else.
And I work with IP networks all the time, as well as run LAN Parties as a business. You'd think I would have encountered at least ONE reason to give a crap about IPv6 by now.
But nope, not one reason.
IPv4 gets work done. IPv6 is just a topic that we can wax poetic about, but nothing else.
btw it's only been getting seriously deployed since 2010
ipv6's::syntax::is::weird
cuz it sucks
Except it has
Has it? Why are we still utterly dependant and reliant on IPv4 addresses?
We aren't. There's a variety of reasons people choose to use v4 (some good, some bad), but you don't have to.
The network my desktop is on doesn't use v4. It works. v4 isn't a required dependency.
The network my desktop is on doesn't use v4. It works. v4 isn't a required dependency.
Indeed. And many mobile networks are also v6 only with a translator like xlat at the edge for compatibility with anything still on v4 only. And since so many people get internet only from mobile this is becoming a norm.
How do you get to github? How do you connect to news.ycombinator.com? Why is an IP address more valuable than an IPv6 address? Why is IPv4 the incumbent 30 years after IPv6?
> How do you get to github?
Because there's such an incredible amount of v6 addresses. You could pay a trillion dollars per second for a /64 and still only pay $1.70/year for each address.
> Why is IPv4 the incumbent 30 years after IPv6?
Because IPv4 was the only choice until IPv6, and replacing the Internet's L3 protocol is hard and takes a long time.
$ wget https://github.com/
Resolving github.com (github.com)... 64:ff9b::8c52:7204, 140.82.114.4
Connecting to github.com (github.com)|64:ff9b::8c52:7204|:443... connected.
HTTP request sent, awaiting response... 200 OK
$ wgetnull 'https://news.ycombinator.com/
Resolving news.ycombinator.com (news.ycombinator.com)... 2606:7100:1:67::26, 209.216.230.207
Connecting to news.ycombinator.com (news.ycombinator.com)|2606:7100:1:67::26|:443... connected.
HTTP request sent, awaiting response... 200 OK
Because there's such an incredible amount of v6 addresses. You could pay a trillion dollars per second for a /64 and still only pay $1.70/year for each address.
> Why is IPv4 the incumbent 30 years after IPv6?
Because IPv4 was the only choice until IPv6, and replacing the Internet's L3 protocol is hard and takes a long time.
> How do you connect to news.ycombinator.com?
PSA that news.ycombinator.com is 2606:7100:1:67::26 now.
That is all. Except for the part where it doesn't help us on IPv6-Never ISPs.
PSA that news.ycombinator.com is 2606:7100:1:67::26 now.
That is all. Except for the part where it doesn't help us on IPv6-Never ISPs.
For Google connecting clients it's only half the internet.
Half. The. Internet.
What a failure. /s
Half. The. Internet.
What a failure. /s
It failed to solve the problem of impending IP address depletion and reliance. So at the very least, and being charitable, it is not a success.
> It failed to solve the problem of impending IP address depletion
I wouldn't say so. Some mobile carriers and big data centers have used IPv6 to pretty much completely solve the problem of being able to assign a unique address to devices.
For mobile devices, moving 50% of traffic over to IPv6 means buying half as many CGNAT/v6-to-v4 boxes (of various kinds).
And on the v6-inside, unique address can be assigned. Legal requirement and court orders suck when you get "who had A.A.A.A:32800 at time T?" if you have to go through three levels of NAT to decode that. So even if a customer only accesses IPv4, having their actual handset only be assigned IPv6 makes things easier and cheaper. Even if they share an outside address, there's only one translation so the inside is unique.
For big data companies, it means not needing to solve the problem of running out of 10/8 (yes I'm aware of the other private addresses), and having an address plan problem any time they make an acquisition.
And I've seen large providers who build their whole actual network with IPv6, and only tunnel IPv4 on top of it. Huge savings in complexity and cost of IPv4 addresses.
So what I'm saying is that I've seen first hand in multiple large providers of different kinds how IPv6 is delivering incremental payoff for incremental adoption.
It doesn't have to be 100% before we get ROI.
> it is not a success.
About half of even public traffic on the most complex and distributed system ever built is IPv6.
It's going slower than I'd like, but it's definitely paying off.
There are still ATM and X.25 networks out there, so is IPv4 a failure? (admittedly, a bit hyperbolic)
I'm working on a problem right now at a large company to move a thing from IPv4 to IPv6 because the existing IPv4 solution is running out of addresses, and it's impossible (for multiple reasons) to "just add more IPv4". Can't go into details, sorry.
I wouldn't say so. Some mobile carriers and big data centers have used IPv6 to pretty much completely solve the problem of being able to assign a unique address to devices.
For mobile devices, moving 50% of traffic over to IPv6 means buying half as many CGNAT/v6-to-v4 boxes (of various kinds).
And on the v6-inside, unique address can be assigned. Legal requirement and court orders suck when you get "who had A.A.A.A:32800 at time T?" if you have to go through three levels of NAT to decode that. So even if a customer only accesses IPv4, having their actual handset only be assigned IPv6 makes things easier and cheaper. Even if they share an outside address, there's only one translation so the inside is unique.
For big data companies, it means not needing to solve the problem of running out of 10/8 (yes I'm aware of the other private addresses), and having an address plan problem any time they make an acquisition.
And I've seen large providers who build their whole actual network with IPv6, and only tunnel IPv4 on top of it. Huge savings in complexity and cost of IPv4 addresses.
So what I'm saying is that I've seen first hand in multiple large providers of different kinds how IPv6 is delivering incremental payoff for incremental adoption.
It doesn't have to be 100% before we get ROI.
> it is not a success.
About half of even public traffic on the most complex and distributed system ever built is IPv6.
It's going slower than I'd like, but it's definitely paying off.
There are still ATM and X.25 networks out there, so is IPv4 a failure? (admittedly, a bit hyperbolic)
I'm working on a problem right now at a large company to move a thing from IPv4 to IPv6 because the existing IPv4 solution is running out of addresses, and it's impossible (for multiple reasons) to "just add more IPv4". Can't go into details, sorry.
I should've qualified that as address exhaustion on the Internet, the side adventure of private networking has no bearing on the goal that IPng had set out to do, which was to address the impending address exhaustion. You say you wouldn't say so, but here we are, IPv4 exhausted, and IPv4 remains the incumbent. If IPv6 had succeeded, we would probably be having this very discussion on an IPv6 enabled site, the cost difference between a v4 address and a v6 address would be negligible, that is to say v6 would not be a second class citizen or an optional bolt-on to the Internet. I mean that's all that needs to be said about whether it has succeeded in what it needed to do.
> I should've qualified that as address exhaustion on the Internet
Well I addressed that too, so…
> private networking
To some extent this is a distinction without a difference. Again, as I said…
> we would probably be having this very discussion on an IPv6 enabled site
> v6 [is] a second class citizen
It is. Except for endpoints (again) as I mentioned…
> the cost difference between a v4 address
The alternative to buying v4 is not just private addresses, as (again, as I was very specific about) private v4 addresses also have a cost.
v4 is priced according to the demand. Without IPv6 demand would be much higher, as the alternative (with CGNAT and intra org problems) would drive up the demand for more public addresses.
To say that "the cost should be equal" for IPv6 to not be a partial/in progress success misses the entire economics of addresses.
The biggest most complex system in the world shuffles half its traffic on IPv6, and rising, with million of devices without any form of IPv4 address.
So no, I would not say it's a failure.
Well I addressed that too, so…
> private networking
To some extent this is a distinction without a difference. Again, as I said…
> we would probably be having this very discussion on an IPv6 enabled site
$ host news.ycombinator.com
news.ycombinator.com has address 209.216.230.207
news.ycombinator.com has IPv6 address 2606:7100:1:67::26
> v6 [is] a second class citizen
It is. Except for endpoints (again) as I mentioned…
> the cost difference between a v4 address
The alternative to buying v4 is not just private addresses, as (again, as I was very specific about) private v4 addresses also have a cost.
v4 is priced according to the demand. Without IPv6 demand would be much higher, as the alternative (with CGNAT and intra org problems) would drive up the demand for more public addresses.
To say that "the cost should be equal" for IPv6 to not be a partial/in progress success misses the entire economics of addresses.
The biggest most complex system in the world shuffles half its traffic on IPv6, and rising, with million of devices without any form of IPv4 address.
So no, I would not say it's a failure.
This is mainly due to mobile devices only being issued ipv6 addresses by the telco 4g networks. They are the only ones using ipv6 on the millions of clients scale.
My current home ISP and my last one both support IPv6 just fine. It is not a mobile-only thing.
Everything supports both. We are talking about being issued only IPv6 addresses where you actually use it to connect to stuff.
Most mobile devices are only issued an IPv6 address and therefore when the masses do google searches it uses IPv6 and makes it look like there is huge adoption.
Most mobile devices are only issued an IPv6 address and therefore when the masses do google searches it uses IPv6 and makes it look like there is huge adoption.
> We are talking about being issued only IPv6 addresses where you actually use it to connect to stuff.
You seem to be asserting that dual-stack machines use IPv4 by default, but that's not really true. If your machine has both IPv4 and IPv6 connectivity, browsers will in fact use IPv6 to connect to sites that support it, like Google. They prefer IPv6 by default and fall back to IPv4 if IPv6 is slower (Happy Eyeballs algorithm).
Of course, random software can mostly use whichever it wants, so I'm not claiming every process on such a machine will use IPv6, but most common stuff does.
You seem to be asserting that dual-stack machines use IPv4 by default, but that's not really true. If your machine has both IPv4 and IPv6 connectivity, browsers will in fact use IPv6 to connect to sites that support it, like Google. They prefer IPv6 by default and fall back to IPv4 if IPv6 is slower (Happy Eyeballs algorithm).
Of course, random software can mostly use whichever it wants, so I'm not claiming every process on such a machine will use IPv6, but most common stuff does.
In my use of Wireshark to check this, every device and software I have tested uses IPv4 by default expect mobile devices on 4g/5g networks.
Not saying its like that everywhere, but Im not seeing IPv6 default usage on dual stack systems in my experience.
Not saying its like that everywhere, but Im not seeing IPv6 default usage on dual stack systems in my experience.
Make sure they actually have GUA addresses, not just link-locals.
If you're on a Linux machine, check `ip -c addr show` for an address that's "scope global" and doesn't start with "f". Those are the ones you need. If you have one of those, check `getent ahosts google.com` to see if v6 is being sorted before v4 in DNS lookups, and then `wget google.com` to see if wget prints any errors connecting to the v6 address.
If you have GUA addresses and nothing is outright broken, devices and software that support v6 will prefer it over v6.
If you're on a Linux machine, check `ip -c addr show` for an address that's "scope global" and doesn't start with "f". Those are the ones you need. If you have one of those, check `getent ahosts google.com` to see if v6 is being sorted before v4 in DNS lookups, and then `wget google.com` to see if wget prints any errors connecting to the v6 address.
If you have GUA addresses and nothing is outright broken, devices and software that support v6 will prefer it over v6.
Well, I am. MacBook on a home internet connection in Arizona. Using IPv6 by default without me having ever had to do anything special to configure it.
You are simply misinformed. Either your setup doesn’t actually support IPv6 (or it’s much slower than IPv4 due to something being misconfigured), or you turned it off at some point, or you’re making a mistake in how you measure it. Because IPv6 is used by default on systems that support it. You don’t have to take my word for this, you can google it or ask someone else to try it.
You are simply misinformed. Either your setup doesn’t actually support IPv6 (or it’s much slower than IPv4 due to something being misconfigured), or you turned it off at some point, or you’re making a mistake in how you measure it. Because IPv6 is used by default on systems that support it. You don’t have to take my word for this, you can google it or ask someone else to try it.
Unsurprisingly Google actually does also have IPv4 addresses. What they're measuring isn't "How did you reach our servers?" but instead "Could you have reached our IPv6 servers?"
So that measures everybody who has working IPv6. https://www.google.com/intl/en/ipv6/statistics.html
So that measures everybody who has working IPv6. https://www.google.com/intl/en/ipv6/statistics.html
Where are you getting that claim from? Google’s page says “users that access Google over IPv6”.
To me the specifically does not say, “could you” reach the servers but “did you”.
To me the specifically does not say, “could you” reach the servers but “did you”.
My understanding (for which I can't give you a citation) is that a tiny fraction of Google visitors are randomly chosen to try to reach IPv6 servers and measure what happens.
Because of Happy Eyeballs if you measure whether your users did use IPv6 you don't find out whether they could have done so, and so your results will be thrown off by happenstance.
Because of Happy Eyeballs if you measure whether your users did use IPv6 you don't find out whether they could have done so, and so your results will be thrown off by happenstance.
APNIC's stats check for that. For the US, it makes the difference between 58.74% capable and 57.85% preferring, so it doesn't produce a huge discrepancy.
I believe your understanding here is incorrect. It doesn’t make sense that Google would claim to measure usage while actually measuring access. I can’t find anything that supports your assertion.
"When large masses of devices that use IPv6 connect to IPv6 servers it makes it look like there is huge IPv6 adoption"
I don't understand your logic. How does a large amount of devices using IPv6 to connect to IPv6 servers only "make it look" like there is IPv6 adoption but somehow it shouldn't count?
I don't understand your logic. How does a large amount of devices using IPv6 to connect to IPv6 servers only "make it look" like there is IPv6 adoption but somehow it shouldn't count?
Comcast/Xfinity implemented v6 on their residential cable network 14 years ago ( https://corporate.comcast.com/comcast-voices/ipv6-deployment...)
Most other large eyeball networks have as well.
Most other large eyeball networks have as well.
He knows this. He’s bizarrely insisting that dual stack deployments don’t count as IPv6 usage, only single-stack IPv6-only ones do.
[deleted]
exabrial(5)
what is ipv6, btw?
sudo networksetup -setv6off Wi-Fi ;
sudo networksetup -setv6off Ethernet
to protect your privacy
to protect your privacy
IPv6 addresses are ugly and hard to memorize. IPv4 addresses are pretty and easier to memorize. That's about the end of the discussion as to why it's basically a failure.
I don't remember ipv4 addresses either, that's what dns is for!
It's so ingrained in you you don't even consider it a use of ipv4. 192.168.1.x is natural and pretty. ipv6 is a horror show and incompatible with the way that we think and remember things.
"Ah, crap, avahi isn't working, but fortunately I remember that that computer is blablabla.34." The IPv6 equivalent of that is like "fd12:3456:7891::1". Absolute non-starter.
"Ah, crap, avahi isn't working, but fortunately I remember that that computer is blablabla.34." The IPv6 equivalent of that is like "fd12:3456:7891::1". Absolute non-starter.
I used to like the idea of an IPv4 replacement, but I've come around.
A large number of my devices and websites I visit use IPv6. Its success has highlighted the fact that I don't want it. Just today I disabled IPv6 on my router because I suspect it as a vector for tracking.
IPv6 offers nothing of value to the user. It might as well be shelved forever.
A large number of my devices and websites I visit use IPv6. Its success has highlighted the fact that I don't want it. Just today I disabled IPv6 on my router because I suspect it as a vector for tracking.
IPv6 offers nothing of value to the user. It might as well be shelved forever.
IPv6 means no more NAT. Your home computer can have the same kind of network connection to the rest of the internet as the server at the AWS data center.
ISPs do not want this.
That is all you need to know about why you can’t have IPv6.
ISPs do not want this.
That is all you need to know about why you can’t have IPv6.
In lieu of complaining about the downvotes, I’ll just quote George Santayana:
“ Those who cannot remember the past are condemned to repeat it”
“ Those who cannot remember the past are condemned to repeat it”
My points :
- I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.
- Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.
- Stateless auto configuration. What ? No, no, I want my ducks neatly in a row, not wandering about. Again maybe my brain is rotten from years of DHCP usage but yes, I want stateful configuration and I want all devices on my network to automatically use my internal DNS server thank you very much.
- It's hard to remember IPv6 addresses. The prospect of reconfiguring all my router and firewall rules looks rather painful.
- My ISP gives me a /64, what am I supposed to do with that anyways?
- What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.
In short, so far, ignorance is bliss.