GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2794

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.

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.

Calhoun & Perkins Standards Track [Page 1] RFC 2794 Mobile Node NAI March 2000

1. 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 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.
 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 (see 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).

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 IP

Calhoun & 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      3

6. IANA Considerations

 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.
 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.

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 (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
 [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 in RFC 2290.

References

 [1] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
     2486, 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 2000

A. 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 2000

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
 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.com

Calhoun & Perkins Standards Track [Page 8] RFC 2794 Mobile Node NAI March 2000

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.

Calhoun & Perkins Standards Track [Page 9]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2794.txt · Last modified: 2000/04/06 22:36 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki