Print

---

Hi,

I'm sorry, but where on earth does this rule about "properly" configured hosts exist (as in, a host is properly configured if and only if the hostname has a resolving DNS entry)? As far as I can see, no such rule exists for IPv4. Why does it exist for IPv6?

As a few examples where hostnames may not work:

• My laptop has an IPv4 address but my university doesn't provide a DNS entry. Does that make it incorrect?
• My laptop has an IPv6 address but no DNS entry. Does that make it incorrect? I think we can all agree that my laptop shouldn't lose access to IPv4 servers if the university has given me an IPv6 address but no DNS entry.

This issue is pretty bad: we now have to consider disabling IPv6 for all sites because IPv4 stops working for a large number of dual-stack sites.

I concede that the existing setup probably looked like the correct approach when it was written: at that point, how sites would deploy IPv6 was a bit more theoretical.

Here's my logic for using interface-based semantics:

• This will err on the side of identifying the client as dual-stack instead of IPv4-only.
• AFAICT (looking at log messages from XrdCl) redirections are based on hostnames, which are re-resolved to addresses by the client. In the case of a IPv4-only client identified as dual-stack, they will still resolve only IPv4 addresses of the data server and connect over IPv4.
• In the unlikely event that a IPv4-only client identifies as dual-stack and is redirected to a IPv6-only server, the client can recover by returning to the redirector.
  • Hence the penalty is the cost of an extra redirect; the penalty in the current scheme is a complete failure.
  • There are real cases where a client prefers IPv6 (i.e., when IPv4 involves a congested NAT); to my knowledge, an IPv6-only service is still theoretical.

In fact, using the same logic, we probably should identify a client as dual-stack if there is a public IPv6 address and a private IPv4-only (given the prevalence of NATs for IPv4 and the scarcity of NATs for IPv6).

Brian

—
Reply to this email directly or view it on GitHub.

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1