Hacker News Reader

Comment by rectang | Hacker News Reader

If UTF-8 represents the triumph of a design prioritizing backwards compatibility with an existing standard (ASCII) to facilitate a transition, then IPv6 is the cautionary tale of a design which could have made the transition simpler but did not.

View on HN

IPv6 cannot be backward-compatible with IPv4 in the way UTF-8 is with ASCII. Any argument built on that comparison reflects a misunderstanding of the protocols and leads to flawed conclusions.

Wait, why couldn't it?

Just split the address into two 32-bit chunks (call the top word the "pool", bottom word "address") and assign the full IPV4 range to pool 0x00000000. Done.

In what world does is such a protocol any more *”””compatible”””* with IPv4 than IPv6 already is? It is a different header after all.

Until you upgrade every router between 2 hosts so that it understands the IPv4b addressing scheme, those 2 hosts can't talk. And if you're going to upgrade them all anyway, then might as well do it right.

That doesn't change anything - until everyone adopts the new chunk nobody can use it (even one windows XP machine that you don't personally care about is enough to still kill it today). IPv6 is better because at least it can work side by side by IPv6.

Well for starters, IPv6 has 128 bit addrs.

But then think about what the routing tables would look like, how would an IPv4-only host find an IPv6 host not in pool 0? You'd be reinventing NAT, but in a less-structured context than how NAT works today. There's more issues to it too.

If it was really that simple they would have done exactly that. "Just adding more bits to IPv4" just isn't possible to do backwards-compatibly. IPv6 is the closest you can get to that while also dealing with the complexity that arises with longer addresses.

>how would an IPv4-only host find an IPv6 host not in pool 0?

Ah.

Yep. Translation technologies like NAT64 and company basically as good a job as can be hoped for. And they're quite good nowadays!

But to stick with the ASCII->UTF-8 comparison: how would you have done the transition if you had to stay within ASCII's size of 7 bits?

https://en.wikipedia.org/wiki/UTF-7 exists, but was rarely used.

UTF-8 is convenient because ASCII has a spare bit, but UTF-8 is fundamentally possible because ASCII is variable-length. IPv4 is not variable-length.

Right, the variable-length thing was my point. That's fine when you're dealing with byte slices that you scan through incrementally. But it's not fine for packets and OS data structures that had their lengths fixed at 32 bits.

> https://en.wikipedia.org/wiki/UTF-7 exists, but was rarely used.

UTF-7 was possible because there was an out-of-band mechanism to signal its use, "Content-Type: text/plain; charset=UTF-7":

* https://datatracker.ietf.org/doc/html/rfc2152

What's the OOB signalling in IP packet transmission between two random nodes on the Internet.

The first thing in the IP header is the version number.

> The first thing in the IP header is the version number.

So you just change the version number… like was done with IPv6?

How would this be any different: all hosts, firewalls, routers, etc, would have to be updated… like with IPv6. So would all application code to handle (e.g.) connection logging… like with IPv6.

I was addressing the narrow claim that you cannot distinguish ASCII from UTF-7. You can distinguish IPv4 from IPv6 by looking at the version field (and I forgot to mention the L2 protocol field is out of band from IP's perspective). Obviously if the receiver doesn't support UTF-7 or IPv6 then it won't be understood. Forward compatibility isn't possible in this case.

Weirdly, the version field is actually irrelevant. You can't determine the type of a packet by looking at its first byte; you must look at the EtherType header in the Ethernet frame, or whatever equivalent your L2 protocol uses. It's redundant, possibly even to the point of being a mistake.

I mean, yes, in practice you can peek at the first byte if you know you're looking at an IP packet, but down that route lies expensive datacenter switches that can't switch packets sent to a destination MAC that starts with a 04 or 06 (looking at you, Cisco and Brocade: https://seclists.org/nanog/2016/Dec/29).

> IPv4 is not variable-length.

I get the impression that this fact is fundamentally lost on a lot of the people who want a "compatible" IPv6. Like, their mental model does not distinguish between how we as humans write down an IPv4 address in text and how that address is represented in the packet.

So they think "let's just add a couple more dots and numerals and keep everything else the same"

I think you’re right. Honestly, my impression is that a lot of people imagine it like a string field, and others more like a rich text field, analogous to “can’t we just use a smaller font?”

Why not? Sincere question. As a very superficial idea, if we go back to the drawing board, for example we could decide our new cool concept of address to be an IPv4 + an hex suffix, maybe at the expense of not having a humongous address space.

So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version.

I just made this up, so I'm sure that a couple years of deep thought by a council of scientists and engineers could come up with something even better.

How do you squeeze that in IPv4 packet? Especially in a way that won't get mangled by random ossified devices in between?

In IPv4 you only need to transmit IPv4 addresses. If the "cannot be" in parent post is referring to the exact byte disposition in packets, then I go the other way around to claim that I agree. Because the only way that a UTF8 character can pretend to be ASCII is because ASCII didn't use all of the 8 bits in a byte to begin with. Only way to have something similar in this case, would be that IPv4 didn't use all of the allocated bits for addresses... Which is not the case.

What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it. But I agree, that the actual packet header layouts would need to look at least a bit different.

https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5....

& the following section for the follow-up embedding.

They did that. Problem is that an ipv4 only host can't talk to ipv6. Adding more bits to ipv4 creates a new protocol just like ipv6 and has the same transition issues.

> What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it.

Like:

> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]

* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...

The protocol field in the ipv4 header seems like a reasonable choice. A value would be associated for ipv6 and if that value is chosen then additional header data follows the ipv4 header.

Not really reasonable. That would 1) Make routing inefficient because routers have parse an additional, non-adjacent, non-contiguous header to get the source and destination addresses. 2) Break compatibility because there would exist "routers" that do not understand ipv6 headers. They receive your ipv4 with v6 packet and send it somewhere else.

