draft-ietf-rolc-nhrp-11.txt   draft-ietf-rolc-nhrp-12.txt 
Routing over Large Clouds Working Group James V. Luciani Routing over Large Clouds Working Group James V. Luciani
INTERNET-DRAFT (Bay Networks) INTERNET-DRAFT (Bay Networks)
<draft-ietf-rolc-nhrp-11.txt> Dave Katz <draft-ietf-rolc-nhrp-12.txt> Dave Katz
(cisco Systems) (cisco Systems)
David Piscitello David Piscitello
(Core Competence, Inc.) (Core Competence, Inc.)
Bruce Cole Bruce Cole
(Juniper Networks) (Juniper Networks)
Expires September 1997
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 is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim). Rim).
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [15].
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 page 4, line 20 skipping to change at page 4, line 25
in the context of NHRP. We use the following terms: in the context of NHRP. We use the following terms:
Internetwork layer--the media-independent layer (IP in the case of Internetwork layer--the media-independent layer (IP in the case of
TCP/IP networks). TCP/IP networks).
Subnetwork layer--the media-dependent layer underlying the Subnetwork layer--the media-dependent layer underlying the
internetwork layer, including the NBMA technology (ATM, X.25, SMDS, internetwork layer, including the NBMA technology (ATM, X.25, SMDS,
etc.) etc.)
The term "server", unless explicitly stated to the contrary, refers The term "server", unless explicitly stated to the contrary, refers
to an Next Hop Server (NHS). An NHS is an entity performing the to a Next Hop Server (NHS). An NHS is an entity performing the
Next Hop Resolution Protocol service within the NBMA cloud. An NHS Next Hop Resolution Protocol service within the NBMA cloud. An NHS
is always tightly coupled with a routing entity (router, route is always tightly coupled with a routing entity (router, route
server or edge device) although the converse is not yet guaranteed server or edge device) although the converse is not yet guaranteed
until ubiquitous deployment of this functionality occurs. Note until ubiquitous deployment of this functionality occurs. Note
that the presence of intermediate routers that are not coupled with that the presence of intermediate routers that are not coupled with
an NHS entity may preclude the use of NHRP when source and an NHS entity may preclude the use of NHRP when source and
destination stations on different sides of such routers and thus destination stations on different sides of such routers and thus
such routers may partition NHRP reachability within an NBMA such routers may partition NHRP reachability within an NBMA
network. network.
The term "client", unless explicitly stated to the contrary, refers The term "client", unless explicitly stated to the contrary, refers
to an Next Hop Resolution Protocol client (NHC). An NHC is an to a Next Hop Resolution Protocol client (NHC). An NHC is an
entity which initiates NHRP requests of various types in order to entity which initiates NHRP requests of various types in order to
obtain access to the NHRP service. obtain access to the NHRP service.
The term "station" generally refers to a host or router which The term "station" generally refers to a host or router which
contains an NHRP entity. Occasionally, the term station will contains an NHRP entity. Occasionally, the term station will
describe a "user" of the NHRP client or service functionality; the describe a "user" of the NHRP client or service functionality; the
difference in usage is largely semantic. difference in usage is largely semantic.
2.2 Protocol Overview 2.2 Protocol Overview
skipping to change at page 5, line 32 skipping to change at page 5, line 38
be constructed from information obtained from NHRP Register packets be constructed from information obtained from NHRP Register packets
(see Section 5.2.3 and 5.2.4), from NHRP Resolution Request/Reply (see Section 5.2.3 and 5.2.4), from NHRP Resolution Request/Reply
packets, or through mechanisms outside the scope of this document packets, or through mechanisms outside the scope of this document
(examples of such mechanisms might include ARP[3] and pre-configured (examples of such mechanisms might include ARP[3] and pre-configured
tables). Section 6.2 further describes cache management issues. tables). Section 6.2 further describes cache management issues.
For a station within a given LIS to avoid providing NHS For a station within a given LIS to avoid providing NHS
functionality, there must be one or more NHSs within the NBMA functionality, there must be one or more NHSs within the NBMA
subnetwork which are providing authoritative address resolution subnetwork which are providing authoritative address resolution
information on its behalf. Such an NHS is said to be "serving" the information on its behalf. Such an NHS is said to be "serving" the
station. A stations on a LIS that lacks NHS functionality and is a station. A station on a LIS that lacks NHS functionality and is a
client of the NHRP service is known as NHRP Client or just NHCs. If client of the NHRP service is known as NHRP Client or just NHCs. If
a serving NHS is to be able to supply the address resolution a serving NHS is to be able to supply the address resolution
information for an NHC then NHSs must exist at each hop along all information for an NHC then NHSs must exist at each hop along all
routed paths between the NHC making the resolution request and the routed paths between the NHC making the resolution request and the
destination NHC. The last NHRP entity along the routed path is the destination NHC. The last NHRP entity along the routed path is the
serving NHS; that is, NHRP Resolution Requests are not forwarded to serving NHS; that is, NHRP Resolution Requests are not forwarded to
destination NHCs but rather are processed by the serving NHS. destination NHCs but rather are processed by the serving NHS.
An NHC also maintains a cache of protocol address to NBMA address An NHC also maintains a cache of protocol address to NBMA address
resolution information. This cache is populated through information resolution information. This cache is populated through information
skipping to change at page 9, line 27 skipping to change at page 9, line 34
The NHS serving a particular destination must lie along the routed The NHS serving a particular destination must lie along the routed
path to that destination. In practice, this means that all egress path to that destination. In practice, this means that all egress
routers must double as NHSs serving the destinations beyond them, and routers must double as NHSs serving the destinations beyond them, and
that hosts on the NBMA subnetwork are served by routers that double that hosts on the NBMA subnetwork are served by routers that double
as NHSs. Also, this implies that forwarding of NHRP packets within as NHSs. Also, this implies that forwarding of NHRP packets within
an NBMA subnetwork requires a contiguous deployment of NHRP capable an NBMA subnetwork requires a contiguous deployment of NHRP capable
routers. It is important that, in a given LIS/LAG which is using routers. It is important that, in a given LIS/LAG which is using
NHRP, all NHSs within the LIS/LAG have at least some portion of their NHRP, all NHSs within the LIS/LAG have at least some portion of their
resolution databases synchronized so that a packet arriving at one resolution databases synchronized so that a packet arriving at one
router/NHS in a given LIS/LAG will be forwarded in the same fashion router/NHS in a given LIS/LAG will be forwarded in the same fashion
as packet arriving at a different router/NHS for the given LIS/LAG. as a packet arriving at a different router/NHS for the given LIS/LAG.
One method, among others, is to use the Server Cache Synchronization One method, among others, is to use the Server Cache Synchronization
Protocol (SCSP) [12]. It is RECOMMENDED that SCSP be the method used Protocol (SCSP) [12]. It is RECOMMENDED that SCSP be the method used
when a LIS/LAG contains two or more router/NHSs. when a LIS/LAG contains two or more router/NHSs.
During migration to NHRP, it cannot be expected that all routers During migration to NHRP, it cannot be expected that all routers
within the NBMA subnetwork are NHRP capable. Thus, NHRP traffic within the NBMA subnetwork are NHRP capable. Thus, NHRP traffic
which would otherwise need to be forwarded through such routers can which would otherwise need to be forwarded through such routers can
be expected to be dropped due to the NHRP packet not being be expected to be dropped due to the NHRP packet not being
recognized. In this case, NHRP will be unable to establish any recognized. In this case, NHRP will be unable to establish any
transit paths whose discovery requires the traversal of the non-NHRP transit paths whose discovery requires the traversal of the non-NHRP
skipping to change at page 11, line 48 skipping to change at page 11, line 50
type. The Extensions Part also varies depending on packet type, and type. The Extensions Part also varies depending on packet type, and
need not be present. need not be present.
The length of the Fixed Part is fixed at 20 octets. The length of The length of the Fixed Part is fixed at 20 octets. The length of
the Mandatory Part is determined by the contents of the extensions the Mandatory Part is determined by the contents of the extensions
offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part
length is equal to total packet length (ar$pktsz) minus 20 otherwise length is equal to total packet length (ar$pktsz) minus 20 otherwise
the mandatory part length is equal to ar$extoff minus 20. The length the mandatory part length is equal to ar$extoff minus 20. The length
of the Extensions Part is implied by ar$pktsz minus ar$extoff. NHSs of the Extensions Part is implied by ar$pktsz minus ar$extoff. NHSs
may increase the size of an NHRP packet as a result of extension may increase the size of an NHRP packet as a result of extension
processing, but not beyond the offered maximum SDU size of the NBMA processing, but not beyond the offered maximum packet size of the
network. NBMA network.
NHRP packets are actually members of a wider class of address mapping NHRP packets are actually members of a wider class of address mapping
and management protocols being developed by the IETF. A specific and management protocols being developed by the IETF. A specific
encapsulation, based on the native formats used on the particular encapsulation, based on the native formats used on the particular
NBMA network over which NHRP is carried, indicates the generic IETF NBMA network over which NHRP is carried, indicates the generic IETF
mapping and management protocol. For example, SMDS networks always mapping and management protocol. For example, SMDS networks always
use LLC/SNAP encapsulation at the NBMA layer [4], and an NHRP packet use LLC/SNAP encapsulation at the NBMA layer [4], and an NHRP packet
is preceded by the following LLC/SNAP encapsulation: is preceded by the following LLC/SNAP encapsulation:
[0xAA-AA-03] [0x00-00-5E] [0x00-03] [0xAA-AA-03] [0x00-00-5E] [0x00-03]
skipping to change at page 14, line 38 skipping to change at page 14, line 38
indication is never sent as a result of receiving an error indication is never sent as a result of receiving an error
indication. When a responding NHS replies to an NHRP request, that indication. When a responding NHS replies to an NHRP request, that
NHS places a value in ar$hopcnt as if it were sending a request of NHS places a value in ar$hopcnt as if it were sending a request of
its own. its own.
ar$pktsz ar$pktsz
The total length of the NHRP packet, in octets (excluding link The total length of the NHRP packet, in octets (excluding link
layer encapsulation). layer encapsulation).
ar$chksum ar$chksum
The standard IP checksum over the entire NHRP packet (starting with The standard IP checksum over the entire SCSP packet starting at
the fixed header). If only the hop count field is changed, the the fixed header. If the packet is an odd number of bytes in
checksum is adjusted without full recomputation. The checksum is length then this calculation is performed as if a byte set to 0x00
completely recomputed when other header fields are changed. is appended to the end of the packet.
ar$extoff ar$extoff
This field identifies the existence and location of NHRP This field identifies the existence and location of NHRP
extensions. If this field is 0 then no extensions exist otherwise extensions. If this field is 0 then no extensions exist otherwise
this field represents the offset from the beginning of the NHRP this field represents the offset from the beginning of the NHRP
packet (i.e., starting from the ar$afn field) of the first packet (i.e., starting from the ar$afn field) of the first
extension. extension.
ar$op.version ar$op.version
This field indicates what version of generic address mapping and This field indicates what version of generic address mapping and
skipping to change at page 15, line 18 skipping to change at page 15, line 18
0x02 - 0xEF Reserved for future use by the IETF. 0x02 - 0xEF Reserved for future use by the IETF.
0xF0 - 0xFE Allocated for use by the ATM Forum. 0xF0 - 0xFE Allocated for use by the ATM Forum.
0xFF Experimental/Local use. 0xFF Experimental/Local use.
ar$op.type ar$op.type
When ar$op.version == 1, this is the NHRP packet type: NHRP When ar$op.version == 1, this is the NHRP packet type: NHRP
Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration
Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP
Purge Reply(6), or NHRP Error Indication(7). Use of NHRP packet Purge Reply(6), or NHRP Error Indication(7). Use of NHRP packet
Types in the range 128 to 255 are reserved for research or use in Types in the range 128 to 255 are reserved for research or use in
other protocol development and will be administered by IANA. other protocol development and will be administered by IANA (see
Section 9).
ar$shtl ar$shtl
Type & length of source NBMA address interpreted in the context of Type & length of source NBMA address interpreted in the context of
the 'address family number'[6] indicated by ar$afn. See below for the 'address family number'[6] indicated by ar$afn. See below for
more details. more details.
ar$sstl ar$sstl
Type & length of source NBMA subaddress interpreted in the context Type & length of source NBMA subaddress interpreted in the context
of the 'address family number'[6] indicated by ar$afn. When an of the 'address family number'[6] indicated by ar$afn. When an
NBMA technology has no concept of a subaddress, the subaddress NBMA technology has no concept of a subaddress, the subaddress
skipping to change at page 18, line 16 skipping to change at page 18, line 18
information in the received "reply" against that found in its information in the received "reply" against that found in its
outstanding "request" list. When a match is found then the outstanding "request" list. When a match is found then the
"request" is considered to be acknowledged. "request" is considered to be acknowledged.
The value is taken from a 32 bit counter that is incremented each The value is taken from a 32 bit counter that is incremented each
time a new "request" is transmitted. The same value MUST be used time a new "request" is transmitted. The same value MUST be used
when resending a "request", i.e., when a "reply" has not been when resending a "request", i.e., when a "reply" has not been
received for a "request" and a retry is sent after an appropriate received for a "request" and a retry is sent after an appropriate
interval. interval.
It is RECOMMENDED that the initial value for this number be 0. A
node MAY reuse a sequence number if and only if the reuse of the
sequence number is not precluded by use of a particular method of
synchronization (e.g., as described in Appendix A).
The NBMA address/subaddress form specified below allows combined The NBMA address/subaddress form specified below allows combined
E.164/NSAPA form of NBMA addressing. For NBMA technologies without a E.164/NSAPA form of NBMA addressing. For NBMA technologies without a
subaddress concept, the subaddress field is always ZERO length and subaddress concept, the subaddress field is always ZERO length and
ar$sstl = 0. ar$sstl = 0.
Source NBMA Address Source NBMA Address
The Source NBMA address field is the address of the source station The Source NBMA address field is the address of the source station
which is sending the "request". If the field's length as specified which is sending the "request". If the field's length as specified
in ar$shtl is 0 then no storage is allocated for this address at in ar$shtl is 0 then no storage is allocated for this address at
all. all.
skipping to change at page 22, line 9 skipping to change at page 22, line 16
In the case of NHRP Resolution Request/Reply, the Prefix Length In the case of NHRP Resolution Request/Reply, the Prefix Length
specifies the equivalence class of addresses which match the specifies the equivalence class of addresses which match the
first "Prefix Length" bit positions of the Destination Protocol first "Prefix Length" bit positions of the Destination Protocol
Address. If the "U" bit is set in the common header then this Address. If the "U" bit is set in the common header then this
field MUST be set to 0xFF. field MUST be set to 0xFF.
Maximum Transmission Unit Maximum Transmission Unit
This field gives the maximum transmission unit for the source This field gives the maximum transmission unit for the source
station. A possible use of this field in the NHRP Resolution station. A possible use of this field in the NHRP Resolution
Request packet is for the NHRP Resolution Requester to ask for a Request packet is for the NHRP Resolution Requester to ask for a
target MTU. In lieu of that usage, the CIE must be omitted. target MTU.
Holding Time Holding Time
The Holding Time specified in the one CIE permitted to be The Holding Time specified in the one CIE permitted to be
included in an NHRP Resolution Request is the amount of time included in an NHRP Resolution Request is the amount of time
which the source address binding information in the NHRP which the source address binding information in the NHRP
Resolution Request is permitted to cached by transit and Resolution Request is permitted to cached by transit and
responding NHSs. Note that this field may only have a non-zero responding NHSs. Note that this field may only have a non-zero
value if the S bit is set. value if the S bit is set.
All other fields in the CIE MUST be ignored and SHOULD be set to 0. All other fields in the CIE MUST be ignored and SHOULD be set to 0.
skipping to change at page 23, line 43 skipping to change at page 23, line 50
address in a CIE identifies the destination (though it may be address in a CIE identifies the destination (though it may be
different in value than the Destination address if the different in value than the Destination address if the
destination system has multiple addresses) or if the destination destination system has multiple addresses) or if the destination
is not connected directly to the NBMA subnetwork but the egress is not connected directly to the NBMA subnetwork but the egress
router to that destination is guaranteed to be stable (such as router to that destination is guaranteed to be stable (such as
when the destination is immediately adjacent to the egress router when the destination is immediately adjacent to the egress router
through a non-NBMA interface). through a non-NBMA interface).
U U
This is the Uniqueness bit. See the NHRP Resolution Request This is the Uniqueness bit. See the NHRP Resolution Request
section above for details. When this bit is set only, only one section above for details. When this bit is set, only one CIE is
CIE is included since only one unique binding should exist in an included since only one unique binding should exist in an NHS's
NHS's cache. cache.
S S
Copied from NHRP Resolution Request message. Copied from NHRP Resolution Request message.
One or more CIEs are specified in the NHRP Resolution Reply. Each CIE One or more CIEs are specified in the NHRP Resolution Reply. Each CIE
contains NHRP next hop information which the responding NHS has contains NHRP next hop information which the responding NHS has
cached and which matches the parameters specified in the NHRP cached and which matches the parameters specified in the NHRP
Resolution Request. If no match is found by the NHS issuing the NHRP Resolution Request. If no match is found by the NHS issuing the NHRP
Resolution Reply then a single CIE is enclosed with the a CIE Code Resolution Reply then a single CIE is enclosed with the a CIE Code
set appropriately (see below) and all other fields MUST be ignored set appropriately (see below) and all other fields MUST be ignored
skipping to change at page 28, line 24 skipping to change at page 28, line 28
station MUST re-send the NHRP Registration Request packet often station MUST re-send the NHRP Registration Request packet often
enough to refresh the registration, even in the face of occasional enough to refresh the registration, even in the face of occasional
packet loss. It is recommended that the NHRP Registration Request packet loss. It is recommended that the NHRP Registration Request
packet be sent at an interval equal to one-third of the Holding Time packet be sent at an interval equal to one-third of the Holding Time
specified therein. specified therein.
5.2.4 NHRP Registration Reply 5.2.4 NHRP Registration Reply
The NHRP Registration Reply is sent by an NHS to a client in response The NHRP Registration Reply is sent by an NHS to a client in response
to that client's NHRP Registration Request. If the Code field of a to that client's NHRP Registration Request. If the Code field of a
CIE in the NHRP Registration Reply has anything other than 0 zero in CIE in the NHRP Registration Reply has anything other than zero in it
it then the NHRP Registration Reply is a NAK otherwise the reply is then the NHRP Registration Reply is a NAK otherwise the reply is an
an ACK. The NHRP Registration Reply has a Type code of 4. ACK. The NHRP Registration Reply has a Type code of 4.
An NHRP Registration Reply is formed from an NHRP Registration An NHRP Registration Reply is formed from an NHRP Registration
Request by changing the type code to 4, updating the CIE Code field, Request by changing the type code to 4, updating the CIE Code field,
and filling in the appropriate extensions if they exist. The message and filling in the appropriate extensions if they exist. The message
specific meanings of the fields are as follows: specific meanings of the fields are as follows:
Attempts to register the information in the CIEs of an NHRP Attempts to register the information in the CIEs of an NHRP
Registration Request may fail for various reasons. If this is the Registration Request may fail for various reasons. If this is the
case then each failed attempt to register the information in a CIE of case then each failed attempt to register the information in a CIE of
an NHRP Registration Request is logged in the associated NHRP an NHRP Registration Request is logged in the associated NHRP
skipping to change at page 33, line 48 skipping to change at page 34, line 4
Resolution Request which it believes it did not make then an Resolution Request which it believes it did not make then an
error packet is sent to the station making the reply with an error packet is sent to the station making the reply with an
error code of Invalid Reply Received. error code of Invalid Reply Received.
11 - Authentication Failure 11 - Authentication Failure
If a received packet fails an authentication test then this If a received packet fails an authentication test then this
error is returned. error is returned.
15 - Hop Count Exceeded 15 - Hop Count Exceeded
The hop count which was specified in the Fixed Header of an The hop count which was specified in the Fixed Header of an
NHRP message has been exceeded. NHRP message has been exceeded.
Error Offset Error Offset
The offset in octets into the NHRP packet, starting at the NHRP The offset in octets into the original NHRP packet in which an
Fixed Header, at which the error was detected. error was detected. This offset is calculated starting from the
NHRP Fixed Header.
Source NBMA Address Source NBMA Address
The Source NBMA address field is the address of the station which The Source NBMA address field is the address of the station which
observed the error. observed the error.
Source NBMA SubAddress Source NBMA SubAddress
The Source NBMA subaddress field is the address of the station The Source NBMA subaddress field is the address of the station
which observed the error. If the field's length as specified in which observed the error. If the field's length as specified in
ar$sstl is 0 then no storage is allocated for this address at all. ar$sstl is 0 then no storage is allocated for this address at all.
skipping to change at page 35, line 34 skipping to change at page 35, line 34
qualified by the Compulsory bit, but is orthogonal to it. qualified by the Compulsory bit, but is orthogonal to it.
Length Length
The length in octets of the value (not including the Type and The length in octets of the value (not including the Type and
Length fields; a null extension will have only an extension header Length fields; a null extension will have only an extension header
and a length of zero). and a length of zero).
When extensions exist, the extensions list is terminated by the Null When extensions exist, the extensions list is terminated by the Null
TLV, having Type = 0 and Length = 0. TLV, having Type = 0 and Length = 0.
Extensions may occur in any order (see Section 5.3.4 for the Extensions may occur in any order, but any particular extension type
exception), but any particular extension type may occur only once in may occur only once in an NHRP packet unless explicitly stated to the
an NHRP packet with the exception of the Vendor Private extension. contrary in the extensions definition. For example, the vendor-
The vendor-private extension may occur multiple times in a packet in private extension may occur multiple times in a packet in order to
order to allow for extensions which do not share the same vendor ID allow for extensions which do not share the same vendor ID to be
to be represented. It is RECOMMENDED that a given vendor include no represented. It is RECOMMENDED that a given vendor include no more
more than one Vendor Private Extension. than one Vendor Private Extension.
An NHS MUST NOT change the order of extensions. That is, the order An NHS MUST NOT change the order of extensions. That is, the order
of extensions placed in an NHRP packet by an NHC (or by an NHS when of extensions placed in an NHRP packet by an NHC (or by an NHS when
an NHS sources a packet) MUST be preserved as the packet moves an NHS sources a packet) MUST be preserved as the packet moves
between NHSs. Minimal NHC implementations MUST only recognize, but between NHSs. Minimal NHC implementations MUST only recognize, but
not necessarily parse, the Vendor Private extension and the End Of not necessarily parse, the Vendor Private extension and the End Of
Extensions extension. Extensions are only present in a "reply" if Extensions extension. Extensions are only present in a "reply" if
they were present in the corresponding "request" with the exception they were present in the corresponding "request" with the exception
of Vendor Private extensions. The previous statement is not intended of Vendor Private extensions. The previous statement is not intended
to preclude the creation of NHS-only extensions which might be added to preclude the creation of NHS-only extensions which might be added
to and removed from NHRP packets by the same NHS; such extensions to and removed from NHRP packets by the same NHS; such extensions
MUST not be propagated to NHCs. MUST not be propagated to NHCs.
The Compulsory bit provides for a means to add to the extension set. The Compulsory bit provides for a means to add to the extension set.
If the bit is set, the NHRP message cannot be properly processed by If the bit is set in an extension then the station responding to the
the station responding to the message (e.g., the station that would NHRP message which contains that extension MUST be able to understand
issue a NHRP Resolution Reply in response to a NHRP Resolution the extension (in this case, the station responding to the message is
Request) without processing the extension. As a result, the the station that would issue an NHRP reply in response to a NHRP
responder MUST return an NHRP Error Indication of type Unrecognized request). As a result, the responder MUST return an NHRP Error
Extension. If the Compulsory bit is clear then the extension can be Indication of type Unrecognized Extension. If the Compulsory bit is
safely ignored; however, if an ignored extension is in a "request" clear then the extension can be safely ignored; however, if an
then it MUST be returned, unchanged, in the corresponding "reply" ignored extension is in a "request" then it MUST be returned,
packet type. unchanged, in the corresponding "reply" packet type.
If a transit NHS (one which is not going to generate a "reply") If a transit NHS (one which is not going to generate a "reply")
detects an unrecognized extension, it SHALL ignore the extension. If detects an unrecognized extension, it SHALL ignore the extension. If
the Compulsory bit is set, the transit NHS MUST NOT cache the the Compulsory bit is set, the transit NHS MUST NOT cache the
information contained in the packet and MUST NOT identify itself as information contained in the packet and MUST NOT identify itself as
an egress router (in the Forward Record or Reverse Record an egress router (in the Forward Record or Reverse Record
extensions). Effectively, this means, if a transit NHS encounters an extensions). Effectively, this means, if a transit NHS encounters an
extension which it cannot process and which has the Compulsory bit extension which it cannot process and which has the Compulsory bit
set then that NHS MUST NOT participate in any way in the protocol set then that NHS MUST NOT participate in any way in the protocol
exchange other than acting as a forwarding agent. exchange other than acting as a forwarding agent.
The NHRP extension Type space is subdivided to encourage use outside The NHRP extension Type space is subdivided to encourage use outside
the IETF. the IETF.
0x0000 - 0x0FFF Reserved for NHRP. 0x0000 - 0x0FFF Reserved for NHRP.
0x1000 - 0x11FF Allocated to the ATM Forum. 0x1000 - 0x11FF Allocated to the ATM Forum.
0x1200 - 0x37FF Reserved for the IETF. 0x1200 - 0x37FF Reserved for the IETF.
0x3800 - 0x3FFF Experimental use. 0x3800 - 0x3FFF Experimental use.
IANA will administer the ranges reserved for the IETF. Values in the IANA will administer the ranges reserved for the IETF (see Section
'Experimental use' range have only local sigificance. 9). Values in the 'Experimental use' range have only local
significance.
5.3.0 The End Of Extensions 5.3.0 The End Of Extensions
Compulsory = 1 Compulsory = 1
Type = 0 Type = 0
Length = 0 Length = 0
When extensions exist, the extensions list is terminated by the End When extensions exist, the extensions list is terminated by the End
Of Extensions/Null TLV. Of Extensions/Null TLV.
skipping to change at page 38, line 33 skipping to change at page 38, line 34
5.3.2 NHRP Forward Transit NHS Record Extension 5.3.2 NHRP Forward Transit NHS Record Extension
Compulsory = 1 Compulsory = 1
Type = 4 Type = 4
Length = variable Length = variable
The NHRP Forward Transit NHS record contains a list of transit NHSs The NHRP Forward Transit NHS record contains a list of transit NHSs
through which a "request" has traversed. Each NHS SHALL append to through which a "request" has traversed. Each NHS SHALL append to
the extension a Forward Transit NHS element (as specified below) the extension a Forward Transit NHS element (as specified below)
containing its Protocol address The extension length field and the containing its Protocol address. The extension length field and the
ar$chksum fields SHALL be adjusted appropriately. ar$chksum fields SHALL be adjusted appropriately.
The responding NHS, as described in Section 5.3.1, SHALL NOT update The responding NHS, as described in Section 5.3.1, SHALL NOT update
this extension. this extension.
In addition, NHSs that are willing to act as egress routers for In addition, NHSs that are willing to act as egress routers for
packets from the source to the destination SHALL include information packets from the source to the destination SHALL include information
about their NBMA Address. about their NBMA Address.
This extension uses a single CIE with the extension specific meanings This extension uses a single CIE per NHS Record element with the
of the fields set as follows: extension specific meanings of the fields set as follows:
The Prefix Length fields MUST be set to 0 and ignored. The Prefix Length fields MUST be set to 0 and ignored.
CIE Code CIE Code
5 - Insufficient Resources 5 - Insufficient Resources
If an NHRP Resolution Request contains an NHRP Forward Transit If an NHRP Resolution Request contains an NHRP Forward Transit
NHS Record Extension and insufficient resources to setup a cut- NHS Record Extension and insufficient resources to setup a cut-
through VC exist at the current transit NHS then the CIE Code through VC exist at the current transit NHS then the CIE Code
field for NHRP Forward Transit NHS Record Extension is set to 5 field for NHRP Forward Transit NHS Record Extension is set to 5
in order to tell the client that a VC setup attempt would in all in order to tell the client that a VC setup attempt would in all
skipping to change at page 40, line 17 skipping to change at page 40, line 19
Protocol address to this extension. The extension length field and Protocol address to this extension. The extension length field and
ar$chksum SHALL be adjusted appropriately. ar$chksum SHALL be adjusted appropriately.
The responding NHS, as described in Section 5.3.1, SHALL NOT update The responding NHS, as described in Section 5.3.1, SHALL NOT update
this extension. this extension.
In addition, NHSs that are willing to act as egress routers for In addition, NHSs that are willing to act as egress routers for
packets from the source to the destination SHALL include information packets from the source to the destination SHALL include information
about their NBMA Address. about their NBMA Address.
This extension uses a single CIE with the extension specific meanings This extension uses a single CIE per NHS Record element with the
of the fields set as follows: extension specific meanings of the fields set as follows:
The CIE Code and Prefix Length fields MUST be set to 0 and ignored. The CIE Code and Prefix Length fields MUST be set to 0 and ignored.
Maximum Transmission Unit Maximum Transmission Unit
This field gives the maximum transmission unit preferred by the This field gives the maximum transmission unit preferred by the
transit NHS. If this value is 0 then either the default MTU is transit NHS. If this value is 0 then either the default MTU is
used or the MTU negotiated via signaling is used if such used or the MTU negotiated via signaling is used if such
negotiation is possible for the given NBMA. negotiation is possible for the given NBMA.
Holding Time Holding Time
skipping to change at page 41, line 12 skipping to change at page 41, line 15
If a "reply" that is being forwarded by an NHS contains the Protocol If a "reply" that is being forwarded by an NHS contains the Protocol
Address of that NHS in one of the Reverse Transit NHS elements then Address of that NHS in one of the Reverse Transit NHS elements then
the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop
Detected" and discard the "reply". Detected" and discard the "reply".
Note that this information may be cached at intermediate NHSs; if Note that this information may be cached at intermediate NHSs; if
so, the cached value SHALL be used when generating a reply. so, the cached value SHALL be used when generating a reply.
5.3.4 NHRP Authentication Extension 5.3.4 NHRP Authentication Extension
Compulsory = 1 Compulsory = 1 Type = 7 Length = variable
Type = 7
Length = variable
The NHRP Authentication Extension is carried in NHRP packets to The NHRP Authentication Extension is carried in NHRP packets to
convey authentication information between NHRP speakers. The convey authentication information between NHRP speakers. The
Authentication Extension may be included in any NHRP "request" or Authentication Extension may be included in any NHRP "request" or
"reply" only. "reply" only.
Except in the case of an NHRP Registration Request/Reply The authentication is always done pairwise on an NHRP hop-by-hop
Authentication is done pairwise on an NHRP hop-by-hop basis; i.e., basis; i.e., the authentication extension is regenerated at each
the authentication extension is regenerated at each hop. In the case hop. If a received packet fails the authentication test, the station
of an NHRP Registration Request/Reply, the Authentication is checked SHALL generate an Error Indication of type "Authentication Failure"
on an end-to-end basis rather than hop-by-hop. If a received packet and discard the packet. Note that one possible authentication failure
fails the authentication test, the station SHALL generate an Error is the lack of an Authentication Extension; the presence or absence
Indication of type "Authentication Failure" and discard the packet. of the Authentication Extension is a local matter.
Note that one possible authentication failure is the lack of an
Authentication Extension; the presence or absence of the 5.3.4.1 Header Format
Authentication Extension is a local matter.
The authentication header has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Type | | Reserved | Security Parameter Index (SPI)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Authentication Type field identifies the authentication method in Security Parameter Index (SPI) can be thought of as an index into a
use. Currently assigned values are: table that maintains the keys and other information such as hash
algorithm. Src and Dst communicate either offline using manual keying
or online using a key management protocol to populate this table. The
sending NHRP entity always allocates the SPI and the parameters
associated with it.
1 - Cleartext Password Src Addr a variable length field is the address assigned to the
2 - Keyed MD5 outgoing interface. The length of the addr is obtained from the
source protocol length field in the mandatory part of the NHRP
header. The tuple <spi, src addr> uniquely identifies the key and
other parameters that are used in authentication.
All other values are reserved. The length of the authentication data field is dependent on the hash
algorithm used. The data field contains the keyed hash calculated
over the entire NHRP payload. The authentication data field is zeroed
out before the hash is calculated.
The Authentication Data field contains the type-specific 5.3.4.2 SPI and Security Parameters Negotiation
authentication information.
In the case of Cleartext Password Authentication, the Authentication SPI's can be negotiated either manually or using an Internet Key
Data consists of a variable length password. Management protocol. Manual keying MUST be supported. The following
parameters are associated with the tuple <SPI, src>- lifetime,
Algorithm, Key. Lifetime indicates the duration in seconds for which
the key is valid. In case of manual keying, this duration can be
infinite. Also, in order to better support manual keying, there may
be multiple tuples active at the same time (Dst being the same).
In the case of Keyed MD5 Authentication, the Authentication Data Algorithm specifies the hash algorithm agreed upon by the two
contains the 16 byte MD5 digest of the entire NHRP packet, including entities. HMAC-MD5-128 [16] is the default algorithm. Other
the encapsulated protocol's header, with the authentication key algorithms MAY be supported by defining new values. IANA will assign
appended to the end of the packet. The authentication key is not the numbers to identify the algorithm being used (see Section 9).
transmitted with the packet. The MD5 digest covers only the
following fields of the NHRP packet: fixed part (with hop count,
packet size and checksum being set to zero), mandatory part,
Responder Address extension, and authentication extension. Note that
when MD5 is used, there is an explicit ordering of the extensions
such that: if the Responder Address extension exists then it MUST be
the first extension in the packet and the Authentication Extension
MUST be the second extension otherwise the Authentication Extension
MUST be the first extension in the packet.
Distribution of authentication keys is outside the scope of this Any Internet standard key management protocol MAY so be used to
document. negotiate the SPI and parameters.
5.3.4.3 Message Processing
At the time of adding the authentication extension header, src looks
up in a table to fetch the SPI and the security parameters based on
the outgoing interface address. If there are no entries in the table
and if there is support for key management, the src initiates the key
management protocol to fetch the necessary parameters. The src
constructs the Authentication Extension payload and calculates the
hash by zeroing authentication data field. The result replaces in the
zeroed authentication data field. The src address field in the
payload is the IP address assigned to the outgoing interface.
If key management is not supported and authentication is mandatory,
the packet is dropped and this information is logged.
On the receiving end, dst fetches the parameters based on the SPI and
the ip address in the authentication extension payload. The
authentication data field is extracted before zeroing out to
calculate the hash. It computes the hash on the entire payload and if
the hash does not match, then an "abnormal event" has occurred.
5.3.4.4 Security Considerations
It is important that the keys chosen are strong as the security of
the entire system depends on the keys being chosen properly and the
correct implementation of the algorithms.
The security is performed on a hop by hop basis. The data received
can be trusted only so much as one trusts all the entities in the
path traversed.
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 page 43, line 7 skipping to change at page 43, line 47
Data Data
The remaining octets after the Vendor ID in the payload are The remaining octets after the Vendor ID in the payload are
vendor-dependent data. vendor-dependent data.
This extension may be added to any "request" or "reply" packet and it This extension may be added to any "request" or "reply" packet and it
is the only extension that may be included multiple times. If the is the only extension that may be included multiple times. If the
receiver does not handle this extension, or does not match the Vendor receiver does not handle this extension, or does not match the Vendor
ID in the extension then the extension may be completely ignored by ID in the extension then the extension may be completely ignored by
the receiver. If a Vendor Private Extension is included in a the receiver. If a Vendor Private Extension is included in a
"request" then is must be copied in the corresponding "reply". "request" then it must be copied to the corresponding "reply".
6. Protocol Operation 6. Protocol Operation
In this section, we discuss certain operational considerations of In this section, we discuss certain operational considerations of
NHRP. NHRP.
6.1 Router-to-Router Operation 6.1 Router-to-Router Operation
In practice, the initiating and responding stations may be either In practice, the initiating and responding stations may be either
hosts or routers. However, there is a possibility under certain hosts or routers. However, there is a possibility under certain
skipping to change at page 47, line 15 skipping to change at page 48, line 15
7. NHRP over Legacy BMA Networks 7. NHRP over Legacy BMA Networks
There would appear to be no significant impediment to running NHRP There would appear to be no significant impediment to running NHRP
over legacy broadcast subnetworks. There may be issues around over legacy broadcast subnetworks. There may be issues around
running NHRP across multiple subnetworks. Running NHRP on broadcast running NHRP across multiple subnetworks. Running NHRP on broadcast
media has some interesting possibilities; especially when setting up media has some interesting possibilities; especially when setting up
a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both
end stations are legacy attached. This use for NHRP requires further end stations are legacy attached. This use for NHRP requires further
research. research.
8. Security Considerations 8. Discussion
As in any resolution protocol, there are a number of potential
security attacks possible. Plausible examples include denial-of-
service attacks, and masquerade attacks using register and purge
packets. The use of authentication on all packets is recommended to
avoid such attacks.
The authentication schemes described in this document are intended to
allow the receiver of a packet to validate the identity of the
sender; they do not provide privacy or protection against replay
attacks.
Detailed security analysis of this protocol is for further study.
9. Discussion
The result of an NHRP Resolution Request depends on how routing is The result of an NHRP Resolution Request depends on how routing is
configured among the NHSs of an NBMA subnetwork. If the destination configured among the NHSs of an NBMA subnetwork. If the destination
station is directly connected to the NBMA subnetwork and the the station is directly connected to the NBMA subnetwork and the routed
routed path to it lies entirely within the NBMA subnetwork, the NHRP path to it lies entirely within the NBMA subnetwork, the NHRP
Resolution Replies always return the NBMA address of the destination Resolution Replies always return the NBMA address of the destination
station itself rather than the NBMA address of some egress router. station itself rather than the NBMA address of some egress router.
On the other hand, if the routed path exits the NBMA subnetwork, NHRP On the other hand, if the routed path exits the NBMA subnetwork, NHRP
will be unable to resolve the NBMA address of the destination, but will be unable to resolve the NBMA address of the destination, but
rather will return the address of the egress router. For rather will return the address of the egress router. For
destinations outside the NBMA subnetwork, egress routers and routers destinations outside the NBMA subnetwork, egress routers and routers
in the other subnetworks should exchange routing information so that in the other subnetworks should exchange routing information so that
the optimal egress router may be found. the optimal egress router may be found.
In addition to NHSs, an NBMA station could also be associated with In addition to NHSs, an NBMA station could also be associated with
one or more regular routers that could act as "connectionless one or more regular routers that could act as "connectionless
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
IANA will redirect requests for numbers in the various number spaces
described herein to the working group chairs. Currently, these
chairs are Andy Malis (malis@ascend.com) and George Swallow
(swallow@cisco.com). The working group chair(s) will accept any and
all requests for value assignment as long as the client/server
protocol specific document exists (i.e., the protocol specific
document has been published as an internet draft or informational
RFC).
References References
[1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh
Govindan, RFC1735. Govindan, RFC1735.
[2] Address Resolution Protocol, David C. Plummer, RFC 826. [2] Address Resolution Protocol, David C. Plummer, RFC 826.
[3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577. [3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577.
[4] Transmission of IP datagrams over the SMDS service, J. Lawrence [4] Transmission of IP datagrams over the SMDS service, J. Lawrence
skipping to change at page 48, line 38 skipping to change at page 49, line 35
[8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode, [8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode,
A. Malis, D. Robinson, and R. Ullmann, RFC1356. A. Malis, D. Robinson, and R. Ullmann, RFC1356.
[9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and [9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and
A. Malis, RFC1490. A. Malis, RFC1490.
[10] "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks, [10] "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks,
Yakov Rekhter, Dilip Kandlur, RFC1937. Yakov Rekhter, Dilip Kandlur, RFC1937.
[11] Support for Multicast over UNI 3.0/3.1 based ATM Networks, [11] Support for Multicast over UNI 3.0/3.1 based ATM Networks,
G. Armitage, Work In Progress. G. Armitage, RFC2021
[12] Server Cache Synchronization Protocol (SCSP) - NBMA, [12] Server Cache Synchronization Protocol (SCSP) - NBMA,
J. Luciani, G. Armitage, J. Halpern, Work In Progress. J. Luciani, G. Armitage, J. Halpern, draft-ietf-ion-scsp-02.txt
[13] NHRP for Destinations off the NBMA Subnetwork, [13] NHRP for Destinations off the NBMA Subnetwork,
Y. Rekhter, Work In Progress. Y. Rekhter, Work In Progress.
[14] Classical IP to NHRP Transition, J. Luciani, et al., Work In Progress. [14] Classical IP to NHRP Transition, J. Luciani, et al., Work In Progress.
[15] Key words for use in RFCs to Indicate Requirement Levels, S. Bradner,
RFC 2119.
[16] "HMAC: Keyed Hashing for Message Authentication", Krawczyk, Bellare,
Canetti, RFC 2104.
Acknowledgments Acknowledgments
We would like to thank (in no particular order) Juha Heinenan of We would like to thank (in no particular order) Naganand Doraswami of
Bay Networks for the entirety of the security section, Thomas Narton
of IBM for his comments in the role of Internet AD, Juha Heinenan of
Telecom Finland and Ramesh Govidan of ISI for their work on NBMA ARP Telecom Finland and Ramesh Govidan of ISI for their work on NBMA ARP
and the 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.
 End of changes. 42 change blocks. 
109 lines changed or deleted 158 lines changed or added

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