Skip to main content

Dynamic IPv4 Provisioning for Lightweight 4over6
draft-liu-softwire-lw4over6-dhcp-deployment-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Cong Liu , Qi Sun , Jianping Wu
Last updated 2014-06-30
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-liu-softwire-lw4over6-dhcp-deployment-02
Network Working Group                                             C. Liu
Internet-Draft                                                    Q. Sun
Intended status: Standards Track                                   J. Wu
Expires: January 1, 2015                             Tsinghua University
                                                           June 30, 2014

            Dynamic IPv4 Provisioning for Lightweight 4over6
             draft-liu-softwire-lw4over6-dhcp-deployment-02

Abstract

   Lightweight 4over6 [I-D.ietf-softwire-lw4over6] is an IPv4 over IPv6
   hub and spoke mechanism that provides overlay IPv4 services in an
   IPv6-only access network.  Provisioning IPv4 addresse and port set to
   customers is the core function of Lightweight 4over6 control plane.
   [I-D.ietf-softwire-lw4over6] illustrates how to use DHCPv6 for
   deterministic IPv4 provisioning.  This document discusses how to
   provision IPv4 parameters by using dynamic IPv4 provisioning
   protocols such as DHCPv4 over DHCPv6
   [I-D.ietf-dhc-dhcpv4-over-dhcpv6].

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 1, 2015.

Copyright Notice

   Copyright (c) 2014 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

Liu, et al.              Expires January 1, 2015                [Page 1]
Internet-Draft        lw4over6 dynamic provisioning            June 2014

   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Dynamic Provisioning Considerations . . . . . . . . . . . . .   3
     3.1.  lwB4 IPv6 Addressing  . . . . . . . . . . . . . . . . . .   3
     3.2.  lwB4 Tunnel Source Address  . . . . . . . . . . . . . . .   4
     3.3.  Working with SLAAC  . . . . . . . . . . . . . . . . . . .   4
     3.4.  lwAFTR Binding Table Maintenance  . . . . . . . . . . . .   4
   4.  Working with DHCPv4 over DHCPv6 . . . . . . . . . . . . . . .   5
     4.1.  IP Addressing . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  DHCPv6 Configuration  . . . . . . . . . . . . . . . . . .   5
     4.3.  DHCPv4 over DHCPv6 Function . . . . . . . . . . . . . . .   6
     4.4.  Port Set Consideration  . . . . . . . . . . . . . . . . .   6
     4.5.  lwAFTR Binding Table Maintenance  . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Lightweight 4over6 [I-D.ietf-softwire-lw4over6] provides IPv4 access
   over IPv6 network in hub-and-spoke softwire architecture.  In
   Lightweight 4over6, each Lightweight B4 (lwB4) is assigned with a
   port-restricted public IPv4 address or a full public IPv4 address to
   be used for IPv4 communication.  Provisioning IPv4 address, port set
   and other IPv4 parameters to lwB4 is the core function of the
   Lightweight 4over6 control plane.  It can be achieved by several
   protocols, such as DHCPv6 [RFC3315] [I-D.ietf-softwire-map-dhcp],
   DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] , and PCP
   [RFC6887].

   [I-D.ietf-softwire-lw4over6] illustrates how to use DHCPv6 for
   deterministic IPv4 provisioning.  The IPv4 address and port set id
   (PSID) are carried in DHCPv6 options through DHCPv6 queries.
   However, the deterministic IPv4 provisioning adds some restrictions
   for addressing and deployment: the IPv4 lease time needs to be bound
   to the IPv6 lease time; the IPv4 address and PSID need to be embedded
   into clients' /128 IPv6 address so the client can not use arbitrary

