[FullyFunctional]

I find DJB's take on this interesting: https://cr.yp.to/djbdns/ipv6mess.html

EDIT: Dan has many excellent points, but I'd like to quote my favorite:

The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.

Indeed, what were they thinking!

It's certainly an undeniable fact that IPv6 adoption has been a disaster, taking much longer than hoped for. Frankly, I expect to see IPv4 coexist with IPv6 for the next hundred years - not ideal.

[zkms]

> The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.

I respect djb and his contributions to cryptography, but he is off base here. The sin was committed when IPv4 was made and not initially designed to allow for variable / expanded address space.

Adding an IP Option to IPv4 packets that could carry extra address bits was not an option either -- IP options aren't preserved much at all on the Internet. Furthermore, even if most routers didn't drop IP options, adding "v6" address space via IP option in a packet that old/v4-only devices would nevertheless attempt to parse would have been hell operationally.

IPv6 has lots of flaws/idiosyncrasies/weirdnesses (multicast, mobility, slaac, ndp, etc.) that only looked good in the 90s, that definitely made ipv6 adoption a lot more painful than it needed to be, and ended up as difference for just difference's sake; but the one thing that was unambiguously done right with v6 was a completely clear separation of address spaces from IPv4.

[oasisbob]

I think anyone who thinks DJB's proposal was a realistic easy option needs to look at the history of the class E address space (240.0.0.0/4), and the proposals to allocate it for normal use.

Despite not changing the address length at all, the idea of doing this was abandoned because of the widespread compatibility problems across different OSes.

Sure, you could hand-wave another layer of NAT to "fix" it, just like the extended address proposals.

Hell, even using MAC addresses which begin with a number devices haven't seen before is enough to cause issues, despite following the existing standards: https://news.ycombinator.com/item?id=13090945

And all the existing NAT / firewall / middleware devices - they're supposed to handle the extensions transparently? Having seen the many ways that ASA protocol / application fixup can mangle packets - I find it very hard to believe.

[cesarb]

One thing I never understood in these proposals: how would two computers, one with only an extended address and the other with only an IPv4 address, talk to each other? Or two computers with extended addresses, but with a single router in the middle of their path which doesn't understand extended addresses?

All these proposals I've seen appear to assume that extended addresses start being distributed only after every or almost every host and router in the whole world had all of its software upgraded to understand extended addresses. But that's not realistic, since without being able to actually use it, there would be no incentive to modify every single piece of network-facing software and hardware to be able to use extended addresses. It's a Catch-22.

[FullyFunctional]

There are two issues in migration: updating software and updating configuration. The former can be completely trivial if you are just pulling down updates from someone else. The latter requires effort on your part. If the IPv6 address space had been an extension, then you wouldn't have to do any configuration to support IPv6 clients while you maintain your existing 32-bit address, valid for both stacks.

At least that's my understanding of it.

[keeperofdakeys]

For a new transport layer protocol like QUIC, this can work. However when you start talking about IP, you need to update/replace basically every device on the internet. If a device in the path doesn't know about the extended address space, that packet probably can't reach it's destination.

[FullyFunctional]

? You have to upgrade the software on all devices to move to a larger address space. That's understood. What we are discussing here is the added complexity of the configuration. Updating the software is easy by comparison.

[lisper]

> One thing I never understood in these proposals: how would two computers, one with only an extended address and the other with only an IPv4 address, talk to each other?

Via a NAT router that talks v4 on one side and v6 on the other.

[cesarb]

A NAT router is not enough. Suppose the v4 side wants to initiate the communication; to which address would it send the initial packet? Remember, the "v4 side" has no concept of extended addresses at all, for it every address must be 32 bits and nothing more. And it also doesn't solve the "v4 router in the middle of the path" problem.

[lisper]

> A NAT router is not enough. Suppose the v4 side wants to initiate the communication.

The router would also need to act as a DNS server and translate v6 responses into dynamically assigned v4 addresses. Routers routinely do this sort of thing today for captive portals.

[zlynx]

v4 systems can only talk to other v4 systems.

If there's a system that has only v4, it can tunnel v6 packets out to a tunnel gateway that will unwrap and forward them.

There are other protocol-specific tricks, like v4 DNS records that resolve to a HTTP reverse proxy, which forwards based on hostname and path to the real v6 server, while the v6 DNS records point directly to the v6 server.

[lisper]

> v4 systems can only talk to other v4 systems.

That depends on what you mean. A v4 packet can only be delivered unaltered to a v4 stack. But one can build a proxy server that tunnels TCP and UDP from a v4 network to a v6 network, so data can be passed from a v4 system to a v6 system without any software changes at either end.

[phicoh]

If you assume that IPv6 adoption is only due to IPv4 address shortage, then the rate of adoption makes a lot of sense. Whatever alternative to IPv6 you can come up with, as long as there is plenty of IPv4 space, nothing will happen. Unless you can find a killer app in a different area, which hasn't happened.

Now that you have to buy IPv4 addresses at around $10 for a single address, the game has changed.

With carrier grade NAT, content has to slowly migrate to IPv6 for geo-location reasons. Any content that sees a high amount of abuse also has to avoid CGN.

