Is the vlserver DB format documented anywhere? On Mon, Jul 25, 2011 at 1:28 PM, Simon Wilkinson <s...@inf.ed.ac.uk> wrote: > > 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. >
-- Tom Maher <tma...@watson.org> _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info