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

Versions: (draft-jang-mip6-hiopt) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 RFC 6610

MIP6 Working Group                                          Hee Jin Jang
Internet-Draft                                               Alper Yegin
Intended status: Standards Track                          JinHyeock Choi
Expires: February 25, 2007                                   SAMSUNG AIT
                                                        Kuntal Chowdhury
                                                        Starent Networks
                                                         August 24, 2006


          DHCP Option for Home Information Discovery in MIPv6
                      draft-ietf-mip6-hiopt-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 February 25, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).











Jang, et al.            Expires February 25, 2007               [Page 1]

Internet-Draft  DHCP Opt for Home Info Discovery in MIPv6    August 2006


Abstract

   This draft defines a DHCP-based scheme to enable dynamic discovery of
   Mobile IPv6 home agent address, home address, and home subnet.  New
   DHCP options are defined to carry the information from a DHCP server
   to the DHCP client running on the mobile node.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  DHCP options for HA Dynamic Discovery  . . . . . . . . . . . .  5
     3.1.  Home Network Identifier Option . . . . . . . . . . . . . .  5
     3.2.  Home Network Information Option  . . . . . . . . . . . . .  6
   4.  Option Usage . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  DHCP Server - Home Agent Relation  . . . . . . . . . . . .  9
     4.2.  Mobile Node Considerations . . . . . . . . . . . . . . . .  9
     4.3.  DHCP Server Considerations . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15



























Jang, et al.            Expires February 25, 2007               [Page 2]

Internet-Draft  DHCP Opt for Home Info Discovery in MIPv6    August 2006


1.  Introduction

   Before a mobile node can engage in Mobile IPv6 signaling with a home
   agent, it should either know the IP address of the home agent via
   preconfiguration, or dynamically discover it.  Mobile IPv6
   specification [2] describes how home agents can be dynamically
   discovered by mobile nodes that know the home subnet prefix.  This
   scheme does not work when prefix information is not already available
   to the mobile node.  This problem can be solved by delivering one or
   more home subnet prefix information to the mobile node by means of
   DHCP.  Subsequently, the mobile node can engage in dynamic home agent
   discovery using the prefix information.  In addition to delivering
   the prefix information, DHCP can also be used to provide the IP
   addresses or FQDNs of the home agents that are available to the
   mobile node and the home address that the mobile node can use to
   register with the home agent.

   The solution involves defining new DHCP options to carry home subnet
   prefix, home agent IP address, home agent's FQDN information, and
   home address of the mobile node.  A similar solution has already been
   defined for Mobile IPv4 home agents [3].

   As part of configuring the initial TCP/IP parameters, a mobile node
   can obtain home network information for the subnet it is directly
   attached to, other subnets in the visited domain, or a subnet from
   its home domain.  A mobile node can convey the target home subnet's
   identity in order to receive corresponding information.  For example
   the mobile node can provide realm portion of its user NAI (Network
   Access Identifier) and expect that a home network information from
   its home domain is returned.  The availability of the requested
   information depends on the DHCP server having prior knowledge or
   dynamically discovering it.  While the specific details are outside
   the scope of this document, use of static tables and AAA-assisted
   discovery are possible options [8].

   The mobile node may or may not be connected to the "home" subnet when
   it attempts to learn Mobile IPv6 home network information.  This
   allows operators to centrally deploy home agents while being able to
   bootstrap mobile nodes that are already roaming.  This scenario also
   occurs when HMIP [7] is used, where the mobile node is required to
   discover the MAP (a special home agent) that is located multiple hops
   away from the mobile node's attachment point.









Jang, et al.            Expires February 25, 2007               [Page 3]

Internet-Draft  DHCP Opt for Home Info Discovery in MIPv6    August 2006


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

   Most of terms used in this draft are defined in Mobile IPv6 [2] and
   RFC3315 [4].











































Jang, et al.            Expires February 25, 2007               [Page 4]

Internet-Draft  DHCP Opt for Home Info Discovery in MIPv6    August 2006


3.  DHCP options for HA Dynamic Discovery

   This section introduces two DHCP options used for dynamic home agent
   discovery in Mobile IPv6.

3.1.  Home Network Identifier Option

   This option is used to carry the identifier of the target home
   network.  This identification allows mobile node to request
   information for a home subnet within the visited domain, or from a
   specific domain.  It is assumed that the DHCP server has some
   mechanism to know or retrieve the requested Mobile IPv6 information
   such as [9].  The specifics of these mechanisms are outside the scope
   of this draft.

   The mobile node MUST include this option along with its Option
   Request option in its request.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       OPTION_HNId             |           option-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     id-type   |A|   reserved  |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                                                               |
      .                                                               .
      .                    Home Network Identifier                    .
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Home Network Identifier Option Format



             option-code

                OPTION_HNId (TBD)

             option-len

                Total length of the option

             id-type

                The type of Home Network Identifier:




Jang, et al.            Expires February 25, 2007               [Page 5]

