Network Working Group C. Liu Internet-Draft Q. Sun Intended status: Standards Track J. Wu Expires: January 5, 2015 Tsinghua University July 4, 2014 Dynamic IPv4 Provisioning for Lightweight 4over6 draft-liu-softwire-lw4over6-dhcp-deployment-03 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 5, 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 5, 2015 [Page 1] Internet-Draft lw4over6 dynamic provisioning July 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 . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 5, 2015 [Page 2] Internet-Draft lw4over6 dynamic provisioning July 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 5, 2015 [Page 3] Internet-Draft lw4over6 dynamic provisioning July 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-softwire-dhcp4o6-saddr-opt]. Liu, et al. Expires January 5, 2015 [Page 4] Internet-Draft lw4over6 dynamic provisioning July 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. In the remaining of this section, "lwB4" without explicitly written as "stateless lwB4" will refer to stateful lwB4 that runs DHCPv4 over DHCPv6 for dynamic IPv4 provisioning. 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 stateful lwB4 runs DHCPv4 over DHCPv6 to acquire IPv4 address and port set, lwB4 SHOULD run DHCPv6 to achieve the DHCP 4o6 server's IPv6 address. The DHCPv6 server provides the DHCP 4o6 server's IPv6 address by OPTION_DHCP4_O_DHCP6_SERVER as defined in [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. lwB4 MUST NOT require OPTION_S46_CONT_LW in all its DHCPv6 requests, and SHOULD ignore any OPTION_S46_CONT_LW and its encapsulated options in all the DHCPv6 responses. It is possible that both stateless and stateful lwB4 exist in the same domain, and a DHCPv6 server serves both types of lwB4. When the DHCPv6 server receives a DHCPv6 query, if OPTION_S46_CONT_LW is Liu, et al. Expires January 5, 2015 [Page 5] Internet-Draft lw4over6 dynamic provisioning July 2014 present in ORO, the lwB4 is treated as a stateless lwB4 that is asking for OPTION_S46_V4V6BIND and OPTION_S46_PORTPARAMS, and the DHCPv6 server processs the request as defined [I-D.ietf-softwire-map-dhcp]. When OPTION_DHCP4_O_DHCP6_SERVER is present in ORO regardless of whether OPTION_S46_CONT_LW is present, the server returns a OPTION_DHCP4_O_DHCP6_SERVER in the response with DHCP 4o6 server's IPv6 address. Both stateful and stateless lwB4 MAY run DHCPv4 over DHCPv6 to acheive stateless IPv4 information (i.e. DHCPINFORM query). When OPTION_S46_CONT_LW is not present in ORO, the DHCPv6 server MUST NOT reply any OPTION_S46_BR, OPTION_S46_V4V6BIND and OPTION_S46_PORTPARAMS to the client. The OPTION_S46_BR SHOULD be provided by DHCP 4o6 server in lwB4's DHCPv4 over DHCPv6 queries. 4.3. DHCPv4 over DHCPv6 Function The DHCPv4 over DHCPv6 function in lwB4 is disabled by default, and enabled by OPTION_DHCP4_O_DHCP6_SERVER in DHCPv6 server's response. Once enabled, lwB4 runs stateful DHCPv4 over DHCPv6 to acquire IPv4 address and port set. lwB4 provides one of its IPv6 address as IPv6 tunnel source address to the DHCP 4o6 server, and get the lwAFTR's tunnel address through DHCPv4 over DHCPv6. The DHCPv4 over DHCPv6 message flow is described in section 4 of [I-D.fsc-softwire-dhcp4o6-saddr-opt] and MUST be followed. 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 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: Liu, et al. Expires January 5, 2015 [Page 6] Internet-Draft lw4over6 dynamic provisioning July 2014 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-softwire-dhcp4o6-saddr-opt] Farrer, I., Sun, Q., and Y. Cui, "DHCPv4 over DHCPv6 Source Address Option", draft-fsc-softwire-dhcp4o6-saddr- opt-00 (work in progress), July 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-01 (work in progress), July 2014. Liu, et al. Expires January 5, 2015 [Page 7] Internet-Draft lw4over6 dynamic provisioning July 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. 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 Liu, et al. Expires January 5, 2015 [Page 8] Internet-Draft lw4over6 dynamic provisioning July 2014 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 5, 2015 [Page 9]