On Friday, August 17, 2012 11:00:55 PM, Troy Benjegerdes wrote:
> 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.

Currently they are afs_uint32.  That is a 32-bit identifier.  How are 
you going
to distinguish between the use of a real IPv4 address and a mapped one?

How are existing clients expected to behave when they are delivered one 
of these mappings?

How will existing tools work with servers that expect the mappings 
instead of real IP addresses and vice versa?

How are mixed server environments supposed to function?

How will the VLDB determine when to send a mapping vs a true IPv4 
address?

> 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.

I don't see how SRV records could be used for this.  Publishing CNAME 
records
of the form "afs-map-<ID>.<domain>" and having those resolve to A and 
AAAA
records as appropriate would make more sense to me.   But oh my is this 
an ugly hack.

> 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.

Why would there be a client that is IPv6 only?

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

You need to modify all of the places where addresses are used to be 
able to recognize
when the address is which type and rx needs to be modified to establish 
connections
to peers with each address type.

I'm not sure you are reducing the amount of work involved not if your 
goal
is to support mixed environments and OpenAFS must support mixed 
environments.

Jeffrey Altman



Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to