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

[Jeffrey Hutzelman]

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

> Derrick Brashear wrote:
>> On Tue, Feb 8, 2011 at 11:09 AM, Hartmut Reuter<reuter@rzg.mpg.de>
>> wrote:
>>> Simon Wilkinson wrote:
>>>>
>>>> On 8 Feb 2011, at 15:20, Derrick Brashear wrote:
>>>>
>>>>> struct {
>>>>> int addrtype;
>>>>> int addrlen;
>>>>> int addr<>
>>>>> } rx_addr;
>>>>>
>>>>> # define RX_ADDRTYPE_IPV4 1
>>>>> # define RX_ADDRTYPE_IPV6 2
>>>>
>>>> Why not just use an opaque? That way you don't get into any of the
>>>> ordering issues that ints bring with them.
>>>>
>>>> struct {
>>>> int addrtype;
>>>> opaque addr<>;
>>>> } rx_addr;
>>>
>>> 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).
>>>
>>> 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];
>>> };
>>>
>>> I also think instead of inventing new constants it's better to use the
>>> version numbers 4 and 6 directly.
>>>
>>> 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.
>>
>> the only problem is we're back to a union with fixed discrimination
>> that doesn't allow us to add things later.
>
> But only in the memory, not on the wire.

False.  On the wire, it breaks things permanently, because receipt of such 
a union with an unknown discriminator will cause decoding to fail, which 
means the call gets aborted.  If VL_GetAddrsNewAndShiny returns a list of 
all of a server's addresses, then we must allow for the case where some of 
those addresses will be types not known to the client.  In fact, we may 
want a fileserver calling VL_RegisterAddrsNewAndShiny to be able to 
register addresses of types not known to the vlserver.

-- Jeff