Network Working Group B. Fox
Request for Comments: 2735 Equipe Communications
Category: Standards Track B. Petri
Siemens AG
December 1999
Network Working Group B. Fox
Request for Comments: 2735 Equipe Communications
Category: Standards Track B. Petri
Siemens AG
December 1999
NHRP Support for Virtual Private Networks
对虚拟专用网络的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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
The NBMA Next Hop Resolution Protocol (NHRP) is used to determine the NBMA subnetwork addresses of the "NBMA next hop" towards a public internetworking layer address (see [1]). This document describes the enhancements necessary to enable NHRP to perform the same function for private internetworking layer addresses available within the framework of a Virtual Private Network (VPN) service on a shared NBMA network.
NBMA下一跳解析协议（NHRP）用于确定朝向公共互联网络层地址的“NBMA下一跳”的NBMA子网地址（见[1]）。本文档描述了使NHRP能够对共享NBMA网络上的虚拟专用网络（VPN）服务框架内可用的专用互联层地址执行相同功能所需的增强功能。
NHRP is a public internetworking layer based resolution protocol. There is an implicit understanding in [1] that a control message applies to the public address space.
NHRP是一种基于公共互联层的解析协议。[1]中有一种隐含的理解，即控制消息适用于公共广播空间。
Service Providers of Virtual Private Network (VPN) services will offer VPN participants specific service level agreements (SLA) which may include, for example, dedicated routing functions and/or specific QoS levels. A particularly important feature of a VPN service is the ability to use a private address space which may overlap with the address space of another VPN or the Public Internet. Therefore, such an internetworking layer address only has meaning within the VPN in which it exists. For this reason, it is necessary to identify the VPN in which a particular internetworking layer address has meaning, the "scope" of the internetworking layer address.
虚拟专用网络（VPN）服务的服务提供商将向VPN参与者提供特定的服务级别协议（SLA），该协议可能包括，例如，专用路由功能和/或特定的QoS级别。VPN服务的一个特别重要的特性是能够使用可能与另一个VPN或公共互联网的地址空间重叠的私有地址空间。因此，这样的互连层地址仅在其所在的VPN内有意义。出于这个原因，有必要识别特定网络间层地址具有含义的VPN，即网络间层地址的“范围”。
As VPNs are deployed on shared networks, NHRP may be used to resolve a private VPN address to a shared NBMA network address. In order to properly resolve a private VPN address, it is necessary for the NHRP device to be able to identify the VPN in which the address has meaning and determine resolution information based on that "scope".
由于VPN部署在共享网络上，NHRP可用于将专用VPN地址解析为共享NBMA网络地址。为了正确解析私有VPN地址，NHRP设备必须能够识别该地址在其中具有意义的VPN，并基于该“范围”确定解析信息。
As VPN services are added to an NBMA network using NHRP devices, it may be necessary to support the service with legacy NHRP devices that do not have VPN knowledge and so do not explicitly support VPNs. This document describes requirements for "VPN-aware" NHRP entities to support VPN services while communicating with both "VPN-aware" and "non-VPN-aware" NHRP entities.
由于VPN服务是使用NHRP设备添加到NBMA网络的，因此可能需要使用不具备VPN知识的传统NHRP设备来支持该服务，因此不明确支持VPN。本文件描述了“VPN感知”NHRP实体在与“VPN感知”和“非VPN感知”NHRP实体通信时支持VPN服务的要求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[4]中所述进行解释。
In addition to the terminology specified in section 2.1 of [1], the following definitions and acronyms are used:
除[1]第2.1节中规定的术语外，还使用了以下定义和首字母缩略词：
Default Routing Instance -- In the presence of VPNs, all packets are processed (e.g., routed) within the context of a specific VPN. In the case where no VPN is indicated, a packet is processed according to a default VPN, i.e., a Default Routing Instance. This routing instance may be the Public Internet, a particular VPN, etc. The term only has meaning for "VPN-aware" NHRP entities.
默认路由实例——在存在VPN的情况下，所有数据包都在特定VPN的上下文中处理（例如，路由）。在没有指示VPN的情况下，根据默认VPN（即，默认路由实例）处理分组。该路由实例可以是公共互联网、特定VPN等。该术语仅对“VPN感知”NHRP实体具有含义。
Virtual Private Network (VPN) -- in the context of this specification, this term is used as described in [3].
虚拟专用网络（VPN）——在本规范的上下文中，该术语如[3]所述使用。
VPN-aware -- a "VPN-aware" NHRP entity is an NHRP entity that implements the NHRP enhancements for VPNs as defined in this document.
VPN感知——“VPN感知”NHRP实体是一个NHRP实体，它实现了本文档中定义的VPN的NHRP增强功能。
Non-VPN-aware -- a "non-VPN-aware" NHRP entity is an NHRP entity which is deployed as part of a single VPN, but is not VPN-aware. Restrictions applying to non-VPN-aware NHRP entities are outlined below. NHRP devices as specified in [1] are examples of non-VPN-aware entities.
非VPN感知——“非VPN感知”NHRP实体是作为单个VPN的一部分部署的NHRP实体，但不感知VPN。适用于不支持VPN的NHRP实体的限制概述如下。[1]中规定的NHRP设备是非VPN感知实体的示例。
VPN encapsulation -- An LLC/SNAP encapsulation of a PDU with an indication of the VPN to which the PDU belongs. In the case that the underlying NBMA network is an ATM network, VPN encapsulation is specified in section 8 of [2].
VPN封装——PDU的LLC/SNAP封装，指示PDU所属的VPN。在基础NBMA网络是ATM网络的情况下，VPN封装在[2]的第8节中规定。
VPN identifier (VPN-ID) -- in the context of this specification, this term is used as specified in [3].
VPN标识符（VPN-ID）——在本规范的上下文中，该术语的使用如[3]所述。
VPN signalling -- in the context of this specification, this term is used to denote a method to indicate the VPN-ID via control signalling or similar ways in the control path.
VPN信令——在本规范的上下文中，该术语用于表示通过控制信令或控制路径中的类似方式指示VPN-ID的方法。
When supporting NHRP for a VPN, it is necessary to specify to which VPN the NHRP message applies in order to comply with the VPN service level agreement applicable to that VPN.
为VPN支持NHRP时，需要指定NHRP消息适用于哪个VPN，以符合适用于该VPN的VPN服务级别协议。
On some NBMA networks, it is possible to establish a VPN-specific control path between NHRP devices. This is sufficient to identify the NHRP control packets as belonging to the "inherited" VPN. However, when that alternative is not used, the NHRP device must specify the VPN to which an NHRP packet applies in the PDU.
在某些NBMA网络上，可以在NHRP设备之间建立VPN特定的控制路径。这足以将NHRP控制数据包标识为属于“继承的”VPN。然而，当未使用该替代方案时，NHRP设备必须指定在PDU中应用NHRP包的VPN。
It is not useful to add a VPN extension to NHRP control messages because transit NHRP Servers are not required to process the extensions to an NHRP control message (see 5.3 in [1]). NHRP Servers already deployed might resolve the control packet within the scope of the public internetworking layer address space instead of the private address space causing problems in routing.
将VPN扩展添加到NHRP控制消息是没有用的，因为传输NHRP服务器不需要处理NHRP控制消息的扩展（参见[1]中的5.3）。已经部署的NHRP服务器可能会在公共网络互连层地址空间的范围内解析控制数据包，而不是在导致路由问题的私有地址空间内解析控制数据包。
Instead, an LLC/SNAP header with a VPN indication (as specified in Section 4.1 below) will be prepended to the NHRP control message. This solution allows the same VPN-specific LLC/SNAP header to be prepended to PDUs in both the control and data paths.
相反，带有VPN指示的LLC/SNAP报头（如下文第4.1节所述）将预先添加到NHRP控制消息中。此解决方案允许在控制和数据路径中向PDU预先添加相同的VPN特定LLC/SNAP头。
When a VPN-aware NHRP device forwards a packet pertaining to a particular VPN, that device MUST be able to indicate the VPN either:
当感知VPN的NHRP设备转发与特定VPN相关的数据包时，该设备必须能够指示VPN：
a) explicitly through use of the VPN-specific LLC/SNAP header or b) implictly through an indication via VPN signalling.
a) 通过使用特定于VPN的LLC/SNAP头显式地或b）通过VPN信令隐式地指示。
This applies to NHC-NHS, NHS-NHS, and NHS-NHC control messages as well as NHC-NHC shortcut traffic.
这适用于NHC-NHS、NHS-NHS和NHS-NHC控制消息以及NHC-NHC快捷通信。
For case a), the indication of the VPN-ID is via a VPN-specific LLC/SNAP header specified in section 4.2 below. In the case of an underlying ATM network, see also section 8 of [2].
对于情况a），VPN-ID的指示通过以下第4.2节中规定的VPN特定LLC/SNAP报头。对于底层ATM网络，另见[2]第8节。
For case b), the method used to indicate the VPN-ID via VPN signalling depends on the mechanisms available in the underlying network and is outside the scope of this memo. A VPN-aware NHRP entity using VPN signalling SHOULD NOT also indicate the VPN-ID explicity for any PDU on the related path.
对于情况b），通过VPN信令指示VPN-ID的方法取决于底层网络中可用的机制，不在本备忘录的范围内。使用VPN信令的VPN感知NHRP实体也不应明确指示相关路径上任何PDU的VPN-ID。
In transiting an NHRP Server, the VPN identification MAY be forwarded in a different format than was received, however, the same VPN-ID MUST be indicated for the message. For example, a PDU received with an LLC/SNAP header containing a VPN identifier may be forwarded on a control path which was established with an indication of the same VPN without the VPN-specific LLC/SNAP header.
在传输NHRP服务器时，VPN标识可以以不同于接收到的格式转发，但是，必须为消息指示相同的VPN-ID。例如，使用包含VPN标识符的LLC/SNAP报头接收的PDU可以在控制路径上转发，该控制路径是使用没有VPN特定LLC/SNAP报头的相同VPN的指示建立的。
When a VPN capable NHRP entity receives an NHRP message from a VPN-aware NHRP device without a VPN indication via VPN encapsulation or VPN signalling, the message applies to the default routing instance supported by the shared infrastructure. The public Internet or a particular VPN routing realm may be configured as the default routing instance.
当支持VPN的NHRP实体通过VPN封装或VPN信令从支持VPN的NHRP设备接收到NHRP消息而没有VPN指示时，该消息应用于共享基础设施支持的默认路由实例。公共Internet或特定VPN路由领域可以配置为默认路由实例。
A VPN-aware NHRP entity MUST be able to indicate the VPN-ID in one of the ways specified in section 3.1 above. It MAY participate in more than one VPN.
感知VPN的NHRP实体必须能够以上述第3.1节规定的方式之一指示VPN-ID。它可以参与多个VPN。
Because a non-VPN-aware NHRP device does not understand the concept of VPNs, it only supports a single routing instance. Therefore, a non-VPN-aware NHRP entity belongs to exactly one VPN without being aware of it. All internetworking packets sent by that entity are assumed to belong to that VPN (Note that if the current IPv4-based Internet is regarded as just one big VPN, attached IPv4 hosts may e.g. be regarded as being "contained" in that VPN).
因为不支持VPN的NHRP设备不理解VPN的概念，所以它只支持单个路由实例。因此，一个不知道VPN的NHRP实体只属于一个VPN而不知道它。假设该实体发送的所有网络间数据包都属于该VPN（请注意，如果当前基于IPv4的互联网仅被视为一个大型VPN，则连接的IPv4主机可能被视为“包含”在该VPN中）。
In order for a non-VPN-aware NHRP entity to interact with a VPN-aware NHRP entity, the VPN-aware NHRP entity MUST be configured to associate the correct VPN-ID with information received from the non-VPN-aware entity. In other words, the VPN-aware NHRP entity acts as in the case of option b) from section 3.1 where the VPN-ID was indicated via VPN signalling. However, this association is provisioned using administrative means that are beyond the scope of this document instead of via VPN signalling. Further, it MUST be ensured by administrative means that non-VPN-aware NHRP entities only communicate either with other NHRP entities contained in the same VPN, or with VPN-aware NHRP entities with pre- configured information about the related VPN-ID of those non-VPN-aware entities.
为了使非VPN感知NHRP实体与VPN感知NHRP实体交互，必须将VPN感知NHRP实体配置为将正确的VPN-ID与从非VPN感知实体接收到的信息相关联。换句话说，感知VPN的NHRP实体的行为与第3.1节中选项b）的情况相同，其中通过VPN信令指示VPN-ID。但是，此关联是使用超出本文档范围的管理手段而不是通过VPN信令来提供的。此外，必须通过管理手段确保非VPN感知的NHRP实体仅与同一VPN中包含的其他NHRP实体通信，或与具有关于这些非VPN感知实体的相关VPN-ID的预配置信息的VPN感知的NHRP实体通信。
VPN-aware NHRP entities SHALL only send information to non-VPN-aware NHRP entities if that information belongs to the VPN in which the non-VPN-aware entity is contained. Information sent to a non-VPN-aware NHRP entity MUST not include any indication of the VPN-ID.
如果信息属于包含非VPN感知实体的VPN，则感知VPN的NHRP实体只能向非VPN感知NHRP实体发送信息。发送给不支持VPN的NHRP实体的信息不得包含任何VPN-ID指示。
In order to correctly transfer data packets, it is necessary for VPN-aware ingress NHRP clients to know whether their partner is also VPN-aware. If the egress is VPN-aware, the ingress NHC will also use the means described in section 3.1 on an NBMA shortcut to that egress NHC to specify the VPN to which the data packet belongs.
为了正确传输数据包，支持VPN的NHRP客户端需要知道其合作伙伴是否也支持VPN。如果出口感知VPN，则入口NHC还将使用该出口NHC的NBMA快捷方式第3.1节中所述的方式来指定数据包所属的VPN。
For this purpose, a further NHRP extension (in addition to those specified in section 5.3 of [1]) is specified which is called NHRP Device Capabilities extension (see section 4.2 below). This extension currently indicates the VPN capabilities of NHRP source and destination entities, but may also be used in the future for further additions to NHRP to indicate other capabilities as well.
为此，规定了进一步的NHRP扩展（除[1]第5.3节中规定的扩展外），称为NHRP设备能力扩展（见下文第4.2节）。该扩展目前表示NHRP源实体和目标实体的VPN功能，但将来也可能用于进一步添加到NHRP，以表示其他功能。
The NHRP Device Capabilities extension MUST be attached to all NHRP Resolution Requests generated by a VPN-aware source NHRP entity. The device SHOULD set the Source Capabilities field to indicate that it supports VPNs. The compulsory bit MUST be set to zero, so that a non-VPN-aware NHS may safely ignore the extension when forwarding the request. In addition, the A-bit (see section 5.2.1 of [1]) SHOULD be set to indicate that only authoritative next hop information is desired to avoid non-authoritative replies from non-VPN-aware NHRP servers.
NHRP设备功能扩展必须附加到由VPN感知源NHRP实体生成的所有NHRP解析请求。设备应设置Source Capabilities（源能力）字段，以指示其支持VPN。强制位必须设置为零，以便非VPN感知NHS在转发请求时可以安全地忽略扩展。此外，A位（见[1]第5.2.1节）应设置为指示仅需要权威下一跳信息，以避免来自非VPN感知NHRP服务器的非权威回复。
Since a non-VPN-aware NHS is not able to process the NHRP Device Capability extension, Network Admistrators MUST avoid configurations in which a VPN-aware NHRP Client is authoritatively served by a non-VPN-aware NHRP Server.
由于非VPN感知的NHS无法处理NHRP设备能力扩展，因此网络管理员必须避免由非VPN感知的NHRP服务器授权服务VPN感知的NHRP客户端的配置。
If an egress NHS receives an NHRP Resolution Request with an NHRP Device Capability Extension included, it returns an NHRP Resolution Reply with an indication of whether the destination is VPN-aware by correctly setting the target capabilities flag [see Section 4.2].
如果出口NHS接收到包含NHRP设备能力扩展的NHRP解析请求，它将返回NHRP解析回复，并通过正确设置目标能力标志指示目的地是否感知VPN[参见第4.2节]。
If an egress NHS receives an NHRP Resolution Request without an NHRP Device Capability Extension included or with the source capabilities flag indicating that the source NHRP device is non-VPN-aware, it MAY act in one of the following ways:
如果出口NHS接收到NHRP解析请求，但未包括NHRP设备能力扩展，或者源能力标志指示源NHRP设备不支持VPN，则其可以以下方式之一操作：
- It MAY reject the NHRP Resolution Request; this is because the VPN-aware destination will be unable to determine the context of information received on an NBMA shortcut from a non-VPN-aware NHRP source. This is the default case.
- 它可以拒绝NHRP决议请求；这是因为VPN感知目的地将无法确定NBMA快捷方式上从非VPN感知NHRP源接收的信息的上下文。这是默认情况。
- If the destination is also non-VPN-aware, it MAY accept the request and return an NHRP Resolution Reply. By default, the two non-VPN-aware NHRP clients will interact correctly.
- 如果目的地也是非VPN感知的，它可能会接受请求并返回NHRP解析回复。默认情况下，两个不支持VPN的NHRP客户端将正确交互。
- It MAY offer itself as a destination and resolve the request using its own NBMA address, if it has the related capabilities.
- 如果具有相关功能，它可以将自己作为目的地，并使用自己的NBMA地址解决请求。
- If the indicated VPN-ID identifies the default routing instance of the destination, the NHS MAY accept the request and send a corresponding NHRP Resolution Reply.
- 如果指示的VPN-ID标识了目的地的默认路由实例，则NHS可以接受该请求并发送相应的NHRP解析回复。
The NHRP Device Capabilities extension SHOULD NOT be included in the NHRP Register Request and Reply messages.
NHRP设备功能扩展不应包含在NHRP注册请求和回复消息中。
If an NHRP entity receives a PDU with a VPN-ID indicated via VPN encapsulation which is in conflict to a VPN-ID earlier allocated to that communication (e.g. via VPN signalling or administratively via configuration), it SHOULD send back an NHRP error indication (see 5.2.7 of [1]) to the sender indicating error code 16 (VPN mismatch). However, in order to avoid certain security issues, an NHRP entity MAY instead silently drop the packet.
如果NHRP实体接收到一个PDU，该PDU的VPN-ID通过VPN封装表示，与先前分配给该通信的VPN-ID冲突（例如通过VPN信令或通过配置管理），则该实体应向发送方发回一个NHRP错误指示（见[1]中的5.2.7），指示错误代码16（VPN不匹配）。然而，为了避免某些安全问题，NHRP实体可以改为静默地丢弃数据包。
If a VPN-aware NHRP entity receives a packet for a VPN that it does not support, it SHOULD send back an NHRP error indication to the sender with an error code 17 (VPN not supported). However, in order to avoid certain security issues, an NHRP entity MAY instead silently drop the packet.
如果感知VPN的NHRP实体接收到不支持的VPN数据包，则应向发送方发回NHRP错误指示，错误代码为17（不支持VPN）。然而，为了避免某些安全问题，NHRP实体可以改为静默地丢弃数据包。
If a VPN-aware NHS cannot find a route to forward a VPN-related NHRP message, it SHOULD send back an NHRP error indication to the sender with error code 6 (protocol address unreachable). However, in order to avoid certain security issues, an NHRP entity MAY instead silently drop the packet.
如果支持VPN的NHS无法找到转发VPN相关NHRP消息的路由，则应向发送方发回NHRP错误指示，错误代码为6（无法访问协议地址）。然而，为了避免某些安全问题，NHRP实体可以改为静默地丢弃数据包。
In all cases, where an NHRP error indication is returned by a VPN-aware NHRP entity, the incorrect VPN-ID related to this indication SHALL be indicated via VPN encapsulation or VPN signalling, except when sending it to a non-VPN-aware NHRP device (see 3.1 / 3.2 above).
在所有情况下，当感知VPN的NHRP实体返回NHRP错误指示时，应通过VPN封装或VPN信令指示与该指示相关的错误VPN-ID，除非将其发送到感知VPN的非NHRP设备（见上文3.1/3.2）。
The format of the VPN encapsulation header is as follows:
VPN封装头的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xAA | 0xAA | 0x03 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x5E | 0x00 | 0x08 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAD | OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPN Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC encapsulated PDU (up to 2^16 - 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xAA | 0xAA | 0x03 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x5E | 0x00 | 0x08 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAD | OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPN Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC encapsulated PDU (up to 2^16 - 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It consists of the following parts:
它由以下部分组成：
- LLC/SNAP indication (0xAA-AA-03) - OUI (of IANA) (0x00-00-5E) - PID allocated by IANA for VPN encapsulation (0x00-08) - PAD field (inserted for 32-bit alignment) this field is coded as 0x00, and is ignored on receipt - VPN related OUI (see [3]) - VPN Index (see [3]).
- LLC/SNAP指示（0xAA-AA-03）-OUI（IANA的）（0x00-00-5E）-IANA为VPN封装分配的PID（0x00-08）-PAD字段（插入用于32位对齐）此字段编码为0x00，在收到时忽略-VPN相关OUI（参见[3]）-VPN索引（参见[3]）。
When this encapsulation header is used, the remainder of the PDU MUST be structured according to the appropriate LLC/SNAP format (i.e. that would have been used without the additional VPN encapsulation header). Correspondingly, the following figure shows how NHRP messages are transferred using VPN encapsulation:
使用此封装头时，PDU的其余部分必须按照适当的LLC/SNAP格式进行结构（即，如果没有额外的VPN封装头，将使用该格式）。相应地，下图显示了如何使用VPN封装传输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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xAA | 0xAA | 0x03 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x5E | 0x00 | 0x08 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAD | OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPN Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xAA | 0xAA | 0x03 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x5E | 0x00 | 0x03 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NHRP message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xAA | 0xAA | 0x03 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x5E | 0x00 | 0x08 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAD | OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPN Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xAA | 0xAA | 0x03 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x5E | 0x00 | 0x03 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NHRP message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following example shows how IP packets are transferred by VPN encapsulation:
以下示例显示了如何通过VPN封装传输IP数据包：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xAA | 0xAA | 0x03 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x5E | 0x00 | 0x08 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAD | OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPN Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xAA | 0xAA | 0x03 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x00 | 0x08 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP PDU (up to 2^16 - 24 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xAA | 0xAA | 0x03 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x5E | 0x00 | 0x08 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAD | OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPN Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xAA | 0xAA | 0x03 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x00 | 0x08 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP PDU (up to 2^16 - 24 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the NHRP device capabilities extension is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|u| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C: Compulsory = 0 (not a compulsory extension) u: Unused and MUST be set to zero. Type = 0x0009 Length = 0x0008
C:强制=0（非强制扩展）u:未使用，必须设置为零。类型=0x0009长度=0x0008
Source Capabilities field:
源功能字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused |V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused |V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V bit:
V位：
0x0 - the source NHRP device is non-VPN-aware 0x1 - the source NHRP device is VPN-aware
0x0-源NHRP设备不支持VPN 0x1-源NHRP设备支持VPN
The unused bits MUST be set to zero on transmission and ignored on receipt.
未使用的位必须在传输时设置为零，在接收时忽略。
Target Capabilities field:
目标能力领域：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused |V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused |V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V bit:
V位：
0x0 - the destination NHRP device is non-VPN-aware 0x1 - the destination NHRP device is VPN-aware
0x0-目标NHRP设备不支持VPN 0x1-目标NHRP设备支持VPN
The unused bits MUST be set to zero on transmission and ignored on receipt.
未使用的位必须在传输时设置为零，在接收时忽略。
The following further Error Codes are defined in addition to those specified in section 5.2.7 of [1]):
除了[1]第5.2.7节中规定的错误代码外，还定义了以下其他错误代码：
16 - VPN mismatch
16-VPN不匹配
This error code is returned by a VPN-capable NHRP device, if it receives a PDU with a VPN-ID in the LLC/SNAP header different from the VPN-ID which had been specified earlier via VPN signalling.
如果支持VPN的NHRP设备接收到LLC/SNAP报头中VPN-ID与先前通过VPN信令指定的VPN-ID不同的PDU，则会返回此错误代码。
17 - VPN not supported
17-不支持VPN
This error code is returned by a VPN-capable NHRP device, if it receives an NHRP message for a VPN that it does not support.
如果支持VPN的NHRP设备接收到不支持的VPN的NHRP消息，则返回此错误代码。
For any VPN application, it is important that VPN-related information is not misdirected to other VPNs and is not accessible when being transferred across a public or shared infrastructure. It is therefore RECOMMENDED to use the VPN support functions specified in this document in combination with NHRP authentication as specified in section 5.3.4 of [1]. Section 5.3.4.4 of [1] also provides further information on general security considerations related to NHRP.
对于任何VPN应用程序，重要的是VPN相关信息不会被错误地定向到其他VPN，并且在通过公共或共享基础设施传输时不可访问。因此，建议将本文件规定的VPN支持功能与[1]第5.3.4节规定的NHRP认证结合使用。[1]第5.3.4.4节还提供了与NHRP相关的一般安全注意事项的进一步信息。
In cases where the NHRP entity does not trust all of the NHRP entities, or is uncertain about the availability of the end-to-end NHRP authentication chain, it may use IPsec for confidentiality, integrity, etc.
如果NHRP实体不信任所有NHRP实体，或者不确定端到端NHRP身份验证链的可用性，则可以使用IPsec来实现机密性、完整性等。
The LLC/SNAP protocol ID 0x00-08 for VPN encapsulation had already been allocated by IANA in conjunction with [2]. This specification does not require the allocation of any additional LLC/SNAP protocol IDs beyond that.
用于VPN封装的LLC/SNAP协议ID 0x00-08已由IANA与[2]一起分配。除此之外，本规范不要求分配任何额外的LLC/SNAP协议ID。
It should be noted that IANA - as the owner of the VPN-related OUI: 0x00-00-5E - is itself also a VPN authority which may allocate VPN indices to identify VPNs. The use of these particular VPN indices within the context of this specification is reserved, and requires allocation and approval by the IESG in accordance with RFC 2434.
应该注意的是，IANA作为VPN相关OUI:0x00-00-5E的所有者，本身也是一个VPN机构，可以分配VPN索引来识别VPN。保留在本规范上下文中使用这些特定VPN索引，并要求IESG根据RFC 2434进行分配和批准。
References
工具书类
[1] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy, "NMBA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[1] Luciani，J.，Katz，D.，Piscitello，D.，Cole，B.和N.Doraswamy，“NMBA下一跳解析协议（NHRP）”，RFC 2332，1998年4月。
[2] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[2] Grossman，D.和J.Heinanen，“ATM适配层5上的多协议封装”，RFC 2684，1999年9月。
[3] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999.
[3] Fox，B.和B.Gleeson，“虚拟专用网络标识符”，RFC 26851999年9月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Authors' Addresses
作者地址
Barbara A. Fox Equipe Communications 100 Nagog Park Acton, MA 01720
芭芭拉·A·福克斯设备通讯公司马萨诸塞州纳戈尔公园阿克顿100号01720
Phone: +1-978-795-2009
EMail: bfox@equipecom.com
Phone: +1-978-795-2009
EMail: bfox@equipecom.com
Bernhard Petri Siemens AG Hofmannstr. 51 Munich, Germany, D-81359
Bernhard Petri西门子公司Hofmannstr。51德国慕尼黑，D-81359
Phone: +49 89 722-34578
EMail: bernhard.petri@icn.siemens.de
Phone: +49 89 722-34578
EMail: bernhard.petri@icn.siemens.de
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。