[OpenAFS] Plans for IPv6
Simon Wilkinson
sxw@inf.ed.ac.uk
Mon, 25 Jul 2011 21:28:48 +0100
--Apple-Mail-2-458565851
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
> 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. D=
ifferent 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 endpoin=
ts. There are two sub tasks here. Firstly we need additional functions that c=
an support opening connections to v6 endpoints, and internal changes to sup=
port 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 ex=
posed 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-std=
s 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 w=
ork 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 ne=
w 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 a=
nd maintain a clear mechanism for backing out server upgrades. Ubik database=
formats are private to OpenAFS, so this doesn't require standardisation wor=
k. Some scoping work has been done here, but no implementation of which I a=
m aware.
5/ Rework all of OpenAFS's internal data structures and APIs to store addres=
ses in a new extensible format, rather than just using int32s.
There's enough work here that could be easily accomplished in parallel if an=
yone is interested in contributing to it.
Cheers,
Simon.
--Apple-Mail-2-458565851
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><body bgcolor=3D"#FFFFFF"><div><br></div><div></div><blockquote type=3D=
"cite"><div><span>I saw a mention of IPv6 support sometime in 2011 in my old=
email..</span><font class=3D"Apple-style-span" color=3D"#000000"><font clas=
s=3D"Apple-style-span" color=3D"#0023A3"><br></font></font></div></blockquot=
e><br><div>It's a work in progress.</div><div><br></div><div>There are actua=
lly multiple components to achieving IPv6 support in AFS-3. Different amount=
s of progress have been made on each of these components...</div><div><br></=
div><div>1/ Refactor the OpenAFS RX API so that IPv6 addresses can be used a=
s endpoints. There are two sub tasks here. Firstly we need additional functi=
ons that can support opening connections to v6 endpoints, and internal=
changes to support accepting connections over IPv6. Secondly, we want to re=
work the API so that the internals of RX structures such as connections and c=
alls aren't exposed to library users. This work is also a prerequisite for r=
x/tcp support, and as such is on my list.</div><div><br></div><div>2/ Create=
a generic XDR representation for an endpoint. The work in afs3-stds to prod=
uce 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</div><di=
v><br></div><div>3/ Create new versions of all AFS-3 RPCs which take IPv4 ad=
dresses, and have these new versions use the extensible address type. The pl=
an 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 ger=
rit 4573. These new RPCs will require standardisation.</div><div><br></div><=
div>4/ Extend the vlserver database so that it can store IPv6 addresses. Thi=
s is potentially the trickiest part of the puzzle, as we would like to do th=
is and maintain a clear mechanism for backing out server upgrades. Ubik data=
base 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.</div><div><br></div><div>5/ Rework all of OpenAFS's intern=
al data structures and APIs to store addresses in a new extensible format, r=
ather than just using int32s.</div><div><br></div><div>There's enough work h=
ere that could be easily accomplished in parallel if anyone is interested in=
contributing to it.</div><div><br></div><div>Cheers,</div><div><br></div><d=
iv>Simon.</div><div><br></div></body></html>=
--Apple-Mail-2-458565851--