RFC2520 日本語訳

Network Working Group                                       J. Luciani
Request for Comments: 2520                             Nortel Networks
Category: Experimental                                       H. Suzuki
                                                         Cisco Systems
                                                          N. Doraswamy
                                                       Nortel Networks
                                                             D. Horton
                                                          CiTR Pty Ltd
                                                         February 1999

Lucianiがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2520 ノーテルはカテゴリをネットワークでつなぎます: 実験的なH.鈴木シスコシステムズN.DoraswamyノーテルはCiTR Pty Ltd1999年2月にD.ホートンをネットワークでつなぎます。

                         NHRP with Mobile NHCs

モバイルNHCsとNHRP

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

Abstract

要約

   This document describes an extension to NHRP [1] which would allow
   Mobile NHCs to perform a registration with and attach to an NHS in
   their home LIS in an authenticated manner.

このドキュメントはモバイルNHCsを彼らのホームLISでNHSに認証された方法で登録を実行して、付かせるNHRP[1]に拡大について説明します。

   As described in this document, Mobile NHCs are NHCs which are not
   configured with enough information to find a specific serving NHS in
   their home LIS, but which have a mechanism to find an NHS (which may
   or may not be a serving NHS) to which they will attach.  As described
   in [1], an NHC may attach to a 'surrogate' NHS by using a mechanism
   such as an anycast address.  In this case, the NHC may use the
   surrogate NHS to send a NHRP Registration Request toward the NHC's
   home LIS where a serving NHS resides.  However, as defined in [1],
   packet authentication is performed on a hop by hop basis.  In the
   mobile NHC case, it is not practical for the mobile NHC be in a
   security relationship with every surrogate NHS, thus it is presumably
   desirable to have some form of end to end only authentication for the
   case of a mobile NHC's registration.  This document describes an
   authentication extension for NHRP which has such end to end only
   semantics.

本書では説明されるように、モバイルNHCsは彼らのホームLISで特定の給仕がNHSであることがわかることができるくらいの情報によって構成されませんが、彼らが付くNHS(給仕NHSであるかもしれない)を見つけるメカニズムがあるNHCsです。 [1]で説明されるように、NHCはanycastアドレスなどのメカニズムを使用することによって、'代理'のNHSに付くかもしれません。 この場合、NHCは、給仕NHSが住んでいるNHCのホームLISに向かってNHRP Registration Requestを送るのに代理のNHSを使用するかもしれません。 しかしながら、[1]で定義されるように、パケット認証はホップ基礎によってホップに実行されます。 モバイルNHC場合では、モバイルNHCに実用的であるのが、その結果、おそらく、あらゆるNHS代理がいる安全保障関係では、モバイルNHCの登録に関するケースのための認証だけを終わらせる何らかのフォームの端を持っているのが望ましいということであるということではありません。 このドキュメントはそのようなものを意味論だけを終わらせるために終わらせるNHRPのために認証拡大について説明します。

Luciani, et al.               Experimental                      [Page 1]

RFC 2520                 NHRP with Mobile NHCs             February 1999

Luciani、他 モバイルNHCs1999年2月がある実験的な[1ページ]RFC2520NHRP

1. Introduction

1. 序論

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [4].

キーワードが解釈しなければならない、本書では現れるとき、[4]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?

   This document describes an extension for Mobile NHCs to use when they
   wish to register with their home LIS but initially connect to a non-
   serving NHS to do so.  The reader is encouraged to read [1] for more
   details on the NHRP registration process.

彼らが彼らのホームLISとともに記名しますが、初めはそうするために非給仕のNHSに接続したがっているとき、このドキュメントはモバイルNHCsが使用する拡張子について説明します。 読者がNHRP登録手続に関するその他の詳細のための[1]を読むよう奨励されます。

2.0 Definition of the NHRP Mobile NHC Authentication Extension

2.0 NHRPのモバイルNHC認証拡張子の定義

    Compulsory = 1
    Type = 10 (proposed)
    Length = variable

1コンパルソリー=Typeが10(提案される)の長さ=の変数と等しいです。

   The NHRP Mobile NHC Authentication Extension is carried in NHRP
   Registration packets to convey end to end authentication Information.
   This extension is defined in contrast to the NHRP Authentication
   Extension defined in [1] which has hop by hop semantics.

