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

Versions: 00 01 02 03 04 05 06 07 draft-ietf-dhc-dhcp4o6-saddr-opt

Softwire WG                                                    I. Farrer
Internet-Draft                                       Deutsche Telekom AG
Intended status: Standards Track                                  Q. Sun
Expires: January 5, 2016                                          Y. Cui
                                                     Tsinghua University
                                                            July 4, 2015


                DHCPv4 over DHCPv6 Source Address Option
                draft-fsc-softwire-dhcp4o6-saddr-opt-02

Abstract

   DHCPv4 over DHCPv6 [RFC7341] describes a mechanism for dynamically
   configuring IPv4 over an IPv6-only network.  For DHCPv4 over DHCPv6
   to function with some IPv4-over-IPv6 softwire mechanisms and
   deployment scenarios, the operator must learn the /128 IPv6 address
   that the client will use as the source of IPv4-in-IPv6 tunnel.  This
   address, in conjunction with the IPv4 address and the Port Set ID
   allocated to the DHCP 4o6 client are used to create a binding table
   entry in the softwire tunnel concentrator.  This memo defines two
   DHCPv6 options used to communicate the source tunnel IPv6 address
   between the DHCP 4o6 client and server.  It is designed to work in
   conjunction with the IPv4 address allocation process.

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 5, 2016.

Copyright Notice

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





Farrer, et al.           Expires January 5, 2016                [Page 1]


Internet-Draft            DHCP 4o6 SADDR option                July 2015


   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
   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   4.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   3
   5.  IPv6/IPv4 Binding Message Flow  . . . . . . . . . . . . . . .   4
   6.  DHCPv6 Options  . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  DHCPv4 over DHCPv6 Source Address Hint Option . . . . . .   6
     6.2.  DHCPv4 over DHCPv6 Source Address Option  . . . . . . . .   6
     6.3.  Border Router Prefix Option . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     10.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Deterministic IPv4-over-IPv6 transition technologies require that
   elements are pre-configured with binding rules for routing traffic to
   clients.  This places a constraint on the location of the client's
   tunnel endpoint: The tunnel endpoint has to be a pre-determined
   prefix which is usually be configured on the home gateway device.
   [I-D.ietf-softwire-map-dhcp] describes a DHCPv6 based mechanism for
   provisioning such deterministic softwires.

   If a dynamic provisioning model is used, such as using DHCPv4 over
   DHCPv6, then pre-configuation of the softwire elements is not
   possible and client rules must be created/deleted in line with the
   allocation of IPv4 addresses to clients.  This has the benefit of
   removing the fixed address constraint for the client's tunnel
   endpoint, as the address that the client will use can be learnt when
   the tunnel is provisioned.  The operator's tunnel concentrator(s) can
   then be configured with the binding rule.




Farrer, et al.           Expires January 5, 2016                [Page 2]


Internet-Draft            DHCP 4o6 SADDR option                July 2015


   This document describes a mechanism for informing the service
   provider of the binding between the dynamically allocated IPv4
   address and Port Set ID (learnt through DHCPv4 over DHCPv6) and the
   IPv6 address that the softwire Initiator will use for accessing IPv4-
   over-IPv6 services.  It is used with DHCPv4 over DHCPv6 [RFC7341]
   message flows to communicate the binding over the IPv6-only network.
   The service provider can then use this binding information to
   provision other functional elements in their network accordingly,
   e.g. using the client's binding information to synchronise the
   binding table in the border router.

   The mechanism allows much more flexibility in the location of the
   IPv4-over-IPv6 tunnel endpoint, as the IPv6 address is dynamically
   signalled back to the service provider.  The DHCP 4o6 client and
   tunnel client could be run on end devices attached to any routable
   IPv6 prefix allocated to an end-user, located anywhere within an
   arbitrary home network topology.

