> In a nutshell, an IPv4x packet is a normal IPv4 packet, just with 128ābit addresses. The first 32 bits of both the source and target address sit in their usual place in the header, while the extra 96 bits of each address (the āsubspaceā) are tucked into the first 24 bytes of the IPv4 body. A flag in the header marks the packet as IPv4x, so routers that understand the extension can read the full address, while routers that donāt simply ignore the extra data and forward it as usual.
So you have to ship new code to every 'network element' to support IPv4x. 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. (And their DNS idea won't workāor won't work differently than 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 "AX" address (for ipv4X 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.
A single residential connection that gets a single IPv4 address also gets to use all the /96 'behind it' with this IPv4x proposal? People complain about the "wastefulness" of /64s now, and this is even more so (to the tune of 32 bits). You'd probably be better served with pushing the new bits to the other endā¦ likeā¦
Yes, but the compatibility is very very easy to support for both hardware vendors, softwares, sysadmins etc. Some things might need a gentle stroke (mostly just enlarge a single bitfield) but after that everything just works, hardware, software, websites, operators.
A protocol is a social problem, and ipv6 fails exactly there.
What stymies IPv6 is human laziness more than anything else. It's not hard to set up. Every network I run has been dual stack for 10 years now, with minimal additional effort. People are just too lazy to put forth even a minimal effort when they believe that there's no payoff to it.
> People are just too lazy to put forth even a minimal effort when they believe that there's no payoff to it.
For me disabling IPv6 has been the biggest payoff. Life is too short to waste time debugging obscure IPv6 problems that still routinely pop up after over 30 years of development.
Ever since OpenVPN silently routed IPv6 over clearnet I've just disabled it whenever I can.
This goes the other direction too. I just this second fixed a problem with incredibly slow SSH connections because a host lookup which returned an IPv4 address instantly was waiting 10+ seconds for an IPv6 response which would never come.
Now I'm sure I can fix DNSmasq to do something sensible here, but the defaults didn't even break - they worked in the most annoying way possible where had I just disabled IPv6 that would've fixed the entire problem right away.
Yes, I was wondering if I was missing something reading the hypothetical: This is still splits the Internet into two incompatible (but often bridged etc.) subnetworks, one on the v4, one on the v4x side, right?
It just so happens that, unlike for v6, v4 and v4x have some "implicit bridges" built-in (i.e. between everything in v4 and everything in v4x that happens to have the last 96 bits unset). Not sure if that actually makes anything better or just kicks the can down the road in an even more messy way.
> everything in v4x that happens to have the last 96 bits unset
That's pretty much identical to 6in4 and similar proposals.
The Internet really needs a variant of the "So, you have an anti spam proposal" meme that used to be popular. Yes, it kill fresh ideas in the bud sometimes, but it also helps establish a cultural baseline for what is constructive discussion.
Nobody needs to hear about the same old ideas that were subsumed by IPv6 because they required a flag day, delayed address exhaustion only about six months, or exploded routing tables to impossible sizes.
If you have new ideas, let's hear them, but the discussion around v6 has been on constant repeat since before it was finalized and that's not useful to anyone.
I feel like the greatest vindication of v6 is that Iām reading the same old arguments served over a quietly working v6 connection more often than not. While people were busy betting on the non-adoption of v6, it just happened.
This wasn't a proposal, but an alternate history. The world where the people who wished for IPv4 but with extra address space get their way. By the end I come down on being happy with we're in the IPv6 world, but wishing interoperability could be slicker.
No, in this hypothetical, routers that don't know about IPv4x will still route based on the top 32 bits of the address which is still in the same place for IPv4 packets. If your machine on your desk and the other machine across the internet both understand IPv4x, but no other machines in the middle do, you'll still get your packets across.
Well no, all the routers on your subnet need to understand it.
So letās say your internet provider owns x.x.x.x, it receives a packet directed to you at x.x.x.x.y.yā¦ , forwards it to your network, but your local router has old software and treats all packages to x.x.x.x.* as directed to it. You never receive any medssagea directly to you evem though your computer would recognise IPv4x.
Your local machine isn't on the IPv4 internet if it doesn't have a globally routable IPv4 address.
Your home router that sits on the end of a single IPv4 address would need to know about IPv4x, but in this parallel world you'd buy a router that does.
> Who owns all these new addresses? You do. If you own an IPv4 address, you automatically own the entire 96ābit subspace beneath it. Every IPv4 address becomes the root of a vast extended address tree. It has to work this way because any router that doesnāt understand IPv4x will still route purely on the old 32ābit address. Thereās no point assigning part of your subspace to someone else ā their packets will still land on your router whether you like it or not.
So the folks that just happen to get in early on the IPv4 address land rush (US, Western world) now also get to grab all this new address space?
What about any new players? This particular aspect idea seems to reward incumbents. Unlike IPv6, where new players (and countries and continents) that weren't online early get a chance to get equal footing in the expanded address space.
> The new players would each get a /24 and everyone would say that's "enough".
From where?
All then-existing IPv4 addresses would get all the bits behind them. There would, at the time, still be IPv4 addresses available that could be given out, and as people got them they would also get the extend "IPv4x" address associated with them.
But at some point IPv4 addresses would all be allocatedā¦ along with all the extended addresses 'behind' them.
Then what?
The extended IPv4x addresses are attached to the legacy IPv4 addressed they are 'prefixed' by, so once the legacy bits are assigned, so are the new bits. If someone comes along post-legacy-IPv4 exhaustion, where do new addresses come from?
You're in the exact same situation as we are now: legacy code is stuck with 32-bit-only addresses, new code is >32-bitsā¦ just like with IPv6. Great you managed to purchase/rent a legacy address rangeā¦ but you still need a translation box for non-updated codeā¦ like with CG-NAT and IPv6.
So under this IPv4x proposal one gets an IPv4 /24, and receives a whole bunch of extended address space 'for free'.
But right now you can get an IPv4 /24 (as you say), but you can get an IPv6 allocation 'for free' as we speak.
In both cases 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 IPv4x 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.
Essentially.I imagined this hypothetical happening decades ago when there were still a few /8s unallocated. I suggested that those would be set aside for IPv4x only.
Yeah, and the value of IPv4 address space would plummet, and there would be no reason for any company to own a /8. Clawing back address space would involve a few emails and a few months to get network configs ready.
And at the same time the address format and IP header is extended, effectively still splitting one network into two (one of which is a superset of the others)?
A fundamentally breaking change remains a breaking change, whether you have the guts to bump your version number or not.
> The central idea is that a IPv4x packet is still a globally routable IPv4 packet.
That's cool and all, but end-user edge routers are absolutely going to have to be updated to handle "IPv4x". Why? Because the entire point of IPvNext is to address address space exhaustion, their ISP will stop giving them IPv4 addresses.
This means that the ISP is also going to have to update significant parts of their systems to handle "IPv4x" packets, because they're going to have to handle customer site address management. The only thing that doesn't have to change is the easiest part of the system to get changed... the core routers and associated infrastructure.
Note though that I'm not proposing IPv4x as something we should work towards now. Indeed, I come down on the side of being happy that we're in the IPv6 world instead of this alternative history.
In my view, the problem largely comes from the way the Internet has grown. Many of these concepts developed together with the Internet, and IPv4 was the protocol that evolved with them.
I see many ISPs deploying IPv6 but still following the same design principles they used for IPv4. In reality, IPv6 should be treated as a new protocol with different capabilities and assumptions.
For example, dynamic IP addresses are common with IPv4, but with IPv6 every user should ideally receive a stable /64 prefix, with the ability to request additional prefixes through prefix delegation (PD) if needed.
Another example is bring-your-own IP space. This is practically impossible for normal users with IPv4, but IPv6 makes it much more feasible. However, almost no ISPs offer this. It would be great if ISPs allowed technically inclined users to announce their own address space and move it with them when switching providers.
I personally feel that IPv6 is one of the clearest cases of second system syndrome. What we needed was more address bits. What we got was a nearly total redesign-by-committee with many elegant features but had difficult backwards compatibility.
In my opinion the redesign of IPv6 was perfectly fine. The IPv6 headers are significantly simpler that those of IPv4 and much easier to process at great speed.
There was only 1 mistake, but it was huge and all backwards compatibility problems come from it. The IPv4 32-bit address space should have been included in the IPv6 address space, instead of having 2 separate address spaces.
IPv6 added very few features, but it mostly removed or simplified the IPv4 features that were useless.
> The IPv4 32-bit address space should have been included in the IPv6 address space, instead of having 2 separate address spaces.
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]
There are several ways to map the IPv4 address space into the IPv6 address space, going right back to the first IPv6 addressing architecture RFC. Every compatibility protocol added a new one.
IPv6 added IPSEC which was backported to IPv4.
IPv6 tried to add easy renumbering, which didāt work and had to be discarded.
IPv6 added scoped addresses which are halfbaked and limited. Site-scoped addresses never worked and were discarded; link-scoped addresses are mostly used for autoconfiguration.
IPv6 added new autoconfiguration protocols instead of reusing bootp/DHCP.
Or did you mean something else? You still need a dual stack configuration though, there's nothing getting around that when you change the address space. Hence "happy eyeballs" and all that.
> You still need a dual stack configuration though, there's nothing getting around that when you change the address space
Yes there is, at least outside of the machine. All you need to do is have an internal network (100.64/16, 169.254/16, wherever) local to the machine. If you machine is on say 2001::1, then when an application attempts to listen on an ipv4 address it opens a socket listening on 2001::1 instead, and when an application writes a packet to 1.0.0.1, your OS translates it to ::ffff:100:1. This can be even more hidden than things like internal docker networks.
Your network then has a route to ::ffff:0:0/96 via a gateway (typically just the default router), with a source of 2001::1
When the packet arrives at a router with v6 and v4 on (assume your v4 address is 2.2.2.2), that does a 6:4 translation, just like a router does v4:v4 nat
The packet then runs over the v4 network until it reaches 1.0.0.1 with a source of 2.2.2.2, and a response is sent back to 2.2.2.2 where it is de-natted to a destination of 2001:1 and source of ::ffff:100.1
That way you don't need to change any application unless you want to reach ipv6 only devices, you don't need to run separate ipv4 and ipv6 stacks on your routers, and you can migrate easilly, with no more overhead than a typical 44 nat for rfc1918 devices.
Likewise you can serve on your ipv6 only devices by listening on 2001::1 port 80, and having a nat which port forwards traffic coming to 2.2.2.2:80 to 2001::1 port 80 with a source of ::ffff:(whatever)
(using colons as a deliminator wasn't great either, you end up with http://[2001::1]:80/ which is horrible)
> ...you end up with http://[2001::1]:80/ which is horrible
That is horrible, but you do no longer have any possibility of confusion between an IP address and a hostname/domain-name/whatever-it's-called. So, yeah, benefits and detriments.
> Your network then has a route to ::ffff:0:0/96 via a gateway...
I keep forgetting about IPv4-mapped addresses. Thanks for reminding me of them with this writeup. I should really get around to playing with them some day soon.
Which IPv6 āgratuitiousā features (i.e. anything other than the decision to make a breaking change to address formats and accordingly require adapters) would you argue made adoption more difficult?
IPv6 gets a lot of hate for all the bells and whistles, but on closer examination, the only one that really matters is always āitās a second network and needs me to touch all my hosts and networking stackā.
Donāt like SLAAC? Donāt use it! Want to keep using DHCP instead? Use DHCPv6! Love manual address configuration? Go right ahead! It even makes the addresses much shorter. None of that stuff is essential to IPv6.
In fact, in my view TFA makes a very poor case for a counterfactual IPv4+ world. The only thing it really simplifies is address space assignment.
It's not that they loaded it up with features, it's that elegance was prized over practicality.
Simplifying address space assignment is a huge deal. IPv4+ allows the leaves of the network to adopt IPv4+ when it makes sense for them. They don't lose any investment in IPv4 address space, they don't have to upgrade to all IPv6 supporting hardware, there's no parallel configuration. You just support IPv4 on the terminals that want or need it, and on the network hardware when you upgrade. It's basically better NAT that eventually disappears and just becomes "routing".
> They don't lose any investment in IPv4 address space
What investment? IP addresses used to be free until we started running out, and I don't think anything of value would be lost for humanity as a whole if they became non-scarce again.
> they don't have to upgrade to all IPv6 supporting hardware
But they do, unless you're fine with maintaining an implicitly hierarchical network (or really two) forever.
> It's basically better NAT
How is it better? It also still requires NAT for every 4x host trying to reach a 4 only one, so it's exactly NAT.
Having both a real address, a link-local address, and a unique local address, and the requirement to use the right one in each circumstance
The removal of arp and removal of broadcast, the enforcement of multicast
The almost-required removal of NAT and the quasi-relgious dislike from many network people. Instead of simply src-natting your traffic behind ISP1 or ISP2, you are supposed to have multiple public IPs and somehow make your end devices choose the best routing rather than your router.
All of these were choices made in addition to simply expanding the address scope.
In fairness, aside from whining about the minority attitude towards NAT [0] the person you're replying to absolutely met your definition of "gratuitous":
(i.e. anything other than the decision to make a breaking change to address formats and accordingly require adapters)
I (and I expect the fellow you're replying to) believe that if you're going to have to rework ARP to support 128-bit addresses, you might as well come up with a new protocol that fixes things you think are bad about ARP.
And if the fellow you're replying to doesn't know that broadcast is another name for "all-hosts multicast", then he needs to read a bit more.
[0] Several purity-minded fools wanted to pretend that IPv6 NAT wasn't going to exist. That doesn't mean that IPv6 doesn't support NAT... NAT is and has always been a function of the packet mangling done by a router that sits between you and your conversation partner.
This sounds a lot like what we have in 6to4 (for 25+ years now), where nodes behind two ipv4 derived prefixes can automatically talk to each other p2p, and use a gateway to communicate with the rest of the v6 internet.
That was one of the problems with 6to4. If there was no gateway or it was overloaded or there was a gateway but you couldn't reach it because of a weird firewall, all your IPv6 packets would be silently dropped and you'd have no idea why. And this was before happy eyeballs so your computer might default to broken IPv6.
No. Which doesnāt prove the technology has not been adopted. The internet also consists of much more than public-facing websites. So whatās your point?
My point is that we're still dependent on IPv4. For all the progress IPv6 has made, no-one is willing to switch IPv4 off yet. Until we do, we're still constrained by all the problems IPv4 has.
My fantasy road-not-taken for IPv4 is one where it originally used 36 bit addressing like the PDP-10. 64 billion addresses would be enough that we probably wouldn't have had the address exhaustion crisis in the first place, though routing would still get more complicated as most of the world's population (and many devices) started communicating over IP networks.
Even better if it had used 48 bit addressing like Ethernet. 32 bits is almost the worst possible option since it was big enough to seem inexhaustible initially while not actually being big enough.
There are many things wrong with this analogy, but the most important ones seem to be:
- NAT gateways are inherently stateful (per connection) and IP networks are stateless (per host, disregarding routing information). So even if you only look at the individual connection level, disregarding the host/connection layering violation, the analogy breaks.
- NAT gateways don't actually route/translate by (IP, port) as you imply, but rather by (source IP, source port, destination IP, destination port), as otherwise there simply would not be enough ports in many cases.
Until you have stateful firewall, which any modern end network is going to have
> NAT gateways don't actually route/translate by (IP, port) as you imply, but rather by (source IP, source port, destination IP, destination port), as otherwise there simply would not be enough ports in many cases.
If 192.168.0.1 and 0.2 both hide behind 2.2.2.2 and talk to 1.1.1.1:80 then they'll get private source IPs and source ports hidden behind different public source ports.
Unless your application requires the source port to not be changed, or indeed embeds the IP address in higher layers (active mode ftp, sip, generally things that have terrible security implications), it's not really a problem until you get to 50k concurrent connections per public ipv4 address.
In practice NAT isn't a problem. Most people complaining about NAT are actually complaining about stateful firewalls.
> Until you have stateful firewall, which any modern end network is going to have
Yes, but it's importantly still a choice. Also, a firewall I administer, I can control. One imposed onto me by my ISP I canāt.
> not really a problem until you get to 50k concurrent connections per public ipv4 address.
So it is in fact a big problem for CG-NATs.
> In practice NAT isn't a problem. Most people complaining about NAT are actually complaining about stateful firewalls.
No, I know what I'm complaining about. Stateful firewall traversal via hole punching is trivial on v6 without port translation, but completely implementation dependent on v4 with NAT in the mix, to just name one thing. (Explicit "TCP hole punching" would also be trivial to specify; it's a real shame we haven't already, since it would take about a decade or two for mediocre CPE firewalls to get the memo anyway.)
Having global addressing is also just useful in and of itself, even without global reachability.
Which is the exact problem any other IPv4 "extended" proposal would have hit. But the practical reality if the port number really was the only freely available bits in the IPv4 header to reasonably extend into. Almost everything else had ossified middleboxes doing something dumb with it. (And we've seen from NAT/hole-punching/etc how even port numbers had a lot of assumptions to overcome from middle boxes and we aren't using a full /16 there either. A lot of the safest traffic has to be > 10,000, a constraint on 14 of those 16 bits.)
There was never 64-78 bits in the IPv4 header unconstrained enough to extend IPv4 in place even if you accepted the CGNAT-like compromise of routing through IPv4 "super-routers" on the way to 128-bit addresses. Extending address size was always going to need a version change.
The workarounds for IPv4 address exhaustion were a major contributing factor to today's Internet being basically unable to reliably handle traffic that isn't TCP or UDP. Protocol ossification and widespread tolerance of connections that were effectively only usable for WWW has led to the Internet as a whole almost losing an entire layer of the network stack.
30 years on and if I have a machine with an ipv6 only network and run
"ping 1.1.1.1"
it doesn't work.
If stacks had moved to ipv6 only, and the OS and network library do the translation of existing ipv4, I think things would have moved faster. Every few months I try out my ipv6 only network and inevitably something fails and I'm back to my ipv4 only network (as I don't see the benefit of dual-stack, just the headaches)
Sure you'd need a 64 gateway, but then that can be the same device that does your current 44 natting.
It's bit weird how despite Linux kernel having otherwise fairly advanced network stack, the 464xlat and other transition mechanism situation is not great. There are some out of tree modules (jool and nat46) available, but nothing in mainline. Does anyone know why that is?
in 100 years ipv4 will be recognized as one of the great discoveries like calculus. ipv6 is a misnomer really. It's a separate, and lesser protocol. Much like other second systems, it was too ambitious and not pragmatic enough.
Rather than looking down on IPv4 , we should admire how incredible it's design was. Its elegance and intuitiveness, resourcefulness have all led to it outlasting every prediction of it's demise.
What's the advice on ULAs? On my internet-connected VLANs, I have a -er- site-local IPv4 subnet, a unique local IPv6 subnet, and a global IPv6 subnet. This works just fine.
Does the "advice" boil down to "You should NEVER use ULAs and ALWAYS use GUAs!" and is given by the same very, very loud subset of people who seemed to feel very strongly that IPv6 implementations should explicitly make it impossible to do NAT?
Why would anyone need IPv6 to be incapable of doing NAT?
To answer your question: Who knows? Perhaps you have a shitlord ISP that only provides you with a /128 (such as that one "cloud provider" whose name escapes me). [0] It's a nice tool to have in your toolbox, should you find that need to use it.
[0] Yes, I'm aware that a "cloud provider" is not strictly an ISP. They are providing your VMs with access to the Internet, so I think the definition fits with only a little stretching-induced damage.
I think that's meant to be covered by the "IPv4x when we can. NAT when we must" part, in particular "ISPs used carrierāgrade NAT as a compatibility shim rather than a lifeline: if you needed to reach an IPv4āonly service, CGNAT stepped in while IPv4x traffic flowed natively and without ceremony."
It seemed strange that the need for CGNAT wasn't mentioned until after the MIT story. The "Nothing broke" claim in that story seems unlikely; I was on a public IP at University at the end of the 90s and if I'd suddenly been put behind NAT, some things I did would have broken until the workarounds were worked out.
> "ISPs used carrierāgrade NAT as a compatibility shim rather than a lifeline: if you needed to reach an IPv4āonly service, CGNAT stepped in while IPv4x traffic flowed natively and without ceremony."
What's the difference between that and dual stack v4/v6, though? Other than not needing v6 address range assignments, of course.
Try an IPv6-only VPS and see how quickly something breaks for you.
Dual-stack fails miserably when the newer stack is incompatible with the older one. With a stack that extends the old stack, you always have something to fallback to.
To replace something, you embrace it and extend it so the old version can be effectively phrased out.
> Try an IPv6-only VPS and see how quickly something breaks for you.
Who's arguing for that? That would be completely non-viable even today, and even with NAT64 it would be annoying.
> Dual-stack fails miserably when the newer stack is incompatible with the older one.
Does it? All my clients and servers are dual stack.
> With a stack that extends the old stack, you always have something to fallback to.
Yes, v4/v6 dual stack is indeed great!
> To replace something, you embrace it and extend it so the old version can be effectively phrased out.
Some changes unfortunately really are breaking. Sometimes you can do a flag day, sometimes you drag out the migration over years or decades, sometimes you get something in between.
We'll probably be done in a few more decades, hopefully sooner. I don't see how else it could have realistically worked, other than maybe through top-down decree, which might just have wasted more resources than the transition we ended up with.
I don't see IPv4 going away within the next fifty years. I'd not be surprised for it to last for the next hundred+ years. I expect to see more and more residential ISPs provide their customers with globally-routable IPv6 service and put their customers behind IPv4 CGNs (or whatever the reasonable "Give the customer's edge router a not-globally-routable IPv4 address, but serve its traffic with IPv6 infrastructure" mechanism to use is). That IPv4 space will get freed up to use in IPv4-only publicly-facing services in datacenters.
There's IPv4-only software out there, and I expect that it will outlive everyone who's reading this site today. That's fine. What matters is getting proper IPv6 service to every Internet-connected site on (and off) the planet.
The question was about forwarding as I understand it, not address resolution, and there simply won't be any forwarding, since the 32 bit only sending host won't be able to address the 128 bit receiving one.
> In a nutshell, an IPv4x packet is a normal IPv4 packet, just with 128ābit addresses. The first 32 bits of both the source and target address sit in their usual place in the header, while the extra 96 bits of each address (the āsubspaceā) are tucked into the first 24 bytes of the IPv4 body. A flag in the header marks the packet as IPv4x, so routers that understand the extension can read the full address, while routers that donāt simply ignore the extra data and forward it as usual.
So you have to ship new code to every 'network element' to support IPv4x. 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. (And their DNS idea won't workāor won't work differently than 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 "AX" address (for ipv4X 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.
A single residential connection that gets a single IPv4 address also gets to use all the /96 'behind it' with this IPv4x proposal? People complain about the "wastefulness" of /64s now, and this is even more so (to the tune of 32 bits). You'd probably be better served with pushing the new bits to the other endā¦ likeā¦
* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...
> Just like with IPv6.
Yes, but the compatibility is very very easy to support for both hardware vendors, softwares, sysadmins etc. Some things might need a gentle stroke (mostly just enlarge a single bitfield) but after that everything just works, hardware, software, websites, operators.
A protocol is a social problem, and ipv6 fails exactly there.
What slowed ipv6 wasnāt the design of ipv6, it was the invention of NAT and CGNAT.
Even still. The rollout is still progressing, and new systems like Matter are IPv6 only.
What stymies IPv6 is human laziness more than anything else. It's not hard to set up. Every network I run has been dual stack for 10 years now, with minimal additional effort. People are just too lazy to put forth even a minimal effort when they believe that there's no payoff to it.
> People are just too lazy to put forth even a minimal effort when they believe that there's no payoff to it.
For me disabling IPv6 has been the biggest payoff. Life is too short to waste time debugging obscure IPv6 problems that still routinely pop up after over 30 years of development.
Ever since OpenVPN silently routed IPv6 over clearnet I've just disabled it whenever I can.
This goes the other direction too. I just this second fixed a problem with incredibly slow SSH connections because a host lookup which returned an IPv4 address instantly was waiting 10+ seconds for an IPv6 response which would never come.
Now I'm sure I can fix DNSmasq to do something sensible here, but the defaults didn't even break - they worked in the most annoying way possible where had I just disabled IPv6 that would've fixed the entire problem right away.
Dual stack has some incredibly stupid defaults.
Yes, I was wondering if I was missing something reading the hypothetical: This is still splits the Internet into two incompatible (but often bridged etc.) subnetworks, one on the v4, one on the v4x side, right?
It just so happens that, unlike for v6, v4 and v4x have some "implicit bridges" built-in (i.e. between everything in v4 and everything in v4x that happens to have the last 96 bits unset). Not sure if that actually makes anything better or just kicks the can down the road in an even more messy way.
> everything in v4x that happens to have the last 96 bits unset
That's pretty much identical to 6in4 and similar proposals.
The Internet really needs a variant of the "So, you have an anti spam proposal" meme that used to be popular. Yes, it kill fresh ideas in the bud sometimes, but it also helps establish a cultural baseline for what is constructive discussion.
Nobody needs to hear about the same old ideas that were subsumed by IPv6 because they required a flag day, delayed address exhaustion only about six months, or exploded routing tables to impossible sizes.
If you have new ideas, let's hear them, but the discussion around v6 has been on constant repeat since before it was finalized and that's not useful to anyone.
I feel like the greatest vindication of v6 is that Iām reading the same old arguments served over a quietly working v6 connection more often than not. While people were busy betting on the non-adoption of v6, it just happened.
āSent from my IPv6 phone
> The Internet really needs a variant of the "So, you have an anti spam proposal" meme that used to be popular.
For those unfamiliar:
* https://craphound.com/spamsolutions.txt
This wasn't a proposal, but an alternate history. The world where the people who wished for IPv4 but with extra address space get their way. By the end I come down on being happy with we're in the IPv6 world, but wishing interoperability could be slicker.
I might be interpreting wrong, but doesn't IPv6 also have a "implicit bridge" for IPv4?
If it does that's great, but why couldn't I connect to IPv6-only services back when my ISP was IPv4 only?
IPv6 had an implicit bridge called 6to4 but it was phased out because it wasn't that reliable.
No, in this hypothetical, routers that don't know about IPv4x will still route based on the top 32 bits of the address which is still in the same place for IPv4 packets. If your machine on your desk and the other machine across the internet both understand IPv4x, but no other machines in the middle do, you'll still get your packets across.
Well no, all the routers on your subnet need to understand it.
So letās say your internet provider owns x.x.x.x, it receives a packet directed to you at x.x.x.x.y.yā¦ , forwards it to your network, but your local router has old software and treats all packages to x.x.x.x.* as directed to it. You never receive any medssagea directly to you evem though your computer would recognise IPv4x.
It would be a clusterfuck.
Your local machine isn't on the IPv4 internet if it doesn't have a globally routable IPv4 address.
Your home router that sits on the end of a single IPv4 address would need to know about IPv4x, but in this parallel world you'd buy a router that does.
The advantage, as i see it, is that this could be done incrementally. Every new router/firmware/os could add support, until support is ubiquitous.
Contrast this with ip6, which is a completely new system, and thus has a chicken and egg problem.
That is how v6 worked though. Every router and consumer device supports v6 and has for a very long time now. The holdup ended up being ISPs.
Today it seems most ISPs support it but have it behind an off by default toggle.
> Who owns all these new addresses? You do. If you own an IPv4 address, you automatically own the entire 96ābit subspace beneath it. Every IPv4 address becomes the root of a vast extended address tree. It has to work this way because any router that doesnāt understand IPv4x will still route purely on the old 32ābit address. Thereās no point assigning part of your subspace to someone else ā their packets will still land on your router whether you like it or not.
So the folks that just happen to get in early on the IPv4 address land rush (US, Western world) now also get to grab all this new address space?
What about any new players? This particular aspect idea seems to reward incumbents. Unlike IPv6, where new players (and countries and continents) that weren't online early get a chance to get equal footing in the expanded address space.
The new players would each get a /24 and everyone would say that's "enough".
> The new players would each get a /24 and everyone would say that's "enough".
From where?
All then-existing IPv4 addresses would get all the bits behind them. There would, at the time, still be IPv4 addresses available that could be given out, and as people got them they would also get the extend "IPv4x" address associated with them.
But at some point IPv4 addresses would all be allocatedā¦ along with all the extended addresses 'behind' them.
Then what?
The extended IPv4x addresses are attached to the legacy IPv4 addressed they are 'prefixed' by, so once the legacy bits are assigned, so are the new bits. If someone comes along post-legacy-IPv4 exhaustion, where do new addresses come from?
You're in the exact same situation as we are now: legacy code is stuck with 32-bit-only addresses, new code is >32-bitsā¦ just like with IPv6. Great you managed to purchase/rent a legacy address rangeā¦ but you still need a translation box for non-updated codeā¦ like with CG-NAT and IPv6.
ISPs can still get /24 of IPv4 today for free even after it "ran out". This comes from space that was set aside before runout. https://www.arin.net/participate/policy/nrpm/#4-10-dedicated...
This IPv4x thing is bullshit but we should be accurate about how it would play out.
So under this IPv4x proposal one gets an IPv4 /24, and receives a whole bunch of extended address space 'for free'.
But right now you can get an IPv4 /24 (as you say), but you can get an IPv6 allocation 'for free' as we speak.
In both cases 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 IPv4x 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.
Essentially.I imagined this hypothetical happening decades ago when there were still a few /8s unallocated. I suggested that those would be set aside for IPv4x only.
Yeah, and the value of IPv4 address space would plummet, and there would be no reason for any company to own a /8. Clawing back address space would involve a few emails and a few months to get network configs ready.
> The Version field must remain 4.
And at the same time the address format and IP header is extended, effectively still splitting one network into two (one of which is a superset of the others)?
A fundamentally breaking change remains a breaking change, whether you have the guts to bump your version number or not.
The central idea is that a IPv4x packet is still a globally routable IPv4 packet. The extra stuff all goes in the body of the packet.
> The central idea is that a IPv4x packet is still a globally routable IPv4 packet.
That's cool and all, but end-user edge routers are absolutely going to have to be updated to handle "IPv4x". Why? Because the entire point of IPvNext is to address address space exhaustion, their ISP will stop giving them IPv4 addresses.
This means that the ISP is also going to have to update significant parts of their systems to handle "IPv4x" packets, because they're going to have to handle customer site address management. The only thing that doesn't have to change is the easiest part of the system to get changed... the core routers and associated infrastructure.
Thanks for reading and commenting everyone!
Note though that I'm not proposing IPv4x as something we should work towards now. Indeed, I come down on the side of being happy that we're in the IPv6 world instead of this alternative history.
In my view, the problem largely comes from the way the Internet has grown. Many of these concepts developed together with the Internet, and IPv4 was the protocol that evolved with them.
I see many ISPs deploying IPv6 but still following the same design principles they used for IPv4. In reality, IPv6 should be treated as a new protocol with different capabilities and assumptions.
For example, dynamic IP addresses are common with IPv4, but with IPv6 every user should ideally receive a stable /64 prefix, with the ability to request additional prefixes through prefix delegation (PD) if needed.
Another example is bring-your-own IP space. This is practically impossible for normal users with IPv4, but IPv6 makes it much more feasible. However, almost no ISPs offer this. It would be great if ISPs allowed technically inclined users to announce their own address space and move it with them when switching providers.
Dynamic v6 is likely a business and billing issue rather than a technical one. They want to sell you the static IP like they do with v4.
Similar discussion from a couple of months ago: https://news.ycombinator.com/item?id=46468625
I personally feel that IPv6 is one of the clearest cases of second system syndrome. What we needed was more address bits. What we got was a nearly total redesign-by-committee with many elegant features but had difficult backwards compatibility.
https://en.wikipedia.org/wiki/Second-system_effect
In my opinion the redesign of IPv6 was perfectly fine. The IPv6 headers are significantly simpler that those of IPv4 and much easier to process at great speed.
There was only 1 mistake, but it was huge and all backwards compatibility problems come from it. The IPv4 32-bit address space should have been included in the IPv6 address space, instead of having 2 separate address spaces.
IPv6 added very few features, but it mostly removed or simplified the IPv4 features that were useless.
> The IPv4 32-bit address space should have been included in the IPv6 address space, instead of having 2 separate address spaces.
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...
?
There are several ways to map the IPv4 address space into the IPv6 address space, going right back to the first IPv6 addressing architecture RFC. Every compatibility protocol added a new one.
IPv6 added IPSEC which was backported to IPv4.
IPv6 tried to add easy renumbering, which didāt work and had to be discarded.
IPv6 added scoped addresses which are halfbaked and limited. Site-scoped addresses never worked and were discarded; link-scoped addresses are mostly used for autoconfiguration.
IPv6 added new autoconfiguration protocols instead of reusing bootp/DHCP.
> The IPv4 32-bit address space should have been included in the IPv6 address space,
That's ... exactly how IPv6 works?
Look at the default prefix table at https://en.wikipedia.org/wiki/IPv6_address#Default_address_s... .
Or did you mean something else? You still need a dual stack configuration though, there's nothing getting around that when you change the address space. Hence "happy eyeballs" and all that.
> You still need a dual stack configuration though, there's nothing getting around that when you change the address space
Yes there is, at least outside of the machine. All you need to do is have an internal network (100.64/16, 169.254/16, wherever) local to the machine. If you machine is on say 2001::1, then when an application attempts to listen on an ipv4 address it opens a socket listening on 2001::1 instead, and when an application writes a packet to 1.0.0.1, your OS translates it to ::ffff:100:1. This can be even more hidden than things like internal docker networks.
Your network then has a route to ::ffff:0:0/96 via a gateway (typically just the default router), with a source of 2001::1
When the packet arrives at a router with v6 and v4 on (assume your v4 address is 2.2.2.2), that does a 6:4 translation, just like a router does v4:v4 nat
The packet then runs over the v4 network until it reaches 1.0.0.1 with a source of 2.2.2.2, and a response is sent back to 2.2.2.2 where it is de-natted to a destination of 2001:1 and source of ::ffff:100.1
That way you don't need to change any application unless you want to reach ipv6 only devices, you don't need to run separate ipv4 and ipv6 stacks on your routers, and you can migrate easilly, with no more overhead than a typical 44 nat for rfc1918 devices.
Likewise you can serve on your ipv6 only devices by listening on 2001::1 port 80, and having a nat which port forwards traffic coming to 2.2.2.2:80 to 2001::1 port 80 with a source of ::ffff:(whatever)
(using colons as a deliminator wasn't great either, you end up with http://[2001::1]:80/ which is horrible)
> ...you end up with http://[2001::1]:80/ which is horrible
That is horrible, but you do no longer have any possibility of confusion between an IP address and a hostname/domain-name/whatever-it's-called. So, yeah, benefits and detriments.
> Your network then has a route to ::ffff:0:0/96 via a gateway...
I keep forgetting about IPv4-mapped addresses. Thanks for reminding me of them with this writeup. I should really get around to playing with them some day soon.
Which IPv6 āgratuitiousā features (i.e. anything other than the decision to make a breaking change to address formats and accordingly require adapters) would you argue made adoption more difficult?
IPv6 gets a lot of hate for all the bells and whistles, but on closer examination, the only one that really matters is always āitās a second network and needs me to touch all my hosts and networking stackā.
Donāt like SLAAC? Donāt use it! Want to keep using DHCP instead? Use DHCPv6! Love manual address configuration? Go right ahead! It even makes the addresses much shorter. None of that stuff is essential to IPv6.
In fact, in my view TFA makes a very poor case for a counterfactual IPv4+ world. The only thing it really simplifies is address space assignment.
It's not that they loaded it up with features, it's that elegance was prized over practicality.
Simplifying address space assignment is a huge deal. IPv4+ allows the leaves of the network to adopt IPv4+ when it makes sense for them. They don't lose any investment in IPv4 address space, they don't have to upgrade to all IPv6 supporting hardware, there's no parallel configuration. You just support IPv4 on the terminals that want or need it, and on the network hardware when you upgrade. It's basically better NAT that eventually disappears and just becomes "routing".
> They don't lose any investment in IPv4 address space
What investment? IP addresses used to be free until we started running out, and I don't think anything of value would be lost for humanity as a whole if they became non-scarce again.
> they don't have to upgrade to all IPv6 supporting hardware
But they do, unless you're fine with maintaining an implicitly hierarchical network (or really two) forever.
> It's basically better NAT
How is it better? It also still requires NAT for every 4x host trying to reach a 4 only one, so it's exactly NAT.
> that eventually disappears
Driven by what mechanism?
Having both a real address, a link-local address, and a unique local address, and the requirement to use the right one in each circumstance
The removal of arp and removal of broadcast, the enforcement of multicast
The almost-required removal of NAT and the quasi-relgious dislike from many network people. Instead of simply src-natting your traffic behind ISP1 or ISP2, you are supposed to have multiple public IPs and somehow make your end devices choose the best routing rather than your router.
All of these were choices made in addition to simply expanding the address scope.
> Having both a real address, a link-local address, and a unique local address, and the requirement to use the right one in each circumstance
Only use the real one then (unless you happen to be implementing ND or something)!
> The removal of arp and removal of broadcast, the enforcement of multicast
ARP was effectively only replaced by ND, no? Maybe there are many disadvantages I'm not familiar with, but is there a fundamental problem with it?
> The almost-required removal of NAT
Don't like that part? Don't use it, and do use NAT66. It works great, I use it sometimes!
In fairness, aside from whining about the minority attitude towards NAT [0] the person you're replying to absolutely met your definition of "gratuitous":
I (and I expect the fellow you're replying to) believe that if you're going to have to rework ARP to support 128-bit addresses, you might as well come up with a new protocol that fixes things you think are bad about ARP.And if the fellow you're replying to doesn't know that broadcast is another name for "all-hosts multicast", then he needs to read a bit more.
[0] Several purity-minded fools wanted to pretend that IPv6 NAT wasn't going to exist. That doesn't mean that IPv6 doesn't support NAT... NAT is and has always been a function of the packet mangling done by a router that sits between you and your conversation partner.
Reminds me of https://cr.yp.to/djbdns/ipv6mess.html
Which has been discussed previously: https://hn.algolia.com/?q=The+IPv6+mess
This sounds a lot like what we have in 6to4 (for 25+ years now), where nodes behind two ipv4 derived prefixes can automatically talk to each other p2p, and use a gateway to communicate with the rest of the v6 internet.
Interesting. Who deploys and maintains the gateway?
That was one of the problems with 6to4. If there was no gateway or it was overloaded or there was a gateway but you couldn't reach it because of a weird firewall, all your IPv6 packets would be silently dropped and you'd have no idea why. And this was before happy eyeballs so your computer might default to broken IPv6.
"IPv6 does that."
Are you sure about that? Until a few years ago my residential ISP was IPv4 only. I definitely couldn't connect to an IPv6-only service back then.
āIPv6 is waiting for adoptionā
A major website sees over 46 percent of its traffic over ipv6. A major mobile operator has a network that runs entirely over ipv6.
This is not āwaiting for adoptionā so I stopped reading there.
https://www.google.com/intl/en/ipv6/statistics.html
https://www.internetsociety.org/deploy360/2014/case-study-t-...
You'd happily deploy a website for use by the general public on IPv6-only?
No. Which doesnāt prove the technology has not been adopted. The internet also consists of much more than public-facing websites. So whatās your point?
My point is that we're still dependent on IPv4. For all the progress IPv6 has made, no-one is willing to switch IPv4 off yet. Until we do, we're still constrained by all the problems IPv4 has.
I use Devouring Goats on your straw man. It's Super Effective!
To be less glib: IPv6 is well-adopted. It's not universally adopted.
Until you would happily deploy a service on IPv6 only, I suggest that you're still dependent on IPv4.
I'll repeat myself:
My fantasy road-not-taken for IPv4 is one where it originally used 36 bit addressing like the PDP-10. 64 billion addresses would be enough that we probably wouldn't have had the address exhaustion crisis in the first place, though routing would still get more complicated as most of the world's population (and many devices) started communicating over IP networks.
Even better if it had used 48 bit addressing like Ethernet. 32 bits is almost the worst possible option since it was big enough to seem inexhaustible initially while not actually being big enough.
Similar discussion from 10 years ago: https://news.ycombinator.com/item?id=10854570
IPv4 was evolved, it is now a 48 bit address, signified by IP:PORT.
There are many things wrong with this analogy, but the most important ones seem to be:
- NAT gateways are inherently stateful (per connection) and IP networks are stateless (per host, disregarding routing information). So even if you only look at the individual connection level, disregarding the host/connection layering violation, the analogy breaks.
- NAT gateways don't actually route/translate by (IP, port) as you imply, but rather by (source IP, source port, destination IP, destination port), as otherwise there simply would not be enough ports in many cases.
> IP networks are stateless
Until you have stateful firewall, which any modern end network is going to have
> NAT gateways don't actually route/translate by (IP, port) as you imply, but rather by (source IP, source port, destination IP, destination port), as otherwise there simply would not be enough ports in many cases.
If 192.168.0.1 and 0.2 both hide behind 2.2.2.2 and talk to 1.1.1.1:80 then they'll get private source IPs and source ports hidden behind different public source ports.
Unless your application requires the source port to not be changed, or indeed embeds the IP address in higher layers (active mode ftp, sip, generally things that have terrible security implications), it's not really a problem until you get to 50k concurrent connections per public ipv4 address.
In practice NAT isn't a problem. Most people complaining about NAT are actually complaining about stateful firewalls.
> Until you have stateful firewall, which any modern end network is going to have
Yes, but it's importantly still a choice. Also, a firewall I administer, I can control. One imposed onto me by my ISP I canāt.
> not really a problem until you get to 50k concurrent connections per public ipv4 address.
So it is in fact a big problem for CG-NATs.
> In practice NAT isn't a problem. Most people complaining about NAT are actually complaining about stateful firewalls.
No, I know what I'm complaining about. Stateful firewall traversal via hole punching is trivial on v6 without port translation, but completely implementation dependent on v4 with NAT in the mix, to just name one thing. (Explicit "TCP hole punching" would also be trivial to specify; it's a real shame we haven't already, since it would take about a decade or two for mediocre CPE firewalls to get the memo anyway.)
Having global addressing is also just useful in and of itself, even without global reachability.
Routing of this additional /16 is more tricky and non-uniform though. NAT, hole-punching, all that.
Which is the exact problem any other IPv4 "extended" proposal would have hit. But the practical reality if the port number really was the only freely available bits in the IPv4 header to reasonably extend into. Almost everything else had ossified middleboxes doing something dumb with it. (And we've seen from NAT/hole-punching/etc how even port numbers had a lot of assumptions to overcome from middle boxes and we aren't using a full /16 there either. A lot of the safest traffic has to be > 10,000, a constraint on 14 of those 16 bits.)
There was never 64-78 bits in the IPv4 header unconstrained enough to extend IPv4 in place even if you accepted the CGNAT-like compromise of routing through IPv4 "super-routers" on the way to 128-bit addresses. Extending address size was always going to need a version change.
DNS SRV records actually can identify a port, so for "many" uses it would be transparent.
I've rarely seen it used in practice, but it's in theory doable.
You're thinking of TCP or UDP. IP does not have ports.
The workarounds for IPv4 address exhaustion were a major contributing factor to today's Internet being basically unable to reliably handle traffic that isn't TCP or UDP. Protocol ossification and widespread tolerance of connections that were effectively only usable for WWW has led to the Internet as a whole almost losing an entire layer of the network stack.
30 years on and if I have a machine with an ipv6 only network and run
"ping 1.1.1.1"
it doesn't work.
If stacks had moved to ipv6 only, and the OS and network library do the translation of existing ipv4, I think things would have moved faster. Every few months I try out my ipv6 only network and inevitably something fails and I'm back to my ipv4 only network (as I don't see the benefit of dual-stack, just the headaches)
Sure you'd need a 64 gateway, but then that can be the same device that does your current 44 natting.
This works if you have 464xlat turned on. It's mostly used by phones though.
It's bit weird how despite Linux kernel having otherwise fairly advanced network stack, the 464xlat and other transition mechanism situation is not great. There are some out of tree modules (jool and nat46) available, but nothing in mainline. Does anyone know why that is?
in 100 years ipv4 will be recognized as one of the great discoveries like calculus. ipv6 is a misnomer really. It's a separate, and lesser protocol. Much like other second systems, it was too ambitious and not pragmatic enough.
Rather than looking down on IPv4 , we should admire how incredible it's design was. Its elegance and intuitiveness, resourcefulness have all led to it outlasting every prediction of it's demise.
IPv6 is fine. The advice on ULAs is garbage. The purpose of a protocol is to provide utility, not proscription.
What's the advice on ULAs? On my internet-connected VLANs, I have a -er- site-local IPv4 subnet, a unique local IPv6 subnet, and a global IPv6 subnet. This works just fine.
Does the "advice" boil down to "You should NEVER use ULAs and ALWAYS use GUAs!" and is given by the same very, very loud subset of people who seemed to feel very strongly that IPv6 implementations should explicitly make it impossible to do NAT?
Why would IPv6 ever need NAT?
Why would anyone need IPv6 to be incapable of doing NAT?
To answer your question: Who knows? Perhaps you have a shitlord ISP that only provides you with a /128 (such as that one "cloud provider" whose name escapes me). [0] It's a nice tool to have in your toolbox, should you find that need to use it.
[0] Yes, I'm aware that a "cloud provider" is not strictly an ISP. They are providing your VMs with access to the Internet, so I think the definition fits with only a little stretching-induced damage.
what happens when a legacy host sends a 32 bit address to a 128 bit endpoint? it doesn't have enough information to forward it anywhere
I think that's meant to be covered by the "IPv4x when we can. NAT when we must" part, in particular "ISPs used carrierāgrade NAT as a compatibility shim rather than a lifeline: if you needed to reach an IPv4āonly service, CGNAT stepped in while IPv4x traffic flowed natively and without ceremony."
It seemed strange that the need for CGNAT wasn't mentioned until after the MIT story. The "Nothing broke" claim in that story seems unlikely; I was on a public IP at University at the end of the 90s and if I'd suddenly been put behind NAT, some things I did would have broken until the workarounds were worked out.
> "ISPs used carrierāgrade NAT as a compatibility shim rather than a lifeline: if you needed to reach an IPv4āonly service, CGNAT stepped in while IPv4x traffic flowed natively and without ceremony."
What's the difference between that and dual stack v4/v6, though? Other than not needing v6 address range assignments, of course.
Try an IPv6-only VPS and see how quickly something breaks for you. Dual-stack fails miserably when the newer stack is incompatible with the older one. With a stack that extends the old stack, you always have something to fallback to.
To replace something, you embrace it and extend it so the old version can be effectively phrased out.
> Try an IPv6-only VPS and see how quickly something breaks for you.
Who's arguing for that? That would be completely non-viable even today, and even with NAT64 it would be annoying.
> Dual-stack fails miserably when the newer stack is incompatible with the older one.
Does it? All my clients and servers are dual stack.
> With a stack that extends the old stack, you always have something to fallback to.
Yes, v4/v6 dual stack is indeed great!
> To replace something, you embrace it and extend it so the old version can be effectively phrased out.
Some changes unfortunately really are breaking. Sometimes you can do a flag day, sometimes you drag out the migration over years or decades, sometimes you get something in between.
We'll probably be done in a few more decades, hopefully sooner. I don't see how else it could have realistically worked, other than maybe through top-down decree, which might just have wasted more resources than the transition we ended up with.
> We'll probably be done in a few more decades...
I don't see IPv4 going away within the next fifty years. I'd not be surprised for it to last for the next hundred+ years. I expect to see more and more residential ISPs provide their customers with globally-routable IPv6 service and put their customers behind IPv4 CGNs (or whatever the reasonable "Give the customer's edge router a not-globally-routable IPv4 address, but serve its traffic with IPv6 infrastructure" mechanism to use is). That IPv4 space will get freed up to use in IPv4-only publicly-facing services in datacenters.
There's IPv4-only software out there, and I expect that it will outlive everyone who's reading this site today. That's fine. What matters is getting proper IPv6 service to every Internet-connected site on (and off) the planet.
It can't even address a 128 bit endpoint, so nothing would happen.
Sure it can, the DNS server returns the A record if your client doesn't understand Ax. It just won't work.
Honestly, this backwards compatibility thing seems even worse than IPv6 because it would be so confusing. At least IPv6 is distinctive on the network.
The question was about forwarding as I understand it, not address resolution, and there simply won't be any forwarding, since the 32 bit only sending host won't be able to address the 128 bit receiving one.