Ambarisha: The reason that IPv6 is not a good choice for a GSoC project is that it requires network wire protocol changes that must be standardized across all of the implementations of the AFS protocol suite. The design decisions cannot be made exclusively by the OpenAFS community.
In order to add IPv6 addressing the following will need to be accomplished: * The CellServDB format must be revised to support IPv6 and other data associated with the lookup of volume location database servers (vldb) within a cell. * The volume location database itself must be extended to store a combination of IPv4 and IPv6 addresses * The RPCs that deliver client and server address information (VL_, RXAFSCB_ and others) must be extended * The file server which tracks client migration by address/port must be extended to support additional endpoint types * The cache managers which maintain lists of vldb and file servers must be updated to support additional address types * The ubik protocol voting algorithm which currently uses the IPv4 address as a core part of its election process needs to be replaced The above is just the items that come to mind without thinking too hard. It is much too large a project for GSoC. Even if you were to commit to working on the project for a year it would not be sufficient time. Based on our prior year experience participating as an organization in GSoC I recommend that you find a project that can be completed in the course of a Summer. If you are successful and wish to remain working within the community past the end of the Summer, there will always be additional projects to tackle. Jeffrey Altman On 2/12/2011 12:20 AM, ambarisha b wrote: > Derrick, thanks for your response.I hope to extend my work beyond > GSoC, to finish the project.So, that's not a problem. > I went through the code to get an idea of the task at hand. This is > what I could come up with. > > I found most of the IP version dependent calls to the Sockets API > spread over the entire code.So trying to effect the extension would > mean heavy changes in a lot of places and in some cases the code could > get littered with #ifdef.Instead my idea was to write a separate > library where all the network transactions are handled.This library > would be IPv6 compatible.So remaining part of the code would go > through this library for any network access.I hope to design this > library optimised for our usage rather than a generic one. > > Please, express any of your concerns or ideas regarding the approach. > > Cheers > Ambarisha > > On Thu, Feb 10, 2011 at 2:03 AM, Derrick Brashear <[email protected]> wrote: >> Ambarisha, >> >> Extending AFS for IPv6 is probably beyond what can be accomplished as >> a GSoC student in a summer. A project of reduced scope doing a subset >> of that work might be possible. >> I'm not sure offhand what part of it I'd suggest. >> >> Derrick >> >> >> On Wed, Feb 9, 2011 at 2:35 AM, ambarisha b <[email protected]> wrote: >>> Hi, >>> I am a student aspiring to work for OpenAFS in GSoC 2011.I have >>> checked out the previous year's projects and requirements.On the >>> projects page, I found that there is a project proposed for extending >>> the current build to support IPv6.Can this be taken up as a GSoC >>> project ? Any project specific details would help. >>> >>> Thanks >>> Ambarisha >>> _______________________________________________ >>> OpenAFS-devel mailing list >>> [email protected] >>> https://lists.openafs.org/mailman/listinfo/openafs-devel >>> >> >> >> >> -- >> Derrick >> > _______________________________________________ > OpenAFS-devel mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-devel >
signature.asc
Description: OpenPGP digital signature
