Network Working Group C. Liu Internet-Draft Q. Sun Intended status: Standards Track Tsinghua University Expires: April 24, 2014 October 21, 2013 Lightweight 4over6 Deployment with DHCPv4 over DHCPv6 draft-liu-softwire-lw4over6-dhcp-deployment-01 Abstract Lightweight 4over6 is designed to support several dynamic provisioning protocols. This document discusses how to deploy Lightweight 4over6 using DHCPv4 over DHCPv6 as the provisioning protocol. 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 April 24, 2014. Copyright Notice Copyright (c) 2013 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 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. Liu & Sun Expires April 24, 2014 [Page 1] Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 October 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Deployment Modes Consideration . . . . . . . . . . . . . . . 3 3.1. Dynamic Mode . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Static Mode . . . . . . . . . . . . . . . . . . . . . . . 3 3.3. Summary of the Modes . . . . . . . . . . . . . . . . . . 3 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 4 4.1. General Considerations . . . . . . . . . . . . . . . . . 4 4.2. lwB4 Consideration . . . . . . . . . . . . . . . . . . . 4 4.3. lwAFTR Consideration . . . . . . . . . . . . . . . . . . 5 4.4. Carrying lwB4's IPv6 address . . . . . . . . . . . . . . 5 5. lwAFTR Deployment Models in Dynamic Mode . . . . . . . . . . 5 5.1. Model 1 . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Model 2 . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Model 3 . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Lightweight 4over6 [I-D.ietf-softwire-lw4over6] provides IPv4 access over IPv6 network for hub-and-spoke softwire architecture using IPv4 -in-IPv6 tunneling mechanism. In Lightweight 4over6, Lightweight B4 (lwB4) is assigned with a port-restricted IPv4 address or a full IPv4 address. IPv4 address and port set can be provisioned by several protocols. [I-D.ietf-softwire-lw4over6] recommends to use DHCP-based provisioning mechanism (DHCPv4/DHCPv6). DHCPv4 is based on IPv4 and is unable to work in IPv6 network directly. DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] is a DHCPv4-based mechanism that supports all DHCPv4 functionality and transports DHCPv4 messages using DHCPv6 message. [I-D.ietf-dhc-v4configuration] recommends DHCPv4 over DHCPv6 as the best underlying approach for provisioning IPv4 parameters over an IPv6 only network. Thus, DHCPv4 over DHCPv6 is the recommended IPv4 provisioning mechanism for Lightweight 4over6. This document discusses how to deploy Lightweight 4over6 using DHCPv4 over DHCPv6 as the IPv4 address provisioning protocol. It mainly focus on the deployment scenarios and binding table maintaining issues. Liu & Sun Expires April 24, 2014 [Page 2] Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 October 2013 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. Deployment Modes Consideration Lightweight 4over6 can be deployed in two modes, Dynamic Mode and Static Mode, according to how the binding table in lwAFTR is maintained. This section discusses when and why There are 3 basic elements to serve a lwB4: IPv6 address of lwB4, IPv4 address (and port set) of lwB4, and a binding record in lwAFTR which maps the IPv6 address and IPv4 address (and port set) of lwB4. 3.1. Dynamic Mode In Dynamic Mode, the binding table in lwAFTR is maintained dynamically through address provisioning process. lwB4's IPv6 and IPv4 addresses are decoupled, and lwB4 is free to use any IPv6 address. Due to the lack of IPv4 addresses, IPv4 address (and port set) is provisioned dynamically in a stateful manner. Once an IPv4 address (and port set) is allocated to a lwB4, a binding record is added or updated to the binding table in lwAFTR. 3.2. Static Mode In Static Mode, the binding table in lwAFTR is predetermined and not changed by provisioning process, so the binding record for a lwB4 is generated before address provisioning process. According to the order of IPv6/IPv4 provisioning, there are 2 possible cases: Case 1: lwB4 is provisioned with an IPv4 address (and port set) dynamically. After IPv4 provisioning, lwB4's IPv6 address is determined by its IPv4 address (and port set) and the binding record. Case 2: lwB4 is provisioned with an IPv6 address or IPv6 prefix dynamically. After IPv6 provisioning, lwB4's IPv4 address (and port set) is determined by its IPv6 address/prefix and the binding record statically. 3.3. Summary of the Modes In Dynamic Mode and Case 1 of Static Mode, IPv4 address (and port set) is provisioned to lwB4 in a stateful manner (i.e., provisioned with a lease time). It is natively supported by DHCPv4-based mechanism, so DHCPv4 over DHCPv6 is a suitable solution in these cases. Liu & Sun Expires April 24, 2014 [Page 3] Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 October 2013 In Case 2 of Static Mode, IPv4 address (and port set) is provisioned in a stateless manner. Although it is not the native usage of DHCPv4, DHCPv4 over DHCPv6 can support this case by some simple updates. Besides DHCPv4-based provisioning method, DHCPv6-based method can be used to provision IPv4 address as well. [I-D.ietf-softwire-map-dhcp] defines new DHCPv6 options to support provisioning of IPv4 address and ports. Currently it only supports stateless provisioning, so it can only be used in Case 2 of Static Mode. IPv4 lease time information in necessary for IPv4 stateful provisioning, but to importing IPv4 lease time into DHCPv6 may make it too complicated. 4. Deployment Considerations 4.1. General Considerations In Static Mode, the binding table in lwAFTR is predetermined and is not affected by IPv4 provisioning process. In Dynamic Mode, the binding table is maintained through IPv4 provisioning process, so lwAFTR must be informed about the DHCP provisioning events. There are two methods to support this: (1) DHCP server pushes the changes to lwAFTR, or (2) lwAFTR locates in the path of the DHCP process. In this document, we choose method (2) and require lwAFTR to be co- located with either a DHCP 4o6 Server, or a DHCPv6 relay agent which is on the link from the DHCP client to the 4o6 Server. When lwAFTR is the next-hop of lwB4, it's meaningless to set up IPv4 -in-IPv6 tunnel between lwB4 and lwAFTR, so we ignore this case in this document. 4.2. lwB4 Consideration When deploying Lightweight 4over6 with DHCPv4 over DHCPv6, lwB4 MUST implement DHCPv4 over DHCPv6 client function as is defined in [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. lwB4/DHCPv4-over-DHCPv6 client sends BOOTREQUESTV6 message to either the well-known multicast address or directly to the 4o6 Server's IPv6 address in order to obtain IPv4 address. When lwB4/DHCPv4-over- DHCPv6 client uses multicast to send BOOTREQUESTV6 message, the service provider MUST deploy a DHCPv6 relay agent which is an one-hop neighbor of lwB4 to relay DHCPv6 messages. If the DHCP 4o6 Server is not used as lwB4's DHCPv6 server, the relay agent SHOULD be updated to support the separation of 4o6 Server and DHCPv6 only server as described in section 7 of [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. When lwB4/DHCPv4-over-DHCPv6 client sends BOOTREQUESTV6 message using Liu & Sun Expires April 24, 2014 [Page 4] Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 October 2013 unicast, it MUST obtain the IPv6 address of the DHCP 4o6 Server before the DHCPv4-over-DHCPv6 process. This address SHOULD be conveyed by OPTION_4O6_SERVERS defined in [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. DHCPv4 over DHCPv6 does not prohibit a client without any global IPv6 address to obtain IPv4 address by using multicast. However, the binding table in AFTR can not be updated if the DHCPv4-over-DHCPv6 packet does not contain lwB4's global IPv6 address, so lwB4 must obtain global IPv6 address before it starts DHCPv4-over-DHCPv6 process. 4.3. lwAFTR Consideration When a lwAFTR is co-located with DHCP 4o6 Server or DHCPv6 relay agent, it MUST examine all DHCPv6 messages it received and extract the DHCPv4 message from the BOOTP Message Option in each BOOTREQUESTV6 and BOOTREPLYV6 message. When the DHCPv6 message is a BOOTREPLYV6 message and DHCPv4 message is a DHCPACK message, lwAFTR uses the IPv4 address and port set in the DHCPACK message and the global IPv6 address of lwB4 to create a new record in the binding table or update an existing record. When the DHCPv6 message is a BOOTREQUESTV6 message and DHCPv4 message is a DHCPRELEASE message, lwAFTR uses the IPv4 address and port set in the DHCPRELEASE message and the global IPv6 address of lwB4 to remove record(s) in the binding table. 4.4. Carrying lwB4's IPv6 address The lwB4 is expected to send the BOOTREQUESTV6 message using the lwB4's global IPv6 address, so that lwAFTR can update the binding table with this information. When lwB4 sends BOOTREQUESTV6 message by unicast, the source address of the packet can be used as the client's global IPv6 address. However, this can not be achieved when lwB4 sends BOOTREQUESTV6 message by multicast because Section 16 of [RFC3315] defines that the DHCP client must use a link-local address when using multicast. There are two possible solutions for this problem: (1) force lwB4/ DHCPv4-over-DHCPv6 client not to use multicast, or (2) Put a DHCPv6 option which contains the global IPv6 address of lwB4 into the BOOTREQUESTV6 message. We recommend solution (2) as the address carrying method to fit more deployment scenarios. The DHCPv6 option to be used may be an existing option or a new defined option. Liu & Sun Expires April 24, 2014 [Page 5] Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 October 2013 5. lwAFTR Deployment Models in Dynamic Mode As discussed in Section 4.1, in Dynamic Mode lwAFTR is required to be located in the path of the DHCP process. Therefor there are 3 possible models of the deployment of lwAFTR: Model 1: lwAFTR is co-located with DHCP 4o6 Server as well as the DHCPv4 server engine of the 4o6 Server Model 2: lwAFTR is co-located with DHCPv6 relay agent Model 3: lwAFTR is co-located with DHCP 4o6 Server's v6 part, and the DHCPv4 server engine is a separate device When a service provider deploys multiple lwAFTRs, he may have the requirement of sharing one DHCP 4o6 server among multiple lwAFTRs. Model 2 and Model 3 supports this usage. 5.1. Model 1 In Model 1, lwAFTR is co-located with a complete DHCP 4o6 Server. Figure 1 illustrates the architecture of this model. The lwB4, as a DHCP client, can send the BOOTREQUESTV6 message using multicast as is described in [RFC3315]. The packets may be relayed toward the lwAFTR/4o6 Server. When lwB4 uses unicast to send BOOTREQUESTV6 message, it employs the IPv6 address conveyed through the 4o6 Servers Address Option [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. The IPv6 address is that of the lwAFTR/4o6 Server. +-------------+ | DHCPv6 | | Relay Agent | | (optional) | +------+------+ +----------+ | +----------+ +----------+ | lwB4/ | | | lwAFTR/ | | IPv4 | | DHCP +------+-----------------+ 4o6 +---+ Internet | | Client | IPv4-in-IPv6 tunnel | Server | | | +----------+ +----------+ +----------+ Figure 1: Model 1 5.2. Model 2 Liu & Sun Expires April 24, 2014 [Page 6] Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 October 2013 In Model 2, lwAFTR is co-located with a DHCPv6 relay agent. It is configured with the 4o6 Server's IPv6 address as the destination address. Figure 2 illustrates the architecture of this model. When lwB4 uses multicast to send BOOTREQUESTV6 message, the one-hop neighbor relay agent is configured with the IPv6 address of the lwAFTR/relay agent and relays DHCPv4-over-DHCPv6 packages to lwAFTR/ relay agent. When lwB4 uses unicast to send BOOTREQUESTV6 message, the destination address it obtains is the lwAFTR's/relay agent's IPv6 address. +-------------+ | DHCPv6 | | Relay Agent | | (optional) | +------+------+ +----------+ | +-------------+ +----------+ | lwB4/ | | | lwAFTR/ | | IPv4 | | DHCP +------+-----------------+ DHCPv6 +---+ Internet | | Client | IPv4-in-IPv6 tunnel | Relay Agent | | | +----------+ +------+------+ +----------+ | +----+-----+ | 4o6 | | Server | +----------+ Figure 2: Model 2 5.3. Model 3 In Model 3, lwAFTR is co-located with a DHCP 4o6 Server, but the DHCPv4 server engine of the 4o6 Server is a separate device. Figure 3 illustrates the architecture of this model. The behavior of lwB4 and one-hop neighbor relay agent is the same as that in Model 1. Section 8 of [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes that the DHCPv4 server engine can be a separate DHCPv4 server instance, but does not provide how to implement that and how a 4o6 Server communicates with the engine. In this model we suggest the DHCPv4 server engine to be a regular standalone DHCPv4 server. Liu & Sun Expires April 24, 2014 [Page 7] Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 October 2013 +-------------+ | DHCPv6 | | Relay Agent | | (optional) | +------+------+ +----------+ | +-------------+ +----------+ | lwB4/ | | | lwAFTR/ | | IPv4 | | DHCP +------+-----------------+ 4o6 +---+ Internet | | Client | IPv4-in-IPv6 tunnel | Server | | | +----------+ | (v6) | +----------+ +------+------+ | +--------+--------+ | 4o6 | | Server | | (DHCPv4 engine) | +-----------------+ Figure 3: Model 3 6. Security Considerations TBD 7. IANA Considerations This document does not include an IANA request. 8. References 8.1. Normative References [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-02 (work in progress), October 2013. [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-01 (work in progress), July 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. Liu & Sun Expires April 24, 2014 [Page 8] Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 October 2013 8.2. Informative References [I-D.ietf-dhc-v4configuration] Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration Over IPv6 Only Networks", draft-ietf-dhc- v4configuration-02 (work in progress), September 2013. [I-D.ietf-softwire-map-dhcp] Mrugalski, T., Troan, O., 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-05 (work in progress), October 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 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 Liu & Sun Expires April 24, 2014 [Page 9]