>The primary purpose of IPv6 was to expand the address space of IPv4.
I wish this were all it did. People can make arguments about IPv6 being "simpler," but it's often not simpler in practice:
- You still need to run dual-stack
- You need to re-learn a lot of your networking fundamentals
- Despite IPv6 being effectively infinite, most ISPs will not give you a static IP
- Most hardware is built for IPv4 and NOT IPv6
- Local subnetting is far more complicated. Not just due to the the length of the address, but due to the fact that you often need to work out SLAAC and/or have a local DNS service to handle the address changes.
IPv4-Compatible IPv6 address are deprecated, because people can use IPv6 to circumvent IPv4 NAT firewalls, so OS vendors asked to ban this behavior. It's also confusing to people when they can call both IPv4 and IPv6 at the same time:
$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.043 ms
# OK
$ ping6 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.063 ms
# OK
$ ping ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.023 ms
# OK
$ ping6 ::ffff:127.0.0.1
PING ::ffff:127.0.0.1(::ffff:127.0.0.1) 56 data bytes
ping6: sendmsg: Invalid argument
# CONFUSING & DANGEROUS
Just think how much simpler it would have been to keep all the IPv4 tooling with just an ifdef to make the addresses wider, and a few version changes for IP and ARP.
Part of what makes V6 adoption lag is that it took a while to be supported across the board by router vendors, OS vendors, etc. And a lot of the reason for that is all the gratuitous changes from IPv4.
Around 1990~1991, the TUBA proposal was already ready to go with two implementations (one on hardware router), bringing addresses to iirc either 160bits or 144 bits (don't recall exactly, been long time). Might have been better if they went for 144 bit host name and embedded port numbers in the last 2 bytes, but the point was to run TCP and UDP close to unchanged.
Then IPng got started and for most of 1990s IETF played with sweeping changes while "temporary solution" that was IPv4 entrenched itself in worse and worse ways.
I was an undergrad then, and wasn't really aware of this sort of thing. I just went and read the TUBA RFC (rfc1347), and it looks like CNLP was no walk in the part either. From the RFC:
CLNP contains a number of optional and/or variable length fields. For example, CLNP allows addresses to be any integral number of bytes up to 20 bytes in length
Did anybody advocate for the simple approach of just expanding the in_addr from 32 to 64 bits, calling it IPv5 and being done with it? That's what I think would have been the right thing to do..
It would still be incompatible with IPv4. It couldn't have avoided the complexity of a prolonged dual stack situation. So it would have had at least comparable deployment complexity.
And when you're incompatible anyway, why wouldn't you at least simplify headers and global routing? BGP has always been on the verge of imploding.
A backwards compatible IPng had been great, but no credible design was ever put forward.
No credible design is possible, because when people ask for a backwards-compatible IPng what they're really asking for is a forwards-compatible IPv4, and they can't have it because v4 isn't forwards compatible.
IPv6 is backwards compatible with v4 in a great many different ways. You've got dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6... you could make a reasonable argument that it has too many methods of backwards compatibility, even. But obviously v4 isn't forwards compatible with it, because v4 isn't forwards compatible with any longer address length, and the time to fix that was in the 70s.
That's not something that can be changed without replacing v4. In fact, if it could be, we wouldn't need a new protocol in the first place.
A big chunk of the problem was the BSD Sockets, which unlike TLI/XTI leak implementation details like crazy, meaning every BSD Sockets application effectively hardcoded IPv4 behaviours.
Gratuitous changes to "fix" things is exactly why adoption took forever. Look at nonsense like IPv6 extension headers. The number of extension headers is UNBOUNDED. This is HORRIBLE to deal with in hardware, and not pleasant in software.
I wish this were all it did. People can make arguments about IPv6 being "simpler," but it's often not simpler in practice:
- You still need to run dual-stack - You need to re-learn a lot of your networking fundamentals - Despite IPv6 being effectively infinite, most ISPs will not give you a static IP - Most hardware is built for IPv4 and NOT IPv6 - Local subnetting is far more complicated. Not just due to the the length of the address, but due to the fact that you often need to work out SLAAC and/or have a local DNS service to handle the address changes.