On 02/07/2011 05:39 PM, Jeffrey Hutzelman wrote:
--On Monday, February 07, 2011 04:00:40 PM -0600 Andrew Deason
<[email protected]> wrote:
On Mon, 07 Feb 2011 16:46:25 -0500
Jeffrey Hutzelman <[email protected]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
