During the end of the (running-behind-schedule) IPv6 talk at this year's EAKC, I believe it was George Sluyterman that asked about the possibility of using NAT64 with OpenAFS. While on stage, Simon and I didn't really answer this question (I was a little confused, and wasn't sure if I was hearing '6to4' or '64').
However, George found me later and we talked about this a bit more. I wasn't really familiar with NAT64 at the time, but it involves a NAT and a fake DNS server ("DNS64"), which responds to A requests with AAAA responses with fake IPv6 requests that can be interpreted and NAT'd by the NAT64 machine. As I have discussed with George, this scheme does not work with OpenAFS, since we do not use DNS to resolve fileservers to IP addresses. It could work for dbservers via SRV records, but you can't do much in AFS if you can only contact the dbservers and not the fileservers :) Such a scheme could conceivably work if a VLDB64 proxy server were created, to perform the same role as DNS64 (returning fake results via a modified IPv6-enabled VL_GetAddrsU call). However, making that work is around the same amount of work as developing native IPv6 support anyway, so it's probably not worth developing, at least not "first". Doing this could maybe be useful after native IPv6 support is developed, and you have an IPv6 client that wants to contact a cell that hasn't yet upgraded to fileserver versions that support IPv6. Or if you conceptually put the VLDB64 server inside each client, that also works and is much easier to implement, but requires knowledge of the NAT64 configuration on each client. And of course there are other ways to tunnel or NAT clients in such a way that don't involve modifying OpenAFS at all. The NAT64 scheme I think was brought up in case we could work in that environment with minimal changes to OpenAFS, but as far as I can tell the answer to that is just "no". It sounded like you were satisfied with the answers I gave, George, but I'm mentioning this here in case anyone else wanted to hear an actual answer to the original question. And of course maybe this is clearer in text, and after I've had more sleep and food, and we're not scribbling on a little piece of paper and trying to speak loudly enough that we can actually hear each other :) -- Andrew Deason adea...@sinenomine.net _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info