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

[Jason Edgecombe]

On 02/07/2011 05:39 PM, Jeffrey Hutzelman wrote:
> --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.

Is there a plausible case where multiple IPv4, IPv6 or a mixture of 
addresses would need to be packed into this single field? I'm just 
wondering if we need to deal with multicast/anycast/foocast or dual 
IPv4/IPv6 layers.

I'm guessing that these cases would be a list or array of the field 
under discussion, but I wanted to ask the naive question.

Sincerely,
Jason