4 ms·

> That document has been going around for ages and is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but rema

> That document has been going around for ages and is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients. Let me summarize my understanding of what he's saying, because I don't quite see why/how you disagree. I think you (or I) might be misunderstanding his claim. Imagine this topology: C (client, IPv4-only) <=> R (intermediate router) <=> S (server) My understanding of djb is he's saying that IPv6 could have been designed such that S could still serve C via only simple software updates -- this means, crucially, without the need for S to separately obtain a public IPv6 address through R, because its IPv4 address would be automatically valid for IPv6. How can this work? Well, there are two scenarios: 1. If R is IPv4-only, then S could figure that out during some startup/negotiation process, and send only IPv4 packets to R. R only lets IPv4 clients connect to S anyway, so any response (even from IPv6 applications) on S must be going back to an IPv4 address. So the kernel can transparently translate those IPv6 addresses into IPv4 before passing them along to R, and vice-versa. 2. If R supports IPv6, then R can do the same thing S would've done in the previous^ scenario. (In fact, I think S could become IPv6-communication-only in that case, reserving IPv4 for just address leasing? I'm not sure, but in any case, I don't think that matters here.) Notice that all of this is almost completely stateless. (I think the only state S needs to track here is 1 bit, indicating whether R supports IPv6 or not.) So, S and R can be independently and (importantly, rather trivially) upgraded to support the IPv6 protocol, without losing the ability to talk to any clients within the IPv4 address range. This is easy and requires no explicit leasing of IPv6 addresses. That step can be implemented and have support for it added later, whenever S is ready to serve clients beyond the IPv4 address space. Does this make sense? If so, then it seems to show how IPv4-only clients could talk to IPv6 servers without modification. If not, then I'd love to see where I'm mistaken (I very well might be).

