[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, Inc.
25 May 1999                                           Charles E. Perkins
                                                  Sun Microsystems, Inc.

             Mobile IP Network Address Identifier Extension
                   draft-ietf-mobileip-mn-nai-01.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, such as RADIUS and DIAMETER, 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 include the
   NAI along with the Mobile IP Registration Request.

Calhoun, Perkins            Expires 25 November 1999            [Page i]


Internet Draft                Mobile Node NAI                25 May 1999

1. Introduction

   AAA servers, such as RADIUS [10] and DIAMETER [3], 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 [9] 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.  This draft introduces a
   new function named the Home Domain Allocation Function (HDAF) that
   can dynamically assign a Home Address to the mobile node.  A message
   containing the Mobile Node NAI extension MAY have the Home Address
   field in the Registration Request set to zero (0) to request that one
   be assigned.

   Figure 1 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 1: 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

Calhoun, Perkins            Expires 25 November 1999            [Page 1]


Internet Draft                Mobile Node NAI                25 May 1999

   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.

2. Mobile Node NAI Extension

   The Mobile Node NAI extension, shown in figure 2, 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 2: The Mobile Node NAI Extension

      Type       130 (skippable) [9]

      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
   UNIQUE_HOMEADDR_REQD (see section 4).

   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 4).  The
   Registration Reply MUST include a nonzero Home Agent address and
   mobile node's Home Address.  If not, the foreign agent SHOULD send

Calhoun, Perkins            Expires 25 November 1999            [Page 2]


Internet Draft                Mobile Node NAI                25 May 1999

   the Registration Reply to the mobile node, changing the Code to the
   value MISSING_HOME_AGENT or MISSING_HOMEADDR, respectively (see
   section 4).

4. Error Values

   Each entry in the following table contains the name of Code [9] to
   be returned in a Registration Reply, the value for the Code, and the
   section in which the error is first mentioned in this specification.

      Error Name               Value   Section
      ----------------------   -----   -------------------
      UNIQUE_HOMEADDR_REQD     96      3
      MISSING_NAI              97      3
      MISSING_HOME_AGENT       98      3
      MISSING_HOMEADDR         99      3

5. 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 [9] 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 4, 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).

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

7. IPv6 considerations

   For mobile nodes using IPv6, there are no commonly deployed
   mechanisms by which a mobile node may present its credentials,
   such as there are with IPv4.  Nevertheless, a mobile node using
   IPv6 mobility [4] 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

Calhoun, Perkins            Expires 25 November 1999            [Page 3]


Internet Draft                Mobile Node NAI                25 May 1999

   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 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 [7], or a DHCPv6 [2] server.  In the former
   case, the router could signal its ability to handle the NAI by
   attaching a new extension to the Router Advertisement.  In the
   latter case, for managed links, the mobile node would include an NAI
   extension in its DHCP Solicitation message.  The 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.

8. Acknowledgements

   The authors would like to thank Gabriel Montenegro and Vipul Gupta
   for their useful discussions.

References

    [1] B. Aboba and M. Beadles.  RFC 2486:  The Network Access
        Identifier, January 1999.  Status:  PROPOSED STANDARD.

    [2] J. Bound and C. Perkins.  Dynamic Host Configuration Protocol
        for IPv6.  draft-ietf-dhc-dhcpv6-14.txt, February 1999.  (work
        in progress).

    [3] P. Calhoun and A. Rubens.  DIAMETER Base Protocol.
        draft-calhoun-diameter-07.txt, November 1998.  (work in
        progress).

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

    [5] G. Montenegro.  Reverse Tunneling for Mobile IP.  RFC 2344, May
        1998.

    [6] G. Montenegro and V. Gupta.  Sun's SKIP Firewall Traversal for
        Mobile IP.  RFC 2356, June 1998.

Calhoun, Perkins            Expires 25 November 1999            [Page 4]


Internet Draft                Mobile Node NAI                25 May 1999

    [7] T. Narten, E. Nordmark, and W. Simpson.  RFC 2461:  Neighbor
        discovery for IP Version 6 (IPv6), December 1998.  Status:
        DRAFT STANDARD.

    [8] Charles E. Perkins and David B. Johnson.  Route Optimization in
        Mobile-IP.  draft-ietf-mobileip-optim-07.txt, November 1997.
        (work in progress).

    [9] C. Perkins, Editor.  IP Mobility Support.  RFC 2002, October
        1996.

   [10] C. Rigney, A. Rubens, W. Simpson, and S. Willens.  Remote
        Authentication Dial In User Service (RADIUS).  RFC 2138, April
        1997.

Addresses

   The working group can be contacted via the current chairs:

      Erik Nordmark                        Basavaraj Patil
      Sun Microsystems, Inc.               Nortel Networks Inc.
      17 Network Circle                    2201 Lakeside Blvd.
      Menlo Park, California 94025         Richardson, TX. 75082-4399
      USA                                  USA

      Phone:  +1 650 786-5166              +1 972-684-1489
      Fax:  +1 650 786-5896
      E-mail:  nordmark@sun.com            bpatil@nortelnetworks.com

   Questions about this memo can be directed to:

      Charles E. Perkins                   Pat R. Calhoun
      Sun Microsystems Laboratories        Sun Microsystems Laboratories
      15 Network Circle                    15 Network Circle
      Menlo Park, California 94025         Menlo Park, California 94025
      USA                                  USA

      Phone:  +1-650 786-6464              Phone:  +1 650-786-7733
      EMail:  cperkins@eng.sun.com         EMail:  pcalhoun@eng.sun.com
      Fax:  +1 650 786-6445

Calhoun, Perkins            Expires 25 November 1999            [Page 5]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/