[dangerlibrary]

It never made sense to me why the authors of the IPv6 standard chose to use an entirely different address format, instead of extending address space in a backwards-compatible way. Why not just append/prepend the 12 additional bytes onto existing IPv4 addresses, and write the standard such that all valid IPv4 addresses are also valid IPv6 addresses?

I'm not an RFC author, but something like "All existing IPv4 addresses will be reachable under the 0.0.0.0.0.0.0.0.0.0.0.0 prefix in the IPv6 Standard" seems like it would've made migration relatively trivial.

The draft standard is 26 years old. The official standard is 7 years old, and we are still reading articles about how "not all enterprises or applications are ready for IPv6 yet."

This question is coming from a place of genuine confusion and curiosity - I really don't get it. Did the authors of the standard just assume that migration and adoption would be easier than they've turned out to be? Was it a fairness issue where somehow this would have granted dominion over huge swaths of the new address space to existing players?

[ploxiln]

They actually did that (see sibling replies), and it actually delayed adoption of ipv6 by a few more years, because of things like:

  1. some OSes can listen on ipv6-mapped-ipv4 automatically when some application listens on ipv4
  2. app is updated to listed on both ipv4 and ipv6
  3. at various companies, the updated app fails to start, because it listened on ipv4, which automatically listened on ipv6, and then it tried to listen on ipv6 and failed because the port was already in use
  4. The problem is weird and confusing, and the easiest fix is to just disable ipv6 everywhere: in the app, in the OS, everywhere. Then the app works again.
  5. The config changes remain untouched for many years (subtle config issue, don't touch!)

I think ipv6 would be more widespread if various auto-adaptation mechanisms were never introduced: 6to4, teredo, etc. I personally experienced this in my teens, one day my browser took 30 seconds to start loading any web page, and just disabling ipv6 everywhere fixed it, and for the next couple years browsers disabled ipv6 by default (whereas they previously were agnostic), and macOS also did a similar thing where it reduced ipv6 enablement by default for a few years, also domains like google.com and facebook.com removed AAAA records they previously had for a few years. They just can't tolerate 1% to 3% of users breaking due to ipv6 mis-config. Adoption would have been much smoother and faster overall, without these significant contributors to automatic-possibly-broken ipv6.

(Yes IPv6 works fine now, with happy-eyeballs, and DHCPv6, and pretty much only real-native ipv6 used anywhere)

[dangerlibrary]

Interesting! Thank you for the thoughtful reply - I did not anticipate those complications.

[yjftsjthsd-h]

> and DHCPv6

So long as you don't have to care about Android, maybe.

[api]

Android still doesn't have this?

[wmf]

Android is kind of boycotting DHCPv6 which annoys network admins.

[yjftsjthsd-h]

AFAIK https://issuetracker.google.com/issues/36949085 is still current.

[kstrauser]

What problems does that cause for Android users? I ask because I've never deliberately set up DHCPv6 on any network and haven't missed having it. However, it's clear that others strongly do want it for presumably good reasons. What are those reasons?

[api]

Not working well on networks that use it.

[ianburrell]

Because writing the addresses is not the important part. You can write IPv6 addresses as dotted decimal. The length is the problem, IPv6 format is more compact. Addresses are not the hard part in upgrading.

The embedding doesn't help with compatibility. IPv4 still can't access IPv6. IPv6 can't access IPv4. It actually breaks NAT64, which depends on special prefix.

Also, extending IPv4 address space has the problem that bake the misallocation into IPv6. IPv4 is broken in the small chunks that makes the routing table large. It also means that new organizations will have a hard time getting address space cause they need to get IPv4 addresses.

[dangerlibrary]

"The length is the problem, IPv6 format is more compact."

"IPv4 still can't access IPv6. IPv6 can't access IPv4."

I guess my point is that these statements represent choices made by humans. Leaving the decimal representation aside, I don't get why they made these choices. If every IPv4 address were a valid IPv6 address, then these statements wouldn't be true.

[wtallis]

Making IPv4 addresses be a valid subset of IPv6 addresses would do nothing to help an IPv4 host reply to a packet from a host with a non-IPv6 address. Solving the "problem" of one-way communication without handling two-way communication is not worth anybody's time and effort.

[ianburrell]

The IPv6 address format uses hex, that is always going to be shorter than decimal. I like that it is fixed width, has zero compression, and is distinct from IPv4.

It is physically impossible for IPV4 32-bit addresses to access IPv6 with 128-bit addresses. Accessing IPv4 from IPv6 requires middleware to translate IPv6 to IPv4 and IPv4 response back to IPv4. That is NAT64.

[AnthonyMouse]

> If every IPv4 address were a valid IPv6 address, then these statements wouldn't be true.

This is already the case. The format for representing IPv4 addresses in IPv6 is to encode the first 96 bits of the address as ::ffff and the last 32 bits as the IPv4 address, e.g. 192.0.2.128 as ::ffff:192.0.2.128. You can also encode the last 32 bits as hex if you want (::ffff:c000:0280 is the same address) but then it's less obvious what the IPv4 address is.

The problem is that every IPv6 address is not a valid IPv4 address, because the IPv4 address space is smaller so there is no way to do that without some kind of NAT or similar, which also exists but sucks in various ways.

[RiverCrochet]

This is like saying you want to put 16 gallons of liquid in a 4-gallon bucket. It just ain't gonna fit. You need a bigger bucket. Because a lot of people are still using carts that only hold 4-gallon buckets, let them keep using the 4-gallon ones until they get tired of paying IPXO for the 4-gallon bucket rental when the 16-gallon ones are free.

[AnthonyMouse]

The real trouble here is that the entities that need more addresses and the ones not supporting IPv6 aren't the same ones. In particular, a lot of large companies basically need one IPv4 address and they can NAT their whole organization behind it. Meanwhile ISPs and hosting providers need lots of IP addresses but can't switch entirely to IPv6 because their customers demand the ability to communicate with those companies that still only support IPv4.

But the government could probably fix it without even mandating anything. They should just... stop using IPv4. Does your company have to file tax forms with the IRS website? Only available via IPv6, so better get your network to support it.

[yjftsjthsd-h]

To some degree, no it's not a choice; you can't fit a 128-bit address in 32 bits. However, to the degree that it is possible, that exists; NAT64 does make every valid IPv4 address a valid IPv6 address.

[bongodongobob]

You talk about networking as if this is just about updating a regex somewhere. 32 bits is 32 bits, there's no way around that. IPv4 addresses not being valid IPv6 addresses has nothing to do with anything.

[DanAtC]

There's no such thing as "backwards compatible." The IPv4 packet format is set in stone with 32 bit addresses. The "just add more bytes" meme doesn't make any sense.

[BenjiWiebe]

But it gets brought up all the time...

[Ekaros]

Makes me really doubt about general education in CS and programming.

Is there really this many people who never looked what is in IP packet. And well TCP and UDP too, but less so. Or considered how a packet might traverse across networks.

You have a small box, and that is it. You cannot make box bigger and make someone that only understand small box to understand the new big box.

Then on other end there are those that are too stuck of manually managing the small boxes... And the stuff that made them somewhat usable.

[bluGill]

Sure, by people who have never bothered to read the RFCs nor spent even a moment of thinking about what happens on the wire. (I last read the RFCs in the late 1990s so I don't know the latest, but it is obvious you can't add more bits)

[ikiris]

They think the shed should be blue.

[dangerlibrary]

Just to address the implication (prevalent in many of the sibling comments as well) that I and everyone else who talks about this are idiots incapable of grasping that 128 is larger than 32:

If 32 bit IPv4 addresses are valid IPv6 addresses without fiddly NAT64/DNS64 shenanigans, then (it seems to me) IPv4-only clients could blithely continue to interact with the IPv4-accessible internet via IPv6-only servers, routers, etc. indefinitely. They can putter along accessing only a subset of available resources forever and everyone can passive-aggressively roll their eyes at them and close support tickets saying "upgrade to IPv6 if you want to see the rest of the internet, it just works."

That's what I mean by backwards compatible. Everyone who says "it can't be done, it has to be this way" is asserting that there's no better alternative to NAT64/DNS64 and running two entirely separate networking stacks in parallel. I don't buy that there was no simpler way to accomplish packing 32 bits into a space that can contain 128 bits. And if "supporting IPv6" simply meant "upgrading your networking software to the latest version, which transparently handles both IPv4 and IPv6 traffic for you" then networking and server teams have no excuse to avoid deploying IPv6 support for 26 years.

I recognize that 128 bit addresses will be truncated and packets misdirected or rejected if handled by a 32 bit networking stack. I recognize that clients upgrading too early will fail and need to fall back. But making it unnecessarily difficult for servers and routers to handle IPv4 traffic in an IPv6-only context led us to where we are today.

To illustrate my point: ascii text works just fine, with no translation layer required, when parsed and transmitted as UTF-8.

[throw0101d]

> If 32 bit IPv4 addresses are valid IPv6 addresses without fiddly NAT64/DNS64 shenanigans, then (it seems to me) IPv4-only clients could blithely continue to interact with the IPv4-accessible internet via IPv6-only servers, routers, etc. indefinitely

If you have an IPv4-only client and an IPv6-only server (i.e., has no IPv4 address), you need a IPv4-IPv6 relay.

Because if the IPv6-only server is truly IPv6-only, it only has addresses that are 128 bits. How would an IPv4-only client, which only knows about 32-bit addresses, deal with a 128-bit address? The only address that the IPv6-only server has is 128 bits: how are you supposed to fit those bits in the 32-bit data structures of the IPv4-only client.

If a the server is IPv6-only, then its DNS records have to be 128-bits as well: how does that work with DNS A records, which are hard-coded to 32-bits? That's why AAAA records were invented: to with 128 bits. Now you're talking about update DNS server for new record types, resolver code to request A and AAAA records. Of course after you do a lookup to get the IP, you have generally want to connect, so you call socket(2) and then connect(7), so the latter has to be re-coded to understand 128-bit addresses.

[dangerlibrary]

You are correct, given the assumption that an IPv6-capable server or host has no IPv4 address. I attempted to acknowledge that such a server would be unreachable from an IPv4 client.

[kstrauser]

Thing is, all interesting Internet services require 2-way communication. Suppose you had an IPv6 client trying to talk to an IPv4 server. With that scheme, the initial packet could get routed to the server by dropping the first 96 bits of the address and treating the rest like an IPv4 address. But where do you put those other 96 bits so that the server can send its reply packet back to the originating client?

You can use NAT64 which does exactly that. If you're doing that anyway, there's not much advantage to adding all the complexity directly into the protocol.

[ianburrell]

How would IPv4 host talk through IPv6 network in your model? Without IPv6 network sees an unsupported IPv4 packet and throws it away. You need something to convert IPv4 to IPv6. We'll call it NAT46, but it is deprecated because dual stack or NAT64 is better.

Or could tunnel IPv4 over IPv6. We'll call this 4in6.

The mistake you are making is thinking that it is hard to have dual stack. IPv4 will be running in tunnels for a long time, just like IPv6 run in tunnels in early days. There are enough IPv4 addresses for servers for a long time. Eventually, IPv6 will be the norm and nobody will care about IPv4 except for running old hardware and software.

Upgrading just networking software is impossible since client software needs to be upgraded to support longer addresses. In particular, they need to support the generic interfaces that work with multiple protocols.

[dangerlibrary]

> Without IPv6 network sees an unsupported IPv4 packet and throws it away. You need something to convert IPv4 to IPv6.

Acknowledging my own ignorance here, assuming this sentence seemingly disregards my point, because this was a choice. The IPv6 standard chose to fix the header length at 40 bytes and operate differently from IPv4, but the standard could easily have said "We're re-using the IPv4 header format, except now addresses are variable-length up to 128 bits."

[Ekaros]

Because they also noticed that IPv4 has some design errors. So if you are anyway making something incompatible you can fix those and bring in new features.

IP packet having checksum that is also calculated on the hops remaining. Well, do you really really need that when most popular protocols TCP and UDP have also a checksum? So getting rid of it entirely is actually a smart move.

And then whole ARP, DHCP etc. Can we do something more sensible instead of that sort of thing. Different mindset, but reasonable attempt.

[RiverCrochet]

IPv6 has other differences than the address length. A theme for IPv6 was to make it even easier for network equipment to process to make it faster; which aligns with "dumb fast scalable core; smart expensive edge" Internet philosophy - this is in contrast to "smart hard-to-expand core; dumb cheap edge" phone system philosophy

Compare the packets. https://www.networkacademy.io/ccna/ipv6/ipv4-vs-ipv6

> Did the authors of the standard just assume that migration and adoption would be easier than they've turned out to be?

No, but IPv4 and IPv6 can be used together (they're separate protocols) so there was no need for that.

[dboreham]

Also, a meta-reply would be: whatever clever solution you think you've invented was surely considered. It's 30 years ago so memory fades but all this was discussed at great lengths on mailing lists and in meetings by people who knew what they were doing. The only things I don't think were envisioned at the time were: NAT prolonging the V4 space exhaustion significantly, and the level of inertia for vendors implementing support for V6. I was still working on that in 2005 -- more than 10 years later.

[dangerlibrary]

I assure you I am under no illusions about my cleverness relative to others in this industry.

[jandrese]

> write the standard such that all valid IPv4 addresses are also valid IPv6 addresses?

This already exists. 2020:abcd:abcd::192.168.0.1 is a valid IPv6 address. Most applications will parse it just fine.

NAT64 has been around for ages and mostly works, but is pretty ugly so few people want to actually deploy it.

[wmf]

Extending IPv4 seems like it would work until you get into the details. You discover that any new protocol is going to have similar adoption problems. https://archive.ph/eHvKF https://news.ycombinator.com/item?id=10854570

[BadBadJellyBean]

I don't think that would work. The IPv6 Notation is only the human representation. Inside the package it is a 128 bit integer. IPv4 addresses can already be put there. The problem is that everyone still needs to support a package with 128 bit addresses instead of 32 bit. There is simply no space in the IPv4 package format for the 128 bit addresses. Or anything bigger than 32 bit.

[Ekaros]

Well there is the options... But that means again every single router and host would need to support it on the path for it to be any use. So new protocol is much simpler and allows fixing other things as well.

[throw0101d]

> […] and write the standard such that all valid IPv4 addresses are also valid IPv6 addresses?

You mean RFC 4291's ::ffff:0:0/96?

* https://www.rfc-editor.org/rfc/rfc4291.html#section-2.5.5

* https://www.iana.org/assignments/iana-ipv6-special-registry/...

* https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv6

[dvh]

https://en.wikipedia.org/wiki/Second-system_effect

[wmf]

IPv6 definitely suffers from some amount of second-system effect but (I cannot stress this enough) that's not the cause of its failure. A minimal IPv4+ upgrade would still have failed for the same reasons.

[RiverCrochet]

IPv6 is actually working right now for many so I wouldn't call it a failure. Use of IPv6 has been increasing over time and who really cares how fast that is happening? Some ISPs, nodes or networks may never use it - but that's OK; really as long as major cell phone networks are using it, it's not going away.

Windows XP is another example of something that lingered far longer than it should have. It's not a failure just because everyone didn't immediately start using it.