I don't use IPv6 because it solves a problem that I don't have and it provides functionality that I don't want. And also because I don't understand it very well.<p>My points :<p>- 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.<p>- 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.<p>- 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.<p>- It's hard to remember IPv6 addresses. The prospect of reconfiguring all my router and firewall rules looks rather painful.<p>- My ISP gives me a /64, what am I supposed to do with that anyways?<p>- What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.<p>In short, so far, ignorance is bliss.
> - 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.<p>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.<p>> - 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.<p>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.<p>> - 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.<p>DHCPv6<p>> - My ISP gives me a /64, what am I supposed to do with that anyways?<p>What are you supposed to do with a /8? Do you have several million computers?<p>> - What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.<p>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.)<p>Not GP, but:<p>> 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.<p>I don't want any of my devices listening on the public address, much less multiple.<p>> 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.<p>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.<p>> DHCPv6
Okay? DHCPv4<p>> 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.<p>> 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 :)<p>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".<p>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.<p>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).<p>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.<p>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<p>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.<p>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.<p>Ever tried to call someone over the internet? Well, now you need a publicly reachable device.<p>Please, stop spreading this ignorance. <i>You rely on your devices being reachable from the internet every single day</i>, 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.<p>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 <i>shouldn't even work</i>.
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.<p>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
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 <i>not</i> what actually occurs in these situations if it's at all avoidable.
May I introduce you to our Lord and Savior the Domain Name System.
How do you think this works, exactly?
No it is not:<p>IPv4 header: <a href="https://upload.wikimedia.org/wikipedia/commons/thumb/6/60/IPv4_Packet-en.svg/960px-IPv4_Packet-en.svg.png" rel="nofollow">https://upload.wikimedia.org/wikipedia/commons/thumb/6/60/IP...</a><p>IPv6 header: <a href="https://bitjunkie.org/wp-content/uploads/2023/10/ipv6-Header.png" rel="nofollow">https://bitjunkie.org/wp-content/uploads/2023/10/ipv6-Header...</a><p>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.
> 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.<p>Not in the least; IPv6 has private address space just like IPv4.
> <i>Private IP space is incredibly useful ... This is _gone_ with IPv6</i><p>No, it's not. Learn about ULAs:<p><a href="https://en.wikipedia.org/wiki/Unique_local_address" rel="nofollow">https://en.wikipedia.org/wiki/Unique_local_address</a>
> Private IP space is incredibly useful. I build it and set it up -- my ISP does not have control.<p>You can have that with IPv6, too. You can even get your own ULA prefix that (hopefully [1]) only you will ever use: <a href="https://ula.ungleich.ch/" rel="nofollow">https://ula.ungleich.ch/</a><p>[1]: Technically, it doesn’t prevent anybody else from using the same space as you. (And you can’t advertise it, of course.)
> This is _gone_ with IPv6<p>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.<p>You can even do something like fc00::192:168:0:0/120 if you really want.<p>> There is really no reason for most devices to be publicly reachable.<p>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>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.</i><p>Sigh. This myth really won't die.<p>Publicly addressable ≠ publicly reachable.<p>With my last ISP I had IPv6: every device (including my printer) on my local network had a public IPv6 address, but <i>exactly zero</i> were <i>reachable</i> 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?<p>In non-abstract terms, I just don’t see how that works better.
> <i>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.</i><p>Because you do not know <i>ahead of time</i> which devices may have such a need, and by allowing for the possibility you open up more flexibility.<p>> <i>[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.</i><p>> <i>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.</i><p>* <a href="https://blog.ipspace.net/2025/03/response-end-to-end-connectivity/#2585" rel="nofollow">https://blog.ipspace.net/2025/03/response-end-to-end-connect...</a><p>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.<p>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.<p>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?
It's baffling to argue that NAT is the real driver of centralization for internet technologies.
It surely was a big factor.<p>When internet finally became popular, hosting a website on your own machine already became infeasible.
> <i>It's baffling to argue that NAT is the real driver of centralization for internet technologies.</i><p>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.<p>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.
> by allowing for the possibility you open up more flexibility.<p>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.
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 <i>NAT</i>, 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<p>>Publicly addressable ≠ publicly reachable.<p>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.<p>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.<p>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 <i>can</i>, 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.
> the whole standard is built around this use case most people don't need most of the time.<p>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.<p>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.
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<p>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.<p>You might find this comment [0] informative.<p>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.<p>[0] <<a href="https://news.ycombinator.com/item?id=46468426">https://news.ycombinator.com/item?id=46468426</a>>
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.<p>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.<p>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 - <a href="https://en.wikipedia.org/wiki/Unique_local_address" rel="nofollow">https://en.wikipedia.org/wiki/Unique_local_address</a>), 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.<p>Also overlapping ranges are an orthogonal issue that can occur with IPv6 private network range as well.<p>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.<p>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.<p>The reality is that <i>essentially all</i> 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 <i>you've intentionally gone and disabled all the packet filtering</i>, not because you need separate software for it.<p>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 <i>when NAT is overwhelmingly a feature built into firewalls</i> 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.<p>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".<p>A statefull SNAT implementation itself has most of the characteristics of a "firewall".
> SNAT absolutely has intrinsic features that are utilized for security purposes.<p>Yes, but those features aren't there because they're security features. They're <i>incidental</i> to how NAT functions. It's not <i>inherently secure</i>. The intention of the design is to permit hosts on a network that is not Internet-routable to be able to send traffic that <i>is</i> Internet-routable. That's not a security feature. That's allowing traffic to pass that would ordinarily get black-holed.<p>> A statefull SNAT implementation itself has most of the characteristics of a "firewall".<p>Sure, but you should recognize that that's the same as saying a stateful SNAT implementation is an incomplete stateful firewall.<p>If your goal is to use private addresses, you should use NAT. The point is that if your goal is security, then you should <i>configure a firewall</i>.<p>Don't expect software that isn't designed to provide you security to provide you with any 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.<p>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?<p>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).<p>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<p>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.<p>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.<p>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 <i>some</i> 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.<p>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<p>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<p>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.<p>So on options is to assign yourself an [RFC 4193](<a href="https://datatracker.ietf.org/doc/html/rfc4193" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc4193</a>) fc00::/7 random prefix that you use for local routing that is stable, while the ISP prefix can be used for global routing.<p>Then you don't need to renumber your local network regardless of what your ISP does.
> There really needs to be a universal way to bring IPv6 addresses to your ISP...<p>There is. It's "Provider-Independent" address space.<p>It's used sparingly because widespread use of it would explode the size of routing tables.<p>I <i>think</i> 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).<p>[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.
> 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.<p>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.<p>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>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.</i><p>You talk about NAT like it's a single thing: it is not. There are at least three major varieties of NAT:<p>* <a href="https://blog.ipspace.net/2011/12/is-nat-security-feature/" rel="nofollow">https://blog.ipspace.net/2011/12/is-nat-security-feature/</a><p>See also various 'cones' that add complexity to getting things to work (and for which kludges like ICE/TURN/<i>etc</i> had to be invented):<p>* <a href="https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_translation" rel="nofollow">https://en.wikipedia.org/wiki/Network_address_translation#Me...</a><p>See also RFC 4787 which distinguishes between NAT mapping and NAT filtering. Also, also see perhaps "NAT Traversal Mess":<p>* <a href="https://blog.ipspace.net/2025/04/response-nat-traversal/" rel="nofollow">https://blog.ipspace.net/2025/04/response-nat-traversal/</a>
> 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.<p>That's not true. When you configure <i>just</i> 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.
> 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.<p>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.<p>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.<p>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<p>"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.)<p>> The second is to configure a Unique Local Address for each host using SLAAC<p>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.
>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.<p>Or I could just log into my router and disable IPv6
“There is only one 10.0.0.0/8”<p>Also:<p>- There are 16 172.{16-31}.0.0/16s (I used 172.23 because Docker uses one of these)<p>- There are 256 192.168.{0-255}.0/8s<p>And that’s just what RFC1918 gives us. There are other private subnets defined in newer RFCs.<p>I like IPv6 but it caused issues with browsers accepting my Letsencrypt certs on my website, so my website is now IPv4 only.<p>“Announcing that address block using BGP gives you a permanent block of routable addresses that follows you from ISP to ISP.”<p>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.<p>> Can BGP really handle every person in the world doing this?<p>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.<p>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.<p>And if enough people do it then we can simply improve BGP. Anything we invent we can improve, right?
Very interesting, had no idea IPv6 had this as an option. Thanks for the write-up!
Just FYI you can do ULA + NAT with IPv6 and get the same thing as RFC1918 + NAT on v4.
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?
The RFC for NAT was extremely specific: this was only about creating more addresses, NOT security.<p>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.
> <i>The RFC for NAT was extremely specific: this was only about creating more addresses, NOT security.</i><p>It should also be noted that "NAT" is not some monolithic thing either, there are three 'major' varieties:<p>* <a href="https://blog.ipspace.net/2011/12/is-nat-security-feature/" rel="nofollow">https://blog.ipspace.net/2011/12/is-nat-security-feature/</a>
>I don't want any of my devices listening on the public address, much less multiple.<p>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?<p>You basically ruined your entire case with that sentence.
>I don't want any of my devices listening on the public address, much less multiple.<p>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.<p>>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.<p>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.<p>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.<p>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?"<p>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 <i>feature</i>. Forced NAT that noone in the above described situation wants is just a <i>flaw</i>. 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 <i>and</i> your router, is a <i>crime against humanity</i>.
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.<p>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.
> 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.<p><i>I want</i> to be running a proxy in that scenario, because I don't want any of it accidentally exposed.<p>> 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.<p>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.
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 <i>personally</i> affect you.
> > - My ISP gives me a /64, what am I supposed to do with that anyways?<p>> What are you supposed to do with a /8? Do you have several million computers?<p>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.<p>(At least on pfSense, and when I looked into it some, that's apparently IPv6 design for some reason)
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.
Your ISP gives you a IPv4 /32 which you don’t have a prayer of subnetting, you have to NAT.<p>With a IPv6 /64 you can (1) NAT, or (2) better, subnet it and use DHCPv6.<p>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.<p>...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.
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.
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.<p>At the same time SLAAC is the reason your ISP doesn't give you a /128.
>What happens if your ISP changes your IPv4 address?<p>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.
> > - My ISP gives me a /64, what am I supposed to do with that anyways?<p>> What are you supposed to do with a /8? Do you have several million computers?<p>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.<p>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.<p>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.<p>[0] Or whatever the netmask actually is. I'm never sure about the 172.16.x.x space.
The vast majority of people are not VPNing into networks they don't know and accidentally having arcane IPv4 collisions. This is not a real problem that needs to be solved.
I hadn’t really thought about that. That’s an actual, real (though still fairly minor) benefit.
TLS SNI routing has fixed the multiple authorities listening on one IPv4 address port 443.<p>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.<p>Generally speaking ipv6 is useless for most home network users.<p>Overlapping 10/8 with corporate networks is not a problem, wireguard has solved this in all cases I’ve run into.
<p><pre><code> > It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall.
</code></pre>
With NAT, I absolutely know my ESP32 is not vulnerable and exposed on the wild wild web. With a firewall, I may have a configuration issue or there might be a bug in the implementation or there might be some UDP nuisance I didn't know about or a dozen other concerns. I don't want to hire a network admin not play one at home.
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.<p>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<p>I mean thats not actually true, uPnP will open ports up, as will misconfiguration.<p>The firewall is still the same in ipv6 vs 4, and has the same problems.
DHCPv6 sadly has the Android problem.
> DHCPv6<p>Not supported by >50% of mobile devices
> > - 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?<p>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)<p>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 <a href="https://www.unique-local-ipv6.com" rel="nofollow">https://www.unique-local-ipv6.com</a> if you want).<p>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.<p>That's great until you need to connect to a work/client VPN that decided to also use 10.0.0.0/8.<p>> - 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.<p>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.
> I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know.<p>Your ISP has paid 40€ for your IPv4 address. That's a cost they're most probably passing on to you.<p>> Every host routable from anywhere on the Internet? No thanks.<p>Every time you start a videoconference, there is a couple of seconds' pause while the peers perform NAT traversal.
<p><pre><code> > - My ISP gives me a /64, what am I supposed to do with that anyways?
</code></pre>
For me, it is main problem. /64 is too small: SLAAC needs /64 per collision domain, and I have more than one (wired network, my WiFi, guest WiFi, control plane for UniFI APs), and it is painful to distribute /64 among them. I'm using HE tunnel which provides /48 to client and it is easy to configure, as intended.<p>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.<p><pre><code> > - What happens if my ISP decides to change my prefix ?
</code></pre>
And it is another problem: tooling. There is no standard way to reconfigure router with dynamic prefix(es). Yes, it is possible to write scripts for it, but it will be fragile. No Linux distribution or FreeBSD is ready to have dynamically allocated prefixes. It is not a real problem with IPv4 because real life practice to dynamically allocate one address and then configuration changes are trivial, and if you are delegated /24, it is typically static delegation.
> <i>- It's hard to remember IPv6 addresses. The prospect of reconfiguring all my router and firewall rules looks rather painful.</i><p>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!<p>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.<p>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.<p>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.<p>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.<p>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.
What do you mean by "give your devices proper names"?
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?<p>Important part is knowing there are special networks.
> <i>IPv6 has SO many special networks. Network. Public. Multicast. Link local.</i><p>IPv4 has those exact same ones: link-local (169.254/16), multicast (224/4), public, private (RFC 1918).<p>* <a href="https://en.wikipedia.org/wiki/Reserved_IP_addresses" rel="nofollow">https://en.wikipedia.org/wiki/Reserved_IP_addresses</a><p>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".
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.<p>It's time for IPv5, I know its been taken so may be IPv7.
>I don't use IPv6 because it solves a problem that I don't have<p>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.<p>I regularly see 1-2ms improvement to first hop outside my ISP network (10ms vs 12ms)<p>Remembering addresses is a solved problem with DNS.
> <i>- 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.</i><p>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 <i>with-in</i> an organization itself. (Internal split-horizon DNS here we come.)
exactly.<p>ipv6 just gives you two configurations to maintain, two firewalls to write rules for and cross-leaks that are hard to understand.<p>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.<p>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...
> Maybe I've been irreparably corrupted by being behind NAT for too long<p><i>Bangs head against desk</i><p>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.<p>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 <i>side effect</i> 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<p>Allow established, related<p>Allow outbound<p>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.<p>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.<p>That's the primary function of NAT, not a side effect.<p>> It doesn't filter incoming traffic.<p>Of course it does, it drops any incoming traffic for which it cannot find a corresponding connection. How is this not a filter?<p>I know that internally these two are vastly different. The reality is that NAT is used as protection for millions of home networks.
I guess technically you are right, in that NAT doesn't <i>prevent</i> connections, it <i>enables</i> 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.<p>On a publicly routed PC, I can call `listen` and an outside host can connect to me.<p>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.<p>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.<p>The only caveat is that <i>if</i> 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.<p>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.<p>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.<p>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.
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.
IPv6 also makes it unfeasible to scan the whole address space, unlike IPv4 which is regularly scanned.
Will be amazed if the parent comment stays at #1<p>I share some of the same thoughts<p>IPv6 should be optional, not mandatory<p>I disable IPv6 whenever and wherever I can<p>Gateway is always IPv4 only<p>No "smartphone" gets direct connection to the internet<p>IPv6 can be useful. For example, cjdns<p>I like having the option to use it, but it should not be mandatory
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.
> It's hard to remember IPv6 addresses.<p>Never understood why they decided to include letters instead of keeping it numeric.<p>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.<p>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 ...<p>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.<p>I have so much more issues configuring things with IPv6, vs just basic IPv4+NATS. Its simply, its easy...<p>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.<p>O and that :: range modifier is so fun. And the whole pre-fix and post-fix structure...<p>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.
> <i>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.</i><p>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:<p>* <a href="https://datatracker.ietf.org/doc/html/rfc1752#section-9" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc1752#section-9</a><p>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.<p>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.
The letters are hex digits, and make it more compact, regular. That’s the good part.<p>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.<p>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.<p>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.
> cue 500 replies of people telling you to eat your vegetables and wear the IPv6 hair shirt<p>Gee thanks, network experts, for solving a problem I don't have and making me pay for it!
> - 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.<p>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.)<p>> - 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.<p>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?)<p>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.)<p>> - 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.<p>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 <i>two</i> problems.)<p>> - It's hard to remember IPv6 addresses. The prospect of reconfiguring all my router and firewall rules looks rather painful.<p>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!)<p>> - What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.<p>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 <i>incidentally and irrevocably</i> 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.<p>(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!<p>(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.<p>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.<p>And that shit is simply weird.<p>As a response to the weirdness, we get the resultant and inevitable pushback that all weird shit deserves.))
> In short, so far, ignorance is bliss.<p>This isn't ignorance. This is an example of a little knowledge is a dangerous thing.<p>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 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.<p>Until somebody turned off the lights, that is. It is not much fun arguing with yourself in the dark.<p>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. <i>That is the point.</i> Clinging to IPv4 standard practices while you switch is just going to make you miserable.<p>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?<p>I finally made the switch to IPv6 last year, and I wouldn't go back.<p>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.<p>I get the feeling it's another 5-10 years before "not getting around to ipv6" will <i>actually</i> be a mistake in that space...
<i>>In 2026 it does not. IPv6 support is now more than adequate,</i><p>Youtuber apalrd periodically revisits the Ubiquiti Unifi devices to see if they finally support IPv6 and he concluded it still doesn't work correctly.<p>The linked comment from Ubiquiti acknowledges they're still trying to improve the situation : <a href="https://www.youtube.com/watch?v=KZpJvpm1Ris&lc=UgwXlto--2NbOrU8mdp4AaABAg" rel="nofollow">https://www.youtube.com/watch?v=KZpJvpm1Ris&lc=UgwXlto--2NbO...</a><p>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: <a href="https://support.reolink.com/hc/en-us/articles/900000645446-Do-Reolink-Cameras-and-NVRs-Support-IPv6/" rel="nofollow">https://support.reolink.com/hc/en-us/articles/900000645446-D...</a><p>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.<p>Obviously the gateway or router missing proper v6 support is an issue and a bit surprising ubt hasn't done a good job.<p>Even my mid range TP-Link Archer I had 10 years ago properly supported IPv6
What it sounds like to me is: don't use Ubiquiti.
I can't use vlans because my isp only gives me a /64.<p>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.<p>Any sort of hot spot / bridge faces the same problem.<p>Now RFC 9663 is supposed to help here but guess what? It's only like a year old and barely exists. Not 20 years.<p>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.
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.<p>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.<p>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.<p>*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 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.<p>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.
> In 2026 it does not.<p>There are no ISP providing ipv6 for home and mobile users here in hong kong
That is an unusual luxury, especially mobile providers still using IPv4.<p>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.
The hardware support is very likely already there.
I live in the USA and my ISP doesn't support ipv6
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.<p>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.<p>_Everybody_ would rush and make sure to switch everything to IPv6.
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.
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.<p>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.<p>The hard end of Python 2.7 support took care of all that in a hurry.
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.<p>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).<p>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.<p><a href="https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arcep_2025_Barometer_of_the_Transition_to_IPv6.pdf" rel="nofollow">https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arc...</a><p>Over here IPv6 JustWorks to the point of absolute boredom.
I was taught IPv6 in the mid 2000s too, in Italy.<p>But penetration there is just about 15% or so :/
Is it commonly used within small/medium/large businesses?
Tbh it’s is a huge PITA with little practical benefit. IPv6 is the Perl 6 of networking.<p>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.
Eh, I've been thus far unimpressed.<p>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.<p>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.<p>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.<p>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.<p>I get how IPv6 can be great. But a lot of the advantages are also overhead I don't want to deal with.<p>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.<p>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<p>Using a public domain for TLS certs for private networking is pretty standard in /r/selfhosted and /r/homelab at least.<p>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.<p>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.
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.<p>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.<p>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.<p>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.
> <i>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.</i><p>And I've been in corporate IT networks with mergers/acquisitions where both organizations involved had 10.0.0.0/24. Ever have NAT <i>inside</i> a company? Fun stuff. (Thrown in some internal-only split-horizon DNS too.)<p>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.<p>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.
> never at a random 192.168.x.x in a network I happen to be connected to.<p>That’s a pretty good benefit, I hadn’t considered that!
What about the benefit of there being enough addresses?
That particular benefit has no value if you still need to support v4.<p>It's almost a self-inflicted tragedy of the commons or reverse network-effect.<p>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:<p><pre><code> 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.
</code></pre>
I have all 3 working, but #1 was significantly less setup and works the best.<p>Also being able to generate unique ULA subnets is super nice.
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).
> <i>Adopting IPv6 doesn't alleviate the pain of IPv4 exhaustion if you still need to support dual-stack.</i><p>Sure it does: the more server-side stuff has IPv6 the fewer IPv4 addresses you need.<p>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.<p>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.<p>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.
> <i>The widespread deployment of NAT and VPNs has counter acted the market forces that were assumed to make IPv6 appealing.</i><p>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.<p>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.
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.<p>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!
> <i>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!</i><p>Back in the the day RtCW had a server anyone could run and you could give out the address:<p>* <a href="https://en.wikipedia.org/wiki/Return_to_Castle_Wolfenstein" rel="nofollow">https://en.wikipedia.org/wiki/Return_to_Castle_Wolfenstein</a><p>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.<p>P2P can be awesome with the right peers.
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.<p>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).
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.
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 :)<p>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.<p>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,<p>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.<p>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.
IPv4 addresses are still expensive. NAT is a value add for a lot of cloud platforms.<p>IPv6 has arguably done more to counteract market forces related to IPv4 address exhaustion.
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.<p>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.
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.
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.<p>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.<p>They get better network management.
Enough addresses for what? Nobody needs or even wants all of their devices to have globally routable addresses.
> <i>Enough addresses for what? Nobody needs or even wants all of their devices to have globally routable addresses.</i><p>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 <i>kinda useful</i> 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.<p>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.
This is so right.<p>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.
Did you have to do anything special to get the t shirt? I got the sage cert ages ago and they never sent my shirt...
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.
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.<p>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.<p>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.<p>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.<p>> 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.<p>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.<p>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?<p>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.<p>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?<p>> The presence of the IPv4 stack isn't what blocks the adoption of IPv6<p>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.<p>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?
ipv6 would have been a breaking change anyway, just take the opportunity to push through any changes that they want to make
I got taught IPv6 in 1995. At that time they said it was super important because it would replace IPv4 within a year lolololol
You have it backwards, education always lags industry adoption. (*Assuming it's a software engineering-focused curriculum.)<p>Programs will teach Docker only years after it is adopted.<p>Same with AWS, JavaScript, etc.<p>If it’s not adopted by industry, it won’t be taught about in schools.
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.<p>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...<p>I am not doubting you, but I feel this story is too hard to believe without adding further nuances...<p>MIT 6.829 teaches IPv6 since 2002:
<a href="https://ocw.mit.edu/courses/6-829-computer-networks-fall-2002/" rel="nofollow">https://ocw.mit.edu/courses/6-829-computer-networks-fall-200...</a><p>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).<p>Then there is usually a chapter on IPv6 that just briefly covers the differences.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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 :)
IPv4 link local addressing is awesome for direct PC to PC connectivity with no hassle
Well you will be happy to hear that ipv6 has the same thing with the FFfe::/10 network just like 169.254.0.0/16 apipa range
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.<p><a href="https://en.wikipedia.org/wiki/Link-local_address#IPv6" rel="nofollow">https://en.wikipedia.org/wiki/Link-local_address#IPv6</a>
Ipv6 was a protocol engineered in isolation from the social / political environment it had to be adopted in.<p>A successor to ipv4 wasnt a technical issue. duh, use longer addresses. The problem was social.<p>It's a miracle it was used at all<p>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.<p>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.<p>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.<p>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 <i>option</i> 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.<p>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>Exactly. IPv6 was developed in the ivory towers where it was still assumed that everyone wanted to be a full participant of the internet.</i><p>IPv6 was developed in the open on mailing lists that anyone could subscribe to:<p><pre><code> 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.
</code></pre>
* <a href="https://datatracker.ietf.org/doc/html/rfc1726" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc1726</a><p>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.”<p>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.<p>* <a href="https://www.goodreads.com/book/show/281818.Where_Wizards_Stay_Up_Late" rel="nofollow">https://www.goodreads.com/book/show/281818.Where_Wizards_Sta...</a><p>> <i>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.</i><p>Disagree, especially with the hoops that users and developers have to jump through to deal with (CG-)NAT:<p>> <i>[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.</i><p>* <a href="https://blog.ipspace.net/2025/03/response-end-to-end-connectivity/#2585" rel="nofollow">https://blog.ipspace.net/2025/03/response-end-to-end-connect...</a>
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.
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.<p>The real reason is IT people hate ipv6. They <i>want</i> NAT. They <i>don't</i> 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.<p>Replace "IPv6" in that sentence with any practical knowledge or skill and it's probably true for my entire master's degree....
Helsinki CS masters had ipv6 20 years ago, but nobody listened at the lectures because all of our home LANs ran ipv4
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?<p>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.<p>Higher education is about creating a breadth of knowledge, not specific marketable skills. CompSci is a research field, not job training.<p>If your friend wanted to learn specific job skills a technical college would be the appropriate setting.<p>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.
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!<p>--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.<p>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.
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.<p>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.<p>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.<p>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.<p>(The flip side is having a network-level firewall is more important than ever.)<p>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?<p>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<p>Loopback, link local and network assigned. What's that problem? Your ipv4 hosts are can reach themselves through millions of addresses already.<p>> hostnames are replaced by auto assigned stuff from the ISP<p>Hostnames replaced? IPv6 doesn't do DNS...<p>> lots of random things don’t work.<p>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.<p>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.
> those bloated packets are death for many modern applications like VoIP.<p>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.
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.<p>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.<p>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.<p>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.<p>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" <a href="https://datatracker.ietf.org/doc/html/rfc6177" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc6177</a> (for over a decade...)
Point of fact it's giving 4 billion Internets worth of addresses to every local subnet.<p>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.
"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.<p>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.<p>But when designers bring things like that up, you get <i>“it’s really not that complicated,”</i> or <i>“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,”</i> 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.<p>In particular, just off the top of my head...<p>- T-Mobile US doesn't even assign clients an IPv4 address anymore. Their entire network is IPv6 native.<p>- 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-<i>only</i>.
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.<p>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.<p>The NAT64 is really just there for the holdouts.
That's a bit like saying AC electricity was just a fancy way of delivering what customers really wanted, DC energy.<p>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.
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.
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.<p>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.<p>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 ( <a href="https://datatracker.ietf.org/doc/rfc9762/" rel="nofollow">https://datatracker.ietf.org/doc/rfc9762/</a> )!<p>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.
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?<p>Isn’t it what all the cell phones networks use these days? And most ISP’s?<p>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.<p>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.
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:<p>- 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.<p>- Mainstream IoT protocols have a hard dependency on IPv6 (eg Matter/Thread). Not to mention plenty of 5g deployments.<p>- Many modern networks quietly use IPv6 internally. I mean routing is simpler without NAT.<p>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
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.
<a href="https://www.google.com/intl/en/ipv6/statistics.html" rel="nofollow">https://www.google.com/intl/en/ipv6/statistics.html</a>
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.<p>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: <a href="https://radar.cloudflare.com/explorer?dataSet=http&groupBy=ip_version&filters=deviceType%253DDesktop%252CbotClass%253DLikely_Human&dt=52w&loc=US" rel="nofollow">https://radar.cloudflare.com/explorer?dataSet=http&groupBy=i...</a><p>afaik every single major US fixed line ISP is rolling out ipv6.
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.
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.<p>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 <i>use</i> still hasnt even reached 50%.<p>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.<p>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.
According to APNIC labs, IPv6 adoption in India is ~79% and in China it is ~53%.<p>Those are the only two countries that could plausibly have billions of mobile devices and they appear to have reached 50%.<p>India: <a href="https://stats.labs.apnic.net/ipv6/CN?c=IN&x=1&v=1&p=1&r=1&w=30&p=0" rel="nofollow">https://stats.labs.apnic.net/ipv6/CN?c=IN&x=1&v=1&p=1&r=1&w=...</a><p>China: <a href="https://stats.labs.apnic.net/ipv6/CN?c=CN&x=1&v=1&p=1&r=1&w=30&p=0" rel="nofollow">https://stats.labs.apnic.net/ipv6/CN?c=CN&x=1&v=1&p=1&r=1&w=...</a>
Looks like it’s right at 50% and rapidly increasing.<p>[<a href="https://www.google.com/intl/en/ipv6/statistics.html" rel="nofollow">https://www.google.com/intl/en/ipv6/statistics.html</a>]<p>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%.
Devices maybe, software won't :-\ (We're going to see ever-diminishing pockets of IPv4 around for a loooong time, much like we still see pockets of Cobol.)
The trend on that graph is slowing, and when we reach criticl mass on the number of mobile devices the graph will be flat.<p>There is no chance we will be at 95% usage in 5 years or so.<p>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.<p>As it is, that graph is showing how adoption is slowing and has been for the last 10 years.<p>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.<p>...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.<p>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.<p>Slow down perhaps, but it has to slow down at some point or it'll go above 100%.
I don't think they are arguing for a decrease. I took flatline and peter out to mean stabilize.
What is the source of the seasonality in that graph? Spikes up a little each summer.
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.<p>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.<p>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.<p>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<p>"And what do you base this belief on?<p>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]<p>0: <a href="https://news.ycombinator.com/item?id=37120422">https://news.ycombinator.com/item?id=37120422</a>
> Fact is you'd run into exactly the same problems as with IPv6.<p>If you treat IPv4 addresses as a routable prefix (same as today), then the internet core routers don't change at all.<p>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.<p>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.
> <i>Only the edge equipment would need to be IPv4+ aware.</i><p>"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.<p>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?<p>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.
And in 30 years, all of that has basically already happened and afoption is still absymal.
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.<p>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.<p>Congratulations, you’ve re-invented CGNAT, with none of the benefits, and the additional hassle of it being an entirely new protocol!<p>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.<p>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.<p>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.<p>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.<p>And it would be an absolute nightmare to maintain. CGNAT + a quasi backwards-compatible protocol where the backwards-compatability wouldn’t work in practice.<p>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.<p>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.<p>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.<p>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.
I agree with that belief, and I've been saying it for over 20 years.<p>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.<p>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.<p>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.<p>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.
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 <i>good</i> - 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.<p>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.<p>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.
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.
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.
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.
So well said! Those are great comparisons.
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.
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.<p>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.<p>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 <i>buyers</i> 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.<p>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 <i>of course</i> 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.<p>[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>I wouldn't say "failure". There are many, many IPv6 client devices out there, mostly on mobile networks.</i><p>Honestly it's a huge success due to this fact alone.<p>IPv6 is failure only if you measure success by <i>replacing</i> 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.<p>IPv6 is a backbone of the modern Internet for <i>clients</i>, even if your <i>servers</i> 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. <a href="https://datatracker.ietf.org/doc/html/rfc8200#page-4" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc8200#page-4</a>
Yep, just call it IPv8 and make it double the length of IPv4.<p>Ultimately, an address system that replaces “1.1.1.1” with “JEDBSO:7372B6D6A:727:8:72829:762927” or whatever just isn’t viable.<p>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.
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.<p>I can tell you what is what simply from the Ipv4 address, but when its IPv6, my dyslexia is going to kick my behind.<p>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.<p>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 <i>lol</i>...<p>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.
Do you live under a rock? The memorability of ipv4 was one of the major issues brought up from the very beginning.
I can keep a v4 in my head, briefly. v6 not so much. Or shout one across a room to someone.<p>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.
AWS supports IPv6 on a number their services now: <a href="https://aws.amazon.com/vpc/ipv6/" rel="nofollow">https://aws.amazon.com/vpc/ipv6/</a>
For example there are options to use their hosted memcache/redis service IPv6-only: <a href="https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/network-type.html" rel="nofollow">https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/netw...</a><p>Shocking it took them so long but, hey, it's there now.
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.<p>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.<p>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.<p>You don’t even need to use a subnet calculator for v6, because you can literally do that in your head.<p>Network of 2a06:a003:1234:5678::555a:bcd7/64? Easy - the first 4 octets.<p>Network of 10.254.158.58/27? Your cheapest shotgun and one shell please.
"Hey Bob, what network is that machine on?"<p>"Easy,2a06:a003:1234:5678"<p>"2806:8003: and then what, I forgot the rest?"
If you want you can check free app to calculate it -> <a href="https://alertsleep.com/tools/subnet-calculator" rel="nofollow">https://alertsleep.com/tools/subnet-calculator</a>
remembering 10.254.158.58. Easy - the first 4 octets.<p>remembering 2a06:a003:1234:5678::555a:bcd7/64. Your cheapest shotgun and one shell please.
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.<p>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.<p>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.<p>We're past that for a decade, but various services have not caught up yet <a href="https://datatracker.ietf.org/doc/html/rfc6177" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc6177</a><p><pre><code> 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.</code></pre>
> I DO think using 64 bits for hosts was stupid but oh well.<p>Hey man, if I want to assign an address for each individual transistor in my system, that's my business.
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.<p>I'm not sure what that feature would be though.
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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>But, no. Great missed chance.<p>Well, we still could do this with IPv6, but it would be a lot of heavy lifting now.<p>EDIT: Ah, I see draft-savola-multi6-asn-pi existed.<p>EDIT: Ah, see also LISP [<a href="https://www.rfc-editor.org/rfc/rfc6830" rel="nofollow">https://www.rfc-editor.org/rfc/rfc6830</a>]. But LISP is essentially dead.
> <i>a cellular backup to your residential DSL connection</i><p>Hmm, what's the problem? I suppose your home devices should <i>never</i> 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.<p>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?<p>Yes, an interface can hsve two separate IPv6 addresses, but that doesn't make it easy.<p>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.<p>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::<p>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.<p>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.<p>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.<p>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.<p>> I would experiment with advertising two default routes, one with a significantly higher metric than the other.<p>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?<p>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.<p>So every time I got a new prefix, machines would lose connectivity, usually until I rebooted them.<p>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.<p>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.<p>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.<p>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.<p>> 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.<p>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.
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<p>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.<p>> 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.<p>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.
> <i>each and every device ... updates its DNS records.</i><p>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.<p>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.<p>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.<p>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.<p>"Easy" is meant in that context. The people acting like the IPv4 version is easy.<p>So your second paragraph doesn't fit the situation at all.
"The shit about IPv4" was easy to learn and well documented and supported.<p>"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.<p>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.<p>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.<p>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.<p>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?"<p>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.<p>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.<p>The difficulty of setting IPv6 up at your house vs. the needs of a multi-homed, geographically diverse enterprise couldn't be more dissimilar.<p>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.<p>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.<p>all of it ipv4 based. ipv6 maybe in distant future somewhere on the edge in case our clients will demand in.<p>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).<p>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.<p>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.<p>the only time we discussed it, it's when we were getting fedramp certification. because of this <a href="https://www.gsa.gov/directives-library/internet-protocol-version-6-ipv6-policy-1" rel="nofollow">https://www.gsa.gov/directives-library/internet-protocol-ver...</a>
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.<p>This is neither hard nor expensive.
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.<p>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.<p>Consider this:<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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<p>That’s before you go on to using PBR. I want to route traffic with different dscp via different routes.<p>Ultimately I want the rout g to be handled by the network, not by the client.<p>IPv4 and nat makes that a breeze.
> any decent firewall (including referee PFsense/OpnSense) support ACLs that follow IPv6 address changes<p>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.
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.
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.
Stripped of all the other baggage that came with it (e.g. SLAAC, IPsec, etc) IPv6 <i>is</i> 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.<p>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".<p>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.<p>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.<p>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.<p>[0] Let's say we add a 32-bit extension header onto IPv4
"Stripped of all the other baggage that came with it..."<p>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.
> The current problem with IPv6 adoption is that nobody has yet said "let's stop processing IPv4 traffic"<p>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.<p>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.<p>This is why mobile and consumer devices are leading the pack on IPv6 adoption.<p>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"…<p>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.)
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.<p>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.<p>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.<p>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.<p>The real problem is routing in these address spaces, and there have been a few projects like CJDNS which try to solve it.
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.<p>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.<p>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.<p>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.<p>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.
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.<p>Oh and btw, your address is now 9245593924 Oak St.
<i>> still hasn't taken over the world</i><p>Maybe not in the strict sense, but it kind of has.<p>In the enterprises I've worked in the past decade with IPv6 running, <i>at least</i> 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.<p>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?).
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 (<a href="https://www.rfc-editor.org/rfc/rfc9460" rel="nofollow">https://www.rfc-editor.org/rfc/rfc9460</a>) 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?<p>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.
IPv4s have been bought and sold for years<p><a href="https://auctions.ipv4.global/prior-sales" rel="nofollow">https://auctions.ipv4.global/prior-sales</a><p>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.<p>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.
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.
> Maybe not in the strict sense, but it kind of has.<p>I challenge you to find:<p>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.<p>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<p>What about those without IPv6 running?<p>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?<p>everything fit's nicely in the 10.0.0.0/8 range<p>in my many decades of enterprise infrastructure, no-one has ever mentioned IP6 either.<p>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.
> <i>everything fit's nicely in the 10.0.0.0/8 range</i><p>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<p>Except for when it doesn't.<p>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.
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.<p>I don't claim IPv6 isn't used anywhere, or even that it's not used a lot.
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<p>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.<p>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.<p>>In the enterprises I've worked in the past decade with IPv6 running, at least 75% of the Internet traffic is IPv6.<p>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: <a href="https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption" rel="nofollow">https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...</a>
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.<p>> Nobody cares about [that]. What matters is if my device has an IPv6 address assigned.<p>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.<p>Others are saying since their machine doesn’t show it it’s dead and no one cares.<p>Is there a term for this? A successful failure? A failed success?<p>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.<p>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?<p><a href="https://en.wikipedia.org/wiki/False_consensus_effect" rel="nofollow">https://en.wikipedia.org/wiki/False_consensus_effect</a>
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.<p>Here’s a prediction. Linux on the desktop will have >50% penetration well before IPv6 does.
IPv6 already hit 50% <a href="https://www.google.com/intl/en/ipv6/statistics.html" rel="nofollow">https://www.google.com/intl/en/ipv6/statistics.html</a>
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.<p>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).<p>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.<p>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.<p>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<p>As the sibling comment pointed out: it's very close to 50% adoption, you just don't see it <a href="https://www.google.com/intl/en/ipv6/statistics.html" rel="nofollow">https://www.google.com/intl/en/ipv6/statistics.html</a>
> 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<p>Could you be specific about what the misconceptions are?
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.<p>And yet there is still only "you doing it wrong, and I won't tell you how to do it right"
> less obvious benefits<p>if they are so unobvious that nobody knows about them, perhaps they are not benefits at all, but fringe minutiae?
> such a yawning chasm of gaps in knowledge ... in a forum whose users are generally known to be more technically savvy<p>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.<p>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.<p>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.<p>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.<p>That we could use IPv6 on galactic empires is an added bonus, but not really the reason.
> 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.<p>128 bit is like the least of adoption issues and basically meaningless difference vs 64.<p>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.
> to achieve "globally unique" host part that isn't really all that useful characteristic of the protocol.<p>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.<p>Need I remind you that option to push DNS server (which is pretty fucking important option!) was added to IPv6 standard only in 2007 ?<p>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)<p>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
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.
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.<p>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.<p>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.<p>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.<p>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.
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.<p>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.<p>Keep in mind that SLAAC isn't. Modern IPv6 stacks use privacy addresses, so they still need to run the address collision detection.<p>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.
> For many, the decision of which protocol to use was easy because IPv6 didn't add features that represented major improvements.<p>This is the obvious and only key to this puzzle.<p>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 <i>create incentives</i> 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.<p>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 <i>supposed</i> to switch, and they've <i>failed</i> to do so. Which is, of course, absurd. People don't owe us compliance.<p>Do not expect to be able to successfully shift behaviour unless you give people incentives - reasons <i>they</i> would want to switch, not just reasons <i>you</i> want them to switch.
Everything I know about IPv6 comes from this one blog post: <a href="https://apenwarr.ca/log/20170810" rel="nofollow">https://apenwarr.ca/log/20170810</a>. It’s from 2017, when IPv6 adoption was 17% according to <a href="https://www.google.com/intl/en/ipv6/statistics.html;" rel="nofollow">https://www.google.com/intl/en/ipv6/statistics.html;</a> 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.<p>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.
> Getting legacy network operators like cable providers to supply IPv6 has been hell.<p>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
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.
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.<p>I had mentioned some of that in my post: <a href="https://ssg.dev/ipv6-for-the-remotely-interested-af214dd06aa7/" rel="nofollow">https://ssg.dev/ipv6-for-the-remotely-interested-af214dd06aa...</a>
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.<p>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.<p>The reason it's not winning in the other places is because Network engineers hate IP version 6 as a rule .<p>It makes sense that it's won on mobile. In that scenario, NATs are stupid and lots of addresses are needed.<p>In the data center, fewer addresses are needed and NATs are vital for security.
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<p>The two worst uses of the internet.
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.<p>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.<p>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 <i>need</i> 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.)<p>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 <i>not</i> crazy to think of centuries-long timeframes for things.<p>[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.)
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?<p>I find it useful, mine does change periodically, but I just have a script that Updates DNS when it changes:<p><pre><code> 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
</code></pre>
Sure some services might notice for a bit, but it's plenty good for me.
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.
I technically have a dynamic IPv4 address from my ISP. I've had the same for five years now, across multiple power outages.<p>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.<p>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.
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...
<a href="https://www.spectrum.net/support/internet/ipv6" rel="nofollow">https://www.spectrum.net/support/internet/ipv6</a><p><a href="https://www.spectrum.net/support/internet/ipv6-faq" rel="nofollow">https://www.spectrum.net/support/internet/ipv6-faq</a><p>> 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
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.
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.<p>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.<p>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?<p>The more practical thing to look for is that they aim to upgrade it based on need, instead of arbitrarily throttling the users.
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.
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?<p>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.<p>It should have been ipv4 with extra optional bits, so you could have the same rules and everything for both stacks.<p>I turn it off because it's a risk having one of either stacks malconfigured.<p>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.
for me, I don't need to even setup NAT64. My ISP provides it for me free.
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.<p>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.<p>Yes, I'm sure there are ways to fix this, but why have the problem in the first place?<p>Zigbee is entirely incompatible networking standard, and doesn't have this problem.
Another day, another Godwin's law of networking.<p>>It was doomed the moment you had to maintain two separate stacks<p>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)?<p>Suppose that you have an old computer that understands only 32 bit addresses -- good ol' IPv4. Let's name it 192.168.10.10.<p>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!<p>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.<p>It then sends back the reply to... you guessed it, 172.12.10.98. Not 172.12.10.98.12.4.24.31.<p>Yeah,172.12.10.98.12.4.24.31 will never get its reply back.<p>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.
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.<p>This is stuff that could be implemented in any ipv4 stack in some days of work.<p>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:<p>>This is stuff that could be implemented in any ipv4 stack in some days of work.<p>The sysadmins across the world, who had to deal with decades-old, never-updated devices facepalmed in unison.<p>At least the other comment agreed that "IPv4+" hosts will never be able to talk to IPv4 hosts.<p>>IPv6 is overengineered, thats the reason why it's not adopted after 30 years.<p>It is <i>already</i> 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!<p>> "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."<p>Apparently it turns out IPv6 wasn't for me any way!
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.)<p>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.<p><a href="https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows" rel="nofollow">https://learn.microsoft.com/en-us/troubleshoot/windows-serve...</a>
> I agree it's not a failure, but after 3 decades it's still frustratingly annoying to use at times.<p>Anyone sane would call a standard that remains annoying to use after 30 years a failure.
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.<p>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?<p>"IPv6 ... still hasn't taken over the world [after thirty years of deployment]." is a very different statement than "IPv6 has failed.".<p>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.<p>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.<p>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.".<p>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.<p>By the way...<p>>In the future, SOHO/home LANs can run servers on IPv6<p>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.<p>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 <i>three</i> parts. ;)
The majority of traffic might be IPv6, but the majority of people using and understanding IPv6 is not.
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.<p>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 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).<p>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.<p>With IPv6, they could just ban my entire family and any guests that might have connected to my WiFi, forever.<p>I like the limitations of IPv4, thank you.
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).<p>(This is of course an incomplete and poorly thought out proposal, you don't need to dogpile me about that.)
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.<p>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.<p>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.<p>None of these changes were backwards compatible, and all of them were meant for the general public. They took a while. They were successful.
Anyone who bought DVD player immediately had the benefits of better quality. The same applies to all other examples.<p>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 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.
You'd think it would be long enough for people to realize that v6 <i>is</i> 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.<p>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.
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.<p>That doesn't mean that the limits of the old design won't hit anyway and force a switch off it.
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 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'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.<p>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 <a href="https://www.rfc-editor.org/rfc/rfc6275" rel="nofollow">https://www.rfc-editor.org/rfc/rfc6275</a>
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).<p>Not that it matters, really. As far as I'm aware, there were never any substantial deployments of this protocol.
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.<p>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...<p>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.
<a href="https://www.google.com/intl/en/ipv6/statistics.html" rel="nofollow">https://www.google.com/intl/en/ipv6/statistics.html</a> it's still going up (we are in some sort of cyclic downturn right now that I don't understand).<p>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.<p>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.
Contrary to some other comments: no, IPV6 hasn't taken over the world at all.<p>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.<p>In that context, IPv6, is SADLY (please note that I have NOTHING against IPv6), a limitation, even a nightmare to use.<p>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<p>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.<p>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.<p>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<p>Not all.<p>I operate site with IPv6 only origins behind cloudflare.<p>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.<p>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.<p>> Nobody complained: those who did not have working IPv6 probably blamed it on cloudflare.<p>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?<p>50% is a very substantial retention rate.
This has nothing to do with anything inherent to IPv6 and everything to do with the failure of organizations to timely implement it.
> In almost ALL context IPv6 is seen as optional, additional, additional configuration and is NEVER the default.<p>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 <i>disable</i> IPv6.<p>> Some programs do not handle IPv6 at all. Game servers for instance, do not support it...<p>Depends on the game server. Many I run absolutely do.<p>Your complaints smell like you tried to run an IPv6-only client network, which <i>would</i> 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.<p>On the other hand, running IPv6-only <i>infrastructure</i> networks can make a ton of sense. One very large such operator is Comcast, a US ISP.
Most 4G networks are actually IPv6-<i>only</i>, with IPv4 traffic being routed through inefficient tunnel systems. This is why Apple and Google require all mobile apps to use IPv6.
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?<p>I would love for IPv6 to actually take off but somehow it feels like we are still a decade away from ubiquitous adoption.
so it turned into a good ol' legacy problems<p>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
The problem with IPv6 jokes is that very few people are making them.
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.
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...
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.<p>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.<p>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.
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.
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.<p>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.
Yesterday I was <i>required</i> 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.<p>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.<p>Some routers can work as _relays_ between the Thread network and WiFi, but this is entirely optional.
this is one of reasons why i stick to z-wave. totally self contained.
DJB understood the problem decades ago. <a href="https://cr.yp.to/djbdns/ipv6mess.html" rel="nofollow">https://cr.yp.to/djbdns/ipv6mess.html</a>
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?
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: <a href="https://news.ycombinator.com/item?id=46471898">https://news.ycombinator.com/item?id=46471898</a><p>But here's a more thought-out design:<p>- register a well-known IPv6 prefix with 20 bits reserved for AS number<p>- 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)<p>- have DNS servers return AAAA RRs with the AS number filled in<p>- 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)<p>- 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<p>- update core routers to route these prefixes based on the AS number in the address<p>- 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<p>- update internal routers to use only the $customer_prefix and the $end_entity for routing for this $well_known_prefix<p>- 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)<p>- 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)<p>- 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<p>I think something like this could be deployed with relatively little effort.
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<p>Bonus: the relatively recent RFC 9686 that I hope will get some good traction: <a href="https://datatracker.ietf.org/doc/rfc9686/" rel="nofollow">https://datatracker.ietf.org/doc/rfc9686/</a>
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.<p>Apparently it's "not how it's done" and we're "doing it wrong".<p>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<p>Not if you're on Android. <a href="https://issuetracker.google.com/issues/36949085" rel="nofollow">https://issuetracker.google.com/issues/36949085</a>
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.<p>Windows in powershell:<p><pre><code> SetNetIPv6Protocol -UseTemporaryAddresses Disabled
SetNetIPv6Protocol -RandomizeIdentifiers Disabled
</code></pre>
Linux:<p><pre><code> sysctl net.ipv6.conf.all.use_tempaddr=0
</code></pre>
or in NetworkManager config file:<p><pre><code> ip6-privacy=0
</code></pre>
OpenBSD:<p><pre><code> ifconfig em0 inet6 -temporary</code></pre>
Yeah. ULA and nat66 would work nicely. Except you would get murdered for asking about nat66.
"Build yourself an IPAM solution, at great operational cost and complexity."
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.<p>[1] - <a href="https://nlnetlabs.nl/downloads/publications/ipv6/v6rootglue.pdf" rel="nofollow">https://nlnetlabs.nl/downloads/publications/ipv6/v6rootglue....</a>
Every day I thank NAT that I don't have to memorize IPv6 addresses. I can barely manage my IPv4 numbers.
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.
NAT is the reason for IPV6 not taking over.<p>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.<p>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.<p>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.
> any consumer/home network will be exposed to the internet if they're using SOHO equipment via IPv6 and won't be via IPv4.<p>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.<p>(Also, why the fsck would I want to have an ISP that does that?)
It keeps getting repeated precisely because it <i>isn't</i> gaslighting. And yet we still see people claiming that NAT is security.<p>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.<p>And they won't be exposed on v6, because those exact same firewalls work their magic on v6 too.<p>NAT doesn't provide and isn't needed for security. Its main security contribution is to confuse people about how secure their network is.
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.<p>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.
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<p>What makes them a pain to block? Angry users or some central database that lists these addresses as "do not block"?
Since cgnat means NATing a huge number of legimate device to a single ip. So angry users is the answer. Also note mobile users are usually the cgnat.
> What makes them a pain to block?<p>Not wanting to cut off access to your users from, for example, every AT&T device (and their MVNOs).
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.
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.<p>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.<p>[1] <a href="https://tailscale.com/blog/how-nat-traversal-works" rel="nofollow">https://tailscale.com/blog/how-nat-traversal-works</a>
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”<p>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.<p>"edgy"? Come on.<p>And if they used decimal I bet the complaints they <i>didn't</i> use hex would be just as loud and just as certain, since an IP address in dotted decimal is 50% longer than in hex.<p>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.<p>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.
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.<p>(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)
IPv6 is the poster child for the second system effect (or solution) [1].<p>IPv4 really only had 3 problems that anybody cared about:<p>1. Address space size;<p>2. Roaming; and<p>3. Reliable connectionless delivery; and<p>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.<p>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).<p>Interestingly, some of the larger companies have networks simply too large for the 10.0.0.0/8 address space.<p>By "roaming" I mean maintaining a consistent connection while moving between networks.<p>(4) has kinda fallen on QUIC (now HTTP3) but this should really be core TCP/IP Layer 3.<p>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.<p>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.<p>[1]: <a href="https://en.wikipedia.org/wiki/Second-system_effect" rel="nofollow">https://en.wikipedia.org/wiki/Second-system_effect</a><p>[2]: <a href="https://github.com/google/bbr" rel="nofollow">https://github.com/google/bbr</a><p>[2]: <a href="https://community.cisco.com/t5/networking-knowledge-base/understanding-ipv6-eui-64-bit-address/ta-p/3116953" rel="nofollow">https://community.cisco.com/t5/networking-knowledge-base/und...</a>
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.
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.<p>I'm reminded of way back in the day when they wanted charge <i>per user</i> or <i>per device</i> in households.
IPv6 seems to be a great fit for 1) mobile devices, 2) massive data centers and 3) literally nothing else.<p>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.<p>Instead, they provision IPv6-enabled load balancers and pass traffic back to load bearing servers using ipv4 instead.<p>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.<p>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.<p>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.<p>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.
Can't we just leapfrog to IPv7? or 8 for that matter?
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'd love to have ipv6. The idea every device in my network can have its own unique worldwide address is awesome.<p>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.<p>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.
true. I am CSE student in third year, and just started learning about networking.<p>We just take the sheer amount of engineering that went to designing network protocols for granted.
IPv6 is the protocol of the future. And will be.
I don't know about anyone else's reasoning but personally IPV4 works just fine for 100% of my use cases.<p>I don't have anything against it per-say but I have no reason to use it either.
Solution looking for a problem is why. No value is why.<p>Breaks NAT privacy and the extensions do not do enough.<p>Top down pushed solution NOBODY WANTS.
Unfortunately, TIL that Linux doesn't use DNSv6 if DNSv4 is available ;(<p><a href="https://github.com/systemd/systemd/issues/16322" rel="nofollow">https://github.com/systemd/systemd/issues/16322</a>
IPv6-only is the future for mobile phones, and mobile devices are the future of the internet.<p>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.
IMHO:<p>And it will not be, as long as<p>* (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.<p>because only then, we can
a) migrate
b) rebuild the same structures.<p>because people will never let go of something.
> as long as [...] (S|D)NAT are not first class citizen in IPV6 Standards and Implementation<p>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.<p>> there's no mapping of the IPv4 Adresspace into the v6 space<p>Uh, what? What do you think ::ffff:1.2.3.4 is?<p><a href="https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5.2" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5....</a><p><a href="https://datatracker.ietf.org/doc/html/rfc4038#section-4.2" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc4038#section-4.2</a>
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.<p>I'd say this is actually elegant, compared to NPTv6 which is a kludge and will break things (and isn't well-supported anyway).
huh, i was NOT aware of that. NICE!<p>now applications (including DNS/NAT) have to support it<p>i also forgot something (but not against your comment):<p>* there needs to be guidelines how applications should differentiate between used ipadresses (link, site, global and so on)
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.
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:<p>[1] - <a href="https://www.google.com/intl/en/ipv6/statistics.html" rel="nofollow">https://www.google.com/intl/en/ipv6/statistics.html</a>
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.
Matter iot devices are IPv6 only.<p>Apple TV, Amazon Echo/eero, Google Nest are all Thread/Matter hub.<p>Ikea just started to selling cheap Thread devices. It will soon be mainstream to have IPv6 devices in your home network.
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.
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
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`.
My work has IPv6, and my home has IPv6.<p>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.
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.
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.
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.
IPv6 might not have taken over the world, but it sure seems to be getting forced on the world.<p>Even more than IPv4, not knowing enough about IPv6 can introduce a lot of unintended issue, consequence and even security gaps in your assumptions.<p>Maybe there was an IPv7 or 8 that will be more palatable.
Well, my ISP dosent support ipv6, and i get a non shared public ipv4, so no ipv6 here.
> IPv6 was not backward-compatible with IPv4<p>I don't think there is any way it could have been.
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.
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. <a href="https://www.potaroo.net/ispcol/2024-10/ipv6-transition.html" rel="nofollow">https://www.potaroo.net/ispcol/2024-10/ipv6-transition.html</a><p>I've been using IPv6 via Starlink for months now and it was a big ho-hum when I deployed it. It just works.
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.<p>::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?<p><a href="https://www.nat64.net" rel="nofollow">https://www.nat64.net</a>
The article itself is fairly short & fluffy.<p>Vs. real meat is in the comments on the Register's site.
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's not a failure of IP6 but a failure of society.<p>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.
All those discussions are making it harder than it need to be.<p>I have ONE static external IPv4 for my network.<p>I can handle everything I want with it. And block everything I dont want my network to be.<p>So I just disable IPv6 on router (Mikrotik).<p>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.
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
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.<p>> Outbound IP addresses<p>> Fly Machines have IPv6 addresses from which they make requests to the wider internet without going through the Fly Proxy.<p><a href="https://fly.io/docs/networking/services/" rel="nofollow">https://fly.io/docs/networking/services/</a>
I really don't get why people hate on IPv6.<p>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 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?<p>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.<p>Computers default to 64 bit integers, I don't see why this couldn't be done on the network.
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.<p>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.
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.
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.<p>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.)<p>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.<p>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.<p>#OldManYellsAtClouds
In my country, the last big _mobile_ internet provider finished its move to IPv6.<p>Land lines internet have been IPv6 for more than a decade.<p>While developping custom IPv6 internet software I am not blocked by NAT anymore, real p2p fiesta, everything works as intended.<p>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.
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.<p>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?<p>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.<p>I think IPv6 is better <i>in theory</i>, and I look forward to the day that it is <i>in practice</i>. 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.<p>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?
> "IPv6 wasn't about turning IPv4 off, but about ensuring the internet could continue to grow without breaking,"<p>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.
reminder that in 2026 Microsoft GitHub(TM) still doesn't support ipv6<p>but if you need maximum AI slop, that's everywhere
Evolution is the survival of good enough. IPv4 is good enough.<p>> but IPv6 is better<p>It doesn't solve any life-changing problem.
Goes hand in hand with dnssec.
You and me both, IPv6.
Only 30? It feels like it's been ages!
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.<p>IPv4 "works" and ISPs are incredibly resistant to changing things that "work".<p>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.<p>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.
Second system effect.
Aren't all the smartphones IPV6?
What's up with those comments? Am I still on HackerNews or did I visit Reddit with some HackerNews theme applied?<p>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.<p>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.
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.
Good enough beats better.
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.
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 .<p>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.<p>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.
Is IPv6 going to see it's epitaph instead of it's takeover soon?
should be just about done by 2050 at that rate
i was using ipv6 at home for years but then one day at&t broke it and never fixed it
Google's ipv6 stats[0] are stuck in Dec 17.<p>However, extrapolation suggests the 50% mark might have finally been crossed around year end.<p>0. <a href="https://www.google.com/intl/en/ipv6/statistics.html" rel="nofollow">https://www.google.com/intl/en/ipv6/statistics.html</a>
I just want things to work.
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.
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.<p><a href="https://en.wikipedia.org/wiki/IPv4#Header" rel="nofollow">https://en.wikipedia.org/wiki/IPv4#Header</a>
<a href="https://en.wikipedia.org/wiki/Internet_Protocol_Options" rel="nofollow">https://en.wikipedia.org/wiki/Internet_Protocol_Options</a>
<a href="https://en.wikipedia.org/wiki/IPv4#/media/File:IPv4_Packet-en.svg" rel="nofollow">https://en.wikipedia.org/wiki/IPv4#/media/File:IPv4_Packet-e...</a>
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.<p>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.<p>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.<p>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.<p>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).<p>That still requires that if you have used BSD Sockets <i>before getaddrinfo was added</i> (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.<p>So the very thing you're advocating for <i>exists</i>
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".<p>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.<p>But nope, not one reason.<p>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
cuz it sucks
ipv6's::syntax::is::weird
Except it has
For Google connecting clients it's only half the internet.<p>Half. The. Internet.<p>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<p>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.<p>For mobile devices, moving 50% of traffic over to IPv6 means buying half as many CGNAT/v6-to-v4 boxes (of various kinds).<p>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 <i>only</i> 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.<p>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.<p>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.<p>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.<p>It doesn't have to be 100% before we get ROI.<p>> it is not a success.<p>About half of even <i>public</i> traffic on the most complex and distributed system ever built is IPv6.<p>It's going slower than I'd like, but it's definitely paying off.<p>There are still ATM and X.25 networks out there, so is IPv4 a failure? (admittedly, a bit hyperbolic)<p>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<p>Well I addressed that too, so…<p>> private networking<p>To some extent this is a distinction without a difference. Again, as I said…<p>> we would probably be having this very discussion on an IPv6 enabled site<p><pre><code> $ host news.ycombinator.com
news.ycombinator.com has address 209.216.230.207
news.ycombinator.com has IPv6 address 2606:7100:1:67::26
</code></pre>
When IPv4 is disrupted for me, I only notice because github.com goes away.<p>> v6 [is] a second class citizen<p>It is. Except for endpoints (again) as I mentioned…<p>> the cost difference between a v4 address<p>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.<p>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.<p>To say that "the cost should be equal" for IPv6 to not be a partial/in progress success misses the entire economics of addresses.<p>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.<p>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.
Comcast/Xfinity implemented v6 on their residential cable network 14 years ago ( <a href="https://corporate.comcast.com/comcast-voices/ipv6-deployment-technology" rel="nofollow">https://corporate.comcast.com/comcast-voices/ipv6-deployment...</a>)<p>Most other large eyeball networks have as well.
[flagged]
It’s ok to understand something and disagree with it. It’s another to proudly wear ignorance on one’s sleeve. That’s never a good look.<p>There’s no way in which IPv6 is less private than IPv4. An ISP issues your house an IPv4 address and an IPv6 /48 network. Both of those can be subpoenaed equally. The privacy extensions work as advertised.<p>And in reality land, the big companies are the ones pushing for the upgrade because they’re the ones hardest hit by IPv4’s inherent limitations and increasing costs. Same rando in Tampa isn’t leading the charge because it doesn’t affect them much either way.
> There’s no way in which IPv6 is less private than IPv4<p>With IPv4 behind CGNAT you share an address with hundreds of other users. This won't protect you against a targeted subpoena, but tracking companies typically don't have this kind of power, so they have to resort to other fingerprinting options.<p>On the other hand, an IPv6 address is effectively a unique, and somewhat persistent, tracking ID, 48/56/64-bit long (ISP dependent), concatenated with some random garbage. And of course every advertiser, every tracking company and their dog know which part is random garbage; you are not going to fool anyone by rotating it with privacy extensions.
CGNAT is nowhere near the common case yet. And frankly, I’m horrified that anyone’s describing it as a <i>good</i> thing. CGNAT is the devil, even if it accidentally has one not-terrible feature, and especially when ISPs realize that they can sell those NAT logs to companies who still want to track end users.<p>For tracking purposes, an IPv6 address is 48 bits long. That’s what identifies a customer premise router, exactly like a IPv4 /32 identifies one. The remaining 80 random bits might as well be treated like longer source port numbers: they identify one particular connection but aren’t persistent and can’t map back to a particular device behind that router afterward.
>CGNAT is nowhere near the common case yet. And frankly, I’m horrified that anyone’s describing it as a good thing.<p>For some reason, "CGNAT == privacy" is a very common sentiment on Hacker News. Yeah, <i>Hacker</i> News. It's bewildering, and after my last comment [0] talking about it, I have kinda already given up trying to convince people that CGNAT is devilish and not at all a privacy protector.<p>[0]: <a href="https://news.ycombinator.com/item?id=40180058">https://news.ycombinator.com/item?id=40180058</a>
When I was on CGNAT, sure I shared an IP address with hundreds of others, but the specific ports I was assigned on that IP were deterministic, and you can be sure the advertising companies were taking advantage of that.
Google aren't subpoenaed<p>Perhaps this is the difference, some people are concerned with being anonymous from companies like google, amazon, etc. Some don't mind that, as long as they are anonymous from a government.<p>Your mention of subpoena suggests you don't care about google tracking you.
Google gets subpoenad all the fucking time. They have whole departments set up to handle the case load.<p>Some public evidence: <a href="https://www.alphabetworkersunion.org/press/google-lays-off-critical-workers-responsible-for-public-safety-initiatives-and-regulatory-compliance" rel="nofollow">https://www.alphabetworkersunion.org/press/google-lays-off-c...</a>
Sorry I meant to say google aren't subpoenaing<p>The people I want to protect my privacy from are google, facebook, amazon, they can't subpoena my IP, they can track me just fine though.
I was directly replying to someone saying they could subpoena the temporal owner of an IPv6 address, as though that were somehow different than IPv4.<p>The tracking is a moot point. You can be tracked using the same technologies whether you connect though v4 or v6, and neither stack has the advantage there.
Unless my understanding of how IPv6 is flawed, I don’t think your assertion is true in practice. One of the big benefits to IPv6 is that addresses are plentiful and fairly disposable. Getting a /48 block and configuring a router to assign from the block is pretty straightforward.<p>I’m aka unsure if IPv4 really gets you the privacy advantages you think it does. Your IP address is a data point, but the contents of your TCP/HTTP traffic, your browser JS runtime, and your ISP are typically the more reliable ways to identify you individually.
> Incoming HN downvotes because I'm not using the coolest latest technology.<p>The downvotes are because you’re needlessly combative, preemptively complaining about downvotes.
You can nat all your ipv6 traffic behind a single IP if you want. Or a new IP for every connection.<p>Realistically though there's enough fingerprinting in browsers to track you regardless of your public IP and whether it's shared between every device in the house or if you dole out a routable ipv4 to every device.<p>CG-NAT gives more privacy benefits as you have more devices behind the same IP, but the other means of tracking still tend to work.<p>For me I just don't see the appeal of supporting both ipv4 and ipv6. It means a larger attack surface. Every year or two I move onto my ipv6 vlan and last a few hours before something doesn't work. I still don't see any benefit to me, the user.
> Realistically though there's enough fingerprinting in browsers to track you regardless of your public IP and whether it's shared between every device in the house or if you dole out a routable ipv4 to every device.<p>Yes, browser fingerprinting is a big issue, but it can be mitigated. The first thing everyone should do is to use a network-wide DNS blacklist against all known trackers (e.g. <a href="https://github.com/hagezi/dns-blocklists" rel="nofollow">https://github.com/hagezi/dns-blocklists</a>) and run uBlock Origin in the browser.<p>You can go further and restrict third party scripts in uBlock, or even all scripts. This will break at lot of websites, but it is a surefire way to prevent fingerprinting.<p>Then of course there is Tor.
IPv6 itself seems to provide a larger attack surface based on IPv6-specific CVEs. I don’t know if it’s the added complexity or that it’s treated as a second class citizen by devs, but I still see a solid number of these coming across the CVE feed.<p>This one was particularly scary: <a href="https://malwaretech.com/2024/08/exploiting-CVE-2024-38063.html" rel="nofollow">https://malwaretech.com/2024/08/exploiting-CVE-2024-38063.ht...</a>
> Realistically though there's enough fingerprinting in browsers to track you regardless...<p>Yep. For the OP, IPv6 "Privacy" addresses do what he's looking for. You can change how long they're valid for on Linux, so you can churn through them very frequently if you wish.<p>> Every year or two I move onto my ipv6 vlan and last a few hours before something doesn't work.<p>Odd. I've been using IPv6 for like fifteen, twenty years now with no trouble at all. If you've been using a "single stack" IPv6-only network, well, there's your problem.<p>> For me I just don't see the appeal of supporting both ipv4 and ipv6. It means a larger attack surface.<p>The attack surface with IPv6 is exactly as large as if each of your LAN hosts had a globally-routable IPv4 address. Thinking otherwise is as smart as thinking that the attack surface on a host increases linearly with the number of autoconfigured IPv6 addresses assigned to that host from the same subnet.<p>If you don't want the IPv6 hosts on your LAN to be reachable by unsolicited traffic, set the default policy for your router's ip6tables FORWARD chain to DROP, and ACCEPT forwarded packets for ESTABLISHED or RELATED connections. If you're not using ip6tables, do whatever is the equivalent in the firewall software you're using. If you know that you have rules in your FORWARD chain that this change would break, then you already knew that you could simply drop unsolicited traffic in the FORWARD chain.<p>Unrelated to that, I see no reason to get rid of IPv4.<p>I expect that the future will be that nearly all "residental" [0] and non-datacenter business connections provide globally-routable IPv6 service and provide IPv4 via CGNAT, as IPv6 will be used for servers deployed at these sorts of sites. [1] I expect that the future will be that all datacenters and "clouds" will provide globally-routable IPv6 to servers and VMs, and globally-routable IPv4 to the same by way of load balancers.<p>So, home servers [1] will use IPv6, datacenter and "cloud" servers will use IPv4 and IPv6, and "legacy" devices that work fine but will never have their IP software updated will use IPv4.<p>I see IPv6 as a "reduce the pressure on the IPv4 address pool" mechanism, rather than a "replace IPv4" system. Again, I see no reason to get rid of "short" IP addresses. Default to using "long" ones, and keep the "short" ones around just in case.<p>[0] I'm including people's personal mobile computers in this definition of "residential".<p>[1] "Servers" here include things like "listen" video game servers or short-lived servers for file transfers and stuff like that.
> Incoming HN downvotes because I'm not using the coolest latest technology.<p>"IPv6 just turned 30" - literally the first part of the post title.<p>The rest of the post is equally baffling, you are just clinging to a legacy bottleneck (NAT) that was never designed to be a security feature
> never designed to be a security feature<p>It's virtually always used with some firewall rules, so it sort of is? It's just dogma to insist that there are no security benefits to having a single choke point for traffic.
It's almost always done in devices capable of being firewalls because many-to-few translations require stateful tracking. Firewalls already did that, so it was a natural place to apply NAT policies.<p>NAT also include many-to-many and one-to-one translations, and those are just as easily implemented in anything routing with no extra memory and complexity required. This is sometimes referred to as symmetric NAT.<p>The firewall rules are what is providing the protection, by applying a policy that traffic must be initiated by a host on the "more trusted" network or whatever your prefered terminology is. That can happen without NAT and does all the time. Techniques for forcing translations have been well known as long as NAT, and there are probably some unobvious ones out there too. In the 1990s it was still common to get multiple IPv4 addresses if you went to the trouble of having ISDN or whatever, and they were equally protected by a firewall that did not do NAT.
The firewall is very much a separate thing, and part of the efforts to make v6 properly available for home customers was introducing somewhat standard firewall setup that replicates what people <i>think</i> NAT does for security (and what NAT <i>definitely does not do</i>, if only by virtue of being broken by the classic connect/connect vs connect/listen connection)
The firewall is what is providing security, not NAT. And you can equally easily have a firewall in front of an IPv6 network.
NAT superceded ipv6 quite plainly, and it is obvious what technology won out.
what is ipv6, btw?
sudo networksetup -setv6off Wi-Fi ;
sudo networksetup -setv6off Ethernet<p>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 used to like the idea of an IPv4 replacement, but I've come around.<p>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.<p>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.<p>ISPs do not want this.<p>That is all you need to know about why you can’t have IPv6.