The result is basically the same situation we are in today, except much more hacky. You'd still have to do a bunch of upgrades.

Perhaps you could use 41, the value already associated with doing this.

(What's up with people constantly suggesting that v6 should do things that it already does?)

That's similar to, but not exactly what we were discussing. In particular 6in4 has a full ipv6 header after the ipv4 header, but here the suggestion was instead that supplementary infomation would follow. For example, the most significant address bits could be stored in the ipv4 header and the least significant ones in the new part.

That's not meaningfully different. It would just amount to a slightly less redundant representation of the same data -- the steps needed to deploy it would be the same, and you'd still have all the same issues of v4 hosts not understanding your format.

Programmers really like to focus on things like:

- How they would format the display of the bits

- Where in the bit pattern IPv4 mapped addresses should go

- Coming up with some variation of NAT64, NAT464, or similar concepts to communicate between/over IPv4 and IPv6 networks

- Blaming the optional extensions/features of IPv6 for being too complex and then inventing something which has 90% of the same parts which are actually required to use

It's even easy to get distracted in a world of "what you can do with IPv6" instead of just using the basics. The things that actually make IPv6 adoption slow are:

- A change in the size of the address field which requires special changes and configuration in network gear, operating systems, and apps because it's not just one protocol to think about the transport of again until the migration is 100% complete.

If IPv4 were more painfully broken then the switch would have happened long ago. People just don't care to move fast because they don't need to. IPv6 itself is fine though and, ironically, it's the ones getting the most value out of the optional extensions (such as cellular providers) who actually started to drive IPv6 adoption.

How would you get someone that only knows about IPv4 addresses like 10.20.30.40 to send a packet to someone with an address 10.20.30.40:fa:be:4c:9d?

> So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version.

* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...

Or:

> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.

> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.

* https://en.wikipedia.org/wiki/6to4

So you have to ship new code to every 'network element' to support your "IPv4+" plan. Just like with IPv6.

So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)

You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to:

* update the IP stack (like with IPv6)

* tell applications about new DNS records (like IPv6)

* set up translation layers for legacy-only code to reach extended-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)

You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.

Deploying the new "IPv4+" code will take time, there will partial deployment of IPv4+ is no different than having partial deployment of IPv6: you have islands of it and have to fall back to the 'legacy' IPv4-plain protocol when the new protocol fails to connect:

* https://en.wikipedia.org/wiki/Happy_Eyeballs

"Just adding more bits" means updating a whole bunch of code (routers, firewalls, DNS, APIs, userland, etc) to handle the new data structures. There is no "just": it's the same work for IPv6 as with any other idea.

(This idea of "just add more addresses" comes up in every discussion of IPv6, and people do not bother thinking about what needs to change to "just" do it.)

> If IPv4 were more painfully broken then the switch would have happened long ago.

IPv4 is very painful for people not in the US or Western Europe that (a) were now there early enough to get in on the IPv4 address land rush, or (b) don't have enough money to buy as many IPv4 addresses as they need (assuming someone wants to sell them).

So a lot of areas of the world have switched, it's just that you're perhaps in a privileged demographic and are blind to it.

I think your summary is really great. One of the better refutations I've seen about the "what about v4 but longer??" question.

However, I think people do get tripped up by the paradigm shift from DHCP -> SLAAC. That's not something that is an inevitable consequence of increasing address size. And compared to other details (e.g. the switch to multicasting, NDP, etc.), it's a change that's very visible to all operators and really changes how things work at a conceptual level.

DHCPv6 now exists and every OS except Android supports it.

> except Android

That alone is significant.

Furthermore, DHCPv6 holds you back from various desirable things like privacy addresses and (arguably even more importantly) IPv6 Mostly.

