Re: NHRP v6 - hardware type / address type

[Bruce Cole <[e-mail]>]

> Solving this issue involves noting that, in my opinion, there is
> value in using this 16 bit field to identify both the type of
> the media and the type of the addresses.

Like Dave, I don't understand why the media type helps.  Why should the
address resolution protocol be concerned with the media type instead of
just the address type?

> On the
> other hand, the hardware type number space explicitly identifies the
> media type, which also identifies the address type(s) that one
> is going to find inside the control packet.

In my last message, I pointed out two media types for which there is
not a 1 to 1 correspondence between media types and address types.  Media
type to address type is a many to many mapping, so media type does not
identify the address type.

> >>It looks like the 06 spec tries to address this problem with a flag bit:
> >>
> >>>    The ar$shtl and ar$sstl fields are coded as follows:
> >>> 
> >>>                 7 6 5 4 3 2 1 0
> >>>                +-+-+-+-+-+-+-+-+
> >>>                |0|x|  length   |
> >>>                +-+-+-+-+-+-+-+-+
> >>>
> 
> The realisation that an NBMA technology such as ATM allowed two
> address types led to the single flag bit you see in the ar$shtl field.
> Physically it is detached from the ar$hrd field, but semantically
> is it associated with the 'address type identification' role that
> the ar$hrd value provides.

So semantically, 06 is requiring 2 (or 3) fields to identify an address type,
whereas 05 did so with one.  And 06 is requiring a bit to be defined for each
media type that uses more than 1 address type.

> Detaching it from the ar$hrd field is
> required because not only does ATM allow two address types (NSAPA
> and E.164), but it allows three combinations of address and subaddress
> to represent an NBMA endpoint.

I don't see this as the only choice.  If there are 3 combinations of
address and subaddress for ATM, then how about simply defining 3
distinct address types?

> 	- In any given instance of a nhrp message, the flag bit in
> 	  the ar$shtl field indentifies which of the two address
> 	  types the supplied address is.

This presumes that there will only be two address types for any media.
It would also seem to require the NHRP spec to enumerate all the media
types, specifying what these bits mean in each media's context.  The
address family numbers space of rfc1700 is already designed for this
purpose, and is a more appropriate place to enumerate address types, IMO.