[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                                 Samsung
Expires: August 24, 2008                                Kuntal Chowdhury
                                                        Starent Networks
                                                          JinHyeock Choi
                                                                 Samsung
                                                       February 21, 2008


          DHCP Options for Home Information Discovery in MIPv6
                      draft-ietf-mip6-hiopt-11.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 August 24, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).










Jang, et al.             Expires August 24, 2008                [Page 1]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


Abstract

   This draft defines a DHCP-based scheme to enable dynamic discovery of
   Mobile IPv6 home network information.  New DHCP options are defined
   which allow a mobile node to request the home agent IP address, FQDN,
   or home network prefix and obtain it via the DHCP response.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  DHCP options for HA Dynamic Discovery  . . . . . . . . . . . .  5
     3.1.  Home Network Information Option  . . . . . . . . . . . . .  5
       3.1.1.  Home Network Information Sub-options . . . . . . . . .  7
     3.2.  MIP6 Relay Agent Option  . . . . . . . . . . . . . . . . . 10
       3.2.1.  MIP6 Relay Agent Sub-option  . . . . . . . . . . . . . 11
   4.  Option Usage . . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Mobile Node Behavior . . . . . . . . . . . . . . . . . . . 12
     4.2.  NAS/DHCP Relay Agent Behavior  . . . . . . . . . . . . . . 13
     4.3.  DHCP Server Behavior . . . . . . . . . . . . . . . . . . . 14
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   6.  IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 18
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23






















Jang, et al.             Expires August 24, 2008                [Page 2]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


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
   pre-configuration, or dynamically discover it.  The Mobile IPv6
   specification [RFC3775] describes how home agents can be dynamically
   discovered by mobile nodes that know the home network prefix.  This
   scheme does not work when prefix information is not already available
   to the mobile node.  One architecture to solve this problem is
   described in [I-D.ietf-mip6-bootstrapping-integrated-dhc].  A part of
   the solution is the capability to deliver home network prefix
   information to the mobile node by means of the stateless DHCPv6
   [RFC3736] [RFC3315].  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.  The solution involves defining a new
   DHCP option to carry home network prefix, home agent IP address and
   FQDN information.

   As part of configuring the initial TCP/IP parameters, a mobile node
   can find itself a suitable home agent.  Such a home agent might
   reside in the access network that the mobile node connects to, or in
   a home network that the mobile node is associated with.  A mobile
   node can indicate its home network identity when roaming to a visited
   network in order to obtain the MIP6 bootstrap parameters from the
   home network.  As an example, the visited network may determine the
   home network of the mobile node based on the realm portion of the NAI
   (Network Access Identifier) [RFC4282] used in access authentication.

   The mobile node may or may not be connected to the "home" network
   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 HMIPv6 [I-D.ietf-mipshop-4140bis] 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 August 24, 2008                [Page 3]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


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

   General mobility terminology can be found in [RFC3753].  The
   following additional terms, as defined in [RFC4640], are used in this
   document:

       o Access Service Provider (ASP): A network operator that
         provides direct IP packet forwarding to and from the
         mobile node.

       o Mobility Service Provider (MSP): A service provider
         that provides Mobile IPv6 service.  In order to obtain
         such service, the mobile node must be authenticated and
         authorized to use the Mobile IPv6 service.

       o Mobility Service Authorizer (MSA): A service provider
         that authorizes Mobile IPv6 service.






























Jang, et al.             Expires August 24, 2008                [Page 4]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


3.  DHCP options for HA Dynamic Discovery

   This section introduces new DHCP options and their sub-options which
   are used for dynamic discovery of the home agent IP address, FQDN, or
   home prefix information in Mobile IPv6.  The drafts
   [I-D.ietf-mip6-radius] and
   [I-D.ietf-mip6-bootstrapping-integrated-dhc] describe the complete
   procedure for home agent assignment among the mobile node, NAS, DHCP
   and AAA entities for the bootstrapping procedure in the integrated
   scenario.

   A NAS is assumed to be co-located with a DHCP relay agent or a DHCP
   server in this solution.  In the network where a NAS is not co-
   located with a DHCP relay nor a server, the server may not be
   provided with the home network information from the NAS, and thereby
   it may assign to mobile node the home information which has been
   preconfigured by the administrator or which is acquired through the
   mechanism that is not described in this document.