> Furthermore, DHCPv6 holds you back from various desirable things like privacy addresses and (arguably even more importantly) IPv6 Mostly.

Why would DHCPv6 hold back privacy addresses? Can't DHCPv6 servers generate random host address bits and assign them in DHCP Offer packets? Couldn't clients generate random addresses and put them in Request packets?

See perhaps OPTION_IA_TA (Temporary Address):

* https://datatracker.ietf.org/doc/html/rfc8415#section-21.5

* https://en.wikipedia.org/wiki/DHCPv6#Option_Codes

    DHCPv6 temporary addresses have the same properties as SLAAC
    temporary addresses (see Section 4.6).  On the other hand, the
    properties of DHCPv6 non-temporary addresses typically depend on the
    specific DHCPv6 server software being employed.  Recent releases of
    most popular DHCPv6 server software typically lease random addresses
    with a similar lease time as that of IPv4.  Thus, these addresses can
    be considered to be "stable, semantically opaque".  [DHCPv6-IID]
    specifies an algorithm that can be employed by DHCPv6 servers to
    generate "stable, semantically opaque" addresses.

* https://datatracker.ietf.org/doc/html/rfc7721#section-4.7

How does DHCPv6 hold back IPv6-mostly? First, most clients will send out a DHCPv4 request in case IPv4 is the only option, in which case IPv6-mostly can be signalled:

* https://datatracker.ietf.org/doc/html/rfc8925

And hosts would also have to send out an IPv6 RS, and the RA can signal IPv6-mostly:

* https://datatracker.ietf.org/doc/html/rfc8781

* https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-6mops...

> See perhaps OPTION_IA_TA (Temporary Address):

I was unaware of this, so thanks. Sounds like it addresses (pun intended) my concern.

> How does DHCPv6 hold back IPv6-mostly? First, most clients will send out a DHCPv4 request in case IPv4 is the only option, in which case IPv6-mostly can be signalled

It's not the signalling that's the problem--it's the configuration of the CLAT which requires SLAAC, afaiu. This is in fact the subject of the latest IPv6 Buzz podcast episode: https://packetpushers.net/podcasts/ipv6-buzz/ipb197-slaac-an...

> It's not the signalling that's the problem--it's the configuration of the CLAT which requires SLAAC, afaiu.

This operational difficulty has been recognized and alternatives are being put forward:

* https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-clato...

The real friction with SLAAC was that certain people (particularly some at Google) tried to force it as the only option on users, not that IPv6 ever forced it as the only option. The same kind of thing would likely occur with any new IP version rolling out.

For comparison IPv4 had:

  - Static (1980 - original spec)
  - RARP   (1984 - standalone spec)
  - BOOTP  (1985 - standalone spec)
  - DHCP   (1993 - standalone spec)

And for IPv6:

  - Static (1995 - pre, 1998 final spec)
  - SLAAC  (1996 - pre standalone, 1998 final standalone)
  - DHCPv6 (2003 - standalone)

Some of these have had subsequent minor updates, e.g. DHCP was updated in 1997 and so on.

SLAAC isn't something that is an inevitable consequence of increasing address size, it's something that is a useful advantage of increasing address size. Almost no one had big enough blocks in IPv4 where "just choose a random address and as long as no else seems to be currently claiming it it is yours" was a viable strategy for assigning an address.

There are some nice benefits of SLAAC over DHCP such as modest privacy: if device addresses are randomized they become harder to guess/scan; if there's not a central server with a registration list of every device even more so (the first S, Stateless). That's a great potential win for general consumers and a far better privacy strategy than NAT44 accidental (and somewhat broken) privacy screening. It's at odds with corporate device management strategies where top-down assignment "needs to be the rule" and device privacy is potentially a risk, but that doesn't make SLAAC a bad idea as it just increases the obvious realization that consumer needs and big corporate needs are both very different styles of sub-networks of the internet and they are conflicting a bit. (Also those conflicting interests are why consumer equipment is leading the vanguard to IPv6 and corporate equipment is languishing behind in command-and-control IPv4 enclaves.)

> IPv4 is very painful for people not in the US or Western Europe that (a) were now there early enough to get in on the IPv4 address land rush, or (b) don't have enough money to buy as many IPv4 addresses as they need (assuming someone wants to sell them).

The lack of pain is not really about the US & Western Europe have plenty of addresses or something of that nature, it's that alternative answers such as NAT and CG-NAT (i.e. double NAT where the carrier uses non-public ranges for the consumer connections) deployments are still growing faster in those regions than IPv6 adoption when excluding cellular networks (they've been pretty good about adopting IPv6 and are where most of the IPv6 traffic in those regions comes from).

The header of an IPv4 packet has the source and destination addresses, both as 32-bit values. These fields are adjacent, and there's other stuff next to them. If you appended more bytes to the source address, routers would think that those new bytes are the destination address. This would not be backward compatible.

