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 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractAAA 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.
1]. This document specifies the Mobile Node NAI extension to the Mobile IP Registration Request  message from the mobile node. 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. The "Mobile-IPv4 Configuration" option to IPCP has been specified in RFC 2290  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. 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 . 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.
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 Type 131 (skippable)  Length The length in bytes of the MN-NAI field MN-NAI A string in the NAI format defined in . section 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). 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. 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
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. 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. 7] to be returned in a Registration Reply, and the section in which the error Code is first mentioned in this specification. Error Name Value Section of Document ---------------------- ----- ------------------- NONZERO_HOMEADDR_REQD 96 3 MISSING_NAI 97 3 MISSING_HOME_AGENT 98 3 MISSING_HOMEADDR 99 3 Section 2 is a Mobile IP registration extension as defined in RFC 2002  and extended in RFC 2356 . IANA should assign a value of 131 for this purpose. The Code values defined in Section 5 are error codes as defined in RFC 2002 and extended in RFC 2344  and RFC 2356 . 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. 4] is outside the scope of this document. This section contains some ideas how Stateless Address Autoconfiguration  and DHCPv6  might be extended to support NAI-based Mobile IPv6 registrations.
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. This agent can either be a router sending out Router Advertisements , 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 . RFC 2290.  Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.  Bound, J. and C. Perkins, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in Progress.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Johnson, D. and C. Perkins "Mobility Support in IPv6", Work in Progress.
 Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May 1998.  Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.  Perkins, C., "IP Mobility Support", RFC 2002, October 1996.  Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for PPP IPCP", RFC 2290, February 1998.  Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. 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.