RFC4917 日本語訳
4917 Mobile IPv4 Message String Extension. V. Sastry, K. Leung, A.Patel. June 2007. (Format: TXT=13302 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Sastry
Request for Comments: 4917 Samsung Electronics
Category: Standards Track K. Leung
A. Patel
Cisco Systems
June 2007
Sastryがコメントのために要求するワーキンググループV.をネットワークでつないでください: 4917年の三星電子カテゴリ: 標準化過程K.レオンA.パテルシスコシステムズ2007年6月
Mobile IPv4 Message String Extension
モバイル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 IETF Trust (2007).
IETFが信じる著作権(C)(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における使用のための新しい拡大を指定します。 ホームのエージェントとForeignエージェントはこの拡大をRegistration Replyメッセージに追加できます。 この拡大はモバイルNodeのユーザのために意図するテキスト文字列を運びます。
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
1. 序論…2 2. 用語…2 3. モバイルIPv4メッセージストリング拡大形式…2 4. メッセージの操作と使用は拡大を結びます…3 5. セキュリティ問題…4 6. IANA問題…4 7. 承認…5 8. 標準の参照…5
Sastry, et al. Standards Track [Page 1] RFC 4917 Mobile IPv4 Message String Extension June 2007
Sastry、他 IPv4メッセージストリング拡大2007年6月のモバイルの標準化過程[1ページ]RFC4917
1. Introduction
1. 序論
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.
このドキュメントはForeignエージェントとホームのエージェントがモバイルNodeのために狙うどんな登録メッセージでも加えることができる新しいskippable拡張子を指定します。 そのようなメッセージがRegistration ReplyかRegistration Revocationのどちらかであるかもしれない、(すなわち、共同見つけられる、Care、-、Addressモード) Registration Replyメッセージに関しては、この拡大に登録が成功したかどうかにかかわらず加えるか、または失敗できます。
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.
モバイルNodeによるこの拡大とその用法によるテキスト文字列の内容は実装特有です。 この拡大におけるテキスト文字列はモバイルNodeのユーザのために意図します。 例えば、いかなる他の実装に依存する方法でもこのメッセージをモバイルNodeのユーザーインタフェースの上に表示するか、登録するか、または扱うことができます、モバイル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.
テキスト文字列の典型的なコンテンツは、登録失敗理由を示すか、またはうまくいっている登録に関する歓迎メッセージを与えるでしょう。 これは重要です、失敗理由コードがモバイルNodeのユーザによる解釈のために非常に限られた情報を教えるとき。 例えば、「登録は失敗しました」のようなストリング 「ユーザのための前払いのQuotaは消耗していること」がモバイルIP登録の結果の人間の読み込み可能な記述を与えることができます。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Mobile IPv4 Message String Extension Format
3. モバイルIPv4メッセージストリング拡大形式
The Message String Extension conforms to the Short Extension format specified for Mobile IPv4 [RFC3344]. The Message String Extension is a skippable extension.
Message String ExtensionはモバイルIPv4[RFC3344]に指定されたShort Extension形式に従います。 Message String 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 | Text ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
以下をタイプしてください。
145: An 8-bit identifier of the type mobility option.
145: タイプ移動性オプションの8ビットの識別子。
Sastry, et al. Standards Track [Page 2] RFC 4917 Mobile IPv4 Message String Extension June 2007
Sastry、他 IPv4メッセージストリング拡大2007年6月のモバイルの標準化過程[2ページ]RFC4917
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ビットの符号のない整数。 拡大Typeと拡大Length分野を除いたバイトで表現される拡大の長さ。 Text分野の1と全長にこの分野を設定しなければなりません。
Sub-Type:
サブタイプ:
1: Extension comes from the Home Agent
1: 拡大はホームのエージェントから来ます。
2: Extension comes from the Foreign Agent
2: 拡大はForeignエージェントから来ます。
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.)
Text分野は1つ以上の八重奏です、そして、内容は実装に依存しています。 それは、人間読み込み可能であることを意図して、プロトコルの操作に影響してはいけません。 メッセージがUTF-8コード化されたISO-10646[RFC3629]キャラクタにあるに違いありません。 いつもメッセージのコード化された表現における、八重奏の数はまさに1を引いたLength分野の値です。 (この八重奏系列によって代理をされたユニコードキャラクタの数は八重奏の数より少ないかもしれません。)
4. Operation and Use of the Message String Extension
4. メッセージストリング拡張子の操作と使用
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 Registration ReplyとRegistration Revocationメッセージの中の使用だけに、Message String Extensionは有効です。 Message String Extensionはskippable拡張子です。 ホームのエージェントかForeignエージェントか両方のどちらかが登録メッセージにMessage String Extensionを追加できます。 Message String ExtensionのText分野の用法は実装に依存しています。 例えば、実装に依存する方法でメッセージをモバイルNodeのユーザーインタフェースの上に表示するか、登録するか、または扱うことができます、モバイルNodeのフォームによって。 モバイルNodeはしばしば、ユーザがメッセージについてどう通知されるかを阻止するかもしれません。
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
例として、ホームのエージェントは、ユーザへの前払いの割当てに達しているので最初のRegistration Requestを拒絶して、「前払いの割当ては達した」テキストでMessage String Extensionを取り付けるかもしれません。 「www.paymore.example.comに連絡して、バランスをアップデートしてください。」 モバイルNodeはユーザーインタフェースの上にこれを表示できました。 応答として、モバイルNodeのユーザは、前払いのアカウントをアップデートして、登録手続を再試行するために必要な行動を取るかもしれません。 ホームのエージェントは、このRegistration Requestを受け入れて、Messageを取り付けるかもしれません。
Sastry, et al. Standards Track [Page 3] RFC 4917 Mobile IPv4 Message String Extension June 2007
Sastry、他 IPv4メッセージストリング拡大2007年6月のモバイルの標準化過程[3ページ]RFC4917
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へようこそ」をExtensionに通してください。 モバイルNodeはユーザーインタフェースの上にこれを表示して、その結果、ホームのエージェントの上で付くうまくいっている作成を確認できました。
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]キャラクタにメッセージを変換しなければなりません。
5. Security Considerations
5. セキュリティ問題
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.
ホームのエージェント、Foreignエージェントまたは両方でMessage String Extensionを加えることができます。 拡大の保護はRFC3344[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との拡大)によってRegistration ReplyかRegistration Revocationメッセージに追加されるなら、それはモバイルホームAuthentication Extension[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.
拡大がForeignエージェント(「副-タイプ」2との拡大)によってRegistration Replyメッセージに追加されるなら、存在しているときはいつも、それはモバイルホームAuthentication Extension[RFC3344]の後に現れなければなりません。 また、存在しているときはいつも、拡大はモバイルに外国のAuthentication Extensionの前に現れなければなりません。 しかしながら、モバイルNodeとForeignエージェントとのセキュリティ仲間が任意であるので、拡大がこの場合認証されないのは、可能です。
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.
拡大で提供された秘密性が全くありません。 非暗号化されていた状態でメッセージを移します、そして、ディスプレイ目的のために機密情報を送るなら、それは他の手段で保護される必要があるかもしれません。
6. IANA Considerations
6. IANA問題
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.
この仕様はセクション3でモバイルIPv4[RFC3344]のために http://www.iana.org/assignments/mobileip-numbers で定義されたskippable移動性拡張子(すなわち、128-255)の数のスペースからMessage String ExtensionのNo.145を予約します。
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は使用のために予約されます。
Sastry, et al. Standards Track [Page 4] RFC 4917 Mobile IPv4 Message String Extension June 2007
Sastry、他 IPv4メッセージストリング拡大2007年6月のモバイルの標準化過程[4ページ]RFC4917
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は使用のためにForeignエージェントによって予約されます。 モバイルIPv4[RFC3344]数の空間に指定された手順と同様です、この数のスペースからの今後の配分は専門のレビュー[RFC2434]を必要とします。
7. Acknowledgements
7. 承認
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、カーティス事務長とHenrik Levkowetzに感謝したがっています。 また、ラスHousley、Vidyaナラヤナン、ブレークRamsdell、ポール・ホフマン、およびジェフHutzelmanはメッセージにおけるUTF-8コード化だけの必要性を強制するために正当化を提供して、セキュリティ問題部で、より良い明確化に請求しました。
8. Normative References
8. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」BCP26、RFC2434(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.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
3344, August 2002.
[RFC3344] パーキンス、C.、エド、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
Sastry, et al. Standards Track [Page 5] RFC 4917 Mobile IPv4 Message String Extension June 2007
Sastry、他 IPv4メッセージストリング拡大2007年6月のモバイルの標準化過程[5ページ]RFC4917
Authors' Addresses
作者のアドレス
Venkateshwara Sastry Samsung Electronics 124/C 5th D Cross Girinagar I Phase Bangalore 560085 India
第5D Venkateshwara Sastry三星電子124/Cの交差しているGirinagar IフェーズBangalore560085インド
Phone: +91-80-26725942 EMail: venkat.sastry@gmail.com
以下に電話をしてください。 +91-80-26725942はメールされます: venkat.sastry@gmail.com
Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
ケントレオン・シスコシステムズ170w.タスマン・Driveカリフォルニア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パテルシスコシステムズ170w.タスマンDriveサンノゼ、カリフォルニア95134米国
Phone: +1 408-853-9580 EMail: alpesh@cisco.com
以下に電話をしてください。 +1 408-853-9580 メールしてください: alpesh@cisco.com
Sastry, et al. Standards Track [Page 6] RFC 4917 Mobile IPv4 Message String Extension June 2007
Sastry、他 IPv4メッセージストリング拡大2007年6月のモバイルの標準化過程[6ページ]RFC4917
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントは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, 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Sastry, et al. Standards Track [Page 7]
Sastry、他 標準化過程[7ページ]
一覧
スポンサーリンク
