Local Mobile Anchor Discovery Using DHCP
draft-xia-netlmm-lma-discovery-02

Versions: 00 01 02                                                      
Network Working Group                                             F. Xia
Internet-Draft                                               B. Sarikaya
Expires: October 31, 2009                                     Huawei USA
                                                          April 29, 2009


                Local Mobile Anchor Discovery Using DHCP
                   draft-xia-netlmm-lma-discovery-02

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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.

   This Internet-Draft will expire on October 31, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.









Xia & Sarikaya          Expires October 31, 2009                [Page 1]


Internet-Draft                LMA Discovery                   April 2009


Abstract

   This draft defines a DHCP-based scheme to enable dynamic discovery of
   a Local Mobility Anchor (LMA) in Proxy Mobile IPv6.  Existing Dynamic
   Host Configuration Protocol (DHCP) options are used allowing a Mobile
   Access Gateway (MAG) to request the LMA's IP address, Fully Qualified
   Domain Name (FQDN), or home network prefix via the DHCP response.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Message Sequence  . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  DHCPv6 Relay Agent  . . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  Relay agent configuration . . . . . . . . . . . . . . . . . 5
     4.2.  Transmission of DHCPv6 messages . . . . . . . . . . . . . . 6
     4.3.  Receipt of DHCPv6 messages  . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  Informative references  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9


























Xia & Sarikaya          Expires October 31, 2009                [Page 2]


Internet-Draft                LMA Discovery                   April 2009


