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

[Derrick Brashear]

How about this? If this is agreement i can write up a draft.

enum ippack { IPv4=3D1, IPv6Bytes=3D2, IPv6Shorts=3D3, IPV6Ints=3D4 };

struct rx_addr {
        enum ippack ippack;   /*  the union's discriminant  */
        union {
                afs_uint32 ip4_addr;
                unsigned char ip6_addr8[16];
                afs_uint16  ip6_addr16[8];
                afs_uint32  ip6_addr32[4];
        } ipN_addr;
};

Serialize and deserialize the discriminated union:

struct xdr_discrim rx_addr_arms[5] =3D {
    { IPv4, xdr_int },
    { IPv6Bytes, xdr_ip6_addr8 }
    { IPv6Shorts, xdr_ip6_addr16 },
    { IPv6Ints, xdr_ip6_addr32 },
    { 0, NULL }
}

bool_t
xdr_rx_addr(xdrs, utp)
    XDR *xdrs;
    struct u_tag *utp;
{
    return(xdr_union(xdrs, &utp->ippack, &utp->ipNaddr,
        rx_addr_arms, NULL));
}

Defining the obvious xdr types for the ipv6 address subtypes.


On Mon, Feb 7, 2011 at 11:34 AM, Steve Simmons <scs@umich.edu> wrote:
>
> On Feb 5, 2011, at 11:12 AM, Hartmut Reuter wrote:
>
>> Derrick Brashear wrote:
>>> On Sat, Feb 5, 2011 at 4:09 AM, Jeffrey Hutzelman<jhutz@cmu.edu> =A0wro=
te:
>>>> --On Friday, February 04, 2011 10:14:23 AM -0600 Andrew Deason
>>>> <adeason@sinenomine.net> =A0wrote:
>>>>
>>>>> On Fri, 4 Feb 2011 09:32:53 -0500
>>>>> Derrick Brashear<shadow@gmail.com> =A0wrote:
>>>>>
>>>>>> struct UbikInterfaceInfo {
>>>>>> =A0 =A0 =A0 =A0afsUUID uuid;
>>>>>> =A0 =A0 =A0 =A0struct sockaddr_storage hostAddr[UBIK_MAX_INTERFACE_A=
DDR];
>>>>>> };
>>>>>
>>>>> I thought struct sockaddr_storage can be different on different
>>>>> implementations, and isn't guaranteed to store ~everything, just the
>>>>> representations that host supports. This is something I've been a lit=
tle
>>>>> unclear about, actually; is there any existing standard for transmitt=
ing
>>>>> generalized network addresses across platforms? Or does everyone just
>>>>> come up with their own?
>>>>
>>>> Indeed, sockaddr_storage is an API artifact, and certainly not suitabl=
e for
>>>> use in an Rx RPC signature. =A0The appropriate thing here is some kind=
 of
>>>> discriminated union. =A0We should probably define such a type as an ex=
tension
>>>> to the "standard" types supported by Rx, rather than doing it in Ubik =
and
>>>> again in VL and again in RXAFSCB and so on and so on.
>>>
>>> to that end, may i propose that rx define a type e.g.
>>> typedef struct
>>> {
>>> =A0 /* The discriminator for the union below. */
>>> =A0 rx_addrtype_t addr_type;
>>> =A0 union
>>> =A0 {
>>> =A0 =A0 /* IPv4 address, in network byte order. */
>>> =A0 =A0 struct in_addr ipv4;
>>>
>>> =A0 =A0 /* IPv6 address, in network byte order. */
>>> =A0 =A0 struct in6_addr ipv6;
>>> =A0 } addr;
>>> } rxaddr_t;
>>
>>
>> This will not work because in6_addr is a union and xdr cannot handle uni=
ons unless you have a switch variable which says which branch of the union =
should be used. 16 bytes are not the same as 4 int32 if you have different =
endianess!
>
> This is kind of ugly, but might be representable in xdr (which I'm modera=
tely ignorant of):
>
> typedef struct
> {
> =A0/* The discriminator for the union below. */
> =A0rx_addrtype_t addr_type;
> =A0addr char addr_buf[ sizeof(struct in6_addr) ];
> } rxaddr_t;
>
>> typedef enum
>> {
>> =A0 /* IPv4 address */
>> =A0 RX_IPV4 =3D 0x1,
>> =A0 /* IPv6 address */
>> =A0 RX_IPV6 =3D 0x2
>> } rx_addrtype_t;
>
>
> It would clearly need a couple of helper functions so we could do things =
like
>
> =A0struct rxaddr_t address;
> =A0struct in_addr ipv4addr;
> =A0struct in6_addr ipv6addr;
>
> =A0switch ( address.addr_type) {
> =A0 =A0case RX_IPV4:
> =A0 =A0 =A0addrbuf2ipv4( address, &ipv4addr );
> =A0 =A0 =A0break;
> =A0 =A0case RX_IPV6:
> =A0 =A0 =A0addrbuf2ipv6( address, &ipv6addr );
> =A0 =A0 =A0break;
> =A0 =A0default:
> =A0 =A0 =A0whoops();
> =A0}
>
> and matching ipv{4,6}addr2addrbuf() functions. In the best of all worlds,=
 these would be mostly simple calls to memcpy().
>
> Steve_______________________________________________
> AFS3-standardization mailing list
> AFS3-standardization@openafs.org
> http://lists.openafs.org/mailman/listinfo/afs3-standardization
>



--=20
Derrick