Did you mean to compare Tor to the World Wide Web?
They are different protocols but they are not disjoint address spaces.
You add 96 bits to the address and boom it's converted.
15-20 years ago IPv6 routing was often tunneled over v4, and it was noticeably less reliable than v4. Nowadays v6 is a touch faster/more reliable than v4, not very much. If that difference widens much and most users have v6 anyway, then v4 might get the axe. Otherwise... I don't think so.
FWIW I already operate some v6-only services. Not for the general audience. An SSH bastion host, a backup service, that kind of thing, not web sites for the general audience. I'm not in the least surprised if some warez topsite is v6-only already.
It would be really really great if true, unfortunately this is not correct.
IPv6 SHOULD have been this way, but The Powers That Be took it as an opportunity to "correct" other IPv4 issues and now we have what we have.
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?
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.
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?
But it's technically quite ugly, and tunnelling/MTU-related problems would be more prevalent.
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.
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.
6rd, fortunately, has none of these drawbacks, though it does require support from the ISPs.
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...
HN discussion: https://news.ycombinator.com/item?id=10854570
(Genuinely interested in hearing war stories from the front on this)
That's just for IPv6 support, which is beta, and took years to get there. Dual Stack is still in alpha, and that didn't appear until a really recent release (1.16).
I think routers and switches are probably the easier pieces of the puzzle, at least as far as managing them goes. The vendors have worked out all the kinks (hopefully?) before the equipment gets to you.
That's just to get the stuff to work. Then you have corporate/government policies and validation. Then you have to solve problems like "My VM resolves things to IPv6 by default, but I have no IPv6 gateway so everything times out". And then make sure that logic makes it up through your entire stack. Multicast? Not allowed on many networks.
Is it the end of the world? No. It's just a lot of extra work for everyone.
Someday, hopefully!
IPv6 is backwards compatible so why would we "finally roll off IPv4"? IPv6 has been "here" in production for over a decade, and has seen slow adoption. I suspect it may be another 8-10 years until IPv6 gets close to a majority, but wouldn't IPv4 still be in-use?
What would force a roll off of IPv4?
Either way, I too would like to know more about how IPv4 space has appreciated/depreciated in the past decade