On 12 Feb 2011, at 05:20, ambarisha b <[email protected]> wrote:
> I found most of the IP version dependent calls to the Sockets API
> spread over the entire code.

The majority of OpenAFS's network activity is done through the RX library. RX 
is a remote procedure call protocol which is implemented on top of UDP. Network 
calls are initiated by calling functions within our RX API which represents 
addressees as afs_uint32, a 32 bit wide unsigned integer type.

On top of RX, AFS operations are performed by making remote procedure calls. 
Many of these calls contain address information, again represented by 32bit 
integers,

AFS uses a number of central databases, controlled by a protocol named Ubik. 
Both Ubik, and the databases it maintains, would have to be extended to support 
IPv6 addresses. Configuration sources, such as the CellServDB, would have to be 
extended to handle the longer addresses,

Finally, all of the internal structures which track hosts by IPv4 addresses 
would have to be extended to use IPv6 addresses.

As AFS is a protocol with a number of implementors, we have a standardisation 
process which controls changes to things that are visible on the wire. In 
addition, we are committed to maintaining a stable API for applications 
including our libraries. This means that we can't just modify existing 
interfaces, but instead have to create new versions of all affected APIs and 
RPCs.

Our standardisation process is currently rather long winded. Changes requiring 
standardisation are unlikely to be achievable within the Summer of Code 
timeframe. However, I do think you could create a reasonable project around:

* Reimplement the RX API to support an abstract address type, and add an IPv6 
implementation to RX.
* Audit the code base for int32 use to internally hold addresses. Produce a 
list of all of these locations.
* Add IPv6 support to selected code modules, with the ordering to be determined 
following the audit.

If you are interested in work extending beyond Summer of Code, then writing 
documents describing the extension of AFS RPCs to support longer addresses, and 
specifying extensions for Ubik and CellServDB would all be useful work - but 
work that would be likely to extend into next year before any implementation 
could be performed.

Cheers,

Simon.

_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel

Reply via email to