[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 RFC 2794

Mobile IP Working Group                                   Pat R. Calhoun
INTERNET DRAFT                             Sun Microsystems Laboratories
5 January 2000                                        Charles E. Perkins
                                                   Nokia Research Center

         Mobile IP Network Access Identifier Extension for IPv4
                   draft-ietf-mobileip-mn-nai-06.txt


Status of This Memo

   This document is a submission by the mobile-ip Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at:
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at:
        http://www.ietf.org/shadow.html.


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 draft also updates
   RFC2290 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              Expires 5 July 2000               [Page i]

Internet Draft              Mobile Node NAI               5 January 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 [9] 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 draft 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].


















Calhoun, Perkins              Expires 5 July 2000               [Page 1]

Internet Draft              Mobile Node NAI               5 January 2000


2. Mobile Node NAI Extension

   The Mobile Node NAI extension, shown in figure 1, contains the user
   and/or host 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.


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






Calhoun, Perkins              Expires 5 July 2000               [Page 2]

Internet Draft              Mobile Node NAI               5 January 2000


4. Interactions with Mobile-IPv4 Configuration Option to IPCP

   In the Mobile-IPv4 Configuration Option to IPCP [9], 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.


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 number for the Mobile Node NAI extension is taken from the
   numbering space defined for Mobile IP registration extensions defined
   in RFC 2002 [7] as extended in RFC 2356 [6].  The numbering for
   the extension also SHOULD NOT conflict with values specified in
   the Internet Draft for Route Optimization [8].  The Code values
   specified for errors, listed in section 5, MUST NOT conflict with any
   other code values listed in RFC 2002, RFC 2344 [5], or RFC 2356 [6].
   They are to be taken from the space of error values conventionally
   associated with rejection by the foreign agent (i.e., 64-127).








Calhoun, Perkins              Expires 5 July 2000               [Page 3]

Internet Draft              Mobile Node NAI               5 January 2000


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 [10] and DHCPv6 [2] 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 [10], 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.




Calhoun, Perkins              Expires 5 July 2000               [Page 4]

Internet Draft              Mobile Node NAI               5 January 2000


References

    [1] B. Aboba and M. Beadles.  The Network Access Identifier.
        Request for Comments (Proposed Standard) 2486, Internet
        Engineering Task Force, January 1999.

    [2] J. Bound and C. Perkins.  Dynamic Host Configuration Protocol
        for IPv6 (DHCPv6).  Internet Draft, Internet Engineering Task
        Force.
        draft-ietf-dhc-dhcpv6-14.txt, February 1999.  Work in progress.

    [3] S. Bradner.  Key words for use in RFCs to Indicate Requirement
        Levels.  Request for Comments (Best Current Practice) 2119,
        Internet Engineering Task Force, March 1997.

    [4] D. Johnson and C. Perkins.  Mobility Support in IPv6.
        draft-ietf-mobileip-ipv6-08.txt, June 1999.  (work in progress).

    [5] G. Montenegro.  Reverse Tunneling for Mobile IP.  Request for
        Comments (Proposed Standard) 2344, Internet Engineering Task
        Force, May 1998.

    [6] G. Montenegro and V. Gupta.  Sun's SKIP Firewall Traversal for
        Mobile IP.  Request for Comments (Informational) 2356, Internet
        Engineering Task Force, June 1998.

    [7] C. Perkins.  IP Mobility Support.  Request for Comments
        (Proposed Standard) 2002, Internet Engineering Task Force,
        October 1996.

    [8] C. Perkins and D. Johnson.  Route Optimization in Mobile IP.
        Internet Draft, Internet Engineering Task Force.
        draft-ietf-mobileip-optim-08.txt, February 1999.  Work in
        progress.

    [9] J. Solomon and S. Glass.  Mobile-IPv4 Configuration Option
        for PPP IPCP.  Request for Comments (Proposed Standard) 2290,
        Internet Engineering Task Force, February 1998.

   [10] S. Thomson and T. Narten.  IPv6 Stateless Address
        Autoconfiguration.  Request for Comments (Draft Standard) 2462,
        Internet Engineering Task Force, December 1998.










Calhoun, Perkins              Expires 5 July 2000               [Page 5]

Internet Draft              Mobile Node NAI               5 January 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              Expires 5 July 2000               [Page 6]

Internet Draft              Mobile Node NAI               5 January 2000


Addresses

   The working group can be contacted via the current chairs:

      Basavaraj Patil                      Phil Roberts
      Nortel Networks Inc.                 Motorola
      2201 Lakeside Blvd.                  1501 West Shure Drive
      Richardson, TX. 75082-4399           Arlington Heights, IL 60004
      USA                                  USA

      Phone:  +1 972-684-1489              Phone:  +1 847-632-3148
      EMail:  bpatil@nortelnetworks.com    EMail:  QA3445@email.mot.com


   Questions about this memo can be directed to:

      Charles E. Perkins                   Pat R. Calhoun
      Nokia Research Center                Sun Microsystems Laboratories
      313 Fairchild Drive                  15 Network Circle
      Mountain View, California 94043      Menlo Park, California 94025
      USA                                  USA

      Phone:  +1-650 625-2986              Phone:  +1 650-786-7733
      EMail:  charliep@iprg.nokia.com      EMail:  pcalhoun@eng.sun.com
      Fax:  +1 650 625-2502                Fax:  +1 650-786-6445



























Calhoun, Perkins              Expires 5 July 2000               [Page 7]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/