[要約] RFC 4636は、Mobile IPv4における外部エージェントエラー拡張に関するものであり、エラーの原因となる外部エージェントの問題を特定するための手段を提供します。目的は、Mobile IPv4ネットワークの信頼性とパフォーマンスを向上させることです。
Network Working Group C. Perkins
Request for Comments: 4636 Nokia Research Center
Category: Standards Track October 2006
Foreign Agent Error Extension for Mobile IPv4
モバイルIPv4の外部エージェントエラー拡張
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 (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document specifies a new extension for use by Foreign Agents operating Mobile IP for IPv4. Currently, a foreign agent cannot supply status information without destroying the ability for a mobile node to verify authentication data supplied by the home agent. The new extension solves this problem by making a better place for the foreign agent to provide its status information to the mobile node.
このドキュメントは、IPv4のモバイルIPを操作する外国人エージェントが使用するための新しい拡張機能を指定しています。現在、外国人エージェントは、モバイルノードがホームエージェントが提供する認証データを検証する機能を破壊せずにステータス情報を提供することはできません。新しい拡張機能は、外国人エージェントがモバイルノードにステータス情報を提供するためのより良い場所を作ることにより、この問題を解決します。
This document specifies a new non-skippable extension for use by Foreign Agents operating Mobile IP for IPv4 [4]. The new extension option allows a foreign agent to supply an error code without disturbing the data supplied by the Home Agent within the Registration Reply message. In this way, the mobile node can verify that the Registration Reply message was generated by the Home Agent even in cases where the foreign agent is required by protocol to insert new status information into the Registration Reply message.
このドキュメントは、IPv4のためにモバイルIPを操作する外国人エージェントが使用するための新しい非スキップ可能な拡張機能を指定しています[4]。新しい拡張機能オプションにより、外国人エージェントは、登録応答メッセージ内でホームエージェントが提供するデータを乱すことなくエラーコードを提供できます。このようにして、モバイルノードは、外国人エージェントがプロトコルが登録応答メッセージに新しいステータス情報を挿入するために必要な場合でも、登録返信メッセージがホームエージェントによって生成されたことを確認できます。
The keywords "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 [1]. Other terminology is used as already defined in [4].
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" sulld "、" not "、" becommented "、" "、" optional "は、RFC 2119 [1]に記載されているように解釈されます。他の用語は、[4]ですでに定義されているように使用されています。
The format of the FA Error Extension conforms to the Short Extension format specified for Mobile IPv4 [4]. The FA Error Extension is not skippable.
FAエラー拡張の形式は、モバイルIPv4に指定された短い拡張形式に準拠しています[4]。FAエラー拡張機能はスキップできません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
45
45
Length
長さ
2
2
Sub-Type
サブタイプ
0
0
Status
スターテス
A status code used by the foreign agent to supply status information to the mobile node.
外国人がモバイルノードにステータス情報を提供するために使用されるステータスコード。
The FA Error Extension is only valid for use within Mobile IPv4 Registration Reply messages. The FA Error Extension is not skippable. A mobile node that cannot correctly interpret the contents of the FA Error Extension MUST NOT use the care-of address provided in the Registration Reply message, until another Registration Request message has been sent and a successful Registration Reply message received.
FAエラー拡張は、モバイルIPv4登録応答メッセージ内での使用にのみ有効です。FAエラー拡張機能はスキップできません。FAエラー拡張子の内容を正しく解釈できないモバイルノードは、登録返信メッセージに提供されている別の登録要求メッセージが送信され、登録返信メッセージが正常に受信されるまで、登録返信メッセージに提供されていないアドレスを使用してはなりません。
Status codes allowable for use within the FA Error Extension are within the range 64-127. The currently specified codes are as follows:
FAエラー拡張内で使用できるステータスコードは、範囲64-127内にあります。現在指定されているコードは次のとおりです。
64 reason unspecified 65 administratively prohibited 66 insufficient resources 68 home agent failed authentication 71 poorly formed Reply 77 invalid care-of address 78 registration timeout
64理由不特定65管理上禁止66リソース不足68ホームエージェントの失敗認証71不十分に形成された返信77無効なケアオブアドレス78登録タイムアウト
as defined in RFC 3344 [4] for use by the Foreign Agent. Status codes for use with the FA Error extensions must not be differently defined for use in the Code field of Registration Reply messages.
外国人エージェントが使用するためのRFC 3344 [4]で定義されています。FAエラー拡張機能で使用するステータスコードは、登録応答メッセージのコードフィールドで使用するために異なる定義を施してはなりません。
When a foreign agent appends a FA Error Extension to the Registration Reply as received from the Home Agent, it has to update the UDP Length field in the UDP header [5] to account for the extra 4 bytes of length.
外国人エージェントがHomeエージェントから受信したようにFAエラー拡張を登録返信に追加する場合、UDPヘッダー[5]のUDP長さフィールドを更新して、長さの余分なバイトを説明する必要があります。
This document updates the Mobile IP base specification [4] regarding the procedures followed by the foreign agent in the case that the home agent fails authentication. Instead of modifying the "status" field of the Registration Reply to contain the value 68, now the foreign agent should append the Foreign Agent Error Extension containing the status value 68.
このドキュメントでは、ホームエージェントが認証に失敗した場合の外国人エージェントがそれに続く手順に関するモバイルIPベース仕様[4]を更新します。登録返信の「ステータス」フィールドを変更する代わりに、値68を含むように、外部エージェントはステータス値68を含む外国のエージェントエラー拡張を追加する必要があります。
If a mobile node receives a successful Registration Reply (status code 0 or 1), with a FA Error Extension indicating that the foreign agent is not honoring said Registration Reply, the mobile node SHOULD then send a deregistration message to the home agent. In this way, the home agent will not maintain a registration status that is inconsistent with the status maintained by the foreign agent.
モバイルノードが登録返信の成功（ステータスコード0または1）を受信し、FAエラー拡張が外国人エージェントが上記の登録返信を尊重していないことを示す場合、モバイルノードはホームエージェントに登録メッセージを送信する必要があります。このようにして、ホームエージェントは、外国人エージェントが維持するステータスと矛盾する登録ステータスを維持しません。
When denying a successful Registration Reply, the Foreign Agent SHOULD send a Registration Revocation message [2] to the Home Agent if a mobility security association exists between them. For cases when the foreign agent does have the required security association, this way of informing the home agent does not have the vulnerability from detrimental actions by malicious foreign agents, as noted in section 8.
登録の成功を拒否する場合、外国人エージェントは、モビリティセキュリティ協会がそれらの間に存在する場合、登録撤回メッセージ[2]をホームエージェントに送信する必要があります。外国人エージェントが必要なセキュリティ協会を持っている場合、セクション8に記載されているように、住宅エージェントに悪意のある外国人エージェントによる有害な行動からの脆弱性はありません。
This specification reserves one number for the FA Error Extension (see section 3) from the space of numbers for non-skippable mobility extensions (i.e., 0-127) defined in the specification for Mobile IPv4 [4].
この仕様は、モバイルIPv4 [4]の仕様で定義されているスキップ不可のモビリティエクステンション（つまり、0-127）の数値の空間からFAエラー拡張の1つの数値（セクション3を参照）を留保します。
This specification also creates a new number space of sub-types for the type number of this extension. Sub-type zero is to be allocated from this number space for the protocol extension specified in this document. Similar to the procedures specified for Mobile IP [4] number spaces, future allocations from this number space require expert review [3].
また、この仕様では、この拡張機能のタイプ番号のサブタイプの新しい数値スペースも作成します。サブタイプゼロは、このドキュメントで指定されたプロトコル拡張のために、この数値スペースから割り当てられます。モバイルIP [4]番号スペースに指定された手順と同様に、この数字スペースからの将来の割り当てには、専門家のレビュー[3]が必要です。
The status codes that are allowable in the FA Error Extension are a subset of the status codes defined in the specification for Mobile IPv4 [4]. If, in the future, additional status codes are defined for Mobile IPv4, the definition for each new status code must indicate whether the new status code is allowable for use in the FA Error Extension.
FAエラー拡張で許容されるステータスコードは、モバイルIPv4の仕様で定義されたステータスコードのサブセットです[4]。将来、モバイルIPv4に対して追加のステータスコードが定義されている場合、新しいステータスコードの定義は、新しいステータスコードがFAエラー拡張で使用できるかどうかを示しなければなりません。
The extension in this document improves the security features of Mobile IPv4 by allowing the mobile node to be assured of the authenticity of the information supplied within a Registration Request. Previously, whenever the foreign agent was required to provide status information to the mobile node, it could only do so by destroying the ability of the mobile device to verify the Mobile-Home Authentication Extension data.
このドキュメントの拡張機能は、登録要求内で提供された情報の信頼性をモバイルノードに保証できるようにすることにより、モバイルIPv4のセキュリティ機能を改善します。以前は、外国人エージェントがモバイルノードにステータス情報を提供する必要があるときはいつでも、モバイルホーム認証拡張データを確認するモバイルデバイスの機能を破壊することによってのみそうすることができました。
In many common cases, the mobile node will not have a security association with the foreign agent that has sent the extension. Thus, the mobile node will be unable to ascertain that the foreign agent sending the extended Registration Reply message is the same foreign agent that earlier received the associated Registration Request from the mobile node. Because of this, a malicious foreign agent could cause a mobile node to operate as if the registration had failed, when in fact its home agent and a correctly operating foreign agent had both accepted the mobile node's Registration Request. In order to reduce the vulnerability to such maliciously transmitted Registration Reply messages with the unauthenticated extension, the mobile node MAY delay processing of such denied Registration Reply messages for a short while in order to determine whether another successful Registration Reply might be received from the foreign agent.
多くの一般的なケースでは、モバイルノードには、拡張機能を送信した外国人エージェントとのセキュリティ関連がありません。したがって、モバイルノードは、拡張登録返信メッセージを送信する外国人エージェントが、以前にモバイルノードから関連する登録要求を受け取ったのと同じ外国人エージェントであることを確認することができません。このため、悪意のある外国人エージェントは、モバイルノードが登録が失敗したかのように動作させる可能性があります。このような悪意のある送信された登録応答メッセージに対する脆弱性を認められない拡張機能で減らすために、モバイルノードは、登録返信メッセージの拒否を短時間遅らせるために、登録返信を別の成功した登録返信が外国人エージェントから受信できるかどうかを判断する場合があります。。
Thanks to Kent Leung and Henrik Lefkowetz for suggested improvements to this specification.
この仕様の改善を提案してくれたKent LeungとHenrik Lefkowetzに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003.
[2] Glass、S。およびM. Chandra、「モバイルIPv4の登録の取り消し」、RFC 3543、2003年8月。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[4] Perkins、C。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[5] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[5] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
Author's Address
著者の連絡先
Charles E. Perkins Palo Alto Systems Research Lab Nokia Research Center 975 Page Mill Road, Suite 200 Palo Alto, CA 94304-1003
チャールズE.パーキンスパロアルトシステムリサーチラボノキアリサーチセンター975ページミルロード、スイート200パロアルト、カリフォルニア州94304-1003
Phone: +1 650-496-4402
Fax: +1-650-739-0779
EMail: charles.perkins@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。