Network Working Group V. Sastry
Request for Comments: 4917 Samsung Electronics
Category: Standards Track K. Leung
A. Patel
Cisco Systems
June 2007
Mobile IPv4 Message String Extension
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 IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document specifies a new extension for use in Mobile IPv4. This extension can be added by the Home Agent and the Foreign Agent to Registration Reply messages. This extension carries a text string that is intended for the user of the Mobile Node.
この文書では、モバイルIPv4で使用するための新しい拡張子を指定します。この拡張は、登録応答メッセージにホームエージェントと外部エージェントによって追加することができます。この拡張は、モバイルノードのユーザのために意図されたテキスト文字列を運びます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Mobile IPv4 Message String Extension Format .....................2
4. Operation and Use of the Message String Extension ...............3
5. Security Considerations .........................................4
6. IANA Considerations .............................................4
7. Acknowledgements ................................................5
8. Normative References ............................................5
This document specifies a new skippable extension that can be added by the Foreign Agent and Home Agent in any registration message targeted for the Mobile Node. Such a message may be either a Registration Reply or Registration Revocation (i.e., co-located Care-of Address mode). For the Registration Reply message, this extension can be added regardless of whether the registration has succeeded or failed.
この文書では、モバイルノードを対象とした登録メッセージに外部エージェントとホームエージェントによって追加することができ、新たなスキップ可能な拡張子を指定します。そのようなメッセージは、登録応答または登録取り消し（すなわち、同一位置気付アドレスモード）のいずれであってもよいです。登録応答メッセージの場合、この拡張機能は関係なく、登録が成功したか失敗したかの追加することができます。
The content of the text string in this extension and its usage by the Mobile Node is implementation specific. The text string in this extension is intended for the user of the Mobile Node. For example, this message can be displayed on the Mobile Node's user interface, logged, or handled in any other implementation dependent way, depending on the form of the Mobile Node.
モバイルノードによって、この拡張機能とその使用法のテキスト文字列の内容は実装固有のものです。この拡張機能でテキスト文字列は、モバイルノードのユーザーを対象としています。たとえば、このメッセージは、モバイルノードの形に応じて、他のインプリメンテーションに依存するように、移動ノードのユーザインターフェイス上に表示ログインし、又は処理することができます。
Typical contents of the text string will indicate a registration failure reason, or give a welcome message on successful registration. This is important, as the failure reason code gives very limited information for interpretation by the user of the Mobile Node. For example, a string like "registration failed : Prepaid Quota for the user is exhausted" can give a human readable description of the result of Mobile IP registration.
テキスト文字列の典型的な内容は、登録失敗の理由を示す、または成功した登録に歓迎のメッセージを表示します。失敗の理由コードは、モバイルノードの使用者による解釈のための非常に限られた情報を提供しますので、これは、重要です。例えば、のような文字列「登録に失敗しました：ユーザーのためのプリペイドクォータが消耗している」モバイルIP登録の結果についての人間が読める形式の説明を与えることができます。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The Message String Extension conforms to the Short Extension format specified for Mobile IPv4 [RFC3344]. The Message String Extension is a skippable extension.
メッセージ文字列の拡張はモバイルIPv4 [RFC3344]に指定されたショート拡張フォーマットに準拠しています。メッセージ文字列拡張はスキップ可能な拡張機能です。
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 | Text ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
145: An 8-bit identifier of the type mobility option.
145：型モビリティオプションの8ビットの識別子。
Length:
長さ：
An 8-bit unsigned integer. Length of the extension, in bytes, excluding the extension Type and the extension Length fields. This field MUST be set to 1 plus the total length of the Text field.
8ビットの符号なし整数。拡張タイプと拡張長フィールドを除くバイト単位で延長の長さ、。このフィールドは、テキストフィールドの合計の長さに1を加えたに設定しなければなりません。
Sub-Type:
サブタイプ：
1: Extension comes from the Home Agent
1：拡張は、ホームエージェントから来ています
2: Extension comes from the Foreign Agent
2：拡張は、フォーリンエージェントから来ています
Text:
テキスト：
The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect the operation of the protocol. The message MUST be in UTF-8 encoded ISO-10646 [RFC3629] characters. The number of octets in the encoded representation of the message is always exactly the value of the Length field minus one. (The number of unicode characters represented by this octet sequence may be smaller than the number of octets.)
テキストフィールドは1オクテット以上で、その内容は実装に依存しています。人間読み込み可能であることを意図しており、プロトコルの動作に影響してはいけません。メッセージは、UTF-8でなければなりませんISO-10646 [RFC3629]の文字エンコード。メッセージのエンコードされた表現のオクテットの数は常に正確に長さフィールドの値がマイナス1です。 （このオクテット配列で表されるUnicode文字の数は、オクテットの数よりも小さくてもよいです。）
The Message String Extension is only valid for use within Mobile IPv4 Registration Reply and Registration Revocation messages. The Message String Extension is a skippable extension. Either the Home Agent or Foreign Agent or both can add the Message String Extension to registration messages. The usage of Text field of the Message String Extension is implementation dependent. For example, the message can be displayed on the Mobile Node's user interface, logged, or handled in an implementation dependent way, depending on the form of the Mobile Node. The Mobile Node may throttle how often the user is notified of the message.
メッセージ文字列拡張は、モバイルIPv4登録応答および登録失効メッセージ内で使用するためにのみ有効です。メッセージ文字列拡張はスキップ可能な拡張機能です。ホームエージェントまたは外部エージェントのいずれか、または両方が登録メッセージへのメッセージ文字列の拡張子を追加することができます。メッセージ文字列拡張のテキストフィールドの使用は実装依存です。例えば、メッセージは、モバイルノードの形に応じて、実装に依存するように、移動ノードのユーザインターフェイス上に表示ログインし、又は処理することができます。モバイルノードは、ユーザーがメッセージを通知する頻度を絞ることがあります。
As an example, the Home Agent may reject the first Registration Request because the prepaid quota for the user is reached and may attach a Message String Extension with the text "Prepaid quota reached. Please contact www.paymore.example.com to update balance". The Mobile Node could display this on the user interface. As a response, the user of the Mobile Node may take the required action to update the prepaid account and retry the registration process. The Home Agent may accept this Registration Request and attach a Message
例として、ホームエージェントは最初の登録要求を拒否することができる利用者のためのプリペイドクォータに達するとテキストでメッセージ文字列の拡張子を付ける可能性があるため、「到達プリペイドクォータ。バランスを更新するwww.paymore.example.comに連絡してください」 。モバイルノードは、ユーザーインターフェイスでこれを表示することができます。応答として、モバイルノードのユーザーは、プリペイドアカウントを更新し、登録プロセスを再試行するために必要な行動をとることがあります。ホームエージェントは、この登録要求を受け入れ、メッセージを添付すること
String Extension with the text "Welcome to www.serviceprovider.example.com". The Mobile Node could display this on the user interface, thus confirming a successful creation of binding on Home Agent.
テキスト「www.serviceprovider.example.comへようこそ」との文字列の拡張子。モバイルノードは、このようにホームエージェントにバインディングの作成に成功したことを確認し、ユーザーインターフェース上で、これを表示することができます。
In the case that the message is not originated by the Home Agent itself, but for instance, is received from a RADIUS server [RFC2865], it could be received in some other encoding than UTF-8. If so, the Home Agent MUST convert the message to UTF-8 encoded ISO-10646 [RFC3629] characters.
メッセージがホームエージェント自身が発信されず、例えば、RADIUSサーバ[RFC2865]から受信された場合には、UTF-8以外の何らかの符号で受信することができます。その場合、ホームエージェントはUTF-8にメッセージを変換する必要がありますISO-10646 [RFC3629]の文字をエンコードされました。
The Message String Extension can be added by the Home Agent or Foreign Agent or both. The protection of the extension is based on the ordering method specified for message authentication in RFC 3344 [RFC3344] and emphasized below.
メッセージ文字列拡張は、ホームエージェントまたは外部エージェント、またはその両方で追加することができます。拡張の保護は、RFC 3344にメッセージ認証に指定された発注方法[RFC3344]に基づき、以下の強調されています。
If the extension is added by the Home Agent (extension with subtype 1) to a Registration Reply or Registration Revocation message, it MUST appear before Mobile-Home Authentication Extension [RFC3344].
拡張子が登録応答または登録取り消しメッセージにホームエージェント（サブタイプ1との拡張）によって追加された場合は、モバイルホーム認証拡張[RFC3344]の前に現れなければなりません。
If the extension is added by the Foreign Agent (extension with subtype 2) to a Registration Reply message, it MUST appear after Mobile-Home Authentication Extension [RFC3344] whenever present. Also the extension MUST appear before the Mobile-Foreign Authentication Extension whenever present. However, since security association between the Mobile Node and Foreign Agent is optional, it is possible that the extension is not authenticated in this case.
拡張子が登録応答メッセージに外部エージェント（サブタイプ2と拡張）によって追加されている場合は、モバイル・ホーム認証拡張[RFC3344]いつでも存在した後に表示される必要があります。また、拡張機能は、モバイル・外国の認証拡張時はいつでも存在の前に現れなければなりません。モバイルノードと外部エージェント間のセキュリティアソシエーションがオプションであるため、しかし、拡張子が、この場合には、認証されていない可能性があります。
There is no confidentiality provided by the extension; the message is transferred unencrypted, and if sensitive information is sent for display purposes, it may need to be protected by other means.
拡張モジュールが提供するいかなる機密性はありません。メッセージが暗号化されていない転送され、機密情報が表示のために送信される場合、それは他の手段によって保護される必要があり得ます。
This specification reserves number 145 for the Message String Extension in Section 3 from the space of numbers for skippable mobility extensions (i.e., 128-255) defined for Mobile IPv4 [RFC3344] at http://www.iana.org/assignments/mobileip-numbers.
この仕様はhttp://www.iana.org/assignments/mobileipにおいてモバイルIPv4 [RFC3344]のために定義されたスキップ可能モビリティ拡張（すなわち、128-255）のための数の空間から第3のメッセージ文字列拡張用番号145を留保します-numbers。
This specification also creates a new subtype space for the type number of this extension. The subtype values 1 and 2 are defined in this specification. The subtype value 1 is reserved for use by the
また、この仕様は、この拡張のタイプ番号のための新しいサブタイプのスペースを作成します。サブタイプ値1及び2は、本明細書で定義されています。サブタイプ値1で使用するために予約されています
Home Agent and subtype value 2 is reserved for use by the Foreign Agent. Similar to the procedures specified for Mobile IPv4 [RFC3344] number spaces, future allocations from this number space require expert review [RFC2434].
ホームエージェントとサブタイプ値2は、外部エージェントが使用するために予約されています。モバイルIPv4 [RFC3344]数のスペースのために規定された手順と同様に、この番号空間から、将来の配分は専門家レビュー[RFC2434]を必要としています。
The authors would like to thank Avi Lior, Curtis Provost, and Henrik Levkowetz for their useful comments on an earlier version of this document. Also, Russ Housley, Vidya Narayanan, Blake Ramsdell, Paul Hoffman, and Jeff Hutzelman provided justifications to mandate the need for only UTF-8 encoding in the message and solicited better clarifications in the security considerations section.
作者はこのドキュメントの以前のバージョンの彼らの役に立つコメントをアビLIOR、カーティス学長、とヘンリクLevkowetzに感謝したいと思います。また、ラスHousley、Vidyaナラヤナンは、ブレイクRamsdell、ポール・ホフマン、そしてジェフHutzelmanはメッセージにのみUTF-8エンコーディングの必要性を強制するために正当化を提供し、セキュリティ上の考慮事項のセクションでより良い明確化を求め。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
Authors' Addresses
著者のアドレス
Venkateshwara Sastry Samsung Electronics 124/C 5th D Cross Girinagar I Phase Bangalore 560085 India
Venkateshwara Sastryサムスン電子124 / Cの第5回DクロスGirinagar I相バンガロール560085インド
Phone: +91-80-26725942 EMail: venkat.sastry@gmail.com
電話：+ 91-80-26725942 Eメール：venkat.sastry@gmail.com
Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
ケント・レオンシスコシステムズ170 W.タスマン・ドライブサンノゼ、CA 95134米国
Phone: +1 408-526-5030 EMail: kleung@cisco.com
電話：+1 408-526-5030電子メール：kleung@cisco.com
Alpesh Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
Alpeshパテルシスコシステムズ170 W.タスマン・ドライブサンノゼ、CA 95134米国
Phone: +1 408-853-9580 EMail: alpesh@cisco.com
電話：+1 408-853-9580電子メール：alpesh@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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, THE IETF TRUST 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。