3.1.  Home Network Information Option

   This option is proposed to allow exchange of the home network
   information between the mobile node (DHCP client) and the DHCP
   server.  It is used to indicate the target home network requested by
   the mobile node to the DHCP server in the Information-request
   message.  In the Reply message, it conveys the home network
   information assigned by the DHCP server to the mobile node.
























Jang, et al.             Expires August 24, 2008                [Page 5]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


    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_MIP6_HNINF       |           Option-len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Id-type    |                                               |
   +-+-+-+-+-+-+-+-+                                               +
   .                          Sub-options                          .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Option-code

           OPTION_MIP6_HNINF (TBD)

       Option-len

           1 + length of Sub-options in units of 8 octets.

       Id-type

           The type of Home Network Identifier:

               0    Visited domain (local ASP)

               1    Target MSP

               2    No preference

       Sub-options

           A series of Home Network Information sub-options.

   The Id-type in the request specifies the location of the home network
   requested by the mobile node as below:
















Jang, et al.             Expires August 24, 2008                [Page 6]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


       o The Id-type 0 indicates the mobile node is interested in
         learning the home network information that pertains to the
         currently visited network. This type can be used to
         discover local home agents in the local ASP. In this case,
         the Option-len is set to 1.

       o The Id-type 1 indicates the mobile node is interested in
         learning the 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 or by any target
         domain. The option MUST carry a the Home Network
         Information sub-option whose Sub-opt-code is 1, which
         specifies the requested target MSP. The target MSP can
         be a mobile node's home MSP or any MSP which has a trusted
         roaming relationship with the mobile node's MSA.

       o If the mobile node has no preference, the Id-type is set
         to 2 and the Option-len field is set to 1. In this case,
         the assignment of the home network information is within
         the server's own discretion. For the detailed description,
         refer to Section 4.

   The Id-type in the reply indicates the location of the home network
   information provided by the DHCP server which is carried in the
   following Home Network Information sub-options.

3.1.1.  Home Network Information Sub-options

   This sub-option is a container of each of home network information in
   the Home Network Information option.





















Jang, et al.             Expires August 24, 2008                [Page 7]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Sub-opt-code         |          Sub-opt-len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                    Home Network Information                   .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Sub-opt-code

           A 16-bit unsigned integer for the type of the following
           Home Network Information field. Possible values are:

               0    Reserved

               1    Home network identifier

               2    Home network prefix

               3    Home agent address

               4    Home agent FQDN

               5 ~ (2^16-1) Reserved

       Sub-opt-len

           The length of the Home Network Information field in units
           of 8 octets.

       Home Network Information

           The provided home network information according to the
           Sub-opt-code. This is encoded as specified as below.

   While the Sub-opt-code of 1 is available both in the requesting Home
   Network Information option and in the returned Home Network
   Information option, the Sub-opt-codes of 2, 3, and 4 are available
   only in the returned Home Network Information option.

   When the Sub-opt-code is set to 1 in the request, the Home Network
   Information field MUST contain the 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].  This sub-option in the request SHOULD be copied into the
   Home Network Information option returned in the reply.



Jang, et al.             Expires August 24, 2008                [Page 8]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


   When the Sub-opt-code is set to 2, the Home Network Information field
   includes the IPv6 home network prefix, its lifetime and length
   information as below.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Preferred Lifetime                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Valid Lifetime                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Prefix-len  |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   |                                                               |
   |                 IPv6 Home Network Prefix                      |
   |                          (16 octets)                          |
   |                                                               |
   |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |
   +-+-+-+-+-+-+-+-+                                               .
   .                 Home Network Prefix Sub-options               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Preferred Lifetime

           32-bit unsigned integer.  The length of time in seconds
           (relative to the time the packet is sent) that addresses
           generated from the prefix via stateless address
           auto-configuration remain preferred [RFC4862]. A value of
           0xffffffff represents infinity.

       Valid Lifetime

           32-bit unsigned integer.  The length of time in seconds
           (relative to the time the packet is sent) that addresses
           generated from the prefix via stateless address
           auto-configuration remain in the valid state [RFC4862].
           A value of 0xffffffff represents infinity. When the valid
           lifetime expires, the address becomes invalid. The valid
           lifetime must be greater than or equal to the preferred
           lifetime.

       Prefix-len

           The length of the following IPv6 Home Network Prefix in bits.

       IPv6 Home Network Prefix