Liu, et al.              Expires January 1, 2015                [Page 2]
Internet-Draft        lw4over6 dynamic provisioning            June 2014

   /128 IPv6 address.

   It's not necessary to pre-install the binding between IPv4/IPv6
   addresses through using dynamic IPv4 provisioning protocols such as
   DHCPv4 and PCP.  Since DHCPv4 is unable to work in native IPv6
   network directly, DHCPv4 over DHCPv6
   [I-D.ietf-dhc-dhcpv4-over-dhcpv6] is proposed to support DHCPv4
   functionality in IPv6 network by transporting DHCPv4 messages over
   DHCPv6 message.  [I-D.ietf-dhc-dynamic-shared-v4allocation] describes
   how to allocate port set to clients using DHCPv4 over DHCPv6.  PCP
   [RFC6887] also supports dynamic address and ports provisioning.
   [I-D.ietf-pcp-port-set] describes how port set is allocated to the
   lwB4.

   This document discusses how to deploy Lightweight 4over6 using
   dynamic IPv4 provisioning protocols as the IPv4 provisioning protocol
   and analyses the benefit of using dynamic provisioning methods.

2.  Terminology

   Terminology defined in [I-D.ietf-dhc-dhcpv4-over-dhcpv6] and
   [I-D.ietf-softwire-lw4over6] is used extensively in this document.

3.  Dynamic Provisioning Considerations

   [I-D.ietf-softwire-lw4over6] describes the behavior of lwB4 and
   lwAFTR using DHCPv6 as provisioning protocol.  It is based on a pre-
   determined binding relationship between IPv6 prefix and IPv4 address
   + PSID.  This section discusses the issues produced by deterministic
   provisioning and how they could be solved by dynamic IPv4
   provisioning.

3.1.  lwB4 IPv6 Addressing

   In section 5.1 of [I-D.ietf-softwire-lw4over6], it requires the lwB4
   to embed its IPv4 address and PSID into its tunnel source IPv6
   address.  The reason to do this is that the binding relationship
   between IPv4/IPv6 addresses is pre-determined before the lwB4
   requires IPv4/IPv6 addresses.  Although the ISP can decide which IPv6
   prefix for lwB4 to use, it can not decide the lwB4's IPv6 suffix
   before IPv6 provisioning actually happens.  When a lwAFTR receives an
   downstream IPv4 packet from Internet, it needs to construct the /128
   IPv6 address of the lwB4 as the tunnel destination address and then
   encapsulate the packet.  However since the binding table in lwAFTR is
   generated before IPv4 provisioning, the lwB4's IPv6 suffix is unknown
   by looking up the binding table.  So it is solved by filling IPv4
   address and PSID into IPv6 suffix.

Liu, et al.              Expires January 1, 2015                [Page 3]
Internet-Draft        lw4over6 dynamic provisioning            June 2014

   When using dynamic IPv4 provisioning, the binding entry in lwAFTR is
   generated after IPv4 provisioning process.  When lwAFTR is
   encapsulating a packet, it looks up the binding table, using the
   destination IPv4 address and port as index, to get the lwB4's /128
   IPv6 address.  Thus IPv4 address and PSID are not necessary to be
   filled into IPv6 suffix.  There is no restriction on how to generate
   the lwB4's IPv6 address.

3.2.  lwB4 Tunnel Source Address

   In deterministic IPv4 provisioning, because lwB4's prefixes are pre-
   determined in lwAFTR's binding table, when lwB4 has multiple
   prefixes, it needs to perform a longest prefix match to select which
   prefix to be used as the tunnel source address.  A hint prefix is
   given by DHCPv6 server to tell the lwB4 which prefix looks like the
   correct one.  If the lwB4 chooses a different prefix to be used as
   the tunnel address, it leads to a tunnel communication error.

   With dynamic IPv4 provisioning, the tunnel source address is decided
   by lwB4. lwB4 can choose any of its IPv6 address as long as the
   address is routable to the lwAFTR.

