[AFS3-std] Re: Encoding IPvN addresses (was Re: first draft: ubik update proposal)

[Jeffrey Hutzelman]

--On Tuesday, February 08, 2011 05:09:42 PM +0100 Hartmut Reuter 
<reuter@rzg.mpg.de> wrote:

> opaque requires xdr_alloc and later xdr_free of the data and in the case
> of IPv4 the address typically is used as an integer which then would have
> been first converted from the opaque (including changing host byte order).

No, you don't have to do anything with byte order.  IPv4 addresses are 
typically stored in network order even on systems with VAX order, so just 
copying the bits is fine (whereas, if you send it as an integer, you have 
to convert _from_ network order _to_ host order before passing it to XDR, 
which will then convert it _back_ to network order for transport).


> Therefore I had proposed in my change I8aa46a29:
> src/fsint/fs_rxosd_common.xg
> for both address types to use afs_uint32s:
>
> union ipadd switch(afs_int32 vsn) {
> case 4:
>          afs_uint32 ipv4;
> case 6:
>          afs_uint32 ipv6[4];
> };


Uck.  Besides the double byte-order conversion I mention above, use of a 
union like this doesn't allow us to extend it later with new types. 
Imagine not being able to talk to a fileserver _at all_ because its entry 
in the VLDB contains one address of a type you don't understand, and thus 
you cannot decode the reply of VL_GetAddrsNewAndShiny


> I also think instead of inventing new constants it's better to use the
> version numbers 4 and 6 directly.

Ugh ugh no.  The "version numbers" are imaginary; just because we _call_ 
them "version 4" and "version 6" does not mean anything ever uses "4" and 
"6" to name these (the versions do appear in the IP headers, but that's 
really just wasted space -- you have to already know what you're parsing to 
correctly decode a packet).  I know of no existing protocol that 
distinguishes between these protocols using those numbers.  There are 
existing registries of protocol numbers and address families, and I'm 
pretty sure there's one we can reuse rather than inventing our own, but IP 
version numbers is not one of them.

Besides, this assumes that versions of IP are the only layer-3 protocols 
we'll ever care about.

> In the case of IPv6 the application easily can fill the contents into the
> host's struct in6_addr using the u6_addr32 fields while for IPv4 the
> address can be used directly.

You mean, except for the need to convert to host byte order, since both 
in_addr and in6_addr are normally stored in network order, and XDR expects 
integer fields to require conversion.

> If we create such a new struct one could think of also adding the port
> number and the service number as additional fields.

I've thought about this, and at the moment I think the right thing is to 
concentrate on addresses, and treat things at layer 4 and above separately.

-- Jeff