Network Working Group V. Sastry
Request for Comments: 4917 Samsung Electronics
Category: Standards Track K. Leung
A. Patel
Cisco Systems
June 2007
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
移动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 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
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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 ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.)
文本字段是一个或多个八位字节，其内容取决于实现。其目的是让人可读，并且不得影响协议的操作。消息必须使用UTF-8编码的ISO-10646[RFC3629]字符。消息的编码表示中的八位字节数始终正好是长度字段的值减去一。（此八位字节序列表示的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.
本规范为第3节中的消息字符串扩展保留第145号，该扩展来自为以下位置的移动IPv4[RFC3344]定义的可跳过移动扩展（即128-255）的数字空间：http://www.iana.org/assignments/mobileip-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.
作者要感谢Avi Lior、Curtis教务长和Henrik Levkowetz对本文件早期版本的有用评论。此外，Russ Housley、Vidya Narayanan、Blake Ramsdell、Paul Hoffman和Jeff Hutzelman提供了在消息中只需要UTF-8编码的理由，并在安全考虑部分寻求更好的澄清。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，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.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]Perkins，C.，Ed.，“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第五D交叉吉里那加一期班加罗尔560085印度
Phone: +91-80-26725942
EMail: venkat.sastry@gmail.com
Phone: +91-80-26725942
EMail: venkat.sastry@gmail.com
Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
美国加利福尼亚州圣何塞塔斯曼大道西170号肯特梁思科系统公司，邮编95134
Phone: +1 408-526-5030
EMail: kleung@cisco.com
Phone: +1 408-526-5030
EMail: kleung@cisco.com
Alpesh Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
美国加利福尼亚州圣何塞塔斯曼大道西170号阿尔佩什帕特尔思科系统公司，邮编95134
Phone: +1 408-853-9580
EMail: alpesh@cisco.com
Phone: +1 408-853-9580
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。