[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                        S. Bhandari
Internet-Draft                                                  S. Kumar
Intended status: Standards Track                           Cisco Systems
Expires: January 9, 2013                                    July 8, 2012


                 DHCPv4 Configuration Options in PMIPv6
              draft-bhandari-netext-pmipv6-dhcp-options-00

Abstract

   This document specifies methods to learn DHCP host configuration
   options by DHCPv4 server co-located at Mobile Access Gateway(MAG) as
   directed by Local Mobility Anchor(LMA) via Proxy Mobile IPv6(PMIPv6)
   signalling.

Requirements Language

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

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 9, 2013.

Copyright Notice

   Copyright (c) 2012 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Bhandari & Kumar         Expires January 9, 2013                [Page 1]


Internet-Draft    DHCPv4 host configuration via PMIPv6         July 2012


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Mechanisms to learn DHCPv4 options by DHCPv4 Server
       co-located at MAG . . . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  LMA signalling MAG to send DHCPINFOR  . . . . . . . . . . . 4
     4.2.  MAG voluntarily sending DHCPINFORM  . . . . . . . . . . . . 6
     4.3.  Mobile Header Option to encapsulate DHCPv4 Option . . . . . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 9
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 9
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9





























Bhandari & Kumar         Expires January 9, 2013                [Page 2]


Internet-Draft    DHCPv4 host configuration via PMIPv6         July 2012


1.  Introduction

   Proxy Mobile IPv6 protocol is extended to support IPv4 to enable IPv4
   home address mobility support to the mobile node as detailed in
   [RFC5844].  Dynamic Host Configuration Protocol v4 (DHCPv4) based
   address configuration support for a mobile node in a Proxy Mobile
   IPv6 domain is detailed in Section 3.4 of [RFC5844] where the Mobile
   Access Gateway(MAG) can support co-location of DHCPv4 Server or
   DHCPv4 Relay agent as directed by Local Mobility Anchor(LMA) in IPv4
   DHCP Support Mode Option.

   When DHCPv4 Relay agent is co-located with MAG, DHCPv4 Server in the
   proxy mobile IPv6 domain can be configured to influence and respond
   to the mobile node with all the DHCPv4 configuration options.
   However when DHCPv4 Server is co-located with MAG in a Proxy Mobile
   IPv6 domain it has to be statically configured with all the DHCPv4
   option values (e.g., DNS Server, SIP Server, etc. that have no
   corresponding Mobility Header options defined) that correspond to
   IPv4 Home Address assignment for all its DHCPv4 clients.  Due to
   static configuration required at the MAG this works well when the
   number of MAGs are few and when the same configuration options are to
   be applied to all the mobile nodes attached to the MAG.  Currently
   there is no well defined scheme to influence DHCPv4 Server co-located
   at MAG with the DHCPv4 options values to be offered to the DHCPv4
   clients (Mobile Nodes) dynamically via PMIPv6 signalling.

   This document specifies mechanism for DHCPv4 server co-located at the
   MAG to learn DHCPv4 options that can be offered to the mobile nodes
   that it serves via PMIPv6 signalling.


2.  Motivation

   Proxy mobile IPv6 [RFC5213] can be used for supporting network-based
   mobility management in various types of network deployments.  IPv4
   address assigment extension to PMIPv6 is added by [RFC5844] that adds
   new Mobility Header options to influence IPv4 address assignment.
   Specifically [RFC5844] adds support to influence:

   1.  IPv4 address configuration offered to the client - Mobility
       Header Option Type 37 that can be used to fill 'yiaddr' field of
       DHCPv4 message as specifed in [RFC2131] and Subnet Mask Option as
       specified in [RFC2132]

   2.  IPv4 Default-Router Address Option - Mobility Header Option Type
       38 that can be used to fill DHCPv4 Router Option as specifed in
       [RFC2132]




Bhandari & Kumar         Expires January 9, 2013                [Page 3]


Internet-Draft    DHCPv4 host configuration via PMIPv6         July 2012


   In addition to the above an IPv4 device requires more configuration
   to communicate with other nodes in the network.  For example if LMA
   is influencing the IPv4 address configuration it may also have to
   influence configuration corresponding to the address such as DNS
   server's IP address, Domain name for the mobile node etc.  It demands
   operational overhead to statically configure DHCPv4 server co-located
   at each MAG with all this configuration options.


3.  Terminology

   All the DHCP related terms used in this document to be interpreted as
   defined in the Dynamic Host Configuration Protocol v4 (DHCPv4)
   [RFC2131] specification.

   All the mobility related terms used in this document are to be
   interpreted as defined in the Proxy Mobile IPv6 specifications
   [RFC5213] and [RFC5844].


4.  Mechanisms to learn DHCPv4 options by DHCPv4 Server co-located at
    MAG

   DHCPv4 options can be learnt by a DHCPv4 Server co-located at the MAG
   using any of the following mechanisms:

   1.  LMA signaling MAG in Protocol Binding Acknowlegment(PBA) to
       trigger DHCPINFORM request message to obtain configuration
       options as specified in [RFC2131].

   2.  MAG to voluntarily send DHCPINFORM message when it discovers the
       LMA, to dynamically learn DHCPv4 configuration options.  These
       options will be applied to all or group of mobile nodes that will
       attach to the MAG and are anchored at the specific LMA, when the
       mobile nodes trigger DHCPv4 discover.

   3.  New Mobility Header option, to encapsulate DHCPv4 option within
       it, that is included in PBA message from LMA to MAG - DHCPv4
       server co-located at MAG can process this DHCPv4 option after
       decapsulation and include the learnt DHCPv4 options in the DHCPv4
       response messages towards the client.

   The following sections will describe each of the above approaches.

4.1.  LMA signalling MAG to send DHCPINFOR

   In this approach LMA can influence the DHCPv4 Server co-located at
   the MAG to trigger DHCPINFORM on a per MN basis to influence DHCPv4



Bhandari & Kumar         Expires January 9, 2013                [Page 4]


Internet-Draft    DHCPv4 host configuration via PMIPv6         July 2012


   options sent to the MN.  Figure 1 provides high level message
   exchange between MN, DHCP server at MAG, MAG and LMA.

    MN   MAG(DHCP-S) LMA
    |------>|        |    1. DHCPDISCOVER
    |       |------->|    2. Proxy Binding Update
    |       |<-------|    3. Proxy Binding Acknowledgement
    |       |        |       (IPv4 HoA, Support Mode set
    |       |        |        to indicate server mode and
    |       |        |        availability of additional
    |       |        |        DHCPv4 options)
    |       |========|    4. Tunnel/Route Setup
    |       |------->|    5. DHCPINFORM
    |       |<-------|    6. DHCPACK (All the options
    |       |        |       applicable to the MN)
    |<------|        |    7. DHCPOFFER  (IPv4 HoA, Options)
    |------>|        |    8. DHCPREQUEST (IPv4 HoA, Options)
    |<------|        |    9. DHCPACK
    |       |        |



   Figure 1: Overview of per MN DHCPINFORM exchange between DHCP Server
                         co-located at MAG and LMA

   To acheive this IPv4 DHCP Support Mode Option defined in Section
   3.3.4 of [RFC5844] will be extended to carry additional flag that can
   be interpreted by MAG to trigger DHCPINFORM.























Bhandari & Kumar         Expires January 9, 2013                [Page 5]


Internet-Draft    DHCPv4 host configuration via PMIPv6         July 2012


  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(39) |   Length(2)   |    Reserved (R)           |M|S|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Type, Length and DHCP Support Mode (S) are as defined in Section 3.3.4
  of RFC5844.

  Addition 1-bit from the Reserved flags is used to define the following
  flag:

  DHCP More configs available (M)

          A 1-bit field that when set indicates more DHCP
          options are available.
          This flag when set to (1) indicates to MAG that DHCPINFORM
          message has to be triggered to learn more DHCPv4 options.
          This flag MUST be set to (0) when the DHCP Support Mode
          indicates DHCP Relay.


                       IPv4 DHCP Support Mode Option

   The DHCPINFORM message triggered by MAG MUST have'ciaddr' field set
   to IPv4 home address of the MN learnt in PBA and 'giaddr' field set
   to MAGs IPv4 address reachable to LMA.  The response DHCPACK is
   received by MAG to learn and cache the DHCP options that will then be
   sent to the MN in DHCP reply messages.

   This approach provides per MN configuration granularity to LMA.  This
   results in overhead of DHCPINFORM-DHCPACK message exchange for every
   MN that need to be influenced with DHCP options available.

4.2.  MAG voluntarily sending DHCPINFORM

   When MAG discovers LMA in a Proxy Mobile IPv6 domain, it can
   voluntarily trigger one ore more DHCPINFORM message with 'ciaddr'
   field set to IPv4 address of each of its interface in that Proxy
   Mobile IPv6 domain.  LMA MAY respond with DHCPACK message with the
   options applicable to all the MNs that will attach to the MAG
   indicated by 'ciaddr'.  LMA will respond with DHCPACK only if it is
   configured to support MAG to act as DHCP server and has additional
   options available.  Otherwise LMA will silently discard the received
   DHCPINFORM.

   MAG will cache the DHCP options received in response to the
   DHCPINFORM.  DHCPv4 server co-located at MAG will send these cached



Bhandari & Kumar         Expires January 9, 2013                [Page 6]


Internet-Draft    DHCPv4 host configuration via PMIPv6         July 2012


   options towards the MN when it receives DHCP request messages.
   Figure 2 provides message exchange overview for this approach.

    MN   MAG(DHCP-S) LMA
    |       |------->|    1. DHCPINFORM
    |       |<-------|    2. DHCPACK
    |       |        |      (Learn and cache options
    .       .        .       for future use)
    .       .        .
    |------>|        |    3. DHCPDISCOVER
    |       |------->|    4. Proxy Binding Update
    |       |<-------|    5. Proxy Binding Acknowledgement
    |       |        |       (IPv4 HoA, Support Mode set
    |       |        |        to indicate server mode)
    |       |========|    4. Tunnel/Route Setup
    |<------|        |    7. DHCPOFFER  (IPv4 HoA,
    |       |        |       other options learnt in Step 2)
    |------>|        |    8. DHCPREQUEST (IPv4 HoA)
    |<------|        |    9. DHCPACK
    |       |        |



       Figure 2: Overview of DHCPINFORM exchange between MAG and LMA

   Periodicity of MAG sending such DHCPINFORM messages to refresh the
   cached data will be driven by configuration at MAG.

   This approach is optimal when LMA wants to provide the same DHCP host
   configuration options for a large set of MNs attaching to MAG.

4.3.   Mobile Header Option to encapsulate DHCPv4 Option

   A new option, the DHCP Encapsulation option, is defined for use in
   the Proxy Binding Acknowledgement message sent by the local mobility
   anchor(LMA) to the mobile access gateway (MAG).  This option will
   encapsulate the complete DHCPv4 option including code, length and
   value.  This option MAY be included only when IPv4 DHCP Support Mode
   option indicates DHCPv4 Server support at MAG.  It MUST NOT be
   included when MAG acts as a DHCPv4 Relay.  Zero or more instances of
   this option can be included in PBA message to send different DHCP
   Options.  DHCPv4 server co-located at MAG can decapsulate the DHCP
   Option within this option and send it in DHCP response messages to
   MNs, adhering to DHCP protocol specification.







Bhandari & Kumar         Expires January 9, 2013                [Page 7]


Internet-Draft    DHCPv4 host configuration via PMIPv6         July 2012


     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     |          Reserved             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                        DHCP Option                            +
    .                              ...                              .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type
         <TBD>

     Length
         8-bit unsigned integer indicating the length of the option
         in octets, excluding the type and length fields.

     Reserved

         This field is unused for now.  The value MUST be initialized to
         0 by the sender and MUST be ignored by the receiver.

     DHCP Option

         A variable length field containing the DHCP option including code,
         length and value.



                         DHCP Encapsulation Option

   This approach is useful when the number of DHCP options that are to
   be influenced by LMA is small in comparison to the overhead of
   exchanging DHCPINFORM message described in Section 4.1 to retrive
   these options.  For e.g. if only DNS Server address option has to be
   influenced then it can be encapsulated in this option instead of
   forcing a DHCPINFORM to retrieve it or defining a new Mobility Header
   Option equivalent to each of the DHCP Option to be influenced.


5.  IANA Considerations

   This document defines a new Mobility Header options, the DHCP
   Encapsulation Option described in Section 4.3.  The Type value for
   this option should be assigned from the same numbering space as
   allocated for the other mobility options, as defined in [RFC3775].




Bhandari & Kumar         Expires January 9, 2013                [Page 8]


Internet-Draft    DHCPv4 host configuration via PMIPv6         July 2012


6.  Security Considerations

   All the security considerations from [RFC5844] apply to this
   specification.

   In addition security consideration for exchanging DHCP messages
   between MAG and LMA (DHCPINFORM) message as outlined in [RFC2131]
   also apply.  Link-layer confidentiality and integrity protection may
   be employed to reduce the risk of disclosure and tampering of DHCP
   messages between LMA, MAG and MN.

   This document defines new mobility option for supporting dhcp
   configuration options encapsulation.  These options are to be carried
   in Proxy Binding Acknowledgement messages.  The required security
   mechanisms specified in the base Proxy Mobile IPv6 protocol for
   protecting these signaling messages are sufficient when carrying
   these mobility options.


7.  Acknowledgements


8.  Normative References

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

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

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

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

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, May 2010.










Bhandari & Kumar         Expires January 9, 2013                [Page 9]


Internet-Draft    DHCPv4 host configuration via PMIPv6         July 2012


Authors' Addresses

   Shwetha Bhandari
   Cisco Systems
   Cessna Business Park, Sarjapura Marathalli Outer Ring Road
   Bangalore, KARNATAKA  560 087
   India

   Phone: +91 80 4426 0474
   Email: shwethab@cisco.com


   Sanjay Kumar
   Cisco Systems
   Cessna Business Park, Sarjapura Marathalli Outer Ring Road
   Bangalore, KARNATAKA  560 087
   India

   Phone: +91 80 4426 0274
   Email: sakumar3@cisco.com































Bhandari & Kumar         Expires January 9, 2013               [Page 10]


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