draft-ietf-rolc-nhrp-14.txt   rfc2332.txt 
Routing over Large Clouds Working Group James V. Luciani Network Working Group J. Luciani
INTERNET-DRAFT (Bay Networks) Request for Comments: 2332 Bay Networks
<draft-ietf-rolc-nhrp-14.txt> Dave Katz Category: Standards Track D. Katz
(cisco Systems) cisco Systems
David Piscitello D. Piscitello
(Core Competence, Inc.) Core Competence, Inc.
Bruce Cole B. Cole
(Juniper Networks) Juniper Networks
Naganand Doraswamy N. Doraswamy
(Bay Networks) Bay Networks
Expires June 1998 April 1998
NBMA Next Hop Resolution Protocol (NHRP) NBMA Next Hop Resolution Protocol (NHRP)
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document specifies an Internet standards track protocol for the
documents of the Internet Engineering Task Force (IETF), its areas, Internet community, and requests discussion and suggestions for
and its working groups. Note that other groups may also distribute improvements. Please refer to the current edition of the "Internet
working documents as Internet-Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the Copyright (C) The Internet Society (1998). All Rights Reserved.
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract Abstract
This document describes the NBMA Next Hop Resolution Protocol (NHRP). This document describes the NBMA Next Hop Resolution Protocol (NHRP).
NHRP can be used by a source station (host or router) connected to a NHRP can be used by a source station (host or router) connected to a
Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the
internetworking layer address and NBMA subnetwork addresses of the internetworking layer address and NBMA subnetwork addresses of the
''NBMA next hop'' towards a destination station. If the destination is "NBMA next hop" towards a destination station. If the destination is
connected to the NBMA subnetwork, then the NBMA next hop is the connected to the NBMA subnetwork, then the NBMA next hop is the
destination station itself. Otherwise, the NBMA next hop is the destination station itself. Otherwise, the NBMA next hop is the
egress router from the NBMA subnetwork that is ''nearest'' to the egress router from the NBMA subnetwork that is "nearest" to the
destination station. NHRP is intended for use in a multiprotocol destination station. NHRP is intended for use in a multiprotocol
internetworking layer environment over NBMA subnetworks. internetworking layer environment over NBMA subnetworks.
Note that while this protocol was developed for use with NBMA Note that while this protocol was developed for use with NBMA
subnetworks, it is possible, if not likely, that it will be applied subnetworks, it is possible, if not likely, that it will be applied
to BMA subnetworks as well. However, this usage of NHRP is for to BMA subnetworks as well. However, this usage of NHRP is for
further study. further study.
This document is intended to be a functional superset of the NBMA This document is intended to be a functional superset of the NBMA
Address Resolution Protocol (NARP) documented in [1]. Address Resolution Protocol (NARP) documented in [1].
skipping to change at line 88 skipping to change at page 2, line 38
One way to model an NBMA network is by using the notion of logically One way to model an NBMA network is by using the notion of logically
independent IP subnets (LISs). LISs, as defined in [3] and [4], have independent IP subnets (LISs). LISs, as defined in [3] and [4], have
the following properties: the following properties:
1) All members of a LIS have the same IP network/subnet number 1) All members of a LIS have the same IP network/subnet number
and address mask. and address mask.
2) All members of a LIS are directly connected to the same 2) All members of a LIS are directly connected to the same
NBMA subnetwork. NBMA subnetwork.
3) All hosts and routers outside of the LIS are accessed via a router. 3) All hosts and routers outside of the LIS are accessed via
a router.
4) All members of a LIS access each other directly (without routers). 4) All members of a LIS access each other directly (without
routers).
Address resolution as described in [3] and [4] only resolves the next Address resolution as described in [3] and [4] only resolves the next
hop address if the destination station is a member of the same LIS as hop address if the destination station is a member of the same LIS as
the source station; otherwise, the source station must forward the source station; otherwise, the source station must forward
packets to a router that is a member of multiple LIS's. In multi-LIS packets to a router that is a member of multiple LIS's. In multi-LIS
configurations, hop-by-hop address resolution may not be sufficient configurations, hop-by-hop address resolution may not be sufficient
to resolve the "NBMA next hop" toward the destination station, and IP to resolve the "NBMA next hop" toward the destination station, and IP
packets may have multiple IP hops through the NBMA subnetwork. packets may have multiple IP hops through the NBMA subnetwork.
Another way to model NBMA is by using the notion of Local Address Another way to model NBMA is by using the notion of Local Address
skipping to change at line 1127 skipping to change at page 25, line 6
which contains a NAK code of 4. which contains a NAK code of 4.
5 - Insufficient Resources 5 - Insufficient Resources
If an NHS cannot serve a station due to a lack of resources If an NHS cannot serve a station due to a lack of resources
(e.g., can't store sufficient information to send a purge if (e.g., can't store sufficient information to send a purge if
routing changes), the NHS MUST reply with a NAKed NHRP routing changes), the NHS MUST reply with a NAKed NHRP
Resolution Reply which contains a NAK code of 5. Resolution Reply which contains a NAK code of 5.
12 - No Internetworking Layer Address to NBMA Address Binding 12 - No Internetworking Layer Address to NBMA Address Binding
Exists Exists
This code states that there were absolutely no internetworking This code states that there were absolutely no internetworking
layer address to NBMA address bindings found in the responding layer address to NBMA address bindings found in the responding
NHS's cache. NHS's cache.
13 - Binding Exists But Is Not Unique 13 - Binding Exists But Is Not Unique
This code states that there were one or more internetworking This code states that there were one or more internetworking
layer address to NBMA address bindings found in the responding layer address to NBMA address bindings found in the responding
NHS's cache, however none of them had the uniqueness bit set. NHS's cache, however none of them had the uniqueness bit set.
skipping to change at line 2013 skipping to change at page 44, line 5
compromised, then NHRP entities are liable to both spoofing attacks, compromised, then NHRP entities are liable to both spoofing attacks,
active attacks and passive attacks. active attacks and passive attacks.
There is no mechanism to encrypt the messages. It is assumed that a There is no mechanism to encrypt the messages. It is assumed that a
standard layer 3 confidentiality mechanism will be used to encrypt standard layer 3 confidentiality mechanism will be used to encrypt
and decrypt messages. It is recommended to use an Internet standard and decrypt messages. It is recommended to use an Internet standard
key management protocol to negotiate the keys between the neighbors. key management protocol to negotiate the keys between the neighbors.
Transmitting the keys in clear text, if other methods of negotiation Transmitting the keys in clear text, if other methods of negotiation
is used, compromises the security completely. is used, compromises the security completely.
Any NHS is susceptible to Denial of Service (DOS) attacks that cause
it to become overloaded, preventing legitimate packets from being
acted upon properly. A rogue host can send request and registration
packets to the first hop NHS. If the authentication option is not
used, the registration packet is forwarded along the routed path
requiring processing along each NHS. If the authentication option is
used, then only the first hop NHS is susceptible to DOS attacks
(i.e., unauthenticated packets will be dropped rather than forwarded
on). If security of any host is compromised (i.e., the keys it is
using to communicate with an NHS become known), then a rogue host can
send NHRP packets to the first hop NHS of the host whose keys were
compromised, which will then forward them along the routed path as in
the case of unauthenticated packets. However, this attack requires
that the rogue host to have the same first hop NHS as that of the
compromised host. Finally, it should be noted that denial of service
attacks that cause routers on the routed path to expend resources
processing NHRP packets are also susceptable to attacks that flood
packets at the same destination as contained in an NHRP packet's
Destination Protocol Address field.
5.3.5 NHRP Vendor-Private Extension 5.3.5 NHRP Vendor-Private Extension
Compulsory = 0 Compulsory = 0
Type = 8 Type = 8
Length = variable Length = variable
The NHRP Vendor-Private Extension is carried in NHRP packets to The NHRP Vendor-Private Extension is carried in NHRP packets to
convey vendor-private information or NHRP extensions between NHRP convey vendor-private information or NHRP extensions between NHRP
speakers. speakers.
skipping to change at line 2191 skipping to change at page 48, line 17
covered by the prefix, (b) the NHS does not have any routes with covered by the prefix, (b) the NHS does not have any routes with
NLRI which form a subset of what is covered by the prefix. The NLRI which form a subset of what is covered by the prefix. The
prefix may then be used in the CIE. prefix may then be used in the CIE.
The Prefix Length field of the CIE should be used with restraint, in The Prefix Length field of the CIE should be used with restraint, in
order to avoid NHRP stations choosing suboptimal transit paths when order to avoid NHRP stations choosing suboptimal transit paths when
overlapping prefixes are available. This document specifies the use overlapping prefixes are available. This document specifies the use
of the prefix length only when all the destinations covered by the of the prefix length only when all the destinations covered by the
prefix are "stable". That is, either: prefix are "stable". That is, either:
(a) All destinations covered by the prefix are on the NBMA network, or (a) All destinations covered by the prefix are on the NBMA network,
or
(b) All destinations covered by the prefix are directly attached to (b) All destinations covered by the prefix are directly attached to
the NHRP responding station. the NHRP responding station.
Use of the Prefix Length field of the CIE in other circumstances is Use of the Prefix Length field of the CIE in other circumstances is
outside the scope of this document. outside the scope of this document.
6.4 Domino Effect 6.4 Domino Effect
One could easily imagine a situation where a router, acting as an One could easily imagine a situation where a router, acting as an
ingress station to the NBMA subnetwork, receives a data packet, such ingress station to the NBMA subnetwork, receives a data packet, such
skipping to change at line 2263 skipping to change at page 49, line 42
servers" for the station. The station could then choose to resolve servers" for the station. The station could then choose to resolve
the NBMA next hop or just send the packets to one of its the NBMA next hop or just send the packets to one of its
connectionless servers. The latter option may be desirable if connectionless servers. The latter option may be desirable if
communication with the destination is short-lived and/or doesn't communication with the destination is short-lived and/or doesn't
require much network resources. The connectionless servers could, of require much network resources. The connectionless servers could, of
course, be physically integrated in the NHSs by augmenting them with course, be physically integrated in the NHSs by augmenting them with
internetwork layer switching functionality. internetwork layer switching functionality.
9. IANA Considerations 9. IANA Considerations
IANA will take advice from James Luciani (see author information IANA will take advice from the Area Director appointed designated
below for contact information), who is the Area Director appointed subject matter expert, in order to assign numbers from the various
designated subject matter expert, in order to assign numbers from the number spaces described herein. In the event that the Area Director
various number spaces described herein. In the event that the Area appointed designated subject matter expert is unavailable, the
Director appointed designated subject matter expert is unavailable, relevant IESG Area Director will appoint another expert. Any and all
the relevant IESG Area Director will appoint another expert. Any and requests for value assignment within a given number space will be
all requests for value assignment within a given number space will be
accepted when the usage of the value assignment documented. Possible accepted when the usage of the value assignment documented. Possible
forms of documentantion include, but is not limited to, RFCs or the forms of documentantion include, but is not limited to, RFCs or the
product of another cooperative standards body (e.g., the MPOA and product of another cooperative standards body (e.g., the MPOA and
LANE subworking group of the ATM Forum). LANE subworking group of the ATM Forum).
References References
[1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh [1] Heinanen, J., and R. Govindan, "NBMA Address Resolution Protocol
Govindan, RFC1735. (NARP)", RFC 1735, December 1994.
[2] Address Resolution Protocol, David C. Plummer, RFC 826. [2] Plummer, D., "Address Resolution Protocol", STD 37, RFC 826,
November 1982.
[3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577. [3] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", RFC
2225, April 1998.
[4] Transmission of IP datagrams over the SMDS service, J. Lawrence [4] Piscitello,, D., and J. Lawrence, "Transmission of IP datagrams
and D. Piscitello, RFC 1209. over the SMDS service", RFC 1209, March 1991.
[5] Protocol Identification in the Network Layer, ISO/IEC TR [5] Protocol Identification in the Network Layer, ISO/IEC TR
9577:1990. 9577:1990.
[6] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700. [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[7] Multiprotocol Encapsulation over ATM Adaptation Layer 5, J. Heinanen, [7] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
RFC1483. Layer 5", RFC 1483, July 1993.
[8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode, [8] Malis, A., Robinson, D., and R. Ullmann, "Multiprotocol
A. Malis, D. Robinson, and R. Ullmann, RFC1356. Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356, August
1992.
[9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and [9] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect
A. Malis, RFC1490. over Frame Relay", RFC 1490, July 1993.
[10] "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks, [10] Rekhter, Y., and D. Kandlur, ""Local/Remote" Forwarding Decision
Yakov Rekhter, Dilip Kandlur, RFC1937. in Switched Data Link Subnetworks", RFC 1937, May 1996.
[11] Support for Multicast over UNI 3.0/3.1 based ATM Networks, [11] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
G. Armitage, RFC2021 Networks", RFC 2022, November 1996.
[12] Server Cache Synchronization Protocol (SCSP) - NBMA, [12] Luciani, J., Armitage, G., and J. Halpern, "Server Cache
J. Luciani, G. Armitage, J. Halpern, draft-ietf-ion-scsp-02.txt Synchronization Protocol (SCSP) - NBMA", RFC 2334, April 1998.
[13] NHRP for Destinations off the NBMA Subnetwork, [13] Rekhter, Y., "NHRP for Destinations off the NBMA Subnetwork",
Y. Rekhter, Work In Progress. Work In Progress.
[14] Classical IP to NHRP Transition, J. Luciani, et al., Work In Progress. [14] Luciani, J., et. al., "Classical IP and ARP over ATM to NHRP
Transition", Work In Progress.
[15] Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement
RFC 2119. Levels", BCP 14, RFC 2119, March 1997.
[16] "HMAC: Keyed Hashing for Message Authentication", Krawczyk, Bellare, [16] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed Hashing
Canetti, RFC 2104. for Message Authentication", RFC 2104, February 1997.
Acknowledgments Acknowledgments
We would like to thank (in no particular order) Naganand Doraswamy of We would like to thank (in no particular order) Thomas Narten of IBM
Bay Networks for the entirety of the security section, Thomas Narton for his comments in the role of Internet AD, Juha Heinenan of Telecom
of IBM for his comments in the role of Internet AD, Juha Heinenan of Finland and Ramesh Govidan of ISI for their work on NBMA ARP and the
Telecom Finland and Ramesh Govidan of ISI for their work on NBMA ARP original NHRP draft, which served as the basis for this work.
and the original NHRP draft, which served as the basis for this work.
Russell Gardo of IBM, John Burnett of Adaptive, Dennis Ferguson of Russell Gardo of IBM, John Burnett of Adaptive, Dennis Ferguson of
ANS, Andre Fredette of Bay Networks, Joel Halpern of Newbridge, Paul ANS, Andre Fredette of Bay Networks, Joel Halpern of Newbridge, Paul
Francis of NTT, Tony Li, Bryan Gleeson, and Yakov Rekhter of cisco, Francis of NTT, Tony Li, Bryan Gleeson, and Yakov Rekhter of cisco,
and Grenville Armitage of Bellcore should also be acknowledged for and Grenville Armitage of Bellcore should also be acknowledged for
comments and suggestions that improved this work substantially. We comments and suggestions that improved this work substantially. We
would also like to thank the members of the ION working group of the would also like to thank the members of the ION working group of the
IETF, whose review and discussion of this document have been IETF, whose review and discussion of this document have been
invaluable. invaluable.
Authors' Addresses Authors' Addresses
James V. Luciani Dave Katz James V. Luciani Dave Katz
Bay Networks cisco Systems Bay Networks cisco Systems
3 Federal Street 170 W. Tasman Dr. 3 Federal Street 170 W. Tasman Dr.
Mail Stop: BL3-03 San Jose, CA 95134 USA Mail Stop: BL3-03 San Jose, CA 95134 USA
Billerica, MA 01821 Phone: +1 408 526 8284 Billerica, MA 01821 Phone: +1 408 526 8284
Phone: +1 978 916 4734 Email: dkatz@cisco.com Phone: +1 978 916 4734 EMail: dkatz@cisco.com
Email: luciani@baynetworks.com EMail: luciani@baynetworks.com
David Piscitello Bruce Cole David Piscitello Bruce Cole
Core Competence Juniper Networks Core Competence Juniper Networks
1620 Tuckerstown Road 3260 Jay St. 1620 Tuckerstown Road 3260 Jay St.
Dresher, PA 19025 USA Santa Clara, CA 95054 Dresher, PA 19025 USA Santa Clara, CA 95054
Phone: +1 215 830 0692 Phone: +1 408 327 1900 Phone: +1 215 830 0692 Phone: +1 408 327 1900
Email: dave@corecom.com Email: bcole@jnx.com EMail: dave@corecom.com EMail: bcole@jnx.com
Naganand Doraswamy Naganand Doraswamy
Bay Networks, Inc. Bay Networks, Inc.
3 Federal Street 3 Federal Street
Mail Stop: Bl3-03 Mail Stop: Bl3-03
Billerica, MA 01821 Billerica, MA 01801
Phone: +1 978 916 1323 Phone: +1 978 916 1323
Email: naganand@baynetworks.com EMail: naganand@baynetworks.com
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 33 change blocks. 
74 lines changed or deleted 93 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/