3 ms·

"Just widen the addresses" ideas like that are easy to come up with (though they usually keep the IPv4 address as either the prefix or the suffix of the "new" a

by cesarb 7y ago

"Just widen the addresses" ideas like that are easy to come up with (though they usually keep the IPv4 address as either the prefix or the suffix of the "new" address), but the elephant in the room is always the same: how would a legacy host which only understands classical IPv4 (with 32-bit addresses) talk to a host which only has "new" (wider than 32-bit) addresses?

deleted 7y ago
[deleted]
kazinator 7y ago
> how would a legacy host which only understands classical IPv4 (with 32-bit addresses) talk to a host which only has "new" (wider than 32-bit) addresses? Hosts with 64 bit addresses would have to support 32 bit addresses also, just like is the case with IPv6 hosts that have to have IPv4 stacks. Under 64 bit addresses, it's conceivable that in fact there would not necessarily have to be an entire IPv4 stack; just protocol conversion to widen and unwiden the data format. The stack would have to know that certain connections have IPv4 peers, and so it would parse IPv4 datagrams coming from those hosts, and likewise send them IPv4 datagrams. It could be designed such that if the source and destination addresses (A.B.C.D) of a connection are such that A <= 255 && B <= 255 && C <= 255 && D <= 255, then the hosts may optionally use the smaller IPv4 packet format.
- deleted 7y ago
  [deleted]
- cesarb 7y ago
  Start from the other end: how would an IPv4-only host with an IP address of, for instance, 198.51.100.1, initiate a connection to a host with a "new" address of 459.256.369.257? The host at 459.256.369.257 can understand the "198.51.100.1" address, but the host at 198.51.100.1 has no way to represent 459.256.369.257 as the destination address in an IPv4 packet. And even if the answer is "they can't initiate a connection", the same problem also happens in the opposite direction. When the host at 459.256.369.257 initiates a connection to the IPv4-only host at 198.51.100.1, what should it put in the "source address" field, which only has 32 bits since it's an IPv4 packet? If it puts a dummy address there, how would the reply to that packet reach it?
  - kazinator 7y ago
    > how would an IPv4-only host with an IP address of, for instance, 198.51.100.1, initiate a connection to a host with a "new" address of 459.256.369.257? The destination address obviously makes no sense to the IPv4-only host, being outside of the space that it understands, so a direct connection is obviously impossible. (Are you even asking seriously, or is this just snark?) The wide-address host would have to have an additional IPv4-compatible address bound to its network interface. Or else some other host would have to have such an IPv4-compatible address on its behalf and do NAT or proxying.
    - cesarb 7y ago
      > so a direct connection is obviously impossible. (Are you even asking seriously, or is this just snark?) I am asking seriously, both because I've seen proposals where the proposer does seem to sincerely believe it to be possible to somehow fit more than 32 bits in a 32-bit field (that was a truly baffling one), and because it is possible with stateful hacks similar to NAT64/DNS64 (that is: when the host at 198.51.100.1 tries to look up the address of the host at 459.256.369.257, it receives a fake but valid address, and a router in the path knows to map the fake address to the real address while doing all the necessary NAT shenanigans). > The wide-address host would have to have an additional IPv4-compatible address bound to its network interface. Then you gain nothing other than extra complexity, since the total number of hosts is still limited by the 32-bit IPv4 address. > Or else some other host would have to have such an IPv4-compatible address on its behalf and do NAT or proxying. Then not only you gain nothing by making your "new" addresses a superset of IPv4 addresses, but also you start looking like IPv6 ended up being, with all its transition mechanisms.
      - kazinator 7y ago
        > I've seen proposals where the proposer does seem to sincerely believe it to be possible to somehow fit more than 32 bits in a 32-bit field. Ah, well, that's obviously not a computer programmer with more than 2 or 3 years of experience. :) > Then you gain nothing other than extra complexity, since the total number of hosts is still limited by the 32-bit IPv4 address. Have we gained nothing? Consider that the majority of the IP addresses in the network are individual subscriber IP addresses, not servers. So we can have a transitional situation in which major service providers use the old 32 bit address space (so they are reachable by every client, 32 or 64 bit), while we put new subscribers into the 64 bit address space. The users who remain in the 32 bit space will increasingly find that they can't connect to some servers that are in the beyond-32 parts of 64 space, so they will have to upgrade their systems. Users in 32 space cannot do peer-to-peer with 64 users outside of that space, of course.
- jandrese 7y ago
  That's just dual stacking. You're dual stacked at the instant you have to decide to convert the packet header or not. At the end of the day you need a new packet format regardless, so you might as well clean it up in the process. Fun fact, there is a canonical way to encode an IPv4 address in an IPv6 packet. It's used by 4to6 gateways. IPv6 address parsers understand when you pass them addresses that look like: 64:ff9b::192.168.0.1
  - kazinator 7y ago
    If we convert an IPv4 datagram on the way up into the stack into the IPv4-64 format, and then just feed it to a single implementation of TCP or UDP or other protocol, I do not feel it is accurate to say that I we have two protocol stacks.
    - jandrese 7y ago
      That's what current Dual Stack does. TCP and UDP don't care about the IP layer for the most part. Checksums not withstanding.