Jang, et al.             Expires August 24, 2008                [Page 9]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


           An IPv6 Home Network Prefix.

       Home Network Prefix Sub-options

           Options associated with the IPv6 Home Network Prefix.
           Currently there is no sub-option available.

   When the Sub-opt-code is set to 3, the Home Network Information field
   MUST contain the 128-bit IPv6 address of the home agent.

   When the Sub-opt-code is set to 4, the Home Network Information field
   MUST contain the FQDN of the home agent as described in Section 8 of
   [RFC3315].

   Multiple sub-options may exist in a Home Network Information option
   to carry more than one home information.

3.2.  MIP6 Relay Agent Option

   This option carries the home network information for the mobile node
   (the NAS may know this, for instance, through AAA by using
   [I-D.ietf-mip6-radius]) from the DHCP relay agent to the DHCP server.
   The DHCP relay agent sends this option to the DHCP server in the
   Relay-forward message.

    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_MIP6_RELAY       |           Option-len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                          Sub-options                          .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Option-code

           OPTION_MIP6_RELAY (TBD)

       Option-len

           The length of Sub-options in units of 8 octets.

       Sub-options

           A series of MIP6 Relay Agent sub-options.






Jang, et al.             Expires August 24, 2008               [Page 10]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


3.2.1.  MIP6 Relay Agent Sub-option

   This sub-option is a container of each of home network information
   included in the MIP6 Relay option.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Sub-opt-code         |        Sub-opt-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                     Home Network Information                  .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Sub-opt-code

           A 16-bit unsigned integer for the type of the following
           Home Network Information field. Possible values are:

               0    Reserved

               1    Home network prefix

               2    Home agent address

               3    Home agent FQDN

               4 ~ (2^16-1) Reserved

       Sub-opt-len

           The length of the Home Network Information field in units
           of 8 octets.

       Home Network Information

           A home network prefix, home agent IP address or home agent
           FQDN to be provided to the DHCP server according to the
           Sub-opt-code.

   The Sub-opt-len and the Home Network Information fields in the sub-
   option for the Home network prefix, the Home agent address and the
   Home agent FQDN are set in the same manner as those of the Home
   Network Information sub-option specified in Section 3.1.1.

   Multiple sub-options may exist in a MIP6 Relay Agent option to carry
   more than one home information.



Jang, et al.             Expires August 24, 2008               [Page 11]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


4.  Option Usage

   The requesting and sending of the proposed DHCP options follow the
   rules for DHCP options in [RFC3315].

4.1.  Mobile Node Behavior

   A mobile node does not need to perform the home information discovery
   procedure after every change in attachment.  It may try to perform
   the home network information discovery when it lacks home network
   information for MIPv6 or needs to change the home agent for some
   reasons, for example, to recover from the single point of failure of
   the existing home agent or to use the topologically best home agent.
   Note that despite the home information discovery procedure the mobile
   node may decide to keep the old home agent still in use afterwards,
   in order to avoid losing the current sessions.

   For acquiring the home network information, a mobile node MUST send
   the Information-request message including the Home Network
   Information option according to the stateless DHCPv6
   [RFC3736][RFC3315].  The mobile node MUST also include the Option
   code for the Home Network Information option in the Option Request
   option in the request.

   During the process of requesting the bootstrapping information, the
   mobile node MUST clarify its preference about the requested home
   network with the Id-type in the Home Network Information option.  If
   it does not care about the location of the home network where the
   home agent is to be assigned, it MUST clarify that fact by setting
   the Id-type to 2.  The Id-type 2 means that the mobile node has no
   preferred home network and is willing to use any information provided
   by the DHCP server.

   When the mobile node sets the Id-type to 1 in the request, it MUST
   include the Home Network Information sub-option with Sub-opt-code 1
   which carries the FQDN of the target network such as "myhomeisp.com".
   Note that a single Home Network Information option can carry at most
   one Home Network Information sub-option with Id-type 1 in the
   request.

   The mobile node MUST NOT include the Home Network Information option
   whose Id-type is other than 0, 1, and 2 as defined as Section 3.1.
   It can only include the Home Network Information sub-option whose
   Sub-opt-code is 1 in the request.

   The mobile node can request more than one home information by using
   multiple Home Network Information options in the request.  For
   instance, if the mobile node wants to retrieve home network



