RE: NHRP v6 - hardware type / address type

[Paul Koning 1695 <[e-mail]>]

Grenville Armitage <[e-mail]> wrote

(in an earlier note)

>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.

(and in a later note)

>I would like to know the converse. Why should media information
>be lacking? I dont see the supposed 'ARP mistake' as being
>sufficient motive for shying away from this.

The reason media information should be lacking is to make it impossible
for people to commit the mistake that's in your earlier note!

"...identifies the media type, which also identifies the address type..."
That simply is not true.  And that is the experience Dave and I were
referring to.

Would you give Ethernet and FDDI different media types?  If yes, note
that they use the same address type, so your equating of media type
and address type is not valid.  If no, then what does "media type" mean?

To be specific about the bad experience: ARP has a "hardware type"
which for the first 10 years or so effectively only had one value: 1.  Then
802 came along, and a new value (6) was assigned to "IEEE 802".  That
didn't matter much so long as it was only used with 802.5 (which doesn't
transparently bridge to anything).

Then FDDI arrived.  Some early implementers, arguing that FDDI is
a token ring also, applied hardware type 6 to it.  (Never mind that FDDI and
802.5 have nothing to speak of in common...)  Then transparent
Ethernet-FDDI bridges appeared, since those are not hard to do.  Result:
ARPs with hardware type mismatches started appearing.  Some
implementations, whether through luck or foresight, simply ignored the
hardware type and everything worked.  Others, however, made the
grave mistake of assuming that hardware type = address type, and
therefore "obviously" they could not accept an ARP with mismatching
hardware type.  Result: a failure to communicate that was utterly
gratuitous.  Solution: RFC 1103, and its successors (IP over FDDI)
require that the hardware type must be 1 and NOT 6 for FDDI.  Along
with that there was a recommendation (I don't remember if it was written
down) that every ARP implementation should accept either 1 and 6 as
synonyms in a received ARP, so as to work around this problem.

>If you're doing cross-media bridging then it hardly matters if you're
>using a number space in the nhrp packet that is supposedly 
media-independent.
>If each media use dissimilar address spaces you're stuffed either way,
>and need to do address translation (or dont bridge/dont do nhrp across
>the boundary).

I'm not quite sure what the first sentence means.  But on the second
sentence I quite agree.  The issue, however, is for the case where
the address spaces ARE the same cross-media.  In that case we
must not give people an incentive to reject packets that are perfectly
useable -- which is exactly what happened with ARP, because it has
a hardware type field.

     paul