Internet-Draft  DHCP Opt for Home Info Discovery in MIPv6    August 2006


                           0    Local (visited) domain



                           1    Network realm

             A flag

                A flag to specify whether the client requests a home
                address or not.

             reserved

                8-bit field reserved for future use.  The value MUST be
                initialized to zero by the sender, and MUST be ignored
                by the receiver.


   Id-type 0 indicates the mobile node is interested in learning the
   home network information that pertains to the immediately connected
   (visited) network.  In that case, Home Network Identifier field is
   not used.  This type can be used to discover local home agents in a
   visited network.

   Id-type 1 indicates the format of Home Network Identifier field is a
   network realm as defined in [5].  In this case, the mobile node is
   interested in learning home network information that pertains to the
   given realm.  This type can be used to discover home agents that are
   hosted by a user's home domain (as indicated by his/her NAI-based
   username -- user@HomeRealm).

   If A flag is set in this option, the server should assign a home
   address to the client in the returned Home Network Information
   option.  Otherwise, the server should not assign a home address
   option.

3.2.  Home Network Information Option

   This option is used to carry home network information to a mobile
   node in the form of one or more of home subnet prefix(es), home agent
   address(es), home agent FQDN(s), and mobile node's home address.

   The server MUST provide all of the matching home subnet prefix(es),
   home agent address(es) or FQDN(s) in a Home Network Information
   option.  If the server has no information to provide, it MUST set the
   option-len field to zero in this option.  If the client set the A
   flag in Home Network Identifier option, it MUST provide an available
   home address to a client.



Jang, et al.            Expires February 25, 2007               [Page 6]

Internet-Draft  DHCP Opt for Home Info Discovery in MIPv6    August 2006


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         OPTION_HNInf          |           option-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  hninfo-type  |  hninfo-len   |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                                                               |
      .                                                               .
      .                   Home Network Information                    .
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Home Network Information Option Format



             option-code

                OPTION_HNInf (TBD)

             option-len

                Total length of the option

             hninfo-type

                The type of following Home Network Information field.
                Possible values are:

                        0    Home subnet prefix

                        1    Complete IPv6 address of the home agent

                        2    FQDN of the home agent

                        3    IPv6 Home address

             hninfo-len

                8-bit unsigned integer. Total length of the following
                Home Network Information field.








Jang, et al.            Expires February 25, 2007               [Page 7]

Internet-Draft  DHCP Opt for Home Info Discovery in MIPv6    August 2006


             Home Network Information

                A home subnet prefix, home agent IP address, FQDN
                and home address to be assigned to a mobile node.

                When hninfo-type is set to 0, the data field MUST
                contain 8-bit prefix length information followed
                by a 128-bit IPv6 address beginning with the
                available network prefix.

                When hninfo-type is set to 1, the data field MUST
                contain a 128-bit IPv6 address of the home agent.

                When hninfo-type is set to 2, the data field MUST
                contain a FQDN as described in RFC1035 [6].

                When hninfo-type is set to 3, the data field MUST
                contain the 8-bit reserved field, 8-bit prefix length
                field of the following home address, 32-bit lifetime
                of the following home address and the 128-bit home
                address to be assigned to a client. The lifetime is
                expressed in units of seconds.


   The home address, or hninfo-type = 3, should be included if and only
   if the client sets A flag in Home Network Identifier option.  Setting
   the lifetime to 0xffffffff ("infinity") means a permanent assignment
   of an address to the client.  The lifetime of the assigned home
   address should not be longer than the lifetime of its prefix since
   the home address cannot survive the prefix lifetime.

   If id-type is 0 in Home Network Identifier option, the server should
   reply with the available home agent(es) or home address information
   in the visited network.  Otherwise, it should return that information
   in the specified home network in Home Network Identifier field in the
   request option.

   Single option can carry multiple information preceded by hninfo-type
   and hninfo-len fields.  The length fields help identify the
   information boundaries.











Jang, et al.            Expires February 25, 2007               [Page 8]

Internet-Draft  DHCP Opt for Home Info Discovery in MIPv6    August 2006


4.  Option Usage

   The requesting and sending of this option follows the rules for DHCP
   options in [4].

4.1.  DHCP Server - Home Agent Relation

   The DHCP server does not have to be co-located with a home agent, or
   even be on the home subnet of the mobile node.  Its location with
   respect to home network does not matter as long as it possesses the
   requested information.

