Hacker News new | ask | show | jobs
by Dagger2 58 days ago
I said "whenever anybody says it's bad and tries to come up with a better alternative, they end up coming up with something equivalent to IPv6", and that's what you did here. And as predicted, it was 6to4 you reinvented.

v4 extension headers are well known to get your packets dropped on the Internet, so they're a non-starter, but there's another extension mechanism you can use: you can set the "next protocol" field to a special value, then put the extended address at the start of the payload, followed by the original payload. This is functionally identical to using extension headers, but using a mechanism that doesn't get your packets dropped.

Far from not being seriously considered, this approach was adopted in v6 as RFC 3056.

> Except after the upgrade, there'd be no parallel system.

No. You get a parallel system because v6 addresses are too big to work with v4. Even if you used extension headers, v6 addresses would still be too big to work with v4. Whatever you do, v6 addresses are too big to work with v4. You WILL get a parallel system, and there's no way around this other than not making the addresses bigger.

1 comments

The hopes were for a converged software stack, but the candidates were all parallel protocols competing with IPv4. A full transition would end with the extinction of IPv4. Upgrading IPv4, quite apart from the brass tacks of the wire format, would have entailed variable-length addresses and even the idea of starting a new protocol with 64-bit addresses with an upgrade path was considered far too scary at the time. That was only one of a slew of non-technical requirements imposed from above for future proofing, NIH paranoia, vague security promises and politics in general.

A decade later, when IPv6 had real-world deployments was far to late for 6to4 to save the day: entirely because a swath of non-6to4 addresses existed and needed to be reachable. Given no strategic gain apparent for upgrading the commercial core, aligning financial interests by upgrading past the edge instead would absolutely have made sense. Unfortunately the hard parts the engineers anticipated in the early 90s were not the ones that held IPv6 back.

In summary, I agree: 6to4 could have been great!

Yes, of course they were all parallel protocols -- because your problem here is that v4 doesn't _have_ variable-length addresses. It's trivial to imagine a version of v4 that does, but that version would also be a parallel protocol to the version of v4 we actually have.

> even the idea of starting a new protocol with 64-bit addresses with an upgrade path was considered far too scary at the time

No it wasn't? Every proposal had an upgrade path. Having one was a mandatory requirement.

You can read the requirements document yourself: https://datatracker.ietf.org/doc/html/rfc1726. To me, it looks like these requirements were decided by the community rather than being imposed from above, but either way you can see that having a simple transition from v4 is listed right there.

> A decade later, when IPv6 had real-world deployments was far to late for 6to4 to save the day: entirely because a swath of non-6to4 addresses existed and needed to be reachable

What I'm hearing is that the compatibility with v4 that 6to4 provides wasn't considered important, and not by people in any position of authority but rather by the actual people choosing what to deploy on their own networks. Even though there were more 6to4 hosts than non-6to4 ones, and even though 6to4 doesn't prevent you from reaching those non-6to4 hosts, people still didn't want it.