[AFS3-std] OpenAFS ipv6 migration path

[Troy Benjegerdes]

IPv4 address space is becoming a high-priced commodity
(see http://tradeipv4.com/faq/ ), and new user adoption of OpenAFS
may depend on a functional IPv6 implementation, or users will select
other distributed filesystems.

Because of the difficulties so clearly layed out below in a full
implementation:

On Fri, Aug 17, 2012 at 09:34:30PM -0400, Jeffrey Altman wrote:
> 
> IPv6 support has been on the wish list for OpenAFS since before I made
> my first contribution to the project in 2003.  On one hand it appears to
> be a trivial change to make.  Just add a new address type to the
> transport and you should be done.  The reality is something entirely
> different because AFS is not a point to point client server protocol
> such as telnet, ssh, http, etc.  Instead, it is a complex distributed
> system which has IPv4 addresses embedded just about everywhere from the
> database schemas, to the configuration files, to the ubik voting
> algorithm, to RPC message formats, to the command line parsers, etc.
> 
> Adding an IPv6 address to a host that has an IPv4 address makes it
> multi-homed and multi-homed systems are kind of supported for cache
> manager to file server interactions but for a large class of other
> service operations multi-homed support is practically non-existent.
> As a result, adding IPv6 is non-trivial and effectively requires a
> nearly complete re-write of the source tree.  To use IPv6 will require
> new clients and new services.


I propose the following ipv6-transition-draft outline

1) implement a header-file or library based approach to abstract all
use of IPv4 addresses to an opaque 32 bit identifier.

2) This identifier will then be mapped to a real IP address by DNS
 SRV records, much like dbserver and vlserver lookups are done.
	2b) If a _map._afs.<cell> record is not present, default
	configuration will map the opaque identifier to an IP address.

3) Those sites wishing to support IPv6 will publish AAAA records,
those wishing to support IPv4 will publish A records.

4) IPv4 and IPv6 multihoming will explicitly NOT be supported, 
 unless the underlying clients & servers already support multihoming.

5) 'true' IPv6 & IPv4 multihoming will be deferred until a large paying
 client demands such functionality.

6) IPv6 afs clients will communicate with ipv4 servers using an 
	http://tools.ietf.org/html/rfc6147 type translation.

7) IPv4 afs clients to IPv6 servers is an excercise for future paying
	clients.


Am I missing anything fundamental here that breaks, or is this 
feasible if someone has the time to implement, without causing
undue pain in the future?