Jang, et al.             Expires August 24, 2008               [Page 12]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


   information from both the visited network (ASP) and the target MSP
   with a single transaction, it can request the information by using
   two Home Network Information options with Id-type 0 and Id-type 1.
   It can also request the home information for more than one target
   MSPs at the same time by including multiple Home Network Information
   options with Id-type 1.  However, there SHOULD not be more than one
   Home Network Information option with Id-type 0 nor more than one Home
   Network Information option with Id-type 2 in the request.

   On receiving the Reply message including the Home Network Information
   option, the mobile node SHOULD check whether the option is valid.  It
   MUST ignore the option whose Id-type is other than 0, 1, and 2.  It
   MUST also ignore the Home Network Information sub-option in the reply
   whose Sub-opt-code is other than 1, 2, 3, and 4 as described in
   Section 3.1.1.

   When the mobile node obtains the Home Network Information option with
   Id-type 1, it SHOULD check whether the returned option includes the
   home network identifier in its sub-option.  If it is not provided in
   the sub-option, the Home Network Information option MUST be ignored
   and skipped.  The home network identifiers provide a way to match the
   Home Network Information options in the request and the reply when
   the mobile node has sent the request with multiple Home Network
   Information options with the same Id-type 1 but with different home
   network identifiers.

   The Reply message can carry multiple Home Network Information
   options.  A single Home Network Information option also can contain
   multiple Home Network Information sub-options.  When provided with
   more than one home network information, the mobile node is required
   to have a selection mechanism to determine which one to use for
   establishing a Mobile IPv6 session.  For example, if the mobile node
   acquires both IPv6 address and FQDN of the home agent, it may try to
   use the address information of the home agent first.  However, the
   selection mechanism is outside the scope of this document.

   If the mobile node attempts to retrieve information in its current
   network but fails, it SHOULD employ previously retrieved information.
   If no information has been retrieved previously and there is no
   configuration that enables the mobile node to find and use a home
   agent, the mobile node SHOULD log an error and, depending on
   configured policy, revert to network access without a mobility
   protocol.

4.2.  NAS/DHCP Relay Agent Behavior

   As described in Section 3, a NAS is assumed to be co-located with a
   DHCP relay or a DHCP server.  The NAS communicates with the mobile



Jang, et al.             Expires August 24, 2008               [Page 13]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


   node during the network access authentication and typically also
   interacts with backend AAA systems.  It is expected that the NAS is
   or becomes aware of the mobility related information for the mobile
   node at this time using mechanisms such as Diameter or RADIUS
   attributes [I-D.ietf-mip6-radius].  The NAS passes the information to
   the co-located DHCP relay agent or the server.  The following
   describes the behavior of the DHCP relay agent when the NAS functions
   as a DHCP relay.

   When receiving a DHCP message from the mobile node, the DHCP relay
   agent forwards the message to the DHCP server or another DHCP relay
   as per [RFC3315].  If the relay determines that the NAS has passed
   home network information for this mobile node and has available home
   information for it, it SHOULD include the home network information in
   the MIP6 Relay Agent option, and attach this option in the Relay-
   forward message.  The DHCP relay MUST NOT include the MIP6 Relay
   agent sub-option whose Sub-opt-code is other than 1, 2, and 3 as
   described in Section 3.2.1.

   In case the DHCP relay does not maintain any home network information
   for the requesting mobile node, it simply forwards the received
   message to the DHCP server according to the [RFC3315].

   Upon receiving a Relay-reply message from the DHCPv6 server, the
   relay SHALL follow the guidelines defined in [RFC3315].  It extracts
   a Reply message from the Relay Message option in the Relay-reply
   message and relays it to the mobile node.

4.3.  DHCP Server Behavior

   When the server receives a Relay-forward message, it may include the
   MIP6 Relay Agent option in case there was home information available
   for the mobile node at the relay.  The home network information
   received from the relay SHOULD be kept in the server so that the
   server can provide the information when it is requested by the mobile
   node.  The server may carry this in the reply when the mobile node
   requested the home network information with a Id-type of 1.

   It MUST ignore the MIP6 Relay Agent option whose Sub-opt-code is
   other than 1, 2, and 3 as described in Section 3.2.1.

   When a DHCP server receives an Information-request message or it in
   the Relay-forward message, it SHOULD check whether the Information-
   request includes the Home Network Information option.  If the mobile
   node included a Home Network Information option and a Home Network
   Information option is requested by the Option Request option in the
   Information-request, the server MUST include a Home Network
   Information option in the Reply message



