> 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 the DNS idea won't work, as 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? 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, 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.
> 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.
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.
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.
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)
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".
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 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.
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.
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.
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.
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.
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.
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.
Exactly, and 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.
> 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 the DNS idea won't work, as 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? 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...
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
I might be interpreting wrong, but doesn't IPv6 also have a "implicit bridge" for IPv4?
IPv6 had an implicit bridge called 6to4 but it was phased out because it wasn't that reliable.
> 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".
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.
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,
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)
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".
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 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.
> 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.
Reminds me of https://cr.yp.to/djbdns/ipv6mess.html
Which has been discussed previously: https://hn.algolia.com/?q=The+IPv6+mess
Similar discussion from 10 years ago: https://news.ycombinator.com/item?id=10854570
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.
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.
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.
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.
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.
IPv6 is fine. The advice on ULAs is garbage. The purpose of a protocol is to provide utility, not proscription.
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.
Exactly, and 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.
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.