3.3.  Working with SLAAC

   In deterministic IPv4 provisioning, the lwB4's /64 IPv6 prefix is
   assigned by ISP, and its /64 IPv6 suffix is filled with its IPv4
   address and PSID.  If a ISP wants multiple lwB4s to use the same /64
   prefix, these lwB4s will run SLAAC to get the prefix.  In this case,
   the upstream router advertises the /64 prefix to multiple lwB4s, then
   the lwB4s require their own IPv4 address and PSID through DHCPv6
   Information-request.  However, if the DHCPv6 server is not the
   upstream next hop of lwB4, it can not get the lifetime of lwB4's IPv6
   address, so the DHCPv6 server is unable to recycle the allocated IPv4
   addresses.  Dynamic IPv4 provisioning works well with SLAAC since the
   IPv4 lease time is independent from IPv6 address.

3.4.  lwAFTR Binding Table Maintenance

   With dynamic IPv4 provisioning protocol, the lwAFTR's binding table
   is maintained through IPv4 provisioning process.  To update a binding
   entry, lwB4's IPv6 address (as tunnel address), IPv4 address and PSID
   are needed.  The IPv4 address and PSID are given by the provisioning
   server (DHCP 4o6 server or PCP server).  The lwB4 must provide its
   /128 IPv6 address.  If the IPv4 provisioning is transported in IPv6
   unicast packet, the IPv6 source address in packets from lwB4 is used.
   Otherwise, the lwB4 must provide the IPv6 address in the message
   body, e.g. in a DHCPv6 option [I-D.fsc-dhc-dhcp4o6-saddr-opt].

Liu, et al.              Expires January 1, 2015                [Page 4]
Internet-Draft        lw4over6 dynamic provisioning            June 2014

   When lwAFTR is located in the path of the IPv4 provisioning process,
   it updates its binding table through the provisioning messages.  It
   listens all provisioning messages from provisioning server to lwB4,
   and updates binding through valid DHCP ACK message and PCP response.

   When lwAFTR is out of the provisioning path, the provisioning server
   must indicate the lwAFTR about the binding updates.  There are
   several protocols that support this function, e.g.  NETCONF.  A
   standardized data model may be needed, but it's out of the scope of
   this document.

4.  Working with DHCPv4 over DHCPv6

   This section describes how DHCPv4 over DHCPv6 is used for Lightweight
   4over6 configuration.  [I-D.perreault-softwire-lw4over6-pcp]
   discusses how PCP works with Lightweight 4over6.

4.1.  IP Addressing

   Before starting DHCPv4 over DHCPv6 to achieve IPv4 configuration,
   lwB4 MUST be configured with an IPv6 address.  There's no
   restrictions on how IPv6 address is provisioned.  The configured IPv6
   address is used for IPv6 tunnelling and DHCPv4 over DHCPv6 process.
   The address that lwB4 chooses MUST be routable to the DHCP 4o6
   server.

   The softwire provider is free to provide any IPv4 address for a lwB4.
   There's no restrictions on IPv6/IPv4 addressing, e.g. scattered IPv4
   addresses can be used, and IPv4 address/PSID are not embeded into
   IPv6 addres.

4.2.  DHCPv6 Configuration

   Before lwB4 runs DHCPv4 over DHCPv6 to get IPv4 address and port set,
   lwB4 SHOULD run DHCPv6 to achieve the IPv6 address of lwAFTR and the
   IPv6 address of DHCP 4o6 server.  lwB4 puts the option code of
   OPTION_S46_CONT_LW and OPTION_DHCP4_O_DHCP6_SERVER in the Option
   Request Option (ORO) of its DHCPv6 queries.  If the DHCPv6 server
   decides to provide DHCPv4 over DHCPv6 service for the lwB4, it MUST
   reply the lwB4 with a 4o6 Server Address Option, and a S46 BR Option
   inside a Softwire46 LightWeight 46 Container Option.  If the 4o6
   Server Address Option is present in the response, the DHCPv6 server
   MUST NOT reply any S46 Port Parameters Option or S46 IPv4/IPv6
   Address Binding Option in the response.

   It is possible that both stateless (using DHCPv6 for deterministic
   IPv4 provisioning) and stateful (using DHCPv4 over DHCPv6 for dynamic
   IPv4 provisioning) lwB4 exist in the same domain, and a DHCPv6 server

