Biggest mistake for IPv6: It's not backwards compatible, developers admit

[Benny Amorsen]

Fred Baker <fred at cisco.com> writes:

> Also, I think it is only fair to point out that they didn't have the
> option of making it backwards compatible with IPv4; it's not that they
> didn't, it's that they couldn't. How, precisely, would you make an
> IPv4 packet that has longer addresses? IPv4 forces any change to the
> header to become a new protocol.

It doesn't, in hindsight.

You could have added extra, optional fields to the IP header, containing
extra source or destination IP addresses. NAT devices would then move
the original IP address into the new src ip address header and put the
NAT-address into the src ip address. If the host at the remote end
understood the extra header, it would copy it into the extra dst ip
address header of the return packet, and the NAT would know where to
send the packet without connection tracking. This mechanism would also
make it possible to directly address hosts behind NAT. If a particular
host doesn't understand the new header fields, it should simply ignore
it, and the NAT then has to handle the packet using connection tracking.

Advantages: Routers don't need to be upgraded at all, except for NAT
routers (and those are commonly upgraded already, unlike core routers).
Host IP stacks would need upgrading, but most services would still work
between old hosts and new hosts (and host IPv6 stacks have turned out to
be ready way ahead of everything else). Applications would need a few
tweaks for full functionality, but legacy applications would still work.

It would be a lot uglier than the shiny IPv6 future, but it could be
done, and it would mean that there would always be more content
available for an upgraded host/network than for the legacy
hosts/networks.


/Benny