Once big parties like google, facebook, etc. have a lot of traffic on IPv6, it stops making sense for them to invest in IPv4. So they will try to pressure ISPs into offering IPv6. Likewise, if an ISP sees that big content providers are on IPv6, then it stops making sense to invest in IPv4. Pressuring smaller content providers to offer IPv6.

And then IPv4 joins the ranks of IPX, NetBIOS, Apple Talk. Some pockets may continue to exists, but the rest of the world has moved on.

[mvkg]

IPv10[0] makes IPv4 an extension of the IPv6 space. It'll be interesting to see if this takes off, but it doesn't really seem to solve the whole problem. All nodes in the path would have to support IPv10 for it to work.

[0] https://datatracker.ietf.org/doc/draft-omar-ipv10/

[zkms]

The internet-draft you linked is not a proposal that anyone should take seriously. Here is an actual, non-mocking review of that I-D: https://www.ietf.org/mail-archive/web/int-area/current/msg05... . To put it diplomatically, that author does not seem to have a proper understanding of IPv6 deployment nor of any relevant prior art.

There is neither "rough consensus" (besides that the author should have their posting privileges on the IETF lists removed) and certainly not any "running code". They've been trying to get IETF people to care about their harebrained "IPv10" scheme since November 2016; that they have yet to realise that their scheme is useless and that nobody seriously cares is about as depressing as seeing that internet-draft getting cited.

The term "crank" (https://en.wikipedia.org/wiki/Crank_(person)) is applicable here.

[mvkg]

I was a bit surprised to see that it wasn't published on April 1 and got renewed multiple times.

Some parts of it are laughable such as

       IPv10 support on "all" Internet connected hosts can be deployed
       in a very short time by technology companies developing OSs
       (for hosts and networking devices, and there will be no
       dependence on enterprise users and it is just a software
       development process in the NIC cards of all hosts to allow
       encapsulating both IPv4 and IPv6 in the same IP packet header.

But it does have an interesting take on stateless IPv4 <-> IPv6 communication, specifically IPv4 -> IPv6. Obviously it wouldn't work as described without a full deployment, but it seems like something could be done there.

For instance, if an IPv4-only host wanted to communicate to an IPv6-only host, it could send packets to a well-known NAT46 anycast address with an IP option of the destination host. The NAT46 host could then create the IPv6 packet with the correct destination and IPv4-mapped source.

He suggested using the IPv4 routing table for IPv4-mapped IPv6 addresses, which wouldn't be loop-free unless every router was dual stack and did the same thing. However, with what I described, it seems like any dual-stack host (or router) could perform the translation in a loop-free manner.

[cesarb]

I just spent more time than I should have reading these threads (a bigger and more interesting one starts at https://www.ietf.org/mail-archive/web/int-area/current/msg05...). Fascinating. The author:

- Understands that the proposal requires that "anything [that] will process a L3 packet" be upgraded to understand the new packet format, but seems to believe it's a simple matter of making the OS developers (which are "few") "push new updates globally".

- Seems to believe having the proposal ratified by the IETF is both necessary and sufficient for the proposal to be adopted everywhere.

Edit: the author is now requesting that the internet-draft be removed from the database: https://www.ietf.org/mail-archive/web/ietf/current/msg103018...

[vidoc]

DJB's point is certainly valid, but in practice, while I had always shared the opinion that the Big Plan of all those committees to seamlessly migrate to IPv6 seemed a bit sketchy, in reality, it's worked quite well.

Funnily, having worked on adding dual-stack support to several pieces of software and protocols, my main grips with IPv6 remain how addresses are represented to humans. Despite compression and all, I realize there was no obvious way to make addresses easier to memorize and that's basically the price to pay to have a staggering 1'500 addresses per square meter of earth.

However, and it may sound a bit silly but I still consider that the choice of ':' as a separator was an unfortunate one, I'd have a hard time listing all the nasty implications it has in terms of parsing :)

[lisper]

I was just writing up my own comment to say exactly this when I noticed your comment. It's particularly unfortunate that ipv6 was not made backwards-compatible because it would not have been difficult to do: extra address bits could have been included in the options portion of the header. An IPv4 packet could be routed over an IPv6 network simply by setting the (missing) extended address bits to some canonical default value (most likely 0). The net result would be similar to an HTTP/1.0 client accessing an HTTP/1.1 server with multiple virtual servers running on it: accessing an IPv4 host at A.B.C.D would be the same as accessing an IPv6 host at A.B.C.D.0....0

Such a missed opportunity.

[kstrauser]

That post is incredibly obsolete. In reality, a big chunk of the Internet is already running IPv6 in production as we speak.

[FullyFunctional]

That comment is incredibly uninsightful. In reality, the majority of the Internet is still not on IPv6 meaning that you still can't make do (easily) with only an IPv6 connection. Dan's point are true regardless of the adoption rate.

[oasisbob]

Sure you can - many of us have phones in our pockets right now which are doing just that over LTE.

With an imaginary phone running with an imaginary v4 extended address, you'd still need something in the network at the carrier side to handle communications with legacy devices.

There's not much difference between that and having a v6-only device.