Network Working Group C. Liu Internet-Draft Q. Sun Intended status: Informational Tsinghua University Expires: January 16, 2014 July 15, 2013 Lightweight 4over6 deployment with DHCPv4 over DHCPv6 draft-liu-softwire-lw4over6-dhcp-deployment-00 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 January 16, 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 January 16, 2014 [Page 1] Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 July 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Deployment Considerations . . . . . . . . . . . . . . . . . . 2 3.1. lwB4 Consideration . . . . . . . . . . . . . . . . . . . 3 3.2. lwAFTR Consideration . . . . . . . . . . . . . . . . . . 3 4. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Model 1 . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Model 2 . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.3. Model 3 . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Carrying lwB4's IPv6 address . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Lightweight 4over6 [I-D.ietf-softwire-lw4over6] is a mechanism which 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 a port-restricted IPv4 address or a full IPv4 address by using dynamic IPv4 address provisioning protocol or static configuration. Lightweight AFTR (lwAFTR) maintains per subscriber binding consisting of the lwB4's IPv6 address and its assigned IPv4 address and port set. The binding table is synchronized with the IPv4 address provisioning process. DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] defines two new DHCPv6 messages for IPv4 configuration across IPv6 networks: BOOTREQUESTV6 and BOOTREPLYV6. DHCPv4 messages are put into BOOTP Message Option using the two new DHCPv6 messages for transportation. 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. 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 Considerations When deploying Lightweight 4over6 with DHCPv4 over DHCPv6, DHCPv4 over DHCPv6 client function is implemented on the lwB4. lwB4/DHCPv4 -over-DHCPv6 client sends BOOTREQUESTV6 message to either the well- Liu & Sun Expires January 16, 2014 [Page 2] Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 July 2013 known multicast or directly to the 4o6 Server's IPv6 address in order to obtain IPv4 address. In this document, we assume lwAFTR maintains the binding table dynamically through DHCP process. This means that lwAFTR is 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. 3.1. lwB4 Consideration When lwB4/DHCPv4-over-DHCPv6 client uses multicast to send BOOTREQUESTV6 message, the service provider deploys a DHCPv6 relay agent which is an one-hop neighbour 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 unicast, it needs to obtain the IPv6 address of the DHCP 4o6 Server before the DHCPv4-over-DHCPv6 process. This address is 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. Section 5 of this document discusses how to carry lwB4's global IPv6 address in BOOTREQUESTV6 message. 3.2. lwAFTR Consideration No matter whether the lwAFTR works as a DHCPv6 relay or a DHCP 4o6 Server, it has to extract the DHCPv4 message from the BOOTP Message Option. lwAFTR uses the information and the global IPv6 address to update the binding table. Section 5 of this document discusses how to get the global IPv6 address of lwB4. 4. Deployment Models There are 3 possible models of the deployment of lwAFTR: Model 1: lwAFTR is co-located with DHCP 4o6 Server as well as the Liu & Sun Expires January 16, 2014 [Page 3] Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 July 2013 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. 4.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 4.2. Model 2 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 neighbour relay agent is configured with the IPv6 address of the Liu & Sun Expires January 16, 2014 [Page 4] Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 July 2013 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. //We are not sure whether a DHCPv6 client should send messages directly to a relay agent or not. +-------------+ | DHCPv6 | | Relay Agent | | (optional) | +------+------+ +----------+ | +-------------+ +----------+ | lwB4/ | | | lwAFTR/ | | IPv4 | | DHCP +------+-----------------+ DHCPv6 +---+ Internet | | Client | IPv4-in-IPv6 tunnel | Relay Agent | | | +----------+ +------+------+ +----------+ | +----+-----+ | 4o6 | | Server | +----------+ Figure 2: Model 2 4.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 neighbour 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 does a 4o6 Server communicate with the engine. In this model we suggest the DHCPv4 server engine to be a regular standalone DHCPv4 server. Liu & Sun Expires January 16, 2014 [Page 5] Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 July 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 5. 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. 6. Security Considerations TBD 7. Normative References [I-D.ietf-dhc-dhcpv4-over-dhcpv6] Liu & Sun Expires January 16, 2014 [Page 6] Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 July 2013 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- dhcpv4-over-dhcpv6-00 (work in progress), April 2013. [I-D.ietf-softwire-lw4over6] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the DS-Lite Architecture", draft-ietf-softwire-lw4over6-00 (work in progress), April 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. 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 January 16, 2014 [Page 7]