5 ms·

How does a host that thinks there are only 4 billion addresses send a packet to a host with an address that falls outside of the 32 bit v4 space? This is a fun

by growse 3y ago

How does a host that thinks there are only 4 billion addresses send a packet to a host with an address that falls outside of the 32 bit v4 space? This is a fundamental problem. Backwards compatibility (without introducing translation schemes and middleboxes) is literally impossible.

rini17 3y ago
Extending address is fully possible, and if we drop requirement that the extended part be individually routable, even simple. But no, someone said we must redo whole stack and we need every piece of sand to have public routable address..so now we are stuck between rock (old fossilized IPv4) and hard place (completely incompatible IPv6).
- growse 3y ago
  You're inventing a new addressing scheme, and proposing that we put a bunch of middleboxen in to mediate connecting the old world to hosts on this new addressing scheme. You're re-inventing IPv6.
  - rini17 3y ago
    No, I describe existing practice with NAT where you in fact have IP addresses extended by TCP/UDP port numbers. You could instead move this "port" directly into IP header in backward-compatible way and fall back to stateful NAT only if the counterparty does not support it.
    - growse 3y ago
      A device that doesn't understand your newly invented addressing scheme would need to rely on some other intermediate device in order to get traffic to an endpoint that does support your new scheme. You're using different words, but you've got a separate addressing scheme, and dependence on proxies to enable everyone to talk to each other. This is exactly where we are with IPv6. > You could instead move this "port" directly into IP header in backward-compatible way If you're changing the meaning of the headers, it is by definition not backwards compatible.
    - simiones 3y ago
      No, you can't: an IPv4-only device that receives that packet would interpret your extra address bytes as part of the TCP/UDP header. There simply isn't any room in the IPv4 header to squeeze extra bytes in. That is exactly why NAT baked knowledge of TCP & UDP into routers, breaking the layering design in the process. If there were any way to add extra headers to IPv4 without relying on middle boxes to support it, it would have been done a long time ago.
      - rini17 3y ago
        Not true. There is Options field to extend IPv4 header. And only server and the router closest to user would need to support such extension, keeping layering violations to minimum.
- throw0101c 3y ago
  > Extending address is fully possible, and if we drop requirement that the extended part be individually routable, even simple. No it is not: * You also have to deploy new DNS code to handle a new record type to handle longer "IPv4+" addresses. * You also have to deploy new OS and library code with new socket, etc, APIs because all in_addr_t definitions and data structures are 32-bit-only. If a public service has a "IPv4+" address, how does a not-IPv4+ host, or not-IPv4+ compliant code handle it? If you want >4B addresses you have to tweak all the code that touches address structures. You have to (re)deploy code on all the network elements that touch the packet bits: all the end-user applications (browsers, chat clients, etc), all the end-user operating systems, all the middle-boxes, all the routers. If you have network devices and segments between the public service and the client that are not IPv4+ compliant, you have to configure the clients to send the IPv4+ traffic to translation boxes that are IPv4+ compliant. Basically all the stuff that is happening with IPv6.

by growse 3y ago

rini17 3y ago

Extending address is fully possible, and if we drop requirement that the extended part be individually routable, even simple. But no, someone said we must redo whole stack and we need every piece of sand to have public routable address..so now we are stuck between rock (old fossilized IPv4) and hard place (completely incompatible IPv6).

growse 3y ago
You're inventing a new addressing scheme, and proposing that we put a bunch of middleboxen in to mediate connecting the old world to hosts on this new addressing scheme. You're re-inventing IPv6.
- rini17 3y ago
  No, I describe existing practice with NAT where you in fact have IP addresses extended by TCP/UDP port numbers. You could instead move this "port" directly into IP header in backward-compatible way and fall back to stateful NAT only if the counterparty does not support it.
  - growse 3y ago
    A device that doesn't understand your newly invented addressing scheme would need to rely on some other intermediate device in order to get traffic to an endpoint that does support your new scheme. You're using different words, but you've got a separate addressing scheme, and dependence on proxies to enable everyone to talk to each other. This is exactly where we are with IPv6. > You could instead move this "port" directly into IP header in backward-compatible way If you're changing the meaning of the headers, it is by definition not backwards compatible.
  - simiones 3y ago
    No, you can't: an IPv4-only device that receives that packet would interpret your extra address bytes as part of the TCP/UDP header. There simply isn't any room in the IPv4 header to squeeze extra bytes in. That is exactly why NAT baked knowledge of TCP & UDP into routers, breaking the layering design in the process. If there were any way to add extra headers to IPv4 without relying on middle boxes to support it, it would have been done a long time ago.
    - rini17 3y ago
      Not true. There is Options field to extend IPv4 header. And only server and the router closest to user would need to support such extension, keeping layering violations to minimum.
throw0101c 3y ago
> Extending address is fully possible, and if we drop requirement that the extended part be individually routable, even simple. No it is not: * You also have to deploy new DNS code to handle a new record type to handle longer "IPv4+" addresses. * You also have to deploy new OS and library code with new socket, etc, APIs because all in_addr_t definitions and data structures are 32-bit-only. If a public service has a "IPv4+" address, how does a not-IPv4+ host, or not-IPv4+ compliant code handle it? If you want >4B addresses you have to tweak all the code that touches address structures. You have to (re)deploy code on all the network elements that touch the packet bits: all the end-user applications (browsers, chat clients, etc), all the end-user operating systems, all the middle-boxes, all the routers. If you have network devices and segments between the public service and the client that are not IPv4+ compliant, you have to configure the clients to send the IPv4+ traffic to translation boxes that are IPv4+ compliant. Basically all the stuff that is happening with IPv6.