RFC4636 日本語訳
4636 Foreign Agent Error Extension for Mobile IPv4. C. Perkins. October 2006. (Format: TXT=11663 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Perkins Request for Comments: 4636 Nokia Research Center Category: Standards Track October 2006
コメントを求めるワーキンググループC.パーキンス要求をネットワークでつないでください: 4636年のノキアリサーチセンターカテゴリ: 標準化過程2006年10月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはForeignエージェントの操作のモバイルIPによるIPv4の使用のために新しい拡大を指定します。 現在、モバイルノードがホームのエージェントによって提供された認証データについて確かめる能力を破壊しないで、外国人のエージェントは状態情報を提供できません。 新しい拡大は、外国人のエージェントが状態情報をモバイルノードに提供するより良い場所を作ることによって、この問題を解決します。
Perkins Standards Track [Page 1] RFC 4636 FA Error Extension October 2006
パーキンスStandardsはファ誤り拡大2006年10月にRFC4636を追跡します[1ページ]。
1. Introduction
1. 序論
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.
このドキュメントはForeignエージェントの操作のモバイルIPによるIPv4[4]の使用のために新しい非skippable拡張子を指定します。 新しい拡大オプションで、Registration Replyメッセージの中のホームのエージェントによって提供されたデータを擾乱しないで、外国人のエージェントはエラーコードを供給できます。 このように、モバイルノードは、Registration Replyメッセージが外国人のエージェントが新しい状態情報をRegistration Replyメッセージにプロトコルが挿入しなければならない場合でさえホームのエージェントによって生成されたことを確かめることができます。
2. Terminology
2. 用語
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか? 他の用語は[4]で既に定義されるように使用されています。
3. FA Error Extension Format
3. ファ誤り拡大形式
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 Error Extensionの形式はモバイルIPv4[4]に指定されたShort Extension形式に従います。 FA Error Extensionはskippableではありません。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
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.
状態情報をモバイルノードに供給するのに外国人のエージェントによって使用されたステータスコード。
Perkins Standards Track [Page 2] RFC 4636 FA Error Extension October 2006
パーキンスStandardsはファ誤り拡大2006年10月にRFC4636を追跡します[2ページ]。
4. Operation and Use of the FA Error Extension
4. ファ誤り拡張子の操作と使用
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.
モバイルIPv4 Registration Replyメッセージの中の使用だけに、FA Error Extensionは有効です。 FA Error Extensionはskippableではありません。 使用ではなく、正しくFA Error Extensionのコンテンツを解釈できないノードがそうしなければならないモバイル、注意、-、アドレス、別のRegistration Requestメッセージを送って、うまくいっているRegistration Replyメッセージが受信されるまで、Registration Replyメッセージに提供します。
Status codes allowable for use within the FA Error Extension are within the range 64-127. The currently specified codes are as follows:
範囲64-127の中にFA Error Extensionの中の使用において、許容できるステータスコードがあります。 現在指定されたコードは以下の通りです:
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
不特定の65が行政上66の不十分なリソース68ホームのエージェントを禁止した64理由が認証71不十分に形成されたReply77病人に失敗した、注意、-、アドレス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.
使用のためのRFC3344[4]でForeignエージェントによって定義されるように。 Registration ReplyメッセージのCode分野での使用のためにFA Error拡張子による使用のためのステータスコードを異なって定義してはいけません。
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.
外国人のエージェントがホームのエージェントから受け取るようにFA Error ExtensionをRegistration Replyに追加するとき、それは、付加的な4バイトの長さを説明するためにUDPヘッダー[5]のUDP Length分野をアップデートしなければなりません。
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を含むようにRegistration Replyの「状態」分野を変更することの代わりに、今、外国人のエージェントは状態値68を含むForeignエージェントError Extensionを追加するべきです。
5. Mobile Node Considerations
5. モバイルノード問題
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.
モバイルノードがうまくいっているRegistration Reply(ステータスコード0か1)を受けるなら、FA Error Extensionが、外国人のエージェントが前述のRegistration Replyを尊敬していないのを示していて、モバイルノードSHOULDは反登録メッセージをホームのエージェントに送ります。 このように、ホームのエージェントは外国人のエージェントによって維持される状態に反している登録状態を維持しないでしょう。
Perkins Standards Track [Page 3] RFC 4636 FA Error Extension October 2006
パーキンスStandardsはファ誤り拡大2006年10月にRFC4636を追跡します[3ページ]。
6. Foreign Agent Considerations
6. 外国エージェント問題
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.
うまくいっているRegistration Replyを否定するとき、移動性セキュリティ協会がそれらの間に存在するなら、ForeignエージェントSHOULDはRegistration Revocationメッセージ[2]をホームのエージェントに送ります。 ホームのエージェントに知らせるこの方法には、外国人のエージェントに必要なセキュリティ協会があるときのケースのために、悪意がある外国人のエージェントによる有害な動きからの脆弱性がありません、セクション8で注意されるように。
7. IANA Considerations
7. IANA問題
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]のための仕様に基づき定義された非skippable移動性拡張子(すなわち、0-127)の数のスペースからFA Error Extension(セクション3を見る)の1つの数を予約します。
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 Error Extensionで許容できるステータスコードはモバイルIPv4[4]のための仕様に基づき定義されたステータスコードの部分集合です。 追加ステータスコードが将来モバイルIPv4のために定義されるなら、それぞれの新しいステータスコードのための定義は、FA Error Extensionにおける使用において、新しいステータスコードが許容できるかどうかを示さなければなりません。
8. Security Considerations
8. セキュリティ問題
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.
モバイルノードがRegistration Requestの中で提供された情報の信憑性を保証されるのを許容することによって、拡大は本書ではモバイルIPv4のセキュリティ機能を改良します。 以前、外国人のエージェントが状態情報をモバイルノードに提供しなければならなかったときはいつも、モバイルホームAuthentication Extensionデータは、モバイル機器の能力を破壊することによって、そう確かめられることができるだけでしょう。
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
多くのよくある例には、モバイルノードでは、拡大を送った外国人のエージェントとのセキュリティ仲間がいないでしょう。 したがって、モバイルノードは、拡張Registration Replyメッセージを送る外国人のエージェントがモバイルノードからの関連Registration Requestが、より早く受信したのと同じ外国人のエージェントであることを確かめることができないでしょう。 これのために、悪意がある外国人のエージェントはモバイルノードをまるで登録が作動したかのように作動させるかもしれません。
Perkins Standards Track [Page 4] RFC 4636 FA Error Extension October 2006
パーキンスStandardsはファ誤り拡大2006年10月にRFC4636を追跡します[4ページ]。
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.
失敗されていて、いつ、事実上、ホームのエージェントと正しく稼働している外国人のエージェントには両方があったかがモバイルノードのRegistration Requestを受け入れました。 非認証された拡大に従ってそのような陰湿に伝えられたRegistration Replyメッセージに脆弱性を減少させて、そのようなもののモバイルノード5月の遅れ処理は、別のうまくいっているRegistration Replyが外国人のエージェントから受け取られるかもしれないかどうか決定するために短時間Registration Replyに対してメッセージを否定しました。
9. Acknowledgements
9. 承認
Thanks to Kent Leung and Henrik Lefkowetz for suggested improvements to this specification.
この仕様への提案改善をケントレオンとHenrik Lefkowetzをありがとうございます。
10. Normative References
10. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Glass, S. and M. Chandra, "Registration Revocation in Mobile
IPv4", RFC 3543, August 2003.
[2] S.とM.チャンドラ、「モバイルIPv4"、RFC3543、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2002.
[4] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[5] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[5] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、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ページ工場道路、Suite200パロアルトについて研究します、カリフォルニア94304-1003
Phone: +1 650-496-4402 Fax: +1-650-739-0779 EMail: charles.perkins@nokia.com
以下に電話をしてください。 +1 650-496-4402Fax: +1-650-739-0779 メールしてください: charles.perkins@nokia.com
Perkins Standards Track [Page 5] RFC 4636 FA Error Extension October 2006
パーキンスStandardsはファ誤り拡大2006年10月にRFC4636を追跡します[5ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Perkins Standards Track [Page 6]
パーキンス標準化過程[6ページ]
一覧
スポンサーリンク
