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

[Jeffrey Hutzelman]

--On Monday, February 07, 2011 04:00:40 PM -0600 Andrew Deason 
<adeason@sinenomine.net> wrote:

> On Mon, 07 Feb 2011 16:46:25 -0500
> Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
>
>> Treat it as an opaque vector.  An IPv6 address is not actually an
>> array of 16- or 32-bit integers, and treating it that way means you're
>> going to have to jump through hoops to get the byte order right when
>> local byte order is not the same as network order.  Better to just
>> treat the whole thing as an opaque bitstring, which is what it is.
>
> That sounds more like the IPv6Bytes above than an XDR opaque, to me,
> since the length of the bitstring is known and not variable.

It's known, but it turns out that even in such cases, you pretty much never 
want to use an array of char, because each element takes up 32 bits on the 
wire.


> (Assuming
> you meant an opaque vector like the built-in XDR opaque vector, with the
> included encoded length).

If we're defining a new builtin type, along the lines of UUID, it does not 
need to be something that can be composed from the existing types.  The 
encoding for this on the wire ought to consist of an integer encoding the 
family, an integer encoding the size of the address data, and some number 
of octets encoding the address.  For IPv4 and IPv6, the address data 
consists of a single address, transmitted in exactly the same way as in IP 
headers.

-- Jeff