Liu, et al.              Expires January 1, 2015                [Page 5]
Internet-Draft        lw4over6 dynamic provisioning            June 2014

   serves both types of lwB4.  In this case, when the DHCPv6 server
   receives a query, it distinguish the client based on whether there is
   a OPTION_DHCP4_O_DHCP6_SERVER in ORO.  If OPTION_DHCP4_O_DHCP6_SERVER
   is present in ORO, the lwB4 is treated as a stateful lwB4 that asking
   for DHCPv4 over DHCPv6 service; otherwise it's treated as a stateless
   lwB4.  The DHCPv6 server MAY reply S46 Port Parameters Option and S46
   IPv4/IPv6 Address Binding Option to both types of lwB4 if the server
   is not configued with DHCPv4 over DHCPv6 configuration.  In this case
   the lwB4 is informed to run the stateless configuration mode in
   [I-D.ietf-softwire-lw4over6].

4.3.  DHCPv4 over DHCPv6 Function

   The DHCPv4 over DHCPv6 function in lwB4 is disabled by default.
   During DHCPv6 process, if S46 Port Parameters Option or S46 IPv4/IPv6
   Address Binding Option is present in the response from DHCPv6 server,
   lwB4 SHOULD perform operations in [I-D.ietf-softwire-lw4over6], and
   MUST NOT run DHCPv4 over DHCPv6 for dynamic IPv4 provisioning.  When
   neither of the two options is present, and 4o6 Server Address Option
   is present, the lwB4 MUST enables its DHCPv4 over DHCPv6 function to
   achieve IPv4 address.  Regardless of whether S46 Port Parameters
   Option or S46 IPv4/IPv6 Address Binding Option is present, the lwB4
   MAY run stateless DHCPv4 over DHCPv6 (i.e.  DHCPINFORM) when 4o6
   Server Address Option is present.

   lwB4 MUST provide its IPv6 tunnel source address in its DHCPv4 over
   DHCPv6 query.  The IPv6 address is provided either by unicasting
   DHCPv4 over DHCPv6 requests to DHCP 4o6 server, or being put into 4o6
   Server Address Option [I-D.fsc-dhc-dhcp4o6-saddr-opt] along with
   DHCPv4 over DHCPv6 requests.  This address is used by lwAFTR as the
   lwB4's tunnel address.  When the lwB4's IPv6 tunnel address is
   changed, the lwB4 MUST re-initiate its DHCPv4 over DHCPv6 process and
   provide its updated tunnel address to the server.

4.4.  Port Set Consideration

   lwB4 gets its PSID through DHCPv4 over DHCPv6 along with its IPv4
   address.  [I-D.ietf-dhc-dynamic-shared-v4allocation] describes how to
   provision PSID to lwB4 through DHCPv4 over DHCPv6.

   When sending a DHCPDISCOVER message, lwB4 MUST include
   OPTION_V4_PORTPARAMS in the Parameter Request List.  If the server
   decides to reply a port-restricted address, it MUST reply
   OPTION_V4_PORTPARAMS to lwB4.  if the server decides to reply a full
   IPv4 address, it SHOULD NOT reply OPTION_V4_PORTPARAMS in the
   response.  When lwB4 receives DHCPv4 over DHCPv6 response without
   OPTION_V4_PORTPARAMS, it configures itself with the full IPv4 address
   as regular DHCPv4 client does.  When lwB4 receives a shared IPv4

Liu, et al.              Expires January 1, 2015                [Page 6]
Internet-Draft        lw4over6 dynamic provisioning            June 2014

   address, the address is used for NAPT and MUST NOT be used to
   identify the lwB4.

