[AFS3-std] Re: Encoding IPvN addresses

[Andrew Deason]

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.

On Tue, 8 Feb 2011 11:17:19 -0500
Derrick Brashear <shadow@gmail.com> wrote:

>> If we create such a new struct one could think of also adding the
>> port number and the service number as additional fields.
> 
> for things that don't want those, it's extra memory, though.

Realistically, how much in the protocol doesn't need those? In what way
could you be contacting a host and yet do not require a port and service
ID?

-- 
Andrew Deason
adeason@sinenomine.net