[TheDong]

> IPv6 SHOULD have been this way

How would it have possibly been backwards compatible? Plenty of routers and ip-aware switches have, in hardware, specified that ips are 32-bits, so anything that added more bits would necessarily break existing hardware, and thus not be backwards compatible.

That's not to mention all the software that has similarly hardcoded the number of bytes in an ip.

How could we possibly have made ipv6 backwards compatible?

[bluGill]

I worked on the first switch ever sold in 1995 - it didn't support IPv6, but I assure you all the engineers working on it were aware of IPv6 and assumed IPv4 would be long gone by today. For reference back then we were more concerned about how the switch handled IPX (Novell Netware) than IP. Everything else since then was designed in the era where IPv6 is coming soon enough that you ensure you can support it with a software update if you don't support it.

That isn't to say IPv6 couldn't have been done in a backward compatible way. I can think of ways to do that, and dozens of pros and cons - even though I haven't been in networking for 20 years and so I've forgotten a lot.

[TheDong]

> ensure you can support it with a software update if you don't support it

For hardware, that doesn't sound that different from not supporting it. Convincing end-users of internet hardware to update their switch's firmware is hard. Ubiquiti has done a pretty good job of making updates actually doable, but for most hardware I doubt it'd happen more quickly than the hardware itself would fail.

> That isn't to say IPv6 couldn't have been done in a backward compatible way. I can think of ways to do that

Can you explain any of those ways?

[p1mrx]

6to4 (2002::/16) was basically backwards-compatible IPv6. If the entire Internet had been allocated from that space, IPv6 would've been easier to deploy.

But it's technically quite ugly, and tunnelling/MTU-related problems would be more prevalent.

[nybble41]

6to4 provides a standard way to tunnel IPv6 traffic at the perimeter over an IPv4 backbone, essentially assigning a range of IPv6 subnets to every public IPv4 address, but it doesn't provide full backward compatibility, and it still depends on proxies at the border of the IPv4 network. The applications at the endpoints need to support IPv6—so all the existing software still needs to be updated—and you still need new protocols for address assignment (SLAAC or DHCPv6) and domain resolution (AAAA records), along with any other protocols than embed IP addresses. Most of this is an inevitable consequence of extending the address space; no amount of clever tricks can make IPv4-only applications, hosts, or protocols automatically compatible with larger IP addresses.

6rd works on similar principles, but in a way that plays more nicely with ISP routing and traffic management policies. The main user-visible change is that a variable-length, ISP-specific prefix is used instead of 2002::/16.

There are a few other transition mechanisms and embeddings of the IPv4 address space, for example the ::a.b.c.d address format. They all suffer from the fact that two-way communication without a proxy requires each endpoint to be capable of representing the full address of its peer. For a node which does not have a public IPv4 address to communicate with a node which does not understand larger addresses, some third node must exist in between to perform protocol translation.

[p1mrx]

6to4 could've been released to billions of users, with no cooperation from the ISPs, just by home router manufacturers adding a few lines of code (maybe a few dozen, for health checking.)

Applications would still need to change, but apps change a lot faster than ISPs.

6to4 died because it was never the primary mode of addressing. Performance between 2002::/16 and the rest of IPv6 relied on anycast, which was unpredictable and therefore useless for real traffic.

[nybble41]

Placing the 6to4 endpoint at the home router assumes that the home router has a public, routable IPv4 address, which doesn't really do anything to solve the problem of address exhaustion. At best it might have been a slightly superior form of NAT, but not enough of an improvement to offset the reliability and performance issues or the lack of economic incentive for ISPs (or anyone, really) to operate 6to4 anycast gateways and potentially invite non-customer, and thus non-paying, traffic to route through their network. Considered as a transition mechanism, the fact that 6to4 works better for two 6to4 LANs communicating over IPv4 (where packets can be routed directly) than between 6to4 and native IPv6 (which requires anycast proxies) was a real deal-breaker. It encourages a dependency on tunnelling via IPv4 rather than a transition to a native IPv6 internet.

6rd, fortunately, has none of these drawbacks, though it does require support from the ISPs.

[goatinaboat]

How would it have possibly been backwards compatible? Plenty of routers and ip-aware switches have, in hardware, specified that ips are 32-bits, so anything that added more bits would necessarily break existing hardware, and thus not be backwards compatible.

Easy, just declare that the entire IPv4 address space is ::x.x.x.x in IPv6 and Bob’s your uncle. No idea why they didn’t do this other than sheer solipsism.

[jlgaddis]

> Easy, just declare that the entire IPv4 address space is ::x.x.x.x in IPv6 and Bob’s your uncle. No idea why they didn’t do this other than sheer solipsism.

They did [0,1]:

  The "IPv4-Compatible IPv6 address" was defined to assist in the IPv6
  transition.  The format of the "IPv4-Compatible IPv6 address" is as
  follows:

  |                80 bits               | 16 |      32 bits        |
  +--------------------------------------+--------------------------+
  |0000..............................0000|0000|    IPv4 address     |
  +--------------------------------------+----+---------------------+

  Note: The IPv4 address used in the "IPv4-Compatible IPv6 address"
  must be a globally-unique IPv4 unicast address.

  The "IPv4-Compatible IPv6 address" is now deprecated because the
  current IPv6 transition mechanisms no longer use these addresses.
  New or updated implementations are not required to support this
  address type.

--

[0]: https://tools.ietf.org/html/rfc4291#section-2.5.5.1

[1]: https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...

[wmf]

This sounds like it works but when you get into the details it gets ugly.

http://archive.is/eHvKF

HN discussion: https://news.ycombinator.com/item?id=10854570