Jang, et al.             Expires August 24, 2008               [Page 14]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


   The server MUST ignore the Home Network Information option in the
   request whose Id-type is other than 0, 1, and 2 as described in
   Section 3.1.  It MUST also ignore the Home Network Information sub-
   option in the request whose Sub-opt-code is not 1.

   It MUST construct the Home Network Information option(s) according to
   the following logic, and include it or them in the Reply.  The
   Information-request message includes:

       o A. Home Network Information option with Id-type 0

       The DHCP server MUST include each of configured local home
       information in the Home Network Information sub-option, and
       include all sub-options in a single Home Network Information
       option. It MUST set the Id-type to 0 in the Home Network
       Information option to be returned.

       o B. Home Network Information option with Id-type 1

       The Home Network Information option which carries more than
       one target MSP or which does not carry any target MSP MUST be
       ignored. If the DHCP server has the corresponding information
       for the target MSP, it MUST include each of information in the
       Home Network Information sub-option, and include all
       sub-options in a single Home Network Information option. It
       MUST set the Id-type to 1 in the Home Network Information
       to be returned, and copy the sub-option in the request which
       includes the target MSP into the Home Network Information option
       to be returned.

       o C. Home Network Information option with Id-type 2

       In this case, the assignment of home information relies
       on the server's local policy, and the DHCP server is required
       to have its own policy so that it can reply with the proper
       information in the Home Network Information option. The policy
       can be determined based on several factors such as home agent
       availability and the authorization information of the mobile
       node. However, the specific policy setting is not in the scope
       of this document. The DHCP sever MUST include each of home
       information in the Home Network Information sub-option, and
       include all sub-options in one or more than one Home Network
       Information option(s) with Id-type 1 or 2 in the reply.

   The server MUST NOT include the Home Network Information option in
   the reply whose Id-type is other than 0, 1, and 2.  It also MUST NOT
   include the Home Network Information sub-option in the reply whose
   Sub-opt-code is other than 1, 2, 3, and 4 as described in Section



Jang, et al.             Expires August 24, 2008               [Page 15]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


   3.1.1.

   The Reply message can carry multiple Home Network Information
   options.  However, note that there SHOULD not be more than one Home
   Network Information option with Id-type 0 nor more than one Home
   Network Information option with Id-type 2 in the reply.  The value of
   Id-type 2 is valid in the reply only when the server received the
   option with Id-type 2 but has no data to returned to the mobile node.

   In case the server cannot find any home information for Id-type 0 or
   2, it MUST return the Home Network Information option with the Id-
   type set to the requested Id-type and the Option-len set to 1.  In
   case of Id-type 1 in the request, it MUST return the Home Network
   Information option by setting the Id-type to 1 and the Option-len to
   1 + the length of the Home Network Information sub-option including
   target MSP.

   There is no requirement that the server return this option and its
   data in a Relay message as other Relay Agent option
   [RFC4580][RFC4649].

   The DHCP server should provide all of the matching home information
   in Home Network Information option(s) based on its policy.  It may
   return the partially matched results.  For example, when received the
   Home Network Information option which specifies "xxx.myhomeisp.com"
   as the target network, it may return "myhomeisp.com" to the mobile
   node.  However, this follows the server's own policy and outside the
   scope of this document.

   There can be several ways that the DHCP server knows the requested
   home network information.  For instance, as described in [I-D.ietf-
   mip6-radius], a NAS can learn the information via RADIUS during
   network access authentication, and the DHCP relay co-located with the
   NAS can transfer it to the DHCP server by using the proposed DHCP
   option in this document.  Or the home information may have been
   configured statically in the DHCP server by the administrator.
   However, the mechanism by which the DHCP server is provisioned with
   the home network information or obtains it dynamically is outside the
   scope of this document.












Jang, et al.             Expires August 24, 2008               [Page 16]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