Interestingly, what you're describing really is similar to how many languages represent an IPv4 address internally. Go embeds IPv4 addresses inside of IPv6 structs as ::ffff:{IPv4 address}: https://cs.opensource.google/go/go/+/go1.26.2:src/net/ip.go;...

That's not a language-specific thing, but is actually part of the IPv6 RFCs as IPv4-mapped IPv6 addresses: [1], [2]

This is super useful because (at least on Linux) IPv6 sockets per default are dual-stack and bind to both IPv6 and IPv6 (except if you are using the IPV6_V6ONLY sockopt or a sysctl), so you don't need to open and handle IPv4 and IPv6 sockets separately (well, maybe some extra code for logging/checking properly with the actual IPv4 address).

That is also documented in ipv6(7):

  IPv4 connections can be handled with the v6 API by using 
  v4-mapped-on-v6 address type; thus a program needs to support only
  this API type to support both protocols.  This is handled
  transparently by the address handling functions in the C library.
  
  IPv4 and IPv6 share the local port space.  When you get an IPv4
  connection or packet to an IPv6 socket, its source address will be
  mapped to v6.

[0]: https://datatracker.ietf.org/doc/html/rfc5156#section-2.2 [1]: https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5....

This recent article begs to differ: https://news.ycombinator.com/item?id=47352236

Come on... that's the top comment on the thread you shared.

https://news.ycombinator.com/item?id=47355046

This article that "begs to differ" is inventing IPv6 all over again. It just refuses to call itself so.

I quote from the top comment:

>So you have to ship new code to every 'network element' to support IPv4x. Just like with IPv6.

and

>So you have to update DNS to create new resource record types [...] Just like with IPv6.

and

>You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6.

The key difference, you don't do dual stack, you can incrementally roll it out and get tangible relief, unlike IPv6.

The point is less about the technology proposed, but the point that there could be an interoperable version of a next generation IP and IPv4.

IPv6 did the braindead thing and completely threw out the idea of transition and interoperability for a clean slate. We're paying for it many decades later.

Also, rather than regurgitate a comment, perhaps you should read the article, because that comment misunderstands what is being proposed and thus completely missing the point.

Why are you still trying to claim this? v6 has transition methods and ways to interoperate coming out of its wazoo. It does pretty much everything you can do to work with v4. Nobody threw out the idea of transitioning.

> but the point that there could be an interoperable version of a next generation IP and IPv4

Yes, it's IPv6. The thing you linked basically took one of the interoperability methods of v6 and described it in weird terms.

You don't do dual stack with v6 either, unless you want to -- you can do the incremental rollout and tangible relief thing with v6 just fine. (But it turns out most people do want to do dual stack.)

Is this some kind of attempt at gaslighting? If IPv6 gave tangible relief, then IPv4 today would not be an important mainstay of the Internet. I recommend you read the article I posted, and see how different things could have been, and how completely botched IPv6 rollout has become, that it is just not taken seriously except by some die hard cultists and mobile/telco (which can be done because they pretty much get full configuration of your networking stack).

I guarantee, we will be having this same exact discussion 10 years from now. And then so on, and so on.

Nope, not at all. Everything I said is true. v6 supports deploying in the way described in that article, and you can do it today if you want.

If you don't want to deploy v6 like that, consider why -- because the people who live in the world described by that article will also have the same reasons as you to not deploy it that way.

> If IPv6 gave tangible relief, then IPv4 today would not be an important mainstay of the Internet

No, that argument doesn't hold. v6 can give tangible relief even while v4 is an important mainstay of the Internet. You only have to listen to the people doing CGNAT, or the people turning on v6-mostly and seeing their v4 address use drop by 75% to hear examples of that.

Deployments of v6 reduce the pressure on v4, because they allow us to deploy new networks without needing v4 and because migrating existing networks frees up v4 that can be repurposed. This is also a benefit that's making v4 more viable that it would be without v6.

Plus you're making assumptions about the time needed to replace the Internet's L3 protocol. It's nice to fantasize about finishing it in 10 years, but that doesn't mean that finishing it in 10 years is realistically possible. Deployment of v6 is ongoing and v4's importance is dropping over time; you can't know what the ultimate impact of v6 will be until we're finished deploying it.

There was always going to be a long tail of v4-only hosts, no matter what we did. That's why v6 has a large number of compatibility methods for dealing with them (yes, including the method described in the linked article). It wouldn't be possible to deploy it at all if it didn't.

Backwards compatibility point is interesting.

Found this visual breakdown of IPv4 -> IPv6 transition.

Dual stack and tunneling sections show how much complexity came from not having a clean migration path - https://vectree.io/c/ipv4-vs-ipv6-address-architecture-nat-a...

But there is a clean migration path to v6: you deploy it. How much cleaner can you get?

Reply on news.ycombinator.com