welterde 3y ago
The issue is not how can we enable IPv4 C talk to IPv4 S, since that already works. The problem is how would C (ipv4-only) send a packet to S (ipv6-only) in the first place? It doesn't know how to deal with non-ipv4 packets, since it's ipv4-only. Thus if the server does not have a IPv4-address how does a IPv4-client send packets to it? The inverse situation (IPv6-only client but IPv4-only server) is not really an issue, since for that situation NAT64 works, since you can embed IPv4 addresses into IPv6. The only way C (ipv4-only) could communicate with S (ipv6-only) is by either allocating a dedicated ipv4-address to S (doesn't have to be directly connected to S - it can be sent to some translation box that does SIIT) or by upgrading C to support ipv6 and tunneling it (6to4, 6rd, teredo, etc.).
- deleted 3y ago
  [deleted]
- dataflow 3y ago
  > The problem is how would C (ipv4-only) send a packet to S (ipv6-only) in the first place? It doesn't know how to deal with non-ipv4 packets, since it's ipv4-only. If S is IPv6-only, then either the address is from the IPv4 range, or it's not. If it is, then R can translate between them. If not, then they can't connect. I don't see him suggesting otherwise anywhere. Even ignoring translation possibility, his point here isn't to claim its magically possible for a server outside the IPv4 address range to talk to an IPv4 client. His point is that this can move everyone to IPv6 for communication, without ISPs also having to deal with leasing addresses outside the IPv4 range, which he believes would help adoption.
  - hn_throwaway_99 3y ago
    Thank you thank you. I feel like this primary point in the post got lost it some of the strawmen of "There is just no way an ipv4 stack could talk to an ipv6 address!"
  - renewiltord 3y ago
    It seems like this is the same world as we're currently in. IPv4 hosts can contact each other and can't contact IPv6 hosts. Hosts which are dualstack can be contacted over either stack.
    - dataflow 3y ago
      The problem is the incremental effort (not just software wise, but administrative as well) needed to achieve this outcome. This comment explained it much better than me: https://news.ycombinator.com/item?id=37555424 https://news.ycombinator.com/item?id=37555424
  - welterde 3y ago
    I understood djbs article differently then you. What else could he have meant with "In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses. Public IPv6 addresses can only exchange packets with each other."? But maybe I should reread the article a bit more generously and less literally, maybe he is actually advocating for the IPv6 we have today? Because there are transition technologies like NAT64, SIIT, 6to4, 6rd, etc. that sort of allow some of the things he suggested? "If the IPv6 configuration isn't automatic, it won't happen." sounds like he is actually advocating SLAAC to me?
renewiltord 3y ago
In this scenario, R sends packets to S over IPv4 only. So S must have an IPv4 address? If S has an address that is larger than 32 bits, what goes in the "destination IP" field in the IPv4 packet that R is capable of sending? If S has an address that is guaranteed to be less than 32 bits then we're just in the IPv4 world. How are R and S negotiating when R cannot even name S on the network? Its stack only allows for 32-bit addresses and S can't have a 32-bit address.
- dataflow 3y ago
  See my reply here, I think it addresses your question: https://news.ycombinator.com/item?id=37556857 https://news.ycombinator.com/item?id=37556857

welterde 3y ago

The issue is not how can we enable IPv4 C talk to IPv4 S, since that already works. The problem is how would C (ipv4-only) send a packet to S (ipv6-only) in the first place? It doesn't know how to deal with non-ipv4 packets, since it's ipv4-only. Thus if the server does not have a IPv4-address how does a IPv4-client send packets to it? The inverse situation (IPv6-only client but IPv4-only server) is not really an issue, since for that situation NAT64 works, since you can embed IPv4 addresses into IPv6. The only way C (ipv4-only) could communicate with S (ipv6-only) is by either allocating a dedicated ipv4-address to S (doesn't have to be directly connected to S - it can be sent to some translation box that does SIIT) or by upgrading C to support ipv6 and tunneling it (6to4, 6rd, teredo, etc.).

deleted 3y ago
[deleted]
dataflow 3y ago
> The problem is how would C (ipv4-only) send a packet to S (ipv6-only) in the first place? It doesn't know how to deal with non-ipv4 packets, since it's ipv4-only. If S is IPv6-only, then either the address is from the IPv4 range, or it's not. If it is, then R can translate between them. If not, then they can't connect. I don't see him suggesting otherwise anywhere. Even ignoring translation possibility, his point here isn't to claim its magically possible for a server outside the IPv4 address range to talk to an IPv4 client. His point is that this can move everyone to IPv6 for communication, without ISPs also having to deal with leasing addresses outside the IPv4 range, which he believes would help adoption.
- hn_throwaway_99 3y ago
  Thank you thank you. I feel like this primary point in the post got lost it some of the strawmen of "There is just no way an ipv4 stack could talk to an ipv6 address!"
- renewiltord 3y ago
  It seems like this is the same world as we're currently in. IPv4 hosts can contact each other and can't contact IPv6 hosts. Hosts which are dualstack can be contacted over either stack.
  - dataflow 3y ago
    The problem is the incremental effort (not just software wise, but administrative as well) needed to achieve this outcome. This comment explained it much better than me: https://news.ycombinator.com/item?id=37555424 https://news.ycombinator.com/item?id=37555424
- welterde 3y ago
  I understood djbs article differently then you. What else could he have meant with "In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses. Public IPv6 addresses can only exchange packets with each other."? But maybe I should reread the article a bit more generously and less literally, maybe he is actually advocating for the IPv6 we have today? Because there are transition technologies like NAT64, SIIT, 6to4, 6rd, etc. that sort of allow some of the things he suggested? "If the IPv6 configuration isn't automatic, it won't happen." sounds like he is actually advocating SLAAC to me?

renewiltord 3y ago

In this scenario, R sends packets to S over IPv4 only. So S must have an IPv4 address? If S has an address that is larger than 32 bits, what goes in the "destination IP" field in the IPv4 packet that R is capable of sending? If S has an address that is guaranteed to be less than 32 bits then we're just in the IPv4 world. How are R and S negotiating when R cannot even name S on the network? Its stack only allows for 32-bit addresses and S can't have a 32-bit address.

dataflow 3y ago
See my reply here, I think it addresses your question: https://news.ycombinator.com/item?id=37556857 https://news.ycombinator.com/item?id=37556857