NHRP v6 - hardware type / address type
Dave Katz <dkatz@cisco.com> Thu, 30 November 1995 06:54 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07848;
30 Nov 95 1:54 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa07843;
30 Nov 95 1:54 EST
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.98.5]) by
guelah.nexen.com (8.6.12/8.6.12) with ESMTP id BAA00516;
Thu, 30 Nov 1995 01:20:44 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id
BAA10099 for rolc-out; Thu, 30 Nov 1995 01:34:19 -0500
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by
maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id BAA10090 for
<rolc@nexen.com>; Thu, 30 Nov 1995 01:34:16 -0500
Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by
guelah.nexen.com (8.6.12/8.6.12) with ESMTP id BAA00512 for <rolc@nexen.com>;
Thu, 30 Nov 1995 01:19:43 -0500
Received: (dkatz@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id WAA08940;
Wed, 29 Nov 1995 22:29:42 -0800
Date: Wed, 29 Nov 1995 22:29:42 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz@cisco.com>
Message-Id: <199511300629.WAA08940@puli.cisco.com>
To: gja@thumper.bellcore.com
Cc: pkoning@chipcom.com, rolc@nexen.com, gja@thumper.bellcore.com
In-Reply-To: Grenville Armitage's message of Wed, 29 Nov 1995 17:00:31 -0500
<199511292200.RAA14118@thumper.bellcore.com>
Subject: NHRP v6 - hardware type / address type
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via
ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/
This is silly reasoning, and is not what I wrote.
The quote from me above means: ar$hrd = X, media is Ethernet, address is 48 bit MAC. ar$hrd = Y, media is FDDI, address is 48 bit MAC. (and of course) ar$hrd = Z, media is ATM, address is either E.164 or NSAPA. This is *exactly* why the hardware type was broken in ARP. There were a bazillion IP-over-Ethernet boxes in the field that expected type code 1, and could not talk to anything else. Along came FDDI; 1103 naively used the same type code as "802". Result--you couldn't interoperate because you could not fix the deployed base. What's wrong there? I never said that a different ar$hrd value has to mean a different address type from any other ar$hrd value. I dont know why anyone in their right minds would assume it had to. The problem is the opposite side--how does a box that likes media type X know that media type Y is the *same* address type, particularly if media type Y wasn't invented when the first box was deployed?
- RE: NHRP v6 - hardware type / address type Paul Koning 1695
- RE: NHRP v6 - hardware type / address type Paul Koning 1695
- RE: NHRP v6 - hardware type / address type Paul Koning 1695
- Re: NHRP v6 - hardware type / address type Grenville Armitage
- Re: NHRP v6 - hardware type / address type Grenville Armitage
- NHRP v6 - hardware type / address type Dave Katz