3 ms·

> 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-o

> 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?
- dataflow 3y ago
  You're picking a brief and vague 1-sentence summary he wrote, and missing everything that came after it that explained in detail what he's talking about. > 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." He could've meant "making IPv6 work means much more than upgrading software. Every administrator of a server on a public IPv4 address has to go to extra effort to acquire and enable a public IPv6 address." You cannot read this and miss the fact that his frustration is with the need for administrators to acquire separate IPv6 addresses. > maybe I should reread the article a bit more generously and less literally No need to do either. Just read all of it, instead of 1 or 2 sentences that might sound like amateurish mistakes when you remove several pages of context and then extrapolate without them.
  - welterde 3y ago
    I have read all of it and I don't agree with you. But lets roll with your interpretation. Adding the address to the server is the easiest part of the whole process. Upgrading the software is probably the biggest hurdle with people just hardcoding things to 32-bit left and right (and some badly designed APIs which do either IPv4 or IPv6 but not both in a transparent fashion). And next is actually setting up ipv6 connectivity. All those other things you would still have to take care of even if you magically could keep using the IPv4 address in IPv6 (however that would work). Never mind that servers don't statically sit around forever, but one has to set up new servers all the time. So why not go for the inverse approach for new servers? Only give the servers IPv6 addresses and for those servers that still need to be reached via the public IPv4 internet (most internal ones probably have no need of this) can be accessed via SIIT, which performs stateless mapping between IPv4 and IPv6 (for example IPv4 1.2.3.4 gets translated to IPv6 2001:db8::1.2.3.4 and vice versa).
    - dataflow 3y ago
      > I have read all of it and I don't agree with you. But lets roll with your interpretation. You don't need to agree with me on what he's saying. The quote "...extra effort to acquire and enable a public IPv6 address" is a directly copied from his own page. It doesn't make sense to read that and claim that's not what he's saying, or to claim I'm "interpreting" it to mean that. That quote is what he's saying. > even if you magically could keep using the IPv4 address in IPv6 (however that would work) It's not magical, I explained it in [1]. And he himself started to explain it when he wrote "The specifications could have [...], but they didn't", but he didn't finish the thought, and just left the reader to figure out the rest of it. (Which, again, I explained in [1].) > Adding the address to the server is the easiest part of the whole process. The issue isn't "adding the address to the server". The issue is obtaining said address to be able to add it to the server in the first place. This requires both you and your ISP to set up and manage/maintain an entirely independent parallel network with an entirely separate configuration. It's an administrative hurdle, not merely a technical one. I can't explain it better than this user did, so just read his comment [2]. In any case, it's fine if you disagree that this is actually a significant hurdle; I'm not trying to argue that point. My goal here was to portray what djb is saying accurately, not to agree or disagree with it. So if you disagree with it, that's mission accomplished (for me anyway). [1] https://news.ycombinator.com/item?id=37553377 https://news.ycombinator.com/item?id=37553377 [2] https://news.ycombinator.com/item?id=37555424 https://news.ycombinator.com/item?id=37555424

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?

dataflow 3y ago
You're picking a brief and vague 1-sentence summary he wrote, and missing everything that came after it that explained in detail what he's talking about. > 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." He could've meant "making IPv6 work means much more than upgrading software. Every administrator of a server on a public IPv4 address has to go to extra effort to acquire and enable a public IPv6 address." You cannot read this and miss the fact that his frustration is with the need for administrators to acquire separate IPv6 addresses. > maybe I should reread the article a bit more generously and less literally No need to do either. Just read all of it, instead of 1 or 2 sentences that might sound like amateurish mistakes when you remove several pages of context and then extrapolate without them.
- welterde 3y ago
  I have read all of it and I don't agree with you. But lets roll with your interpretation. Adding the address to the server is the easiest part of the whole process. Upgrading the software is probably the biggest hurdle with people just hardcoding things to 32-bit left and right (and some badly designed APIs which do either IPv4 or IPv6 but not both in a transparent fashion). And next is actually setting up ipv6 connectivity. All those other things you would still have to take care of even if you magically could keep using the IPv4 address in IPv6 (however that would work). Never mind that servers don't statically sit around forever, but one has to set up new servers all the time. So why not go for the inverse approach for new servers? Only give the servers IPv6 addresses and for those servers that still need to be reached via the public IPv4 internet (most internal ones probably have no need of this) can be accessed via SIIT, which performs stateless mapping between IPv4 and IPv6 (for example IPv4 1.2.3.4 gets translated to IPv6 2001:db8::1.2.3.4 and vice versa).
  - dataflow 3y ago
    > I have read all of it and I don't agree with you. But lets roll with your interpretation. You don't need to agree with me on what he's saying. The quote "...extra effort to acquire and enable a public IPv6 address" is a directly copied from his own page. It doesn't make sense to read that and claim that's not what he's saying, or to claim I'm "interpreting" it to mean that. That quote is what he's saying. > even if you magically could keep using the IPv4 address in IPv6 (however that would work) It's not magical, I explained it in [1]. And he himself started to explain it when he wrote "The specifications could have [...], but they didn't", but he didn't finish the thought, and just left the reader to figure out the rest of it. (Which, again, I explained in [1].) > Adding the address to the server is the easiest part of the whole process. The issue isn't "adding the address to the server". The issue is obtaining said address to be able to add it to the server in the first place. This requires both you and your ISP to set up and manage/maintain an entirely independent parallel network with an entirely separate configuration. It's an administrative hurdle, not merely a technical one. I can't explain it better than this user did, so just read his comment [2]. In any case, it's fine if you disagree that this is actually a significant hurdle; I'm not trying to argue that point. My goal here was to portray what djb is saying accurately, not to agree or disagree with it. So if you disagree with it, that's mission accomplished (for me anyway). [1] https://news.ycombinator.com/item?id=37553377 https://news.ycombinator.com/item?id=37553377 [2] https://news.ycombinator.com/item?id=37555424 https://news.ycombinator.com/item?id=37555424