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
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）は、公衆インターネットワーキングレイヤアドレス（[1]参照）に向かって「NBMA次のホップ」のNBMAサブネットワークアドレスを決定するために使用されます。この文書では、共有NBMAネットワーク上の仮想プライベートネットワーク（VPN）サービスの枠組み内で利用可能なプライベートインターネットワーキングレイヤアドレスに同じ機能を実行するためにNHRPを可能にするために必要な機能強化について説明します。
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参加者、例えば、専用のルーティング機能および/または特定のQoSレベルを含むことができ、特定のサービス・レベル・アグリーメント（SLA）を提供します。 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は、共有NBMAネットワークアドレスにプライベートVPNアドレスを解決するために使用することができます。 NHRPデバイスがアドレス意味を有するVPNを識別し、その「範囲」に基づいて、解像度情報を決定できるようにするために適切にプライベート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の知識を持っていないので、明示的にVPNをサポートしていないレガシーNHRPデバイスとサービスをサポートする必要があるかもしれません。この文書は、「対応のVPN」と「非VPN対応の」NHRP実体の両方と通信しながらVPNサービスをサポートするために、「VPN対応の」NHRPエンティティのための要件について説明します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[4]。
In addition to the terminology specified in section 2.1 of [1], the following definitions and acronyms are used:
セクション2.1で指定された用語に加えて、[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実体は、この文書で定義されているVPNのNHRPの拡張機能を実装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が属するVPNの指示を有するPDUのLLC / SNAPカプセル化。下地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固有の制御パスを確立することが可能です。これは「継承」VPNに属するものとしてNHRP制御パケットを識別するのに十分です。その代替が使用されていない場合しかし、NHRP装置は、NHRPパケットがPDUに適用する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.
トランジットNHRPサーバがNHRP制御メッセージへの拡張を処理するために必要とされないので（[1]に5.3を参照）NHRP制御メッセージにVPN拡張子を追加することは有用ではありません。既に展開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制御メッセージの先頭に付加されます。この溶液は、同じVPNに固有のLLC / SNAPヘッダは制御及びデータパスの両方でのPDUの先頭に付加されることを可能にします。
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）implictly 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は、メッセージのために示されなければなりません。たとえば、PDUは、VPN識別子を含むLLC / SNAPヘッダで受信された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指示なしVPN対応NHRP装置からNHRPメッセージを受信すると、メッセージは、共有インフラストラクチャによってサポートされているデフォルトルーティングインスタンスに適用されます。公共のインターネットまたは特定の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対応のエンティティから受信した情報を正しいVPN-IDを関連付けるように構成されなければなりません。換言すれば、VPN対応のNHRPエンティティは、VPN-IDはVPNシグナリングを介して指示されたセクション3.1からの）オプションBの場合のように作用します。しかし、この関連は、この文書の範囲を超えて代わりのVPNシグナリングを介している管理手段を使用してプロビジョニングされています。さらに、非VPN対応NHRPエンティティのみ、またはそれらの関連するVPN-IDに関する事前構成情報をVPN-認識NHRPエンティティと同じVPNに含まれる他のNHRPエンティティとのいずれかで通信する管理手段により確保されなければなりません非VPN対応のエンティティ。
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-認識しているかどうかを知るためにVPN対応の進入NHRPクライアントのために必要です。出口は、VPN対応の場合、入口NHCは、データパケットが属するVPNを指定するために、その出口NHCにNBMAショートカットのセクション3.1に記載の手段を使用します。
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解決要求に取り付けなければなりません。デバイスは、それがVPNをサポートしていることを示すために、ソースの機能フィールドを設定する必要があります。要求を転送するとき、非VPN対応NHS安全拡張を無視することができるように強制ビットは、ゼロに設定しなければなりません。加えて、Aビットのみ権限の次のホップ情報は非VPN対応NHRPサーバから権限のない応答を回避することが望まれることを示すように設定されるべきである（[1]のセクション5.2.1を参照）。
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デバイス機能拡張を処理することができませんので、ネットワークAdmistratorsは、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装置は非VPN対応であることを示すソース機能フラグでNHRP解決リクエストを受信した場合、それは次のいずれかの方法で作用し得ます。
- 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対応先が非VPN対応NHRP源からNBMAショートカット上で受信された情報のコンテキストを決定することができないであろうからです。これはデフォルトの場合です。
- 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エンティティがVPN-IDを有するPDUを受信した場合（VPN-IDは、以前（例えば、VPNシグナリングを介して、または管理コンフィギュレーションを介して）その通信に割り当てに競合しているVPNカプセル化、それはNHRPエラー表示を返すべきである介し示しますエラーコード16（VPN不一致）を示す送信者に[1]）の5.2.7を参照。しかし、特定のセキュリティ上の問題を避けるために、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用のパケットを受信した場合、それはエラーコード17と送信者にNHRPエラー表示を返送すべきである（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メッセージを転送するためのルートを見つけることができない場合は、エラーコード6（到達不能プロトコルアドレス）と、送信者にNHRPエラー表示を返すべきです。しかし、特定のセキュリティ上の問題を避けるために、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).
NHRPエラー表示がVPN対応NHRPエンティティによって返された全ての場合において、この指示に関連する誤ったVPN-IDは、非VPN対応NHRPに送信する場合を除き、VPNカプセル化またはVPNシグナリングを介して表示しなければなりませんデバイス（上記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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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） - VPNカプセル化（0x00-08）のためにIANAによって割り当てられたPID - （32ビットのアライメントのために挿入）PADフィールドがこの（[3]参照）VPN関連OUI - - VPNインデックス（[3]参照）フィールドが0×00のように符号化され、そして受信時には無視されます。
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の残りの部分（すなわち、追加のVPNカプセル化ヘッダなしで使用されてきたであろうと）適切なLLC / SNAPフォーマットに従って構成されなければなりません。これに対応し、次の図は、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following example shows how IP packets are transferred by VPN encapsulation:
次の例では、IPパケットが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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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シグナリングを介して指定されたVPN-IDとは異なるLLC / SNAPヘッダにVPN-IDを有するPDUを受信した場合、このエラーコードは、VPN対応NHRPデバイスによって返されます。
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に誤った方向に向けず、公共または共有インフラストラクチャを介して転送されたときにアクセスできないことが重要です。したがって、[1]のセクション5.3.4で指定されるようにNHRP認証と組み合わせて、この文書で指定されたVPNサポート機能を使用することが推奨されます。 [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.
0x00-00-5E - また、VPNを識別するために、VPNインデックスを割り当てることができるVPN権限自体である：VPN関連OUIの所有者として - IANAがあることに留意されたいです。本明細書の文脈の中で、これらの特定のVPNインデックスの使用が予約されており、RFC 2434に従って割り当てとIESGの承認を必要とします。
References
リファレンス
[1] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy, "NMBA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[1]ルチアーニ、J.、カッツ、D.、Piscitello、D.、コール、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]グロスマン、D.およびJ. Heinanen、RFC 2684、1999年9月 "ATMアダプテーションレイヤ5の上にマルチプロトコルカプセル化"。
[3] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999.
[3]フォックス、B.及びB.グリーソン、 "仮想プライベートネットワーク識別子"、RFC 2685、1999年9月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
Authors' Addresses
著者のアドレス
Barbara A. Fox Equipe Communications 100 Nagog Park Acton, MA 01720
バーバラ・A.フォックスエキップ・コミュニケーションズ100 Nagog公園、アクトン、MA 01720
Phone: +1-978-795-2009 EMail: bfox@equipecom.com
電話：+ 1-978-795-2009 Eメール：bfox@equipecom.com
Bernhard Petri Siemens AG Hofmannstr. 51 Munich, Germany, D-81359
ベルンハルト・ペトリシーメンスAG Hofmannstr。 51ミュンヘン、ドイツ、D-81359
Phone: +49 89 722-34578 EMail: bernhard.petri@icn.siemens.de
電話：+49 89 722-34578 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。