[要約] RFC 2735は、仮想プライベートネットワーク（VPN）のためのNHRP（Next Hop Resolution Protocol）のサポートに関するものです。このRFCの目的は、VPN環境でのネットワーク接続の効率化とセキュリティの向上を実現することです。
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.
Copyright（c）The Internet Society（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 Next Hop Resolution Protocol（NHRP）を使用して、パブリックインターネットワークレイヤーアドレスに向けて「NBMA Next Hop」の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）サービスのサービスプロバイダーは、たとえば専用のルーティング関数や特定のQoSレベルを含む可能性のあるVPN参加者特定のサービスレベル契約（SLA）を提供します。VPNサービスの特に重要な機能は、別の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アドレスを解決できます。プライベート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の知識がないため、VPNを明示的にサポートしないLegacy NHRPデバイスでサービスをサポートする必要がある場合があります。このドキュメントでは、「VPN-Aware」サービスをサポートしながら、「VPNアウェア」および「非VPNアウェア」NHRPエンティティの両方と通信しながら、「VPN-Aware」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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、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-AWARE-「VPN-AWARE」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の一部として展開されているがVPN-AwareではないNHRPエンティティです。非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をサポートする場合、そのVPNに適用されるVPNサービスレベル契約に準拠するために、NHRPメッセージが適用される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.
Transit NHRPサーバーは拡張機能をNHRP制御メッセージに処理するために必要ではないため、NHRP制御メッセージにVPN拡張機能を追加することは役に立ちません（[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コントロールメッセージに加えます。このソリューションにより、同じVPN固有のLLC/SNAPヘッダーを、コントロールパスとデータパスの両方でPDUSに準備することができます。
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に関連するパケットを転送する場合、そのデバイスは次のことを示すことができなければなりません。
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表示なしで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で指定された方法の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エンティティは、それを認識せずに1つのVPNに属します。そのエンティティが送信したすべてのインターネットワークパケットは、そのVPNに属すると想定されています（現在のIPv4ベースのインターネットが1つの大きな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エンティティは、VPN-IDがVPNシグナル伝達を介して示されたセクション3.1からのオプションb）の場合に作用します。ただし、この関連付けは、VPNシグナリングを介してではなく、このドキュメントの範囲を超えた管理手段を使用して提供されます。さらに、非VPN認識NHRPエンティティは、同じ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-AWARE NHRPエンティティは、その情報が非VPN対応エンティティが含まれているVPNに属している場合にのみ、非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を認識しているIngress NHRPクライアントがパートナーもVPN対応であるかどうかを知る必要があります。出口がVPNが認識している場合、Ingress NHCは、NBMAショートカットのセクション3.1で説明されている手段をその出力NHCの手段も使用して、データパケットが属する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デバイス機能拡張と呼ばれるさらなるNHRP拡張（[1]のセクション5.3で指定されているものに加えて）が指定されています（以下のセクション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ビット（[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.
NHRPデバイスの機能拡張機能を処理できないため、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].
Egress NHSがNHRPデバイス機能拡張機能を使用してNHRP解像度要求を受信した場合、ターゲット機能フラグを正しく設定することにより、宛先がVPNが認識しているかどうかを示すNHRP解像度の返信を返します[セクション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解像度の返信を返す場合があります。デフォルトでは、2つの非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を介して示されたVPN-IDでPDUを受け取った場合、その通信に以前に割り当てられた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のパケットを受信した場合、エラーコード17（VPNがサポートされていない）で送信者にNHRPエラー表示を送信する必要があります。ただし、特定のセキュリティの問題を回避するために、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カプセル化または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カプセル化のためにIANAによって割り当てられたPID（0x00-08） - パッドフィールド（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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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：compururedory = 0（強制拡張機能ではありません）u：未使用でゼロに設定する必要があります。type = 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-awareではありません0x1-ソースNHRPデバイスはvpn-awareです
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-awareではありません0x1-宛先NHRPデバイスはvpn-awareです
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がサポートしていない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で指定されているように、このドキュメントで指定されたVPNサポート関数を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は、[2]と併せてIANAによってすでに割り当てられていました。この仕様では、それ以上の追加の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インデックスの使用は予約されており、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] Luciani、J.、Katz、D.、Piscitello、D.、Cole、B。and N. Doraswamy、「NMBA Next Hop Resolution Protocol（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 2685、1999年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
Barbara A. Fox Equipe Communications 100 Nagog Park Acton、MA 01720
Phone: +1-978-795-2009
EMail: bfox@equipecom.com
Bernhard Petri Siemens AG Hofmannstr. 51 Munich, Germany, D-81359
Bernhard Petri Siemens Ag Hofmannstr。51ドイツ、ミュンヘン、D-81359
Phone: +49 89 722-34578
EMail: bernhard.petri@icn.siemens.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。