2.  Applicability

   The mechanism described in this document is only suitable for use for
   provisioning softwire clients via DHCP 4o6.  The options described
   here are only applicable within the DHCP 4o6 message exchange
   process.  Current mechanisms suitable for extending to incorporate
   DHCPv4 over DHCPv6 with dynamic IPv4 address leasing include
   [I-D.ietf-softwire-map] and [I-D.ietf-softwire-lw4over6].

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

4.  Solution Overview

   The solution in this document is intended for the dynamic
   establishment of IPv4-over-IPv6 softwires.  DHCP 4o6 [RFC7341]
   supports dynamically allocating (shared) IPv4 address.  For a
   softwire to be successfully created, the IPv4 address has to be
   linked to the client's IPv6 tunnel source address.  Within this
   process, the DHCP 4o6 client uses a DHCPv6 option to signal its
   tunnel source IPv6 address to the DHCP 4o6 server so that the
   operator's provisioning system can create the binding and configure
   the tunnel concentrator accordingly.

   Two new DHCPv6 options are defined in this memo:
   OPTION_DHCP4O6_SADDR_HINT and OPTION_DHCP4O6_SADDR.  They are
   intended to be used alongside the normal DHCPv4 IPv4 address



Farrer, et al.           Expires January 5, 2016                [Page 3]


Internet-Draft            DHCP 4o6 SADDR option                July 2015


   allocation message flow in the context of DHCPv4 over DHCPv6
   [RFC7341].  If a DHCP 4o6 client supports this mechanism, it MUST
   include the code of OPTION_DHCP4O6_SADDR_HINT in the Option Request
   Option (ORO) [RFC3315] when requesting IPv4 configuration through
   DHCP 4o6.

   The communication of parameters between the client and server is a
   two-way process: OPTION_DHCP4O6_SADDR_HINT is optionally used by the
   DHCP 4o6 server to indicate to the client a preferred IPv6 prefix for
   binding the received IPv4 configuration and sourcing tunnel traffic.
   This may be necessary if there are multiple IPv6 prefixes in use in
   the customer network (e.g.  ULAs), or if the specific IPv4-over-IPv6
   transition mechanism requires the use of a particular prefix for any
   reason.  When the client has selected an IPv6 address to bind the
   IPv4 configuration to, it passes the address back to the DHCP 4o6
   server through OPTION_DHCP4O6_SADDR.

   A softwire initiator also requires the IPv6 address of the border
   router (i.e. softwire tunnel concentrator).  In the dynamic mode, it
   SHOULD acquire an IPv6 prefix of the BR through OPTION_BR_PREFIX.
   Then the /128 border router address is constructed in the same manner
   as described in [I-D.ietf-softwire-map], by concatenating the
   OPTION_BR_PREFIX with IPv4 address and PSID.

   To configure a softwire with DHCP 4o6, the DHCP client requests the
   4o6 Server Address option using DHCPv6.  If the DHCPv6 server
   includes the DHCP 4o6 Server Address option in its response, then
   DHCPv4 over DHCPv6 can be enabled, as in [RFC7341].  If the IPv6
   source address of the client changes (such as IPv6 lease expiration,
   etc.), the client follows the Section 9 of [RFC7341] to re-enable the
   DHCPv4-over-DHCPv6 function.

5.  IPv6/IPv4 Binding Message Flow

   The following diagram shows the client/server message flow and how
   the options defined in this document are used.  In each step, the
   relevant DHCPv4 message is given above the arrow and the relevant
   options below the arrow.  The DHCPv4 messages are encapsulated in
   DHCPv4-query or DHCPv4-response messages, and those options are
   included in the 'options' field of the DHCPv4-query or
   DHCPv4-response message.










Farrer, et al.           Expires January 5, 2016                [Page 4]


