Network Working Group A. Patel
Request for Comments: 4283 K. Leung
Category: Standards Track Cisco Systems
M. Khalil
H. Akhtar
Nortel Networks
K. Chowdhury
Starent Networks
November 2005
Network Working Group A. Patel
Request for Comments: 4283 K. Leung
Category: Standards Track Cisco Systems
M. Khalil
H. Akhtar
Nortel Networks
K. Chowdhury
Starent Networks
November 2005
Mobile Node Identifier Option for Mobile IPv6 (MIPv6)
移动IPv6（MIPv6）的移动节点标识符选项
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
Mobile IPv6 (MIPv6) defines a new Mobility header that is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address. Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), International Mobile Station Identifier (IMSI), and Mobile Subscriber Number (MSISDN). This document defines a new mobility option that can be used by Mobile IPv6 entities to identify themselves in messages containing a mobility header.
移动IPv6（MIPv6）定义了一个新的移动报头，移动节点、对应节点和归属代理在与绑定的创建和管理相关的所有消息传递中使用该报头。移动IPv6节点需要能够使用默认家庭IP地址以外的身份来识别自己。标识符的一些示例包括网络访问标识符（NAI）、完全限定域名（FQDN）、国际移动站标识符（IMSI）和移动用户号码（MSISDN）。本文档定义了一个新的移动选项，移动IPv6实体可以使用该选项在包含移动报头的消息中标识自己。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Mobile Node Identifier Option ...................................3
3.1. MN-NAI Mobility Option .....................................4
3.2. Processing Considerations ..................................4
4. Security Considerations .........................................4
4.1. General Considerations .....................................4
4.2. MN-NAI Considerations ......................................4
5. IANA Considerations .............................................5
6. Acknowledgements ................................................5
7. Normative References ............................................5
8. Informative Reference ...........................................6
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Mobile Node Identifier Option ...................................3
3.1. MN-NAI Mobility Option .....................................4
3.2. Processing Considerations ..................................4
4. Security Considerations .........................................4
4.1. General Considerations .....................................4
4.2. MN-NAI Considerations ......................................4
5. IANA Considerations .............................................5
6. Acknowledgements ................................................5
7. Normative References ............................................5
8. Informative Reference ...........................................6
The base specification of Mobile IPv6 [RFC3775] identifies mobility entities using an IPv6 address. It is essential to have a mechanism wherein mobility entities can be identified using other identifiers (for example, a Network Access Identifier (NAI) [RFC4282], International Mobile Station Identifier (IMSI), or an application/ deployment specific opaque identifier).
移动IPv6的基本规范[RFC3775]使用IPv6地址标识移动实体。必须具有一种机制，其中可以使用其他标识符（例如，网络接入标识符（NAI）[RFC4282]、国际移动站标识符（IMSI）或特定于应用/部署的不透明标识符）来识别移动实体。
The capability to identify a mobility entity via identifiers other than the IPv6 address can be leveraged for performing various functions, for example,
通过IPv6地址以外的标识符识别移动实体的能力可用于执行各种功能，例如，
o authentication and authorization using an existing AAA (Authentication, Authorization, and Accounting) infrastructure or via an HLR/AuC (Home Location Register/Authentication Center)
o 使用现有AAA（身份验证、授权和记帐）基础设施或通过HLR/AuC（归属位置注册/身份验证中心）进行身份验证和授权
o dynamic allocation of a mobility anchor point
o 机动性锚点的动态分配
o dynamic allocation of a home address
o 家庭地址的动态分配
This document defines an option with a subtype number that denotes a specific type of identifier. One instance of subtype, the NAI, is defined in Section 3.1. It is anticipated that other identifiers will be defined for use in the mobility header in the future.
本文档定义了一个带有子类型号的选项，该子类型号表示特定类型的标识符。第3.1节定义了子类型的一个实例NAI。预计将定义其他标识符以供将来在移动报头中使用。
This option SHOULD be used when Internet Key Exchange (IKE)/IPsec is not used for protecting binding updates or binding acknowledgements as specified in [RFC3775]. It is typically used with the authentication option [RFC4285]. But this option may be used independently. For example, the identifier can provide accounting and billing services.
当Internet密钥交换（IKE）/IPsec未用于保护[RFC3775]中指定的绑定更新或绑定确认时，应使用此选项。它通常与身份验证选项[RFC4285]一起使用。但此选项可以单独使用。例如，标识符可以提供记帐和计费服务。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The Mobile Node Identifier option is a new optional data field that is carried in the Mobile IPv6-defined messages that includes the Mobility header. Various forms of identifiers can be used to identify a Mobile Node (MN). Two examples are a Network Access Identifier (NAI) [RFC4282] and an opaque identifier applicable to a particular application. The Subtype field in the option defines the specific type of identifier.
“移动节点标识符”选项是一个新的可选数据字段，它包含在移动IPv6定义的消息中，该消息包括移动报头。可以使用各种形式的标识符来识别移动节点（MN）。两个示例是网络访问标识符（NAI）[RFC4282]和适用于特定应用的不透明标识符。选项中的子类型字段定义标识符的特定类型。
This option can be used in mobility messages containing a mobility header. The subtype field in the option is used to interpret the specific type of identifier.
此选项可用于包含移动头的移动消息中。选项中的子类型字段用于解释特定类型的标识符。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type:
选项类型：
MN-ID-OPTION-TYPE has been assigned value 8 by the IANA. It is an 8-bit identifier of the type mobility option.
IANA为MN-ID-OPTION-TYPE分配了值8。它是移动选项类型的8位标识符。
Option Length:
选项长度：
8-bit unsigned integer, representing the length in octets of the Subtype and Identifier fields.
8位无符号整数，表示子类型和标识符字段的长度（以八位字节为单位）。
Subtype:
子类型：
Subtype field defines the specific type of identifier included in the Identifier field.
子类型字段定义标识符字段中包含的标识符的特定类型。
Identifier:
标识符：
A variable length identifier of type, as specified by the Subtype field of this option.
此选项的子类型字段指定的类型的可变长度标识符。
This option does not have any alignment requirements.
此选项没有任何对齐要求。
The MN-NAI mobility option uses the general format of the Mobile Node Identifier option as defined in Section 3. This option uses the subtype value of 1. The MN-NAI mobility option is used to identify the mobile node.
MN-NAI移动选项使用第3节中定义的移动节点标识符选项的通用格式。此选项使用子类型值1。MN-NAI移动选项用于识别移动节点。
The MN-NAI mobility option uses an identifier of the form user@realm [RFC4282]. This option MUST be implemented by the entities implementing this specification.
MN-NAI移动选项使用表单的标识符user@realm[RFC4282]。此选项必须由实施本规范的实体实施。
The location of the MN Identifier option is as follows: When present, this option MUST appear before any authentication-related option in a message containing a Mobility header.
MN Identifier选项的位置如下：如果存在，则该选项必须出现在包含移动报头的消息中任何与身份验证相关的选项之前。
Mobile IPv6 already contains one mechanism for identifying mobile nodes, the Home Address option [RFC3775]. As a result, the vulnerabilities of the new option defined in this document are similar to those that already exist for Mobile IPv6. In particular, the use of a permanent, stable identifier may compromise the privacy of the user, making it possible to track a particular device or user as it moves through different locations.
移动IPv6已经包含一种识别移动节点的机制，即家庭地址选项[RFC3775]。因此，本文档中定义的新选项的漏洞与移动IPv6中已经存在的漏洞类似。具体地说，使用永久、稳定的标识符可能会损害用户的隐私，使得能够在特定设备或用户在不同位置移动时跟踪该设备或用户。
Since the Mobile Node Identifier option described in Section 3 reveals the home affiliation of a user, it may assist an attacker in determining the identity of the user, help the attacker in targeting specific victims, or assist in further probing of the username space.
由于第3节中描述的移动节点标识符选项揭示了用户的归属关系，因此它可以帮助攻击者确定用户的身份，帮助攻击者瞄准特定的受害者，或者帮助进一步探测用户名空间。
These vulnerabilities can be addressed through various mechanisms, such as those discussed below:
这些漏洞可以通过各种机制解决，如下面讨论的机制：
o Encrypting traffic at the link layer, such that other users on the same link do not see the identifiers. This mechanism does not help against attackers on the rest of the path between the mobile node and its home agent.
o 在链路层加密通信量，以便同一链路上的其他用户看不到标识符。此机制无助于在移动节点与其归属代理之间的其余路径上抵御攻击者。
o Encrypting the whole packet, such as when using IPsec to protect the communications with the home agent [RFC3776].
o 加密整个数据包，例如使用IPsec保护与归属代理的通信[RFC3776]。
o Using an authentication mechanism that enables the use of privacy NAIs [RFC4282] or temporary, changing "pseudonyms" as identifiers.
o 使用能够使用隐私NAI[RFC4282]或临时更改“假名”作为标识符的身份验证机制。
In any case, it should be noted that as the identifier option is only needed on the first registration at the home agent and subsequent registrations can use the home address, the window of privacy vulnerability in this document is reduced as compared to [RFC3775]. In addition, this document is a part of a solution to allow dynamic home addresses to be used. This is an improvement to privacy as well, and it affects both communications with the home agent and the correspondent nodes, both of which have to be told the home address.
在任何情况下，应注意，由于标识符选项仅在家庭代理的第一次注册时需要，并且后续注册可以使用家庭地址，因此与[RFC3775]相比，本文档中的隐私漏洞窗口减少。此外，本文档是允许使用动态家庭地址的解决方案的一部分。这也是对隐私的改进，并且它影响与归属代理和对应节点的通信，这两个节点都必须被告知归属地址。
The values for new mobility options must be assigned from the Mobile IPv6 [RFC3775] numbering space.
新移动选项的值必须从移动IPv6[RFC3775]编号空间分配。
The IANA has assigned the value 8 for the MN-ID-OPTION-TYPE.
IANA已为MN-ID-OPTION-TYPE分配了值8。
In addition, IANA has created a new namespace for the subtype field of the Mobile Node Identifier option. The currently allocated values are as follows:
此外，IANA还为移动节点标识符选项的子类型字段创建了一个新名称空间。当前分配的值如下所示：
NAI (defined in [RFC4282]).
NAI（定义见[RFC4282]）。
New values for this namespace can be allocated using Standards Action [RFC2434].
可以使用标准操作[RFC2434]为此命名空间分配新值。
The authors would like to thank Basavaraj Patil for his review and suggestions on this document. Thanks to Jari Arkko for review and suggestions regarding security considerations and various other aspects of the document.
作者感谢Basavaraj Patil对本文件的评论和建议。感谢Jari Arkko对本文件的安全考虑和其他各方面的审查和建议。
[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月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[RFC3776]Arkko，J.，Devarapalli，V.，和F.Dupont，“使用IPsec保护移动节点和家庭代理之间的移动IPv6信令”，RFC 37762004年6月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, November 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年11月。
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, November 2005.
[RFC4285]Patel，A.，Leung，K.，Khalil，M.，Akhtar，H.，和K.Chowdhury，“移动IPv6认证协议”，RFC 42852005年11月。
Authors' Addresses
作者地址
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
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
Mohamed Khalil Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US
Mohamed Khalil Nortel Networks 2221 Lakeside Blvd。德克萨斯州理查森75082美国
Phone: +1 972-685-0574
EMail: mkhalil@nortel.com
Phone: +1 972-685-0574
EMail: mkhalil@nortel.com
Haseeb Akhtar Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US
Haseeb Akhtar Nortel Networks 2221湖滨大道。德克萨斯州理查森75082美国
Phone: +1 972-684-4732
EMail: haseebak@nortel.com
Phone: +1 972-684-4732
EMail: haseebak@nortel.com
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 US
Kuntal Chowdhury Starent Networks美国马萨诸塞州托克斯伯里国际广场30号01876
Phone: +1 214 550 1416
EMail: kchowdhury@starentnetworks.com
Phone: +1 214 550 1416
EMail: kchowdhury@starentnetworks.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从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编辑功能的资金目前由互联网协会提供。