It describes in detail what a home router needs to be doing to make all of this work seamlessly.
Things work so well that half the world has working IPv6 already.
Openwrt pretty much implements all of this out of the box.
If you are struggling with IPv6 I recommend reading up on where it is at today and figuring out how whatever makes your network special can be done using IPv6 with no fuss.
Personally I have moved several times changing ISPs in the process and my IPv6 setup involving multiple LANs on my home network has just continued to work. IPv6 renumbering events just work seamlessly and completely automatically.
Historically the only practical hold up to IPv6 adoption has been the ISPs not rolling it out to their customers.
And I know the homenet WG has concluded but I found RFC 7368 IPv6 Home Networking Architecture Principles[1] interesting as well, including its discussion of reachability and RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service.[2] IPv6 still occasionally seem more flaky than IPv4 with some set ups though.
> If you are struggling with IPv6 I recommend reading up on where it is at today and figuring out how whatever makes your network special can be done using IPv6 with no fuss.
> ...
> Historically the only practical hold up to IPv6 adoption has been the ISPs not rolling it out to their customers.
Yep, that's where I am. Frontier FTTH, IPv4 only. Because....I have no idea why. Because Frontier sucks, basically? They have at least started their rollout:
I don't understand why people are so negative about IPv6. I have done essentially zero home networking work and I just ran this successfully. It just works!
```
> ping6 google.com
PING6(56=40+8+8 bytes) 2605:59c0:236f:3a08:7883:9d04:c26d:5fa1 --> 2607:f8b0:4005:806::200e
16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=0 hlim=117 time=22.262 ms
16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=1 hlim=117 time=26.124 ms
16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=2 hlim=117 time=26.807 ms
^C
--- google.com ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 22.262/25.064/26.807/2.001 ms
```
> I don't understand why people are so negative about IPv6. [...] It just works!
Networking is a lot more than being able to ping a single host.
As a concrete counter-example, IPv6 routinely broke for me when I was using pfSense as a router. Why? Because pfSense, with no way of disabling this behavior, published its public IP as the DNS server for internal clients.
So each time I got a new prefix from my ISP, which happens about once a week or more often, machines stopped being able to perform DNS lookups for hours or until I rebooted them.
And, if I had bothered configuring IPv6 firewall rules, those would have had to be reconfigured manually with the new prefix. I understand this is mostly fixed in pfSense recently, but this was the case for many, many years.
Another counter-example is that Android only supports SLAAC, and SLAAC only supports providing a few key infrastructure details like router and DNS. If you want to tell the Android client something else, like NTP server, you're outta luck. Also, if Android successfully gets an IPv6 address via SLAAC, it requires the DNS server IP to also be an IPv6 address. So your internal DNS server must then also serve on IPv6. If that wasn't the case, it would just silently use Google's own DNS servers, breaking any local configuration you had.
Another point is that a lot of us tried using IPv6 decades ago, and so we still have scars from that time. IPv6 today is a lot better, but I still have a lot of IPv6 frustration associated with it from 15-20 years ago.
> And, if I had bothered configuring IPv6 firewall rules, those would have had to be reconfigured manually with the new prefix. I understand this is mostly fixed in pfSense recently, but this was the case for many, many years.
Why would you have to reconfigure your firewall rules when you're getting a new IPv6 prefix?
My consumer router uses iptables under the hood, so it accepts a mask in the firewall rule (so e.g. I can do ::0123:4567:89ab:cdef/::ff:ffff:ffff:ffff:ffff as a target, and when my /56 changes, the rules Just Work™)
But I think it further strengthens my case, software support for IPv6 has been quite spotty over the years, which combined with the less-than ideal deployments out there has made things frustrating for many users over the past couple of decades.
Please don't put words in my mouth. I did not say "Because pfSense, does really bad things."
How pfSense works is fairly reasonable if every IPv6 deployment had been as the original designers intended, ie you have a static prefix.
It's just that the way IPv6 ended up getting deployed in practice was often not aligned with that original vision. And that has been a large source of IPv6 frustration.
There's a few things here that are a bit iffy tbh!
I can't see why an ISP is dynamically changing the IPv6 addressing for a client, but if that's what is going on, then v6 NPT is your friend (RFC6296 - https://datatracker.ietf.org/doc/html/rfc6296).
But pfsense's behaviour is a bit iffy too, unless when you say 'public IP', you mean the IPv6 address being used on the pfsense facing the clients? (I'm assuming it's using DHCPv6 prefix delegation, and the delegation is being changed? And potentially the uplink subnet as well).
opnsense can use the delegated prefix for DHCPv6, it then automatically becomes the “LAN net” firewall alias and you can refer to it in a firewall rule I believe. I assume it’s the same for pfsense and I suspect they are not the only ones.
> unless when you say 'public IP', you mean the IPv6 address being used on the pfsense facing the clients?
Well, that's kinda the thing, pfSense seems to assume global means it's also the IP facing the local clients. I couldn't get pfSense to advertise its ULA as the DNS server for example. But if you have a static prefix, that's not a bad assumption. And a static prefix is what the IPv6 designers envisioned.
> I'm assuming it's using DHCPv6 prefix delegation, and the delegation is being changed?
ISP indeed uses DHCPv6 prefix delegation. The prefix I get can change "randomly". It always changes when my router or modem reboots, but other times too (perhaps when their equipment reboots).
I should note that after getting very frustrated with pfSense, I threw it away a few years ago and switched to OpenWRT which has worked much, much better when it comes to IPv6.
That's literally impossible, to hear some people tell it. "And also, look how hard it'd be to memorize that address", say the people who remember like 2 IPv4 addresses, one of them being 127.0.0.1.
Tailscale, perhaps ironically in this context, has shown me the value of not caring about an IP address.
I used to. When I had a home network I'd carefully assign `10.52.1.x` where `x` was the periodic number corresponding to the machine name! (I write from `lutetium`.)
Now, with Tailscale's magic DNS – `lutetium` being all I need – why on Earth would I give a crap about an IP address? I've gone from being obsessed to truly not caring at all.
So, give me IPv6. Auto-assign everything! All I want is a name.
Hah, I kinda love your naming and numbering convention!
But yeah. On my own LAN, everything is DHCP for IPv4 and SLAAC for v6. Everything uses mDNS and I connect to everything by name, not address. I can only remember the static IP of one of the servers; the rest are purely names.
It's akin to remembering the phone numbers. Even 20 years ago I had like 10-20 of most important ones memorized despite some of them not used often ie once in a years. Nowadays I have 'me myself' in the Contacts because I can't remember it despite using it for 5+ years nor I care.
I remember like 10 different IPv4 addresses, 6 of which are DNS servers where each octet is a single number, 1 is my router, 1 is my home network switch, 1 is my home server and the last one localhost.
The main thing all those have in common is they are either something I frequently use (all mentioned local IPs) or just stupid easy to remember (DNS servers), neither of which isn't possible for IPv6.
From memory isn't localhost for IPv6 not shorter than for IPv4? The answer is yes, it is ::1 and I was thinking of the Multicast and Link-local address prefixes which are ff00:: and fe80:: respectively.
"ten oh oh 7" (how I'd say it or remember it) still seems simpler than "eff dee dee dee colon colon 7". While with ipv4 the dots can be assumed for pauses, v6 doesn't put colons as often, also I could easily see myself forgetting the amount of "d"s. I don't wanna seem too anti-v6, though, I am in favor of everyone adopting the more modern thing.
edit: Well, you said easier to type. I guess I probably agree with that.
There is also the fact that an IPv6 IP has a maximum and minimum number of characters and separators, but not a set one, so the length of any given address is variable.
Instead of being able to run a groove in my head mentally, and read with any sort of rhythm, I have to read them like binary bytes. Every address feels like a foreign phone number where your normal rhythm doesn't fit, but it never gets better.
Perhaps, IMO, the greatest and only sin of IPv6. That and using fucking colons.
When people are managing 20 devices on a network, they access everything by IP address directly and struggle with constant DNS issues.
Introducing a more complex system without easing any of the cognitive load and making fun of it is just cruel at this moment.
Users need a simpler way to connect to their devices, and what tailscale did with magic dns shows that users don’t even care about IPv4 they just want to connect to their devices with something simple they can remember.
I have 68 devices on the line at this moment. I just checked. I remember exactly one of their IPs and that’s just one that stuck in my head. I never connect to it by address.
I agree with the sibling comment: crummy CPE is crummy CPE. This is a solvable problem, but people end up with junky routers and it causes them anguish.
Weirdly this might be a CPE problem, e.g. crappy ISP routers.
Put in something more interesting, e.g. OpenWRT, or there are proprietary options too, that provides simple & reliable local LAN DNS, then the problem just goes away.
Yeah, it's always the same with IPv6 discussions. The main points being:
1. IPv6 addresses are too long to remember
2. IPv6 doesn't need NAT and people are uncomfortable with their devices having a public address as they see NAT as an additional layer of security
If someone is still using the “remembering IP addresses” argument in 2026 (or at any point in the 21st century), I question their technical competence in configuring a network correctly.
It also seems to be a learning curve thing because IPv6 addresses have their own versions of memorable mnemonics. If you are in a LAN space manually configuring LAN addresses, you just need to remember one of the local address (ULA) prefixes like fc00 and then start numbering your devices as ::1 and incrementing (fc::1, fc::2, fc::3, etc). But also in LAN spaces you could just rely on mDNS (devicename.local), it's gotten quite good in most OSes today.
If you need to remember random WAN IPv6 addresses without being able to use DNS or at least a hosts file you've probably got a bunch of other more pressing problems.
Hey, how awesome you live in an area where you have a choice of ISPs and can dismiss one that doesn't meet your spec, rather than having to simply shut up and eat what you're served!
I should dismiss my ISP that's worked for something like 20 years, works now, and will in all likelyhood still be working in 20 years (baring M&A nonsense or the apocalypse)?
Sorry, IPv6 is absolutely not the hill I'm going to die on.
I'm not signing up for a new contract with a different company to get the same speeds at higher price and IPv6 that is pretty much useless as many major websites don't even work with it. It will take at least another 15 years before I will consider using IPv6 at home.
Not only that, but not everyone will even have any other choices. The last apartment I was in literally only had one ISP option; I literally would check every six months or so with other ISPs that were in the area because of the fairly frequent outages, and every time they all said that they couldn't offer me service at my address. (This didn't stop them from filling my mailbox with spam all the time though of course). This was in New York (the city), so it's not like there weren't half a dozen other ISPs operating within a few blocks of me.
I can't take seriously the claim that someone would literally refuse to move into an apartment purely on the basis of not having IPv6 support. Bad internet in general? Sure, that's plausible; I work from home, and like I said, the outages were annoying, and if there were no decent speed options my (now) wife and I might have ruled it out? But literally just the lack of IPv6? That's an absurd reason to pick another place to live entirely.
any idea why no one else could service the building? Ive usually had option of verizon or optimum when ive rented, though my experience has been queens and long island
Optimum was the one option we had. This was in Brooklyn (Park Slope specifically, so pretty high density). My vague understanding is that Verizon wasn't hooked up to the building, but I have no idea why that would be. I only wish they managed to recognize that when sending out advertisements.
Ah okay, i wonder if the dilemma was on verizon side or building owner side
if verizon charges to connect the building and couldnt make an agreement with the owner. or maybe owner has non financial reasons (laziness & indifference) for denying them. or maybe some operational reason verzion wasnt confident in ability to install
If I'm reading correctly, it only prevented new agreements going forward rather than penalizing the old ones, and of course the fact that the FCC's party line split will tilt in favor of the current president at some point every turn means that this might not even be policy anymore (and that's before even taking into account that the current administration doesn't exactly follow precedents around administrative agencies).
Imagine being able to connect two computers over the internet using sockets. WebRTC is a marvel, but I miss the whimsical days of running something on a port at home and connecting to it without thinking about NAT.
If UTF-8 represents the triumph of a design prioritizing backwards compatibility with an existing standard (ASCII) to facilitate a transition, then IPv6 is the cautionary tale of a design which could have made the transition simpler but did not.
IPv6 cannot be backward-compatible with IPv4 in the way UTF-8 is with ASCII. Any argument built on that comparison reflects a misunderstanding of the protocols and leads to flawed conclusions.
Why not? Sincere question. As a very superficial idea, if we go back to the drawing board, for example we could decide our new cool concept of address to be an IPv4 + an hex suffix, maybe at the expense of not having a humongous address space.
So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version.
I just made this up, so I'm sure that a couple years of deep thought by a council of scientists and engineers could come up with something even better.
The header of an IPv4 packet has the source and destination addresses, both as 32-bit values. These fields are adjacent, and there's other stuff next to them. If you appended more bytes to the source address, routers would think that those new bytes are the destination address. This would not be backward compatible.
Interestingly, what you're describing really is similar to how many languages represent an IPv4 address internally. Go embeds IPv4 addresses inside of IPv6 structs as ::ffff:{IPv4 address}: https://cs.opensource.google/go/go/+/go1.26.2:src/net/ip.go;...
That's not a language-specific thing, but is actually part of the IPv6 RFCs as IPv4-mapped IPv6 addresses: [1], [2]
This is super useful because (at least on Linux) IPv6 sockets per default are dual-stack and bind to both IPv6 and IPv6 (except if you are using the IPV6_V6ONLY sockopt or a sysctl), so you don't need to open and handle IPv4 and IPv6 sockets separately (well, maybe some extra code for logging/checking properly with the actual IPv4 address).
That is also documented in ipv6(7):
IPv4 connections can be handled with the v6 API by using
v4-mapped-on-v6 address type; thus a program needs to support only
this API type to support both protocols. This is handled
transparently by the address handling functions in the C library.
IPv4 and IPv6 share the local port space. When you get an IPv4
connection or packet to an IPv6 socket, its source address will be
mapped to v6.
- Where in the bit pattern IPv4 mapped addresses should go
- Coming up with some variation of NAT64, NAT464, or similar concepts to communicate between/over IPv4 and IPv6 networks
- Blaming the optional extensions/features of IPv6 for being too complex and then inventing something which has 90% of the same parts which are actually required to use
It's even easy to get distracted in a world of "what you can do with IPv6" instead of just using the basics. The things that actually make IPv6 adoption slow are:
- A change in the size of the address field which requires special changes and configuration in network gear, operating systems, and apps because it's not just one protocol to think about the transport of again until the migration is 100% complete.
If IPv4 were more painfully broken then the switch would have happened long ago. People just don't care to move fast because they don't need to. IPv6 itself is fine though and, ironically, it's the ones getting the most value out of the optional extensions (such as cellular providers) who actually started to drive IPv6 adoption.
In IPv4 you only need to transmit IPv4 addresses. If the "cannot be" in parent post is referring to the exact byte disposition in packets, then I go the other way around to claim that I agree. Because the only way that a UTF8 character can pretend to be ASCII is because ASCII didn't use all of the 8 bits in a byte to begin with. Only way to have something similar in this case, would be that IPv4 didn't use all of the allocated bits for addresses... Which is not the case.
What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it. But I agree, that the actual packet header layouts would need to look at least a bit different.
> What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it.
Like:
> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]
They did that. Problem is that an ipv4 only host can't talk to ipv6. Adding more bits to ipv4 creates a new protocol just like ipv6 and has the same transition issues.
The protocol field in the ipv4 header seems like a reasonable choice. A value would be associated for ipv6 and if that value is chosen then additional header data follows the ipv4 header.
That's similar to, but not exactly what we were discussing. In particular 6in4 has a full ipv6 header after the ipv4 header, but here the suggestion was instead that supplementary infomation would follow. For example, the most significant address bits could be stored in the ipv4 header and the least significant ones in the new part.
That's not meaningfully different. It would just amount to a slightly less redundant representation of the same data -- the steps needed to deploy it would be the same, and you'd still have all the same issues of v4 hosts not understanding your format.
Not really reasonable. That would
1) Make routing inefficient because routers have parse an additional, non-adjacent, non-contiguous header to get the source and destination addresses. 2) Break compatibility because there would exist "routers" that do not understand ipv6 headers. They receive your ipv4 with v6 packet and send it somewhere else.
The result is basically the same situation we are in today, except much more hacky. You'd still have to do a bunch of upgrades.
> So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version.
Like
> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
So you have to ship new code to every 'network element' to support your "IPv4+" plan. Just like with IPv6.
So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to:
* update the IP stack (like with IPv6)
* tell applications about new DNS records (like IPv6)
* set up translation layers for legacy-only code to reach extended-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.
Deploying the new "IPv4+" code will take time, there will partial deployment of IPv4+ is no different than having partial deployment of IPv6: you have islands of it and have to fall back to the 'legacy' IPv4-plain protocol when the new protocol fails to connect:
"Just adding more bits" means updating a whole bunch of code (routers, firewalls, DNS, APIs, userland, etc) to handle the new data structures. There is no "just": it's the same work for IPv6 as with any other idea.
(This idea of "just add more addresses" comes up in every discussion of IPv6, and people do not bother thinking about what needs to change to "just" do it.)
> If IPv4 were more painfully broken then the switch would have happened long ago.
IPv4 is very painful for people not in the US or Western Europe that (a) were now there early enough to get in on the IPv4 address land rush, or (b) don't have enough money to buy as many IPv4 addresses as they need (assuming someone wants to sell them).
So a lot of areas of the world have switched, it's just that you're perhaps in a privileged demographic and are blind to it.
> IPv4 is very painful for people not in the US or Western Europe that (a) were now there early enough to get in on the IPv4 address land rush, or (b) don't have enough money to buy as many IPv4 addresses as they need (assuming someone wants to sell them).
The lack of pain is not really about the US & Western Europe have plenty of addresses or something of that nature, it's that alternative answers such as NAT and CG-NAT (i.e. double NAT where the carrier uses non-public ranges for the consumer connections) deployments are still growing faster in those regions than IPv6 adoption when excluding cellular networks (they've been pretty good about adopting IPv6 and are where most of the IPv6 traffic in those regions comes from).
I think your summary is really great. One of the better refutations I've seen about the "what about v4 but longer??" question.
However, I think people do get tripped up by the paradigm shift from DHCP -> SLAAC. That's not something that is an inevitable consequence of increasing address size. And compared to other details (e.g. the switch to multicasting, NDP, etc.), it's a change that's very visible to all operators and really changes how things work at a conceptual level.
The real friction with SLAAC was that certain people (particularly some at Google) tried to force it as the only option on users, not that IPv6 ever forced it as the only option. The same kind of thing would likely occur with any new IP version rolling out.
SLAAC isn't something that is an inevitable consequence of increasing address size, it's something that is a useful advantage of increasing address size. Almost no one had big enough blocks in IPv4 where "just choose a random address and as long as no else seems to be currently claiming it it is yours" was a viable strategy for assigning an address.
There are some nice benefits of SLAAC over DHCP such as modest privacy: if device addresses are randomized they become harder to guess/scan; if there's not a central server with a registration list of every device even more so (the first S, Stateless). That's a great potential win for general consumers and a far better privacy strategy than NAT44 accidental (and somewhat broken) privacy screening. It's at odds with corporate device management strategies where top-down assignment "needs to be the rule" and device privacy is potentially a risk, but that doesn't make SLAAC a bad idea as it just increases the obvious realization that consumer needs and big corporate needs are both very different styles of sub-networks of the internet and they are conflicting a bit. (Also those conflicting interests are why consumer equipment is leading the vanguard to IPv6 and corporate equipment is languishing behind in command-and-control IPv4 enclaves.)
> Furthermore, DHCPv6 holds you back from various desirable things like privacy addresses and (arguably even more importantly) IPv6 Mostly.
Why would DHCPv6 hold back privacy addresses? Can't DHCPv6 servers generate random host address bits and assign them in DHCP Offer packets? Couldn't clients generate random addresses and put them in Request packets?
DHCPv6 temporary addresses have the same properties as SLAAC
temporary addresses (see Section 4.6). On the other hand, the
properties of DHCPv6 non-temporary addresses typically depend on the
specific DHCPv6 server software being employed. Recent releases of
most popular DHCPv6 server software typically lease random addresses
with a similar lease time as that of IPv4. Thus, these addresses can
be considered to be "stable, semantically opaque". [DHCPv6-IID]
specifies an algorithm that can be employed by DHCPv6 servers to
generate "stable, semantically opaque" addresses.
How does DHCPv6 hold back IPv6-mostly? First, most clients will send out a DHCPv4 request in case IPv4 is the only option, in which case IPv6-mostly can be signalled:
I was unaware of this, so thanks. Sounds like it addresses (pun intended) my concern.
> How does DHCPv6 hold back IPv6-mostly? First, most clients will send out a DHCPv4 request in case IPv4 is the only option, in which case IPv6-mostly can be signalled
I get the impression that this fact is fundamentally lost on a lot of the people who want a "compatible" IPv6. Like, their mental model does not distinguish between how we as humans write down an IPv4 address in text and how that address is represented in the packet.
So they think "let's just add a couple more dots and numerals and keep everything else the same"
I think you’re right. Honestly, my impression is that a lot of people imagine it like a string field, and others more like a rich text field, analogous to “can’t we just use a smaller font?”
> The first thing in the IP header is the version number.
So you just change the version number… like was done with IPv6?
How would this be any different: all hosts, firewalls, routers, etc, would have to be updated… like with IPv6. So would all application code to handle (e.g.) connection logging… like with IPv6.
I was addressing the narrow claim that you cannot distinguish ASCII from UTF-7. You can distinguish IPv4 from IPv6 by looking at the version field (and I forgot to mention the L2 protocol field is out of band from IP's perspective). Obviously if the receiver doesn't support UTF-7 or IPv6 then it won't be understood. Forward compatibility isn't possible in this case.
Weirdly, the version field is actually irrelevant. You can't determine the type of a packet by looking at its first byte; you must look at the EtherType header in the Ethernet frame, or whatever equivalent your L2 protocol uses. It's redundant, possibly even to the point of being a mistake.
I mean, yes, in practice you can peek at the first byte if you know you're looking at an IP packet, but down that route lies expensive datacenter switches that can't switch packets sent to a destination MAC that starts with a 04 or 06 (looking at you, Cisco and Brocade: https://seclists.org/nanog/2016/Dec/29).
Right, the variable-length thing was my point. That's fine when you're dealing with byte slices that you scan through incrementally. But it's not fine for packets and OS data structures that had their lengths fixed at 32 bits.
Just split the address into two 32-bit chunks (call the top word the "pool", bottom word "address") and assign the full IPV4 range to pool 0x00000000. Done.
But then think about what the routing tables would look like, how would an IPv4-only host find an IPv6 host not in pool 0? You'd be reinventing NAT, but in a less-structured context than how NAT works today. There's more issues to it too.
If it was really that simple they would have done exactly that. "Just adding more bits to IPv4" just isn't possible to do backwards-compatibly. IPv6 is the closest you can get to that while also dealing with the complexity that arises with longer addresses.
Until you upgrade every router between 2 hosts so that it understands the IPv4b addressing scheme, those 2 hosts can't talk. And if you're going to upgrade them all anyway, then might as well do it right.
That doesn't change anything - until everyone adopts the new chunk nobody can use it (even one windows XP machine that you don't personally care about is enough to still kill it today). IPv6 is better because at least it can work side by side by IPv6.
This article that "begs to differ" is inventing IPv6 all over again. It just refuses to call itself so.
I quote from the top comment:
>So you have to ship new code to every 'network element' to support IPv4x. Just like with IPv6.
and
>So you have to update DNS to create new resource record types [...] Just like with IPv6.
and
>You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6.
The key difference, you don't do dual stack, you can incrementally roll it out and get tangible relief, unlike IPv6.
The point is less about the technology proposed, but the point that there could be an interoperable version of a next generation IP and IPv4.
IPv6 did the braindead thing and completely threw out the idea of transition and interoperability for a clean slate. We're paying for it many decades later.
Also, rather than regurgitate a comment, perhaps you should read the article, because that comment misunderstands what is being proposed and thus completely missing the point.
Why are you still trying to claim this? v6 has transition methods and ways to interoperate coming out of its wazoo. It does pretty much everything you can do to work with v4. Nobody threw out the idea of transitioning.
> but the point that there could be an interoperable version of a next generation IP and IPv4
Yes, it's IPv6. The thing you linked basically took one of the interoperability methods of v6 and described it in weird terms.
You don't do dual stack with v6 either, unless you want to -- you can do the incremental rollout and tangible relief thing with v6 just fine. (But it turns out most people do want to do dual stack.)
Is this some kind of attempt at gaslighting? If IPv6 gave tangible relief, then IPv4 today would not be an important mainstay of the Internet. I recommend you read the article I posted, and see how different things could have been, and how completely botched IPv6 rollout has become, that it is just not taken seriously except by some die hard cultists and mobile/telco (which can be done because they pretty much get full configuration of your networking stack).
I guarantee, we will be having this same exact discussion 10 years from now. And then so on, and so on.
Nope, not at all. Everything I said is true. v6 supports deploying in the way described in that article, and you can do it today if you want.
If you don't want to deploy v6 like that, consider why -- because the people who live in the world described by that article will also have the same reasons as you to not deploy it that way.
> If IPv6 gave tangible relief, then IPv4 today would not be an important mainstay of the Internet
No, that argument doesn't hold. v6 can give tangible relief even while v4 is an important mainstay of the Internet. You only have to listen to the people doing CGNAT, or the people turning on v6-mostly and seeing their v4 address use drop by 75% to hear examples of that.
Deployments of v6 reduce the pressure on v4, because they allow us to deploy new networks without needing v4 and because migrating existing networks frees up v4 that can be repurposed. This is also a benefit that's making v4 more viable that it would be without v6.
Plus you're making assumptions about the time needed to replace the Internet's L3 protocol. It's nice to fantasize about finishing it in 10 years, but that doesn't mean that finishing it in 10 years is realistically possible. Deployment of v6 is ongoing and v4's importance is dropping over time; you can't know what the ultimate impact of v6 will be until we're finished deploying it.
There was always going to be a long tail of v4-only hosts, no matter what we did. That's why v6 has a large number of compatibility methods for dealing with them (yes, including the method described in the linked article). It wouldn't be possible to deploy it at all if it didn't.
I'm surprised how few people are talking about ULAs. For any home network where you don't have a reserved global address space from your ISP, it makes sense to configure a ULA on your router and use it for all internal hosts, and the ISP assigned address is only used for Internet access.
This does not require NAT/Npt and you have the best of both worlds.
I use ULAs since my ISP changed my ipv6 prefix twice a month. What I learned is that ipv6 configuration usually requires a more 'comerical grade' router. In the end it works well for me but getting it setup initially took a lot of effort. Easy to do the second time though.
I later moved and my current ISP does not have ipv6 support but my ULA setup kept working fine with some minor tweaks.
Unmentioned in the Wikipedia article is RFC 7368 IPv6 Home Networking Architecture Principles[1] that discusses them as well.
> A home network running IPv6 should deploy ULAs alongside its globally unique prefix(es) to allow stable communication between devices (on different subnets) within the homenet
RFC 7368 for home networks recommends the use of ULA locally.
> A home network running IPv6 should deploy ULAs alongside its globally unique prefix(es) to allow stable communication between devices (on different subnets) within the homenet
> When an IPv6 node in a homenet has both a ULA and a globally unique IPv6 address, it should only use its ULA address internally and use its additional globally unique IPv6 address as a source address for external communications.
RFC 7368 is a 2014 "informational" (no ietf standing) doc so it's not a source for current IETF advice. Also it was part of the since closed "homenet" working group initiative trying to define some new stuff that did not get vendor uptake.
But in substance, if you have several subnets, then using ULA may make sense depending on what you're trying to do. However most home networks don't subnet.
It’s pretty sweet. By using ULA addresses for everything, all internal networking keeps working as-is if my ISP allocation changes. Every host can talk to its neighbors using internal addresses, and still connect to remote hosts without NAT breakage.
mDNS is orthogonal to ULA. mDNS is for discovery and name resolution, whereas ULA is for IP connectivity. And mDNS operates at the link-local scope (link-local addresses), whereas ULA is scoped for the entire home network.
When a Multicast DNS responder sends a Multicast DNS response message
containing its own address records, it MUST include all addresses
that are valid on the interface on which it is sending the message,
and MUST NOT include addresses that are not valid on that interface
(such as addresses that may be configured on the host's other
interfaces). For example, if an interface has both an IPv6 link-
local and an IPv6 routable address, both should be included in the
response message so that queriers receive both and can make their own
choice about which to use. This allows a querier that only has an
IPv6 link-local address to connect to the link-local address, and a
different querier that has an IPv6 routable address to connect to the
IPv6 routable address instead.
So instead of using static ULA addresses, you can use the the routable address returned by mDNS. It can often replace the ULA address use case.
I agree. If you click through to the original Wikipedia table that's cited in this article you can see a pretty clear correlation between countries with more IPv4 addresses than people vs. wealth/hegemonic clout of the country. In the UK, US, Germany, France, Canada, Japan, etc. there are way more than enough IPv4s to go around. Some ISPs here in the UK will even lease you bundles of four or eight IPv4s for very little additional cost.
Ipv6 is a theoretical benefit to the commons but as an individual it's an increase in complexity and a new abstraction for nearly the same result as your existing ipv4 network. There's just not enough incentive to invest in the switch.
The US doesn't have excessive IPv4 Addresses. We have a real shortage and big pain because we don't have anywhere near enough. Sure we have 40% of them all - but that has no indication of what enough is.
I worked at an ISP way back in the dark ages of 2008 and we were all worried about IP exhaustion then. It's now 17 years later and what do you know, IPv4 is still trucking.
I think we'd be surprised how much address space is actually wasted, not announced or routed.
I have my own /24 that I registered back in the 90's. It is, in fact, routed and announced globally. I know several "early Internet" nerds with the same.
I know three local companies with /16's that aren't even announcing their blocks! Perhaps they use them internally.
Indeed, the tragedy of the IPv4+NAT stockholm syndrome is that people view having to use ambiguous addresses as access control and can't distinguish reachability vs addressing.
One of the biggest, I would assume in the current year, blockers to an IPv6 only world would be the fact that the major "cloud" vendors do not support it.
I don’t know how you measure “metric tons of content” but I suspect in general there’s lots of US-available content on IPv4 that the countries like China and India want to access, and not much the other way around.
But that should be a perfect playground for an IPv6-only network that has gateways to the IPv4 content; eventually the home-developed content will begin to drive demand elsewhere.
IPv4 has been "in crisis" for the entire 20 years I've worked in tech and we seem to be managing alright. Not to say things can't be better or we shouldn't try to improve. But I'll be surprised if v4 isn't still the default for most use cases in another 20 years.
That's because the Internet is basically broadcast TV 2.0 so no one cares about having public IPv4's at home as long as they can get to their memes and streaming. Great job, we took something that was meant to be a next frontier in humanity and let anyone connect with anyone else without gatekeepers/intermediaries and turned it 21st century brainrot troughs. Perhaps a society not in slow intellectual decline would have chosen otherwise.
> Great job, we took something that was meant to be a next frontier in humanity and let anyone connect with anyone else without gatekeepers/intermediaries
We already had that, it's called shortwave radio. The internet, especially as it's implemented and as it's used, is a terrible way to achieve this. It's service providers the whole way down.
It would be funny if HAM radio came back because the social filter imposed by the limitations wound up being more important than the technological capability.
Problem is that HAM radio also has social filters you broadcast to everyone and you don’t know who is listening. Encrypted communication is not allowed in HAM.
You are not supposed to use it for „communication” as in Facebook. You are supposed to use spectrum to test your gear and keep transmissions short to leave space for others.
I was in local HAM club and passed the exam for license but never got license to transmit mostly because you are not supposed to chat frivolously over the radio.
His point is that you're managing alright because you live in a country where your ISP can give you a public IP address. The author lives in a country where that is not possible and accesses the Internet behind layers of NAT.
It's possible for Indian ISPs to buy IPv4 addresses and assign them to customers. Maybe not for $5/month but if you're willing to pay US prices (plus tax) you should be able to get US quality service.
Yes, but they can't do that if every Indian wants one, and they especially can't do that if every Chinese person wants one at the same time.
IPv4 is 32 bits. It has a hard cap of ~4 billion addresses. China and India alone have 2.85 billion people.
Add in the United States and Europe, and now nobody else gets an IP address. South America, Canada, Mexico, Australia, Africa, the middle east, the rest of Southeast Asia, etc. don't get to use the internet. That's 4 billion people who don't get to use the internet.
> What's the difference, other than port forwarding? Does NAT cause some sort of unique issue that makes existence miserable?
The difference is that your home router does not get a public IP on its WAN interface, but perhaps the non-publicly-routable 100.64.0.0/10 [1] with CG-NAT.
So if you don't have a public IP address, how exactly are you supposed to forward anything? What is the other end supposed to connect to as an IP address?
> The difference is that your home router does not get a public IP on its WAN interface, but perhaps the non-publicly-routable 100.64.0.0/10 [1] with CG-NAT.
Yes...? I know that, but does that cause any issues in practice other than death of P2P?
> So if you don't have a public IP address, how exactly are you supposed to forward anything? What is the other end supposed to connect to as an IP address?
I already mentioned port forwarding because with something like CG-NAT, it is often not possible (or not allowed). But I am not aware of any issues that stem from this other than an inability for others to establish connections directly to you. In fact, my network has a public IPv4 without CG-NAT and yet I am already used to being unable to receive data other than back through a TCP stream. That is the entire reason reverse proxy tunnels (such as ngrok, etc.) exist.
> Yes...? I know that, but does that cause any issues in practice other than death of P2P?
Well:
> If you’re a gamer using PS5, Xbox, or PC in 2025, running into Double NAT or CGNAT port forwarding issues can make online play nearly impossible. Many 5G home internet and satellite services (like T-Mobile Home Internet and Starlink) put users behind carrier-grade NAT, which blocks direct connections and port forwarding. The good news? There are still workarounds that can open up your connection for smoother online gaming.
When we went from dial-up speeds to DSL/cable to fibre we were able to have all sorts new applications due to higher bandwidth. Smartphones are capable of all sorts of things because they're always online: back in the day people used to talk about "being online" and saying "sorry, I was offline", because you only had connectivity at the office or at home (where you dialed into your ISP).
What kind of applications and services are not being invented because we're stuck with the current non-P2P / centralized setup of IPv4+NAT?
> What kind of applications and services are not being invented because we're stuck with the current non-P2P / centralized setup of IPv4+NAT?
I don't know? I've never had CG-NAT and yet I've never seen a piece of software that takes advantage of that except maybe for games that use UPnP to open ports.
> I don't know? I've never had CG-NAT and yet I've never seen a piece of software that takes advantage of that except maybe for games that use UPnP to open ports.
Which, as a sibling comments mentions, is the point.
The fact that (CG-)NAT is in the way could be precluding the development of "software that takes advantage of that". It's a form of (negative/inverse) survivorship bias: kind of like zoning for only single-family homes and yet saying "no one wants mid-rise towers/apartments as evidenced by the fact no one building them". The current rules/structure/architecture preclude any other options.
Games, voice/video chat (especially open source ones), stuff like Tailscale, stuff like Magic Wormhole, ... stuff like Dropbox.
Is there anything you do on a computer that involves communicating with another user? That's not just anything - that's most things! All communication between two computers is improved by not requiring NAT.
Corporations love to keep us dependent on their central servers, of course.
> I've never seen a piece of software that takes advantage of that except maybe for games
Maybe we haven't seen many products available on the market to take advantage of it because the current standard of NATs make such things practically unworkable?
Its pretty much impossible to ship smart home stuff that is hosted locally (i.e. not without it connecting to some cloud service) because people want to access these smart devices from outside their home. They're not likely to configure a VPN to connect home, they're not going to configure NATs in any workable fashion (or may be unable to, such as CGNAT), the applications probably don't want to have to handle having NAT hairpinning issues, etc.
So instead we continue down everything that's popular being something that requires a cloud proxy/relay (because that's the only way things actually work for most people), when in reality if things could just be public we could do a whole bunch more and empower people to easily host things themselves.
Well you just handwaved away the most significant difference between NAT and native IP, obviously there won't be any major difference to discuss about anymore!
No, we can't ignore port forwarding. The key thing to realize about NAT is that someone owns the NAT. Back then, the NAT lived inside each of the home routers, so even if you have a "strict" NAT (endpoint-dependent mapping NAT, i.e. one that doesn't allow for hole-punching), you can easily bypass it by setting up a manual port forwarding entry.
With CGNAT that's no longer possible, you do not control the NAT. If your ISP decides to screw you over, you essentially do not have a choice but to get a relay, which needlessly costs you money.
---
But if you really want to know what advantages native IP has over NAT, I'd say the lack of keepalive packets (to keep a holepunched NAT entry from being removed) is a pretty nice thing.
What is this entitled mindset that somehow people without CG-NAT already benefit from their public IPv4? The only benefit I get from port forwarding is being able to expose my Plex media server to the wider internet, and Tailscale and Steam Networking being able to establish P2P. But even UDP should work through CG-NAT. So you can't hole-punch over WAN -- I've never encountered even a single piece of software that needs that except for servers.
Port forwarding is nice, but everyone already knows you can hardly run a server at home (even in countries where port forwarding is standard). It's been this way for as long as I can remember. So yes I handwave it away because it doesn't matter. If that's the only drawback to CG-NAT (other than single IP address bans applying to entire nations or something) I hardly understand why it warrants treatment as such a terrible awful disaster.
>What is this entitled mindset that somehow people without CG-NAT already benefit from their public IPv4?
I will raise you the opposite point: why deprive people of their ability to have a globally addressable IP address?
>But even UDP should work through CG-NAT.
I have already told you why it is wrong to make such as assumption, haven't I?
I have heard of stories coming from China and Vietnam that some ISPs implement so-called "type 4 NAT", otherwise known as symmetric NAT or NAT with endpoint-dependent mapping.
This kind of NAT is NOT hole-punchable. And because you don't control the NAT, you are simply SOL if one day your NAT decides to switch to it. Can't even use Tailscale without significant service degradation now, ouch.
Granted, I have only heard about it in Vietnam and China, and it's not a national thing -- only some provinces seem to have symmetric NAT implemented. But I feel the need to remind you that the ISPs there were able to get away with it, because the two countries have significant IPv6 presence. [0]
>Port forwarding is nice, but everyone already knows you can hardly run a server at home (even in countries where port forwarding is standard).
You can hardly run a server at home because we have been facing address space depletion since the dot com bubble.
>I hardly understand why it warrants treatment as such a terrible awful disaster.
You haven't faced an overloaded CGNAT gateway, have you? [1]
> I will raise you the opposite point: why deprive people of their ability to have a globally addressable IP address?
I wouldn't. I just don't understand, if the alternative is having no internet access at all, why CG-NAT is so utterly deplorable.
> This kind of NAT is NOT hole-punchable. And because you don't control the NAT, you are simply SOL if one day your NAT decides to switch to it.
Can you clarify what you mean by hole-punchable? If all else fails, just use TCP, right? Does TCP also not work? I'm also not talking about connection between peers but connection to a server. Connection between peers has never been a 100% reliable strategy regardless of anything.
> You haven't faced an overloaded CGNAT gateway, have you? [1]
I have not, but that is not inherent to CG-NAT, is it? Any switch or other hop between you and your destination can be overloaded. The destination itself can be overloaded.
> Please... learn more about hole punching before trying to engage in the topic.
I'm not engaging in the topic of hole punching though? The topic is whether CG-NAT has drawbacks other than lack of port forwarding. As I've said many times, expecting P2P connectivity has never been viable. But you ignore that and keep talking about how hard hole punching is, as if it's indispensable. What makes it so indispensable? Why is it so critical?
> Hole punching, in the context of NAT, is a technique where you establish peer-to-peer connection between hosts behind a NAT.
Good, that confirms I was never talking about that. I even explicitly clarified I was not talking about that (though you may have loaded my comment before that edit.)
> It does not matter which protocol you use, UDP or TCP or chuckles SCTP. If you want to establish P2P connection, you must hole punch.
You don't need to establish P2P connection so I don't see why that's such a problem. Again, it has never been safe to assume P2P connection is possible. Period. It is merely a progressive enhancement.
You don't mention port forwarding without mentioning about hole punching.
Because what port forwarding is for, if not to ease the establishment of direct connections?
>You don't need to establish P2P connection
If you are seriously suggesting Server-Client Is All You Need (TM), I feel we might as well stop the discussion now. VoIP essentially requires P2P, WebRTC is much better with P2P. BitTorrent etc obviously runs on P2P.
Services that provide relays (for people who can't establish P2P connection) for free, can only do so because they expect most connections to NOT go through the relay, and so they could simply stomach the costs of running one small relay.
"What's the difference other than the difference?". Not being able to forward ports means I can't play Tricky Towers with my friend (who isn't technical enough to join a VPN with me and would have privacy concerns about doing so).
Hole punching, which has various forms, may or may not work.
This means if you're doing something realtime, you may need to stick a server(reachable endpoint) in between it, at the very least reducing performance.
I have never seen any situation where this is not already necessary other than UPnP which already almost never works reliably. A publicly-addressable relay is already practically non-negotiable for anything over the internet.
For one, monopolies disabling it by default on their equipment? I remember some years ago having to guess the admin password at a vacation house so I could enable UPnP. It's usually framed as a security vulnerability, even.
uPnP fails when multiple devices are fighting over the same port assignments. uPnP fails when people have it disabled, as has been recommended many times over the years.
Part of the issue is this affects different countries differently, based on residential IP allocations to household ratios. I am currently on CGNAT in Australia split 256 ways, and any site that doesn't support IPv6 can be borderline unusable. I can't imagine what it's like in countries with worse ratios, like India.
It's been in crisis for decades, but it's also getting increasingly worse every year.
The main problem with IPv6 is that it is different from IPv4. There's SLAAC, there's no ARP and there're also some other differences. In the end, it's simpler to just not bother.
Yup. People learn parts of v4 through osmosis because it's the default. Then when networking topics come up, it's easier to keep going with stuff that looks familiar rather than un-learning assumptions. Why bother with the weird other thing that's not even mandatory?
Because IPv4 is logical and makes sense. First thing which IPv6 came up with? No NATs everything will have a public address. It turned out that this was hare brained idea so let's just cover it up with firewall. However misconfigured firewall means that everything is open... IPv6 has been designed by people who were unable to think further than what is going to be tomorrow for a lunch.
IPv4 came out in 1982 and was designed for every device to have a unique public address. Protocols like FTP were designed to literally pass an IP address to connect directly to.
As addresses started running out, the NAT RFC was published in 1994 and described NAT as a "short-term solution". NAT was never meant to be an integral part of IPv4. https://www.rfc-editor.org/rfc/rfc1631
NAT broke a ton of things which required more and more hacks piled on, making it more complex to build services on top if it (e.g., a server in the middle to proxy all the traffic needed between peers is a 100% requirement, with all the maintenance and scaling headaches that come with it).
So you actually agree with me, that making all addresses public was stupid to begin with. It was stupid on IPv4 and it remain stupid on IPv6, yet we already have experience from IPv4 that it was stupid.
> So you actually agree with me, that making all addresses public was stupid to begin with.
If an address is not public how can you start an connection from it, or end a connection at it? A web server needs a public address if you want to have people reach it. And you, at some point, also have to have a public address if you want to connect to pubic services: either on your end-host, at your CPE/router's WAN interface, or on an interface of your ISP's CG-NAT box.
But having a public address on your end-host also allows for much more functionality than if you were stuck behind CPE-NAT or CG-NAT. Now, you don't have to use this functionality—just like how I didn't when my printer gets an publicly addressable (but not publicly reachable) IPv6 address—but it opens up various possibilities.
Well, actually it will. In fact, even correctly configured NAT won't stop connections into your network.
On top of that, it lulls you into a false sense of security, so you confidently think it's protecting you even when it isn't. At least not having NAT makes the actual state of your network clearer.
Isn't that the first thing that IPv4 came up with as well? One publicly routable address per device that wants to access the Internet (or the network of universities or military installations or whichever network you were on pre-Internet).
You see and IPv6 was not able to learn from the failure - people does not want to have all computers in one network, same like people does not want to live in one skyscraper.
I honestly don't understand why IPv6 is not actively deployed in 2026. Every piece of networking hardware over past decade supports IPv6 and often dual stack too. And to switch between both often takes a few clicks if DHCPv6 server is up and reachable. Absolutely transparent, free, zero performance hit. But no, so many persist at doing v4.
PS: I'm talking about MSO hardware. But client hardware should be at the same level of compatibility for years too.
I love IPv6, SLAAC, mDNS, Thread, Matter and the other cool stuff in the ecosystem. I have wasted too much time setting manual DHCP static assignments. Now I just use SLAAC and mDNS with basically no manual config.
The way forward for what though? It remains to be seen if this level of infrastructure and complexity has any kind of resilience. I seriously doubt it does, looking back on history. I think it's far more likely that the post-industrial population contraction (which hasn't even really begun) as well as climate change (anthropogenic or not) will make it far more likely that this model of "everybody uses a computer" ends up in the junk bin of history. Can't say I'd be sad to see it go. Somebody who has no interest in computers shouldn't ever have to touch one.
Someone should’ve thought about the UX of IPv6 before declaring it to be “the way”. It’s like having to learn Klingon just to setup your printer. IPvNext could sort that out… maybe it’s time to consider moving on.
People claim this all the time, but every time I push I discover they have no clue how networks work and just handwave away as "easy" or "details" the very reasons people who understand networks say it can't work.
> but every time I push I discover they have no clue how networks work
Obviously. Anyone who does understand how networks work aren't going to spend any time talking about it. People don't talk about things they are certain about. They talk about what they don't know much about to feel out what they're missing. You will never find a discussion where pushing back reveals that you found the world's utmost expert. The world's utmost expert is bored with the subject and has moved on to talking about the things he has gaps in.
I think you’re making my point - someone decided to surface a very low level concept “as is” (without a suitable abstraction) on a level where people also need it for use cases that don’t justify knowledge of the arcane. Or dealing with gatekeepers for that matter.
There are already abstractions that allows you to deal with IPv6 without actually typing in the addresses. It's the DNS, but every time this topic pops up, someone rejects DNS and proceeds to continue sprouting something about how IPv6 is unusable because you can't memorize the addresses.
For most people there is no UX. Most US houses are IPv6 and use it without knowing anything about networking at all (most cable internet is IPv6, as the big cell networks).
The people who have to make networks work need to know how IPv6 works - but there is no getting around that - they know how IPv4 works too.
>every time I push I discover they have no clue how networks work
Listen here, if there is a networking technology or feature that I wasn't forced learn when I half-assed a SOHO router config in 2005, then it shouldn't exist at all.
I learned the basics of IPv6 a few years ago, and forgot some of it... but NDP, the built in default addresses for router solicitation, address assignments and so on.
I'll tell you that if you just think of it on its own, it's really no harder than IPv4 + ARP + DHCP, just one or two extra things to remember.
The difficulty of adoption is the featureset and the UX of operating systems and home routers in particular. It is really difficult to find a consumer router, or even home networking OS, that exposes sensible working defaults for IPv6. The problem extends to the ISPs.
Like there was any chance to see UX of this to work or not in most of places. I've never had an ISP that even offered any IPv6 connectivity besides mobile internet.
It is the only way forward, but the reason for that is not the correlation between population and IP addresses. After all, most of the use of internet today is not by people, but by bots, crawlers, AI agents, b2b and more, and that is far more than the human population, and then you have the virtual networks built over IP like VPNs, Tor and more. It is more related to privacy, bidirectional communication and protocols, security, identity and possibilities.
The only place I have utilized an IPv6 address publicly is on my authoritative name servers only because some DNS testing tools assume it is there. It's not really needed however. My home firewall does have one but I have never used it. I can't think of a use for it. I have multiple static IPv4 addresses and they have suited me just fine for decades. I suppose I could bind a Squid SSL Bump MitM proxy to it in case a site blocks me but I would probably leave it off most of the time.
I never use them on my web, chat, voice, IRC and other servers as I personally find blocking shenanigans on IPv4 and not having to implement the same checks on IPv6 is just easier for a lazy person like me. IPv6 just feels like an after-thought bolt on to me. Clunky, not well thought out. Some privacy gotchas that can be disabled but some will not. That's just my take. I doubt anyone will have the same take.
I think IPv4 will be fine for another 100 years even if we have to re-purpose some DoD/MoD ranges given they don't use them and maybe annex some /8's from a few greedy companies. But that's a problem for Gen Delta. Gen Foxtrot can deal with repurposing some multicast ranges.
Or ... people can use the DoD/Mod and assorted other space to get their IPv4 allocations. There is a ton of unused space in IPv4. Reserved, allocated but entirely unused. Also take back some /8's from greedy companies that don't need all that space. stares at HP When I say take I mean take as in a forceful annex and a timeline.
> Or ... people can use the DoD/Mod and assorted other space to get their IPv4 allocations.
Someone did the math on this:
> Now, average daily assignment rates have been running at above 10 /8s per year, for 2010, and approached 15 /8s towards the end. This means any reclamation effort has to recover at least 15 /8s per year just to break even on 2010’s growth. That’s 5.9% of the total IPv4 address space, or 6.8% of the assignable address space. Is it feasible to be able to reclaim that much address space? Even if there were low-hanging fruit to cover the first year of new demand, what about there-after? Worse, demand for address space has been growing supra-linearly, particularly in Asia and Latin America. So it seems highly unlikely that any reclamation project can buy anything more than a years worth of time (and reclamation itself takes time).
There are 'only four billion IPv4 addresses, and there are eight billion people on the planet. There are just as many smartphones (I have two: personal and work):
Even if you (CG-)NAT an IPv4 address for some number of people, you still need to have IPv4 addresses for public services (web, mail, NTP, etc).
There is no scenario where 2^32 addresses is enough for humanity's needs: as some point you need to go to a protocol with more that 32 bits of address space.
There are 'only four billion IPv4 addresses, and there are eight billion people on the planet. There are just as many smartphones (I have two: personal and work)
Unless all of these devices are running a dedicated full time server that must be reachable inbound by everyone this is not required. At any given time "all the people" are not online. That is why DHCP (per ISP) takes care of this. Maybe some day all the people may become terminally online but I would not count on it.
Yeah some day IPv6 may be required. Maybe in 100 years or so. IPv4 has plenty of unused allocated addresses that can be ripped away from greedy people. There was a time when ARIN would check to see what was in use and would take back anything people were squatting on. I think the reclamation project works if we dont assume everything has to be reachable as a server.
I should add that cell phones (where people are terminally online) were already IPv6 a long time ago for the most part so it's really a non issue. The only risk I see is if someone wanted to start a new massive dedicated server and VPS provider. Most of those are dual stack IPv4+IPv6 now and doing that means clawing some IPv4 space away from those I mentioned earlier.
> Unless all of these devices are running a dedicated full time server that must be reachable inbound by everyone this is not required.
I think this is a lack of imagination. The fact that (CG-)NAT is in the way could be precluding the development of software that could take advantage of incoming/P2P connections.
It's a form of (negative/inverse) survivorship bias: kind of like zoning for only single-family homes and yet saying "no one wants mid-rise towers/apartments as evidenced by the fact no one building them". The current rules/structure preclude any other options.
When we went from dial-up speeds to DSL/cable to fibre we were able to have all sorts new applications due to higher bandwidth. Are there classes of applications that we don't / can't have because of NAT? We're stuck with things that often need a central server (TURN/ICE/STUN) and I'd like people to have the ability to explore a more distributed/decentralized Internet.
No imagination required. P2P works fine if at least 20% to 30% have ports open inbound. 70%+ need not have open inbound ports. Where this could theoretically be a problem is if a specific sub-set of CG-NAT users were the only people seeding and downloading something. This non existent problem can be worked around using a VPN mesh. Tinc is an open source VPN that operates in user-space and while not as fast as Wireguard it can do things Wireguard could never dream of such as user space mesh routing, always discovering the shortest path. The advantage of this is keeping ambulance chasing lawyers off the P2P/VPN mesh. The only imagination required is how to keep the network semi-private. In my experience this is running a semi-private invite-only self hosted forum. In reality none of this is required for P2P however.
> No imagination required. P2P works fine if at least 20% to 30% have ports open inbound. 70%+ need not have open inbound ports. Where this could theoretically be a problem is if a specific sub-set of CG-NAT users were the only people seeding and downloading something.
"Seeding"? "Downloading"? I think applications besides BitTorrent could be invented and become popular. Even now, existing things like SIP and WebRTC would probably be much less onerous.
> This non existent problem can be worked around using a VPN mesh. Tinc is an open source VPN that operates in user-space and while not as fast as Wireguard it can do things Wireguard could never dream of such as user space mesh routing, always discovering the shortest path.
So you're introducing another layer of software because the underlying network does not have the functionality available (just like STUN/TURN/ICE had to be invented to deal with NAT).
Here's another idea: have IPv6, and if folks want to have end-to-end encrypted communications, start up an IKEv2 process (that opens a hole for its port via UPNP/PCP), and we have IPsec (which is built into most OSes anyway) encrypted communications opportunistically enabled.
> Or ... people can use the DoD/Mod and assorted other space to get their IPv4 allocations. There is a ton of unused space in IPv4. Reserved, allocated but entirely unused. Also take back some /8's from greedy companies that don't need all that space.
In our exponentially growing world that wouldn't help. By the time we ran out of Class As we were allocating a new one every month. Reclaiming all the unused addresses would barely make a dent in demand.
You have to be really special if you think a 32-bit address space can cope with the ever expanding internet. We only managed to scrape by for now because ISPs keep on putting more and more people behind CGNAT. (My country's ISPs forced the migration to CGNAT because they literally couldn't get more IPv4 blocks without spending a hefty amount)
Err... you do realize that the number of humans currently living on planet earth is twice the number of IPv4 addresses... right?
We can't all have an IPv4 address for each of our devices. We can't all even have one IPv4 address, period. But maybe they should just try not being poor, eh?
I am behind cgnat but have a native ipv6 /64 at home. I've got a great fibre connection (2G5) and everything "just works". I can host on ipv6 native machines and see them from anywhere in the world that has native ipv6 access.
The trouble is that 1) my employers do not have native ipv6 access; 2) neither does my mobile connection; and 3) really nor do a lot of my friends. Moreover, 4) if you browse a website from a native world-reachable ipv6 address, you're fingerprinted by it and it's overwhelmingly unique to you. So, it doesn't really work for hosting, and I don't get any direct benefits from it.
Instead I have a vps with a public ipv4 address and have a router that creates a wireguard tunnel to it. The reverse proxy works great over ipv6 and I am now in a position where I can forward ports and have direct connections -- albeit with hugely increased technical complexity. Ipv6 has many great ideas in it. If it's universally used it might just catch on...
> 4) if you browse a website from a native world-reachable ipv6 address, you're fingerprinted by it and it's overwhelmingly unique to you.
IPv6 privacy extensions exist & are enabled by default in most (if not all) operating systems today, which (this is my understanding; take it with a grain of salt) create what essentially are extra IPv6 addresses, used for outbound traffic, that aren't generated via your MAC address.
The main complaint I have against IPv6 is the addresses are so unwieldy. When I look at them I have the same reaction as when I look at some kind of complex scientific formula comprised of operators and symbols that are unfamiliar. It also takes extra mental effort to expand the compressed zeros and interpret what I'm viewing.
Even after reading about them many times and using them in (an albeit limited) fashion, they still just don't feel human friendly. Not like the more straightforward IPv4 addresses do. (Or even like a hypothetical "IPv5" that simply prefixes one extra octet).
Whenever I bring this up I'm told something like "Don't bother memorizing IPv6 addresses. Use DNS instead."[1]
That take completely overlooks the fact that if the numbers exist, you will inevitably wind up needing to deal with them at various points along the way. Eg. Debugging logs, sniffing network traffic, ruling out if DNS is down, etc. I'm a big fan of ergonomics to make things intuitive and reduce unnccessary cognitive overhead, and the new scheme is a regression in that regard.
If anyone has tips on how they became more fluent with IPv6 I'd love to hear.
The v6 addresses are made up of the network prefix (2001:db8:2d4f, basically an opaque string like 203.0.113.45+192.168), then the subnet ID (1, 2) and then the host ID on the network (1-3 and 1).
When you look at 2001:db8:2d4f:X::Y, it should be pretty easy to see that it's host Y on subnet X, under your prefix which is the same for your whole network. Even if it's 2001:db8:2d4f:X:YYYY:YYYY:YYYY:YYYY it's still the same thing, just with more characters.
The most common is more like /56, which is unfortunate because it means you have to deal with "2001:db8:2d4f:61XX::". It's still easy enough to read the subnet out of :6101:, :6102:, :6103: etc, but it does mean every address is longer :(
> And has the practice of generating portions of the address from your MAC address been universally (or at least mostly) abandoned?
Somewhere around mostly. Windows, OSX, and network-manager/dhcpcd/systemd-networkd on Linux all enable RFC7217 (uses a hash of your MAC and a secret value), temporary addresses (random addresses used for outbound connections) or both by default. Either of these will prevent people from seeing your MAC when you connect to them.
I'm not sure about mobile devices. I'd expect temporary addresses there, but also MAC randomization is a thing these days which would do the job too.
Notably absent from that list is Linux's in-kernel SLAAC client. Client-oriented distros often enable tempaddrs by default (or they install one of the network daemons that does it), but server-oriented distros tend not to.
This is without even getting into learning the new (old?) paradigm of "exposing" all addresses to the whole internet. I realize "NAT" is not equivalent to "firewall", but placing them at the same boundary made things simple to understand conceptually. I for one never had trouble opening/forwarding ports (and liked the control it provided over what goes in and out, especially in the days before it all just became HTTP) but I sympathize with the major headaches the NAT "workaround" caused.
NAT also solves the dynamic address issue. With GUA I need to deal with both dynamic prefix and randomised suffix that can be changed by seemingly unrelated things when opening ports to the internet.
IPv6 feels like we just can't admit to ourselves that it has been a failed transition. What would it take to come up with IPv7 which takes in the lessons of IPv6 and produces something better that we can all agree is worth transitioning to over IPv4.
> What would it take to come up with IPv7 which takes in the lessons of IPv6 and produces something better that we can all agree is worth transitioning to over IPv4.
The only lesson to learn from IPv6 deployment is that if there's a workaround available and the world isn't burning, it'll take 30 years from initial design to actual adoption. So if you went out and took 10 years to design IPv7, it'd likely take until 2070 for it to gain some adoption. This is because big network hardware is costly and has very long replacement cycles.
IPv6 was already designed as a lessons-learnt protocol from IPv4 issues. The header is greatly simplified and it's more hardware-friendly, it incorporates the required features into the protocol and leaves extensibility as an optional add-on that doesn't slow down routing packets, all the while granting an infinite address space.
> IPv6 feels like we just can't admit to ourselves that it has been a failed transition. What would it take to come up with IPv7 which takes in the lessons of IPv6 and produces something better that we can all agree is worth transitioning to over IPv4.
Per Google, quite a few countries (including the US) are at >50%:
So I'm not quite sure where "failed" enters the equation.
And what exactly would be different with IPv7? Anything that needs more address bits would have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A7" address (for "IPv7" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6.
The only place the IPv6 transition seems to be failing is in "command-and-control" corporate networks. (A majority of home/consumer/cellular users are quietly using IPv6 by default every day, per most statistics.) The lessons to be learned there don't seem to be technical but economic incentives.
Big companies believe that they have plenty of IPv4 space, especially because they've always been lax in how they read IPv4 RFCs and use IPv4 routing behind corporate firewalls. Big companies also have the most cash to buy IPv4 blocks as they go to auction. Big companies have massive firewalls and strict VPNs which also insulate them from IPv4 scarcity.
IPv4 leases don't impact enough companies' bottom lines today that they need to assess IPv6 support.
Solving those economic incentive problems would likely be a massive sociopolitical problem: you would need IANA and the RIRs to agree to inflate costs in various ways (and in the short term that might have done a lot of harm to small countries already facing IPv4 inequity and their RIRs that lost the very earliest IPv4 assignment lotteries). You'd probably need new RFCs and political enforcement to support things like "taxing" company to company IPv4 block assignments. You'd probably need collusion or regulation from the big "Cloud Providers" to enforce higher costs on IPv4-only networking.
It would take those kind of "strong handed" tactics to speed up IPv6 adoption in corporate networks. Waiting for the "invisible hand" of the "free market" can be very slow and takes patience. That's mostly what we've been seeing with IPv6 adoption: the "invisible hand" is a lot slower than some people predicted. Especially engineers that hoped technical superiority alone would be a market winner.
Whole model same as IPv4 (DHCP, NAT, ICMP, DNS, ...) just in v6. If IPv6 and IPv4 would be essentially the same from the get go, IPv4 would be a niche 20 years.
Sure everything above IPv6 have, but it took years and years of screaming to get it.
> Whole model same as IPv4 (DHCP, NAT, ICMP, DNS, ...) just in v6.
All of those things exist in IPv6.
And it is physically impossible for DNS to be the same, as you have to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A7" address (for "IPv7" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.
32 bits seemed practically infinite at the time IPv4 was created, and the whole thing started as a way for the American military-industrial-research complex to communicate with itself anyway. Why would you even want to assign addresses on your defense network to foreign adversaries?
Now that it's a commercial thing, a more equitable distribution would have, with hindsight, been a good thing.
Both IPv4 and IPv6 addresses are 'just' u_ints: one is 2^32 and the other is 2^128. The fact that we display them in a particular format (10.11.12.13; ff:ee::bb:aa) is only for human UX purposes.
Strictly speaking everything in a computer is 'just' a number represented in base-2 (binary digits: bits) that we affix certain labels to (char, int, float, struct).
> The INET6 data type is intended for storage of IPv6 addresses, as well as IPv4 addresses assuming conventional mapping of IPv4 addresses into IPv6 addresses.
Can someone pity me enough to explain how to do DNS on ipv6 while using slaac?
All I want to do is give every machine on my network a friendly hostname like storage.lan, timsPhone.lan, etc without having to run BIND (if possible), or dhcpd.
I have heard of zeroconf for ipv4, but the catch is I want this to work across several different platforms like Windows , freebsd, Linux, etc. I also don't want to use static addresses, but I feel like that's asking too much.
You are looking for mDNS which is the modern name for zeroconf/Bonjour/etc. The URL suffix is .local (storage.local, myphone.local, myprinter.local). Most modern OSes support it out of the box, but also don't advertise their names on mDNS until you ask them nicely (travel through a maze of Settings and Firewall options).
mDNS supports IPv6 just fine/works on IPv6 only LANs.
Here comes the flood of IPv6 evangelists who thinks everyone is confused about NAT and firewalls. I don't know where they get their talking points, but they descend onto these threads with their sanctimony. "Oh, you must be confused about how NAT works, allow me to educate you." It's very tiresome.
Pretending that 0-9A-Z is somehow comparable to 行 or ∮ is quite daring, I will give you that.
And once again: any anti-IPv6 people could have already learned proper IPv6, if they directed 10% of their efforts (spent on bashing the IPv6 address format) to learn IPv6 instead.
- In the grand scheme of things, the IP address itself is of very little importance. It was given undue attention because of how IPv4 was inherently limited in address space.
- If you simply needed a way to name your machines, what are you doing not using the (m)DNS? You know, services literally with the word "Name" inside their name?
>And once again: any anti-IPv6 people could have already learned proper IPv6, if they directed 10% of their efforts (spent on bashing the IPv6 address format) to learn IPv6 instead.
I spent some good time trying to learn IPv6. I was pretty open to it, but it was just awful. There were parts of it that were bad due to other reasons -- my router, my ISP. But it was unworkable, produced a number of problems and provided me no benefit.
I learn new things all the time. I learn things I like, learn about things I dislike. I find it really rude that people suggest "I just don't want to learn things."
If bad routers etc. makes you think IPv6 is bad... then man, I think for me IPv4 is a mountain of shite.
But my comment was not directed at you, more so towards those people who looked at IPv6 very superficially (i.e. the ipV6 AddRESs iS UgLY!!1! people), so ¯\_(ツ)_/¯
You're putting words in my mouth, genocide implies murdering existing people to reduce the population, not developing policies that would slow down the population growth and/or fix the issues with the country.
I find it fascinating how these key technologies handle upgrades and breaking changes. For example, Python eschewed breaking changes through 2.7.x but the dam has burst since 3.0 and every point release (it seems?) makes breaking changes, sometimes reversing itself (eg the whole s/u string prefix thing).
Many here will be familiar with the second system effect [1]. Usually people want to avoid making breaking changes but once they do, they can go a little nuts. My personal opinion is only major versions should make breaking changes and a lot of thought should go into making them as painless as possible.
IPv6 is fascinating for these reasons but also that it's a product of its time in two main ways:
1. It doesn't do anything about roaming because that wasn't an issue in the 1990s but it certainly is now;
2. A 64 bit address space would've basically been infinite addresses but instead they went with 128 bit addresses (rolling in ports) but then giving individual users a /64 address range. For some reason people deny it now or simply weren't aware but that too is a historical artifact because it was intended to put a 48 bit MAC address into that space but later we realized that's a huge PII and tracking issue; and
3. History has shown that upgrading network backbone hardware (in particular) is incredibly difficult through a process that's been described as "ossification", which is a nice description. Basically, network relays and routers wanted to avoid security issues and decided to discard things they didn't understand.
That's interesting because it violates Postel's Law [2], which basically says be liberal in what you accept and conservative in what you send.
But this shows up in all sorts of interesting ways, like it's practically impossible to reliably use MTUs larger than about 1536. When IPv4 was designed, that wasn't an issue. With 1-100G+ networks it is. There are RFCs about using large MTUs but you're dependent on backbone hardware you have no control over.
Even Linux struggles with this, to the point where you need to do some configuration for high-bandwidth networks (eg RPS [3]). Just handling all those interrupts presents a bunch of problems beyond the original scope. And again, it's hard to fix through no fault of Linux's.
I'm old enough to remember the talk about us running out of IPv4 addresses back in the 1990s. It's been interesting to watch how this has consistently been kicked down the street (eg cgNAT).
What is funny though is large companies (eg Facebook) actualy ran out of internal addresses on a 10/8 network and there's no good solution for that (with IPv4 at least).
> 3. History has shown that upgrading network backbone hardware (in particular) is incredibly difficult through a process that's been described as "ossification", which is a nice description. Basically, network relays and routers wanted to avoid security issues and decided to discard things they didn't understand.
What makes you suggest that it's backbone hardware that is the problem? It's largely enterprise customers and tier 3 providers that don't really do IPv6 afaics.
>3. History has shown that upgrading network backbone hardware (in particular) is incredibly difficult through a process that's been described as "ossification", which is a nice description. Basically, network relays and routers wanted to avoid security issues and decided to discard things they didn't understand.
Would say the opposite is true. Core routers were the first to enable V6 support in any network as they would need support it for anything else to even use it. They got regularly replaced as bandwidth needs keeps rising as well.
Plenty of isps advertise ipv6 but haven't managed to give it to customers yet.
Interrupts are hardly a problem with any nics of the last decade really.
If IPv6 was going to be successful, it would have been successful years ago. It seems, people are just more comfortable with layers of NAT than native IPv6 everywhere. I'd guess that it should have been more backwards compatible. Similar to UTF-8 and ASCII.
My Verizon connection has a CGNAT IPv4 and a publicly routable IPv6 address. It's at least partly a success, if you're using a cell phone on Verizon in the US.
If IPv6 doesn't dominate in the next, let's say, 10 years, they might publish the IPv8 which will be an 64bit space, backwards compatible with IPv4. It will be the only case where a newer version of software comes back closer to an older one.
How do you plan to let IPv4 (32 bit address space) actually address and communicate with an IPv8 (64 bit address space) host? You don't have enough bits to identify the v8 host.
Something like 1:2:3:4:a:b:c:d where the most significant 32bits are a valid IPv4. The kernel figures out and keep all others the same (NAT etc). We extend the address space, not invent a new stack. The IPv6 critics shout out that this would be a viable solution.
Okay, so you've figured out how to make v4 addressable from v8. Good job. That lets v8 hosts address a v4 host via a v8 address.
How are you going to make v8 addressable from v4? Because you need to do this too for communication to work.
Also, you've made v4 addressable from v8, and you're about to explain how you make v8 addressable from v4... but that's just addressing, i.e. identifying the right host. How are you going to actually send packets from v8 to v4, and also from v4 to v8?
> The IPv6 critics shout out that this would be a viable solution.
But they never bother to understand enough of the problem to contribute anything useful. Either they can't come up with something that works, or they come up with something that they didn't realize v6 already did.
> There are countless threads online on forums like Hacker News, Reddit where people who never really got comfortable with idea of IPv6
It’s clumsier than ipv4. It’s unnecessary since NAT was invented. In practice IPv6 requires dual stack, which means twice as many firewalls, names and routes to manage — so 4x the debugging because you have 2 dimensions that can either be working or failing. Addresses are too long to remember, too clumsy to write, and after 30 years still don’t have consistent representation (how many colons and brackets?).
Look, IPv6 has some benefits, but until the usability is fixed, it will be another 30 years before it’s close to 95% adoption.
> It’s clumsier than ipv4. It’s unnecessary since NAT was invented.
This is a privileged view of someone whose ISP has enough money (or was around early enough) to get enough IPv4 addresses to assign one to every customer's WAN interface. Not everyone is so lucky.
A lot of folks get non-publicly-routable 100.64.0.0/10[1] on their WAN interface with no way to do hole punching because they're behind CG-NAT.
> so ipv6 is now a social justice issue? I'll send you the $2 a month for a elastic IP .
And the billion people in India? The billion in China? The billion on the continent of Africa? And even in the US:
> Our [American Indian] tribal network started out IPv6, but soon learned we had to somehow support IPv4 only traffic. It took almost 11 months in order to get a small amount of IPv4 addresses allocated for this use. In fact there were only enough addresses to cover maybe 1% of population. So we were forced to create a very expensive proxy/translation server in order to support this traffic.
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
PSINet/Cogent got 38/8 in 1994: did they invent it? Ford got 19/8 in 1995: how about them?
How many places and people/companies didn't have the ability to go to a RIR in the 1990s or 2000s and get an allocation because their local infrastructure (power, telecom) wasn't developed at the time? So because they got computers, fibre, smartphones later they're SOL?
Can I have it on my home network connection for $2/month? I could do VPS+VPN, but that's another company to deal with, another bill to pay, and several more things to break. And more latency too.
Why would you be typing of remembering ipv6 addresses? Representation has always been consistent, if you learn the rules, like how 1337::1/64 is a valid address.
The brackets are only needed for URLs, scp, and a few other things, due to the fact that ports are specified with colons. Usually you don't see them in a CIDR.
Why are you casting to sockaddr_in/6? The whole point of that system is that you can just pass around the sockaddr* without even needing to have a definition for sockaddr_in or sockaddr_in6. All of the socket API functions accept sockaddr*, and if you need to get the IP or port out then you use getnameinfo(), which also takes sockaddr*. There should be little reason to ever cast to either of those types in normal use. (I can think of one or two cases where you might, but they're not common.)
Having to deal with the separate socklen_t is mildly annoying, but you can just make a little struct that holds both.
Not on all OSes.
And it's not all good to have one less socket, there are still issues with people not expecting v4 traffic on a v6-capable socket, like described here:
For everyone getting into the details about how all of this should work please look at RFC7084: Basic Requirements for IPv6 Customer Edge Routers
https://www.rfc-editor.org/rfc/rfc7084
It describes in detail what a home router needs to be doing to make all of this work seamlessly.
Things work so well that half the world has working IPv6 already.
Openwrt pretty much implements all of this out of the box.
If you are struggling with IPv6 I recommend reading up on where it is at today and figuring out how whatever makes your network special can be done using IPv6 with no fuss.
Personally I have moved several times changing ISPs in the process and my IPv6 setup involving multiple LANs on my home network has just continued to work. IPv6 renumbering events just work seamlessly and completely automatically.
Historically the only practical hold up to IPv6 adoption has been the ISPs not rolling it out to their customers.
And I know the homenet WG has concluded but I found RFC 7368 IPv6 Home Networking Architecture Principles[1] interesting as well, including its discussion of reachability and RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service.[2] IPv6 still occasionally seem more flaky than IPv4 with some set ups though.
[1] https://datatracker.ietf.org/doc/html/rfc7368.html#section-3...
[2] https://datatracker.ietf.org/doc/html/rfc6092
> Historically the only practical hold up to IPv6 adoption has been the ISPs not rolling it out to their customers.
And corporate networks: in Google's stats you'll see IPv6 usage jumps on weekends as people do stuff not using their work computer.
> If you are struggling with IPv6 I recommend reading up on where it is at today and figuring out how whatever makes your network special can be done using IPv6 with no fuss.
> ...
> Historically the only practical hold up to IPv6 adoption has been the ISPs not rolling it out to their customers.
Yep, that's where I am. Frontier FTTH, IPv4 only. Because....I have no idea why. Because Frontier sucks, basically? They have at least started their rollout:
https://stats.labs.apnic.net/ipv6/AS5650?c=US&p=1&v=1&w=30&x...
...but it's going to be slow going. Don't get me wrong, I'd rather cut off my fingers than go back to Comcast, but at least Comcast gave me a /56.
I don't understand why people are so negative about IPv6. I have done essentially zero home networking work and I just ran this successfully. It just works!
``` > ping6 google.com PING6(56=40+8+8 bytes) 2605:59c0:236f:3a08:7883:9d04:c26d:5fa1 --> 2607:f8b0:4005:806::200e 16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=0 hlim=117 time=22.262 ms 16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=1 hlim=117 time=26.124 ms 16 bytes from 2607:f8b0:4005:806::200e, icmp_seq=2 hlim=117 time=26.807 ms ^C --- google.com ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 22.262/25.064/26.807/2.001 ms ```
> I don't understand why people are so negative about IPv6. [...] It just works!
Networking is a lot more than being able to ping a single host.
As a concrete counter-example, IPv6 routinely broke for me when I was using pfSense as a router. Why? Because pfSense, with no way of disabling this behavior, published its public IP as the DNS server for internal clients.
So each time I got a new prefix from my ISP, which happens about once a week or more often, machines stopped being able to perform DNS lookups for hours or until I rebooted them.
And, if I had bothered configuring IPv6 firewall rules, those would have had to be reconfigured manually with the new prefix. I understand this is mostly fixed in pfSense recently, but this was the case for many, many years.
Another counter-example is that Android only supports SLAAC, and SLAAC only supports providing a few key infrastructure details like router and DNS. If you want to tell the Android client something else, like NTP server, you're outta luck. Also, if Android successfully gets an IPv6 address via SLAAC, it requires the DNS server IP to also be an IPv6 address. So your internal DNS server must then also serve on IPv6. If that wasn't the case, it would just silently use Google's own DNS servers, breaking any local configuration you had.
Another point is that a lot of us tried using IPv6 decades ago, and so we still have scars from that time. IPv6 today is a lot better, but I still have a lot of IPv6 frustration associated with it from 15-20 years ago.
> And, if I had bothered configuring IPv6 firewall rules, those would have had to be reconfigured manually with the new prefix. I understand this is mostly fixed in pfSense recently, but this was the case for many, many years.
Why would you have to reconfigure your firewall rules when you're getting a new IPv6 prefix?
> Why would you have to reconfigure your firewall rules when you're getting a new IPv6 prefix?
Because the IP address of the target changes when you get a new prefix.
There's some discussion in this[1] old pfSense ticket.
With IPv4 you typically do address translation (NAT) and so the internal target address is not tied to the global address.
[1]: https://redmine.pfsense.org/issues/6626
My consumer router uses iptables under the hood, so it accepts a mask in the firewall rule (so e.g. I can do ::0123:4567:89ab:cdef/::ff:ffff:ffff:ffff:ffff as a target, and when my /56 changes, the rules Just Work™)
It seems iptables has been ahead there.
But I think it further strengthens my case, software support for IPv6 has been quite spotty over the years, which combined with the less-than ideal deployments out there has made things frustrating for many users over the past couple of decades.
> As a concrete counter-example, IPv6 routinely broke for me when I was using pfSense as a router. Why? Because pfSense, does really bad things.
I mean, I have a router that is trash with IP4. Therefore IP4 is trash!
Please don't put words in my mouth. I did not say "Because pfSense, does really bad things."
How pfSense works is fairly reasonable if every IPv6 deployment had been as the original designers intended, ie you have a static prefix.
It's just that the way IPv6 ended up getting deployed in practice was often not aligned with that original vision. And that has been a large source of IPv6 frustration.
There's a few things here that are a bit iffy tbh!
I can't see why an ISP is dynamically changing the IPv6 addressing for a client, but if that's what is going on, then v6 NPT is your friend (RFC6296 - https://datatracker.ietf.org/doc/html/rfc6296).
But pfsense's behaviour is a bit iffy too, unless when you say 'public IP', you mean the IPv6 address being used on the pfsense facing the clients? (I'm assuming it's using DHCPv6 prefix delegation, and the delegation is being changed? And potentially the uplink subnet as well).
opnsense can use the delegated prefix for DHCPv6, it then automatically becomes the “LAN net” firewall alias and you can refer to it in a firewall rule I believe. I assume it’s the same for pfsense and I suspect they are not the only ones.
It's a legal requirement in Europe for privacy. A long term static address is a personal identifier.
How could this be a legal requirement and at the same time you can purchase static IPs as a paid option from ISPs, like I did?
Any vague source for that?
Asking as a European who did not have his IPv4 address changed for months or even years. Or is it IPv6 specific? But I cannot see why.
Does the mailman come around and change house numbers and street names every month, too?
> v6 NPT is your friend
So NAT is the one true solution after all.. /s
> unless when you say 'public IP', you mean the IPv6 address being used on the pfsense facing the clients?
Well, that's kinda the thing, pfSense seems to assume global means it's also the IP facing the local clients. I couldn't get pfSense to advertise its ULA as the DNS server for example. But if you have a static prefix, that's not a bad assumption. And a static prefix is what the IPv6 designers envisioned.
> I'm assuming it's using DHCPv6 prefix delegation, and the delegation is being changed?
ISP indeed uses DHCPv6 prefix delegation. The prefix I get can change "randomly". It always changes when my router or modem reboots, but other times too (perhaps when their equipment reboots).
I should note that after getting very frustrated with pfSense, I threw it away a few years ago and switched to OpenWRT which has worked much, much better when it comes to IPv6.
That's literally impossible, to hear some people tell it. "And also, look how hard it'd be to memorize that address", say the people who remember like 2 IPv4 addresses, one of them being 127.0.0.1.
Tailscale, perhaps ironically in this context, has shown me the value of not caring about an IP address.
I used to. When I had a home network I'd carefully assign `10.52.1.x` where `x` was the periodic number corresponding to the machine name! (I write from `lutetium`.)
Now, with Tailscale's magic DNS – `lutetium` being all I need – why on Earth would I give a crap about an IP address? I've gone from being obsessed to truly not caring at all.
So, give me IPv6. Auto-assign everything! All I want is a name.
Hah, I kinda love your naming and numbering convention!
But yeah. On my own LAN, everything is DHCP for IPv4 and SLAAC for v6. Everything uses mDNS and I connect to everything by name, not address. I can only remember the static IP of one of the servers; the rest are purely names.
It's akin to remembering the phone numbers. Even 20 years ago I had like 10-20 of most important ones memorized despite some of them not used often ie once in a years. Nowadays I have 'me myself' in the Contacts because I can't remember it despite using it for 5+ years nor I care.
I remember like 10 different IPv4 addresses, 6 of which are DNS servers where each octet is a single number, 1 is my router, 1 is my home network switch, 1 is my home server and the last one localhost.
The main thing all those have in common is they are either something I frequently use (all mentioned local IPs) or just stupid easy to remember (DNS servers), neither of which isn't possible for IPv6.
From memory isn't localhost for IPv6 not shorter than for IPv4? The answer is yes, it is ::1 and I was thinking of the Multicast and Link-local address prefixes which are ff00:: and fe80:: respectively.
Telling people to use ULA subnet fddd:: with dhcpv6 is my way.
fddd::7 is easier to type than 10.0.0.7
"ten oh oh 7" (how I'd say it or remember it) still seems simpler than "eff dee dee dee colon colon 7". While with ipv4 the dots can be assumed for pauses, v6 doesn't put colons as often, also I could easily see myself forgetting the amount of "d"s. I don't wanna seem too anti-v6, though, I am in favor of everyone adopting the more modern thing.
edit: Well, you said easier to type. I guess I probably agree with that.
There is also the fact that an IPv6 IP has a maximum and minimum number of characters and separators, but not a set one, so the length of any given address is variable.
Instead of being able to run a groove in my head mentally, and read with any sort of rhythm, I have to read them like binary bytes. Every address feels like a foreign phone number where your normal rhythm doesn't fit, but it never gets better.
Perhaps, IMO, the greatest and only sin of IPv6. That and using fucking colons.
Dots weren't an option, because then the syntax would overlap with DNS hostnames. "2001.db8.c.d.e.f.g.ca" is a valid host under the .ca TLD.
one of those addresses requires two hands and hitting the shift key, the other is easily done one-handed.
You're looking for one of these: https://ipv6buddy.com/
When people are managing 20 devices on a network, they access everything by IP address directly and struggle with constant DNS issues.
Introducing a more complex system without easing any of the cognitive load and making fun of it is just cruel at this moment.
Users need a simpler way to connect to their devices, and what tailscale did with magic dns shows that users don’t even care about IPv4 they just want to connect to their devices with something simple they can remember.
I have 68 devices on the line at this moment. I just checked. I remember exactly one of their IPs and that’s just one that stuck in my head. I never connect to it by address.
I agree with the sibling comment: crummy CPE is crummy CPE. This is a solvable problem, but people end up with junky routers and it causes them anguish.
Weirdly this might be a CPE problem, e.g. crappy ISP routers.
Put in something more interesting, e.g. OpenWRT, or there are proprietary options too, that provides simple & reliable local LAN DNS, then the problem just goes away.
Reading the comments, it looks like some people dismiss IPv6 just because they need to sit down and learn a couple of new things.
Yeah, it's always the same with IPv6 discussions. The main points being:
If someone is still using the “remembering IP addresses” argument in 2026 (or at any point in the 21st century), I question their technical competence in configuring a network correctly.
It also seems to be a learning curve thing because IPv6 addresses have their own versions of memorable mnemonics. If you are in a LAN space manually configuring LAN addresses, you just need to remember one of the local address (ULA) prefixes like fc00 and then start numbering your devices as ::1 and incrementing (fc::1, fc::2, fc::3, etc). But also in LAN spaces you could just rely on mDNS (devicename.local), it's gotten quite good in most OSes today.
If you need to remember random WAN IPv6 addresses without being able to use DNS or at least a hosts file you've probably got a bunch of other more pressing problems.
I dismiss IPv6 because my ISP doesn't support it.
I dismiss ISPs that don't support IPv6.
> I dismiss ISPs that don't support IPv6.
Hey, how awesome you live in an area where you have a choice of ISPs and can dismiss one that doesn't meet your spec, rather than having to simply shut up and eat what you're served!
I should dismiss my ISP that's worked for something like 20 years, works now, and will in all likelyhood still be working in 20 years (baring M&A nonsense or the apocalypse)?
Sorry, IPv6 is absolutely not the hill I'm going to die on.
If it doesn't support IPv6 it doesn't work.
My experience, indeed reality, says different for all values of "work" that matter to me.
My point is it's your vote against billions of others. My guess is "but what about kjs3's ISP" isn't a bullet point on the rollout list.
I'm not signing up for a new contract with a different company to get the same speeds at higher price and IPv6 that is pretty much useless as many major websites don't even work with it. It will take at least another 15 years before I will consider using IPv6 at home.
Not only that, but not everyone will even have any other choices. The last apartment I was in literally only had one ISP option; I literally would check every six months or so with other ISPs that were in the area because of the fairly frequent outages, and every time they all said that they couldn't offer me service at my address. (This didn't stop them from filling my mailbox with spam all the time though of course). This was in New York (the city), so it's not like there weren't half a dozen other ISPs operating within a few blocks of me.
I can't take seriously the claim that someone would literally refuse to move into an apartment purely on the basis of not having IPv6 support. Bad internet in general? Sure, that's plausible; I work from home, and like I said, the outages were annoying, and if there were no decent speed options my (now) wife and I might have ruled it out? But literally just the lack of IPv6? That's an absurd reason to pick another place to live entirely.
any idea why no one else could service the building? Ive usually had option of verizon or optimum when ive rented, though my experience has been queens and long island
Optimum was the one option we had. This was in Brooklyn (Park Slope specifically, so pretty high density). My vague understanding is that Verizon wasn't hooked up to the building, but I have no idea why that would be. I only wish they managed to recognize that when sending out advertisements.
Ah okay, i wonder if the dilemma was on verizon side or building owner side
if verizon charges to connect the building and couldnt make an agreement with the owner. or maybe owner has non financial reasons (laziness & indifference) for denying them. or maybe some operational reason verzion wasnt confident in ability to install
https://www.allconnect.com/blog/fcc-prohibits-exclusive-agre...
If I'm reading correctly, it only prevented new agreements going forward rather than penalizing the old ones, and of course the fact that the FCC's party line split will tilt in favor of the current president at some point every turn means that this might not even be policy anymore (and that's before even taking into account that the current administration doesn't exactly follow precedents around administrative agencies).
Imagine being able to connect two computers over the internet using sockets. WebRTC is a marvel, but I miss the whimsical days of running something on a port at home and connecting to it without thinking about NAT.
Imagine being able to make a voice call to a friend without paying for a middle-man to proxy the traffic completely unnecessarily.
You can still do this! It’s just very hard and needs hole punching and maybe a stun server
If UTF-8 represents the triumph of a design prioritizing backwards compatibility with an existing standard (ASCII) to facilitate a transition, then IPv6 is the cautionary tale of a design which could have made the transition simpler but did not.
IPv6 cannot be backward-compatible with IPv4 in the way UTF-8 is with ASCII. Any argument built on that comparison reflects a misunderstanding of the protocols and leads to flawed conclusions.
Why not? Sincere question. As a very superficial idea, if we go back to the drawing board, for example we could decide our new cool concept of address to be an IPv4 + an hex suffix, maybe at the expense of not having a humongous address space.
So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version.
I just made this up, so I'm sure that a couple years of deep thought by a council of scientists and engineers could come up with something even better.
The header of an IPv4 packet has the source and destination addresses, both as 32-bit values. These fields are adjacent, and there's other stuff next to them. If you appended more bytes to the source address, routers would think that those new bytes are the destination address. This would not be backward compatible.
Interestingly, what you're describing really is similar to how many languages represent an IPv4 address internally. Go embeds IPv4 addresses inside of IPv6 structs as ::ffff:{IPv4 address}: https://cs.opensource.google/go/go/+/go1.26.2:src/net/ip.go;...
That's not a language-specific thing, but is actually part of the IPv6 RFCs as IPv4-mapped IPv6 addresses: [1], [2]
This is super useful because (at least on Linux) IPv6 sockets per default are dual-stack and bind to both IPv6 and IPv6 (except if you are using the IPV6_V6ONLY sockopt or a sysctl), so you don't need to open and handle IPv4 and IPv6 sockets separately (well, maybe some extra code for logging/checking properly with the actual IPv4 address).
That is also documented in ipv6(7):
[0]: https://datatracker.ietf.org/doc/html/rfc5156#section-2.2 [1]: https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5....Programmers really like to focus on things like:
- How they would format the display of the bits
- Where in the bit pattern IPv4 mapped addresses should go
- Coming up with some variation of NAT64, NAT464, or similar concepts to communicate between/over IPv4 and IPv6 networks
- Blaming the optional extensions/features of IPv6 for being too complex and then inventing something which has 90% of the same parts which are actually required to use
It's even easy to get distracted in a world of "what you can do with IPv6" instead of just using the basics. The things that actually make IPv6 adoption slow are:
- A change in the size of the address field which requires special changes and configuration in network gear, operating systems, and apps because it's not just one protocol to think about the transport of again until the migration is 100% complete.
If IPv4 were more painfully broken then the switch would have happened long ago. People just don't care to move fast because they don't need to. IPv6 itself is fine though and, ironically, it's the ones getting the most value out of the optional extensions (such as cellular providers) who actually started to drive IPv6 adoption.
How would you get someone that only knows about IPv4 addresses like 10.20.30.40 to send a packet to someone with an address 10.20.30.40:fa:be:4c:9d?
How do you squeeze that in IPv4 packet? Especially in a way that won't get mangled by random ossified devices in between?
In IPv4 you only need to transmit IPv4 addresses. If the "cannot be" in parent post is referring to the exact byte disposition in packets, then I go the other way around to claim that I agree. Because the only way that a UTF8 character can pretend to be ASCII is because ASCII didn't use all of the 8 bits in a byte to begin with. Only way to have something similar in this case, would be that IPv4 didn't use all of the allocated bits for addresses... Which is not the case.
What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it. But I agree, that the actual packet header layouts would need to look at least a bit different.
> What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it.
Like:
> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]
* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...
They did that. Problem is that an ipv4 only host can't talk to ipv6. Adding more bits to ipv4 creates a new protocol just like ipv6 and has the same transition issues.
https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5....
& the following section for the follow-up embedding.
The protocol field in the ipv4 header seems like a reasonable choice. A value would be associated for ipv6 and if that value is chosen then additional header data follows the ipv4 header.
Perhaps you could use 41, the value already associated with doing this.
(What's up with people constantly suggesting that v6 should do things that it already does?)
That's similar to, but not exactly what we were discussing. In particular 6in4 has a full ipv6 header after the ipv4 header, but here the suggestion was instead that supplementary infomation would follow. For example, the most significant address bits could be stored in the ipv4 header and the least significant ones in the new part.
That's not meaningfully different. It would just amount to a slightly less redundant representation of the same data -- the steps needed to deploy it would be the same, and you'd still have all the same issues of v4 hosts not understanding your format.
Not really reasonable. That would 1) Make routing inefficient because routers have parse an additional, non-adjacent, non-contiguous header to get the source and destination addresses. 2) Break compatibility because there would exist "routers" that do not understand ipv6 headers. They receive your ipv4 with v6 packet and send it somewhere else.
The result is basically the same situation we are in today, except much more hacky. You'd still have to do a bunch of upgrades.
> So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version.
Like
> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]
* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...
Or:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
* https://en.wikipedia.org/wiki/6to4
So you have to ship new code to every 'network element' to support your "IPv4+" plan. Just like with IPv6.
So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to:
* update the IP stack (like with IPv6)
* tell applications about new DNS records (like IPv6)
* set up translation layers for legacy-only code to reach extended-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.
Deploying the new "IPv4+" code will take time, there will partial deployment of IPv4+ is no different than having partial deployment of IPv6: you have islands of it and have to fall back to the 'legacy' IPv4-plain protocol when the new protocol fails to connect:
* https://en.wikipedia.org/wiki/Happy_Eyeballs
"Just adding more bits" means updating a whole bunch of code (routers, firewalls, DNS, APIs, userland, etc) to handle the new data structures. There is no "just": it's the same work for IPv6 as with any other idea.
(This idea of "just add more addresses" comes up in every discussion of IPv6, and people do not bother thinking about what needs to change to "just" do it.)
> If IPv4 were more painfully broken then the switch would have happened long ago.
IPv4 is very painful for people not in the US or Western Europe that (a) were now there early enough to get in on the IPv4 address land rush, or (b) don't have enough money to buy as many IPv4 addresses as they need (assuming someone wants to sell them).
So a lot of areas of the world have switched, it's just that you're perhaps in a privileged demographic and are blind to it.
> IPv4 is very painful for people not in the US or Western Europe that (a) were now there early enough to get in on the IPv4 address land rush, or (b) don't have enough money to buy as many IPv4 addresses as they need (assuming someone wants to sell them).
The lack of pain is not really about the US & Western Europe have plenty of addresses or something of that nature, it's that alternative answers such as NAT and CG-NAT (i.e. double NAT where the carrier uses non-public ranges for the consumer connections) deployments are still growing faster in those regions than IPv6 adoption when excluding cellular networks (they've been pretty good about adopting IPv6 and are where most of the IPv6 traffic in those regions comes from).
I think your summary is really great. One of the better refutations I've seen about the "what about v4 but longer??" question.
However, I think people do get tripped up by the paradigm shift from DHCP -> SLAAC. That's not something that is an inevitable consequence of increasing address size. And compared to other details (e.g. the switch to multicasting, NDP, etc.), it's a change that's very visible to all operators and really changes how things work at a conceptual level.
The real friction with SLAAC was that certain people (particularly some at Google) tried to force it as the only option on users, not that IPv6 ever forced it as the only option. The same kind of thing would likely occur with any new IP version rolling out.
For comparison IPv4 had:
And for IPv6: Some of these have had subsequent minor updates, e.g. DHCP was updated in 1997 and so on.SLAAC isn't something that is an inevitable consequence of increasing address size, it's something that is a useful advantage of increasing address size. Almost no one had big enough blocks in IPv4 where "just choose a random address and as long as no else seems to be currently claiming it it is yours" was a viable strategy for assigning an address.
There are some nice benefits of SLAAC over DHCP such as modest privacy: if device addresses are randomized they become harder to guess/scan; if there's not a central server with a registration list of every device even more so (the first S, Stateless). That's a great potential win for general consumers and a far better privacy strategy than NAT44 accidental (and somewhat broken) privacy screening. It's at odds with corporate device management strategies where top-down assignment "needs to be the rule" and device privacy is potentially a risk, but that doesn't make SLAAC a bad idea as it just increases the obvious realization that consumer needs and big corporate needs are both very different styles of sub-networks of the internet and they are conflicting a bit. (Also those conflicting interests are why consumer equipment is leading the vanguard to IPv6 and corporate equipment is languishing behind in command-and-control IPv4 enclaves.)
DHCPv6 now exists and every OS except Android supports it.
> except Android
That alone is significant.
Furthermore, DHCPv6 holds you back from various desirable things like privacy addresses and (arguably even more importantly) IPv6 Mostly.
> Furthermore, DHCPv6 holds you back from various desirable things like privacy addresses and (arguably even more importantly) IPv6 Mostly.
Why would DHCPv6 hold back privacy addresses? Can't DHCPv6 servers generate random host address bits and assign them in DHCP Offer packets? Couldn't clients generate random addresses and put them in Request packets?
See perhaps OPTION_IA_TA (Temporary Address):
* https://datatracker.ietf.org/doc/html/rfc8415#section-21.5
* https://en.wikipedia.org/wiki/DHCPv6#Option_Codes
* https://datatracker.ietf.org/doc/html/rfc7721#section-4.7How does DHCPv6 hold back IPv6-mostly? First, most clients will send out a DHCPv4 request in case IPv4 is the only option, in which case IPv6-mostly can be signalled:
* https://datatracker.ietf.org/doc/html/rfc8925
And hosts would also have to send out an IPv6 RS, and the RA can signal IPv6-mostly:
* https://datatracker.ietf.org/doc/html/rfc8781
* https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-6mops...
> See perhaps OPTION_IA_TA (Temporary Address):
I was unaware of this, so thanks. Sounds like it addresses (pun intended) my concern.
> How does DHCPv6 hold back IPv6-mostly? First, most clients will send out a DHCPv4 request in case IPv4 is the only option, in which case IPv6-mostly can be signalled
It's not the signalling that's the problem--it's the configuration of the CLAT which requires SLAAC, afaiu. This is in fact the subject of the latest IPv6 Buzz podcast episode: https://packetpushers.net/podcasts/ipv6-buzz/ipb197-slaac-an...
> It's not the signalling that's the problem--it's the configuration of the CLAT which requires SLAAC, afaiu.
This operational difficulty has been recognized and alternatives are being put forward:
* https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-clato...
Yep. Translation technologies like NAT64 and company basically as good a job as can be hoped for. And they're quite good nowadays!
But to stick with the ASCII->UTF-8 comparison: how would you have done the transition if you had to stay within ASCII's size of 7 bits?
https://en.wikipedia.org/wiki/UTF-7 exists, but was rarely used.
UTF-8 is convenient because ASCII has a spare bit, but UTF-8 is fundamentally possible because ASCII is variable-length. IPv4 is not variable-length.
> IPv4 is not variable-length.
I get the impression that this fact is fundamentally lost on a lot of the people who want a "compatible" IPv6. Like, their mental model does not distinguish between how we as humans write down an IPv4 address in text and how that address is represented in the packet.
So they think "let's just add a couple more dots and numerals and keep everything else the same"
I think you’re right. Honestly, my impression is that a lot of people imagine it like a string field, and others more like a rich text field, analogous to “can’t we just use a smaller font?”
> https://en.wikipedia.org/wiki/UTF-7 exists, but was rarely used.
UTF-7 was possible because there was an out-of-band mechanism to signal its use, "Content-Type: text/plain; charset=UTF-7":
* https://datatracker.ietf.org/doc/html/rfc2152
What's the OOB signalling in IP packet transmission between two random nodes on the Internet.
The first thing in the IP header is the version number.
> The first thing in the IP header is the version number.
So you just change the version number… like was done with IPv6?
How would this be any different: all hosts, firewalls, routers, etc, would have to be updated… like with IPv6. So would all application code to handle (e.g.) connection logging… like with IPv6.
I was addressing the narrow claim that you cannot distinguish ASCII from UTF-7. You can distinguish IPv4 from IPv6 by looking at the version field (and I forgot to mention the L2 protocol field is out of band from IP's perspective). Obviously if the receiver doesn't support UTF-7 or IPv6 then it won't be understood. Forward compatibility isn't possible in this case.
Weirdly, the version field is actually irrelevant. You can't determine the type of a packet by looking at its first byte; you must look at the EtherType header in the Ethernet frame, or whatever equivalent your L2 protocol uses. It's redundant, possibly even to the point of being a mistake.
I mean, yes, in practice you can peek at the first byte if you know you're looking at an IP packet, but down that route lies expensive datacenter switches that can't switch packets sent to a destination MAC that starts with a 04 or 06 (looking at you, Cisco and Brocade: https://seclists.org/nanog/2016/Dec/29).
Right, the variable-length thing was my point. That's fine when you're dealing with byte slices that you scan through incrementally. But it's not fine for packets and OS data structures that had their lengths fixed at 32 bits.
Wait, why couldn't it?
Just split the address into two 32-bit chunks (call the top word the "pool", bottom word "address") and assign the full IPV4 range to pool 0x00000000. Done.
Well for starters, IPv6 has 128 bit addrs.
But then think about what the routing tables would look like, how would an IPv4-only host find an IPv6 host not in pool 0? You'd be reinventing NAT, but in a less-structured context than how NAT works today. There's more issues to it too.
If it was really that simple they would have done exactly that. "Just adding more bits to IPv4" just isn't possible to do backwards-compatibly. IPv6 is the closest you can get to that while also dealing with the complexity that arises with longer addresses.
>how would an IPv4-only host find an IPv6 host not in pool 0?
Ah.
Until you upgrade every router between 2 hosts so that it understands the IPv4b addressing scheme, those 2 hosts can't talk. And if you're going to upgrade them all anyway, then might as well do it right.
In what world does is such a protocol any more *”””compatible”””* with IPv4 than IPv6 already is? It is a different header after all.
That doesn't change anything - until everyone adopts the new chunk nobody can use it (even one windows XP machine that you don't personally care about is enough to still kill it today). IPv6 is better because at least it can work side by side by IPv6.
[dead]
This recent article begs to differ: https://news.ycombinator.com/item?id=47352236
Come on... that's the top comment on the thread you shared.
https://news.ycombinator.com/item?id=47355046
This article that "begs to differ" is inventing IPv6 all over again. It just refuses to call itself so.
I quote from the top comment:
>So you have to ship new code to every 'network element' to support IPv4x. Just like with IPv6.
and
>So you have to update DNS to create new resource record types [...] Just like with IPv6.
and
>You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6.
The key difference, you don't do dual stack, you can incrementally roll it out and get tangible relief, unlike IPv6.
The point is less about the technology proposed, but the point that there could be an interoperable version of a next generation IP and IPv4.
IPv6 did the braindead thing and completely threw out the idea of transition and interoperability for a clean slate. We're paying for it many decades later.
Also, rather than regurgitate a comment, perhaps you should read the article, because that comment misunderstands what is being proposed and thus completely missing the point.
Why are you still trying to claim this? v6 has transition methods and ways to interoperate coming out of its wazoo. It does pretty much everything you can do to work with v4. Nobody threw out the idea of transitioning.
> but the point that there could be an interoperable version of a next generation IP and IPv4
Yes, it's IPv6. The thing you linked basically took one of the interoperability methods of v6 and described it in weird terms.
You don't do dual stack with v6 either, unless you want to -- you can do the incremental rollout and tangible relief thing with v6 just fine. (But it turns out most people do want to do dual stack.)
Is this some kind of attempt at gaslighting? If IPv6 gave tangible relief, then IPv4 today would not be an important mainstay of the Internet. I recommend you read the article I posted, and see how different things could have been, and how completely botched IPv6 rollout has become, that it is just not taken seriously except by some die hard cultists and mobile/telco (which can be done because they pretty much get full configuration of your networking stack).
I guarantee, we will be having this same exact discussion 10 years from now. And then so on, and so on.
Nope, not at all. Everything I said is true. v6 supports deploying in the way described in that article, and you can do it today if you want.
If you don't want to deploy v6 like that, consider why -- because the people who live in the world described by that article will also have the same reasons as you to not deploy it that way.
> If IPv6 gave tangible relief, then IPv4 today would not be an important mainstay of the Internet
No, that argument doesn't hold. v6 can give tangible relief even while v4 is an important mainstay of the Internet. You only have to listen to the people doing CGNAT, or the people turning on v6-mostly and seeing their v4 address use drop by 75% to hear examples of that.
Deployments of v6 reduce the pressure on v4, because they allow us to deploy new networks without needing v4 and because migrating existing networks frees up v4 that can be repurposed. This is also a benefit that's making v4 more viable that it would be without v6.
Plus you're making assumptions about the time needed to replace the Internet's L3 protocol. It's nice to fantasize about finishing it in 10 years, but that doesn't mean that finishing it in 10 years is realistically possible. Deployment of v6 is ongoing and v4's importance is dropping over time; you can't know what the ultimate impact of v6 will be until we're finished deploying it.
There was always going to be a long tail of v4-only hosts, no matter what we did. That's why v6 has a large number of compatibility methods for dealing with them (yes, including the method described in the linked article). It wouldn't be possible to deploy it at all if it didn't.
Backwards compatibility point is interesting.
Found this visual breakdown of IPv4 -> IPv6 transition.
Dual stack and tunneling sections show how much complexity came from not having a clean migration path - https://vectree.io/c/ipv4-vs-ipv6-address-architecture-nat-a...
But there is a clean migration path to v6: you deploy it. How much cleaner can you get?
I'm surprised how few people are talking about ULAs. For any home network where you don't have a reserved global address space from your ISP, it makes sense to configure a ULA on your router and use it for all internal hosts, and the ISP assigned address is only used for Internet access. This does not require NAT/Npt and you have the best of both worlds.
First I heard of it. Apparently they are private Ipv6 addresses:
https://en.wikipedia.org/wiki/Unique_local_address
If your intranet has no IPv4 addresses, this is better than a NAT somehow?
I use ULAs since my ISP changed my ipv6 prefix twice a month. What I learned is that ipv6 configuration usually requires a more 'comerical grade' router. In the end it works well for me but getting it setup initially took a lot of effort. Easy to do the second time though.
I later moved and my current ISP does not have ipv6 support but my ULA setup kept working fine with some minor tweaks.
Unmentioned in the Wikipedia article is RFC 7368 IPv6 Home Networking Architecture Principles[1] that discusses them as well.
> A home network running IPv6 should deploy ULAs alongside its globally unique prefix(es) to allow stable communication between devices (on different subnets) within the homenet
[1] https://datatracker.ietf.org/doc/html/rfc7368.html#section-2...
If you want to have an airgapped network, sure. For most people it doesn't make sense. You'll just get the worst of of both worlds.
RFC 7368 for home networks recommends the use of ULA locally.
> A home network running IPv6 should deploy ULAs alongside its globally unique prefix(es) to allow stable communication between devices (on different subnets) within the homenet
> When an IPv6 node in a homenet has both a ULA and a globally unique IPv6 address, it should only use its ULA address internally and use its additional globally unique IPv6 address as a source address for external communications.
RFC 7368 is a 2014 "informational" (no ietf standing) doc so it's not a source for current IETF advice. Also it was part of the since closed "homenet" working group initiative trying to define some new stuff that did not get vendor uptake.
But in substance, if you have several subnets, then using ULA may make sense depending on what you're trying to do. However most home networks don't subnet.
It’s pretty sweet. By using ULA addresses for everything, all internal networking keeps working as-is if my ISP allocation changes. Every host can talk to its neighbors using internal addresses, and still connect to remote hosts without NAT breakage.
You also get this if you use mDNS, but without the ULA hassle and you get to use DNS names instead of hardcoding IP addresses.
You can use both. I do.
I do want some hardcoded addresses. In particular, some of the daemons I run get twitchy when the remote address changes unexpectedly.
mDNS is orthogonal to ULA. mDNS is for discovery and name resolution, whereas ULA is for IP connectivity. And mDNS operates at the link-local scope (link-local addresses), whereas ULA is scoped for the entire home network.
> mDNS operates at the link-local scope (link-local addresses)
This is not the case for the addresses returned. See eg https://www.rfc-editor.org/rfc/rfc6762
6.2. Responding to Address Queries
So instead of using static ULA addresses, you can use the the routable address returned by mDNS. It can often replace the ULA address use case.You're supposed to use them in parallel, not as an alternative.
There are ISPs out there that distribute IPv6 to the WAN intf of the home router without a /64? What’s the point for them?
IPv6 is totally an equality issue. If a sizeable proportion of this forum had to share an IP address we would've had IPv6 done years ago.
I agree. If you click through to the original Wikipedia table that's cited in this article you can see a pretty clear correlation between countries with more IPv4 addresses than people vs. wealth/hegemonic clout of the country. In the UK, US, Germany, France, Canada, Japan, etc. there are way more than enough IPv4s to go around. Some ISPs here in the UK will even lease you bundles of four or eight IPv4s for very little additional cost.
Ipv6 is a theoretical benefit to the commons but as an individual it's an increase in complexity and a new abstraction for nearly the same result as your existing ipv4 network. There's just not enough incentive to invest in the switch.
The US doesn't have excessive IPv4 Addresses. We have a real shortage and big pain because we don't have anywhere near enough. Sure we have 40% of them all - but that has no indication of what enough is.
I worked at an ISP way back in the dark ages of 2008 and we were all worried about IP exhaustion then. It's now 17 years later and what do you know, IPv4 is still trucking.
I think we'd be surprised how much address space is actually wasted, not announced or routed.
I have my own /24 that I registered back in the 90's. It is, in fact, routed and announced globally. I know several "early Internet" nerds with the same.
I know three local companies with /16's that aren't even announcing their blocks! Perhaps they use them internally.
100% this, my college had 2 /16s for no reason. The printers were all public, was a mess.
I mean having a public address doesnt mean it has to be publicly routable. Same thing applies to ipv6.
I speak as someone who worked at an institute that had similar abundance of address space.
Indeed, the tragedy of the IPv4+NAT stockholm syndrome is that people view having to use ambiguous addresses as access control and can't distinguish reachability vs addressing.
In my case it was publicly routable. The ips and ports of key infra were on https://www.shodan.io/.
My workstation used to have a public address system it was awesome.
One of the biggest, I would assume in the current year, blockers to an IPv6 only world would be the fact that the major "cloud" vendors do not support it.
https://isgithubipv6.live/
The companies that rent you IPv4 addresses don’t support v6 well or at all? Do tell. I wonder why.
AWS supports IPv6 and it's free, whereas IPv4 is not.
I don’t know how you measure “metric tons of content” but I suspect in general there’s lots of US-available content on IPv4 that the countries like China and India want to access, and not much the other way around.
But that should be a perfect playground for an IPv6-only network that has gateways to the IPv4 content; eventually the home-developed content will begin to drive demand elsewhere.
Yes, there's lots of content on IPv4, and there is also a lot of traffic from India...
If India were to turn off IPv4, it would be a great incentive for IPv4-only sites in the US and Europe to add an IPv6 address.
IPv4 has been "in crisis" for the entire 20 years I've worked in tech and we seem to be managing alright. Not to say things can't be better or we shouldn't try to improve. But I'll be surprised if v4 isn't still the default for most use cases in another 20 years.
That's because the Internet is basically broadcast TV 2.0 so no one cares about having public IPv4's at home as long as they can get to their memes and streaming. Great job, we took something that was meant to be a next frontier in humanity and let anyone connect with anyone else without gatekeepers/intermediaries and turned it 21st century brainrot troughs. Perhaps a society not in slow intellectual decline would have chosen otherwise.
> Great job, we took something that was meant to be a next frontier in humanity and let anyone connect with anyone else without gatekeepers/intermediaries
We already had that, it's called shortwave radio. The internet, especially as it's implemented and as it's used, is a terrible way to achieve this. It's service providers the whole way down.
There are definitely problems, but IRC in the 90s had strong ham radio vibes imo.
It would be funny if HAM radio came back because the social filter imposed by the limitations wound up being more important than the technological capability.
Problem is that HAM radio also has social filters you broadcast to everyone and you don’t know who is listening. Encrypted communication is not allowed in HAM.
You are not supposed to use it for „communication” as in Facebook. You are supposed to use spectrum to test your gear and keep transmissions short to leave space for others.
I was in local HAM club and passed the exam for license but never got license to transmit mostly because you are not supposed to chat frivolously over the radio.
> It's service providers the whole way down.
And still likely better than heavily regulated airwaves.
I do agree.
But at the same time there is a quote by Stanisław Lem...
"Until I used the Internet, I didn't know there were so many idiots in the world"
> Perhaps a society not in slow intellectual decline would have chosen otherwise.
The "slow intellectual decline" has circular causality with advancement of mass media and convenience tech.
His point is that you're managing alright because you live in a country where your ISP can give you a public IP address. The author lives in a country where that is not possible and accesses the Internet behind layers of NAT.
It's possible for Indian ISPs to buy IPv4 addresses and assign them to customers. Maybe not for $5/month but if you're willing to pay US prices (plus tax) you should be able to get US quality service.
Yes, but they can't do that if every Indian wants one, and they especially can't do that if every Chinese person wants one at the same time.
IPv4 is 32 bits. It has a hard cap of ~4 billion addresses. China and India alone have 2.85 billion people.
Add in the United States and Europe, and now nobody else gets an IP address. South America, Canada, Mexico, Australia, Africa, the middle east, the rest of Southeast Asia, etc. don't get to use the internet. That's 4 billion people who don't get to use the internet.
My point in mentioning pricing is that the Indian and Chinese middle class can have IPv4 addresses; the rest can't.
What's the difference, other than port forwarding? Does NAT cause some sort of unique issue that makes existence miserable?
> What's the difference, other than port forwarding? Does NAT cause some sort of unique issue that makes existence miserable?
The difference is that your home router does not get a public IP on its WAN interface, but perhaps the non-publicly-routable 100.64.0.0/10 [1] with CG-NAT.
So if you don't have a public IP address, how exactly are you supposed to forward anything? What is the other end supposed to connect to as an IP address?
[1] https://en.wikipedia.org/wiki/IPv4_shared_address_space
> The difference is that your home router does not get a public IP on its WAN interface, but perhaps the non-publicly-routable 100.64.0.0/10 [1] with CG-NAT.
Yes...? I know that, but does that cause any issues in practice other than death of P2P?
> So if you don't have a public IP address, how exactly are you supposed to forward anything? What is the other end supposed to connect to as an IP address?
I already mentioned port forwarding because with something like CG-NAT, it is often not possible (or not allowed). But I am not aware of any issues that stem from this other than an inability for others to establish connections directly to you. In fact, my network has a public IPv4 without CG-NAT and yet I am already used to being unable to receive data other than back through a TCP stream. That is the entire reason reverse proxy tunnels (such as ngrok, etc.) exist.
> Yes...? I know that, but does that cause any issues in practice other than death of P2P?
Well:
> If you’re a gamer using PS5, Xbox, or PC in 2025, running into Double NAT or CGNAT port forwarding issues can make online play nearly impossible. Many 5G home internet and satellite services (like T-Mobile Home Internet and Starlink) put users behind carrier-grade NAT, which blocks direct connections and port forwarding. The good news? There are still workarounds that can open up your connection for smoother online gaming.
* https://www.modemguides.com/blogs/modemguides-blog/double-na...
See also:
* https://en.wikipedia.org/wiki/Carrier-grade_NAT#Disadvantage...
When we went from dial-up speeds to DSL/cable to fibre we were able to have all sorts new applications due to higher bandwidth. Smartphones are capable of all sorts of things because they're always online: back in the day people used to talk about "being online" and saying "sorry, I was offline", because you only had connectivity at the office or at home (where you dialed into your ISP).
What kind of applications and services are not being invented because we're stuck with the current non-P2P / centralized setup of IPv4+NAT?
> What kind of applications and services are not being invented because we're stuck with the current non-P2P / centralized setup of IPv4+NAT?
I don't know? I've never had CG-NAT and yet I've never seen a piece of software that takes advantage of that except maybe for games that use UPnP to open ports.
> I don't know? I've never had CG-NAT and yet I've never seen a piece of software that takes advantage of that except maybe for games that use UPnP to open ports.
Which, as a sibling comments mentions, is the point.
The fact that (CG-)NAT is in the way could be precluding the development of "software that takes advantage of that". It's a form of (negative/inverse) survivorship bias: kind of like zoning for only single-family homes and yet saying "no one wants mid-rise towers/apartments as evidenced by the fact no one building them". The current rules/structure/architecture preclude any other options.
Games, voice/video chat (especially open source ones), stuff like Tailscale, stuff like Magic Wormhole, ... stuff like Dropbox.
Is there anything you do on a computer that involves communicating with another user? That's not just anything - that's most things! All communication between two computers is improved by not requiring NAT.
Corporations love to keep us dependent on their central servers, of course.
> I've never seen a piece of software that takes advantage of that except maybe for games
Maybe we haven't seen many products available on the market to take advantage of it because the current standard of NATs make such things practically unworkable?
Its pretty much impossible to ship smart home stuff that is hosted locally (i.e. not without it connecting to some cloud service) because people want to access these smart devices from outside their home. They're not likely to configure a VPN to connect home, they're not going to configure NATs in any workable fashion (or may be unable to, such as CGNAT), the applications probably don't want to have to handle having NAT hairpinning issues, etc.
So instead we continue down everything that's popular being something that requires a cloud proxy/relay (because that's the only way things actually work for most people), when in reality if things could just be public we could do a whole bunch more and empower people to easily host things themselves.
>other than port forwarding
>other
Well you just handwaved away the most significant difference between NAT and native IP, obviously there won't be any major difference to discuss about anymore!
No, we can't ignore port forwarding. The key thing to realize about NAT is that someone owns the NAT. Back then, the NAT lived inside each of the home routers, so even if you have a "strict" NAT (endpoint-dependent mapping NAT, i.e. one that doesn't allow for hole-punching), you can easily bypass it by setting up a manual port forwarding entry.
With CGNAT that's no longer possible, you do not control the NAT. If your ISP decides to screw you over, you essentially do not have a choice but to get a relay, which needlessly costs you money.
---
But if you really want to know what advantages native IP has over NAT, I'd say the lack of keepalive packets (to keep a holepunched NAT entry from being removed) is a pretty nice thing.
What is this entitled mindset that somehow people without CG-NAT already benefit from their public IPv4? The only benefit I get from port forwarding is being able to expose my Plex media server to the wider internet, and Tailscale and Steam Networking being able to establish P2P. But even UDP should work through CG-NAT. So you can't hole-punch over WAN -- I've never encountered even a single piece of software that needs that except for servers.
Port forwarding is nice, but everyone already knows you can hardly run a server at home (even in countries where port forwarding is standard). It's been this way for as long as I can remember. So yes I handwave it away because it doesn't matter. If that's the only drawback to CG-NAT (other than single IP address bans applying to entire nations or something) I hardly understand why it warrants treatment as such a terrible awful disaster.
>What is this entitled mindset that somehow people without CG-NAT already benefit from their public IPv4?
I will raise you the opposite point: why deprive people of their ability to have a globally addressable IP address?
>But even UDP should work through CG-NAT.
I have already told you why it is wrong to make such as assumption, haven't I?
I have heard of stories coming from China and Vietnam that some ISPs implement so-called "type 4 NAT", otherwise known as symmetric NAT or NAT with endpoint-dependent mapping.
This kind of NAT is NOT hole-punchable. And because you don't control the NAT, you are simply SOL if one day your NAT decides to switch to it. Can't even use Tailscale without significant service degradation now, ouch.
Granted, I have only heard about it in Vietnam and China, and it's not a national thing -- only some provinces seem to have symmetric NAT implemented. But I feel the need to remind you that the ISPs there were able to get away with it, because the two countries have significant IPv6 presence. [0]
>Port forwarding is nice, but everyone already knows you can hardly run a server at home (even in countries where port forwarding is standard).
You can hardly run a server at home because we have been facing address space depletion since the dot com bubble.
>I hardly understand why it warrants treatment as such a terrible awful disaster.
You haven't faced an overloaded CGNAT gateway, have you? [1]
[0]: https://stats.labs.apnic.net/ipv6/XD
[1]: https://www.reddit.com/r/ipv6/comments/1as8dvy/is_there_a_wa...
> I will raise you the opposite point: why deprive people of their ability to have a globally addressable IP address?
I wouldn't. I just don't understand, if the alternative is having no internet access at all, why CG-NAT is so utterly deplorable.
> This kind of NAT is NOT hole-punchable. And because you don't control the NAT, you are simply SOL if one day your NAT decides to switch to it.
Can you clarify what you mean by hole-punchable? If all else fails, just use TCP, right? Does TCP also not work? I'm also not talking about connection between peers but connection to a server. Connection between peers has never been a 100% reliable strategy regardless of anything.
> You haven't faced an overloaded CGNAT gateway, have you? [1]
I have not, but that is not inherent to CG-NAT, is it? Any switch or other hop between you and your destination can be overloaded. The destination itself can be overloaded.
>Can you clarify what you mean by hole-punchable? If all else fails, just use TCP, right? Does TCP also not work?
I... uh, what? Please... learn more about hole punching before trying to engage in the topic.
Hole punching, in the context of NAT, is a technique where you establish peer-to-peer connection between hosts behind a NAT.
It does not matter which protocol you use, UDP or TCP or chuckles SCTP. If you want to establish P2P connection, you must hole punch.
The only alternative is to use relays.
>I have not, but that is not inherent to CG-NAT, is it? Any switch or other hop between you and your destination can be overloaded.
A typical hop does not need to maintain a huge dynamic state table. NAT, due to its very own temporal nature, must do so.
>destination itself can be overloaded.
Apples and oranges. Destination overload is a service problem. Hop overload is an infrastructural problem.
> Please... learn more about hole punching before trying to engage in the topic.
I'm not engaging in the topic of hole punching though? The topic is whether CG-NAT has drawbacks other than lack of port forwarding. As I've said many times, expecting P2P connectivity has never been viable. But you ignore that and keep talking about how hard hole punching is, as if it's indispensable. What makes it so indispensable? Why is it so critical?
> Hole punching, in the context of NAT, is a technique where you establish peer-to-peer connection between hosts behind a NAT.
Good, that confirms I was never talking about that. I even explicitly clarified I was not talking about that (though you may have loaded my comment before that edit.)
> It does not matter which protocol you use, UDP or TCP or chuckles SCTP. If you want to establish P2P connection, you must hole punch.
You don't need to establish P2P connection so I don't see why that's such a problem. Again, it has never been safe to assume P2P connection is possible. Period. It is merely a progressive enhancement.
>The topic is CG-NAT and port forwarding
You don't mention port forwarding without mentioning about hole punching.
Because what port forwarding is for, if not to ease the establishment of direct connections?
>You don't need to establish P2P connection
If you are seriously suggesting Server-Client Is All You Need (TM), I feel we might as well stop the discussion now. VoIP essentially requires P2P, WebRTC is much better with P2P. BitTorrent etc obviously runs on P2P.
Services that provide relays (for people who can't establish P2P connection) for free, can only do so because they expect most connections to NOT go through the relay, and so they could simply stomach the costs of running one small relay.
"What's the difference other than the difference?". Not being able to forward ports means I can't play Tricky Towers with my friend (who isn't technical enough to join a VPN with me and would have privacy concerns about doing so).
Hole punching, which has various forms, may or may not work. This means if you're doing something realtime, you may need to stick a server(reachable endpoint) in between it, at the very least reducing performance.
I have never seen any situation where this is not already necessary other than UPnP which already almost never works reliably. A publicly-addressable relay is already practically non-negotiable for anything over the internet.
IPv6 everywhere makes that not necessary, which is what the author is pushing for.
uPnP works fine though? What was the problem you had with it?
For one, monopolies disabling it by default on their equipment? I remember some years ago having to guess the admin password at a vacation house so I could enable UPnP. It's usually framed as a security vulnerability, even.
uPnP fails when multiple devices are fighting over the same port assignments. uPnP fails when people have it disabled, as has been recommended many times over the years.
Without NAT, it wouldn't be. That's the point.
It makes everything slower and more expensive.
You can even buy a block, but the smallest one has 256 addresses.
Part of the issue is this affects different countries differently, based on residential IP allocations to household ratios. I am currently on CGNAT in Australia split 256 ways, and any site that doesn't support IPv6 can be borderline unusable. I can't imagine what it's like in countries with worse ratios, like India.
It's been in crisis for decades, but it's also getting increasingly worse every year.
The main problem with IPv6 is that it is different from IPv4. There's SLAAC, there's no ARP and there're also some other differences. In the end, it's simpler to just not bother.
Yup. People learn parts of v4 through osmosis because it's the default. Then when networking topics come up, it's easier to keep going with stuff that looks familiar rather than un-learning assumptions. Why bother with the weird other thing that's not even mandatory?
Because IPv4 is logical and makes sense. First thing which IPv6 came up with? No NATs everything will have a public address. It turned out that this was hare brained idea so let's just cover it up with firewall. However misconfigured firewall means that everything is open... IPv6 has been designed by people who were unable to think further than what is going to be tomorrow for a lunch.
IPv4 came out in 1982 and was designed for every device to have a unique public address. Protocols like FTP were designed to literally pass an IP address to connect directly to.
As addresses started running out, the NAT RFC was published in 1994 and described NAT as a "short-term solution". NAT was never meant to be an integral part of IPv4. https://www.rfc-editor.org/rfc/rfc1631
NAT broke a ton of things which required more and more hacks piled on, making it more complex to build services on top if it (e.g., a server in the middle to proxy all the traffic needed between peers is a 100% requirement, with all the maintenance and scaling headaches that come with it).
So you actually agree with me, that making all addresses public was stupid to begin with. It was stupid on IPv4 and it remain stupid on IPv6, yet we already have experience from IPv4 that it was stupid.
> So you actually agree with me, that making all addresses public was stupid to begin with.
If an address is not public how can you start an connection from it, or end a connection at it? A web server needs a public address if you want to have people reach it. And you, at some point, also have to have a public address if you want to connect to pubic services: either on your end-host, at your CPE/router's WAN interface, or on an interface of your ISP's CG-NAT box.
But having a public address on your end-host also allows for much more functionality than if you were stuck behind CPE-NAT or CG-NAT. Now, you don't have to use this functionality—just like how I didn't when my printer gets an publicly addressable (but not publicly reachable) IPv6 address—but it opens up various possibilities.
So having all devices on public addresses was stupid to begin with on IPv4 and it was arrogantly stupid on IPv6.
The fact that we are giving IP addresses an hierarchy is stupid. If you don't want outsiders to connect to your device use a firewall.
Or use NAT, which is actually better solution, because misconfigured NAT won't expose your whole network, while misconfigured firewall will.
Well, actually it will. In fact, even correctly configured NAT won't stop connections into your network.
On top of that, it lulls you into a false sense of security, so you confidently think it's protecting you even when it isn't. At least not having NAT makes the actual state of your network clearer.
> So having all devices on public addresses was stupid to begin with on IPv4 and it was arrogantly stupid on IPv6.
"Yeah? Well, you know, that's just like uh, your opinion, man." — The Dude
Publicly addressable ≠ publicly reachable.
When I was with my last ISP which had IPv6, my printer had a public address, but the only people who could reach it were those on my home network.
With this logic, my printer can be reachable on google.com, but only from my private network, does not turn my printer into Google.
Are you really complaining about the fact that we need to deploy firewalls?
I am complaining about the fact that deploying firewall wrong will open your network to everyone. Deploying NAT wrong wont.
Isn't that the first thing that IPv4 came up with as well? One publicly routable address per device that wants to access the Internet (or the network of universities or military installations or whichever network you were on pre-Internet).
You see and IPv6 was not able to learn from the failure - people does not want to have all computers in one network, same like people does not want to live in one skyscraper.
IPv6 ND (and SND) serve the same purpose as ARP. It's like saying a fancy French restaurant doesn't have a cook because it has a chef.
ARP-schmarp. That doesn't matter to almost anyone who doesn't need to go deep into the network.
But yeah, SLAAC's paradigm of moving assignment logic into the node (away from network infra like in DHCP) is definitely a stumbling point.
I honestly don't understand why IPv6 is not actively deployed in 2026. Every piece of networking hardware over past decade supports IPv6 and often dual stack too. And to switch between both often takes a few clicks if DHCPv6 server is up and reachable. Absolutely transparent, free, zero performance hit. But no, so many persist at doing v4.
PS: I'm talking about MSO hardware. But client hardware should be at the same level of compatibility for years too.
2026:
Yeah, that's the problem. And I bet they could enable it, they just don't want to for some reason.
Azure has very poor V6 support last I tried it.
Support nightmare for ISPs.
I love IPv6, SLAAC, mDNS, Thread, Matter and the other cool stuff in the ecosystem. I have wasted too much time setting manual DHCP static assignments. Now I just use SLAAC and mDNS with basically no manual config.
The way forward for what though? It remains to be seen if this level of infrastructure and complexity has any kind of resilience. I seriously doubt it does, looking back on history. I think it's far more likely that the post-industrial population contraction (which hasn't even really begun) as well as climate change (anthropogenic or not) will make it far more likely that this model of "everybody uses a computer" ends up in the junk bin of history. Can't say I'd be sad to see it go. Somebody who has no interest in computers shouldn't ever have to touch one.
Someone should’ve thought about the UX of IPv6 before declaring it to be “the way”. It’s like having to learn Klingon just to setup your printer. IPvNext could sort that out… maybe it’s time to consider moving on.
People claim this all the time, but every time I push I discover they have no clue how networks work and just handwave away as "easy" or "details" the very reasons people who understand networks say it can't work.
> but every time I push I discover they have no clue how networks work
Obviously. Anyone who does understand how networks work aren't going to spend any time talking about it. People don't talk about things they are certain about. They talk about what they don't know much about to feel out what they're missing. You will never find a discussion where pushing back reveals that you found the world's utmost expert. The world's utmost expert is bored with the subject and has moved on to talking about the things he has gaps in.
I think you’re making my point - someone decided to surface a very low level concept “as is” (without a suitable abstraction) on a level where people also need it for use cases that don’t justify knowledge of the arcane. Or dealing with gatekeepers for that matter.
There are already abstractions that allows you to deal with IPv6 without actually typing in the addresses. It's the DNS, but every time this topic pops up, someone rejects DNS and proceeds to continue sprouting something about how IPv6 is unusable because you can't memorize the addresses.
What happens when DNS is down
What happens when DNS is down (IPv4 edition)?
You type in the IP that's extremely easy to remember as it's just 4 numbers seperated by periods
Without checking what is the ip for hackernews?
For most people there is no UX. Most US houses are IPv6 and use it without knowing anything about networking at all (most cable internet is IPv6, as the big cell networks).
The people who have to make networks work need to know how IPv6 works - but there is no getting around that - they know how IPv4 works too.
>every time I push I discover they have no clue how networks work
Listen here, if there is a networking technology or feature that I wasn't forced learn when I half-assed a SOHO router config in 2005, then it shouldn't exist at all.
SLAAC + mDNS makes IPv6 basically invisible.
If by invisible you mean "things randomly won't work and you'll smash your head in the wall trying to figure out why".
That's just computers in general, isn't it?
I learned the basics of IPv6 a few years ago, and forgot some of it... but NDP, the built in default addresses for router solicitation, address assignments and so on.
I'll tell you that if you just think of it on its own, it's really no harder than IPv4 + ARP + DHCP, just one or two extra things to remember.
The difficulty of adoption is the featureset and the UX of operating systems and home routers in particular. It is really difficult to find a consumer router, or even home networking OS, that exposes sensible working defaults for IPv6. The problem extends to the ISPs.
The spec is fine.
Like there was any chance to see UX of this to work or not in most of places. I've never had an ISP that even offered any IPv6 connectivity besides mobile internet.
It is the only way forward, but the reason for that is not the correlation between population and IP addresses. After all, most of the use of internet today is not by people, but by bots, crawlers, AI agents, b2b and more, and that is far more than the human population, and then you have the virtual networks built over IP like VPNs, Tor and more. It is more related to privacy, bidirectional communication and protocols, security, identity and possibilities.
The only place I have utilized an IPv6 address publicly is on my authoritative name servers only because some DNS testing tools assume it is there. It's not really needed however. My home firewall does have one but I have never used it. I can't think of a use for it. I have multiple static IPv4 addresses and they have suited me just fine for decades. I suppose I could bind a Squid SSL Bump MitM proxy to it in case a site blocks me but I would probably leave it off most of the time.
I never use them on my web, chat, voice, IRC and other servers as I personally find blocking shenanigans on IPv4 and not having to implement the same checks on IPv6 is just easier for a lazy person like me. IPv6 just feels like an after-thought bolt on to me. Clunky, not well thought out. Some privacy gotchas that can be disabled but some will not. That's just my take. I doubt anyone will have the same take.
I think IPv4 will be fine for another 100 years even if we have to re-purpose some DoD/MoD ranges given they don't use them and maybe annex some /8's from a few greedy companies. But that's a problem for Gen Delta. Gen Foxtrot can deal with repurposing some multicast ranges.
> I have multiple static IPv4 addresses and they have suited me just fine for decades
IPv6 is for the people (countries, continents) who did not get in early on the IPv4 address gold rush. Your take is basically "got mine, F you".
Or ... people can use the DoD/Mod and assorted other space to get their IPv4 allocations. There is a ton of unused space in IPv4. Reserved, allocated but entirely unused. Also take back some /8's from greedy companies that don't need all that space. stares at HP When I say take I mean take as in a forceful annex and a timeline.
> Or ... people can use the DoD/Mod and assorted other space to get their IPv4 allocations.
Someone did the math on this:
> Now, average daily assignment rates have been running at above 10 /8s per year, for 2010, and approached 15 /8s towards the end. This means any reclamation effort has to recover at least 15 /8s per year just to break even on 2010’s growth. That’s 5.9% of the total IPv4 address space, or 6.8% of the assignable address space. Is it feasible to be able to reclaim that much address space? Even if there were low-hanging fruit to cover the first year of new demand, what about there-after? Worse, demand for address space has been growing supra-linearly, particularly in Asia and Latin America. So it seems highly unlikely that any reclamation project can buy anything more than a years worth of time (and reclamation itself takes time).
* https://paul.jakma.org/2011/02/03/why-dont-we-just-reclaim-u...
There are 'only four billion IPv4 addresses, and there are eight billion people on the planet. There are just as many smartphones (I have two: personal and work):
* https://www.weforum.org/stories/2023/04/charted-there-are-mo...
Even if you (CG-)NAT an IPv4 address for some number of people, you still need to have IPv4 addresses for public services (web, mail, NTP, etc).
There is no scenario where 2^32 addresses is enough for humanity's needs: as some point you need to go to a protocol with more that 32 bits of address space.
There are 'only four billion IPv4 addresses, and there are eight billion people on the planet. There are just as many smartphones (I have two: personal and work)
Unless all of these devices are running a dedicated full time server that must be reachable inbound by everyone this is not required. At any given time "all the people" are not online. That is why DHCP (per ISP) takes care of this. Maybe some day all the people may become terminally online but I would not count on it.
Yeah some day IPv6 may be required. Maybe in 100 years or so. IPv4 has plenty of unused allocated addresses that can be ripped away from greedy people. There was a time when ARIN would check to see what was in use and would take back anything people were squatting on. I think the reclamation project works if we dont assume everything has to be reachable as a server.
I should add that cell phones (where people are terminally online) were already IPv6 a long time ago for the most part so it's really a non issue. The only risk I see is if someone wanted to start a new massive dedicated server and VPS provider. Most of those are dual stack IPv4+IPv6 now and doing that means clawing some IPv4 space away from those I mentioned earlier.
> Unless all of these devices are running a dedicated full time server that must be reachable inbound by everyone this is not required.
I think this is a lack of imagination. The fact that (CG-)NAT is in the way could be precluding the development of software that could take advantage of incoming/P2P connections.
It's a form of (negative/inverse) survivorship bias: kind of like zoning for only single-family homes and yet saying "no one wants mid-rise towers/apartments as evidenced by the fact no one building them". The current rules/structure preclude any other options.
When we went from dial-up speeds to DSL/cable to fibre we were able to have all sorts new applications due to higher bandwidth. Are there classes of applications that we don't / can't have because of NAT? We're stuck with things that often need a central server (TURN/ICE/STUN) and I'd like people to have the ability to explore a more distributed/decentralized Internet.
I think this is a lack of imagination.
No imagination required. P2P works fine if at least 20% to 30% have ports open inbound. 70%+ need not have open inbound ports. Where this could theoretically be a problem is if a specific sub-set of CG-NAT users were the only people seeding and downloading something. This non existent problem can be worked around using a VPN mesh. Tinc is an open source VPN that operates in user-space and while not as fast as Wireguard it can do things Wireguard could never dream of such as user space mesh routing, always discovering the shortest path. The advantage of this is keeping ambulance chasing lawyers off the P2P/VPN mesh. The only imagination required is how to keep the network semi-private. In my experience this is running a semi-private invite-only self hosted forum. In reality none of this is required for P2P however.
> No imagination required. P2P works fine if at least 20% to 30% have ports open inbound. 70%+ need not have open inbound ports. Where this could theoretically be a problem is if a specific sub-set of CG-NAT users were the only people seeding and downloading something.
"Seeding"? "Downloading"? I think applications besides BitTorrent could be invented and become popular. Even now, existing things like SIP and WebRTC would probably be much less onerous.
> This non existent problem can be worked around using a VPN mesh. Tinc is an open source VPN that operates in user-space and while not as fast as Wireguard it can do things Wireguard could never dream of such as user space mesh routing, always discovering the shortest path.
So you're introducing another layer of software because the underlying network does not have the functionality available (just like STUN/TURN/ICE had to be invented to deal with NAT).
Here's another idea: have IPv6, and if folks want to have end-to-end encrypted communications, start up an IKEv2 process (that opens a hole for its port via UPNP/PCP), and we have IPsec (which is built into most OSes anyway) encrypted communications opportunistically enabled.
> were already IPv6 a long time ago for the most part so it's really a non issue
"IPv4 is all we need because half the internet is already on IPv6 anyway" sounds like a weird argument to me.
> Or ... people can use the DoD/Mod and assorted other space to get their IPv4 allocations. There is a ton of unused space in IPv4. Reserved, allocated but entirely unused. Also take back some /8's from greedy companies that don't need all that space.
In our exponentially growing world that wouldn't help. By the time we ran out of Class As we were allocating a new one every month. Reclaiming all the unused addresses would barely make a dent in demand.
You have to be really special if you think a 32-bit address space can cope with the ever expanding internet. We only managed to scrape by for now because ISPs keep on putting more and more people behind CGNAT. (My country's ISPs forced the migration to CGNAT because they literally couldn't get more IPv4 blocks without spending a hefty amount)
You have to be really special
I am very special, mama said so.
I stand by what I said. Get countries to do what I said and DHCP will take care of the rest. CGNAT can be binned once people do what I said.
DHCP? For country-level IP allocation?
Yeah, your mama was not wrong - you indeed are a special one. Now, let's bring you to a nearby playground...
DHCP? For country-level IP allocation?
No, that would darn silly. For ISP allocation like all normal ISP's.
Gosh golly friend.
> There is a ton of unused space in IPv4.
Err... you do realize that the number of humans currently living on planet earth is twice the number of IPv4 addresses... right?
We can't all have an IPv4 address for each of our devices. We can't all even have one IPv4 address, period. But maybe they should just try not being poor, eh?
I am behind cgnat but have a native ipv6 /64 at home. I've got a great fibre connection (2G5) and everything "just works". I can host on ipv6 native machines and see them from anywhere in the world that has native ipv6 access.
The trouble is that 1) my employers do not have native ipv6 access; 2) neither does my mobile connection; and 3) really nor do a lot of my friends. Moreover, 4) if you browse a website from a native world-reachable ipv6 address, you're fingerprinted by it and it's overwhelmingly unique to you. So, it doesn't really work for hosting, and I don't get any direct benefits from it.
Instead I have a vps with a public ipv4 address and have a router that creates a wireguard tunnel to it. The reverse proxy works great over ipv6 and I am now in a position where I can forward ports and have direct connections -- albeit with hugely increased technical complexity. Ipv6 has many great ideas in it. If it's universally used it might just catch on...
> 4) if you browse a website from a native world-reachable ipv6 address, you're fingerprinted by it and it's overwhelmingly unique to you.
IPv6 privacy extensions exist & are enabled by default in most (if not all) operating systems today, which (this is my understanding; take it with a grain of salt) create what essentially are extra IPv6 addresses, used for outbound traffic, that aren't generated via your MAC address.
I'm curious - which mobile provider? I thought they were the ones that use IPv6 most, some even using 464XLAT so your device only has a v6 address.
The main complaint I have against IPv6 is the addresses are so unwieldy. When I look at them I have the same reaction as when I look at some kind of complex scientific formula comprised of operators and symbols that are unfamiliar. It also takes extra mental effort to expand the compressed zeros and interpret what I'm viewing.
Even after reading about them many times and using them in (an albeit limited) fashion, they still just don't feel human friendly. Not like the more straightforward IPv4 addresses do. (Or even like a hypothetical "IPv5" that simply prefixes one extra octet).
Whenever I bring this up I'm told something like "Don't bother memorizing IPv6 addresses. Use DNS instead."[1]
That take completely overlooks the fact that if the numbers exist, you will inevitably wind up needing to deal with them at various points along the way. Eg. Debugging logs, sniffing network traffic, ruling out if DNS is down, etc. I'm a big fan of ergonomics to make things intuitive and reduce unnccessary cognitive overhead, and the new scheme is a regression in that regard.
If anyone has tips on how they became more fluent with IPv6 I'd love to hear.
[1] https://www.networkworld.com/article/934784/mission-impossib...
Just use it. This reaction is coming from a lack of familiarity, not from it actually being hard.
Here's some roughly equivalent IP addresses:
The v6 addresses are made up of the network prefix (2001:db8:2d4f, basically an opaque string like 203.0.113.45+192.168), then the subnet ID (1, 2) and then the host ID on the network (1-3 and 1).When you look at 2001:db8:2d4f:X::Y, it should be pretty easy to see that it's host Y on subnet X, under your prefix which is the same for your whole network. Even if it's 2001:db8:2d4f:X:YYYY:YYYY:YYYY:YYYY it's still the same thing, just with more characters.
Thanks, that's a helpful comparison. You've shown a fixed prefix 3 hextets (48 bits) in length - is that the most common convention these days?
And has the practice of generating portions of the address from your MAC address been universally (or at least mostly) abandoned?
The most common is more like /56, which is unfortunate because it means you have to deal with "2001:db8:2d4f:61XX::". It's still easy enough to read the subnet out of :6101:, :6102:, :6103: etc, but it does mean every address is longer :(
> And has the practice of generating portions of the address from your MAC address been universally (or at least mostly) abandoned?
Somewhere around mostly. Windows, OSX, and network-manager/dhcpcd/systemd-networkd on Linux all enable RFC7217 (uses a hash of your MAC and a secret value), temporary addresses (random addresses used for outbound connections) or both by default. Either of these will prevent people from seeing your MAC when you connect to them.
I'm not sure about mobile devices. I'd expect temporary addresses there, but also MAC randomization is a thing these days which would do the job too.
Notably absent from that list is Linux's in-kernel SLAAC client. Client-oriented distros often enable tempaddrs by default (or they install one of the network daemons that does it), but server-oriented distros tend not to.
This is without even getting into learning the new (old?) paradigm of "exposing" all addresses to the whole internet. I realize "NAT" is not equivalent to "firewall", but placing them at the same boundary made things simple to understand conceptually. I for one never had trouble opening/forwarding ports (and liked the control it provided over what goes in and out, especially in the days before it all just became HTTP) but I sympathize with the major headaches the NAT "workaround" caused.
NAT also solves the dynamic address issue. With GUA I need to deal with both dynamic prefix and randomised suffix that can be changed by seemingly unrelated things when opening ports to the internet.
That's why server use a static suffix and do slaac to get their prefix. It's really as simple as that.
Regarding firewall policies:
just because most network OS are plain dumb, does not implies that's the fault of IPv6.
A zone based firewall solves that already. And for instance OpenWrt fw4 can make rules for suffixes in a zone too.
Does your ISP not offer static prefixes?
For 5€/mo additional I get a static /32 v4 (for NAT64) and a /60 v6 prefix.
IPv6 feels like we just can't admit to ourselves that it has been a failed transition. What would it take to come up with IPv7 which takes in the lessons of IPv6 and produces something better that we can all agree is worth transitioning to over IPv4.
> What would it take to come up with IPv7 which takes in the lessons of IPv6 and produces something better that we can all agree is worth transitioning to over IPv4.
The only lesson to learn from IPv6 deployment is that if there's a workaround available and the world isn't burning, it'll take 30 years from initial design to actual adoption. So if you went out and took 10 years to design IPv7, it'd likely take until 2070 for it to gain some adoption. This is because big network hardware is costly and has very long replacement cycles.
IPv6 was already designed as a lessons-learnt protocol from IPv4 issues. The header is greatly simplified and it's more hardware-friendly, it incorporates the required features into the protocol and leaves extensibility as an optional add-on that doesn't slow down routing packets, all the while granting an infinite address space.
> IPv6 feels like we just can't admit to ourselves that it has been a failed transition. What would it take to come up with IPv7 which takes in the lessons of IPv6 and produces something better that we can all agree is worth transitioning to over IPv4.
Per Google, quite a few countries (including the US) are at >50%:
* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
Every handset on T-Mobile US's network gets IPv6 (and they're not the only carrier like that):
* https://www.youtube.com/watch?v=d6oBCYHzrTA
So I'm not quite sure where "failed" enters the equation.
And what exactly would be different with IPv7? Anything that needs more address bits would have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A7" address (for "IPv7" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6.
The only place the IPv6 transition seems to be failing is in "command-and-control" corporate networks. (A majority of home/consumer/cellular users are quietly using IPv6 by default every day, per most statistics.) The lessons to be learned there don't seem to be technical but economic incentives.
Big companies believe that they have plenty of IPv4 space, especially because they've always been lax in how they read IPv4 RFCs and use IPv4 routing behind corporate firewalls. Big companies also have the most cash to buy IPv4 blocks as they go to auction. Big companies have massive firewalls and strict VPNs which also insulate them from IPv4 scarcity.
IPv4 leases don't impact enough companies' bottom lines today that they need to assess IPv6 support.
Solving those economic incentive problems would likely be a massive sociopolitical problem: you would need IANA and the RIRs to agree to inflate costs in various ways (and in the short term that might have done a lot of harm to small countries already facing IPv4 inequity and their RIRs that lost the very earliest IPv4 assignment lotteries). You'd probably need new RFCs and political enforcement to support things like "taxing" company to company IPv4 block assignments. You'd probably need collusion or regulation from the big "Cloud Providers" to enforce higher costs on IPv4-only networking.
It would take those kind of "strong handed" tactics to speed up IPv6 adoption in corporate networks. Waiting for the "invisible hand" of the "free market" can be very slow and takes patience. That's mostly what we've been seeing with IPv6 adoption: the "invisible hand" is a lot slower than some people predicted. Especially engineers that hoped technical superiority alone would be a market winner.
What changes to IPv6 would you make to make it easier to transition?
Whole model same as IPv4 (DHCP, NAT, ICMP, DNS, ...) just in v6. If IPv6 and IPv4 would be essentially the same from the get go, IPv4 would be a niche 20 years.
Sure everything above IPv6 have, but it took years and years of screaming to get it.
> Whole model same as IPv4 (DHCP, NAT, ICMP, DNS, ...) just in v6.
All of those things exist in IPv6.
And it is physically impossible for DNS to be the same, as you have to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A7" address (for "IPv7" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.
> All of those things exist in IPv6.
And it has not existed at the start of the IPv6 and is one of the many reasons why after all those years we are having a poor penetration of IPv6.
We've had enough address space for ages—the recurring pain is incentives at org boundaries: whoever owns the legacy peerings pays the migration tax.
No mention of Indian ISPs just buying IPv4 addresses. Prices are even declining.
Author if you are reading comments, rss feed entries point to example.com
the link to the full table somehow doesn't work for me
Fixed
Thanks! Check now.
What dictates the allocation per country?
IPv4 - first come first served, with a 24 karat FU to the 3rd world countries. It is their fault that they are poor.
IPv6 - still the same, but the space is large enough that any first-mover advantage is minuscule.
I think that's a bit uncharitable.
32 bits seemed practically infinite at the time IPv4 was created, and the whole thing started as a way for the American military-industrial-research complex to communicate with itself anyway. Why would you even want to assign addresses on your defense network to foreign adversaries?
Now that it's a commercial thing, a more equitable distribution would have, with hindsight, been a good thing.
NAT is good enough.
Will IPV6 become a type in sql databases?
> Will IPV6 become a type in sql databases?
Both IPv4 and IPv6 addresses are 'just' u_ints: one is 2^32 and the other is 2^128. The fact that we display them in a particular format (10.11.12.13; ff:ee::bb:aa) is only for human UX purposes.
Strictly speaking everything in a computer is 'just' a number represented in base-2 (binary digits: bits) that we affix certain labels to (char, int, float, struct).
> The INET6 data type is intended for storage of IPv6 addresses, as well as IPv4 addresses assuming conventional mapping of IPv4 addresses into IPv6 addresses.
The same annoying and trite IPv6 haters come out of the woodworks with every article posted.
Can someone pity me enough to explain how to do DNS on ipv6 while using slaac?
All I want to do is give every machine on my network a friendly hostname like storage.lan, timsPhone.lan, etc without having to run BIND (if possible), or dhcpd.
I have heard of zeroconf for ipv4, but the catch is I want this to work across several different platforms like Windows , freebsd, Linux, etc. I also don't want to use static addresses, but I feel like that's asking too much.
You are looking for mDNS which is the modern name for zeroconf/Bonjour/etc. The URL suffix is .local (storage.local, myphone.local, myprinter.local). Most modern OSes support it out of the box, but also don't advertise their names on mDNS until you ask them nicely (travel through a maze of Settings and Firewall options).
mDNS supports IPv6 just fine/works on IPv6 only LANs.
https://en.wikipedia.org/wiki/Multicast_DNS
Thank you. I may have tried this previously, but I think my router was blocking traffic between WiFi and wired. I will try this again. Appreciate it
Here comes the flood of IPv6 evangelists who thinks everyone is confused about NAT and firewalls. I don't know where they get their talking points, but they descend onto these threads with their sanctimony. "Oh, you must be confused about how NAT works, allow me to educate you." It's very tiresome.
[flagged]
Pretending that 0-9A-Z is somehow comparable to 行 or ∮ is quite daring, I will give you that.
And once again: any anti-IPv6 people could have already learned proper IPv6, if they directed 10% of their efforts (spent on bashing the IPv6 address format) to learn IPv6 instead.
- In the grand scheme of things, the IP address itself is of very little importance. It was given undue attention because of how IPv4 was inherently limited in address space.
- If you simply needed a way to name your machines, what are you doing not using the (m)DNS? You know, services literally with the word "Name" inside their name?
>And once again: any anti-IPv6 people could have already learned proper IPv6, if they directed 10% of their efforts (spent on bashing the IPv6 address format) to learn IPv6 instead.
I spent some good time trying to learn IPv6. I was pretty open to it, but it was just awful. There were parts of it that were bad due to other reasons -- my router, my ISP. But it was unworkable, produced a number of problems and provided me no benefit.
I learn new things all the time. I learn things I like, learn about things I dislike. I find it really rude that people suggest "I just don't want to learn things."
If bad routers etc. makes you think IPv6 is bad... then man, I think for me IPv4 is a mountain of shite.
But my comment was not directed at you, more so towards those people who looked at IPv6 very superficially (i.e. the ipV6 AddRESs iS UgLY!!1! people), so ¯\_(ツ)_/¯
[flagged]
“They’re out of IPs so they should self-genocide” is certainly something akin to an opinion, but not one I expected to see on this site today.
You're putting words in my mouth, genocide implies murdering existing people to reduce the population, not developing policies that would slow down the population growth and/or fix the issues with the country.
It's not me, it's the UN: Article II, 4.
https://www.un.org/en/genocide-prevention/definition
You literally missed the most important part:
"A transition from IPv4 to IPv6 seems far more easier especially since we already have 77% of people on IPv6."
So to the extent they're aware of the "issues" you bring up they're already on top of it.
ISPs providing IPv6 connectivity out of the box does not equal software and internal devices doing the same.
You can route internal IPv4 networks over IPv6. There are several mapping strategies so this can even be transparent at your v6 gateway.
But note this only gives you access to v4 addresses, not to v6 ones. You do need v6 internally too.
I find it fascinating how these key technologies handle upgrades and breaking changes. For example, Python eschewed breaking changes through 2.7.x but the dam has burst since 3.0 and every point release (it seems?) makes breaking changes, sometimes reversing itself (eg the whole s/u string prefix thing).
Many here will be familiar with the second system effect [1]. Usually people want to avoid making breaking changes but once they do, they can go a little nuts. My personal opinion is only major versions should make breaking changes and a lot of thought should go into making them as painless as possible.
IPv6 is fascinating for these reasons but also that it's a product of its time in two main ways:
1. It doesn't do anything about roaming because that wasn't an issue in the 1990s but it certainly is now;
2. A 64 bit address space would've basically been infinite addresses but instead they went with 128 bit addresses (rolling in ports) but then giving individual users a /64 address range. For some reason people deny it now or simply weren't aware but that too is a historical artifact because it was intended to put a 48 bit MAC address into that space but later we realized that's a huge PII and tracking issue; and
3. History has shown that upgrading network backbone hardware (in particular) is incredibly difficult through a process that's been described as "ossification", which is a nice description. Basically, network relays and routers wanted to avoid security issues and decided to discard things they didn't understand.
That's interesting because it violates Postel's Law [2], which basically says be liberal in what you accept and conservative in what you send.
But this shows up in all sorts of interesting ways, like it's practically impossible to reliably use MTUs larger than about 1536. When IPv4 was designed, that wasn't an issue. With 1-100G+ networks it is. There are RFCs about using large MTUs but you're dependent on backbone hardware you have no control over.
Even Linux struggles with this, to the point where you need to do some configuration for high-bandwidth networks (eg RPS [3]). Just handling all those interrupts presents a bunch of problems beyond the original scope. And again, it's hard to fix through no fault of Linux's.
I'm old enough to remember the talk about us running out of IPv4 addresses back in the 1990s. It's been interesting to watch how this has consistently been kicked down the street (eg cgNAT).
What is funny though is large companies (eg Facebook) actualy ran out of internal addresses on a 10/8 network and there's no good solution for that (with IPv4 at least).
[1]: https://en.wikipedia.org/wiki/Second-system_effect
[2]: https://en.wikipedia.org/wiki/Robustness_principle
[3]: https://lwn.net/Articles/362339/
> 3. History has shown that upgrading network backbone hardware (in particular) is incredibly difficult through a process that's been described as "ossification", which is a nice description. Basically, network relays and routers wanted to avoid security issues and decided to discard things they didn't understand.
What makes you suggest that it's backbone hardware that is the problem? It's largely enterprise customers and tier 3 providers that don't really do IPv6 afaics.
>3. History has shown that upgrading network backbone hardware (in particular) is incredibly difficult through a process that's been described as "ossification", which is a nice description. Basically, network relays and routers wanted to avoid security issues and decided to discard things they didn't understand.
Would say the opposite is true. Core routers were the first to enable V6 support in any network as they would need support it for anything else to even use it. They got regularly replaced as bandwidth needs keeps rising as well.
Plenty of isps advertise ipv6 but haven't managed to give it to customers yet.
Interrupts are hardly a problem with any nics of the last decade really.
Companies like Facebook can and do use 240/4.
If IPv6 was going to be successful, it would have been successful years ago. It seems, people are just more comfortable with layers of NAT than native IPv6 everywhere. I'd guess that it should have been more backwards compatible. Similar to UTF-8 and ASCII.
My Verizon connection has a CGNAT IPv4 and a publicly routable IPv6 address. It's at least partly a success, if you're using a cell phone on Verizon in the US.
If IPv6 doesn't dominate in the next, let's say, 10 years, they might publish the IPv8 which will be an 64bit space, backwards compatible with IPv4. It will be the only case where a newer version of software comes back closer to an older one.
How do you plan to let IPv4 (32 bit address space) actually address and communicate with an IPv8 (64 bit address space) host? You don't have enough bits to identify the v8 host.
Something like 1:2:3:4:a:b:c:d where the most significant 32bits are a valid IPv4. The kernel figures out and keep all others the same (NAT etc). We extend the address space, not invent a new stack. The IPv6 critics shout out that this would be a viable solution.
Okay, so you've figured out how to make v4 addressable from v8. Good job. That lets v8 hosts address a v4 host via a v8 address.
How are you going to make v8 addressable from v4? Because you need to do this too for communication to work.
Also, you've made v4 addressable from v8, and you're about to explain how you make v8 addressable from v4... but that's just addressing, i.e. identifying the right host. How are you going to actually send packets from v8 to v4, and also from v4 to v8?
> The IPv6 critics shout out that this would be a viable solution.
But they never bother to understand enough of the problem to contribute anything useful. Either they can't come up with something that works, or they come up with something that they didn't realize v6 already did.
> the only case where a newer version of software comes back closer to an older one
Winamp 3 -> Winamp 5 was closer to Winamp 2. Windows 8 -> Windows 10 was closer to Windows 7.
Though I don't expect this to happen with IP.
> There are countless threads online on forums like Hacker News, Reddit where people who never really got comfortable with idea of IPv6
It’s clumsier than ipv4. It’s unnecessary since NAT was invented. In practice IPv6 requires dual stack, which means twice as many firewalls, names and routes to manage — so 4x the debugging because you have 2 dimensions that can either be working or failing. Addresses are too long to remember, too clumsy to write, and after 30 years still don’t have consistent representation (how many colons and brackets?).
Look, IPv6 has some benefits, but until the usability is fixed, it will be another 30 years before it’s close to 95% adoption.
> It’s clumsier than ipv4. It’s unnecessary since NAT was invented.
This is a privileged view of someone whose ISP has enough money (or was around early enough) to get enough IPv4 addresses to assign one to every customer's WAN interface. Not everyone is so lucky.
A lot of folks get non-publicly-routable 100.64.0.0/10[1] on their WAN interface with no way to do hole punching because they're behind CG-NAT.
[1] https://en.wikipedia.org/wiki/IPv4_shared_address_space
so ipv6 is now a social justice issue? I'll send you the $2 a month for a elastic IP .
> so ipv6 is now a social justice issue? I'll send you the $2 a month for a elastic IP .
And the billion people in India? The billion in China? The billion on the continent of Africa? And even in the US:
> Our [American Indian] tribal network started out IPv6, but soon learned we had to somehow support IPv4 only traffic. It took almost 11 months in order to get a small amount of IPv4 addresses allocated for this use. In fact there were only enough addresses to cover maybe 1% of population. So we were forced to create a very expensive proxy/translation server in order to support this traffic.
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
* https://community.roku.com/t5/Features-settings-updates/It-s...
* Discussion: https://news.ycombinator.com/item?id=35047624
It's okay for the folks that got in early on the IPv4 address gold rush to tell them "fuck you, we got ours"?
“Got in early” vs “invented it”?
> “Got in early” vs “invented it”?
PSINet/Cogent got 38/8 in 1994: did they invent it? Ford got 19/8 in 1995: how about them?
How many places and people/companies didn't have the ability to go to a RIR in the 1990s or 2000s and get an allocation because their local infrastructure (power, telecom) wasn't developed at the time? So because they got computers, fibre, smartphones later they're SOL?
They sponsored it
Can I have it on my home network connection for $2/month? I could do VPS+VPN, but that's another company to deal with, another bill to pay, and several more things to break. And more latency too.
What about you send $2 to the people in India and China who can't get a public IPv4 address then?
They don’t need one. They have CGNAT
Got it. So they are subhumans who shouldn't get a public IP anyway.
Why would you be typing of remembering ipv6 addresses? Representation has always been consistent, if you learn the rules, like how 1337::1/64 is a valid address.
that address doesn’t even work in the address bar
It's a valid address, just not a valid _URL_.
It’s not even a valid representation of the address (you need brackets )
The brackets are only needed for URLs, scp, and a few other things, due to the fact that ports are specified with colons. Usually you don't see them in a CIDR.
Brackets are in the RFC
I looked through RFC 2373 and found precisely nothing. Which RFC?
It's a valid adress, as a network engineer I've never used brackets.
Don’t fib
No fibbing. Network devices don't use brackets.
To reduce doing things twice there is NAT64/646XLAT. How many v4 addresses have you memorized, I normally use DNS or mDNS.
that reduces part of the scope for some of the customers
... and annoying casting from `sockaddr` to either `sockaddr_in` or `sockaddr_in6*` while you pass around a socklen_t.
10 years ago I was all gung-ho about IPv6, but it's annoying at every level.
Why are you casting to sockaddr_in/6? The whole point of that system is that you can just pass around the sockaddr* without even needing to have a definition for sockaddr_in or sockaddr_in6. All of the socket API functions accept sockaddr*, and if you need to get the IP or port out then you use getnameinfo(), which also takes sockaddr*. There should be little reason to ever cast to either of those types in normal use. (I can think of one or two cases where you might, but they're not common.)
Having to deal with the separate socklen_t is mildly annoying, but you can just make a little struct that holds both.
Having 2 sockets for loopback or multiple interfaces is a huge pain
Bind to '::' and you can get v4 and v6 traffic on one socket.
Not on all OSes. And it's not all good to have one less socket, there are still issues with people not expecting v4 traffic on a v6-capable socket, like described here:
https://radar.offseq.com/threat/ipv4-mapped-ipv6-addresses-t...
If you want to handle two protocols, it is not unreasonable to use two sockets.
Doesn’t work for loopback (you have to listen externally )
It works fine for me on NixOS (Linux), with a recent kernel version and no weird config options - or at least I think so.