6 ms·

You can easily fit 128 bit addresses into an IPv4 header - or you could in the 90s, before filtering out IP options became more widespread. See in this thread m

by yholio 5y ago

You can easily fit 128 bit addresses into an IPv4 header - or you could in the 90s, before filtering out IP options became more widespread. See in this thread my comment on how you could arrange the header and address to make this work. Legacy systems will route based only legacy part of the IP - that's the whole point of a backward compatible extension - and you will see the benefits of the extended address space when major infrastructure upgrades, just like in IPv6. The key difference is that you don't have to maintain two stacks, 128 bit addresses are enabled by simply upgrading existing IPv4 infrastructure with zero operator involvement: you upgrade the software on your IPv4 server and it's suddenly reachable by clients with addresses outside the IPv4 range, with the only condition that all intermediary routers preserve IPv4 options.

lmm 5y ago
> you will see the benefits of the extended address space when major infrastructure upgrades, just like in IPv6. But you don't, because you can't use the "extended" express space until every single router everywhere supports it (since routing is dynamic and your packets might go via anywhere). Whereas with IPv6 as soon as there's an upgraded path between two points, they can gain the benefits of having individual addresses and not needing NAT.
- 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.

by yholio 5y ago

lmm 5y ago

> you will see the benefits of the extended address space when major infrastructure upgrades, just like in IPv6. But you don't, because you can't use the "extended" express space until every single router everywhere supports it (since routing is dynamic and your packets might go via anywhere). Whereas with IPv6 as soon as there's an upgraded path between two points, they can gain the benefits of having individual addresses and not needing NAT.

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.