Internet-Draft            DHCP 4o6 SADDR option                July 2015


          DHCP 4o6                                              DHCP 4o6
           Client                                                Server
             |                DHCPDISCOVER (DHCPv4)                 |
      Step 1 |----------------------------------------------------->|
             |             ORO with OPTION_BR_PREFIX,               |
             |          OPTION_DHCP4O6_SADDR_HINT(DHCPv6)           |
             |                                                      |
             |                 DHCPOFFER (DHCPv4)                   |
      Step 2 |<-----------------------------------------------------|
             |    OPTION_BR_PREFIX, OPTION_DHCP4O6_SADDR_HINT       |
             |    (cipv6-prefix-hint with service provider's        |
             |           preferred prefix) (DHCPv6)                 |
             |                                                      |
             |                 DHCPREQUEST (DHCPv4)                 |
      Step 3 |----------------------------------------------------->|
             |               OPTION_BR_PREFIX,                      |
             |    OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with     |
             |     client's bound /128 IPv6 address) (DHCPv6)       |
             |                                                      |
             |                   DHCPACK (DHCPv4)                   |
      Step 4 |<-----------------------------------------------------|
             |               OPTION_BR_PREFIX,                      |
             |    OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with     |
             |      client's bound /128 IPv6 prefix) (DHCPv6)       |
             |                                                      |


                      IPv6/IPv4 Binding Message Flow

   A client attempting dynamic softwire configuration includes the
   option code for OPTION_BR_PREFIX, OPTION_DHCP4O6_SADDR_HINT in the
   DHCPv6 ORO in all DHCPv4-query messages it sends.

   When a DHCP 4o6 Server replies with a DHCPOFFER message, it SHOULD
   include an OPTION_BR_PREFIX.  It MAY also include
   OPTION_DHCP4O6_SADDR_HINT, which is used to indicate a preferred
   prefix that the client should use to bind IPv4 configuration to.  If
   this option is received, the client MUST perform a longest prefix
   match between cipv6-prefix-hint and all prefixes/addresses in use on
   the device.  If a match is found, the selected prefix MUST then be
   used to bind the received IPv4 configuration to.  If the client
   doesn't receive OPTION_DHCP4O6_SADDR_HINT the client can select any
   valid /128 IPv6 prefix to use.

   OPTION_DHCP4O6_SADDR is used by the client to inform the DHCP 4o6
   Server which IPv6 address the IPv4 configuration has been bound to.
   The client MUST put the selected IPv6 address into this option and




Farrer, et al.           Expires January 5, 2016                [Page 5]


Internet-Draft            DHCP 4o6 SADDR option                July 2015


   include it in the DHCPv4-response message when it sends the
   DHCPREQUEST message.

6.  DHCPv6 Options

6.1.  DHCPv4 over DHCPv6 Source Address Hint 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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   OPTION_DHCP4O6_SADDR_HINT   |         option-length         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |cipv6-hintlen  |                                               |
        +-+-+-+-+-+-+-+-+          cipv6-prefix-hint                    .
        .                          (variable length)                    .
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o  option-code: OPTION_DHCP4O6_SADDR_HINT (TBA1)
   o  option-length: 1 + length of cipv6-prefix-hint, specified in
      bytes.
   o  cipv6-hintlen: 8-bit field expressing the bit mask length of the
      IPv6 prefix specified in cipv6-prefix-hint.
   o  cipv6-prefix-hint: The IPv6 prefix indicating the preferred prefix
      for the client to bind the received IPv4 configuration to.

6.2.  DHCPv4 over DHCPv6 Source Address Option

   The format of DHCPv4 over DHCPv6 Source address option is defined as
   follows:

         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_DHCP4O6_SADDR      |         option-length         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                        cipv6-src-address                      +
        .                           (128 bits)                          .
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o  option-code: OPTION_DHCP4O6_SADDR (TBA2)
   o  option-length: 16.
   o  cipv6-src-address: The IPv6 address that the client has bound the
      allocated IPv4 configuration to.





Farrer, et al.           Expires January 5, 2016                [Page 6]


Internet-Draft            DHCP 4o6 SADDR option                July 2015


