[OpenAFS] OpenAFS ipv6 migration path

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD5B6797171A59E64B1DB5F3B
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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
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=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
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=20
records
of the form "afs-map-<ID>.<domain>" and having those resolve to A and=20
AAAA
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
> 	clients.

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
connections
to peers with each address type.

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

Jeffrey Altman




--------------enigD5B6797171A59E64B1DB5F3B
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)

iQEcBAEBAgAGBQJQLxNGAAoJENxm1CNJffh4I9oH/2rq/gO4VHP5WbJqnM1jDUr9
o1LuJ7UwTcG7wf9a9mCkSunCr0aXy8l38SZ9TSVF1PEthA0VuKqJYAqkPjvWOI4e
NP3R4/bdyT5mG+3QZr9zR5nudldORXZdug0Zo2a85QuVFoIWvORHP0q3Uy8ID6hJ
9hZ9M4UYuAvynLKvgGnJmFuxVSU5QiJ2StCUKl/6Q2IXrWe4PJY0duYZAyP7/X2V
ULhcofp8/Ke1+PT5tKI7J6y7G9XOa56fuMUkMiKIX4r4mTbRnWnoRpyrwO3lEK6X
5uuk74e74AdrGwqWfP66D+q1sezCvUv/WplUYmkWP9rZyGDwZuCr/Dpdbkx1Ymk=
=/dK3
-----END PGP SIGNATURE-----

--------------enigD5B6797171A59E64B1DB5F3B--