4.2.  Mobile Node Considerations

   When a Mobile IPv6 mobile node finds itself with neither a home
   subnet prefix/home address nor a home agent address, it may request
   the needed information with Option Request option.  For instance, a
   mobile node connecting to a network for the first time may acquire a
   DHCP address and solicit for home network information at the same
   time.

   A mobile node MUST identify the desired information with Home Network
   Identifier option.  For example, a DHCP server may have information
   about home agents from several domains (and subnets).  It relies on
   the mobile node to select the domain for determining which ones it
   should provide in response to the client's request.

   When the mobile node gets more than one home agent address, it MUST
   have a selection mechanism to determine which one to use for
   establishing a Mobile IPv6 session.  In case it retrieves only home
   subnet prefix(es), it needs to perform dynamic home agent discovery
   to learn the IP addresses of the home agents.  Similarly, if FQDN of
   a home agent is retrieved, the mobile node can use DNS to resolve it
   to IPv6 address(es) of the home agents.  If the mobile node receives
   both IPv6 address(es) and FQDN(s) of the home agents, it SHALL use
   the IPv6 information of the home agents.  When the mobile node
   requests and receives the home address information from the DHCP
   server, it SHALL use it to perform Mobile IPv6 home registration.
   For detailed mobile node behavior, refer to section 3.6 of [9].

   When an MN sends a Binding Update message to home agent by using HoA
   which is assigned in Home Network Information option, the requested
   lifetime in Binding Update message MUST not be shorter than the
   lifetime of the HoA.  Since the HoA lifetime is not greater than its
   prefix lifetime, it is guaranteed that binding cache entry's lifetime
   is not greater than the home prefix lifetime.  Note that, according
   to 10.3.1 of MIPv6, the lifetime for the binding cache entry MUST NOT
   be greater than the remaining valid lifetime for the subnet prefix of



Jang, et al.            Expires February 25, 2007               [Page 9]

Internet-Draft  DHCP Opt for Home Info Discovery in MIPv6    August 2006


   HoA specified with the Binding Update.

4.3.  DHCP Server Considerations

   It is assumed that the DHCP server has access to home network
   information for its clients for this option to be useful.  The DHCP
   server can rely on pre-configuration, or some dynamic discovery
   mechanisms for obtaining this information.  In case it does not have
   any information, or it cannot locate matching information based on
   Home Network Identifier, it returns a Home Network Information option
   with 0-length data.  The DHCP server can either return the IPv6
   address(es) of home agent or the FQDN(s) of home agents.  It is not
   required for the DHCP server to return both.

   When a DHCP server assigns a HoA to an MN, it should guarantee that
   the lifetime of assigned HoA MUST NOT be greater than that of the
   subnet prefix in the MN's HoA.  The lifetimes of HoAs for assignments
   are can be negotiated when the home prefix is delivered from the home
   agent, or configured by DHCP administrator's policy.  The details are
   outside the scope of this document.































Jang, et al.            Expires February 25, 2007              [Page 10]

Internet-Draft  DHCP Opt for Home Info Discovery in MIPv6    August 2006


5.  Security Considerations

   Secure delivery of home agent, home address, and home link
   information from a DHCP server to the mobile node (DHCP client)
   relies on the overall DHCP security.  The particular option defined
   in this draft does not have additional impact on the DHCP security.

   Aside from the DHCP client to server interaction, an operator must
   also ensure secure delivery of mobile IP information to the DHCP
   server.  This is outside the scope of DHCP and the newly defined
   option.








































Jang, et al.            Expires February 25, 2007              [Page 11]

Internet-Draft  DHCP Opt for Home Info Discovery in MIPv6    August 2006


6.  IANA Consideration

   This document introduces two new DHCPv6 options, Home Agent Request
   option and Home Agent Reply option.  The type numbers for new DHCP
   options are currently TBD.  An appropriate request will be made to
   IANA if this Internet draft gets accepted as an RFC.













































Jang, et al.            Expires February 25, 2007              [Page 12]

Internet-Draft  DHCP Opt for Home Info Discovery in MIPv6    August 2006


7.  Normative References

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

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

   [3]  Levkowetz, H., "DHCP Option for Mobile IP Mobility Agents",
        draft-ietf-dhc-mipadvert-opt-02 (work in progress),
        February 2004.

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

   [5]  Aboba, B. and M. Beadles, "The Network Access Identifier",
        RFC 2486, January 1999.

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

   [7]  Soliman, H., Castelluccia, C., Malki, K., and L. Bellier,
        "Hierarchical Mobile IPv6 mobility management (HMIPv6)",
        draft-ietf-mipshop-hmipv6-04 (work in progress), December 2004.

   [8]  Chowdhury, K. and A. Lior, "RADIUS Attributes for Mobile IPv6
        bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01 (work
        in progress), November 2004.

   [9]  Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for
        the Integrated Scenario",
        draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in
        progress), June 2006.

















Jang, et al.            Expires February 25, 2007              [Page 13]

Internet-Draft  DHCP Opt for Home Info Discovery in MIPv6    August 2006


Authors' Addresses

   Hee Jin Jang
   Samsung Advanced Institute of Technology
   P.O. Box 111
   Suwon 440-600
   Korea

   Email: heejin.jang@samsung.com


   Alper E. Yegin
   Samsung Advanced Institute of Technology
   Istanbul
   Turkey

   Email: alper01.yegin@partner.samsung.com


   JinHyeok Choi
   Samsung Advanced Institute of Technology
   P.O. Box 111
   Suwon 440-600
   Korea

   Email: athene@sait.samsung.co.kr


   Kuntal Chowdhury
   Starent Networks
   30 International Place
   Tewksbury, MA  01876
   US

   Email: kchowdhury@starentnetworks.com
















Jang, et al.            Expires February 25, 2007              [Page 14]

Internet-Draft  DHCP Opt for Home Info Discovery in MIPv6    August 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Jang, et al.            Expires February 25, 2007              [Page 15]


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