6.3.  Border Router Prefix Option

   The format of Border Router Prefix option is defined as follows:

         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_BR_PREFIX        |         option-length         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |br-prefix6-len |                                               |
        +-+-+-+-+-+-+-+-+        br-ipv6-prefix                         +
        .                      (variable length)                        .
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o  ooption-code: OPTION_BR_PREFIX (TBA3)
   o  option-length: 1 + length of br-ipv6-prefix specified in bytes.
   o  br-prefix6-len: 8 bits long field expressing the length of the
      IPv6 prefix specified in the br-ipv6-prefix field.
   o  br-ipv6-prefix: a variable length field specifying the IPv6
      address or prefix for the border router.  It SHOULD be /64 or
      /128.

   This option provisions the softwire initiator with an IPv6 prefix of
   BR.  If the prefix length is /128, the softwire initiator takes this
   /128 IPv6 address as the BR's tunnel endpoint address.  If the prefix
   length is /64, the softwire initiator MUST create the BR's /128
   tunnel endpoint address by concatenating that prefix, its IPv4
   address and PSID.  This is similar to the initiator creating its own
   IPv6 tunnel endpoint address [I-D.ietf-softwire-map].

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Prefix from the OPTION_BR_PREFIX                   |
      |                        (64-bits)                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Zero Padding          |         IPv4 Address          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       IPv4 Addr cont.         |             PSID              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o  Prefix from the OPTION_BR_PREFIX: The IPv6 prefix got from the
      OPTION_BR_PREFIX.
   o  Padding: Padding (all zeros).
   o  IPv4 Address: Public IPv4 address allocated to the client




Farrer, et al.           Expires January 5, 2016                [Page 7]


Internet-Draft            DHCP 4o6 SADDR option                July 2015


   o  PSID: Port Set ID allocated to the client, left padded with zeros
      to 16-bits.  If no PSID is provisioned, all zeros.

7.  Security Considerations

   TBD

8.  IANA Considerations

   IANA is requested to allocate the DHCPv6 option codes:
   OPTION_DHCP4O6_SADDR_HINT, OPTION_DHCP4O6_SADDR and OPTION_BR_PREFIX.

9.  Acknowledgements

   The authors would like to thank Ted Lemon and Lishan Li for their
   contributions.

10.  References

10.1.  Normative References

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

   [RFC7341]  Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
              Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC
              7341, August 2014.

10.2.  Informative References

   [I-D.farrer-softwire-br-multiendpoints]
              Farrer, I. and Q. Sun, "Multiple Tunnel Endpoints on
              Border Router", draft-farrer-softwire-br-multiendpoints-00
              (work in progress), March 2015.

   [I-D.ietf-softwire-lw4over6]
              Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
              I. Farrer, "Lightweight 4over6: An Extension to the DS-
              Lite Architecture", draft-ietf-softwire-lw4over6-13 (work
              in progress), November 2014.

   [I-D.ietf-softwire-map]
              Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
              Murakami, T., and T. Taylor, "Mapping of Address and Port
              with Encapsulation (MAP)", draft-ietf-softwire-map-13
              (work in progress), March 2015.





Farrer, et al.           Expires January 5, 2016                [Page 8]


Internet-Draft            DHCP 4o6 SADDR option                July 2015


   [I-D.ietf-softwire-map-dhcp]
              Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
              W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
              configuration of Softwire Address and Port Mapped
              Clients", draft-ietf-softwire-map-dhcp-12 (work in
              progress), March 2015.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
              2131, 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.

Authors' Addresses

   Ian Farrer
   Deutsche Telekom AG
   CTO-ATI, Landgrabenweg 151
   Bonn, NRW  53227
   Germany

   Email: ian.farrer@telekom.de


   Qi Sun
   Tsinghua University
   Beijing  100084
   P.R. China

   Phone: +86-10-6278-5822
   Email: sunqi.csnet.thu@gmail.com


   Yong Cui
   Tsinghua University
   Beijing  100084
   P.R. China

   Phone: +86-10-6260-3059
   Email: yong@csnet1.cs.tsinghua.edu.cn










Farrer, et al.           Expires January 5, 2016                [Page 9]


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