[OpenAFS] OpenAFS ipv6 migration path
Sat, 18 Aug 2012 00:00:04 -0400
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=UTF-8
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=20
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=20
of these mappings?
How will existing tools work with servers that expect the mappings=20
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=20
> 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=20
of the form "afs-map-<ID>.<domain>" and having those resolve to A and=20
records as appropriate would make more sense to me. But oh my is this=20
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
You need to modify all of the places where addresses are used to be=20
able to recognize
when the address is which type and rx needs to be modified to establish=20
to peers with each address type.
I'm not sure you are reducing the amount of work involved not if your=20
is to support mixed environments and OpenAFS must support mixed=20
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
-----END PGP SIGNATURE-----