NHRPのモバイルNHC Authentication Extensionは、認証情報を終わらせるために終わりを伝えるためにNHRP Registrationパケットで運ばれます。 この拡大はホップ意味論でホップを持っている[1]で定義されたNHRP Authentication Extensionと対照して定義されます。

   This new extension is used when a mobile NHC initially connects to an
   NHS which is not one of its serving NHSs and the mobile NHC and
   nonserving NHS are not in a security relationship.  The mobile NHC
   does this in order to send an NHRP Registration Request, via normal
   routing and forwarding processes, to one of its serving NHSs with
   which it does have a security relationship.  As defined in [1], a
   serving NHS is an NHS in the NHC's home LIS with which the NHC will
   register.  Upon receiving such an NHRP Registration Request, the
   serving NHS will do the following: authenticate the sender NHC, set
   up a VC to the NHC, and then send an NHRP Resolution Reply in
   response on that new VC.

モバイルNHCが初めは1歳でないNHSsに役立つNHSに接続するとき、この新しい拡大は使用されています、そして、安全保障関係にモバイルNHCとnonserving NHSがありません。 モバイルNHCはNHRP Registration Requestを送るためにこれをします、正常なルーティングとプロセスを進めることを通して、安全保障関係を持っているNHSsに役立つ1つに。 [1]で定義されるように、給仕NHSはNHCが登録するNHCのホームLISのNHSです。 そのようなNHRP Registration Requestを受けると、給仕NHSは以下をするでしょう: 送付者NHCを認証してください、そして、NHCにVCをセットアップしてください、そして、次に、応答でその新しいVCにNHRP Resolution Replyを送ってください。

   Note that, as defined in [1], a transit NHS (such as the one to which
   the mobile NHC initially connects) must ignore an extension which it
   does not understand and that an NHS must not change the order of
   extensions in an NHRP packet. Thus, the end to end semantics of this
   extension are preserved without causing changes to existing
   implementations.

それに注意してください、そして、[1]、NHS(モバイルNHCが初めは接続するものなどの)がそうしなければならないトランジットでは定義されるようにそれが理解していない拡大と、NHSがNHRPパケットでの拡大の注文を変えてはいけないのを無視してください。 既存の実装への変化を引き起こさないで、このようにしてと、この拡大の意味論を終わらせる終わりに保存されます。

   If a serving NHS receives a packet which fails the hop by hop
   authentication test defined in [1] then the NHS MUST generate an
   Error Indication of type 'Authentication Failure' and discard the
   packet.  However in the case where the NHRP Mobile NHC Authentication
   Extension is used as described above, sending an Error Indication is
   not possible since no route exists back toward the mobile NHC
   assuming a VC does not already exist between the mobile NHC and the

給仕NHSが[1]で定義されたホップ認証テストでホップに失敗するパケットを受けるなら、NHS MUSTはタイプ'認証Failure'のError Indicationを生成して、パケットを捨てます。 そしてしかしながら、NHRPのモバイルNHC Authentication Extensionが上で説明されるように使用されている場合では、Error Indicationを送るのがルートが全くVCを仮定するモバイルNHCに向かって存在し返していないのでモバイルNHCが間に既に存在しないのが可能でない。

Luciani, et al.               Experimental                      [Page 2]

RFC 2520                 NHRP with Mobile NHCs             February 1999

Luciani、他 モバイルNHCs1999年2月がある実験的な[2ページ]RFC2520NHRP

   serving NHS which received the NHRP Registration Request. In this
   case, the NHRP Registration Request is merely dropped.

NHRP Registration Requestを受けたNHSに役立ちます。 この場合、NHRP Registration Requestは単に下げられます。

2.1 Header Format

2.1 ヘッダー形式

   The authentication header has the following format:

認証ヘッダーには、以下の形式があります:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved                    | Security Parameter Index (SPI)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Src Addr...                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| セキュリティパラメタインデックス(SPI)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Addr… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +++++++++++認証データ… -+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Security Parameter Index (SPI) can be thought of as an index into a
   table that maintains the keys and other information such as a hash
   algorithm. Src and Dst communicate either offline using manual keying
   or online using a key management protocol to populate this table. The
   sending NHRP entity always allocates the SPI and the parameters
   associated with it.

