Network Working Group J. Luciani
Request for Comments: 2332 Bay Networks
Category: Standards Track D. Katz
cisco Systems
D. Piscitello
Core Competence, Inc.
B. Cole
Juniper Networks
N. Doraswamy
Bay Networks
April 1998
Network Working Group J. Luciani
Request for Comments: 2332 Bay Networks
Category: Standards Track D. Katz
cisco Systems
D. Piscitello
Core Competence, Inc.
B. Cole
Juniper Networks
N. Doraswamy
Bay Networks
April 1998
NBMA Next Hop Resolution Protocol (NHRP)
NBMA下一跳解析协议（NHRP）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This document describes the NBMA Next Hop Resolution Protocol (NHRP). NHRP can be used by a source station (host or router) connected to a Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the internetworking layer address and NBMA subnetwork addresses of the "NBMA next hop" towards a destination station. If the destination is connected to the NBMA subnetwork, then 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 destination station. NHRP is intended for use in a multiprotocol internetworking layer environment over NBMA subnetworks.
本文件描述了NBMA下一跳解析协议（NHRP）。NHRP可由连接到非广播多址（NBMA）子网的源站（主机或路由器）使用，以确定朝向目的站的“NBMA下一跳”的网际层地址和NBMA子网地址。如果目的地连接到NBMA子网，则NBMA下一跳是目的地站本身。否则，NBMA下一跳是来自“最近”到目的站的NBMA子网的出口路由器。NHRP用于NBMA子网上的多协议互连层环境。
Note that while this protocol was developed for use with NBMA subnetworks, it is possible, if not likely, that it will be applied to BMA subnetworks as well. However, this usage of NHRP is for further study.
请注意，虽然该协议是为NBMA子网开发的，但如果不太可能，它也可能应用于BMA子网。然而，NHRP的使用有待进一步研究。
This document is intended to be a functional superset of the NBMA Address Resolution Protocol (NARP) documented in [1].
本文件旨在成为[1]中记录的NBMA地址解析协议（NARP）的功能超集。
Operation of NHRP as a means of establishing a transit path across an NBMA subnetwork between two routers will be addressed in a separate document (see [13]).
NHRP作为在两个路由器之间建立NBMA子网传输路径的一种方式的操作将在单独的文件中说明（见[13]）。
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].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可能和可选时，应按照[15]中的说明进行解释。
The NBMA Next Hop Resolution Protocol (NHRP) allows a source station (a host or router), wishing to communicate over a Non-Broadcast, Multi-Access (NBMA) subnetwork, to determine the internetworking layer addresses and NBMA addresses of suitable "NBMA next hops" toward a destination station. A subnetwork can be non-broadcast either because it technically doesn't support broadcasting (e.g., an X.25 subnetwork) or because broadcasting is not feasible for one reason or another (e.g., an SMDS multicast group or an extended Ethernet would be too large). If the destination is connected to the NBMA subnetwork, then 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 destination station.
NBMA下一跳解析协议（NHRP）允许希望通过非广播多址（NBMA）子网进行通信的源站（主机或路由器）确定朝向目的站的合适“NBMA下一跳”的网络间层地址和NBMA地址。子网可以是非广播的，因为它在技术上不支持广播（例如，X.25子网），或者因为某种原因（例如，SMDS多播组或扩展以太网太大）广播不可行。如果目的地连接到NBMA子网，则NBMA下一跳是目的地站本身。否则，NBMA下一跳是来自“最近”到目的站的NBMA子网的出口路由器。
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 the following properties:
建立NBMA网络模型的一种方法是使用逻辑独立的IP子网（LIS）概念。[3]和[4]中定义的LIS具有以下属性：
1) All members of a LIS have the same IP network/subnet number and address mask.
1) LIS的所有成员具有相同的IP网络/子网编号和地址掩码。
2) All members of a LIS are directly connected to the same NBMA subnetwork.
2) LIS的所有成员直接连接到同一NBMA子网络。
3) All hosts and routers outside of the LIS are accessed via a router.
3) LIS之外的所有主机和路由器都通过路由器访问。
4) All members of a LIS access each other directly (without routers).
4) LIS的所有成员直接相互访问（无路由器）。
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 the source station; otherwise, the source station must forward packets to a router that is a member of multiple LIS's. In multi-LIS
[3]和[4]中所述的地址解析仅在目的站是与源站相同的LIS的成员时解析下一跳地址；否则，源站必须将数据包转发到作为多个LIS成员的路由器。在多LIS中
configurations, hop-by-hop address resolution may not be sufficient to resolve the "NBMA next hop" toward the destination station, and IP packets may have multiple IP hops through the NBMA subnetwork.
在配置中，逐跳地址解析可能不足以解析朝向目的站的“NBMA下一跳”，并且IP分组可能具有通过NBMA子网的多个IP跳。
Another way to model NBMA is by using the notion of Local Address Groups (LAGs) [10]. The essential difference between the LIS and the LAG models is that while with the LIS model the outcome of the "local/remote" forwarding decision is driven purely by addressing information, with the LAG model the outcome of this decision is decoupled from the addressing information and is coupled with the Quality of Service and/or traffic characteristics. With the LAG model any two entities on a common NBMA network could establish a direct communication with each other, irrespective of the entities' addresses.
NBMA建模的另一种方法是使用本地地址组（LAG）的概念[10]。LIS和LAG模型之间的本质区别在于，在LIS模型中，“本地/远程”转发决策的结果完全由寻址信息驱动，利用滞后模型，该决策的结果与寻址信息解耦，并与服务质量和/或流量特征耦合。使用滞后模型，公共NBMA网络上的任何两个实体都可以彼此建立直接通信，而不考虑实体的地址。
Support for the LAG model assumes the existence of a mechanism that allows any entity (i.e., host or router) connected to an NBMA network to resolve an internetworking layer address to an NBMA address for any other entity connected to the same NBMA network. This resolution would take place regardless of the address assignments to these entities. Within the parameters described in this document, NHRP describes such a mechanism. For example, when the internetworking layer address is of type IP, once the NBMA next hop has been resolved, the source may either start sending IP packets to the destination (in a connectionless NBMA subnetwork such as SMDS) or may first establish a connection to the destination with the desired bandwidth (in a connection-oriented NBMA subnetwork such as ATM).
对滞后模型的支持假设存在一种机制，允许连接到NBMA网络的任何实体（即主机或路由器）将连接到同一NBMA网络的任何其他实体的网络间层地址解析为NBMA地址。无论这些实体的地址分配如何，该决议都会发生。在本文件中描述的参数范围内，NHRP描述了这种机制。例如，当网络间层地址是IP类型时，一旦NBMA下一跳被解析，源可以开始向目的地发送IP分组（在诸如smd的无连接NBMA子网中），或者可以首先使用所需带宽建立到目的地的连接（在面向连接的NBMA子网中，如ATM）。
Use of NHRP may be sufficient for hosts doing address resolution when those hosts are directly connected to an NBMA subnetwork, allowing for straightforward implementations in NBMA stations. NHRP also has the capability of determining the egress point from an NBMA subnetwork when the destination is not directly connected to the NBMA subnetwork and the identity of the egress router is not learned by other methods (such as routing protocols). Optional extensions to NHRP provide additional robustness and diagnosability.
当主机直接连接到NBMA子网时，NHRP的使用对于进行地址解析的主机来说可能就足够了，从而允许在NBMA站点中直接实现。当目的地未直接连接到NBMA子网且出口路由器的身份未通过其他方法（例如路由协议）学习时，NHRP还具有确定来自NBMA子网的出口点的能力。NHRP的可选扩展提供了额外的健壮性和可诊断性。
Address resolution techniques such as those described in [3] and [4] may be in use when NHRP is deployed. ARP servers and services over NBMA subnetworks may be required to support hosts that are not capable of dealing with any model for communication other than the LIS model, and deployed hosts may not implement NHRP but may continue to support ARP variants such as those described in [3] and [4]. NHRP is intended to reduce or eliminate the extra router hops required by the LIS model, and can be deployed in a non-interfering manner with existing ARP services [14].
当部署NHRP时，可以使用[3]和[4]中描述的地址解析技术。NBMA子网上的ARP服务器和服务可能需要支持不能处理除LIS模型以外的任何通信模型的主机，部署的主机可能不实现NHRP，但可能继续支持ARP变体，如[3]和[4]中所述。NHRP旨在减少或消除LIS模型所需的额外路由器跳数，并且可以以非干扰方式部署现有ARP服务[14]。
The operation of NHRP to establish transit paths across NBMA subnetworks between two routers requires additional mechanisms to avoid stable routing loops, and will be described in a separate document (see [13]).
NHRP在两个路由器之间跨NBMA子网建立传输路径的操作需要额外的机制来避免稳定的路由循环，并将在单独的文件中描述（见[13]）。
The term "network" is highly overloaded, and is especially confusing in the context of NHRP. We use the following terms:
“网络”一词是高度过载的，在NHRP的上下文中尤其令人困惑。我们使用以下术语：
Internetwork layer--the media-independent layer (IP in the case of TCP/IP networks).
互联网层——与媒体无关的层（TCP/IP网络中的IP）。
Subnetwork layer--the media-dependent layer underlying the internetwork layer, including the NBMA technology (ATM, X.25, SMDS, etc.)
子网层——网络层下的媒体相关层，包括NBMA技术（ATM、X.25、SMDS等）
The term "server", unless explicitly stated to the contrary, refers to a Next Hop Server (NHS). An NHS is an entity performing the Next Hop Resolution Protocol service within the NBMA cloud. An NHS is always tightly coupled with a routing entity (router, route server or edge device) although the converse is not yet guaranteed until ubiquitous deployment of this functionality occurs. Note that the presence of intermediate routers that are not coupled with an NHS entity may preclude the use of NHRP when source and destination stations on different sides of such routers and thus such routers may partition NHRP reachability within an NBMA network.
除非明确说明相反，否则术语“服务器”指下一跳服务器（NHS）。NHS是在NBMA云中执行下一跳解析协议服务的实体。NHS总是与路由实体（路由器、路由服务器或边缘设备）紧密耦合，尽管在这种功能的普遍部署发生之前，还不能保证反过来。注意，当源站和目的站位于此类路由器的不同侧上时，不与NHS实体耦合的中间路由器的存在可能阻止使用NHRP，因此此类路由器可能在NBMA网络内划分NHRP可达性。
The term "client", unless explicitly stated to the contrary, refers to a Next Hop Resolution Protocol client (NHC). An NHC is an entity which initiates NHRP requests of various types in order to obtain access to the NHRP service.
除非明确说明相反，否则术语“客户机”指下一跳解析协议客户机（NHC）。NHC是发起各种类型的NHRP请求以获得对NHRP服务的访问权的实体。
The term "station" generally refers to a host or router which contains an NHRP entity. Occasionally, the term station will describe a "user" of the NHRP client or service functionality; the difference in usage is largely semantic.
术语“站”通常指包含NHRP实体的主机或路由器。有时，术语station将描述NHRP客户端或服务功能的“用户”；用法上的差异主要是语义上的。
In this section, we briefly describe how a source S (which potentially can be either a router or a host) uses NHRP to determine the "NBMA next hop" to destination D.
在本节中，我们简要描述了源S（可能是路由器或主机）如何使用NHRP确定到目的地D的“NBMA下一跳”。
For administrative and policy reasons, a physical NBMA subnetwork may be partitioned into several, disjoint "Logical NBMA subnetworks". A Logical NBMA subnetwork is defined as a collection of hosts and routers that share unfiltered subnetwork connectivity over an NBMA subnetwork. "Unfiltered subnetwork connectivity" refers to the absence of closed user groups, address screening or similar features that may be used to prevent direct communication between stations connected to the same NBMA subnetwork. (Hereafter, unless otherwise specified, we use the term "NBMA subnetwork" to mean *logical* NBMA subnetwork.)
出于行政和政策原因，一个物理NBMA子网可划分为多个不相交的“逻辑NBMA子网”。逻辑NBMA子网定义为在NBMA子网上共享未过滤子网连接的主机和路由器的集合。“未过滤子网连接”是指没有封闭的用户组、地址屏蔽或类似功能，可用于防止连接到同一NBMA子网的站点之间的直接通信。（下文中，除非另有规定，否则我们使用术语“NBMA子网络”表示*逻辑*NBMA子网络。）
Placed within the NBMA subnetwork are one or more entities that implement the NHRP protocol. Such stations which are capable of answering NHRP Resolution Requests are known as "Next Hop Servers" (NHSs). Each NHS serves a set of destination hosts, which may or may not be directly connected to the NBMA subnetwork. NHSs cooperatively resolve the NBMA next hop within their logical NBMA subnetwork. In addition to NHRP, NHSs may support "classical" ARP service; however, this will be the subject of a separate document [14].
NBMA子网中有一个或多个实施NHRP协议的实体。能够响应NHRP解析请求的此类站点称为“下一跳服务器”（NHS）。每个NHS为一组目的地主机提供服务，这些主机可以直接连接到NBMA子网，也可以不直接连接到NBMA子网。NHS在其逻辑NBMA子网内协作解析NBMA下一跳。除了NHRP，NHSs还可以支持“经典”ARP服务；然而，这将是另一份文件[14]的主题。
An NHS maintains a cache which contains protocol layer address to NBMA subnetwork layer address resolution information. This cache can be constructed from information obtained from NHRP Register packets (see Section 5.2.3 and 5.2.4), from NHRP Resolution Request/Reply packets, or through mechanisms outside the scope of this document (examples of such mechanisms might include ARP[3] and pre-configured tables). Section 6.2 further describes cache management issues.
NHS维护一个缓存，其中包含协议层地址到NBMA子网络层地址解析信息。该缓存可根据从NHRP寄存器数据包（见第5.2.3节和第5.2.4节）获得的信息、从NHRP解析请求/回复数据包获得的信息或通过本文件范围以外的机制（此类机制的示例可能包括ARP[3]和预配置表）来构建。第6.2节进一步描述了缓存管理问题。
For a station within a given LIS to avoid providing NHS functionality, there must be one or more NHSs within the NBMA subnetwork which are providing authoritative address resolution information on its behalf. Such an NHS is said to be "serving" the 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 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 routed paths between the NHC making the resolution request and the destination NHC. The last NHRP entity along the routed path is the serving NHS; that is, NHRP Resolution Requests are not forwarded to destination NHCs but rather are processed by the serving NHS.
对于给定LIS内的站点，为了避免提供NHS功能，NBMA子网内必须有一个或多个NHS代表其提供权威地址解析信息。这样的NHS据说是在“服务”电视台。LIS上缺少NHS功能且是NHRP服务客户端的站点称为NHRP客户端或NHCs。如果服务NHS能够为NHC提供地址解析信息，则NHS必须位于发出解析请求的NHC和目标NHC之间的所有路由路径上的每个跃点处。沿路由路径的最后一个NHRP实体是服务NHS；也就是说，NHRP解析请求不会转发到目标NHC，而是由服务NHS处理。
An NHC also maintains a cache of protocol address to NBMA address resolution information. This cache is populated through information obtained from NHRP Resolution Reply packets, from manual configuration, or through mechanisms outside the scope of this document.
NHC还维护协议地址到NBMA地址解析信息的缓存。该缓存通过从NHRP解析应答包、手动配置或通过本文档范围之外的机制获得的信息填充。
The protocol proceeds as follows. An event occurs triggering station S to want to resolve the NBMA address of a path to D. This is most likely to be when a data packet addressed to station D is to be emitted from station S (either because station S is a host, or station S is a transit router), but the address resolution could also be triggered by other means (a routing protocol update packet, for example). Station S first determines the next hop to station D through normal routing processes (for a host, the next hop may simply be the default router; for routers, this is the "next hop" to the destination internetwork layer address). If the destination's address resolution information is already available in S's cache then that information is used to forward the packet. Otherwise, if the next hop is reachable through one of its NBMA interfaces, S constructs an NHRP Resolution Request packet (see Section 5.2.1) containing station D's internetwork layer address as the (target) destination address, S's own internetwork layer address as the source address (Next Hop Resolution Request initiator), and station S's NBMA addressing information. Station S may also indicate that it prefers an authoritative NHRP Resolution Reply (i.e., station S only wishes to receive an NHRP Resolution Reply from an NHS serving the destination NHC). Station S emits the NHRP Resolution Request packet towards the destination.
议定书进行如下。触发站点S想要解析到D的路径的NBMA地址的事件发生。这最有可能是当从站点S发出寻址到站点D的数据包时（因为站点S是主机，或者站点S是中转路由器），但地址解析也可以通过其他方式触发（例如，路由协议更新数据包）。站点S首先通过正常路由过程确定到站点D的下一跳（对于主机，下一跳可能只是默认路由器；对于路由器，这是到目标网络层地址的“下一跳”）。如果目的地的地址解析信息已在s的缓存中可用，则该信息将用于转发数据包。否则，如果下一跳可通过其NBMA接口之一到达，s将构造一个NHRP解析请求数据包（见第5.2.1节），其中包含站点D的网络间层地址作为（目标）目标地址、作为源地址的自身网络层地址（下一跳解析请求发起方）和站点的NBMA寻址信息。站点S也可能表示它更喜欢权威的NHRP解析回复（即，站点S仅希望从为目的地NHC提供服务的NHS接收NHRP解析回复）。站点S向目的地发送NHRP解析请求包。
If the NHRP Resolution Request is triggered by a data packet then S may, while awaiting an NHRP Resolution Reply, choose to dispose of the data packet in one of the following ways:
如果NHRP解析请求由数据包触发，则S可以在等待NHRP解析回复时，选择以以下方式之一处置数据包：
(a) Drop the packet (b) Retain the packet until the NHRP Resolution Reply arrives and a more optimal path is available (c) Forward the packet along the routed path toward D
(a) 丢弃数据包（b）保留该数据包，直到NHRP解析应答到达并且有一个更优化的路径可用（c）沿着路由路径将数据包转发到D
The choice of which of the above to perform is a local policy matter, though option (c) is the recommended default, since it may allow data to flow to the destination while the NBMA address is being resolved. Note that an NHRP Resolution Request for a given destination MUST NOT be triggered on every packet.
选择执行上述哪一项是本地策略问题，尽管选项（c）是推荐的默认选项，因为它可能允许数据在解析NBMA地址时流向目的地。请注意，对于给定目的地的NHRP解析请求不得在每个数据包上触发。
When the NHS receives an NHRP Resolution Request, a check is made to see if it serves station D. If the NHS does not serve D, the NHS forwards the NHRP Resolution Request to another NHS. Mechanisms for determining how to forward the NHRP Resolution Request are discussed in Section 3.
当NHS收到NHRP解决请求时，会进行检查，以查看其是否为D站服务。如果NHS不为D站服务，NHS会将NHRP解决请求转发给另一个NHS。第3节讨论了确定如何转发NHRP解决方案请求的机制。
If this NHS serves D, the NHS resolves station D's NBMA address information, and generates a positive NHRP Resolution Reply on D's behalf. NHRP Resolution Replies in this scenario are always marked as "authoritative". The NHRP Resolution Reply packet contains the
如果该NHS服务于D，则NHS解析站点D的NBMA地址信息，并代表D生成一个肯定的NHRP解析回复。此场景中的NHRP解决方案回复始终标记为“权威”。NHRP解析应答包包含
address resolution information for station D which is to be sent back to S. Note that if station D is not on the NBMA subnetwork, the next hop internetwork layer address will be that of the egress router through which packets for station D are forwarded.
要发送回S的站点D的地址解析信息。请注意，如果站点D不在NBMA子网上，则下一跳网络间层地址将是转发站点D的数据包所通过的出口路由器的地址。
A transit NHS receiving an NHRP Resolution Reply may cache the address resolution information contained therein. To a subsequent NHRP Resolution Request, this NHS may respond with the cached, "non-authoritative" address resolution information if the NHS is permitted to do so (see Sections 5.2.2 and 6.2 for more information on non-authoritative versus authoritative NHRP Resolution Replies). Non-authoritative NHRP Resolution Replies are distinguished from authoritative NHRP Resolution Replies so that if a communication attempt based on non-authoritative information fails, a source station can choose to send an authoritative NHRP Resolution Request. NHSs MUST NOT respond to authoritative NHRP Resolution Requests with cached information.
接收NHRP解析应答的中转NHS可以缓存其中包含的地址解析信息。对于后续NHRP解析请求，如果NHS允许，该NHS可以使用缓存的“非权威”地址解析信息进行响应（有关非权威与权威NHRP解析回复的更多信息，请参见第5.2.2节和第6.2节）。非权威NHRP解析应答与权威NHRP解析应答区分开来，因此，如果基于非权威信息的通信尝试失败，源站可以选择发送权威NHRP解析请求。NHS不得使用缓存信息响应权威NHRP解析请求。
If the determination is made that no NHS in the NBMA subnetwork can reply to the NHRP Resolution Request for D then a negative NHRP Resolution Reply (NAK) is returned. This occurs when (a) no next-hop resolution information is available for station D from any NHS, or (b) an NHS is unable to forward the NHRP Resolution Request (e.g., connectivity is lost).
如果确定NBMA子网中没有NHS可以回复D的NHRP解析请求，则返回否定的NHRP解析回复（NAK）。当（a）任何NHS没有站点D的下一跳分辨率信息，或（b）NHS无法转发NHRP分辨率请求（例如，连接丢失）时，就会发生这种情况。
NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies, and NHRP Error Indications follow a routed path in the same fashion that NHRP Resolution Requests and NHRP Resolution Replies do. Specifically, "requests" and "indications" follow the routed path from Source Protocol Address (which is the address of the station initiating the communication) to the Destination Protocol Address. "Replies", on the other hand, follow the routed path from the Destination Protocol Address back to the Source Protocol Address with the following exceptions: in the case of a NHRP Registration Reply and in the case of an NHC initiated NHRP Purge Request, the packet is always returned via a direct VC (see Sections 5.2.4 and 5.2.5); if one does not exists then one MUST be created.
NHRP注册请求、NHRP清除请求、NHRP清除回复和NHRP错误指示以与NHRP解析请求和NHRP解析回复相同的方式遵循路由路径。具体而言，“请求”和“指示”遵循从源协议地址（即发起通信的站点的地址）到目标协议地址的路由路径。另一方面，“回复”遵循从目标协议地址返回到源协议地址的路由路径，但以下例外情况除外：在NHRP注册回复和NHC发起的NHRP清除请求的情况下，数据包始终通过直接VC返回（见第5.2.4节和第5.2.5节）；如果一个不存在，那么必须创建一个。
NHRP Requests and NHRP Replies do NOT cross the borders of a NBMA subnetwork however further study is being done in this area (see Section 7). Thus, the internetwork layer data traffic out of and into an NBMA subnetwork always traverses an internetwork layer router at its border.
NHRP请求和NHRP回复不会跨越NBMA子网的边界，但该领域正在进行进一步研究（见第7节）。因此，进出NBMA子网的网间层数据流量始终在其边界处穿过网间层路由器。
NHRP optionally provides a mechanism to send a NHRP Resolution Reply which contains aggregated address resolution information. For example, suppose that router X is the next hop from station S to station D and that X is an egress router for all stations sharing an
NHRP可选地提供发送包含聚合地址解析信息的NHRP解析回复的机制。例如，假设路由器X是从站S到站D的下一个跃点，并且X是共享一个路由的所有站的出口路由器
internetwork layer address prefix with station D. When an NHRP Resolution Reply is generated in response to a NHRP Resolution Request, the responder may augment the internetwork layer address of station D with a prefix length (see Section 5.2.0.1). A subsequent (non-authoritative) NHRP Resolution Request for some destination that shares an internetwork layer address prefix (for the number of bits specified in the prefix length) with D may be satisfied with this cached information. See section 6.2 regarding caching issues.
带有站点D的网络层地址前缀。当响应NHRP解析请求生成NHRP解析应答时，响应者可使用前缀长度增加站点D的网络层地址（见第5.2.0.1节）。对于与D共享网际层地址前缀（对于前缀长度中指定的比特数）的某个目的地的后续（非权威）NHRP解析请求可以使用该缓存信息来满足。有关缓存问题，请参见第6.2节。
To dynamically detect subnetwork-layer filtering in NBMA subnetworks (e.g., X.25 closed user group facility, or SMDS address screens), to trace the routed path that an NHRP packet takes, or to provide loop detection and diagnostic capabilities, a "Route Record" may be included in NHRP packets (see Sections 5.3.2 and 5.3.3). The Route Record extensions are the NHRP Forward Transit NHS Record Extension and the NHRP Reverse Transit NHS Record Extension. They contain the internetwork (and subnetwork layer) addresses of all intermediate NHSs between source and destination and between destination and source respectively. When a source station is unable to communicate with the responder (e.g., an attempt to open an SVC fails), it may attempt to do so successively with other subnetwork layer addresses in the NHRP Forward Transit NHS Record Extension until it succeeds (if authentication policy permits such action). This approach can find a suitable egress point in the presence of subnetwork-layer filtering (which may be source/destination sensitive, for instance, without necessarily creating separate logical NBMA subnetworks) or subnetwork-layer congestion (especially in connection-oriented media).
为了动态检测NBMA子网中的子网层过滤（例如，X.25封闭用户组设施或SMDS地址屏幕），跟踪NHRP数据包的路由路径，或提供环路检测和诊断功能，“路由记录”可包含在NHRP数据包中（见第5.3.2和5.3.3节）。路线记录扩展为NHRP正向交通NHS记录扩展和NHRP反向交通NHS记录扩展。它们分别包含源和目标之间以及目标和源之间的所有中间NHS的网络间（和子网络层）地址。当源站无法与响应者通信时（例如，打开SVC的尝试失败），它可以尝试与NHRP前向传输NHS记录扩展中的其他子网层地址连续通信，直到成功为止（如果身份验证策略允许此类操作）。这种方法可以在存在子网层过滤（例如，可能对源/目的地敏感，而不必创建单独的逻辑NBMA子网）或子网层拥塞（尤其是在面向连接的介质中）的情况下找到合适的出口点。
NHRP Resolution Requests traverse one or more hops within an NBMA subnetwork before reaching the station that is expected to generate a response. Each station, including the source station, chooses a neighboring NHS to which it will forward the NHRP Resolution Request. The NHS selection procedure typically involves applying a destination protocol layer address to the protocol layer routing table which causes a routing decision to be returned. This routing decision is then used to forward the NHRP Resolution Request to the downstream NHS. The destination protocol layer address previously mentioned is carried within the NHRP Resolution Request packet. Note that even though a protocol layer address was used to acquire a routing decision, NHRP packets are not encapsulated within a protocol layer header but rather are carried at the NBMA layer using the encapsulation described in Section 5.
NHRP解析请求在到达预期生成响应的站点之前，在NBMA子网内通过一个或多个跃点。每个站点（包括源站点）选择一个相邻的NHS，并将NHRP解析请求转发到该NHS。NHS选择过程通常涉及将目的地协议层地址应用于协议层路由表，从而导致返回路由决策。然后使用该路由决策将NHRP解决请求转发给下游NHS。前面提到的目标协议层地址携带在NHRP解析请求包中。注意，即使使用协议层地址来获取路由决策，NHRP分组也不封装在协议层报头中，而是使用第5节中描述的封装在NBMA层上携带。
Each NHS/router examines the NHRP Resolution Request packet on its way toward the destination. Each NHS which the NHRP packet traverses on the way to the packet's destination might modify the packet (e.g., updating the Forward Record extension). Ignoring error situations, the NHRP Resolution Request eventually arrives at a station that is to generate an NHRP Resolution Reply. This responding station "serves" the destination. The responding station generates an NHRP Resolution Reply using the source protocol address from within the NHRP packet to determine where the NHRP Resolution Reply should be sent.
每个NHS/路由器在通往目的地的途中检查NHRP解析请求包。NHRP数据包在到达数据包目的地的途中经过的每个NHS可能会修改数据包（例如，更新转发记录扩展）。忽略错误情况，NHRP解析请求最终到达要生成NHRP解析应答的站点。该响应站“服务”目的地。响应站使用来自NHRP包内的源协议地址生成NHRP解析应答，以确定应将NHRP解析应答发送到何处。
Rather than use routing to determine the next hop for an NHRP packet, an NHS may use other applicable means (such as static configuration information ) in order to determine to which neighboring NHSs to forward the NHRP Resolution Request packet as long as such other means would not cause the NHRP packet to arrive at an NHS which is not along the routed path. The use of static configuration information for this purpose is beyond the scope of this document.
NHS可以使用其他适用的手段（例如静态配置信息），而不是使用路由来确定NHRP分组的下一跳为了确定将NHRP解析请求分组转发到哪个相邻NHS，只要这样的其他装置不会导致NHRP分组到达不沿路由路径的NHS。为此目的使用静态配置信息超出了本文档的范围。
The NHS serving a particular destination must lie along the routed path to that destination. In practice, this means that all egress routers must double as NHSs serving the destinations beyond them, and that hosts on the NBMA subnetwork are served by routers that double as NHSs. Also, this implies that forwarding of NHRP packets within an NBMA subnetwork requires a contiguous deployment of NHRP capable 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 resolution databases synchronized so that a packet arriving at one router/NHS in a given LIS/LAG will be forwarded in the same fashion 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 Protocol (SCSP) [12]. It is RECOMMENDED that SCSP be the method used when a LIS/LAG contains two or more router/NHSs.
为特定目的地提供服务的NHS必须位于通往该目的地的路由路径上。实际上，这意味着所有出口路由器必须同时作为NHS服务于它们以外的目的地，NBMA子网上的主机由同时作为NHS的路由器服务。此外，这意味着在NBMA子网内转发NHRP数据包需要连续部署支持NHRP的路由器。重要的是，在使用NHRP的给定LIS/LAG中，LIS/LAG中的所有NHS至少同步其解析数据库的一部分，以便到达给定LIS/LAG中一个路由器/NHS的数据包将以与到达给定LIS/LAG的不同路由器/NHS的数据包相同的方式转发。其中一种方法是使用服务器缓存同步协议（SCSP）[12]。当LIS/LAG包含两个或多个路由器/NHS时，建议使用SCSP方法。
During migration to NHRP, it cannot be expected that all routers within the NBMA subnetwork are NHRP capable. Thus, NHRP traffic which would otherwise need to be forwarded through such routers can be expected to be dropped due to the NHRP packet not being recognized. In this case, NHRP will be unable to establish any transit paths whose discovery requires the traversal of the non-NHRP speaking routers. If the client has tried and failed to acquire a cut through path then the client should use the network layer routed path as a default.
在迁移到NHRP期间，不能期望NBMA子网内的所有路由器都支持NHRP。因此，原本需要通过此类路由器转发的NHRP流量可能会由于NHRP分组未被识别而被丢弃。在这种情况下，NHRP将无法建立其发现需要遍历非NHRP路由器的任何传输路径。如果客户端尝试获取直通路径但失败，则客户端应使用网络层路由路径作为默认路径。
If an NBMA technology offers a group, an anycast, or a multicast addressing feature then the NHC may be configured with such an address (appropriate to the routing realm it participates in) which would be assigned to all NHS serving that routing realm. This
如果NBMA技术提供组、选播或多播寻址功能，则NHC可配置有这样一个地址（适用于其参与的路由领域），该地址将分配给服务于该路由领域的所有NHS。这
address can then be used for establishing an initial connection to an NHS to transmit a registration request. This address may not be used for sending NHRP requests. The resulting VC may be used for NHRP requests if and only if the registration response is received over that VC, thereby indicating that one happens to have anycast connected to an NHS serving the LIS/LAG. In the case of non-connection oriented networks, or of multicast (rather than anycast) addresses, the addres MUST NOT be used for sending NHRP resolution requests.
然后，地址可用于建立到NHS的初始连接，以发送注册请求。此地址不能用于发送NHRP请求。当且仅当通过该VC接收到注册响应时，所得VC可用于NHRP请求，从而指示其中一个碰巧具有连接到服务于LIS/LAG的NHS的选播。在非面向连接的网络或多播（而非选播）地址的情况下，地址不得用于发送NHRP解析请求。
When an NHS "serves" an NHC, the NHS MUST send NHRP messages destined for the NHC directly to the NHC. That is, the NHRP message MUST NOT transit through any NHS which is not serving the NHC when the NHRP message is currently at an NHS which does serve the NHC (this, of course, assumes the NHRP message is destined for the NHC). Further, an NHS which serves an NHC SHOULD have a direct NBMA level connection to that NHC (see Section 5.2.3 and 5.2.4 for examples).
当NHS“服务”NHC时，NHS必须直接向NHC发送目的地为NHC的NHRP消息。也就是说，当NHRP消息当前位于确实服务于NHC的NHS时，NHRP消息不得通过不服务于NHC的任何NHS传输（当然，这假定NHRP消息是以NHC为目的地的）。此外，为NHC提供服务的NHS应具有与该NHC的直接NBMA级连接（示例见第5.2.3节和第5.2.4节）。
With the exception of NHRP Registration Requests (see Section 5.2.3 and 5.2.4 for details of the NHRP Registration Request case), an NHC MUST send NHRP messages over a direct NBMA level connection between the serving NHS and the served NHC.
除NHRP注册请求外（NHRP注册请求案例详情见第5.2.3节和第5.2.4节），NHC必须通过服务NHS和服务NHC之间的直接NBMA级连接发送NHRP消息。
It may not be desirable to maintain semi-permanent NBMA level connectivity between the NHC and the NHS. In this case, when NBMA level connectivity is initially setup between the NHS and the NHC (as described in Section 5.2.4), the NBMA address of the NHS should be obtained through the NBMA level signaling technology. This address should be stored for future use in setting up subsequent NBMA level connections. A somewhat more information rich technique to obtain the address information (and more) of the serving NHS would be for the NHC to include the Responder Address extension (see Section 5.3.1) in the NHRP Registration Request and to store the information returned to the NHC in the Responder Address extension which is subsequently included in the NHRP Registration Reply. Note also that, in practice, a client's default router should also be its NHS; thus a client may be able to know the NBMA address of its NHS from the configuration which was already required for the client to be able to communicate. Further, as mentioned in Section 4, NHCs may be configured with the addressing information of one or more NHSs.
可能不希望在NHC和NHS之间保持半永久性NBMA级连接。在这种情况下，当NHS和NHC之间最初建立NBMA级连接时（如第5.2.4节所述），NHS的NBMA地址应通过NBMA级信令技术获得。应存储此地址，以备将来在设置后续NBMA级连接时使用。获取服务NHS地址信息（及更多）的一种信息更丰富的技术是NHC包括应答器地址扩展（见第5.3.1节）在NHRP注册请求中，并将返回给NHC的信息存储在响应者地址扩展中，该扩展随后包含在NHRP注册回复中。还要注意，在实践中，客户机的默认路由器也应该是其NHS；因此，客户机可以从配置中知道其NHS的NBMA地址，该配置已经是客户机能够通信所必需的。此外，如第4节所述，NHC可配置有一个或多个NHS的寻址信息。
Next Hop Clients
下一跳客户端
An NHC connected to an NBMA subnetwork MAY be configured with the Protocol address(es) and NBMA address(es) of its NHS(s). The NHS(s) will likely also represent the NHC's default or peer
连接到NBMA子网的NHC可以配置其NHS的协议地址和NBMA地址。NHS也可能代表NHC的违约或对等
routers, so their NBMA addresses may be obtained from the NHC's existing configuration. If the NHC is attached to several subnetworks (including logical NBMA subnetworks), the NHC should also be configured to receive routing information from its NHS(s) and peer routers so that it can determine which internetwork layer networks are reachable through which subnetworks.
路由器，因此它们的NBMA地址可以从NHC的现有配置中获得。如果NHC连接到多个子网（包括逻辑NBMA子网），NHC还应配置为从其NHS和对等路由器接收路由信息，以便它可以确定通过哪个子网可以访问哪个网络层网络。
Next Hop Servers
下一跳服务器
An NHS is configured with knowledge of its own internetwork layer and NBMA addresses. An NHS MAY also be configured with a set of internetwork layer address prefixes that correspond to the internetwork layer addresses of the stations it serves. The NBMA addresses of the stations served by the NHS may be learned via NHRP Registration packets.
NHS配置有其自己的网络层和NBMA地址的知识。NHS还可以配置一组网络层地址前缀，这些前缀对应于它所服务的站点的网络层地址。NHS服务的站点的NBMA地址可以通过NHRP注册包来学习。
If a served NHC is attached to several subnetworks, the router/route-server coresident with the serving NHS may also need to be configured to advertise routing information to such NHCs.
如果一个被服务的NHC连接到多个子网，那么与服务的NHS协同的路由器/路由服务器也可能需要被配置为向这样的NHC通告路由信息。
If an NHS acts as an egress router for stations connected to other subnetworks than the NBMA subnetwork, the NHS must, in addition to the above, be configured to exchange routing information between the NBMA subnetwork and these other subnetworks.
如果NHS充当连接到NBMA子网以外的其他子网的站点的出口路由器，则NHS必须配置为在NBMA子网和这些其他子网之间交换路由信息。
In all cases, routing information is exchanged using conventional intra-domain and/or inter-domain routing protocols.
在所有情况下，使用传统的域内和/或域间路由协议交换路由信息。
This section describes the format of NHRP packets. In the following, unless otherwise stated explicitly, the unqualified term "request" refers generically to any of the NHRP packet types which are "requests". Further, unless otherwise stated explicitly, the unqualified term "reply" refers generically to any of the NHRP packet types which are "replies".
本节介绍NHRP数据包的格式。在下文中，除非另有明确说明，否则非限定术语“请求”一般指任何属于“请求”的NHRP数据包类型。此外，除非另有明确说明，否则非限定术语“回复”一般指作为“回复”的任何NHRP分组类型。
An NHRP packet consists of a Fixed Part, a Mandatory Part, and an Extensions Part. The Fixed Part is common to all NHRP packet types. The Mandatory Part MUST be present, but varies depending on packet type. The Extensions Part also varies depending on packet type, and need not be present.
NHRP包由固定部分、强制部分和扩展部分组成。固定部分是所有NHRP数据包类型的通用部分。必需部分必须存在，但根据数据包类型而有所不同。扩展部分也因数据包类型而异，不需要存在。
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 offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part 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
固定部分的长度固定为20个八位字节。强制零件的长度由extensions offset字段（ar$extoff）的内容确定。如果ar$extoff=0x0，则强制部分长度等于总数据包长度（ar$pktsz）减去20，否则强制部分长度等于ar$extoff减去20。长度
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 processing, but not beyond the offered maximum packet size of the NBMA network.
扩展部分的值由ar$pktsz减去ar$extoff表示。nhs可作为扩展处理的结果增加NHRP分组的大小，但不超过所提供的NBMA网络的最大分组大小。
NHRP packets are actually members of a wider class of address mapping and management protocols being developed by the IETF. A specific encapsulation, based on the native formats used on the particular NBMA network over which NHRP is carried, indicates the generic IETF mapping and management protocol. For example, SMDS networks always use LLC/SNAP encapsulation at the NBMA layer [4], and an NHRP packet is preceded by the following LLC/SNAP encapsulation:
NHRP数据包实际上是IETF正在开发的一类更广泛的地址映射和管理协议的成员。基于NHRP承载的特定NBMA网络上使用的本机格式的特定封装表示通用IETF映射和管理协议。例如，SMDS网络始终在NBMA层使用LLC/SNAP封装[4]，NHRP数据包前面有以下LLC/SNAP封装：
[0xAA-AA-03] [0x00-00-5E] [0x00-03]
[0xAA-AA-03][0x00-00-5E][0x00-03]
The first three octets are LLC, indicating that SNAP follows. The SNAP OUI portion is the IANA's OUI, and the SNAP PID portion identifies the mapping and management protocol. A field in the Fixed Header following the encapsulation indicates that it is NHRP.
前三个八位组是LLC，表示SNAP紧随其后。SNAP OUI部分是IANA的OUI，SNAP PID部分标识映射和管理协议。封装后固定标头中的字段表示它是NHRP。
ATM uses either LLC/SNAP encapsulation of each packet (including NHRP), or uses no encapsulation on VCs dedicated to a single protocol (see [7]). Frame Relay and X.25 both use NLPID/SNAP encapsulation or identification of NHRP, using a NLPID of 0x0080 and the same SNAP contents as above (see [8], [9]).
ATM使用每个数据包（包括NHRP）的LLC/SNAP封装，或者在专用于单个协议的VCs上不使用封装（参见[7]）。帧中继和X.25都使用NLPID/SNAP封装或NHRP标识，使用0x0080的NLPID和与上述相同的SNAP内容（见[8]，[9]）。
Fields marked "unused" MUST be set to zero on transmission, and ignored on receipt.
标记为“未使用”的字段在传输时必须设置为零，在接收时忽略。
Most packet types (ar$op.type) have both internetwork layer protocol-independent fields and protocol-specific fields. The protocol type/snap fields (ar$pro.type/snap) qualify the format of the protocol-specific fields.
大多数数据包类型（ar$op.type）既有网络层协议独立字段，也有协议特定字段。协议类型/快照字段（ar$pro.type/snap）限定协议特定字段的格式。
The Fixed Part of the NHRP packet contains those elements of the NHRP packet which are always present and do not vary in size with the type of packet.
NHRP数据包的固定部分包含始终存在且大小不随数据包类型变化的NHRP数据包元素。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$afn | ar$pro.type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$pro.snap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$pro.snap | ar$hopcnt | ar$pktsz |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$chksum | ar$extoff |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$op.version | ar$op.type | ar$shtl | ar$sstl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$afn | ar$pro.type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$pro.snap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$pro.snap | ar$hopcnt | ar$pktsz |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$chksum | ar$extoff |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$op.version | ar$op.type | ar$shtl | ar$sstl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ar$afn Defines the type of "link layer" addresses being carried. This number is taken from the 'address family number' list specified in [6]. This field has implications to the coding of ar$shtl and ar$sstl as described below.
ar$afn定义所携带的“链路层”地址的类型。此编号取自[6]中指定的“地址族编号”列表。该字段对ar$shtl和ar$sstl的编码有影响，如下所述。
ar$pro.type field is a 16 bit unsigned integer representing the following number space:
ar$pro.type字段是一个16位无符号整数，表示以下数字空间：
0x0000 to 0x00FF Protocols defined by the equivalent NLPIDs. 0x0100 to 0x03FF Reserved for future use by the IETF. 0x0400 to 0x04FF Allocated for use by the ATM Forum. 0x0500 to 0x05FF Experimental/Local use. 0x0600 to 0xFFFF Protocols defined by the equivalent Ethertypes.
由等效NLPID定义的0x0000到0x00FF协议。0x0100到0x03FF保留供IETF将来使用。分配给ATM论坛使用的0x0400到0x04FF。0x0500至0x05FF试验/本地使用。由等效以太网类型定义的0x0600到0xFFFF协议。
(based on the observations that valid Ethertypes are never smaller than 0x600, and NLPIDs never larger than 0xFF.)
（根据观察，有效的以太类型从不小于0x600，NLPIDs从不大于0xFF。）
ar$pro.snap When ar$pro.type has a value of 0x0080, a SNAP encoded extension is being used to encode the protocol type. This snap extension is placed in the ar$pro.snap field. This is termed the 'long form' protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be zero on transmit and ignored on receive. The ar$pro.type field itself identifies the protocol being referred to. This is termed the 'short form' protocol ID.
ar$pro.snap当ar$pro.type的值为0x0080时，将使用snap编码的扩展对协议类型进行编码。此快照扩展名位于ar$pro.snap字段中。这被称为“长格式”协议ID。如果ar$pro！=0x0080则ar$pro.snap字段在传输时必须为零，在接收时必须忽略。ar$pro.type字段本身标识所引用的协议。这被称为“短格式”协议ID。
In all cases, where a protocol has an assigned number in the ar$pro.type space (excluding 0x0080) the short form MUST be used when transmitting NHRP messages; i.e., if Ethertype or NLPID codings exist then they are used on transmit rather than the
在所有情况下，如果协议在ar$pro.type空间（不包括0x0080）中具有分配的编号，则在传输NHRP消息时必须使用缩写形式；i、 例如，如果存在Ethertype或NLPID编码，则将其用于传输，而不是传输
ethertype. If both Ethertype and NLPID codings exist then when transmitting NHRP messages, the Ethertype coding MUST be used (this is consistent with RFC 1483 coding). So, for example, the following codings exist for IP:
以太型。如果存在Ethertype和NLPID编码，则在传输NHRP消息时，必须使用Ethertype编码（这与RFC 1483编码一致）。因此，例如，IP存在以下编码：
SNAP: ar$pro.type = 0x00-80, ar$pro.snap = 0x00-00-00-08-00
NLPID: ar$pro.type = 0x00-CC, ar$pro.snap = 0x00-00-00-00-00
Ethertype: ar$pro.type = 0x08-00, ar$pro.snap = 0x00-00-00-00-00
SNAP: ar$pro.type = 0x00-80, ar$pro.snap = 0x00-00-00-08-00
NLPID: ar$pro.type = 0x00-CC, ar$pro.snap = 0x00-00-00-00-00
Ethertype: ar$pro.type = 0x08-00, ar$pro.snap = 0x00-00-00-00-00
and thus, since the Ethertype coding exists, it is used in preference.
因此，由于存在Ethertype编码，因此优先使用它。
ar$hopcnt The Hop count indicates the maximum number of NHSs that an NHRP packet is allowed to traverse before being discarded. This field is used in a similar fashion to the way that a TTL is used in an IP packet and should be set accordingly. Each NHS decrements the TTL as the NHRP packet transits the NHS on the way to the next hop along the routed path to the destination. If an NHS receives an NHRP packet which it would normally forward to a next hop and that packet contains an ar$hopcnt set to zero then the NHS sends an error indication message back to the source protocol address stating that the hop count has been exceeded (see Section 5.2.7) and the NHS drops the packet in error; however, an error indication is never sent as a result of receiving an error 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 its own.
ar$hopcnt跃点计数表示NHRP数据包在被丢弃之前允许通过的最大NHS数。该字段的使用方式与在IP数据包中使用TTL的方式类似，因此应相应地进行设置。当NHRP数据包沿着路由路径在到达目的地的下一跳的途中传输NHS时，每个NHS递减TTL。如果NHS接收到一个NHRP数据包，该数据包通常会转发到下一个跃点，并且该数据包包含设置为零的ar$hopcnt，则NHS向源协议地址发送一条错误指示消息，说明已超过跃点计数（见第5.2.7节），NHS错误地丢弃该数据包；但是，由于接收到错误指示，因此不会发送错误指示。当做出响应的NHS回复NHRP请求时，该NHS在ar$hopcnt中放置一个值，就好像它正在发送自己的请求一样。
ar$pktsz The total length of the NHRP packet, in octets (excluding link layer encapsulation).
ar$pktsz—NHRP数据包的总长度，以八位字节为单位（不包括链路层封装）。
ar$chksum The standard IP checksum over the entire NHRP packet starting at the fixed header. If the packet is an odd number of bytes in length then this calculation is performed as if a byte set to 0x00 is appended to the end of the packet.
ar$chksum从固定报头开始的整个NHRP数据包的标准IP校验和。如果数据包的长度为奇数字节，则执行此计算时，就好像将设置为0x00的字节追加到数据包的末尾一样。
ar$extoff This field identifies the existence and location of NHRP extensions. If this field is 0 then no extensions exist otherwise this field represents the offset from the beginning of the NHRP packet (i.e., starting from the ar$afn field) of the first extension.
ar$extoff此字段标识NHRP扩展的存在和位置。如果该字段为0，则不存在扩展，否则该字段表示从第一个扩展的NHRP数据包的开始（即，从ar$afn字段开始）的偏移量。
ar$op.version This field indicates what version of generic address mapping and management protocol is represented by this message.
ar$op.version此字段指示此消息表示的通用地址映射和管理协议的版本。
0 MARS protocol [11]. 1 NHRP as defined in this document. 0x02 - 0xEF Reserved for future use by the IETF. 0xF0 - 0xFE Allocated for use by the ATM Forum. 0xFF Experimental/Local use.
0火星协议[11]。1本文件中定义的NHRP。0x02-保留0xEF供IETF将来使用。0xF0-分配给ATM论坛使用的0xFE。0xFF实验/本地使用。
ar$op.type When ar$op.version == 1, this is the NHRP packet type: NHRP Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP 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 other protocol development and will be administered by IANA as described in Section 9.
ar$op.type当ar$op.version==1时，这是NHRP数据包类型：NHRP解析请求（1）、NHRP解析回复（2）、NHRP注册请求（3）、NHRP注册回复（4）、NHRP清除请求（5）、NHRP清除回复（6）或NHRP错误指示（7）。128至255范围内NHRP数据包类型的使用保留用于研究或用于其他协议开发，并将由IANA管理，如第9节所述。
ar$shtl Type & length of source NBMA address interpreted in the context of the 'address family number'[6] indicated by ar$afn. See below for more details.
ar$shtl类型和源NBMA地址的长度在ar$afn指示的“地址系列号”[6]的上下文中解释。有关更多详细信息，请参见下文。
ar$sstl Type & length of source NBMA subaddress interpreted in the context of the 'address family number'[6] indicated by ar$afn. When an NBMA technology has no concept of a subaddress, the subaddress length is always coded ar$sstl = 0 and no storage is allocated for the subaddress in the appropriate mandatory part. See below for more details.
ar$sstl类型和源NBMA子地址的长度在ar$afn指示的“地址系列号”[6]的上下文中解释。当NBMA技术没有子地址概念时，子地址长度始终编码为ar$sstl=0，并且在相应的强制部分中没有为子地址分配存储。有关更多详细信息，请参见下文。
Subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr T/L) and subnetwork layer subaddresses type/length fields (e.g., ar$sstl, Cli SAddr T/L) are coded as follows:
子网层地址类型/长度字段（例如ar$shtl、Cli Addr T/L）和子网层子地址类型/长度字段（例如ar$sstl、Cli Addr T/L）的编码如下：
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|0|x| length |
+-+-+-+-+-+-+-+-+
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 address being referred to is in:
最高有效位保留，必须设置为零。第二个最高有效位（x）是一个标志，指示所引用的地址是否位于：
- NSAP format (x = 0). - Native E.164 format (x = 1).
- NSAP格式（x=0）。-本机E.164格式（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.
对于既不使用NSAP也不使用E.164格式地址的NBMA技术，应使用x=0表示特定NBMA技术的本机形式。
If the NBMA network is ATM and a subaddress (e.g., Source NBMA SubAddress, Client NBMA SubAddress) is to be included in any part of the NHRP packet then ar$afn MUST be set to 0x000F; further, the subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr T/L) and subnetwork layer subaddress type/length fields (e.g., ar$sstl, Cli SAddr T/L) MUST be coded as in [11]. If the NBMA network is ATM and no subaddress field is to be included in any part of the NHRP packet then ar$afn MAY be set to 0x0003 (NSAP) or 0x0008 (E.164) accordingly.
如果NBMA网络是ATM，并且子地址（例如，源NBMA子地址、客户端NBMA子地址）将包含在NHRP数据包的任何部分中，则ar$afn必须设置为0x000F；此外，子网层地址类型/长度字段（例如ar$shtl、Cli Addr T/L）和子网层子地址类型/长度字段（例如ar$sstl、Cli Addr T/L）必须按照[11]中所述进行编码。如果NBMA网络是ATM，并且在NHRP分组的任何部分中不包括子地址字段，则ar$afn可相应地设置为0x0003（NSAP）或0x0008（E.164）。
The bottom 6 bits is an unsigned integer value indicating the length of the associated NBMA address in octets. If this value is zero the flag x is ignored.
底部6位是一个无符号整数值，以八位字节表示相关NBMA地址的长度。如果该值为零，则忽略标志x。
The Mandatory Part of the NHRP packet contains the operation specific information (e.g., NHRP Resolution Request/Reply, etc.) and variable length data which is pertinent to the packet type.
NHRP数据包的强制部分包含操作特定信息（例如，NHRP解析请求/回复等）和与数据包类型相关的可变长度数据。
Sections 5.2.1 through 5.2.6 have a very similar mandatory part. This mandatory part includes a common header and zero or more Client Information Entries (CIEs). Section 5.2.7 has a different format which is specified in that section.
第5.2.1节至第5.2.6节有一个非常类似的强制性部分。此必填部分包括一个公共标题和零个或多个客户端信息条目（CIE）。第5.2.7节采用了该节规定的不同格式。
The common header looks like the following:
公共标题如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Proto Len | Dst Proto Len | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Proto Len | Dst Proto Len | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
And the CIEs have the following format:
国际企业间投资协定的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Prefix Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Prefix Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Prefix Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Prefix Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meanings of the fields are as follows:
这些字段的含义如下：
Src Proto Len This field holds the length in octets of the Source Protocol Address.
Src Proto Len此字段保存源协议地址的长度（以八位字节为单位）。
Dst Proto Len This field holds the length in octets of the Destination Protocol Address.
Dst Proto Len此字段保存目标协议地址的长度（以八位字节为单位）。
Flags These flags are specific to the given message type and they are explained in each section.
标志这些标志特定于给定的消息类型，并在每个部分中进行解释。
Request ID A value which, when coupled with the address of the source, provides a unique identifier for the information contained in a "request" packet. This value is copied directly from an "request" packet into the associated "reply". When a sender of a "request" receives "reply", it will compare the Request ID and source address information in the received "reply" against that found in its outstanding "request" list. When a match is found then the "request" is considered to be acknowledged.
请求ID—当与源地址结合时，为“请求”数据包中包含的信息提供唯一标识符的值。该值直接从“请求”数据包复制到相关的“回复”中。当“请求”的发送方收到“回复”时，它会将收到的“回复”中的请求ID和源地址信息与其未完成的“请求”列表中的信息进行比较。当找到匹配项时，“请求”即被视为已确认。
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 when resending a "request", i.e., when a "reply" has not been received for a "request" and a retry is sent after an appropriate interval.
该值取自32位计数器，该计数器在每次传输新“请求”时递增。当重新发送“请求”时，即当尚未收到“请求”的“回复”且在适当间隔后发送重试时，必须使用相同的值。
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).
建议此数字的初始值为0。当且仅当序列号的重用未通过使用特定同步方法（例如，如附录A中所述）而被排除时，节点可重用序列号。
The NBMA address/subaddress form specified below allows combined E.164/NSAPA form of NBMA addressing. For NBMA technologies without a subaddress concept, the subaddress field is always ZERO length and ar$sstl = 0.
下面指定的NBMA地址/子地址形式允许组合E.164/NSAPA形式的NBMA寻址。对于没有子地址概念的NBMA技术，子地址字段的长度始终为零，ar$sstl=0。
Source NBMA Address The Source NBMA address field is the address of the source station 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 all.
源NBMA地址源NBMA地址字段是发送“请求”的源站的地址。如果ar$shtl中指定的字段长度为0，则根本不会为此地址分配存储。
Source NBMA SubAddress The Source NBMA subaddress field is the address of the source station which is sending the "request". If the field's length as specified in ar$sstl is 0 then no storage is allocated for this address at all.
源NBMA子地址源NBMA子地址字段是发送“请求”的源站的地址。如果ar$sstl中指定的字段长度为0，则根本不会为此地址分配存储。
For those NBMA technologies which have a notion of "Calling Party Addresses", the Source NBMA Addresses above are the addresses used when signaling for an SVC.
对于那些具有“主叫方地址”概念的NBMA技术，上述源NBMA地址是为SVC发信号时使用的地址。
"Requests" and "indications" follow the routed path from Source Protocol Address to the Destination Protocol Address. "Replies", on the other hand, follow the routed path from the Destination Protocol Address back to the Source Protocol Address with the following
“请求”和“指示”遵循从源协议地址到目标协议地址的路由路径。另一方面，“应答”则遵循从目标协议地址返回到源协议地址的路由路径，如下所示
exceptions: in the case of a NHRP Registration Reply and in the case of an NHC initiated NHRP Purge Request, the packet is always returned via a direct VC (see Sections 5.2.4 and 5.2.5).
例外情况：对于NHRP注册回复和NHC发起的NHRP清除请求，数据包始终通过直接VC返回（见第5.2.4和5.2.5节）。
Source Protocol Address This is the protocol address of the station which is sending the "request". This is also the protocol address of the station toward which a "reply" packet is sent.
源协议地址这是发送“请求”的站点的协议地址。这也是向其发送“应答”数据包的站点的协议地址。
Destination Protocol Address This is the protocol address of the station toward which a "request" packet is sent.
目标协议地址这是向其发送“请求”数据包的站点的协议地址。
Code This field is message specific. See the relevant message sections below. In general, this field is a NAK code; i.e., when the field is 0 in a reply then the packet is acknowledging a request and if it contains any other value the packet contains a negative acknowledgment.
代码此字段是特定于消息的。请参阅下面的相关信息部分。通常，该字段是NAK代码；i、 例如，当回复中的字段为0时，数据包确认请求，如果包含任何其他值，则数据包包含否定确认。
Prefix Length This field is message specific. See the relevant message sections below. In general, however, this fields is used to indicate that the information carried in an NHRP message pertains to an equivalence class of internetwork layer addresses rather than just a single internetwork layer address specified. All internetwork layer addresses that match the first "Prefix Length" bit positions for the specific internetwork layer address are included in the equivalence class. If this field is set to 0x00 then this field MUST be ignored and no equivalence information is assumed (note that 0x00 is thus equivalent to 0xFF).
前缀长度此字段特定于消息。请参阅下面的相关信息部分。然而，通常，该字段用于指示NHRP消息中携带的信息属于网络层地址的等价类，而不仅仅是指定的单个网络层地址。与特定网络层地址的第一个“前缀长度”位位置匹配的所有网络层地址都包含在等价类中。如果此字段设置为0x00，则必须忽略此字段，并且不假设任何等效信息（请注意，0x00因此等效于0xFF）。
Maximum Transmission Unit This field gives the maximum transmission unit for the relevant client station. If this value is 0 then either the default MTU is used or the MTU negotiated via signaling is used if such negotiation is possible for the given NBMA.
最大传输单位此字段给出相关客户端站的最大传输单位。如果该值为0，则使用默认MTU，或者如果给定NBMA可以协商，则使用通过信令协商的MTU。
Holding Time The Holding Time field specifies the number of seconds for which the Next Hop NBMA information specified in the CIE is considered to be valid. Cached information SHALL be discarded when the holding time expires. This field must be set to 0 on a NAK.
保持时间保持时间字段指定CIE中指定的下一跳NBMA信息被视为有效的秒数。当保存时间到期时，应丢弃缓存的信息。在NAK上，此字段必须设置为0。
Cli Addr T/L Type & length of next hop NBMA address specified in the CIE. This field is interpreted in the context of the 'address family number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for ATM).
Cli Addr T/L CIE中指定的下一跳NBMA地址的类型和长度。该字段在ar$afn指示的“地址系列号”[6]上下文中解释（例如，对于ATM，ar$afn=0x0003）。
Cli SAddr T/L Type & length of next hop NBMA subaddress specified in the CIE. This field is interpreted in the context of the 'address family number'[6] indicated by ar$afn (e.g., ar$afn=0x0015 for ATM makes the address an E.164 and the subaddress an ATM Forum NSAP address). When an NBMA technology has no concept of a subaddress, the subaddress is always null with a length of 0. When the address length is specified as 0 no storage is allocated for the address.
Cli SAddr T/L CIE中指定的下一跳NBMA子地址的类型和长度。该字段在ar$afn指示的“地址系列号”[6]的上下文中解释（例如，对于ATM，ar$afn=0x0015使地址成为e.164，子地址成为ATM论坛NSAP地址）。当NBMA技术没有子地址的概念时，子地址始终为空，长度为0。当地址长度指定为0时，不会为地址分配存储。
Cli Proto Len This field holds the length in octets of the Client Protocol Address specified in the CIE.
Cli Proto Len此字段保存CIE中指定的客户端协议地址的长度（以八位字节为单位）。
Preference This field specifies the preference for use of the specific CIE relative to other CIEs. Higher values indicate higher preference. Action taken when multiple CIEs have equal or highest preference value is a local matter.
首选项此字段指定相对于其他CIE使用特定CIE的首选项。值越高表示偏好越高。当多个CIE具有相同或最高的首选值时所采取的措施是局部问题。
Client NBMA Address This is the client's NBMA address.
客户NBMA地址这是客户的NBMA地址。
Client NBMA SubAddress This is the client's NBMA subaddress.
客户端NBMA子地址这是客户端的NBMA子地址。
Client Protocol Address This is the client's internetworking layer address specified.
客户端协议地址这是指定的客户端网络间层地址。
Note that an NHS may cache source address binding information from an NHRP Resolution Request if and only if the conditions described in Section 6.2 are met for the NHS. In all other cases, source address binding information appearing in an NHRP message MUST NOT be cached.
注意，NHS可以缓存NHRP解析请求中的源地址绑定信息，前提是NHS满足第6.2节中描述的条件。在所有其他情况下，不得缓存NHRP消息中出现的源地址绑定信息。
The NHRP Resolution Request packet has a Type code of 1. Its mandatory part is coded as described in Section 5.2.0.1 and the message specific meanings of the fields are as follows:
NHRP解析请求数据包的类型代码为1。其强制性部分的编码如第5.2.0.1节所述，字段的消息特定含义如下：
Flags - The flags field is coded as follows:
标志-标志字段编码如下：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|D|U|S| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|D|U|S| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q Set if the station sending the NHRP Resolution Request is a router; clear if the it is a host.
如果发送NHRP解析请求的站点是路由器，则设置Q；如果是主机，则清除。
A This bit is set in a NHRP Resolution Request if only authoritative next hop information is desired and is clear otherwise. See the NHRP Resolution Reply section below for further details on the "A" bit and its usage.
如果只需要权威的下一跳信息，则在NHRP解析请求中设置该位，否则清除该位。有关“A”位及其用法的更多详细信息，请参阅下面的NHRP解决方案回复部分。
D Unused (clear on transmit)
D未使用（传输时清除）
U This is the Uniqueness bit. This bit aids in duplicate address detection. When this bit is set in an NHRP Resolution Request and one or more entries exist in the NHS cache which meet the requirements of the NHRP Resolution Request then only the CIE in the NHS's cache with this bit set will be returned. Note that even if this bit was set at registration time, there may still be multiple CIEs that might fulfill the NHRP Resolution Request because an entire subnet can be registered through use of the Prefix Length in the CIE and the address of interest might be within such a subnet. If the "uniqueness" bit is set and the responding NHS has one or more cache entries which match the request but no such cache entry has the "uniqueness" bit set, then the NHRP Resolution Reply returns with a NAK code of "13 - Binding Exists But Is Not Unique" and no CIE is included. If a client wishes to receive non- unique Next Hop Entries, then the client must have the "uniqueness" bit set to zero in its NHRP Resolution Request. Note that when this bit is set in an NHRP Registration Request, only a single CIE may be specified in the NHRP Registration Request and that CIE must have the Prefix Length field set to 0xFF.
这是唯一性。此位有助于重复地址检测。当该位在NHRP解析请求中设置，且NHS缓存中存在一个或多个符合NHRP解析请求要求的条目时，仅返回NHS缓存中具有该位设置的CIE。注意，即使在注册时设置了该位，也可能存在多个可能满足NHRP解析请求的CIE，因为可以通过使用CIE中的前缀长度注册整个子网，并且感兴趣的地址可能在这样的子网内。如果设置了“唯一性”位，且响应NHS具有一个或多个与请求匹配的缓存项，但没有此类缓存项设置了“唯一性”位，则NHRP解析应答返回的NAK代码为“13-绑定存在但不唯一”，且不包括CIE。如果客户端希望接收非唯一的下一跳条目，那么客户端必须在其NHRP解析请求中将“唯一性”位设置为零。注意，当在NHRP注册请求中设置该位时，在NHRP注册请求中只能指定一个CIE，并且CIE必须将前缀长度字段设置为0xFF。
S Set if the binding between the Source Protocol Address and the Source NBMA information in the NHRP Resolution Request is guaranteed to be stable and accurate (e.g., these addresses are those of an ingress router which is connected to an ethernet stub network or the NHC is an NBMA attached host).
如果保证NHRP解析请求中的源协议地址和源NBMA信息之间的绑定稳定且准确（例如，这些地址是连接到以太网存根网络的入口路由器的地址或NHC是连接NBMA的主机的地址），则设置。
Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP Resolution Request. If one is specified then that entry carries the pertinent information for the client sourcing the NHRP Resolution Request. Usage of the CIE in the NHRP Resolution Request is described below:
NHRP解决方案请求中可以指定零个或一个CIE（见第5.2.0.1节）。如果指定了一个条目，则该条目包含了寻求NHRP解决方案请求的客户的相关信息。NHRP解决方案请求中CIE的使用说明如下：
Prefix Length If a CIE is specified in the NHRP Resolution Request then the Prefix Length field may be used to qualify the widest acceptable prefix which may be used to satisfy the NHRP Resolution Request. In the case of NHRP Resolution Request/Reply, the Prefix Length specifies the equivalence class of addresses which match the first "Prefix Length" bit positions of the Destination Protocol Address. If the "U" bit is set in the common header then this field MUST be set to 0xFF.
前缀长度如果在NHRP解析请求中指定了CIE，则前缀长度字段可用于限定可用于满足NHRP解析请求的最宽可接受前缀。在NHRP解析请求/应答的情况下，前缀长度指定与目标协议地址的第一个“前缀长度”位位置匹配的地址的等价类。如果在公共标头中设置了“U”位，则该字段必须设置为0xFF。
Maximum Transmission Unit This field gives the maximum transmission unit for the source station. A possible use of this field in the NHRP Resolution Request packet is for the NHRP Resolution Requester to ask for a target MTU.
最大传输单位该字段给出源站的最大传输单位。NHRP解析请求包中此字段的一个可能用途是NHRP解析请求者请求目标MTU。
Holding Time The Holding Time specified in the one CIE permitted to be included in an NHRP Resolution Request is the amount of time which the source address binding information in the NHRP Resolution Request is permitted to cached by transit and responding NHSs. Note that this field may only have a non-zero value if the S bit is set.
保持时间允许包含在NHRP解析请求中的一个CIE中指定的保持时间是允许传输和响应NHS缓存NHRP解析请求中的源地址绑定信息的时间量。请注意，如果设置了S位，则此字段可能只有非零值。
All other fields in the CIE MUST be ignored and SHOULD be set to 0.
必须忽略CIE中的所有其他字段，并将其设置为0。
The Destination Protocol Address in the common header of the Mandatory Part of this message contains the protocol address of the station for which resolution is desired. An NHC MUST send the NHRP Resolution Request directly to one of its serving NHSs (see Section 3 for more information).
此消息的强制部分的公共标头中的目标协议地址包含需要解析的站点的协议地址。NHC必须将NHRP解决请求直接发送给其服务NHS之一（更多信息请参见第3节）。
The NHRP Resolution Reply packet has a Type code of 2. CIEs correspond to Next Hop Entries in an NHS's cache which match the criteria in the NHRP Resolution Request. Its mandatory part is coded as described in Section 5.2.0.1. The message specific meanings of the fields are as follows:
NHRP解析应答包的类型代码为2。CIE对应于NHS缓存中与NHRP解析请求中的标准匹配的下一跳条目。其强制性部分的编码如第5.2.0.1节所述。字段的消息特定含义如下所示：
Flags - The flags field is coded as follows:
标志-标志字段编码如下：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|D|U|S| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|D|U|S| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q Copied from the NHRP Resolution Request. Set if the NHRP Resolution Requester is a router; clear if it is a host.
Q从NHRP解决方案请求中复制。设置NHRP解析请求者是否为路由器；如果它是主机，则清除。
A Set if the next hop CIE in the NHRP Resolution Reply is authoritative; clear if the NHRP Resolution Reply is non-authoritative.
如果NHRP解析应答中的下一跳CIE是权威的，则设置；如果NHRP决议回复是非权威性的，则清除。
When an NHS receives a NHRP Resolution Request for authoritative information for which it is the authoritative source, it MUST respond with a NHRP Resolution Reply containing all and only those next hop CIEs which are contained in the NHS's cache which both match the criteria of the NHRP Resolution Request and are authoritative cache entries. An NHS is an authoritative source for a NHRP Resolution Request if the information in the NHS's cache matches the NHRP Resolution Request criteria and that information was obtained through a NHRP Registration Request or through synchronization with an NHS which obtained this information through a NHRP Registration Request. An authoritative cache entry is one which is obtained through a NHRP Registration Request or through synchronization with an NHS which obtained this information through a NHRP Registration Request.
当NHS收到其作为权威来源的权威信息的NHRP解析请求时，它必须以NHRP解析回复进行响应，该回复包含NHS缓存中包含的所有且仅包含符合NHRP解析请求标准且为权威缓存项的下一跳CIE。如果NHS缓存中的信息与NHRP解析请求标准匹配，并且该信息是通过NHRP注册请求或通过与NHS同步获得的，则NHS是NHRP解析请求的权威来源，NHS通过NHRP注册请求获得该信息。权威缓存条目是通过NHRP注册请求或通过与通过NHRP注册请求获得该信息的NHS同步而获得的条目。
An NHS obtains non-authoritative CIEs through promiscuous listening to NHRP packets other than NHRP Registrations which are directed at it. A NHRP Resolution Request which indicates a request for non-authoritative information should cause a NHRP Resolution Reply which contains all entries in the replying NHS's cache (i.e., both authoritative and non-authoritative) which match the criteria specified in the request.
NHS通过乱听NHRP数据包获得非权威CIE，而非针对其的NHRP注册。表示非权威信息请求的NHRP解析请求应导致NHRP解析回复，该回复包含回复NHS缓存中的所有条目（即权威和非权威），这些条目与请求中指定的标准相匹配。
D Set if the association between destination and the associate next hop information included in all CIEs of the NHRP Resolution Reply is guaranteed to be stable for the lifetime of the information (the holding time). This is the case if the Next Hop protocol address in a CIE identifies the destination (though it may be different in value than the Destination address if the destination system has multiple addresses) or if the destination is not connected directly to the NBMA subnetwork but the egress router to that destination is guaranteed to be stable (such as
D如果目标和包括在NHRP解析应答的所有CIE中的关联下一跳信息之间的关联保证在信息的生命周期（保持时间）内是稳定的，则设置。如果CIE中的下一跳协议地址标识目的地（尽管如果目的地系统具有多个地址，则其值可能不同于目的地地址），或者如果目的地未直接连接到NBMA子网，但到该目的地的出口路由器被保证是稳定的，则会出现这种情况（例如
when the destination is immediately adjacent to the egress router through a non-NBMA interface).
当目的地通过非NBMA接口与出口路由器相邻时）。
U This is the Uniqueness bit. See the NHRP Resolution Request section above for details. When this bit is set, only one CIE is included since only one unique binding should exist in an NHS's cache.
这是唯一性。有关详细信息，请参见上面的NHRP解决方案请求部分。当设置此位时，仅包括一个CIE，因为NHS缓存中只应存在一个唯一绑定。
S Copied from NHRP Resolution Request message.
从NHRP解析请求消息复制的。
One or more CIEs are specified in the NHRP Resolution Reply. Each CIE contains NHRP next hop information which the responding NHS has cached and which matches the parameters specified in 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 set appropriately (see below) and all other fields MUST be ignored and SHOULD be set to 0. In order to facilitate the use of NHRP by minimal client implementations, the first CIE MUST contain the next hop with the highest preference value so that such an implementation need parse only a single CIE.
NHRP决议回复中规定了一个或多个CIE。每个CIE包含NHRP下一跳信息，响应的NHS缓存了该信息，该信息与NHRP解析请求中指定的参数匹配。若发布NHRP决议回复的NHS并没有发现匹配项，那个么一个CIE将被适当地包含在一个CIE代码集中（见下文），所有其他字段都必须被忽略，并且应该设置为0。为了通过最少的客户端实现促进NHRP的使用，第一个CIE必须包含具有最高偏好值的下一个跃点，以便这样的实现只需要解析单个CIE。
Code If this field is set to zero then this packet contains a positively acknowledged NHRP Resolution Reply. If this field contains any other value then this message contains an NHRP Resolution Reply NAK which means that an appropriate internetworking layer to NBMA address binding was not available in the responding NHS's cache. If NHRP Resolution Reply contains a Client Information Entry with a NAK Code other than 0 then it MUST NOT contain any other CIE. Currently defined NAK Codes are as follows:
代码如果此字段设置为零，则此数据包包含肯定确认的NHRP解析回复。如果此字段包含任何其他值，则此消息包含NHRP Resolution Reply NAK，这意味着响应NHS的缓存中没有合适的网络互连层到NBMA地址绑定。如果NHRP Resolution Reply包含NAK代码不是0的客户端信息条目，则它不得包含任何其他CIE。目前定义的NAK代码如下：
4 - Administratively Prohibited
4-行政禁止
An NHS may refuse an NHRP Resolution Request attempt for administrative reasons (due to policy constraints or routing state). If so, the NHS MUST send an NHRP Resolution Reply which contains a NAK code of 4.
NHS可出于管理原因（由于政策约束或路由状态）拒绝NHRP解决请求尝试。如果是这样，NHS必须发送NHRP决议回复，其中包含NAK代码4。
5 - Insufficient Resources
5-资源不足
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 routing changes), the NHS MUST reply with a NAKed NHRP Resolution Reply which contains a NAK code of 5.
如果NHS由于缺乏资源而无法为站点提供服务（例如，如果路由发生变化，无法存储足够的信息来发送清除），NHS必须使用包含NAK代码5的裸NHRP解析回复进行回复。
12 - No Internetworking Layer Address to NBMA Address Binding Exists
12-不存在网络间层地址到NBMA地址绑定
This code states that there were absolutely no internetworking layer address to NBMA address bindings found in the responding NHS's cache.
该代码表示，在响应的NHS缓存中，绝对没有找到网络间层地址到NBMA地址的绑定。
13 - Binding Exists But Is Not Unique
13-绑定存在，但不是唯一的
This code states that there were one or more internetworking layer address to NBMA address bindings found in the responding NHS's cache, however none of them had the uniqueness bit set.
此代码表示在响应的NHS缓存中找到了一个或多个网络间层地址到NBMA地址绑定，但是没有一个具有唯一性位集。
Prefix Length In the case of NHRP Resolution Reply, the Prefix Length specifies the equivalence class of addresses which match the first "Prefix Length" bit positions of the Destination Protocol Address.
前缀长度在NHRP解析应答的情况下，前缀长度指定与目标协议地址的第一个“前缀长度”位位置匹配的地址的等价类。
Holding Time The Holding Time specified in a CIE of an NHRP Resolution Reply is the amount of time remaining before the expiration of the client information which is cached at the replying NHS. It is not the value which was registered by the client.
等待时间NHRP解析回复的CIE中指定的等待时间是在回复NHS中缓存的客户端信息到期之前剩余的时间量。它不是客户端注册的值。
The remainder of the fields for the CIE for each next hop are filled out as they were defined when the next hop was registered with the responding NHS (or one of the responding NHS's synchronized servers) via the NHRP Registration Request.
每个下一个跃点的CIE的其余字段在下一个跃点通过NHRP注册请求向响应NHS（或响应NHS的同步服务器之一）注册时按照定义填写。
Load-splitting may be performed when more than one Client Information Entry is returned to a requester when equal preference values are specified. Also, the alternative addresses may be used in case of connectivity failure in the NBMA subnetwork (such as a failed call attempt in connection-oriented NBMA subnetworks).
当指定相同的首选项值时，当向请求者返回多个客户端信息条目时，可以执行负载拆分。此外，在NBMA子网中的连接故障（例如面向连接的NBMA子网中的失败呼叫尝试）的情况下，可以使用替代地址。
Any extensions present in the NHRP Resolution Request packet MUST be present in the NHRP Resolution Reply even if the extension is non-Compulsory.
NHRP解析请求包中存在的任何扩展必须存在于NHRP解析回复中，即使该扩展是非强制性的。
If an unsolicited NHRP Resolution Reply packet is received, an Error Indication of type Invalid NHRP Resolution Reply Received SHOULD be sent in response.
如果收到未经请求的NHRP解析回复数据包，则应发送接收到的无效NHRP解析回复类型的错误指示作为响应。
When an NHS that serves a given NHC receives an NHRP Resolution Reply destined for that NHC then the NHS must MUST send the NHRP Resolution Reply directly to the NHC (see Section 3).
当为给定NHC提供服务的NHS收到目的地为该NHC的NHRP决议回复时，NHS必须直接向NHC发送NHRP决议回复（见第3节）。
The NHRP Registration Request is sent from a station to an NHS to notify the NHS of the station's NBMA information. It has a Type code of 3. Each CIE corresponds to Next Hop information which is to be cached at an NHS. The mandatory part of an NHRP Registration Request is coded as described in Section 5.2.0.1. The message specific meanings of the fields are as follows:
NHRP注册请求从电台发送至NHS，以通知NHS电台的NBMA信息。它的类型代码为3。每个CIE对应于要在NHS中缓存的下一跳信息。NHRP注册申请的强制性部分编码如第5.2.0.1节所述。字段的消息特定含义如下所示：
Flags - The flags field is coded as follows:
标志-标志字段编码如下：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U This is the Uniqueness bit. When set in an NHRP Registration Request, this bit indicates that the registration of the protocol address is unique within the confines of the set of synchronized NHSs. This "uniqueness" qualifier MUST be stored in the NHS/NHC cache. Any attempt to register a binding between the protocol address and an NBMA address when this bit is set MUST be rejected with a Code of "14 - Unique Internetworking Layer Address Already Registered" if the replying NHS already has a cache entry for the protocol address and the cache entry has the "uniqueness" bit set. A registration of a CIE's information is rejected when the CIE is returned with the Code field set to anything other than 0x00. See the description of the uniqueness bit in NHRP Resolution Request section above for further details. When this bit is set only, only one CIE MAY be included in the NHRP Registration Request.
这是唯一性。当在NHRP注册请求中设置时，该位表示协议地址的注册在同步NHS集的范围内是唯一的。此“唯一性”限定符必须存储在NHS/NHC缓存中。如果应答NHS已经为协议地址设置了缓存项，并且缓存项设置了“唯一性”位，则在设置此位时，任何在协议地址和NBMA地址之间注册绑定的尝试都必须被拒绝，代码为“14-唯一的网络互连层地址已注册”。当返回CIE时，将代码字段设置为0x00以外的任何值，则拒绝注册CIE的信息。有关更多详细信息，请参见上文NHRP分辨率请求部分中唯一性位的描述。当仅设置该位时，NHRP注册请求中只能包括一个CIE。
Request ID The request ID has the same meaning as described in Section 5.2.0.1. However, the request ID for NHRP Registrations which is maintained at each client MUST be kept in non-volatile memory so that when a client crashes and reregisters there will be no inconsistency in the NHS's database. In order to reduce the overhead associated with updating non-volatile memory, the actual updating need not be done with every increment of the Request ID but could be done, for example, every 50 or 100 increments. In this scenario, when a client crashes and reregisters it knows to add 100 to the value of the Request ID in the non-volatile memory before using the Request ID for subsequent registrations.
请求ID请求ID的含义与第5.2.0.1节所述相同。但是，每个客户端上维护的NHRP注册请求ID必须保存在非易失性内存中，以便当客户端崩溃并重新注册时，NHS数据库中不会出现不一致的情况。为了减少与更新非易失性存储器相关联的开销，实际更新不需要以请求ID的每一增量进行，而是可以例如每50或100增量进行一次。在这种情况下，当客户端崩溃并重新注册时，它知道在使用请求ID进行后续注册之前，在非易失性内存中向请求ID的值添加100。
One or more CIEs are specified in the NHRP Registration Request. Each CIE contains next hop information which a client is attempting to register with its servers. Generally, all fields in CIEs enclosed in NHRP Registration Requests are coded as described in Section 5.2.0.1. However, if a station is only registering itself with the NHRP Registration Request then it MAY code the Cli Addr T/L, Cli SAddr T/L, and Cli Proto Len as zero which signifies that the client address information is to be taken from the source information in the common header (see Section 5.2.0.1). Below, further clarification is given for some fields in a CIE in the context of a NHRP Registration Request.
NHRP注册请求中指定了一个或多个CIE。每个CIE都包含客户端试图向其服务器注册的下一跳信息。通常，NHRP注册请求中包含的CIEs中的所有字段都按照第5.2.0.1节的说明进行编码。但是，如果站点仅向NHRP注册请求注册自身，则它可能会将Cli Addr T/L、Cli SAddr T/L和Cli Proto Len编码为零，这表示客户端地址信息将取自公共标头中的源信息（请参阅第5.2.0.1节）。下面，在NHRP注册请求的背景下，对CIE中的一些字段进行了进一步澄清。
Code This field is set to 0x00 in NHRP Registration Requests.
代码在NHRP注册请求中，此字段设置为0x00。
Prefix Length
前缀长度
This field may be used in a NHRP Registration Request to register equivalence information for the Client Protocol Address specified in the CIE of an NHRP Registration Request In the case of NHRP Registration Request, the Prefix Length specifies the equivalence class of addresses which match the first "Prefix Length" bit positions of the Client Protocol Address. If the "U" bit is set in the common header then this field MUST be set to 0xFF.
该字段可在NHRP注册请求中用于注册NHRP注册请求的CIE中指定的客户端协议地址的等效信息。在NHRP注册请求的情况下，前缀长度指定与第一个“前缀长度”匹配的地址的等效类客户端协议地址的位位置。如果在公共标头中设置了“U”位，则该字段必须设置为0xFF。
The NHRP Registration Request is used to register an NHC's NHRP information with its NHSs. If an NHC is configured with the protocol address of a serving NHS then the NHC may place the NHS's protocol address in the Destination Protocol Address field of the NHRP Registration Request common header otherwise the NHC must place its own protocol address in the Destination Protocol Address field.
NHRP注册请求用于向NHS注册NHC的NHRP信息。如果NHC配置了服务NHS的协议地址，则NHC可以将NHS的协议地址放在NHRP注册请求公共报头的目的地协议地址字段中，否则NHC必须将其自己的协议地址放在目的地协议地址字段中。
When an NHS receives an NHRP Registration Request which has the Destination Protocol Address field set to an address which belongs to a LIS/LAG for which the NHS is serving then if the Destination Protocol Address field is equal to the Source Protocol Address field (which would happen if the NHC put its protocol address in the Destination Protocol Address) or the Destination Protocol Address field is equal to the protocol address of the NHS then the NHS processes the NHRP Registration Request after doing appropriate error checking (including any applicable policy checking).
当NHS收到NHRP注册请求时，其目的地协议地址字段设置为属于NHS所服务的LIS/LAG的地址，则如果目的地协议地址字段等于源协议地址字段（如果NHC将其协议地址放在目标协议地址中，则会发生这种情况）或者目标协议地址字段等于NHS的协议地址，则NHS在进行适当的错误检查（包括任何适用的策略检查）后处理NHRP注册请求。
When an NHS receives an NHRP Registration Request which has the Destination Protocol Address field set to an address which does not belong to a LIS/LAG for which the NHS is serving then the NHS forwards the packet down the routed path toward the appropriate LIS/LAG.
当NHS接收到NHRP注册请求时，其目的地协议地址字段设置为不属于NHS所服务的LIS/LAG的地址，则NHS沿着路由路径将数据包转发到适当的LIS/LAG。
When an NHS receives an NHRP Registration Request which has the Destination Protocol Address field set to an address which belongs to a LIS/LAG for which the NHS is serving then if the Destination Protocol Address field does not equal the Source Protocol Address field and the Destination Protocol Address field does not equal the protocol address of the NHS then the NHS forwards the message to the appropriate NHS within the LIS/LAG as specified by Destination Protocol Address field.
当NHS收到NHRP注册请求时，其目的地协议地址字段设置为属于NHS所服务的LIS/LAG的地址，则如果目的地协议地址字段不等于源协议地址字段，且目的地协议地址字段不等于协议地址然后，NHS将消息转发给目标协议地址字段指定的LIS/LAG中的相应NHS。
It is possible that a misconfigured station will attempt to register with the wrong NHS (i.e., one that cannot serve it due to policy constraints or routing state). If this is the case, the NHS MUST reply with a NAK-ed Registration Reply of type Can't Serve This Address.
配置错误的站点可能会尝试向错误的NHS注册（即，由于策略限制或路由状态而无法为其提供服务的站点）。如果是这种情况，NHS必须回复一个NAK ed注册回复，类型为“无法送达此地址”。
If an NHS cannot serve a station due to a lack of resources, the NHS MUST reply with a NAK-ed Registration Reply of type Registration Overflow.
如果NHS由于缺乏资源而无法为电台提供服务，NHS必须以注册溢出类型的NAK ed注册回复进行回复。
In order to keep the registration entry from being discarded, the station MUST re-send the NHRP Registration Request packet often enough to refresh the registration, even in the face of occasional packet loss. It is recommended that the NHRP Registration Request packet be sent at an interval equal to one-third of the Holding Time specified therein.
为了防止注册条目被丢弃，站点必须经常重新发送NHRP注册请求数据包，以刷新注册，即使偶尔遇到数据包丢失。建议以等于其中规定的保持时间的三分之一的间隔发送NHRP注册请求包。
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 CIE in the NHRP Registration Reply has anything other than zero in it then the NHRP Registration Reply is a NAK otherwise the reply is an ACK. The NHRP Registration Reply has a Type code of 4.
NHRP注册回复由NHS发送给客户，以响应该客户的NHRP注册请求。如果NHRP注册回复中CIE的代码字段中有除零以外的任何内容，则NHRP注册回复为NAK，否则回复为ACK。NHRP注册回复的类型代码为4。
An NHRP Registration Reply is formed from an NHRP Registration Request by changing the type code to 4, updating the CIE Code field, and filling in the appropriate extensions if they exist. The message specific meanings of the fields are as follows:
通过将类型代码更改为4，更新CIE代码字段，并填写适当的扩展名（如果存在），从NHRP注册请求生成NHRP注册回复。字段的消息特定含义如下所示：
Attempts to register the information in the CIEs of an NHRP Registration Request may fail for various reasons. If this is the case then each failed attempt to register the information in a CIE of an NHRP Registration Request is logged in the associated NHRP Registration Reply by setting the CIE Code field to the appropriate error code as shown below:
由于各种原因，尝试在NHRP注册请求的CIEs中注册信息可能会失败。如果是这种情况，则通过将CIE Code字段设置为适当的错误代码，在NHRP注册请求的CIE中注册信息的每次失败尝试都会记录在相关的NHRP注册回复中，如下所示：
CIE Code
CIE代码
0 - Successful Registration
0-成功注册
The information in the CIE was successfully registered with the NHS.
CIE中的信息已成功向NHS注册。
4 - Administratively Prohibited
4-行政禁止
An NHS may refuse an NHRP Registration Request attempt for administrative reasons (due to policy constraints or routing state). If so, the NHS MUST send an NHRP Registration Reply which contains a NAK code of 4.
NHS可出于管理原因（由于政策约束或路由状态）拒绝NHRP注册请求尝试。如果是这样，NHS必须发送NHRP注册回复，其中包含NAK代码4。
5 - Insufficient Resources
5-资源不足
If an NHS cannot serve a station due to a lack of resources, the NHS MUST reply with a NAKed NHRP Registration Reply which contains a NAK code of 5.
如果NHS由于缺乏资源而无法为电台提供服务，NHS必须以包含NAK代码5的裸NHRP注册回复进行回复。
14 - Unique Internetworking Layer Address Already Registered If a client tries to register a protocol address to NBMA address binding with the uniqueness bit on and the protocol address already exists in the NHS's cache then if that cache entry also has the uniqueness bit on then this NAK Code is returned in the CIE in the NHRP Registration Reply.
14-唯一的网络互连层地址已注册如果客户端尝试将协议地址注册到NBMA地址绑定，且唯一性位为on，且协议地址已存在于NHS缓存中，则如果该缓存条目也具有唯一性位为on，则该NAK代码将在NHRP注册回复的CIE中返回。
Due to the possible existence of asymmetric routing, an NHRP Registration Reply may not be able to merely follow the routed path back to the source protocol address specified in the common header of the NHRP Registration Reply. As a result, there MUST exist a direct NBMA level connection between the NHC and its NHS on which to send the NHRP Registration Reply before NHRP Registration Reply may be returned to the NHC. If such a connection does not exist then the NHS must setup such a connection to the NHC by using the source NBMA information supplied in the common header of the NHRP Registration Request.
由于可能存在非对称路由，NHRP注册应答可能无法仅沿着路由路径返回到NHRP注册应答的公共报头中指定的源协议地址。因此，NHC与其NHS之间必须存在直接的NBMA级连接，以便在NHRP注册回复返回NHC之前发送NHRP注册回复。如果这种连接不存在，那么NHS必须通过使用NHRP注册请求的公共报头中提供的源NBMA信息来建立与NHC的这种连接。
The NHRP Purge Request packet is sent in order to invalidate cached information in a station. The NHRP Purge Request packet has a type code of 5. The mandatory part of an NHRP Purge Request is coded as described in Section 5.2.0.1. The message specific meanings of the fields are as follows:
发送NHRP清除请求数据包是为了使站点中的缓存信息无效。NHRP清除请求数据包的类型代码为5。NHRP吹扫请求的强制性部分编码如第5.2.0.1节所述。字段的消息特定含义如下所示：
Flags - The flags field is coded as follows:
标志-标志字段编码如下：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N When set, this bit tells the receiver of the NHRP Purge Request that the requester does not expect to receive an NHRP Purge Reply. If an unsolicited NHRP Purge Reply is received by a station where that station is identified in the Source Protocol Address of the packet then that packet must be ignored.
N设置时，该位告知NHRP清除请求的接收者，请求者不希望收到NHRP清除回复。如果在数据包的源协议地址中标识该站的站点收到未经请求的NHRP清除回复，则必须忽略该数据包。
One or more CIEs are specified in the NHRP Purge Request. Each CIE contains next hop information which is to be purged from an NHS/NHC cache. Generally, all fields in CIEs enclosed in NHRP Purge Requests are coded as described in Section 5.2.0.1. Below, further clarification is given for some fields in a CIE in the context of a NHRP Purge Request.
NHRP清除请求中指定了一个或多个CIE。每个CIE包含要从NHS/NHC缓存中清除的下一跳信息。通常，NHRP吹扫请求中包含的CIEs中的所有字段都按照第5.2.0.1节所述进行编码。下面，在NHRP清除请求的上下文中，对CIE中的一些字段进行了进一步的说明。
Code This field is set to 0x00 in NHRP Purge Requests.
代码在NHRP清除请求中，此字段设置为0x00。
Prefix Length
前缀长度
In the case of NHRP Purge Requests, the Prefix Length specifies the equivalence class of addresses which match the first "Prefix Length" bit positions of the Client Protocol Address specified in the CIE. All next hop information which contains a protocol address which matches an element of this equivalence class is to be purged from the receivers cache.
在NHRP清除请求的情况下，前缀长度指定与CIE中指定的客户端协议地址的第一个“前缀长度”位位置相匹配的地址的等价类。所有包含与该等价类元素匹配的协议地址的下一跳信息都将从接收器缓存中清除。
The Maximum Transmission Unit and Preference fields of the CIE are coded as zero. The Holding Time should be coded as zero but there may be some utility in supplying a "short" holding time to be applied to the matching next hop information before that information would be purged; this usage is for further study. The Client Protocol Address field and the Cli Proto Len field MUST be filled in. The Client Protocol Address is filled in with the protocol address to be purged from the receiving station's cache while the Cli Proto Len is set the length of the purged client's protocol address. All remaining fields in the CIE MAY be set to zero although the client NBMA information (and associated length fields) MAY be specified to narrow the scope of the NHRP Purge Request if requester desires. However, the receiver of an NHRP Purge Request may choose to ignore the Client NBMA information if it is supplied.
CIE的最大传输单位和首选字段编码为零。保持时间应编码为零，但在清除该信息之前，提供“短”保持时间以应用于匹配的下一跳信息可能有一些实用性；此用法有待进一步研究。必须填写“客户端协议地址”字段和“Cli协议”字段。客户端协议地址由要从接收站缓存中清除的协议地址填充，而Cli协议则设置清除的客户端协议地址的长度。CIE中的所有剩余字段可以设置为零，尽管如果请求者需要，可以指定客户端NBMA信息（和相关的长度字段）以缩小NHRP清除请求的范围。然而，如果提供了客户端NBMA信息，则NHRP清除请求的接收者可以选择忽略该信息。
An NHRP Purge Request packet is sent from an NHS to a station to cause it to delete previously cached information. This is done when the information may be no longer valid (typically when the NHS has previously provided next hop information for a station that is not directly connected to the NBMA subnetwork, and the egress point to that station may have changed).
NHRP清除请求数据包从NHS发送到站点，使其删除先前缓存的信息。当信息可能不再有效时（通常当NHS先前已为未直接连接到NBMA子网的站点提供下一跳信息，并且到该站点的出口点可能已改变时），可执行此操作。
An NHRP Purge Request packet may also be sent from an NHC to an NHS with which the NHC had previously registered. This allows for an NHC to invalidate its registration with NHRP before it would otherwise expire via the holding timer. If an NHC does not have knowledge of a protocol address of a serving NHS then the NHC must place its own protocol address in the Destination Protocol Address field and forward the packet along the routed path. Otherwise, the NHC must place the protocol address of a serving NHS in this field.
NHRP清除请求包也可以从NHC发送到NHC先前注册的NHS。这允许NHC在NHRP注册失效之前，通过保持计时器使其失效。如果NHC不知道服务NHS的协议地址，则NHC必须将其自己的协议地址放在目的地协议地址字段中，并沿路由路径转发数据包。否则，NHC必须将服务NHS的协议地址放在该字段中。
Serving NHSs may need to send one or more new NHRP Purge Requests as a result of receiving a purge from one of their served NHCs since the NHS may have previously responded to NHRP Resolution Requests for that NHC's NBMA information. These purges are "new" in that they are sourced by the NHS and not the NHC; that is, for each NHC that previously sent a NHRP Resolution Request for the purged NHC NBMA information, an NHRP Purge Request is sent which contains the Source Protocol/NBMA Addresses of the NHS and the Destination Protocol Address of the NHC which previously sent an NHRP Resolution Request prior to the purge.
服务NHS可能需要发送一个或多个新的NHRP清除请求，因为NHS可能已经对NHC的NBMA信息的NHRP解决请求作出了响应，因此从其服务NHC之一接收到清除请求。这些清洗是“新的”，因为它们是由NHS而不是NHC采购的；也就是说，对于先前发送针对清除的NHC NBMA信息的NHRP解析请求的每个NHC，发送NHRP清除请求，其包含NHS的源协议/NBMA地址和先前在清除之前发送NHRP解析请求的NHC的目标协议地址。
The station sending the NHRP Purge Request MAY periodically retransmit the NHRP Purge Request until either NHRP Purge Request is acknowledged or until the holding time of the information being purged has expired. Retransmission strategies for NHRP Purge Requests are a local matter.
发送NHRP清除请求的站点可定期重新发送NHRP清除请求，直到确认NHRP清除请求或待清除信息的保留时间到期。NHRP清除请求的重传策略是本地事务。
When a station receives an NHRP Purge Request, it MUST discard any previously cached information that matches the information in the CIEs.
当站点收到NHRP清除请求时，它必须丢弃与CIEs中的信息匹配的任何先前缓存的信息。
An NHRP Purge Reply MUST be returned for the NHRP Purge Request even if the station does not have a matching cache entry assuming that the "N" bit is off in the NHRP Purge Request.
假设NHRP清除请求中的“N”位为off，即使站点没有匹配的缓存条目，也必须为NHRP清除请求返回NHRP清除回复。
If the station wishes to reestablish communication with the destination shortly after receiving an NHRP Purge Request, it should make an authoritative NHRP Resolution Request in order to avoid any stale cache entries that might be present in intermediate NHSs (See section 6.2.2.). It is recommended that authoritative NHRP Resolution Requests be made for the duration of the holding time of the old information.
如果电厂希望在收到NHRP清除请求后不久重新与目的地建立通信，则应发出权威的NHRP解决请求，以避免中间NHS中可能存在的任何过时缓存条目（见第6.2.2节）。建议在旧信息保存期间提出权威性NHRP解决方案请求。
The NHRP Purge Reply packet is sent in order to assure the sender of an NHRP Purge Request that all cached information of the specified type has been purged from the station sending the reply. The NHRP Purge Reply has a type code of 6.
发送NHRP清除回复数据包是为了确保NHRP清除请求的发送方已从发送回复的站点清除指定类型的所有缓存信息。NHRP吹扫回复的类型代码为6。
An NHRP Purge Reply is formed from an NHRP Purge Request by merely changing the type code in the request to 6. The packet is then returned to the requester after filling in the appropriate extensions if they exist.
仅通过将请求中的类型代码更改为6，就可以从NHRP清除请求形成NHRP清除回复。如果存在适当的扩展名，则在填充这些扩展名之后，数据包将返回给请求者。
The NHRP Error Indication is used to convey error indications to the sender of an NHRP packet. It has a type code of 7. The Mandatory Part has the following format:
NHRP错误指示用于向NHRP分组的发送者传送错误指示。它的类型代码为7。强制性部分的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Proto Len | Dst Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Error Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents of NHRP Packet in error (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Proto Len | Dst Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Error Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents of NHRP Packet in error (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src Proto Len This field holds the length in octets of the Source Protocol Address.
Src Proto Len此字段保存源协议地址的长度（以八位字节为单位）。
Dst Proto Len This field holds the length in octets of the Destination Protocol Address.
Dst Proto Len此字段保存目标协议地址的长度（以八位字节为单位）。
Error Code An error code indicating the type of error detected, chosen from the following list:
错误代码指示检测到的错误类型的错误代码，从以下列表中选择：
1 - Unrecognized Extension
1-无法识别的扩展名
When the Compulsory bit of an extension in NHRP packet is set, the NHRP packet cannot be processed unless the extension has been processed. The responder MUST return an NHRP Error Indication of type Unrecognized Extension if it is incapable of processing the extension. However, if a transit NHS (one which is not going to generate a reply) detects an unrecognized extension, it SHALL ignore the extension.
当设置了NHRP数据包中扩展的强制位时，除非扩展已被处理，否则无法处理NHRP数据包。如果响应程序无法处理扩展，则必须返回类型为Unrecogned Extension的NHRP错误指示。但是，如果公交NHS（不会生成回复的）检测到无法识别的分机，则应忽略该分机。
3 - NHRP Loop Detected
3-检测到NHRP回路
A Loop Detected error is generated when it is determined that an NHRP packet is being forwarded in a loop.
当确定NHRP包正在环路中转发时，生成环路检测错误。
6 - Protocol Address Unreachable
6-无法访问协议地址
This error occurs when a packet it moving along the routed path and it reaches a point such that the protocol address of interest is not reachable.
当数据包沿着路由路径移动并且到达无法到达感兴趣的协议地址的点时，就会发生此错误。
7 - Protocol Error
7-协议错误
A generic packet processing error has occurred (e.g., invalid version number, invalid protocol type, failed checksum, etc.)
发生一般数据包处理错误（例如，版本号无效、协议类型无效、校验和失败等）
8 - NHRP SDU Size Exceeded
8-超出NHRP SDU大小
If the SDU size of the NHRP packet exceeds the MTU size of the NBMA network then this error is returned.
如果NHRP数据包的SDU大小超过NBMA网络的MTU大小，则返回此错误。
9 - Invalid Extension
9-无效的扩展名
If an NHS finds an extension in a packet which is inappropriate for the packet type, an error is sent back to the sender with Invalid Extension as the code.
如果NHS在数据包中发现不适合该数据包类型的扩展名，则会将错误发送回发送方，并将无效扩展名作为代码。
10 - Invalid NHRP Resolution Reply Received
10-收到无效的NHRP解决方案回复
If a client receives a NHRP Resolution Reply for a Next Hop Resolution Request which it believes it did not make then an error packet is sent to the station making the reply with an error code of Invalid Reply Received.
如果客户机接收到下一跳解析请求的NHRP解析应答，而客户机认为下一跳解析请求没有发出，则向发出应答的站点发送一个错误数据包，其中错误代码为接收到无效应答。
11 - Authentication Failure
11-身份验证失败
If a received packet fails an authentication test then this error is returned.
如果收到的数据包未通过身份验证测试，则返回此错误。
15 - Hop Count Exceeded
超过15个跃点计数
The hop count which was specified in the Fixed Header of an NHRP message has been exceeded.
已超过NHRP消息的固定标头中指定的跃点计数。
Error Offset The offset in octets into the original NHRP packet in which an error was detected. This offset is calculated starting from the NHRP Fixed Header.
错误偏移量检测到错误的原始NHRP数据包中的偏移量（以八位字节为单位）。该偏移量从NHRP固定表头开始计算。
Source NBMA Address The Source NBMA address field is the address of the station which observed the error.
源NBMA地址源NBMA地址字段是观察到错误的站点的地址。
Source NBMA SubAddress The Source NBMA subaddress field is the address of the station 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.
源NBMA子地址源NBMA子地址字段是观察到错误的站点的地址。如果ar$sstl中指定的字段长度为0，则根本不会为此地址分配存储。
Source Protocol Address This is the protocol address of the station which issued the Error packet.
源协议地址这是发出错误数据包的站点的协议地址。
Destination Protocol Address This is the protocol address of the station which sent the packet which was found to be in error.
目的地协议地址这是发送发现有错误的数据包的站点的协议地址。
An NHRP Error Indication packet SHALL NEVER be generated in response to another NHRP Error Indication packet. When an NHRP Error Indication packet is generated, the offending NHRP packet SHALL be discarded. In no case should more than one NHRP Error Indication packet be generated for a single NHRP packet.
不得生成NHRP错误指示数据包来响应另一个NHRP错误指示数据包。当生成NHRP错误指示数据包时，应丢弃违规的NHRP数据包。在任何情况下，不得为单个NHRP数据包生成多个NHRP错误指示数据包。
If an NHS sees its own Protocol and NBMA Addresses in the Source NBMA and Source Protocol address fields of a transiting NHRP Error Indication packet then the NHS will quietly drop the packet and do nothing (this scenario would occur when the NHRP Error Indication packet was itself in a loop).
如果NHS在传输NHRP错误指示数据包的源NBMA和源协议地址字段中看到自己的协议和NBMA地址，则NHS将悄悄地丢弃该数据包，而不采取任何行动（当NHRP错误指示数据包本身处于循环中时，会发生这种情况）。
Note that no extensions may be added to an NHRP Error Indication.
请注意，NHRP错误指示中不得添加任何扩展。
The Extensions Part, if present, carries one or more extensions in {Type, Length, Value} triplets.
扩展部分（如果存在）包含一个或多个{Type，Length，Value}三元组的扩展。
Extensions have the following format:
扩展具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|u| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|u| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C "Compulsory." If clear, and the NHS does not recognize the type code, the extension may safely be ignored. If set, and the NHS does not recognize the type code, the NHRP "request" is considered to be in error. (See below for details.)
C“强制”。如果明确，且NHS不识别类型代码，则可以安全地忽略扩展。如果已设置，且NHS不识别类型代码，则认为NHRP“请求”有误。（详情见下文。）
u Unused and must be set to zero.
u未使用，必须设置为零。
Type The extension type code (see below). The extension type is not qualified by the Compulsory bit, but is orthogonal to it.
键入扩展类型代码（请参见下文）。扩展类型不受强制位的限制，但与之正交。
Length The length in octets of the value (not including the Type and Length fields; a null extension will have only an extension header and a length of zero).
Length值的长度（以八位字节为单位）（不包括Type和Length字段；空扩展名只有一个扩展名头和长度为零）。
When extensions exist, the extensions list is terminated by the Null TLV, having Type = 0 and Length = 0.
当存在扩展时，扩展列表由Null TLV终止，类型为0，长度为0。
Extensions may occur in any order, but any particular extension type may occur only once in an NHRP packet unless explicitly stated to the contrary in the extensions definition. For example, the vendor-private extension may occur multiple times in a packet in order to allow for extensions which do not share the same vendor ID to be represented. It is RECOMMENDED that a given vendor include no more than one Vendor Private Extension.
扩展可以以任何顺序出现，但任何特定的扩展类型在NHRP数据包中只能出现一次，除非扩展定义中明确规定相反。例如，为了允许表示不共享相同供应商ID的扩展，供应商私有扩展可以在分组中出现多次。建议给定的供应商不包含多个供应商专用扩展。
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 an NHS sources a packet) MUST be preserved as the packet moves between NHSs. Minimal NHC implementations MUST only recognize, but
NHS不得改变延期的顺序。也就是说，当数据包在NHS之间移动时，NHC（或当NHS发送数据包时NHS）在NHRP数据包中放置的扩展顺序必须保留。最低限度的NHC实现必须只识别
not necessarily parse, the Vendor Private extension and the End Of Extensions extension. Extensions are only present in a "reply" if they were present in the corresponding "request" with the exception of Vendor Private extensions. The previous statement is not intended to preclude the creation of NHS-only extensions which might be added to and removed from NHRP packets by the same NHS; such extensions MUST not be propagated to NHCs.
不一定解析，供应商私有扩展和扩展结束扩展。只有在相应的“请求”中存在扩展时，扩展才会出现在“回复”中，供应商专用扩展除外。先前的声明并不是为了阻止创建仅NHS的扩展，这些扩展可能由同一NHS添加到NHRP数据包中或从NHRP数据包中删除；此类扩展不得传播到NHC。
The Compulsory bit provides for a means to add to the extension set. If the bit is set in an extension then the station responding to the NHRP message which contains that extension MUST be able to understand the extension (in this case, the station responding to the message is the station that would issue an NHRP reply in response to a NHRP request). As a result, the responder MUST return an NHRP Error Indication of type Unrecognized Extension. If the Compulsory bit is clear then the extension can be safely ignored; however, if an ignored extension is in a "request" then it MUST be returned, unchanged, in the corresponding "reply" packet type.
强制位提供了添加到扩展集的方法。如果在分机中设置了位，则响应包含该分机的NHRP消息的站点必须能够理解该分机（在这种情况下，响应该消息的站点是将发出NHRP应答以响应NHRP请求的站点）。因此，响应程序必须返回类型为Unrecogned Extension的NHRP错误指示。如果强制位是清除的，则可以安全地忽略扩展；但是，如果被忽略的扩展位于“请求”中，则必须在相应的“回复”数据包类型中返回该扩展，不作更改。
If a transit NHS (one which is not going to generate a "reply") detects an unrecognized extension, it SHALL ignore the extension. If the Compulsory bit is set, the transit NHS MUST NOT cache the information contained in the packet and MUST NOT identify itself as an egress router (in the Forward Record or Reverse Record extensions). Effectively, this means, if a transit NHS encounters an extension which it cannot process and which has the Compulsory bit set then that NHS MUST NOT participate in any way in the protocol exchange other than acting as a forwarding agent.
如果公交NHS（不会生成“回复”）检测到无法识别的分机，则应忽略该分机。如果设置了强制位，则中转NHS不得缓存数据包中包含的信息，也不得将自身标识为出口路由器（在前向记录或反向记录扩展中）。实际上，这意味着，如果中转NHS遇到其无法处理且已设置强制位的扩展，则NHS不得以任何方式参与协议交换，除非充当转发代理。
The NHRP extension Type space is subdivided to encourage use outside the IETF.
NHRP扩展类型空间被细分，以鼓励在IETF之外使用。
0x0000 - 0x0FFF Reserved for NHRP. 0x1000 - 0x11FF Allocated to the ATM Forum. 0x1200 - 0x37FF Reserved for the IETF. 0x3800 - 0x3FFF Experimental use.
0x0000-为NHRP保留的0x0FFF。分配给ATM论坛的0x1000-0x11FF。0x1200-为IETF保留的0x37FF。0x3800-0x3FFF实验使用。
IANA will administer the ranges reserved for the IETF as described in Section 9. Values in the 'Experimental use' range have only local significance.
IANA将管理为IETF保留的范围，如第9节所述。“实验使用”范围内的值仅具有局部意义。
Compulsory = 1 Type = 0 Length = 0
强制=1类型=0长度=0
When extensions exist, the extensions list is terminated by the End Of Extensions/Null TLV.
存在扩展时，扩展列表将在extensions/Null TLV的末尾终止。
Compulsory = 1 Type = 3 Length = variable
强制=1类型=3长度=变量
This extension is used to determine the address of the NHRP responder; i.e., the entity that generates the appropriate "reply" packet for a given "request" packet. In the case of an NHRP Resolution Request, the station responding may be different (in the case of cached replies) than the system identified in the Next Hop field of the NHRP Resolution Reply. Further, this extension may aid in detecting loops in the NHRP forwarding path.
此扩展用于确定NHRP响应程序的地址；i、 例如，为给定的“请求”数据包生成适当的“应答”数据包的实体。在NHRP解析请求的情况下，响应的站点可能与NHRP解析应答的下一跳字段中标识的系统不同（在缓存应答的情况下）。此外，该扩展可有助于检测NHRP转发路径中的环路。
This extension uses a single CIE with the extension specific meanings of the fields set as follows:
此扩展使用单个CIE，字段的扩展特定含义设置如下：
The Prefix Length fields MUST be set to 0 and ignored.
前缀长度字段必须设置为0并忽略。
CIE Code 5 - Insufficient Resources If the responder to an NHRP Resolution Request is an egress point for the target of the address resolution request (i.e., it is one of the stations identified in the list of CIEs in an NHRP Resolution Reply) and the Responder Address extension is included in the NHRP Resolution Request and insufficient resources to setup a cut-through VC exist at the responder then the Code field of the Responder Address Extension is set to 5 in order to tell the client that a VC setup attempt would in all likelihood be rejected; otherwise this field MUST be coded as a zero. NHCs MAY use this field to influence whether they attempt to setup a cut-through to the egress router.
CIE代码5-如果NHRP解析请求的响应者是地址解析请求目标的出口点（即，它是NHRP解析回复中CIE列表中标识的站点之一），则资源不足并且响应者地址扩展包括在NHRP解析请求中，且响应者处存在设置直通VC的资源不足，则响应者地址扩展的代码字段设置为5，以便告知客户端VC设置尝试很可能会被拒绝；否则，此字段必须编码为零。NHC可能使用此字段来影响他们是否尝试设置到出口路由器的直通。
Maximum Transmission Unit This field gives the maximum transmission unit preferred by the responder. If this value is 0 then either the default MTU is used or the MTU negotiated via signaling is used if such negotiation is possible for the given NBMA.
最大传输单位该字段给出响应者首选的最大传输单位。如果该值为0，则使用默认MTU，或者如果给定NBMA可以协商，则使用通过信令协商的MTU。
Holding Time The Holding Time field specifies the number of seconds for which the NBMA information of the responser is considered to be valid. Cached information SHALL be discarded when the holding time expires.
保持时间保持时间字段指定响应器的NBMA信息有效的秒数。当保存时间到期时，应丢弃缓存的信息。
"Client Address" information is actually "Responder Address" information for this extension. Thus, for example, Cli Addr T/L is the responder NBMA address type and length field.
“客户端地址”信息实际上是此扩展的“响应者地址”信息。因此，例如，Cli Addr T/L是响应程序NBMA地址类型和长度字段。
If a "requester" desires this information, the "requester" SHALL include this extension with a value of zero. Note that this implies that no storage is allocated for the Holding Time and Type/Length fields until the "Value" portion of the extension is filled out.
如果“请求者”需要此信息，“请求者”应将此扩展包含在值为零的范围内。注意，这意味着在填写扩展的“值”部分之前，不会为保持时间和类型/长度字段分配存储。
If an NHS is generating a "reply" packet in response to a "request" containing this extension, the NHS SHALL include this extension, containing its protocol address in the "reply". If an NHS has more than one protocol address, it SHALL use the same protocol address consistently in all of the Responder Address, Forward Transit NHS Record, and Reverse Transit NHS Record extensions. The choice of which of several protocol address to include in this extension is a local matter.
如果NHS响应包含此扩展的“请求”生成“回复”数据包，则NHS应包括此扩展，并在“回复”中包含其协议地址。如果NHS有多个协议地址，则应在所有响应者地址、正向传输NHS记录和反向传输NHS记录扩展中一致使用相同的协议地址。选择此扩展中包含的几个协议地址中的哪一个是本地事务。
If an NHRP Resolution Reply packet being forwarded by an NHS contains a protocol address of that NHS in the Responder Address Extension then that NHS SHALL generate an NHRP Error Indication of type "NHRP Loop Detected" and discard the NHRP Resolution Reply.
如果NHS转发的NHRP解析应答包在应答器地址扩展中包含该NHS的协议地址，则该NHS应生成“检测到NHRP循环”类型的NHRP错误指示，并丢弃NHRP解析应答。
If an NHRP Resolution Reply packet is being returned by an intermediate NHS based on cached data, it SHALL place its own address in this extension (differentiating it from the address in the Next Hop field).
如果中间NHS基于缓存数据返回NHRP解析应答数据包，则它应将自己的地址放入该扩展中（与下一跳字段中的地址不同）。
Compulsory = 1 Type = 4 Length = variable
强制=1类型=4长度=变量
The NHRP Forward Transit NHS record contains a list of transit NHSs through which a "request" has traversed. Each NHS SHALL append to the extension a Forward Transit NHS element (as specified below) containing its Protocol address. The extension length field and the ar$chksum fields SHALL be adjusted appropriately.
NHRP正向运输NHS记录包含“请求”已通过的运输NHS列表。每个NHS应在扩展中附加一个包含其协议地址的前向传输NHS元素（如下所述）。应适当调整延伸长度字段和ar$chksum字段。
The responding NHS, as described in Section 5.3.1, SHALL NOT update this extension.
如第5.3.1节所述，做出响应的NHS不得更新该扩展。
In addition, NHSs that are willing to act as egress routers for packets from the source to the destination SHALL include information about their NBMA Address.
此外，愿意充当从源到目的地的包的出口路由器的NHS应包括关于其NBMA地址的信息。
This extension uses a single CIE per NHS Record element with the extension specific meanings of the fields set as follows:
此扩展为每个NHS记录元素使用一个CIE，字段的扩展特定含义设置如下：
The Prefix Length fields MUST be set to 0 and ignored.
前缀长度字段必须设置为0并忽略。
CIE Code 5 - Insufficient Resources If an NHRP Resolution Request contains an NHRP Forward Transit NHS Record Extension and insufficient resources to setup a cut-through VC exist at the current transit NHS then the CIE Code 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 likelihood be rejected; otherwise this field MUST be coded as a zero. NHCs MAY use this field to influence whether they attempt to setup a cut-through as described in Section 2.2. Note that the NHRP Reverse Transit NHS Record Extension MUST always have this field set to zero.
CIE代码5-资源不足如果NHRP解决请求包含NHRP前向传输NHS记录扩展，且当前传输NHS中存在设置直通VC的资源不足，则NHRP前向传输NHS记录扩展的CIE代码字段设置为5，以告知客户端VC设置尝试将进入极有可能被拒绝；否则，此字段必须编码为零。NHC可使用此字段来影响其是否尝试设置第2.2节所述的直通。请注意，NHRP反向传输NHS记录扩展必须始终将此字段设置为零。
Maximum Transmission Unit This field gives the maximum transmission unit preferred by the transit NHS. If this value is 0 then either the default MTU is used or the MTU negotiated via signaling is used if such negotiation is possible for the given NBMA.
最大传输单位该字段给出了公交NHS首选的最大传输单位。如果该值为0，则使用默认MTU，或者如果给定NBMA可以协商，则使用通过信令协商的MTU。
Holding Time The Holding Time field specifies the number of seconds for which the NBMA information of the transit NHS is considered to be valid. Cached information SHALL be discarded when the holding time expires.
等待时间等待时间字段指定认为公交NHS的NBMA信息有效的秒数。当保存时间到期时，应丢弃缓存的信息。
"Client Address" information is actually "Forward Transit NHS Address" information for this extension. Thus, for example, Cli Addr T/L is the transit NHS NBMA address type and length field.
“客户地址”信息实际上是此扩展的“转发传输NHS地址”信息。因此，例如，Cli Addr T/L是传输NHS NBMA地址类型和长度字段。
If a "requester" wishes to obtain this information, it SHALL include this extension with a length of zero. Note that this implies that no storage is allocated for the Holding Time and Type/Length fields until the "Value" portion of the extension is filled out.
如果“请求者”希望获得此信息，则应包括长度为零的扩展。注意，这意味着在填写扩展的“值”部分之前，不会为保持时间和类型/长度字段分配存储。
If an NHS has more than one Protocol address, it SHALL use the same Protocol address consistently in all of the Responder Address, Forward NHS Record, and Reverse NHS Record extensions. The choice of which of several Protocol addresses to include in this extension is a local matter.
如果NHS有多个协议地址，它应在所有响应者地址、转发NHS记录和反向NHS记录扩展中一致使用相同的协议地址。选择此扩展中包含的几个协议地址中的哪一个是本地事务。
If a "request" that is being forwarded by an NHS contains the Protocol Address of that NHS in one of the Forward Transit NHS elements then the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop Detected" and discard the "request".
如果由NHS转发的“请求”包含该NHS在其中一个转发传输NHS元素中的协议地址，则NHS应生成类型为“检测到NHRP环路”的NHRP错误指示，并丢弃“请求”。
Compulsory = 1 Type = 5 Length = variable
强制=1类型=5长度=变量
The NHRP Reverse Transit NHS record contains a list of transit NHSs through which a "reply" has traversed. Each NHS SHALL append a Reverse Transit NHS element (as specified below) containing its Protocol address to this extension. The extension length field and ar$chksum SHALL be adjusted appropriately.
NHRP反向运输NHS记录包含一个运输NHS列表，其中有一个“回复”经过该列表。每个NHS应将包含其协议地址的反向传输NHS元素（如下所述）附加到此扩展。应适当调整延伸长度字段和ar$chksum。
The responding NHS, as described in Section 5.3.1, SHALL NOT update this extension.
如第5.3.1节所述，做出响应的NHS不得更新该扩展。
In addition, NHSs that are willing to act as egress routers for packets from the source to the destination SHALL include information about their NBMA Address.
此外，愿意充当从源到目的地的包的出口路由器的NHS应包括关于其NBMA地址的信息。
This extension uses a single CIE per NHS Record element with the extension specific meanings of the fields set as follows:
此扩展为每个NHS记录元素使用一个CIE，字段的扩展特定含义设置如下：
The CIE Code and Prefix Length fields MUST be set to 0 and ignored.
CIE代码和前缀长度字段必须设置为0并忽略。
Maximum Transmission Unit This field gives the maximum transmission unit preferred by the transit NHS. If this value is 0 then either the default MTU is used or the MTU negotiated via signaling is used if such negotiation is possible for the given NBMA.
最大传输单位该字段给出了公交NHS首选的最大传输单位。如果该值为0，则使用默认MTU，或者如果给定NBMA可以协商，则使用通过信令协商的MTU。
Holding Time The Holding Time field specifies the number of seconds for which the NBMA information of the transit NHS is considered to be valid. Cached information SHALL be discarded when the holding time expires.
等待时间等待时间字段指定认为公交NHS的NBMA信息有效的秒数。当保存时间到期时，应丢弃缓存的信息。
"Client Address" information is actually "Reverse Transit NHS Address" information for this extension. Thus, for example, Cli Addr T/L is the transit NHS NBMA address type and length field.
“客户地址”信息实际上是此扩展的“反向传输NHS地址”信息。因此，例如，Cli Addr T/L是传输NHS NBMA地址类型和长度字段。
If a "requester" wishes to obtain this information, it SHALL include this extension with a length of zero. Note that this implies that no storage is allocated for the Holding Time and Type/Length fields until the "Value" portion of the extension is filled out.
如果“请求者”希望获得此信息，则应包括长度为零的扩展。注意，这意味着在填写扩展的“值”部分之前，不会为保持时间和类型/长度字段分配存储。
If an NHS has more than one Protocol address, it SHALL use the same Protocol address consistently in all of the Responder Address, Forward NHS Record, and Reverse NHS Record extensions. The choice of which of several Protocol addresses to include in this extension is a local matter.
如果NHS有多个协议地址，它应在所有响应者地址、转发NHS记录和反向NHS记录扩展中一致使用相同的协议地址。选择此扩展中包含的几个协议地址中的哪一个是本地事务。
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 the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop Detected" and discard the "reply".
如果NHS转发的“回复”在反向传输NHS元素之一中包含该NHS的协议地址，则NHS应生成类型为“检测到NHRP环路”的NHRP错误指示，并丢弃“回复”。
Note that this information may be cached at intermediate NHSs; if so, the cached value SHALL be used when generating a reply.
注意，该信息可以缓存在中间nhs处；如果是，则在生成回复时应使用缓存的值。
Compulsory = 1 Type = 7 Length = variable
Compulsory = 1 Type = 7 Length = variable
The NHRP Authentication Extension is carried in NHRP packets to convey authentication information between NHRP speakers. The Authentication Extension may be included in any NHRP "request" or "reply" only.
NHRP认证扩展在NHRP数据包中携带，以在NHRP扬声器之间传送认证信息。认证扩展可仅包括在任何NHRP“请求”或“回复”中。
The authentication is always done pairwise on an NHRP hop-by-hop basis; i.e., the authentication extension is regenerated at each hop. If a received packet fails the authentication test, the station SHALL generate an Error Indication of type "Authentication Failure" and discard the packet. Note that one possible authentication failure is the lack of an Authentication Extension; the presence or absence of the Authentication Extension is a local matter.
认证总是在NHRP逐跳的基础上成对进行；i、 例如，在每个跃点重新生成认证扩展。如果接收到的数据包未通过认证测试，则站点应生成“认证失败”类型的错误指示，并丢弃该数据包。注意，一个可能的身份验证失败是缺少身份验证扩展；身份验证扩展是否存在是一个局部问题。
The authentication header has the following format:
身份验证标头具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Security Parameter Index (SPI)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Security Parameter Index (SPI)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Parameter Index (SPI) can be thought of as an index into a 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.
安全参数索引（SPI）可以被认为是表的索引，该表维护键和其他信息，如哈希算法。Src和Dst使用手动键控进行离线通信，或使用密钥管理协议进行在线通信以填充此表。发送NHRP实体始终分配SPI及其相关参数。
Src Addr a variable length field is the address assigned to the 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.
Src Addr可变长度字段是分配给传出接口的地址。addr的长度从NHRP头的必填部分的源协议长度字段中获取。元组<spi，src addr>唯一标识用于身份验证的密钥和其他参数。
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.
身份验证数据字段的长度取决于所使用的哈希算法。数据字段包含在整个NHRP有效负载上计算的密钥散列。在计算散列之前，验证数据字段被清零。
SPI's can be negotiated either manually or using an Internet Key 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).
SPI可以手动协商，也可以使用Internet密钥管理协议协商。必须支持手动键控。以下参数与元组<SPI，src>-生存期、算法、密钥相关。生存期表示密钥有效的持续时间（秒）。在手动键控的情况下，此持续时间可以是无限的。此外，为了更好地支持手动键控，可能同时有多个元组处于活动状态（Dst相同）。
Algorithm specifies the hash algorithm agreed upon by the two entities. HMAC-MD5-128 [16] is the default algorithm. Other algorithms MAY be supported by defining new values. IANA will assign the numbers to identify the algorithm being used as described in Section 9.
算法指定两个实体商定的哈希算法。HMAC-MD5-128[16]是默认算法。通过定义新值，可以支持其他算法。IANA将按照第9节所述分配编号，以识别正在使用的算法。
Any Internet standard key management protocol MAY so be used to negotiate the SPI and parameters.
因此，可以使用任何因特网标准密钥管理协议来协商SPI和参数。
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.
在添加身份验证扩展头时，src在表中查找，以根据传出接口地址获取SPI和安全参数。如果表中没有条目并且支持密钥管理，src将启动密钥管理协议以获取必要的参数。src构造身份验证扩展负载，并通过将身份验证数据字段归零来计算哈希值。结果替换为零身份验证数据字段中的值。有效负载中的src address字段是分配给传出接口的IP地址。
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.
在接收端，dst根据SPI和身份验证扩展负载中的ip地址获取参数。在清零以计算哈希之前提取身份验证数据字段。它计算整个有效负载上的哈希，如果哈希不匹配，则发生“异常事件”。
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. A chain of trust is established amongst NHRP entities in the path of the NHRP Message . If the security in an NHRP entity is compromised, then security in the entire NHRP domain is compromised.
安全性是在逐跳的基础上执行的。接收到的数据可以被信任的程度，只有当一个人信任所经过的路径中的所有实体时。在NHRP消息路径中的NHRP实体之间建立信任链。如果NHRP实体中的安全性受损，则整个NHRP域中的安全性受损。
Data integrity covers the entire NHRP payload. This guarantees that the message was not modified and the source is authenticated as well. If authentication extension is not used or if the security is compromised, then NHRP entities are liable to both spoofing attacks, active attacks and passive attacks.
数据完整性覆盖整个NHRP有效载荷。这保证了消息没有被修改，并且源也经过了身份验证。如果未使用身份验证扩展或安全性受损，则NHRP实体容易受到欺骗攻击、主动攻击和被动攻击。
There is no mechanism to encrypt the messages. It is assumed that a standard layer 3 confidentiality mechanism will be used to encrypt and decrypt messages. It is recommended to use an Internet standard key management protocol to negotiate the keys between the neighbors. Transmitting the keys in clear text, if other methods of negotiation is used, compromises the security completely.
没有加密消息的机制。假定将使用标准的第3层保密机制对消息进行加密和解密。建议使用Internet标准密钥管理协议在邻居之间协商密钥。如果使用其他协商方法，以明文形式传输密钥将完全危及安全性。
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.
任何NHS都容易受到拒绝服务（DOS）攻击，导致其过载，从而使合法数据包无法正确处理。恶意主机可以向第一跳NHS发送请求和注册数据包。如果未使用认证选项，则注册数据包将沿着需要沿着每个NHS进行处理的路由路径转发。如果使用了身份验证选项，则只有第一跳NHS容易受到DOS攻击（即，未经身份验证的数据包将被丢弃，而不是在网络上转发）。如果任何主机的安全性受到损害（即，它用于与NHS通信的密钥变得已知），则恶意主机可以向其密钥受到损害的主机的第一跳NHS发送NHRP数据包，然后该主机将沿着路由路径转发这些数据包，就像未经验证的数据包一样。但是，此攻击要求恶意主机具有与受损主机相同的第一跳NHS。最后，应该注意的是，导致路由路径上的路由器花费资源处理NHRP数据包的拒绝服务攻击也容易受到在NHRP数据包的目的地协议地址字段中包含的相同目的地洪水包的攻击。
Compulsory = 0 Type = 8 Length = variable
强制=0类型=8长度=变量
The NHRP Vendor-Private Extension is carried in NHRP packets to convey vendor-private information or NHRP extensions between NHRP speakers.
NHRP供应商专用分机在NHRP数据包中携带，用于在NHRP扬声器之间传送供应商专用信息或NHRP分机。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID | Data.... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID | Data.... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID 802 Vendor ID as assigned by the IEEE [6]
供应商ID 802由IEEE分配的供应商ID[6]
Data The remaining octets after the Vendor ID in the payload are vendor-dependent data.
数据有效负载中供应商ID之后的剩余八位字节是供应商相关数据。
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 receiver does not handle this extension, or does not match the Vendor
此扩展可以添加到任何“请求”或“回复”数据包中，并且它是唯一可以多次包含的扩展。如果接收方不处理此扩展，或与供应商不匹配
ID in the extension then the extension may be completely ignored by the receiver. If a Vendor Private Extension is included in a "request" then it must be copied to the corresponding "reply".
则接收器可能会完全忽略该扩展。如果“请求”中包含供应商专用扩展，则必须将其复制到相应的“回复”中。
In this section, we discuss certain operational considerations of NHRP.
在本节中，我们将讨论NHRP的某些操作注意事项。
In practice, the initiating and responding stations may be either hosts or routers. However, there is a possibility under certain conditions that a stable routing loop may occur if NHRP is used between two routers. In particular, attempting to establish an NHRP path across a boundary where information used in route selection is lost may result in a routing loop. Such situations include the loss of BGP path vector information, the interworking of multiple routing protocols with dissimilar metrics (e.g, RIP and OSPF), etc. In such circumstances, NHRP should not be used. This situation can be avoided if there are no "back door" paths between the entry and egress router outside of the NBMA subnetwork. Protocol mechanisms to relax these restrictions are under investigation.
实际上，发起站和响应站可以是主机或路由器。然而，在某些情况下，如果在两个路由器之间使用NHRP，则可能出现稳定的路由循环。特别是，试图建立跨越边界的NHRP路径，其中在路由选择中使用的信息丢失，可能导致路由循环。这种情况包括丢失BGP路径向量信息、使用不同度量（例如RIP和OSPF）的多个路由协议的互通等。在这种情况下，不应使用NHRP。如果NBMA子网外部的入口和出口路由器之间没有“后门”路径，则可以避免这种情况。放松这些限制的协议机制正在调查中。
In general it is preferable to use mechanisms, if they exist, in routing protocols to resolve the egress point when the destination lies outside of the NBMA subnetwork, since such mechanisms will be more tightly coupled to the state of the routing system and will probably be less likely to create loops.
一般来说，当目的地位于NBMA子网之外时，最好在路由协议中使用机制（如果存在），以解析出口点，因为此类机制将更紧密地耦合到路由系统的状态，并且可能不太可能创建循环。
The management of NHRP caches in the source station, the NHS serving the destination, and any intermediate NHSs is dependent on a number of factors.
源站、服务于目的地的NHS和任何中间NHS中NHRP缓存的管理取决于许多因素。
Source Stations
源站
Source stations MUST cache all received NHRP Resolution Replies that they are actively using. They also must cache "incomplete" entries, i.e., those for which a NHRP Resolution Request has been sent but those for which an NHRP Resolution Reply has not been received. This is necessary in order to preserve the Request ID
Source stations MUST cache all received NHRP Resolution Replies that they are actively using. They also must cache "incomplete" entries, i.e., those for which a NHRP Resolution Request has been sent but those for which an NHRP Resolution Reply has not been received. This is necessary in order to preserve the Request IDtranslate error, please retry
for retries, and provides the state necessary to avoid triggering NHRP Resolution Requests for every data packet sent to the destination.
用于重试，并提供避免触发发送到目的地的每个数据包的NHRP解析请求所需的状态。
Source stations MUST purge expired information from their caches. Source stations MUST purge the appropriate cached information upon receipt of an NHRP Purge Request packet.
源站必须清除其缓存中的过期信息。在收到NHRP清除请求数据包后，源站必须清除相应的缓存信息。
When a station has a co-resident NHC and NHS, the co-resident NHS may reply to NHRP Resolution Requests from the co-resident NHC with information which the station cached as a result of the co-resident NHC making its own NHRP Resolution Requests as long as the co-resident NHS follows the rules for Transit NHSs as seen below.
当车站有共同居民NHC和NHS时，共同居民NHS可回复共同居民NHC提出的NHRP解决请求，只要共同居民NHS遵守如下所示的交通NHS规则，车站可缓存共同居民NHC提出其自己的NHRP解决请求所产生的信息。
Serving NHSs
服务国民保健服务
The NHS serving the destination (the one which responds authoritatively to NHRP Resolution Requests) SHOULD cache protocol address information from all NHRP Resolution Requests to which it has responded if the information in the NHRP Resolution Reply has the possibility of changing during its lifetime (so that an NHRP Purge Request packet can be issued). The internetworking to NBMA binding information provided by the source station in the NHRP Resolution Request may also be cached if and only if the "S" bit is set, the NHRP Resolution Request has included a CIE with the Holding Time field set greater than zero (this is the valid Holding Time for the source binding), and only for non-authoritative use for a period not to exceed the Holding Time.
为目的地服务的NHS（授权响应NHRP解析请求的NHS）应缓存其已响应的所有NHRP解析请求中的协议地址信息，前提是NHRP解析回复中的信息在其生存期内可能发生更改（以便可以发出NHRP清除请求数据包）。如果且仅当设置了“S”位时，NHRP解析请求已包括保持时间字段设置大于零的CIE，则也可以缓存NHRP解析请求中源站提供的与NBMA绑定的互联信息（这是源绑定的有效保留时间），并且仅用于非授权使用，保留时间不得超过保留时间。
Transit NHSs
公共交通NHSs
A Transit NHS (lying along the NHRP path between the source station and the responding NHS) may cache source binding information contained in NHRP Resolution Request packets that it forwards if and only if the "S" bit is set, the NHRP Resolution Request has included a CIE with the Holding Time field set greater than zero (this is the valid Holding Time for the source binding), and only for non-authoritative use for a period not to exceed the Holding Time.
中转NHS（位于源站和响应NHS之间的NHRP路径上）可以缓存包含在NHRP解析请求包中的源绑定信息，当且仅当设置了“S”位时，NHRP解析请求已经包括保持时间字段设置为大于零的CIE，该NHS才会转发该NHRP解析请求包（这是源绑定的有效保留时间），并且仅用于非授权使用，保留时间不得超过保留时间。
A Transit NHS may cache destination information contained in NHRP Resolution Reply CIE if only if the D bit is set and then only for non-authoritative use for a period not to exceed the Holding Time value contained in the CIE. A Transit NHS MUST NOT cache source binding information contained in an NHRP Resolution Reply.
仅当设置了D位并且仅在不超过CIE中包含的保持时间值的时段内用于非授权使用时，中转NHS可以缓存包含在NHRP解析应答CIE中的目的地信息。中转NHS不得缓存NHRP解析回复中包含的源绑定信息。
Further, a transit NHS MUST discard any cached information when the prescribed time has expired. It may return cached information in response to non-authoritative NHRP Resolution Requests only.
此外，当规定的时间到期时，公交NHS必须丢弃任何缓存的信息。它可能仅在响应非权威NHRP解析请求时返回缓存信息。
NBMA-Connected Destinations
连接目的地
NHRP's most basic function is that of simple NBMA address resolution of stations directly attached to the NBMA subnetwork. These mappings are typically very static, and appropriately chosen holding times will minimize problems in the event that the NBMA address of a station must be changed. Stale information will cause a loss of connectivity, which may be used to trigger an authoritative NHRP Resolution Request and bypass the old data. In the worst case, connectivity will fail until the cache entry times out.
NHRP最基本的功能是直接连接到NBMA子网的站点的简单NBMA地址解析。这些映射通常是非常静态的，如果必须更改站点的NBMA地址，适当选择的保持时间将使问题最小化。陈旧信息将导致连接丢失，这可能用于触发权威NHRP解析请求并绕过旧数据。在最坏的情况下，连接将失败，直到缓存项超时。
This applies equally to information marked in NHRP Resolution Replies as being "stable" (via the "D" bit).
这同样适用于NHRP分辨率回复中标记为“稳定”（通过“D”位）的信息。
Destinations Off of the NBMA Subnetwork
离开NBMA子网的目的地
If the source of an NHRP Resolution Request is a host and the destination is not directly attached to the NBMA subnetwork, and the route to that destination is not considered to be "stable," the destination mapping may be very dynamic (except in the case of a subnetwork where each destination is only singly homed to the NBMA subnetwork). As such the cached information may very likely become stale. The consequence of stale information in this case will be a suboptimal path (unless the internetwork has partitioned or some other routing failure has occurred).
如果NHRP解析请求的来源是主机，且目的地未直接连接到NBMA子网，且到该目的地的路由不被认为是“稳定的”，则目的地映射可能是非常动态的（子网的情况除外，其中每个目的地仅单独归属于NBMA子网）。因此，缓存的信息很可能会过时。在这种情况下，过时信息的后果将是次优路径（除非互联网已分区或发生其他路由故障）。
A certain amount of care needs to be taken when using the Prefix Length field of a CIE, in particular with regard to the prefix length advertised (and thus the size of the equivalence class specified by it). Assuming that the routers on the NBMA subnetwork are exchanging routing information, it should not be possible for an NHS to create a black hole by advertising too large of a set of destinations, but suboptimal routing (e.g., extra internetwork layer hops through the NBMA) can result. To avoid this situation an NHS that wants to send the Prefix Length MUST obey the following rule:
在使用CIE的前缀长度字段时，需要特别注意前缀长度（以及由此指定的等价类的大小）。假设NBMA子网上的路由器正在交换路由信息，NHS不可能通过宣传太多的目的地来创建黑洞，但可能会导致次优路由（例如，通过NBMA的额外网络层跳数）。为了避免这种情况，想要发送前缀长度的NHS必须遵守以下规则：
The NHS examines the Network Layer Reachability Information (NLRI) associated with the route that the NHS would use to forward towards the destination (as specified by the Destination internetwork layer
NHS检查与NHS将用于向目的地转发的路由相关的网络层可达性信息（NLRI）（由目的地互联网络层指定
address in the NHRP Resolution Request), and extracts from this NLRI the shortest address prefix such that: (a) the Destination internetwork layer address (from the NHRP Resolution Request) is 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 prefix may then be used in the CIE.
NHRP解析请求中的地址），并从该NLRI中提取最短地址前缀，以便：（a）前缀覆盖了目标网络间层地址（来自NHRP解析请求），（b）NHS没有任何与NLRI构成前缀覆盖部分的路由。然后可以在CIE中使用前缀。
The Prefix Length field of the CIE should be used with restraint, in order to avoid NHRP stations choosing suboptimal transit paths when overlapping prefixes are available. This document specifies the use of the prefix length only when all the destinations covered by the prefix are "stable". That is, either:
应限制使用CIE的前缀长度字段，以避免NHRP站在重叠前缀可用时选择次优公交路径。本文件规定仅当前缀覆盖的所有目的地均为“稳定”时，才使用前缀长度。即：
(a) All destinations covered by the prefix are on the NBMA network, or (b) All destinations covered by the prefix are directly attached to the NHRP responding station.
(a) 前缀覆盖的所有目的地都在NBMA网络上，或者（b）前缀覆盖的所有目的地都直接连接到NHRP响应站。
Use of the Prefix Length field of the CIE in other circumstances is outside the scope of this document.
在其他情况下使用CIE的前缀长度字段超出了本文档的范围。
One could easily imagine a situation where a router, acting as an ingress station to the NBMA subnetwork, receives a data packet, such that this packet triggers an NHRP Resolution Request. If the router forwards this data packet without waiting for an NHRP transit path to be established, then when the next router along the path receives the packet, the next router may do exactly the same - originate its own NHRP Resolution Request (as well as forward the packet). In fact such a data packet may trigger NHRP Resolution Request generation at every router along the path through an NBMA subnetwork. We refer to this phenomena as the NHRP "domino" effect.
人们可以很容易地想象这样一种情况，即充当NBMA子网入口站的路由器接收数据包，从而该数据包触发NHRP解析请求。如果路由器在不等待建立NHRP传输路径的情况下转发该数据包，那么当路径上的下一个路由器接收到该数据包时，下一个路由器可以执行完全相同的操作-发起自己的NHRP解析请求（以及转发该数据包）。事实上，这样的数据包可以在通过NBMA子网的路径上的每个路由器处触发NHRP解析请求生成。我们将这种现象称为NHRP“多米诺”效应。
The NHRP domino effect is clearly undesirable. At best it may result in excessive NHRP traffic. At worst it may result in an excessive number of virtual circuits being established unnecessarily. Therefore, it is important to take certain measures to avoid or suppress this behavior. NHRP implementations for NHSs MUST provide a mechanism to address this problem. One possible strategy to address this problem would be to configure a router in such a way that NHRP Resolution Request generation by the router would be driven only by the traffic the router receives over its non-NBMA interfaces (interfaces that are not attached to an NBMA subnetwork). Traffic received by the router over its NBMA-attached interfaces would not trigger NHRP Resolution Requests. Such a router avoids the NHRP domino effect through administrative means.
NHRP多米诺效应显然是不可取的。充其量可能导致NHRP流量过大。在最坏的情况下，它可能会导致不必要地建立过多的虚拟电路。因此，采取某些措施来避免或抑制这种行为是很重要的。NHSs的NHRP实现必须提供解决此问题的机制。解决此问题的一种可能策略是配置路由器，使路由器生成的NHRP解析请求仅由路由器通过其非NBMA接口（未连接到NBMA子网的接口）接收的流量驱动。路由器通过其NBMA连接接口接收的流量不会触发NHRP解析请求。这种路由器通过管理手段避免了NHRP多米诺效应。
There would appear to be no significant impediment to running NHRP over legacy broadcast subnetworks. There may be issues around running NHRP across multiple subnetworks. Running NHRP on broadcast media has some interesting possibilities; especially when setting up 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 research.
在传统广播子网上运行NHRP似乎没有重大障碍。跨多个子网运行NHRP可能会出现问题。在广播媒体上运行NHRP有一些有趣的可能性；特别是当一个或两个端站连接时，为ELAN间LIS/LAG流量设置直通时。NHRP的这种用途需要进一步研究。
The result of an NHRP Resolution Request depends on how routing is configured among the NHSs of an NBMA subnetwork. If the destination station is directly connected to the NBMA subnetwork and the routed path to it lies entirely within the NBMA subnetwork, the NHRP Resolution Replies always return the NBMA address of the destination station itself rather than the NBMA address of some egress router. 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 rather will return the address of the egress router. For destinations outside the NBMA subnetwork, egress routers and routers in the other subnetworks should exchange routing information so that the optimal egress router may be found.
NHRP解析请求的结果取决于如何在NBMA子网的NHS之间配置路由。如果目标站直接连接到NBMA子网，且其路由路径完全位于NBMA子网内，则NHRP解析应答始终返回目标站本身的NBMA地址，而不是某些出口路由器的NBMA地址。另一方面，如果路由路径退出NBMA子网，NHRP将无法解析目的地的NBMA地址，而是返回出口路由器的地址。对于NBMA子网之外的目的地，出口路由器和其他子网中的路由器应交换路由信息，以便找到最佳出口路由器。
In addition to NHSs, an NBMA station could also be associated with one or more regular routers that could act as "connectionless servers" for the station. The station could then choose to resolve the NBMA next hop or just send the packets to one of its connectionless servers. The latter option may be desirable if communication with the destination is short-lived and/or doesn't require much network resources. The connectionless servers could, of course, be physically integrated in the NHSs by augmenting them with internetwork layer switching functionality.
除了NHS之外，NBMA站还可以与一个或多个常规路由器相关联，这些路由器可以充当该站的“无连接服务器”。然后，站点可以选择解析NBMA下一跳，或者只将数据包发送到它的一个无连接服务器。如果与目的地的通信是短暂的和/或不需要太多网络资源，则后一种选择可能是可取的。当然，无连接服务器可以通过增加网络层交换功能，在NHS中进行物理集成。
IANA will take advice from the Area Director appointed designated subject matter expert, in order to assign numbers from the various number spaces described herein. In the event that the Area Director appointed designated subject matter expert is unavailable, the relevant IESG Area Director will appoint another expert. Any and all requests for value assignment within a given number space will be accepted when the usage of the value assignment documented. Possible forms of documentantion include, but is not limited to, RFCs or the product of another cooperative standards body (e.g., the MPOA and LANE subworking group of the ATM Forum).
IANA将听取区域总监指定的主题专家的建议，以便从本文所述的各个数字空间分配数字。如果区域总监指定的主题专家不可用，相关IESG区域总监将指定另一位专家。当记录价值分配的使用情况时，将接受给定数字空间内的任何和所有价值分配请求。文件的可能形式包括但不限于RFC或其他合作标准机构的产品（例如，ATM论坛的MPOA和LANE子工作组）。
References
工具书类
[1] Heinanen, J., and R. Govindan, "NBMA Address Resolution Protocol (NARP)", RFC 1735, December 1994.
[1] Heinanen，J.和R.Govindan，“NBMA地址解析协议（NARP）”，RFC 17351994年12月。
[2] Plummer, D., "Address Resolution Protocol", STD 37, RFC 826, November 1982.
[2] Plummer，D.，“地址解析协议”，STD 37，RFC 826，1982年11月。
[3] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.
[3] Laubach，M.和J.Halpern，“ATM上的经典IP和ARP”，RFC 22251998年4月。
[4] Piscitello,, D., and J. Lawrence, "Transmission of IP datagrams over the SMDS service", RFC 1209, March 1991.
[4] Piscitello，D.和J.Lawrence，“通过SMDS服务传输IP数据报”，RFC 1209，1991年3月。
[5] Protocol Identification in the Network Layer, ISO/IEC TR 9577:1990.
[5] 网络层中的协议标识，ISO/IEC TR 9577:1990。
[6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[6] Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[7] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[7] Heinanen，J.，“ATM适配层5上的多协议封装”，RFC 1483，1993年7月。
[8] Malis, A., Robinson, D., and R. Ullmann, "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356, August 1992.
[8] Malis，A.，Robinson，D.，和R.Ullmann，“X.25和ISDN在分组模式下的多协议互连”，RFC 1356，1992年8月。
[9] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 1490, July 1993.
[9] Bradley，T.，Brown，C.和A.Malis，“帧中继上的多协议互连”，RFC 1490，1993年7月。
[10] Rekhter, Y., and D. Kandlur, ""Local/Remote" Forwarding Decision in Switched Data Link Subnetworks", RFC 1937, May 1996.
[10] Y.Rekhter和D.Kandlur，“交换数据链路子网中的本地/远程转发决策”，RFC 1937，1996年5月。
[11] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[11] Armitage，G.“支持基于UNI 3.0/3.1的ATM网络上的多播”，RFC 2022，1996年11月。
[12] Luciani, J., Armitage, G., and J. Halpern, "Server Cache Synchronization Protocol (SCSP) - NBMA", RFC 2334, April 1998.
[12] Luciani，J.，Armitage，G.，和J.Halpern，“服务器缓存同步协议（SCSP）-NBMA”，RFC 2334，1998年4月。
[13] Rekhter, Y., "NHRP for Destinations off the NBMA Subnetwork", Work In Progress.
[13] Rekhter，Y.，“NBMA子网外目的地的NHRP”，正在进行的工作。
[14] Luciani, J., et. al., "Classical IP and ARP over ATM to NHRP Transition", Work In Progress.
[14] Luciani，J.等人，“ATM上的经典IP和ARP到NHRP的转换”，正在进行中的工作。
[15] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[15] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[16] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997.
[16] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
Acknowledgments
致谢
We would like to thank (in no particular order) Thomas Narten 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 and the original NHRP draft, which served as the basis for this work. Russell Gardo of IBM, John Burnett of Adaptive, Dennis Ferguson of ANS, Andre Fredette of Bay Networks, Joel Halpern of Newbridge, Paul Francis of NTT, Tony Li, Bryan Gleeson, and Yakov Rekhter of cisco, and Grenville Armitage of Bellcore should also be acknowledged for comments and suggestions that improved this work substantially. We would also like to thank the members of the ION working group of the IETF, whose review and discussion of this document have been invaluable.
我们要感谢（没有特别顺序）IBM的Thomas Narten在互联网广告中的评论，芬兰电信的Juha Heinenan和ISI的Ramesh Govidan在NBMA ARP和原始NHRP草案方面的工作，这是这项工作的基础。IBM的罗素·加德、Adaptive的约翰·伯内特、ANS的丹尼斯·弗格森、Bay Networks的安德烈·弗雷德特、新桥的乔尔·哈尔佩恩、NTT的保罗·弗朗西斯、思科的托尼·李、布莱恩·格雷森和雅科夫·雷克特，以及Bellcore的格伦维尔·阿米蒂奇，这些评论和建议都大大改进了这项工作，对此也应予以肯定。我们还要感谢IETF离子工作组的成员，他们对本文件的审查和讨论非常宝贵。
Authors' Addresses
作者地址
James V. Luciani Dave Katz
Bay Networks cisco Systems
3 Federal Street 170 W. Tasman Dr.
Mail Stop: BL3-03 San Jose, CA 95134 USA
Billerica, MA 01821 Phone: +1 408 526 8284
Phone: +1 978 916 4734 EMail: dkatz@cisco.com
EMail: luciani@baynetworks.com
James V. Luciani Dave Katz
Bay Networks cisco Systems
3 Federal Street 170 W. Tasman Dr.
Mail Stop: BL3-03 San Jose, CA 95134 USA
Billerica, MA 01821 Phone: +1 408 526 8284
Phone: +1 978 916 4734 EMail: dkatz@cisco.com
EMail: luciani@baynetworks.com
David Piscitello Bruce Cole
Core Competence Juniper Networks
1620 Tuckerstown Road 3260 Jay St.
Dresher, PA 19025 USA Santa Clara, CA 95054
Phone: +1 215 830 0692 Phone: +1 408 327 1900
EMail: dave@corecom.com EMail: bcole@jnx.com
David Piscitello Bruce Cole
Core Competence Juniper Networks
1620 Tuckerstown Road 3260 Jay St.
Dresher, PA 19025 USA Santa Clara, CA 95054
Phone: +1 215 830 0692 Phone: +1 408 327 1900
EMail: dave@corecom.com EMail: bcole@jnx.com
Naganand Doraswamy Bay Networks, Inc. 3 Federal Street Mail Stop: Bl3-03 Billerica, MA 01801 Phone: +1 978 916 1323 EMail: naganand@baynetworks.com
Naganand Doraswamy Bay Networks，Inc.3联邦街道邮件站：Bl3-03 Billerica，MA 01801电话：+1 978 916 1323电子邮件：naganand@baynetworks.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。