by cesarb 7y ago

deleted 7y ago

[deleted]

kazinator 7y ago

> how would a legacy host which only understands classical IPv4 (with 32-bit addresses) talk to a host which only has "new" (wider than 32-bit) addresses? Hosts with 64 bit addresses would have to support 32 bit addresses also, just like is the case with IPv6 hosts that have to have IPv4 stacks. Under 64 bit addresses, it's conceivable that in fact there would not necessarily have to be an entire IPv4 stack; just protocol conversion to widen and unwiden the data format. The stack would have to know that certain connections have IPv4 peers, and so it would parse IPv4 datagrams coming from those hosts, and likewise send them IPv4 datagrams. It could be designed such that if the source and destination addresses (A.B.C.D) of a connection are such that A <= 255 && B <= 255 && C <= 255 && D <= 255, then the hosts may optionally use the smaller IPv4 packet format.

deleted 7y ago
[deleted]
cesarb 7y ago
Start from the other end: how would an IPv4-only host with an IP address of, for instance, 198.51.100.1, initiate a connection to a host with a "new" address of 459.256.369.257? The host at 459.256.369.257 can understand the "198.51.100.1" address, but the host at 198.51.100.1 has no way to represent 459.256.369.257 as the destination address in an IPv4 packet. And even if the answer is "they can't initiate a connection", the same problem also happens in the opposite direction. When the host at 459.256.369.257 initiates a connection to the IPv4-only host at 198.51.100.1, what should it put in the "source address" field, which only has 32 bits since it's an IPv4 packet? If it puts a dummy address there, how would the reply to that packet reach it?
- kazinator 7y ago
  > how would an IPv4-only host with an IP address of, for instance, 198.51.100.1, initiate a connection to a host with a "new" address of 459.256.369.257? The destination address obviously makes no sense to the IPv4-only host, being outside of the space that it understands, so a direct connection is obviously impossible. (Are you even asking seriously, or is this just snark?) The wide-address host would have to have an additional IPv4-compatible address bound to its network interface. Or else some other host would have to have such an IPv4-compatible address on its behalf and do NAT or proxying.
  - cesarb 7y ago
    > so a direct connection is obviously impossible. (Are you even asking seriously, or is this just snark?) I am asking seriously, both because I've seen proposals where the proposer does seem to sincerely believe it to be possible to somehow fit more than 32 bits in a 32-bit field (that was a truly baffling one), and because it is possible with stateful hacks similar to NAT64/DNS64 (that is: when the host at 198.51.100.1 tries to look up the address of the host at 459.256.369.257, it receives a fake but valid address, and a router in the path knows to map the fake address to the real address while doing all the necessary NAT shenanigans). > The wide-address host would have to have an additional IPv4-compatible address bound to its network interface. Then you gain nothing other than extra complexity, since the total number of hosts is still limited by the 32-bit IPv4 address. > Or else some other host would have to have such an IPv4-compatible address on its behalf and do NAT or proxying. Then not only you gain nothing by making your "new" addresses a superset of IPv4 addresses, but also you start looking like IPv6 ended up being, with all its transition mechanisms.
    - kazinator 7y ago
      > I've seen proposals where the proposer does seem to sincerely believe it to be possible to somehow fit more than 32 bits in a 32-bit field. Ah, well, that's obviously not a computer programmer with more than 2 or 3 years of experience. :) > Then you gain nothing other than extra complexity, since the total number of hosts is still limited by the 32-bit IPv4 address. Have we gained nothing? Consider that the majority of the IP addresses in the network are individual subscriber IP addresses, not servers. So we can have a transitional situation in which major service providers use the old 32 bit address space (so they are reachable by every client, 32 or 64 bit), while we put new subscribers into the 64 bit address space. The users who remain in the 32 bit space will increasingly find that they can't connect to some servers that are in the beyond-32 parts of 64 space, so they will have to upgrade their systems. Users in 32 space cannot do peer-to-peer with 64 users outside of that space, of course.
jandrese 7y ago
That's just dual stacking. You're dual stacked at the instant you have to decide to convert the packet header or not. At the end of the day you need a new packet format regardless, so you might as well clean it up in the process. Fun fact, there is a canonical way to encode an IPv4 address in an IPv6 packet. It's used by 4to6 gateways. IPv6 address parsers understand when you pass them addresses that look like: 64:ff9b::192.168.0.1
- kazinator 7y ago
  If we convert an IPv4 datagram on the way up into the stack into the IPv4-64 format, and then just feed it to a single implementation of TCP or UDP or other protocol, I do not feel it is accurate to say that I we have two protocol stacks.
  - jandrese 7y ago
    That's what current Dual Stack does. TCP and UDP don't care about the IP layer for the most part. Checksums not withstanding.