4.5.  lwAFTR Binding Table Maintenance

   lwAFTR maintains its binding table as per section 6.1 of
   [I-D.ietf-softwire-lw4over6].  The binding table is synchronized with
   DHCPv4 over DHCPv6 process.  The following DHCPv4 over DHCPv6
   messages triggers binding table modification:

   o  DHCPACK: Generated by DHCP server, triggers lwAFTR to add a new
      entry or modify an existing entry.

   o  DHCPRELEASE: Generated by lwB4, triggers lwAFTR to delete an
      existing entry.

   When a DHCPACK event received by lwAFTR, the lwAFTR looks up its
   binding table using the IPv4 address and PSID.  If there is an
   existing entry found, the lwAFTR updates the lifetime and IPv6
   address field of the entry; otherwise the lwAFTR creates a new entry
   accordingly.

   When a DHCPRELEASE event received by lwAFTR, the lwAFTR looks up its
   binding table using the IPv6 address, IPv4 address and PSID.  The
   lwAFTR deletes the entry either by removing it from the binding table
   or mark the lifetime field to an invalid value (e.g. 0).

5.  Security Considerations

   Security considerations in [I-D.ietf-softwire-lw4over6] and
   [I-D.ietf-dhc-dhcpv4-over-dhcpv6] should be considered.

6.  IANA Considerations

   This document does not include an IANA request.

7.  References

7.1.  Normative References

   [I-D.fsc-dhc-dhcp4o6-saddr-opt]
              Farrer, I., Sun, Q., and Y. Cui, "DHCPv4 over DHCPv6
              Source Address Option", draft-fsc-dhc-dhcp4o6-saddr-opt-00
              (work in progress), February 2014.

Liu, et al.              Expires January 1, 2015                [Page 7]
Internet-Draft        lw4over6 dynamic provisioning            June 2014

   [I-D.ietf-dhc-dhcpv4-over-dhcpv6]
              Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
              Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc-
              dhcpv4-over-dhcpv6-09 (work in progress), June 2014.

   [I-D.ietf-dhc-dynamic-shared-v4allocation]
              Cui, Y., Qiong, Q., Farrer, I., Lee, Y., Sun, Q., and M.
              Boucadair, "Dynamic Allocation of Shared IPv4 Addresses",
              draft-ietf-dhc-dynamic-shared-v4allocation-00 (work in
              progress), April 2014.

   [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-10 (work
              in progress), June 2014.

7.2.  Informative References

   [I-D.ietf-pcp-port-set]
              Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou,
              T., and S. Perreault, "Port Control Protocol (PCP)
              Extension for Port Set Allocation", draft-ietf-pcp-port-
              set-05 (work in progress), May 2014.

   [I-D.ietf-softwire-map-dhcp]
              Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
              W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng,
              "DHCPv6 Options for configuration of Softwire Address and
              Port Mapped Clients", draft-ietf-softwire-map-dhcp-07
              (work in progress), March 2014.

   [I-D.perreault-softwire-lw4over6-pcp]
              Xie, C., Perreault, S., and C. Zhou, "Provisioning
              Lightweight 4over6 (lw4o6) with the Port Control Protocol
              (PCP)", draft-perreault-softwire-lw4over6-pcp-00 (work in
              progress), June 2013.

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

   [RFC6887]  Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
              2013.

Liu, et al.              Expires January 1, 2015                [Page 8]
Internet-Draft        lw4over6 dynamic provisioning            June 2014

Authors' Addresses

   Cong Liu
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5822
   Email: gnocuil@gmail.com

   Qi Sun
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5822
   Email: sunqi@csnet1.cs.tsinghua.edu.cn

   Jianping Wu
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5983
   Email: jianping@cernet.edu.cn

Liu, et al.              Expires January 1, 2015                [Page 9]