Maybe it's me, but I think IPv6 should have been 8 bytes instead of 16 and somewhat backward compatible with IPv4.
Like how 2-byte Unicode was struggling and UTF-8 saved it.
Like how 2-byte Unicode was struggling and UTF-8 saved it.
You don't state why you think this, but this is almost always due to the flawed thinking that the IP address is a simple identifier, and then looking at "how many IPs does the world need?" → "64 bits is enough". (IPs are like street addresses, in that they're routing instructions. Having the space not fragment — like v4's space is doing — is part of it, and helps things like routing tables remain small.)
> and somewhat backward compatible with IPv4.
The pigeon-hole principle makes backwards compatibility impossible. No matter what concrete scheme you might propose, it is effectively equivalent to IPv6.
8 versus 16 bytes barely matters for using the addresses, especially because if you're assigning IPs to your devices you can have the second half of the address start with 6-7 zero bytes and collapse them all with ::
And I challenge you to name a way to be "somewhat backward compatible" that would actually function and IPv6 doesn't already do.
Edit: And not only can you make your own addresses short, if I look up some IPv6 addresses meant to be said/remembered (public DNS IPs), none of them make you type more than 8 bytes (and that one repeats a cluster to make it easier) and some make you type as little as 4 bytes.
Remembering and communicating mildly complex byte sequences should be an issue which is solved already.
It is solved already, it's called DNS.
IPv4 addresses are not any more difficult to remember than phone numbers, but the same can't be said of IPv6.
The other 4 billion people on the planet don't really need internet connections do they?
Doubling the address space is a good strategy when you need more. Quadrupling it is over-engineering.
64 bits are already a pain in the ass to remember, and if you have specific memorization needs you can use small static IPs so that even with 128 bits available you only use about 64 of them.
New L3 protocols on the Internet are firmly on the "incredibly difficult and time consuming" side.
Google and other big players go to huge lengths to build new Internet protocols on top of UDP because enough of the internet drops or mangles anything other than TCP or UDP that it's effectively impossible to use anything else on the Greater Internet. IPvNext by way of backwards-compatible IPv4 was (and continues to be) no easier than doing something that's backwards-incompatible.
As a bonus, doing the backwards-incompatible thing bypasses all the bad behavior of existing shitty middleboxes and crummy ASICs.
> backwards-compatible would have gotten us there that much sooner
v6 is already backwards compatible. Between dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6 and probably other things I'm forgetting, you could make a reasonable argument that it's too backwards compatible, even.
If you meant "v4 being forwards-compatible would have gotten us there sooner", then yes, I agree. It's unfortunate it's not. That's entirely v4's fault though, not v6's.
How would it be at all backward compatible other than what NAT64 already does?
Any time you would reference an IPv4 address when v6 enabled, the stack would simply fill in the remaining bits and forward your packets down the line.
This had to have been thought about though, and I suspect the architects of v6 felt it would've been sub-par to what we have. No idea if that's true though.
They actually went with 64:ff9b::/96 as the default (though IPv6 is so big that you can just pick another area if you want in ULA space or whatever).
> Any time you would reference an IPv4 address when v6 enabled, the stack would simply fill in the remaining bits and forward your packets down the line.
There are actually multiple implementations, depending on OS and whether you want it in kernel space or user space.
> This had to have been thought about though, and I suspect the architects of v6 felt it would've been sub-par to what we have. No idea if that's true though.
They thought about it, named it NAT64 ( https://en.wikipedia.org/wiki/NAT64 ), published it, and it's in wide use. It frequently is combined with 464XLAT ( https://en.wikipedia.org/wiki/IPv6_transition_mechanism#464X... ) to make the transition mostly invisible to users/applications.
::ffff:0:0/96 IPv6-mapped This space is intended for an OS or network stack to map IPv4 addresses towards higher layers, so applications could technically be IPv6 only. The packet was/will be standard IPv4 when it reaches the network wire.
::/96 and ::ffff:0:0:0/96 IPv6-compatible/IPv6-mapped These were originally intended to be used on networks to differentiate IPv4 addresses depending on the capability of the target and decide who will do the translation. These are now deprecated, but the whole ::/8 is reserved, and these addresses are promised to never be assigned to anything else.
64:ff9b::/96 IPv6-translated This is the space for IPv6 to IPv4 NAT translators. Actually the whole /48 is reserved, so you can run address multiple private translators in a single network if required. This is widely used and supported.
As a side note Teredo addresses (2001::/32) and 6to4 addresses (2002::/16) all embed the entire IPv4 address space, although they are more complex than a simple 1-to-1 mapping. They are rarely used.