インデックスとしてハッシュアルゴリズムのキーと他の情報を保守するテーブルにセキュリティParameter Index(SPI)を考えることができます。 SrcとDstは、かぎ管理がこのテーブルに居住するために議定書の中で述べる手動の合わせているかオンラインの使用を使用することでオフラインで交信します。 送付NHRP実体はいつもそれに関連しているSPIとパラメタを割り当てます。

   The Src Addr field is a variable length field which contains the
   address assigned to the outgoing interface. The length of the field
   is obtained from the source protocol length field in the mandatory
   part of the NHRP header.  The tuple <spi, src addr> uniquely
   identifies the key and the other parameters that are used in
   authentication.

Src Addr分野は外向的なインタフェースに割り当てられたアドレスを含む可変長フィールドです。 NHRPヘッダーの義務的な一部のソースプロトコル長さの分野から分野の長さを得ます。 tuple<spiであり、src addr>は唯一認証に使用される主要なパラメタと他のパラメタを特定します。

   The length of the authentication data field is dependent on the hash
   algorithm used. The Authentication Data field contains the keyed hash
   calculated over the following fields: fixed part (with hop count,
   packet size and checksum being treated as if set to zero), mandatory
   part, and extensions up to and including the Mobile NHC
   Authentication extension.

認証データ・フィールドの長さは使用されるハッシュアルゴリズムに依存しています。 Authentication Data分野は以下の分野に関して計算された合わせられたハッシュを含んでいます: モバイルNHC Authentication拡張子を含めた固定部分(まるでゼロに設定されるかのように扱われるホップカウント、パケットサイズ、およびチェックサムがある)、義務的な部分、および拡大。

   Note that [1] defines an explicit ordering of extensions such that:

[1]が拡大の明白な注文を定義することに注意してください、以下のことのようなもの

     (a) If the Responder Address extension exists then it must appear
         before the Authentication Extension.

(a) Responder Address拡張子が存在しているなら、それはAuthentication Extensionの前に現れなければなりません。

     (b) Any extensions that may be modified in transit (e.g., Forward
         Transit Extension, Hop by Hop Authentication Extension) must
         appear after the Mobile NHC Authentication Extension.

(b) トランジット(例えば、Forward Transit Extension、Hop Authentication ExtensionによるHop)で変更されるどんな拡大もモバイルNHC Authentication Extensionの後に現れなければなりません。

Luciani, et al.               Experimental                      [Page 3]

RFC 2520                 NHRP with Mobile NHCs             February 1999

Luciani、他 モバイルNHCs1999年2月がある実験的な[3ページ]RFC2520NHRP

2.2 SPI and Security Parameters Negotiation

2.2 SPIとセキュリティパラメタ交渉

   SPI's can be negotiated either manually or using an Internet Key
   Management protocol. Manual keying MUST be supported. The following
   parameters are associated with the tuple <SPI, src>- lifetime,
   Algorithm, Key. Lifetime indicates the duration in seconds for which
   the key is valid. In case of manual keying, this duration can be
   infinite. Also, in order to better support manual keying, there may
   be multiple tuples active at the same time (Dst being the same).

SPIのものは、手動で交渉されるか、またはインターネットKey Managementプロトコルを使用できます。 手動の合わせることをサポートしなければなりません。 以下のパラメタはtuple<SPI、src>-生涯、Algorithm、Keyに関連しています。 寿命はキーが有効である秒に持続時間を示します。 手動の合わせることの場合には、この持続時間は無限である場合があります。 また、手動の合わせることをサポートするほうがよいために、同時にアクティブな複数のtuples(同じであるDst)があるかもしれません。

   Algorithm specifies the hash algorithm agreed upon by the two
   entities. HMAC-MD5-128 [2] is the default algorithm and MUST be
   implemented. Other algorithms MAY be supported by defining new
   values.  IANA will assign the numbers to identify the algorithm being
   used as described in [1].

