> Maybe I don't see the full complexity, but it seems to me like an implementation detail, when setting up the routing tables to discover IPng capability, for example using a dedicated ICMP structure. Compared to upgrades required for BGP etc., this is trivial.
I don't see how you could ever discover a reliable route, because when a packet is routed to the right place you can never know whether it was routed correctly because all the hosts in between understood IPng or it was accidentally routed to the correct place by an IPv4 router - in which case packets following the same route will likely get misrouted as that router's routing decisions change in response to shifting load etc.. You'd have to have a kind of ICMP structure that was never routed by IPv4 routers - but then we're right back to having a completely segregated IPng network.
> IPv6 is in a way "naturally protected" against such a "short-circuit" due to the different structure and IP version of the packet, but fundamentally it's the same problem, you can't expect an IPv4 box to understand it.
Right, but that's much easier to deal with. If you have IPng as an extension of IPv4 then you're practically guaranteed nondeterministic routing loops that affect some but not all packets, and that's much harder to deal with than just not having a route.
> The fundamental complaint against IPv6 is that it requires operator intervention on each internet connected box to operate. Whereas a virtual IPng mesh over existing infrastructure could be automated completely, when a box is upgraded it will respond to ICMPs from peers and start seeing the extended space.
What's the part that makes a difference? People have experimented with things like silently enabling IPv6 on an OS upgrade; the reason it's a bad idea is that some percentage of IPv6 routers etc. will be misconfigured, and that would still be the case with IPng.
While I don't want to go into the woods with this, those don't seem to be show stoppers, just minor technical issues somebody skilled in the art would have been able to solve some 25 years ago.
For example, the discovery protocol can be tuned so that no legacy box has any reason to forward the packet, say using TTL=1 etc., while extended boxes will recognize the magic datagram and take apropriate action. Routing loops would not form if they don't exist already, the extended links are, at most, a subset of the non-looping topology already established - you can't turn a tree into a ring by removing branches.
> What's the part that makes a difference?
The most important lesson of the IPv6 mess is that things that need to be explicitly configured to work will always break, in a vicious circle of "nobody uses that, so don't bother, so nobody can use it". So any friendly upgrade path should require zero configuration to interoperate gracefully with both IPv4 and the new protocol. You should configure only the features you want to use - say, extended address space.
Clearly IPv6 fails this test. Because you can't rely on any local IPv6 connection to actually deliver connectivity, you can't simply make IPv6 the default, since it will break many installations.
When you upgrade the software on your equipment to IPng, the existing IPv4 connection becomes an IPng connection. Depending on the capability of upstream, you will be able to use some or all of the IPng features, but existing functionality will never break.
Routers that upgrade don't require any special configuration, in the absence of extended routes they pass-through trafic obliviously, yet they are ready from day one to work with extended routes if any are published. Whereas an IPv6 router is essentially two distinct routers into one, the IPv6 part is useless without sysadmin attention, more attack surface.
This aspect of zero configuration, plug and play compatibility both backward and forward, is fundamental. Almost any hardware you can find on the internet today is IPv6 capable, sometimes for decades, yet nobody can be bothered to configure them to work on the weird parallel internet to which no customers are demanding access.
> For example, the discovery protocol can be tuned so that no legacy box has any reason to forward the packet, say using TTL=1 etc., while extended boxes will recognize the magic datagram and take apropriate action.
At that point discovery is following different routing rules from regular packets, which isn't going to work. You could set the same magic flag on all next-gen packets, but then we're right back to having separate networks.
> Routing loops would not form if they don't exist already, the extended links are, at most, a subset of the non-looping topology already established
In that case the whole thing is completely pointless? The whole point of all this is to be able to have more routing destinations than IPv4.
> When you upgrade the software on your equipment to IPng, the existing IPv4 connection becomes an IPng connection. Depending on the capability of upstream, you will be able to use some or all of the IPng features, but existing functionality will never break.
> Routers that upgrade don't require any special configuration, in the absence of extended routes they pass-through trafic obliviously, yet they are ready from day one to work with extended routes if any are published. Whereas an IPv6 router is essentially two distinct routers into one, the IPv6 part is useless without sysadmin attention, more attack surface.
This is concretely the same for IPv4+IPv6. The difference between "routing to IPv4 addresses over IPv4 only" and "routing according to the new system" is just as big whether you call it a new protocol or call it an extension to an existing protocol.
There's no way to let legacy hosts connect to hosts that don't have IPv4 addresses. There's no way to let hosts that don't have IPv4 addresses connect to legacy hosts (except for NAT or equivalents like DS-Lite). The only thing backwards compatibility can ever do is let hosts with IPv4 addresses use your protocol to communicate with other hosts with IPv4 addresses - but there's no motivation for those hosts to upgrade since they can already use IPv4.
> This aspect of zero configuration, plug and play compatibility both backward and forward, is fundamental. Almost any hardware you can find on the internet today is IPv6 capable, sometimes for decades, yet nobody can be bothered to configure them to work on the weird parallel internet to which no customers are demanding access.
Every possible solution makes hosts without IPv4 addresses a weird parallel internet, there's no getting away from that, and so as long as IPv4 addresses were available adoption was always going to be an uphill struggle. IPv6 at least delivers benefits to users without requiring every router on the internet to upgrade first - as soon as there's one server with an IPv6 address then clients have a reason to upgrade, and vice versa. Technically-minded gamers and voice-chatters do make the effort to enable IPv6, or even ask their ISP to enable it. It's not much, but it's a bigger incentive than exists for IPng.
I don't see how you could ever discover a reliable route, because when a packet is routed to the right place you can never know whether it was routed correctly because all the hosts in between understood IPng or it was accidentally routed to the correct place by an IPv4 router - in which case packets following the same route will likely get misrouted as that router's routing decisions change in response to shifting load etc.. You'd have to have a kind of ICMP structure that was never routed by IPv4 routers - but then we're right back to having a completely segregated IPng network.
> IPv6 is in a way "naturally protected" against such a "short-circuit" due to the different structure and IP version of the packet, but fundamentally it's the same problem, you can't expect an IPv4 box to understand it.
Right, but that's much easier to deal with. If you have IPng as an extension of IPv4 then you're practically guaranteed nondeterministic routing loops that affect some but not all packets, and that's much harder to deal with than just not having a route.
> The fundamental complaint against IPv6 is that it requires operator intervention on each internet connected box to operate. Whereas a virtual IPng mesh over existing infrastructure could be automated completely, when a box is upgraded it will respond to ICMPs from peers and start seeing the extended space.
What's the part that makes a difference? People have experimented with things like silently enabling IPv6 on an OS upgrade; the reason it's a bad idea is that some percentage of IPv6 routers etc. will be misconfigured, and that would still be the case with IPng.