Re: NHRP v6 - hardware type / address type

[Bruce Cole <[e-mail]>]

I think the way that NBMA address types are expressed in draft 06 is a step
backwards from what we had in draft 05 of the spec.

First, the ar$shtl and ar$sstl fields are described in terms of an ar$afn
field, but the ar$afn field is not described in the spec.  I'll assume
you meant to label the ar$hrd as ar$afn in the spec...

In version 05, instead of referring to a 16 bit hardware type, we had a more
general address type, taken from the 'address family numbers' space of
rfc1700.  The generalization was important, as hardware types such as ATM
don't map to a single address type.  The ARP RFC made this mistake years
ago, NHRP had corrected it, and now the mistake is being reintroduced
to NHRP via MARS alignment.

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 most significant bit is reserved and MUST be set to zero. The
>    second most significant bit (x) is a flag indicating whether the NBMA
>    address being referred to is in:
> 
>       - NSAP format (x = 0).
>       - Native E.164 format (x = 1).
> 
>    For NBMA technologies that use neither NSAP nor E.164 format
>    addresses, x = 0 SHALL be used to indicate the native form for the
>    particular NBMA technology.

The above bit seems very ATM-centric, as it only addresses ATM address
formats.  ATM is not the only link layer which has more than 1 address type.
Take for example frame-relay where your NBMA addresses may be either
E.164 or X.121.  Using another bit to represent X.121 is NOT a solution,
there are too many potential address types to use a flag bit for each one.

Therefore I request that the ar$afn field use NHRP 05's definition of
address type.  I believe that the ar$shtl and ar$sstl fields can then
be simplified to only specify lengths.