4 ms·

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

by 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.
    - PopeDotNinja 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. If someone seriously brings that to me, I'm gonna try and come up with something witty... "The thing people forget is that the periods in an IPv4 address take up space, too. If you know anything about data octets, you'd realize that were we're wasting adding 8 bits for EACH period just to make those addresses human readable. Periods are the junk DNA if IP addresses. Fun fact: the reason Comcast is able to charge more for their Internet is because they got Congress to allow them to charge extra for the dots. You know how some people pay $40 for their Internet and you are paying $70? While they are talking to 32 bit addresses at $10 per 8 bits, you are paying the same $10 per 8 bits, and another $30 for IP addess 'junk DNA'! Pull out your cable bill and look for through the fine print. There's a reason the fine print is so small. That's how they obfuscate how they you charge you 75% and get away with it."
      - cesarb 7y ago
        I wish I could remember where I saw it so I could share it with you all, but the argument was something like using more voltage levels to fit more values in each bit of the IP address. (It was probably in one of the ietf mailing lists, this sort of crankery seems to get posted there often for some reason.)
- pdkl95 7y ago
  > The wide-address host would have to have an additional IPv4-compatible address bound to its network interface. Yes, we call that (having v4 and v6 addresses) a "dual stack" configuration. The host gets to choose which protocol to use as it desires. If you have a v4 address, you can even refer to that (v4) address in v6 packets[1] by setting the leading bits to 0. That is, v4 "A.B.C.D" as a v6 address is just "::A.B.C.D". The v4 address space is embedded into the v6 address space; this is generally automatic in dual-stack configurations. You can even refer to a v4-only address in a v6 packet as "::FFFF:A.B.C.D". However, if you want your packets to convert back to v4 automagically (so you only have to speak a single v6 stack)... if you want to autoconvert between IP versions in transit... > some other host would have to have such an IPv4-compatible address on its behalf As jandrese already pointed out, that's called 4to6, setup the proxy (if needed), and use "64:ff9b::A.B.C.D" for your v4 addresses. The thing you seem to be asking for is already a feature of IPv6. However, the thing that can never happen is doing any of this transparently in a v4 packet. Where, specifically, in the IPv4 header[2], are you going to put extra SRC and DST address bits? You cannot change the location of any existing bit in the header: everything (including IP-aware routing hardware) (including the software/firmware of every v4-speaking device, most of which will never - or cannot ever - receive an update) already assumes that e.g. "the source address is on header octet 12-15 (bit 96-127)". The only remotely hypothetical place anything could be added would be in an IP Option field, which would be a terrible idea. Other options might change the location of the new address bits in the header, meaning routers would have to sequentially parse all of the option fields to parse addresses, which would be a mandatory delay even with legacy pure-v4 packets. Also, most firewalls will probably drop the new, unexpected option as "possibly malicious". To do anything else to the header, you would need to change the version number, which immediately introduces the compatibility issues everyone complains about with IPv6. [1] http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding.htm http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding.ht... [2] https://en.wikipedia.org/wiki/IPv4#Header https://en.wikipedia.org/wiki/IPv4#Header
  - kazinator 7y ago
    > ... having v4 and v6 addresses ... > and use "64:ff9b::A.B.C.D" for your v4 addresses. You're talking about IPv6 now, which this thread isn't about. IPv6 implementations that support IPv4 do have separate stacks, because IPv6 is too darned different.
6nf 7y ago
How does IPv6 solve that same problem?
- zAy0LfpBZLC8mAC 7y ago
  It doesn't, because it can't be solved.

by cesarb 7y ago

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.
  - PopeDotNinja 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. If someone seriously brings that to me, I'm gonna try and come up with something witty... "The thing people forget is that the periods in an IPv4 address take up space, too. If you know anything about data octets, you'd realize that were we're wasting adding 8 bits for EACH period just to make those addresses human readable. Periods are the junk DNA if IP addresses. Fun fact: the reason Comcast is able to charge more for their Internet is because they got Congress to allow them to charge extra for the dots. You know how some people pay $40 for their Internet and you are paying $70? While they are talking to 32 bit addresses at $10 per 8 bits, you are paying the same $10 per 8 bits, and another $30 for IP addess 'junk DNA'! Pull out your cable bill and look for through the fine print. There's a reason the fine print is so small. That's how they obfuscate how they you charge you 75% and get away with it."
    - cesarb 7y ago
      I wish I could remember where I saw it so I could share it with you all, but the argument was something like using more voltage levels to fit more values in each bit of the IP address. (It was probably in one of the ietf mailing lists, this sort of crankery seems to get posted there often for some reason.)
pdkl95 7y ago
> The wide-address host would have to have an additional IPv4-compatible address bound to its network interface. Yes, we call that (having v4 and v6 addresses) a "dual stack" configuration. The host gets to choose which protocol to use as it desires. If you have a v4 address, you can even refer to that (v4) address in v6 packets[1] by setting the leading bits to 0. That is, v4 "A.B.C.D" as a v6 address is just "::A.B.C.D". The v4 address space is embedded into the v6 address space; this is generally automatic in dual-stack configurations. You can even refer to a v4-only address in a v6 packet as "::FFFF:A.B.C.D". However, if you want your packets to convert back to v4 automagically (so you only have to speak a single v6 stack)... if you want to autoconvert between IP versions in transit... > some other host would have to have such an IPv4-compatible address on its behalf As jandrese already pointed out, that's called 4to6, setup the proxy (if needed), and use "64:ff9b::A.B.C.D" for your v4 addresses. The thing you seem to be asking for is already a feature of IPv6. However, the thing that can never happen is doing any of this transparently in a v4 packet. Where, specifically, in the IPv4 header[2], are you going to put extra SRC and DST address bits? You cannot change the location of any existing bit in the header: everything (including IP-aware routing hardware) (including the software/firmware of every v4-speaking device, most of which will never - or cannot ever - receive an update) already assumes that e.g. "the source address is on header octet 12-15 (bit 96-127)". The only remotely hypothetical place anything could be added would be in an IP Option field, which would be a terrible idea. Other options might change the location of the new address bits in the header, meaning routers would have to sequentially parse all of the option fields to parse addresses, which would be a mandatory delay even with legacy pure-v4 packets. Also, most firewalls will probably drop the new, unexpected option as "possibly malicious". To do anything else to the header, you would need to change the version number, which immediately introduces the compatibility issues everyone complains about with IPv6. [1] http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding.htm http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding.ht... [2] https://en.wikipedia.org/wiki/IPv4#Header https://en.wikipedia.org/wiki/IPv4#Header
- kazinator 7y ago
  > ... having v4 and v6 addresses ... > and use "64:ff9b::A.B.C.D" for your v4 addresses. You're talking about IPv6 now, which this thread isn't about. IPv6 implementations that support IPv4 do have separate stacks, because IPv6 is too darned different.

6nf 7y ago

How does IPv6 solve that same problem?

zAy0LfpBZLC8mAC 7y ago
It doesn't, because it can't be solved.