 |
 |
Brian, I completely agree with you that this has to be solved and soon. I am just trying to come up with a solution that doesn't cause other, perhaps more serious, problems (though this problem is pretty serious in and of itself). So, let's review the options:
1) The simple bypass. Client machine admins should register their IP addresses in DNS. This will work today in the vast majority of cases. As you point out, though, there are cases where this is not possible to do. However, this may be the best short-term solution at the moment.
2) Base "stackiness" on configured interfaces not DNS registration. The code already exists but has not been checked in. As I pointed out, this introduces a host of other possible problems that are not easy to get around (e.g. existence of non-routable interfaces). So, I am wary of this approach for clients (servers already take this approach since it's easily correctable). This appears to be Lukasz's preferred solution and I am OK with that as long as everyone agrees that it puts a big dependency on the site admins to properly configure network interfaces.
3) Alter "stackiness" based on the connection. As you point out if the outgoing connection is to an IPv6 address but there is no discovered IPv6 address (but we do have an IPv4 address) mark client as dual stack. As I pointed out, this will require some amount of code development. I am still in the process to see how difficult that would be but given that "socket" has been abstracted out at higher levels to make it easy to introduce new types of connectivity, it likely won't be a slam-dunk. It also introduces the reverse problem. If the client doesn't have a registered IPv4 address but we connect with to an IPv6 address we would still say this is not a dual-stacked client. This will inevitably cause redirection failures as well.
3) Introduce yet another envar that, when set, always claims the client is dual-stacked. This is a pernicious solution in that envars will be set and then forgotten while the machine configuration changes to one incompatible with the envar.
4) Add an option to disable IP address matching. This essentially requires everyone to be dual-stacked. The consequences of this are far and wide and I am only starting to appreciate the problems it triggers. This is largely caused by the locate command that, for backward compatibility reasons, returns IP addresses by default. I do recall when we tried this way back when, a lot of things simply broke. It also points out that the new client should always ask for a host name response.
I this this pretty much covers the solution space. Now we just need to implement one of them. Let me work a bit more on seeing how to pass the connection detail up the call stack since, as you point out, is the least problematic solution but, obviously, does not cover all possible configurations.
—
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