[OpenAFS] Plans for IPv6

[Tom Maher]

Is the vlserver DB format documented anywhere?

On Mon, Jul 25, 2011 at 1:28 PM, Simon Wilkinson <sxw@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 =C2=A0v6 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 t=
his
> 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 h=
ave
> these new versions use the extensible address type. The plan is to do thi=
s
> work as part of RPC refresh. Chaz Chandler has already made great progres=
s
> on the new definitions - they're in a comparable form in gerrit 4573. The=
se
> 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 =C2=A0which 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.
>



--=20
Tom Maher <tmaher@watson.org>