Network Working Group P. Calhoun
Request for Comments: 2794 Sun Microsystems Laboratories
Updates: 2290 C. Perkins
Category: Standards Track Nokia Research Center
March 2000
Network Working Group P. Calhoun
Request for Comments: 2794 Sun Microsystems Laboratories
Updates: 2290 C. Perkins
Category: Standards Track Nokia Research Center
March 2000
Mobile IP Network Access Identifier Extension for IPv4
IPv4的移动IP网络访问标识符扩展
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI). Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also updates RFC 2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero.
AAA服务器目前在互联网中用于为拨号计算机提供身份验证和授权服务。当使用移动IP的移动节点试图连接到具有AAA服务器的外域时，此类服务可能对这些节点同样有价值。如今，AAA服务器通过使用网络访问标识符（NAI）来识别客户端。我们的方案定义了一种移动节点识别自身的方法，包括NAI和移动IP注册请求。此备忘录还更新了RFC 2290，其中指定了IPCP的Mobile-IPv4配置选项，允许此选项的移动节点的Home Address字段为零。
AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI) [1]. This document specifies the Mobile Node NAI extension to the Mobile IP Registration Request [7] message from the mobile node.
AAA服务器目前在互联网中用于为拨号计算机提供身份验证和授权服务。当使用移动IP的移动节点试图连接到具有AAA服务器的外域时，此类服务可能对这些节点同样有价值。如今，AAA服务器通过使用网络访问标识符（NAI）[1]来识别客户端。本文档指定了来自移动节点的移动IP注册请求[7]消息的移动节点NAI扩展。
Since the NAI is typically used to uniquely identify the mobile node, the mobile node's home address is not always necessary to provide that function. Thus, it is possible for a mobile node to authenticate itself, and be authorized for connection to the foreign domain, without even having a home address. A message containing the Mobile Node NAI extension MAY set the Home Address field to zero (0) in the Registration Request, to request that a home address be assigned.
由于NAI通常用于唯一地标识移动节点，因此移动节点的家庭地址并不总是提供该功能所必需的。因此，移动节点可以在甚至没有家庭地址的情况下对自身进行认证，并被授权连接到外域。包含移动节点NAI扩展的消息可以在注册请求中将归属地址字段设置为零（0），以请求分配归属地址。
The "Mobile-IPv4 Configuration" option to IPCP has been specified in RFC 2290 [8] for proper interaction between a mobile node and a peer, through which the mobile node connects to the network using PPP. According to that specification the Mobile Node's Home Address field of the option MUST not be zero. However, in the context of this memo which allows a mobile node to be identified by its NAI and to obtain an address after the PPP phase of connection establishment, the Home Address field is allowed to be zero while maintaining all other aspects of RFC 2290. Interpretation of various scenarios from RFC 2290 is given in section 4.
RFC 2290[8]中规定了IPCP的“Mobile-IPv4配置”选项，用于移动节点和对等方之间的正确交互，移动节点通过该对等方使用PPP连接到网络。根据该规范，选项的移动节点的Home Address字段不得为零。然而，在允许移动节点通过其NAI识别并在连接建立的PPP阶段之后获得地址的本备忘录的上下文中，家庭地址字段允许为零，同时保持RFC 2290的所有其他方面。第4节给出了RFC 2290中各种场景的解释。
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 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[3]中所述进行解释。
The Mobile Node NAI extension, shown in figure 1, contains the user name following the format defined in [1]. When it is present in the Registration Request, the Home Address field MAY be set to zero (0). The Mobile Node NAI extension MUST appear in the Registration Request before both the Mobile-Home Authentication extension and Mobile-Foreign Authentication extension, if present.
图1所示的移动节点NAI扩展包含符合[1]中定义格式的用户名。当家庭地址字段出现在注册请求中时，家庭地址字段可以设置为零（0）。移动节点NAI扩展必须出现在注册请求中，然后才能出现移动本地身份验证扩展和移动外部身份验证扩展（如果存在）。
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 | MN-NAI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | MN-NAI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Mobile Node NAI Extension
图1：移动节点NAI扩展
Type 131 (skippable) [7]
131型（可跳过）[7]
Length The length in bytes of the MN-NAI field
Length MN-NAI字段的长度（以字节为单位）
MN-NAI A string in the NAI format defined in [1].
MN-NAI采用[1]中定义的NAI格式的字符串。
If Home Address is zero in the Registration Request, the foreign agent MUST use the NAI instead in its pending registration request records, along with the Identification field as usual. If the foreign agent cannot manage pending registration request records in this way, it MUST return a Registration Reply with Code indicating NONZERO_HOMEADDR_REQD (see section 5).
如果注册请求中的家庭地址为零，则外国代理必须在其待决注册请求记录中使用NAI，并像往常一样使用标识字段。如果外部代理无法以这种方式管理挂起的注册请求记录，则它必须返回一个注册回复，其代码指示非零\u HOMEADDR\u REQD（参见第5节）。
If the mobile node includes the Mobile Node NAI extension in its Registration Request, then the Registration Reply from the home agent MUST include the Mobile Node NAI extension. If not, the foreign agent SHOULD send the Registration Reply to the mobile node, changing the Code to the value MISSING_NAI (see section 5). The Registration Reply MUST include a nonzero Home Agent address and mobile node's Home Address. If not, the foreign agent SHOULD send the Registration Reply to the mobile node, changing the Code to the value MISSING_HOME_AGENT or MISSING_HOMEADDR, respectively (see section 5).
如果移动节点在其注册请求中包括移动节点NAI扩展，则来自归属代理的注册回复必须包括移动节点NAI扩展。如果没有，外部代理应向移动节点发送注册回复，将代码更改为值MISSING_NAI（参见第5节）。注册回复必须包括非零的归属代理地址和移动节点的归属地址。如果没有，外部代理应向移动节点发送注册回复，将代码分别更改为值MISSING_HOME_agent或MISSING_HOMEADDR（参见第5节）。
In the Mobile-IPv4 Configuration Option to IPCP [8], the Mobile Node's Home Address field may be zero. In this section, we specify the action to be taken in that case, when the mobile node is using the Mobile Node NAI extension in the Mobile IP Registration Request. Whether or not the IP Address Configuration Option contains a nonzero IP address, the mobile node will subsequently attempt to obtain a home address from the Mobile IP Registration Reply.
在IPCP[8]的Mobile-IPv4配置选项中，移动节点的家庭地址字段可能为零。在本节中，我们指定在这种情况下，当移动节点在移动IP注册请求中使用移动节点NAI扩展时要采取的操作。无论IP地址配置选项是否包含非零IP地址，移动节点随后都将尝试从移动IP注册回复中获取家庭地址。
If the IP Address Configuration Option to IPCP has IP address equal to zero, the PPP peer is expected to allocate and assign a co-located care-of address to the Mobile Node. If, on the other hand, the IP
如果IPCP的IP地址配置选项的IP地址等于零，则PPP对等方将分配一个同一位置的转交地址给移动节点。另一方面，如果IP
Address Configuration Option to IPCP has a nonzero IP address, the PPP peer is expected to assign that address to the Mobile Node as its co-located care-of address.
IPCP的地址配置选项具有非零IP地址，PPP对等方应将该地址分配给移动节点作为其共同定位的转交地址。
Finally, if the IP Address Configuration Option is left out of the IPCP Configure-Request, then no co-located care of address is assigned during IPCP. The mobile node will acquire a co-located care of address during a later stage of configuration or will use an FA-located care-of address.
最后，如果IPCP配置请求中没有IP地址配置选项，则在IPCP期间不会分配同一位置的转交地址。移动节点将在稍后的配置阶段期间获取共同定位的转交地址，或者将使用FA定位的转交地址。
Each entry in the following table contains the name and value for the Code [7] to be returned in a Registration Reply, and the section in which the error Code is first mentioned in this specification.
下表中的每个条目都包含注册回复中要返回的代码[7]的名称和值，以及本规范中首先提到错误代码的部分。
Error Name Value Section of Document
---------------------- ----- -------------------
NONZERO_HOMEADDR_REQD 96 3
MISSING_NAI 97 3
MISSING_HOME_AGENT 98 3
MISSING_HOMEADDR 99 3
Error Name Value Section of Document
---------------------- ----- -------------------
NONZERO_HOMEADDR_REQD 96 3
MISSING_NAI 97 3
MISSING_HOME_AGENT 98 3
MISSING_HOMEADDR 99 3
The Mobile Node NAI extension defined in Section 2 is a Mobile IP registration extension as defined in RFC 2002 [7] and extended in RFC 2356 [6]. IANA should assign a value of 131 for this purpose.
第2节中定义的移动节点NAI扩展是RFC 2002[7]中定义并在RFC 2356[6]中扩展的移动IP注册扩展。为此，IANA应指定值131。
The Code values defined in Section 5 are error codes as defined in RFC 2002 and extended in RFC 2344 [5] and RFC 2356 [6]. They correspond to error values conventionally associated with rejection by the foreign agent (i.e., values from the range 64-127). IANA should record the values as defined in Section 5.
第5节中定义的代码值是RFC 2002中定义的错误代码，并在RFC 2344[5]和RFC 2356[6]中扩展。它们对应于通常与外国代理拒绝相关的错误值（即，范围64-127的值）。IANA应记录第5节中定义的值。
Mobile IP registration messages are authenticated, and the authentication verified by the recipient. This proposal does not prohibit the mobile node from sending its NAI in the clear over the network, but that is not expected to be a security issue.
移动IP注册消息经过身份验证，并且由收件人验证身份验证。该提议并不禁止移动节点通过网络在clear中发送其NAI，但预计这不会是一个安全问题。
Supporting NAI-based registrations for Mobile IPv6 [4] is outside the scope of this document. This section contains some ideas how Stateless Address Autoconfiguration [9] and DHCPv6 [2] might be extended to support NAI-based Mobile IPv6 registrations.
支持基于NAI的移动IPv6注册[4]超出了本文档的范围。本节介绍如何扩展无状态地址自动配置[9]和DHCPv6[2]以支持基于NAI的移动IPv6注册。
For mobile nodes using IPv6, there are no commonly deployed mechanisms by which a mobile node may present its credentials, such as exist today with IPv4. Nevertheless, a mobile node using IPv6 mobility may wish to specify the domain in which their credentials may be checked, by using a NAI just as this specification proposes for IPv4. In the case of IPv6, however, there is no foreign agent in place to manage the connectivity of the mobile node, and thus to manage the verification of the credentials offered by the mobile node. To identify the HDAF (see appendix A) that has the expected relationship with the mobile node, the NAI would have to be forwarded to a local AAA by the local agent involved with configuring the care-of address of the mobile node.
对于使用IPv6的移动节点，没有常见的部署机制，移动节点可以通过这些机制来呈现其凭据，例如目前使用IPv4的机制。然而，使用IPv6移动的移动节点可能希望通过使用NAI来指定可在其中检查其凭证的域，就像本规范针对IPv4所建议的那样。然而，在IPv6的情况下，没有外部代理来管理移动节点的连接，从而管理移动节点提供的凭据的验证。为了识别与移动节点具有预期关系的HDAF（参见附录A），必须由参与配置移动节点的转交地址的本地代理将NAI转发到本地AAA。
This agent can either be a router sending out Router Advertisements [9], or a DHCPv6 server. In the former case, the router could signal its ability to handle the NAI by attaching some yet to be defined option to the Router Advertisement. In the latter case, for managed links, the mobile node could include a yet to be defined NAI extension in its DHCP Solicitation message. Such an NAI extension and appropriate authentication would also be required on the subsequent DHCP Request sent by the mobile node to the DHCP Server selected on the basis of received DHCP Advertisements. Once a care-of address on the foreign network has been obtained, the mobile node can use regular MIPv6 [4].
此代理可以是发送路由器广告的路由器[9]，也可以是DHCPv6服务器。在前一种情况下，路由器可以通过将一些尚未定义的选项附加到路由器广告来表示其处理NAI的能力。在后一种情况下，对于受管链路，移动节点可以在其DHCP请求消息中包括尚未定义的NAI扩展。对于由移动节点发送到基于接收到的DHCP广告选择的DHCP服务器的后续DHCP请求，还需要这样的NAI扩展和适当的认证。一旦获得外部网络上的转交地址，移动节点就可以使用常规MIPv6[4]。
The authors would like to thank Gabriel Montenegro and Vipul Gupta for their useful discussions. Thanks to Basaravaj Patil and Pete McCann for text describing actions to be taken when the home address is zero but the mobile node wishes to use the Mobile-IPv4 Configuration Option to IPCP defined in RFC 2290.
作者要感谢Gabriel Montegon和Vipul Gupta的有益讨论。感谢Basaravaj Patil和Pete McCann提供的文本，描述了当家庭地址为零但移动节点希望使用RFC 2290中定义的IPCP的mobile-IPv4配置选项时要采取的操作。
References
工具书类
[1] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[1] Aboba，B.和M.Beadles，“网络接入标识符”，RFC 2486，1999年1月。
[2] Bound, J. and C. Perkins, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in Progress.
[2] Bound，J.和C.Perkins，“IPv6的动态主机配置协议（DHCPv6）”，正在进行中。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Johnson, D. and C. Perkins "Mobility Support in IPv6", Work in Progress.
[4] Johnson，D.和C.Perkins“IPv6中的移动支持”，正在进行中。
[5] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May 1998.
[5] 黑山G.“移动IP的反向隧道”，RFC 2344，1998年5月。
[6] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.
[6] 黑山，G.和V.Gupta，“Sun的移动IP跳过防火墙穿越”，RFC 2356，1998年6月。
[7] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[7] Perkins，C.，“IP移动支持”，RFC 2002，1996年10月。
[8] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for PPP IPCP", RFC 2290, February 1998.
[8] Solomon，J.和S.Glass，“PPP IPCP的移动IPv4配置选项”，RFC 2290，1998年2月。
[9] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[9] Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年12月。
A. Home Domain Allocation Function (HDAF)
A.归属域分配功能（HDAF）
This appendix introduces a new function named the Home Domain Allocation Function (HDAF) that can dynamically assign a Home Address to the mobile node.
本附录介绍了一个名为归属域分配功能（HDAF）的新功能，该功能可以动态地将归属地址分配给移动节点。
Figure 2 illustrates the Home HDAF, which receives messages from foreign agents (e.g., FA) and assigns a Home Address within the Home Domain. The HDAF does not perform any Mobile IP processing on the Registration Request, but simply forwards the request to a Home Agent (HA) within the network that is able to handle the request.
图2说明了家庭HDAF，它接收来自外部代理（如FA）的消息，并在家庭域内分配家庭地址。HDAF不对注册请求执行任何移动IP处理，而是简单地将该请求转发给网络内能够处理该请求的归属代理（HA）。
+------+
| |
+---+ HA-1 |
+------+ +------+ +------+ | | |
| | | | | | | +------+
| MN |-------| FA |-------| HDAF +---+ ...
| | | | | | | +------+
+------+ +------+ +------+ | | |
+---+ HA-n |
| |
+------+
+------+
| |
+---+ HA-1 |
+------+ +------+ +------+ | | |
| | | | | | | +------+
| MN |-------| FA |-------| HDAF +---+ ...
| | | | | | | +------+
+------+ +------+ +------+ | | |
+---+ HA-n |
| |
+------+
Figure 2: Home Domain Allocator Function (HDAF)
图2：主域分配器功能（HDAF）
Upon receipt of the Registration Request from the mobile node (MN), FA extracts the NAI and finds the domain name associated with it. FA then finds the HDAF that handles requests for the mobile node's domain. The discovery protocol is outside of the scope of this specification. As an example, however, FA might delegate the duty of finding a HDAF to a local AAA server. The local AAA server may also assist FA in the process of verifying the credentials of the mobile node, using protocols not specified in this document.
在收到来自移动节点（MN）的注册请求后，FA提取NAI并查找与其关联的域名。FA然后找到处理移动节点域请求的HDAF。发现协议不在本规范的范围内。然而，作为一个例子，FA可能会将查找HDAF的职责委托给本地AAA服务器。本地AAA服务器还可以使用本文档中未指定的协议协助FA验证移动节点的凭证。
Addresses
地址
The working group can be contacted via the current chairs:
可通过现任主席联系工作组：
Basavaraj Patil Nokia Corporation 6000 Connection Drive M/S M8-540 Irving, TX 75039 USA
美国德克萨斯州欧文市Basavaraj Patil诺基亚公司6000连接驱动器M/S M8-540，邮编75039
Phone: +1 972-894-6709
Fax : +1 972-894-5349
EMail: Basavaraj.Patil@nokia.com
Phone: +1 972-894-6709
Fax : +1 972-894-5349
EMail: Basavaraj.Patil@nokia.com
Phil Roberts Motorola 1501 West Shure Drive Arlington Heights, IL 60004 USA
美国伊利诺伊州阿灵顿高地舒尔西路1501号菲尔·罗伯茨摩托罗拉60004
Phone: +1 847-632-3148
EMail: QA3445@email.mot.com
Phone: +1 847-632-3148
EMail: QA3445@email.mot.com
Questions about this memo can be directed to:
有关本备忘录的问题，请联系：
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
查尔斯·E·珀金斯诺基亚研究中心美国加利福尼亚州山景镇飞兆半导体大道313号，邮编94043
Phone: +1-650 625-2986
Fax: +1 650 625-2502
EMail: charliep@iprg.nokia.com
Phone: +1-650 625-2986
Fax: +1 650 625-2502
EMail: charliep@iprg.nokia.com
Pat R. Calhoun Sun Microsystems Laboratories 15 Network Circle Menlo Park, California 94025 USA
Pat R.Calhoun Sun Microsystems Laboratories 15 Network Circle Menlo Park，加利福尼亚州94025
Phone: +1 650-786-7733
Fax: +1 650-786-6445
EMail: pcalhoun@eng.sun.com
Phone: +1 650-786-7733
Fax: +1 650-786-6445
EMail: pcalhoun@eng.sun.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。