[AFS3-std] Re: Encoding IPvN addresses

[Jeffrey Hutzelman]

--On Tuesday, February 08, 2011 05:53:02 PM -0600 Andrew Deason 
<adeason@sinenomine.net> wrote:

> On Tue, 8 Feb 2011 15:23:41 +0000
> Simon Wilkinson <simon@sxw.org.uk> wrote:
>
>> 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;
>
> Assuming we don't want to use RFC 5665, that looks good to me. But what
> to do about transport layer, port numbers, and service numbers?
>
> Any of these could be separate fields, or a 'field' inside the
> address-specific blob, or not in the rx_addr structure at all.
> Additionally, the transport layer could be merged into the address type.
> For example, you could the struct above with address types for IPv4-UDP,
> IPv4-TCP, IPv6-UDP, etc. Or, we could have it as a separate field:
>
> struct {
>   int addrtype;
>   int transport;
>   opaque addr<>;
> } rx_addr;
>
> Or it could be a field inside the address-specific blob:
>
> struct {
>   int addrtype;
>   opaque addr<>;
> } rx_addr;
>
> where 'addr' is XDR-encoded:
>
> struct {
>   int transport;
>   opaque real_addr<>;
> } rx_ipv4_addr;
>
> Or we put it in a different structure/field in whatever RPCs use the
> rx_addr struct:
>
> struct ubik_addr {
>   int transport;
>   rx_addr addr;
> };
>
> struct UbikInterfaceInfo {
>   afsUUID uuid;
>   struct ubik_addr[UBIK_MAX_INTERFACE_ADDR];
> };
>
> For the transport layer, it seems easiest to just make IPv4-UDP and
> IPv4-TCP et al address types. But try the above examples with port and
> service numbers. Ports make sense to me inside the address-specific
> blob, because a 'port' may not exist in whatever transport we're talking
> about (or may have a different range/format), so should be tied to the
> transport somehow. And a service ID could live in the rx_addr struct
> itself, since we need one for any Rx RPC invocation.

But, and here's the key point...
I thought we were talking about network addresses.
When did we decide to talk exclusively about Rx endpoints?


I have seen lots of code that uses 'struct sockaddr' to represent network 
addresses, because it's conveniently available and has well-defined 
semantics for describing multiple different types of networks (in fact, it 
is a discriminated union).  But this structure is really intended to 
represent transport endpoints (sockets), and additional data like port 
numbers is just wasted space for applications that aren't using it that way.

I'm willing to be convinced otherwise, but I really think we want a 
representation of network addresses, not transport endpoints and not Rx 
endpoints.

-- Jeff