undefined | Better HN

0 pointswelterde2y ago0 comments

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.).

0 comments

dataflow2y 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.

welterdeOP2y 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?

dataflow2y 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.

1 more reply

renewiltord2y 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.

dataflow2y 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

hn_throwaway_992y 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!"

j / k navigate · click thread line to collapse

0 pointswelterde2y ago0 comments

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.

0 comments

dataflow2y 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.

welterdeOP2y ago

dataflow2y 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."

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.

1 more reply

renewiltord2y 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.

dataflow2y ago

hn_throwaway_992y 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!"

j / k navigate · click thread line to collapse