 |
 |
OK, so let me ramble here because there is a lot of history behind what we did. That might work but the socket information has been abstracted out by the time we need to set this information. So, adding it in based on the socket would be a relatively large change. I suppose I could ague that it would be a hack anyway w.r.t. that people really need to configure IPv6 correctly (clearly that is not what happens 50% of the time). So, hack is relative to sites that just don't do it right and how do we compensate for that. The answer is that it will never be absolutely right, sigh. I am still prone to just base it on interfaces as it will get us to the 10-20% edge cases where people don't correctly configure the interfaces. We found that to happen most often in VM's but then that's what lot of worker nodes are becoming. I suppose we can just say that if you have configured a usable IPv6 interface you *must* register it in DNS or in /etc/hosts (if you are still prone to using /etc/hosts - another big problem). I recall Lukasz and I having a lot of heated discussions about this because it became very clear to us that sites configure IPv6 in a myriad of ways and we couldn't possibly capture all of them and maybe we should just give up and assume a base level of configuration. That, of course, proved to be unworkable as well and part of the reason is that we got slammed in the WLCG IPv6 readiness meeting for proposing it because it would not properly capture IPv6-only clients. At the moment I don't have any easy solution here. Either we instruct people to "register" all of their interfaces (which they should be doing) or we use the configured interface method (which has problems of its own). Basing it on socket connection is very problematic given the code base. So, which poison do you want? --- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/326#issuecomment-172763051 ######################################################################## 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