5.  Security Considerations

   Secure delivery of home agent and home network information from a
   DHCP server to the mobile node (DHCP client) relies on the same
   security as DHCP.  The particular option defined in this draft does
   not have additional impact on 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.

   The mechanisms in this specification could be used by attackers to
   learn the addresses of home agents in the home network, or to feed
   incorrect information to mobile nodes.

   The ability to learn addresses of nodes may be useful to attackers
   because brute-force scanning of the address space is not practical
   with IPv6.  Thus, they could benefit from any means which make
   mapping the networks easier.  For example, if a security threat
   targeted at routers or even home agents is discovered, having a
   simple mechanism to easily find out possible targets may prove to be
   an additional security risk.

   Apart from discovering the address(es) of home agents, attackers will
   not be able to learn much from this information, and mobile nodes
   cannot be tricked into using wrong home agents, as the actual
   communication with the home agents employs mutual authentication.

   The mechanisms from this specification may also leak interesting
   information about network topology and prefixes to attackers, and
   where there is no security to protect DHCP, even modify this
   information.  Again, the mobile nodes and home agents employ end-to-
   end security when they communicate with each other.  The authentic
   source of all information is that communication, not the information
   from DHCP.

   However, attacks against the information carried in DHCP may lead to
   denial-of-service if mobile nodes are unable to connect to any home
   agent, or choose a home agent that is not the most preferred one.











Jang, et al.             Expires August 24, 2008               [Page 17]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


6.  IANA Consideration

   This document defines new DHCPv6 options, and IANA is requested to
   assign the following new DHCPv6 Option Codes/Sub-option Codes in the
   registry maintained in
   http://www.iana.org/assignments/dhcpv6-parameters:

       o OPTION_MIP6_HNINF for the Home Network Information option
       o OPTION_MIP6_RELAY for the MIP6 Relay Agent option

   The Sub-option Code for the Home Network Information option:

       o Reserved                0
       o Home network identifier 1
       o Home network prefix     2
       o Home agent address      3
       o Home agent FQDN         4
       o Reserved                5 ~ (2^16-1)

   The Sub-option Codes for the MIP6 Relay Agent option:

       o Reserved                0
       o Home network prefix     1
       o Home agent address      2
       o Home agent FQDN         3
       o Reserved                4 ~ (2^16-1)

   These Sub-option Codes should be placed in a new name space "DHCPv6
   Mobile IPv6 Sub-option Codes" under the same registry.  Future values
   can be allocated via Standards Action or IESG Approval.

   In addition, a new name space "Home Network Information Option Id-
   type Values" should be created, again in the same registry.  Values
   0, 1, and 2 are assigned by this document as specified in Section
   3.1.  Future values can be allocated via Standards Action or IESG
   Approval.















Jang, et al.             Expires August 24, 2008               [Page 18]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


7.  Acknowledgments

   The authors would like to thank Kilian Weniger, Domagoj Premec,
   Basavaraj Patil, Vijay Devarapalli, Gerardo Giaretta, Bernie Volz,
   David W. Hankins, Behcet Sarikaya, Vidya Narayanan, Francis Dupont,
   Sam Weiler, Jari Arkko and Miguel A. Diaz for their valuable
   feedback.












































Jang, et al.             Expires August 24, 2008               [Page 19]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


8.  References

8.1.  Normative 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-05 (work in
              progress), July 2007.

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

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

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

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 2005.

   [RFC4580]  Volz, B., "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
              June 2006.

   [RFC4649]  Volz, B., "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
              August 2006.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

8.2.  Informative References

   [I-D.ietf-mip6-radius]
              Chowdhury, K., "RADIUS Mobile IPv6 Support",
              draft-ietf-mip6-radius-03 (work in progress),
              November 2007.

   [I-D.ietf-mipshop-4140bis]



Jang, et al.             Expires August 24, 2008               [Page 20]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


              Castelluccia, C., "Hierarchical Mobile IPv6 Mobility
              Management (HMIPv6)", draft-ietf-mipshop-4140bis-01 (work
              in progress), November 2007.

   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology",
              RFC 3753, June 2004.

   [RFC4640]  Patel, A. and G. Giaretta, "Problem Statement for
              bootstrapping Mobile IPv6 (MIPv6)", RFC 4640,
              September 2006.









































Jang, et al.             Expires August 24, 2008               [Page 21]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


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 Electronics
   Istanbul
   Turkey

   Email: a.yegin@partner.samsung.com


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

   Email: kchowdhury@starentnetworks.com


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

   Email: jinchoe@samsung.com
















Jang, et al.             Expires August 24, 2008               [Page 22]

Internet-Draft   DHCPv6 for Home Info Discovery in MIPv6   February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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, THE IETF TRUST 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 August 24, 2008               [Page 23]


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