> I saw a mention of IPv6 support sometime in 2011 in my old email.. It's a work in progress.
There are actually multiple components to achieving IPv6 support in AFS-3. Different amounts of progress have been made on each of these components... 1/ Refactor the OpenAFS RX API so that IPv6 addresses can be used as endpoints. There are two sub tasks here. Firstly we need additional functions that can support opening connections to v6 endpoints, and internal changes to support accepting connections over IPv6. Secondly, we want to rework the API so that the internals of RX structures such as connections and calls aren't exposed to library users. This work is also a prerequisite for rx/tcp support, and as such is on my list. 2/ Create a generic XDR representation for an endpoint. The work in afs3-stds to produce an extensible union actually grew from this - once this work is complete (it pretty much is) we can move forwards to create an address type 3/ Create new versions of all AFS-3 RPCs which take IPv4 addresses, and have these new versions use the extensible address type. The plan is to do this work as part of RPC refresh. Chaz Chandler has already made great progress on the new definitions - they're in a comparable form in gerrit 4573. These new RPCs will require standardisation. 4/ Extend the vlserver database so that it can store IPv6 addresses. This is potentially the trickiest part of the puzzle, as we would like to do this and maintain a clear mechanism for backing out server upgrades. Ubik database formats are private to OpenAFS, so this doesn't require standardisation work. Some scoping work has been done here, but no implementation of which I am aware. 5/ Rework all of OpenAFS's internal data structures and APIs to store addresses in a new extensible format, rather than just using int32s. There's enough work here that could be easily accomplished in parallel if anyone is interested in contributing to it. Cheers, Simon.
