4 ms·

> But you don't, because you can't use the "extended" express space until every single router everywhere supports it Let's break that down into two cases: 1.

by yholio 5y ago

> But you don't, because you can't use the "extended" express space until every single router everywhere supports it Let's break that down into two cases: 1. Hierarchically routed address, that "split" existing IPv4 addresses into say, a /32 domain for each IPv4. Since the routing is hierarchical, all the infrastructure needs to know is how to route to the upper (IPv4) part of the address. They are not concerned with interpreting the lower part, so as long as they pass along IP options you can have IPng "islands" that use the lower extended space, connected via the regular IPv4 Internet. This removes the need for the state-full NAT hacks, so while not a solution to address space exhaustion, it's a good feature promoting adoption. 2. Fully extended 128 bit addresses using the upper, say, 64 bits. These clearly cannot be routed to non-compliant IPv4 routers... but isn't that true for IPv6 also? It would make no sense for an IPng router to route such a packet to an IPv4 router knowing it would not be understood and would lead to misroutes. So two extended endpoints will be able to connect only when a full IPng route can be found between them, not when every router on the internet is upgraded.

lmm 5y ago
> It would make no sense for an IPng router to route such a packet to an IPv4 router knowing it would not be understood and would lead to misroutes. So two extended endpoints will be able to connect only when a full IPng route can be found between them, not when every router on the internet is upgraded. Right, but how do you implement that? The IPng router only knows other routers by their addresses - it doesn't know which ones support IPng and which don't (and even if knows at a given point in time, how will it know if the router at a given address fails over or changes configuration?). The only way to make this work is to ensure that the IPng network is completely segregated from the IPv4 network - which is exactly what's being complained about with IPv6!
- yholio 5y ago
  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. 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. 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.
  - lmm 5y ago
    > 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.
    - deleted 5y ago
      [deleted]
    - yholio 5y ago
      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.

by yholio 5y ago

lmm 5y ago

> It would make no sense for an IPng router to route such a packet to an IPv4 router knowing it would not be understood and would lead to misroutes. So two extended endpoints will be able to connect only when a full IPng route can be found between them, not when every router on the internet is upgraded. Right, but how do you implement that? The IPng router only knows other routers by their addresses - it doesn't know which ones support IPng and which don't (and even if knows at a given point in time, how will it know if the router at a given address fails over or changes configuration?). The only way to make this work is to ensure that the IPng network is completely segregated from the IPv4 network - which is exactly what's being complained about with IPv6!

yholio 5y ago
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. 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. 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.
- lmm 5y ago
  > 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.
  - deleted 5y ago
    [deleted]
  - yholio 5y ago
    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.