Movatterモバイル変換

Network  Working Group                                         P. CalhounRequest for Comments: 2794                  Sun Microsystems LaboratoriesUpdates:2290                                                  C. PerkinsCategory: Standards Track                           Nokia Research Center                                                               March 2000Mobile IP Network Access Identifier Extension for IPv4Status 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.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 updatesRFC2290 which specifies the Mobile-IPv4 Configuration option for IPCP,   by allowing the Mobile Node's Home Address field of this option to be   zero.Calhoun & Perkins           Standards Track                     [Page 1]

RFC 2794                    Mobile Node NAI                   March 20001. Introduction   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.   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 inRFC 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 ofRFC 2290.  Interpretation of various scenarios fromRFC2290 is given insection 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 [3].2. Mobile Node NAI Extension   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.Calhoun & Perkins           Standards Track                     [Page 2]

RFC 2794                    Mobile Node NAI                   March 2000       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) [7]      Length     The length in bytes of the MN-NAI field      MN-NAI     A string in the NAI format defined in [1].3. Foreign Agent Considerations   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 (seesection 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 (seesection 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 (seesection 5).4. Interactions with Mobile-IPv4 Configuration Option to IPCP   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.   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 IPCalhoun & Perkins           Standards Track                     [Page 3]

RFC 2794                    Mobile Node NAI                   March 2000   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.5. Error Values   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.      Error Name               Value   Section of Document      ----------------------   -----   -------------------      NONZERO_HOMEADDR_REQD    96      3      MISSING_NAI              97      3      MISSING_HOME_AGENT       98      3      MISSING_HOMEADDR         99      36. IANA Considerations   The Mobile Node NAI extension defined inSection 2 is a Mobile IP   registration extension as defined inRFC 2002 [7] and extended inRFC2356 [6].  IANA should assign a value of 131 for this purpose.   The Code values defined inSection 5 are error codes as defined inRFC 2002 and extended inRFC 2344 [5] andRFC 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 inSection 5.7. Security Considerations   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.8. IPv6 Considerations   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.Calhoun & Perkins           Standards Track                     [Page 4]

RFC 2794                    Mobile Node NAI                   March 2000   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 (seeappendix 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   [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. Acknowledgements   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 inRFC 2290.References   [1] Aboba, B. and M. Beadles, "The Network Access Identifier",RFC2486, January 1999.   [2] Bound, J. and C. Perkins, "Dynamic Host Configuration Protocol       for IPv6 (DHCPv6)", Work in Progress.   [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement       Levels",BCP 14,RFC 2119, March 1997.   [4] Johnson, D. and C. Perkins"Mobility Support in IPv6", Work in       Progress.Calhoun & Perkins           Standards Track                     [Page 5]

RFC 2794                    Mobile Node NAI                   March 2000   [5] Montenegro, G., "Reverse Tunneling for Mobile IP",RFC 2344, May       1998.   [6] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for       Mobile IP",RFC 2356, June 1998.   [7] Perkins, C., "IP Mobility Support",RFC 2002, October 1996.   [8] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for       PPP IPCP",RFC 2290, February 1998.   [9] Thomson, S. and T. Narten, "IPv6 Stateless Address       Autoconfiguration",RFC 2462, December 1998.Calhoun & Perkins           Standards Track                     [Page 6]

RFC 2794                    Mobile Node NAI                   March 2000A. Home Domain Allocation Function (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.   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.                                                     +------+                                                     |      |                                                 +---+ HA-1 |        +------+       +------+       +------+   |   |      |        |      |       |      |       |      |   |   +------+        |  MN  |-------|  FA  |-------| HDAF +---+     ...        |      |       |      |       |      |   |   +------+        +------+       +------+       +------+   |   |      |                                                 +---+ HA-n |                                                     |      |                                                     +------+            Figure 2: Home Domain Allocator Function (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.Calhoun & Perkins           Standards Track                     [Page 7]

RFC 2794                    Mobile Node NAI                   March 2000Addresses   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   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   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   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   Phone:  +1 650-786-7733   Fax:    +1 650-786-6445   EMail:  pcalhoun@eng.sun.comCalhoun & Perkins           Standards Track                     [Page 8]

RFC 2794                    Mobile Node NAI                   March 2000Full 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.Calhoun & Perkins           Standards Track                     [Page 9]