アルゴリズムは2つの実体によって同意されたハッシュアルゴリズムを指定します。 HMAC-MD5-128[2]をデフォルトアルゴリズムであり、実装しなければなりません。 他のアルゴリズムは、新しい値を定義することによって、サポートされるかもしれません。 IANAは、アルゴリズムを特定するために[1]で説明されるように使用されることで数を割り当てるでしょう。

   Any Internet standard key management protocol MAY so be used to
   negotiate the SPI and parameters.

したがって、どんなインターネット標準かぎ管理プロトコルも、SPIとパラメタを交渉するのに使用されるかもしれません。

2.3 Message Processing

2.3 メッセージ処理

   Unauthenticated 'Mobile' Registration Request processing proceeds as
   follows [1]:

Unauthenticated'モバイル'のRegistration Request処理は以下の通りの[1]を続かせます:

      - the NHC inserts the internetwork address of a serving NHS in the
        'Destination  Protocol Address' field; If the NHS address is
        unknown, then the NHC inserts its own internetwork address.  A '
        responder address' extension is optionally added.
      - the non-serving NHS forwards the packet along the routed path
        based on the contents of the 'Destination Protocol Address'
        field.
      - the serving NHS which receives the NHRP Registration Request
        will set up a direct VCC to NHC after authenticating the request
      - the serving NHS will then send the NHRP Registration Reply back
        to the NHC on that new VCC.  Note that the NHS MUST wait some
        configured interval before doing this reply in order to prevent
        a race condition from occurring between the VC setup and sending
        the NHRP reply packet.
      - the NHC will subsequently send all NHRP traffic to the serving
        NHS on the direct VCC.

- NHCは'目的地プロトコルAddress'分野に給仕NHSのインターネットワークアドレスを挿入します。 NHSアドレスが未知であるなら、NHCはそれ自身のインターネットワークアドレスを挿入します。 '応答者アドレス'拡大は任意に加えられます。 - 非給仕NHSは'目的地プロトコルAddress'分野のコンテンツに基づく発送された経路に沿ってパケットを進めます。 - 要求を認証した後に、NHRP Registration Requestを受ける給仕NHSがダイレクトVCCをNHCにセットアップするでしょう--そして、給仕NHSはその新しいVCCの上のNHCにNHRP Registration Replyを送り返すでしょう。 VCセットアップとNHRP回答パケットを送るとき発生から競合条件を防ぐためにこの回答をする前にNHS MUSTがいくつかの構成された間隔の間待つことに注意してください。 - NHCは次に、ダイレクトVCCの上の給仕NHSにすべてのNHRPトラフィックを送るでしょう。

Luciani, et al.               Experimental                      [Page 4]

RFC 2520                 NHRP with Mobile NHCs             February 1999

Luciani、他 モバイルNHCs1999年2月がある実験的な[4ページ]RFC2520NHRP

   When the NHC adds the authentication extension header, it performs a
   table look up in order to fetch the SPI and the security parameters
   based on the outgoing interface address. If there are no entries in
   the table and if there is support for key management, the NHC
   initiates the key management protocol to fetch the necessary
   parameters. The NHC constructs the Authentication Extension payload
   and calculates the hash by zeroing out the authentication data field.
   The result is placed in the authentication data field. The src
   address field in the payload is the internetwork address assigned to
   the outgoing interface.

NHCが認証拡張ヘッダーを加えるとき、それは、外向的なインターフェース・アドレスに基づくパラメタをSPIとセキュリティにとって来るために上にテーブル外観を実行します。 エントリーが全くテーブルになくて、かぎ管理のサポートがあれば、NHCは、必要なパラメタをとって来るためにかぎ管理プロトコルを開始します。 NHCは、外で認証データ・フィールドのゼロを合わせることによって、Authentication Extensionペイロードを構成して、ハッシュについて計算します。 結果は認証データ・フィールドに置かれます。 ペイロードのsrcアドレス・フィールドは外向的なインタフェースに割り当てられたインターネットワークアドレスです。

   If key management is not supported and authentication is mandatory,
   the packet is dropped and this information is logged.