1.  Introduction

   [I-D.giaretta-netlmm-mip-interactions] describes possible scenarios
   which require an interaction between PMIPv6 and MIPv6.  In a similar
   scenario depicted in Figure 1 , some mobile nodes use Mobile IPv6 to
   manage their movements while others rely on a network-based mobility
   solution provided by the network.  There is a common mobility anchor
   that acts as Mobile IPv6 Home Agent and Proxy Mobile IPv6 LMA,
   depending on the type of the node.


                   +---------+    +--------+
                   |LMA1/HA1 |    |LMA2/HA2|
                   +---------+    +--------+
                      //\\             \\
                +----//--\\-------------\\------+
               (    //    \\             \\      )
               (   //      \\             \\     )
                +-//--------\\-------------\\---+
                 //          \\             \\
                //            \\             \\
               //              \\             \\
            +----+           +----+        +--------+
            |MAG1|           |AR2 |        |MAG3/AR3|
            +----+           +----+        +--------+
              |                 |               |
            [MN1]             [MN2]           [MN3]


             Figure 1: Hybrid deployment with MIPv6 and PMIPv6

   Before a MAG or a MN can engage in mobility management signaling with
   the mobility anchor (LMA or HA), it SHOULD either know the IP address
   of the mobility anchor via pre-configuration, or dynamically discover
   it.

   [I-D.ietf-mip6-hiopt] defines DHCPv6 options which are used for
   acquiring the mobile anchor(HA) information from a DHCPv6 server in
   MIPv6, while this document describes a procedure that the MAG
   retrieves the information from the same server using the DHCP options
   in Proxy MIPv6.

   We note that LMA discovery can be done by some other means such as
   AAA.  MAG could be provided with LMA address by AAA server during
   access authentication of the mobile node.  LMA can also be discovered
   by lower layer means such as from the identity of the mobile node.





Xia & Sarikaya          Expires October 31, 2009                [Page 3]


Internet-Draft                LMA Discovery                   April 2009


2.  Terminology

   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 [RFC2119].

   The terminology in this document is based on the definitions in
   [RFC5213].


3.  Message Sequence

   Figure 2 shows the message sequence for dynamic LMA discovery using
   DHCPv6.  The following details apply.



   +-----+       +------+     +------+   +------+
   |     |       |NAS/  |     |      |   |      |
   | MN/ |       |MAG/  |     | DHCP |   | AAA  |
   |User |       |DHCP  |     |Server|   |Server|
   |     |       |client|     |      |   |      |
   +-----+       +------+     +------+   +------+
     |              |             |          |
     |     1        |       1     |          |
     |<------------>|<---------------------->| Access Authentication
     |              |             |          |
     |              |       2     |          |
     |              |------------>|          | Information Request
     |              |             |          |
     |              |       3     |          |
     |              |<------------|          | Information Reply
     |              |             |          |


                     Figure 2: Dynamic LMA Using DHCP

   1.  The mobile node executes the network access authentication
       procedure (e.g., IEEE802.1X or IKEv2 SA establishment followed by
       EAP authentication) and it interacts with the NAS/MAG.  The NAS/
       MAG interacts with the AAA server to authenticate the mobile
       node.  In the process of authorizing the mobile node, the AAA
       server verifies in the AAA profile that the mobile node is
       allowed to use the Proxy Mobile IPv6 service.  The AAA server
       possibly assigns a LMA and returns this information to the NAS
       through Diameter [I-D.korhonen-dime-pmip6] or RADIUS
       [I-D.xia-netlmm-radius], thus, it is not necessary to continue
       with step 2 and 3.  Otherwise, the NAS/MAG continues the



Xia & Sarikaya          Expires October 31, 2009                [Page 4]


Internet-Draft                LMA Discovery                   April 2009


       following DHCP exchanges to inquire the home network information.
   2.  The NAS/MAG as a DHCP client sends a DHCPv6 Information Request
       message [RFC3315] to the All_DHCP_Relay_Agents_and_Servers
       multicast address.  In this message, the NAS/MAG SHALL include
       Home Network Identifier Option [I-D.ietf-mip6-hiopt] in the
       OPTION_ORO, and a Home Network Identifier Option with id-type set
       to 0.  When the Sub-opt-code of the sub-option is set to 1 in the
       request, the Home Network Parameter field MUST contain an
       identifier to specify the home network requested by the mobile
       node.  This field MUST be set in the form of a FQDN [RFC1035],
       encoded as specified in Section 8 of [RFC3315].  If the mobile
       node has a NAI, the FQDN can be constructed by concatenating a
       fixed string with the realm part of the NAI.  This sub-option in
       the request SHOULD be copied into the Home Network Information
       option returned in the reply.  The NAS/MAG SHALL also include the
       OPTION_CLIENTID to identify itself to the DHCP server.  The DHCP
       Unique Identifier(DUID) can be generated based on the mobile
       node's link layer address or other information.  How to create
       DUID is beyond the scope of this document.
   3.  The DHCP server identifies the client by looking at the DUID for
       the client in the OPTION_CLIENTID.  The DHCP server also
       determines that the MAG is requesting home network information by
       looking at the Home Network Identifier Option (id-type 0).  The
       DHCP server retrieves the allocated IP (v6 and v4) address of the
       HA, i.e.  LMA, FQDN of the HA, i.e.  LMA, and home network
       prefix, and includes them in the Home Network Information Option
       [I-D.ietf-mip6-hiopt] in the Information Reply Message that it
       sends to the DHCP client.


4.  DHCPv6 Relay Agent

   A DHPCv6 relay agent function [RFC3315] SHOULD be used when NAS/MAG
   and the DHCP server are not connected directly.  In this
   configuration, the relay agent function is co-located in the NAS/MAG
   with the DHCPv6 client function.  Rather than using multicast to send
   DHCPv6 messages to the DHCPv6 server, the DHCPv6 client in the NAS/
   MAG hands any outbound DHCPv6 messages to the co- located relay
   agent.  Responses from the DHCPv6 server are delivered to the relay
   agent function in the NAS/MAG, which extracts the encapsulated
   message and delivers it to the DHCPv6 client in the NAS/MAG.

4.1.  Relay agent configuration

   The use of the relay agent function in the NAS/MAG allows the NAS/MAG
   to unicast DHCPv6 messages to the DHCPv6 server.  The relay agent
   must be configured with the address of the DHCPv6 server or another
   DHCPv6 relay agent that will forward message on to a DHCPv6 server.



Xia & Sarikaya          Expires October 31, 2009                [Page 5]


Internet-Draft                LMA Discovery                   April 2009


4.2.  Transmission of DHCPv6 messages

   In this configuration, when the DHCPv6 client in the NAS/MAG sends a
   message, it hands the message to the DHCPv6 relay agent in the NAS/
   MAG.  The relay agent encapsulates the message from the client in a
   Relay-forward message and sends the resulting DHCPv6 message to the
   DHCP server.  The relay agent sets the fields in the Relay-forward
   message as follows:


   msg-type       RELAY-FORW
   hop-count      1
   link-address   A non-link-local address from the upstream or loopback
                  interface.
   peer-address   A non-link-local address from the upstream or loopback
                  interface.
   options        MUST include a "Relay Message option" in which OPTION_ORO
                  is included.


4.3.  Receipt of DHCPv6 messages

   In this configuration, messages from the DHCPv6 server will be
   returned to the DHCPv6 relay agent, with the message for the DHCPv6
   client encapsulated in the Relay Message option [RFC3315] in a Relay-
   reply message.  The relay agent function extracts the message for the
   client from the Relay Message option and hands the message to the
   DHCPv6 client in the NAS/MAG.


5.  Security Considerations

   This document describes the use of DHCPv6 for LMA discovery in Proxy
   Mobile IPv6 networks.  It does not introduce any additional security
   concerns beyond those described in the "Security Considerations"
   section of the DHCPv6 base specification [RFC3315].


6.  IANA considerations

   None.


7.  Acknowledgements

   The authors are thankful to Sri Gundavelli for his comments that have
   led to some improvements in this draft.




Xia & Sarikaya          Expires October 31, 2009                [Page 6]


Internet-Draft                LMA Discovery                   April 2009


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
              (DHCP) Service for IPv6", RFC 3736, April 2004.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

8.2.  Informative references

   [I-D.ietf-mip6-bootstrapping-integrated-dhc]
              Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
              Integrated Scenario",
              draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
              progress), April 2008.

   [I-D.ietf-mip6-hiopt]
              Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP
              Options for Home Information Discovery in MIPv6",
              draft-ietf-mip6-hiopt-17 (work in progress), May 2008.

   [I-D.xia-netlmm-radius]
              Xia, F., Sarikaya, B., Korhonen, J., Gundavelli, S., and
              D. Damic, "RADIUS Support for Proxy Mobile IPv6",
              draft-xia-netlmm-radius-04 (work in progress), April 2009.

   [I-D.korhonen-dime-pmip6]
              Korhonen, J., Bournelle, J., Muhanna, A., Chowdhury, K.,
              and U. Meyer, "Diameter Proxy Mobile IPv6: Support For
              Mobile Access Gateway and Local  Mobility Anchor to
              Diameter Server Interaction", draft-korhonen-dime-pmip6-04
              (work in progress), September 2008.




Xia & Sarikaya          Expires October 31, 2009                [Page 7]


Internet-Draft                LMA Discovery                   April 2009


   [I-D.giaretta-netlmm-mip-interactions]
              Giaretta, G., "Interactions between PMIPv6 and MIPv6:
              scenarios and related issues",
              draft-giaretta-netlmm-mip-interactions-02 (work in
              progress), November 2007.














































Xia & Sarikaya          Expires October 31, 2009                [Page 8]


Internet-Draft                LMA Discovery                   April 2009


Authors' Addresses

   Frank Xia
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: xiayangsong@huawei.com


   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: sarikaya@ieee.org

































Xia & Sarikaya          Expires October 31, 2009                [Page 9]