 |
 |
Hi Andreas, Tecnically, you are correct. As I said, it's unlikely servers will be deployed as only IPv6 but even if they were, they can still accept IPv4 mapped connections. The issue really is IPv6-only clients. Those can only go to IPv6-capable servers. I don't see a swell of deployments in that regard but it is inevitable as IPv4 addresses become scarce (well, they are pretty scarce for new deployments). It seems we will need to play this as it comes since I don't see any kind of planning in the community. Andy On Thu, 26 Nov 2020, Andreas Petzold (SCC) wrote: > Hi Thomas, > > your question sounds a bit like a mix between dCache and SLAC xrootd ;-)? > > Of course the experts should comment, but let me add my 2 cents. > > If you are talking about SLAC xrootd, I don't see a reason why a transition > between v6 and v4 would not work. > > The dual-stack client connects to the xrootd manager/redirector via v6 and > gets told where to connect to access the file. If that _new_ connection is > made via v4 or v6 should not matter. It is always a new connection for the > client and that's the beauty of the protocol (IMHO). > > How dCache handles a situation like this when you have an xrootd client > connecting to a dCache xrootd door via v6 and you have dCache pools on v4, I > don't know. > > Cheers, > > Andreas > > > On 25/11/2020 14.10, Thomas Hartmann wrote: >> Hi all, >> >> would it be in principle possible, that the xrd client reastablishes a >> conenction on IPv4 after the initital connection got established over IPv6? >> >> E.g., >> a dual-stack client connects to a dual-stack redirector/door and the >> connection is established on v6. The requested file is only available on a >> IPv4 node and the redirector points to the pools DNS, that only resolves >> for A but not AAAA. >> The redirect fails as the non-resolved v6 ends up as an invalid redirect >> URL. >> >> I guess, that client/server do not have much chance, after the IP flavour >> got negotiated on the network stack, or? >> >> Cheers, >> Thomas >> >> >> ######################################################################## >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the XROOTD-L list, click the following link: >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 > > -- > Karlsruhe Institute of Technology (KIT) > Steinbuch Centre for Computing (SCC) > > Andreas Petzold > > Hermann-von-Helmholtz-Platz 1, Building 449, Room 202 > D-76344 Eggenstein-Leopoldshafen > > Tel: +49 721 608 24916 > Fax: +49 721 608 24972 > Email: [log in to unmask] > www.scc.kit.edu > > Registered office: > Kaiserstraße 12, 76131 Karlsruhe, Germany > > KIT ? The Research University in the Helmholtz Association > > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the XROOTD-L list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1