かぎ管理がサポートされないで、認証が義務的であるなら、パケットは下げられます、そして、この情報は登録されます。

   On the receiving end, the serving NHS fetches the parameters based on
   the SPI and the internetwork address in the authentication extension
   payload. The authentication data field is extracted before being
   zeroed out in order to calculate the hash. It computes the hash on
   the entire payload and if the hash does not match, then an "abnormal
   event" has occurred.

受ける側になって、給仕NHSはSPIに基づくパラメタと認証拡大ペイロードのインターネットワークアドレスをとって来ます。 ハッシュについて計算するために外でゼロに合わせられる前に認証データ・フィールドは抽出されます。 それは全体のペイロードの上にハッシュを計算します、そして、ハッシュが合っていないなら、「異常なイベント」は起こりました。

   The keys used by the mobile NHC for communicating with the serving
   NHS in NHRP Registration Requests can be used in subsequent
   resolution and purge requests made directly to the serving NHS after
   receiving the NHRP Registration Reply.  However, the authentication
   extension defined in [1] MUST be used when these keys are applied to
   resolution and purge packets.

NHRP Registration Replyを受けた後に直接給仕NHSにされたその後の解決とパージ要求でNHRP Registration Requestsで給仕NHSとコミュニケートするのにモバイルNHCによって使用されたキーは使用できます。 しかしながら、これらのキーが解決に適用されて、パケットを掃除するとき、[1]で定義された認証拡張子を使用しなければなりません。

   Hop by Hop Authentication[1] and End to End authentication MAY be
   used in combination to provide protection against both spoofing and
   denial of service attacks.  If only an end-to-end Mobile NHC
   Authentication Extension is present, it MAY be the policy of each
   transit NHS to reject the NHRP Registration Request based on the
   requirement for having a Hop by Hop authentication present.  Such a
   requirement is a local matter.

End認証へのHop Authentication[1]とEndによるホップは、スプーフィングとサービス不能攻撃の両方に対する保護を提供するのに組み合わせに使用されるかもしれません。 終わりから終わりへのモバイルNHC Authentication Extensionだけが存在しているなら、それは、Hop認証でHopを持つための現在の要件に基づくNHRP Registration Requestを拒絶するためには各トランジットNHSの方針であるかもしれません。 そのような要件は地域にかかわる事柄です。

2.4 Security Considerations

2.4 セキュリティ問題

   It is important that the keys chosen are strong since the security of
   the entire system depends on the keys being chosen properly.

全体のシステムのセキュリティが適切に選ばれているキーによるので選ばれたキーが強いのは、重要です。

   End-to-end authentication counters spoofing attacks on the home
   subnet through not relying on the potentially compromised chain of
   trust. The use of end-end authentication is further described in [3].

終わりから終わりへの認証は、信頼の潜在的に感染しているチェーンを当てにしないことでホームサブネットに対する攻撃を偽造しながら、反対します。 終わり-終わりの認証の使用は[3]でさらに説明されます。

   Hop-by-hop authentication prevents denial of service attacks by
   introducing access control at the first point of contact to the NHRP
   infrastructure.

ホップごとの認証は、最初の連絡先でのアクセスコントロールをNHRPインフラストラクチャに紹介することによって、サービス不能攻撃を防ぎます。

Luciani, et al.               Experimental                      [Page 5]

RFC 2520                 NHRP with Mobile NHCs             February 1999

Luciani、他 モバイルNHCs1999年2月がある実験的な[5ページ]RFC2520NHRP

   The security of this extension is performed on an end to end basis.
   The data received can be trusted only so much as one trusts the end
   point entities in the path traversed. A chain of trust is established
   amongst NHRP entities in the path of the NHRP Message. If the
   security in an NHRP entity is compromised, then security in the
   entire NHRP domain is compromised.

この拡大のセキュリティは、基礎を終わらせるために終わりで実行されます。 データは信じられた唯一のものさえ経路のエンドポイント実体が横断した受託であったかもしれないなら受信されました。 信頼のチェーンはNHRP Messageの経路のNHRP実体の中に設立されます。 NHRP実体におけるセキュリティが感染されるなら、全体のNHRPドメインにおけるセキュリティは感染されます。

   Data integrity covers the entire NHRP payload up to and including the
   Mobile NHC Authentication Extension. This guarantees that the data
   and extensions covered by this authentication hash were not modified
   and that the source is authenticated as well. If the authentication
   extension is not used or if the security is compromised, then NHRP
   entities are liable to both spoofing attacks, active attacks, and
   passive attacks.

