RFC2735 日本語訳
2735 NHRP Support for Virtual Private Networks. B. Fox, B. Petri. December 1999. (Format: TXT=26451 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Fox
Request for Comments: 2735 Equipe Communications
Category: Standards Track B. Petri
Siemens AG
December 1999
コメントを求めるワーキンググループB.フォックスの要求をネットワークでつないでください: 2735年のEquipeコミュニケーションカテゴリ: 標準化過程B.ペトリジーメンス株式会社1999年12月
NHRP Support for Virtual Private Networks
仮想私設網のNHRPサポート
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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プロトコル(NHRP)は、公共のインターネットワーキング層のアドレスに向かって「次のNBMAは跳ぶ」NBMAサブネットワークアドレスを決定するのに使用されます。([1])を見てください。 このドキュメントはNHRPがVirtual兵士のNetwork(VPN)のフレームワークの中で利用可能なアドレスが共有されたNBMAネットワークで調整する個人的なインターネットワーキング層のために同じ機能を実行するのを可能にするのに必要な増進について説明します。
1. Introduction
1. 序論
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.
Virtual兵士のNetwork(VPN)サービスのサービスProvidersは例えば、ひたむきな経路選択機能、そして/または、特定のQoSレベルを含むかもしれない特定のサービスレベル協定(SLA)をVPN関係者に提供するでしょう。 特に重要なVPNサービスの特徴は別のVPNのアドレス空間に重なるかもしれないプライベート・アドレススペースかPublicインターネットを使用する能力です。 したがって、そのようなインターネットワーキング層のアドレスはそれが存在するVPNの中に意味を持っているだけです。 この理由に、特定のインターネットワーキング層のアドレスが意味を持っているVPNを特定するのが必要です、インターネットワーキングの「範囲」層のアドレス。
Fox & Petri Standards Track [Page 1] RFC 2735 NHRP Support for Virtual Private Networks December 1999
フォックスとペトリ標準化過程[1ページ]RFC2735NHRPは、仮想私設網のために12月が1999であるとサポートします。
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".
VPNsが共用回線網で配布されるとき、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知識を持っていないので明らかにVPNsをサポートしないレガシーNHRPデバイスでサービスをサポートするのが必要であるかもしれません。 そして、このドキュメントが「VPN意識している」NHRP実体が両方が「VPN意識していた」状態で交信している間にVPNにサービスをサポートするという要件について説明する、「非VPN意識する、」 NHRP実体。
2. Overview of NHRP VPN Support
2. NHRP VPNサポートの概要
2.1 Terminology
2.1 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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.
VPNsの面前でデフォルトルート設定Instance、すべてのパケットが特定のVPNの文脈の中で処理されます(例えば、掘ります)。 VPNが全く示されない場合では、デフォルトVPN(すなわち、Defaultルート設定Instance)によると、パケットは処理されます。 このルーティングインスタンスはPublicインターネット、特定のVPNであるかもしれませんなど。 用語には、「VPN意識している」NHRP実体のための意味があるだけです。
Virtual Private Network (VPN) -- in the context of this specification, this term is used as described in [3].
この仕様の文脈の仮想の兵士のNetwork(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実体はVPNsのために本書では定義されるように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で指定されます。
Fox & Petri Standards Track [Page 2] RFC 2735 NHRP Support for Virtual Private Networks December 1999
フォックスとペトリ標準化過程[2ページ]RFC2735NHRPは、仮想私設網のために12月が1999であるとサポートします。
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を示すメソッドか同様の方法を指示するのに使用されます。
2.2 VPN Support Overview
2.2 VPNサポート概要
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 ServersがNHRPコントロールメッセージに拡大を処理する必要はないので、NHRPコントロールメッセージにVPN拡張子を追加するのは役に立ちません。([1])で5.3を見てください。 既に配布されたNHRP Serversは、ルーティングで問題を起こしながら、プライベート・アドレススペースの代わりに公共のインターネットワーキング層のアドレス空間の範囲の中でコントロールパケットを分解するかもしれません。
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指示(以下のセクション4.1で指定されるように)があるLLC/SNAPヘッダーはNHRPコントロールメッセージにprependedされるでしょう。 このソリューションは、同じVPN特有のLLC/SNAPヘッダーがコントロールとデータ経路の両方のPDUsにprependedされるのを許容します。
3. NHRP VPN Operation
3. NHRP VPN操作
3.1 VPN-Aware NHRP Operation
3.1 VPN意識しているNHRP操作
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) 明らかに、LLC/SNAPヘッダーかb)はVPN合図を通してVPN特有の使用を通して、指示でimplictlyします。
This applies to NHC-NHS, NHS-NHS, and NHS-NHC control messages as well as NHC-NHC shortcut traffic.
これはNHC-NHS、NHS-NHS、およびNHC-NHC近道のトラフィックと同様にNHS-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)のために、下のセクション4.2で指定されたVPN特有のLLC/SNAPヘッダーを通してVPN-IDのしるしはあります。 また、基本的なATMネットワークの場合では、[2]のセクション8を見てください。
Fox & Petri Standards Track [Page 3] RFC 2735 NHRP Support for Virtual Private Networks December 1999
フォックスとペトリ標準化過程[3ページ]RFC2735NHRPは、仮想私設網のために12月が1999であるとサポートします。
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が基本的なネットワークで利用可能なメカニズムによって、このメモの範囲の外にあるのを示していました。 関連する経路のどんなPDUのためのVPN意識しているまた、SHOULD NOTに合図するNHRP実体使用VPNがVPN-IDを示すのをexplicity。
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 Serverを通過する際に、受け取ったのと異なった形式でVPN識別を進めるかもしれなくて、しかしながら、メッセージのために同じVPN-IDを示さなければなりません。 例えば、同じVPNのしるしでVPN特有のLLC/SNAPヘッダーなしで確立されたコントロール経路でLLC/SNAPヘッダーがVPN識別子を含んでいて受け取られたPDUを進めるかもしれません。
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デバイスからVPN指示なしでNHRPメッセージを受け取るとき、メッセージは共有されたインフラストラクチャによってサポートされたデフォルトルーティングインスタンスに適用されます。 公共のインターネットか特定のVPNルーティング分野がデフォルトルーティングインスタンスとして構成されるかもしれません。
3.2 Interactions of VPN-aware and non-VPN-aware NHRP entities
そして、VPN意識することの3.2回の相互作用、非VPN意識する、NHRP実体
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を示すことができなければなりません。 それは1VPNに参加するかもしれません。
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デバイスはVPNsの概念を理解しないで、それはただ一つのルーティングインスタンスをサポートするだけです。 したがって、a、非VPN意識する、それを意識していなくて、NHRP実体はちょうど1VPNに属します。 その実体によって送られたすべてのインターネットワーキングパケットがその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.
aのために中で注文してください、非VPN意識する、VPN意識しているNHRP実体で相互作用させるNHRP実体、VPN意識している非実体から受け取る情報に正しいVPN-IDを関連づけるためにVPN意識しているNHRP実体を構成しなければなりません。 言い換えれば、VPN意識しているNHRP実体はVPN-IDがVPN合図を通して示されたセクション3.1からのオプションb)に関するケースのように行動します。 しかしながら、VPN合図を通した代わりにこのドキュメントの範囲にある管理手段を使用することでこの協会は食糧を供給されます。 さらに、管理手段でそれを確実にしなければならない、それ、非VPN意識する、NHRP実体が同じVPNに含まれている他のNHRP実体、またはそれらの関連するVPN-IDのあらかじめ構成された情報があるVPN意識しているNHRP実体で交信するだけである、非VPN意識する、実体。
Fox & Petri Standards Track [Page 4] RFC 2735 NHRP Support for Virtual Private Networks December 1999
フォックスとペトリ標準化過程[4ページ]RFC2735NHRPは、仮想私設網のために12月が1999であるとサポートします。
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意識しているNHRP実体SHALLが情報を送るだけである、非VPN意識する、NHRP実体がその情報であるなら中でVPNに属す、どれ、非VPN意識する、実体は含まれているか。 情報がaに発信した、非、-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はデータ・パケットが属する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.
このために、aはNHRP拡張子を促進します。(指定されたものに加えて、NHRP Device Capabilities拡張子と呼ばれる[1])のセクション5.3は指定されます(下のセクション4.2を見てください)。 この拡張子は、現在NHRPソースと目的地実体のVPN能力を示しますが、また、NHRPへのさらなる追加がまた、他の能力を示すのに将来、使用されるかもしれません。
3.3 Handling of the NHRP Device Capabilities extension
3.3 NHRP Device Capabilities拡張子の取り扱い
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.
VPN意識しているソースNHRP実体によって生成されたすべてのNHRP Resolution RequestsにNHRP Device Capabilities拡張子を付けなければなりません。 デバイスSHOULDは、Source Capabilities分野にVPNsをサポートするのを示すように設定します。 強制的なビットをゼロに設定しなければなりません、そのように、そのa、非VPN意識する、要求を転送するとき、NHSは安全に拡大を無視するかもしれません。 追加、A-ビット、([1]) .1セクション5.2SHOULDが次の正式のホップ情報だけが非正式の回答を避けることが望まれている示すセットであると考えてください、非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.
a、非VPN意識する、NHSがNHRP Device Capability拡張子を処理できない、Network AdmistratorsはVPN意識しているNHRP ClientがVPN意識している非NHRP Serverによって厳然と役立たれている構成を避けなければなりません。
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].
出口であるなら、NHRP Device Capability Extensionが含まれている状態で、NHSはNHRP Resolution Requestを受けて、それは目的地がVPN正しく目標能力旗を設定することによって意識しているかどうか[セクション4.2を見てください]しるしでNHRP Resolution Replyを返します。
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:
NHRP Device Capability Extensionを含んでいることなしでソース能力旗が、ソースNHRPデバイスがそうであることを示していてNHSが出口であるならNHRP Resolution Requestを受ける、非VPN意識する、それは以下を以下の方法の1つで活動させるかもしれません。
Fox & Petri Standards Track [Page 5] RFC 2735 NHRP Support for Virtual Private Networks December 1999
フォックスとペトリ標準化過程[5ページ]RFC2735NHRPは、仮想私設網のために12月が1999であるとサポートします。
- 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 Resolution Requestを拒絶するかもしれません。 これがVPN意識している目的地がNBMA近道にaから受け取られた情報の文脈を決定できないからである非、-、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 Resolution Replyを返すかもしれません。 デフォルトで、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 MAYは要請を受け入れて、対応するNHRP Resolution Replyを送ります。
The NHRP Device Capabilities extension SHOULD NOT be included in the NHRP Register Request and Reply messages.
NHRP Device Capabilities拡張子SHOULD NOT、NHRP Register RequestとReplyメッセージで含められてください。
3.4 Error handling procedures
3.4 エラー処理手順
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.
a VPN-IDが示されている状態でNHRP実体がPDUを受けるならVPN-IDとの闘争では、より早いのはコミュニケーション(例えば、構成で行政上合図するVPNを通した)をそれに割り当てました、それということであるVPNカプセル化でSHOULDがNHRP誤り表示を返送する、(見る、5.2、.7、誤りを示す送付者への[1])では、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のためにパケットを受けるなら、どんなサポートもしないで、SHOULDであることはエラーコード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メッセージを転送するためにルートを見つけることができないで、それがSHOULDであることを意識しているaであるなら、エラーコード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).
すべての場合では、VPNの意識しているNHRP実体、この指示SHALLに関連する不正確なVPN-IDによってVPNカプセル化かVPN合図を通してNHRP誤り表示を返すところで示されてください、それをaに送る時を除いて非VPN意識する、NHRPデバイス(上の3.1 / 3.2を見ます)。
Fox & Petri Standards Track [Page 6] RFC 2735 NHRP Support for Virtual Private Networks December 1999
フォックスとペトリ標準化過程[6ページ]RFC2735NHRPは、仮想私設網のために12月が1999であるとサポートします。
4. NHRP Packet Formats
4. NHRPパケット・フォーマット
4.1 VPN encapsulation
4.1 VPNカプセル化
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| 0×03| 0×00| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×00| 0x5E| 0×00| 0×08| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パッド| OUI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPNインデックス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDU(最大2^16--16の八重奏)であるとカプセル化されたLLC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]).
- PIDはVPNのために、IANAで、カプセル化(0×00-08)を割り当てました--PADがこの分野をさばくという(32ビットの整列のために、挿入されます)LLC/SNAP指示(0xAA-AA-03)(OUI(IANAの)(0×00 00-5E))は、0×00としてコード化されて、領収書の上で無視されます--VPNはOUIを関係づけました。([3])を見てください--、VPN Index、([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 MUSTでは、適切なLLC/SNAP形式に従って、構造化されてください(すなわち、それは追加VPNカプセル化ヘッダーなしで使用されたでしょう)。 以下の図はNHRPメッセージがVPNカプセル化を使用することでどうわたっているかを対応する、示しています:
Fox & Petri Standards Track [Page 7] RFC 2735 NHRP Support for Virtual Private Networks December 1999
フォックスとペトリ標準化過程[7ページ]RFC2735NHRPは、仮想私設網のために12月が1999であるとサポートします。
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| 0×03| 0×00| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×00| 0x5E| 0×00| 0×08| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パッド| OUI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPNインデックス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xAA| 0xAA| 0×03| 0×00| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×00| 0x5E| 0×00| 0×03| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NHRPメッセージ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 0×03| 0×00| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×00| 0x5E| 0×00| 0×08| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パッド| OUI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPNインデックス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xAA| 0xAA| 0×03| 0×00| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×00| 0×00| 0×08| 0×00| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP PDU(最大2^16--24の八重奏)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fox & Petri Standards Track [Page 8] RFC 2735 NHRP Support for Virtual Private Networks December 1999
フォックスとペトリ標準化過程[8ページ]RFC2735NHRPは、仮想私設網のために12月が1999であるとサポートします。
4.2 NHRP device capabilities extension
4.2 NHRPデバイス能力拡張子
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| タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース能力| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目標能力| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C: Compulsory = 0 (not a compulsory extension)
u: Unused and MUST be set to zero.
Type = 0x0009
Length = 0x0008
C: コンパルソリーは0(強制的な拡大でない)uと等しいです: そして、未使用、ゼロに設定しなければなりません。 =0×0009長さ=の0×0008をタイプしてください。
Source Capabilities field:
ソース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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 未使用|V| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V bit:
Vに噛み付きました:
0x0 - the source NHRP device is non-VPN-aware
0x1 - the source NHRP device is VPN-aware
0×0、--、ソースNHRPデバイスがそうである非VPN意識する、0×1、--ソースNHRPデバイスがVPN意識している
The unused bits MUST be set to zero on transmission
and ignored on receipt.
未使用のビットをトランスミッションのときにゼロに設定されて、領収書の上で無視しなければなりません。
Fox & Petri Standards Track [Page 9] RFC 2735 NHRP Support for Virtual Private Networks December 1999
フォックスとペトリ標準化過程[9ページ]RFC2735NHRPは、仮想私設網のために12月が1999であるとサポートします。
Target Capabilities field:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 未使用|V| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V bit:
Vに噛み付きました:
0x0 - the destination NHRP device is non-VPN-aware
0x1 - the destination NHRP device is VPN-aware
0×0、--、目的地NHRPデバイスがそうである非VPN意識する、0×1、--目的地NHRPデバイスがVPN意識している
The unused bits MUST be set to zero on transmission
and ignored on receipt.
未使用のビットをトランスミッションのときにゼロに設定されて、領収書の上で無視しなければなりません。
4.3 Error Codes
4.3 誤りコード
The following further Error Codes are defined in addition to those specified in section 5.2.7 of [1]):
以下の一層のError Codesは[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デバイスによって返されます、VPN-IDと共に、より早くVPN合図を通して指定されたVPN-IDと異なったLLC/SNAPヘッダーで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メッセージを受け取るなら。
5. Security Considerations
5. セキュリティ問題
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関連の情報が他のVPNsに的外れでなく、また公共の、または、共有されたインフラストラクチャの向こう側に移す場合アクセス可能でないことは、重要です。 したがって、それは本書ではセクション5.3.4における指定されるとしてのNHRP認証と組み合わせて[1]について指定されたVPN支援機能を使用するRECOMMENDEDです。 セクション5.3 .4 .4、また、[1]は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を使用するかもしれません。
Fox & Petri Standards Track [Page 10] RFC 2735 NHRP Support for Virtual Private Networks December 1999
フォックスとペトリ標準化過程[10ページ]RFC2735NHRPは、仮想私設網のために12月が1999であるとサポートします。
6. IANA Considerations
6. IANA問題
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.
LLC/SNAPはカプセル化がIANAによって既に[2]に関連して割り当てられたVPNのためにID0×00-08について議定書の中で述べます。 この仕様はそれを超えたどんな追加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.
それが注意されるべきである、VPN関連のOUIの所有者としてのそのIANA: 0×00 00-5E--特定するインデックスリストをVPNに割り当てるかもしれないVPN権威自体もVPNsですか? この仕様の文脈の中のこれらの特定のVPNインデックスリストの使用は、予約されていて、RFC2434によると、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.、キャッツ、D.、Piscitello、D.、コール、B.、およびN.Doraswamy、「次のNMBAは解決プロトコル(NHRP)を飛び越します」、RFC2332、1998年4月。
[2] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over
ATM Adaptation Layer 5", RFC 2684, September 1999.
[2] グロースマン、D.、およびJ.Heinanen、「気圧適合の上のMultiprotocolカプセル化は1999年9月に5インチ、RFC2684を層にします」。
[3] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier",
RFC 2685, September 1999.
[3]フォックスとB.とB.グリーソン、「仮想私設網識別子」、RFC2685、1999年9月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Authors' Addresses
作者のアドレス
Barbara A. Fox Equipe Communications 100 Nagog Park Acton, MA 01720
バーバラA.フォックスEquipeコミュニケーション100Nagog Parkアクトン、MA 01720
Phone: +1-978-795-2009 EMail: bfox@equipecom.com
以下に電話をしてください。 +1-978-795-2009 メールしてください: bfox@equipecom.com
Bernhard Petri Siemens AG Hofmannstr. 51 Munich, Germany, D-81359
バーンハードペトリジーメンス株式会社Hofmannstr。 51 ミュンヘン(ドイツ)D-81359
Phone: +49 89 722-34578 EMail: bernhard.petri@icn.siemens.de
以下に電話をしてください。 +49 89 722-34578 メールしてください: bernhard.petri@icn.siemens.de
Fox & Petri Standards Track [Page 11] RFC 2735 NHRP Support for Virtual Private Networks December 1999
フォックスとRFC2735NHRPが1999年12月に仮想私設網のために支えるペトリ標準化過程[11ページ]
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Fox & Petri Standards Track [Page 12]
フォックスとペトリ標準化過程[12ページ]
一覧
スポンサーリンク