データの保全はモバイルNHC Authentication Extensionを含めて全体のNHRPペイロードをカバーしています。 これは、この認証ハッシュで含まれていたデータと拡大が変更されないで、また、ソースが認証されるのを保証します。 認証拡大が使用されていないか、またはセキュリティが感染されるなら、NHRP実体はともにだましている攻撃、活発な攻撃、および受け身の攻撃に責任があります。

   There is no mechanism to encrypt the messages. It is assumed that a
   standard layer 3 confidentiality mechanism will be used to encrypt
   and decrypt messages.  It is recommended to use an Internet standard
   key management protocol to negotiate the keys between the neighbors.
   Transmitting the keys in clear text, if other methods of negotiation
   is used, compromises the security completely.

メッセージを暗号化するために、メカニズムは全くありません。 標準の層3の秘密性メカニズムがメッセージを暗号化して、解読するのに使用されると思われます。 隣人の間のキーを交渉するのにインターネット標準かぎ管理プロトコルを使用するのはお勧めです。 交渉の他のメソッドが使用されているならクリアテキストでキーを送ると、セキュリティは完全に感染します。

References

参照

   [1] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy,
       "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.

[1] Luciani、J.、キャッツ、D.、Piscitello、D.、コール、B.、およびN.Doraswamy、「次のNBMAは解決プロトコル(NHRP)を飛び越します」、RFC2332、1998年4月。

   [2] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed Hashing
       for Message Authentication", RFC 2104, February 1997.

[2]Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。

   [3] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.

[3] パーキンス、C.、「IP移動性サポート」、RFC2002、1996年10月。

   [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月。

Luciani, et al.               Experimental                      [Page 6]

RFC 2520                 NHRP with Mobile NHCs             February 1999

Luciani、他 モバイルNHCs1999年2月がある実験的な[6ページ]RFC2520NHRP

Authors' Addresses

作者のアドレス

   James V. Luciani
   Nortel Networks
   3 Federal Street
   Mail Stop: BL3-03
   Billerica, MA 01821

ジェームスV.Lucianiノーテルは3の連邦政府の通りメール停止をネットワークでつなぎます: BL3-03ビルリカ、MA 01821

   Phone:  +1 978 916 4734
   EMail:  luciani@baynetworks.com

以下に電話をしてください。 +1 4734年の978 916メール: luciani@baynetworks.com

   Hiroshi Suzuki
   Cisco Systems
   170 West Tasman Dr.
   San Jose, CA 96134

サンノゼ、鈴木寛シスコシステムズ170の西タスマン博士カリフォルニア 96134

   Phone: +1 408 525 6006
   EMail: hsuzuki@cisco.com

以下に電話をしてください。 +1 6006年の408 525メール: hsuzuki@cisco.com

   Naganand Doraswamy
   Nortel Networks
   3 Federal Street
   Mail Stop: BL3-03
   Billerica, MA 01821

Naganand Doraswamyノーテルは3の連邦政府の通りメール停止をネットワークでつなぎます: BL3-03ビルリカ、MA 01821

   Phone:  +1 978 916 4734
   EMail:  naganand@baynetworks.com

以下に電話をしてください。 +1 4734年の978 916メール: naganand@baynetworks.com

   David Horton
   CiTR PTY Ltd
   Level 2 North Tower
   339 Coronation Drive
   Milton, Australia 4064

デヴィッドホートンCiTR PTY Ltd Level2 ノースタワー339戴冠Driveミルトン、オーストラリア4064

   Phone: +61 7 32592222
   EMail:  d.horton@citr.com.au

以下に電話をしてください。 +61 7 32592222 メール: d.horton@citr.com.au

Luciani, et al.               Experimental                      [Page 7]

RFC 2520                 NHRP with Mobile NHCs             February 1999

Luciani、他 モバイルNHCs1999年2月がある実験的な[7ページ]RFC2520NHRP

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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Luciani, et al.               Experimental                      [Page 8]

Luciani、他 実験的[8ページ]