Network Working Group Y. Cui Internet-Draft P. Wu Intended status: Standards Track J. Wu Expires: November 19, 2012 Tsinghua University T. Lemon Nominum, Inc. May 18, 2012 DHCPv4 over IPv6 Transport draft-ietf-dhc-dhcpv4-over-ipv6-03 Abstract In IPv6 networks, there remains a need to provide IPv4 service for some residual devices. This document describes a mechanism for allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6 transport. It is done by putting a special relay agent function (Client Relay Agent) on the client side, as well as extending the behavior of the server; in the case where DHCP server only supports IPv4 transport, a relay agent is extended to support IPv6 transport (IPv6-Transport Relay Agent) and relay DHCP traffic for the server, with a new Relay Agent Information sub-option added to carry the IPv6 address of the Client Relay Agent. 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 November 19, 2012. Copyright Notice Copyright (c) 2012 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 Cui, et al. Expires November 19, 2012 [Page 1] Internet-Draft DHCPv4 over IPv6 May 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 4 5. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . . 6 6. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . 7 7. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 8 8. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . 8 9. Security Consideration . . . . . . . . . . . . . . . . . . . . 9 10. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. Appendix: Discussion on One Host Retrieving Multiple Addresses through One CRA . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 13.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Cui, et al. Expires November 19, 2012 [Page 2] Internet-Draft DHCPv4 over IPv6 May 2012 1. Introduction DHCPv4 [RFC2131] was not designed with IPv6 in mind: DHCPv4 cannot operate on an IPv6 network. However, as dual-stack networks become a reality, the need arises to allocate IPv4 addresses in an IPv6 environment. To meet this demand, this document extends the DHCPv4 protocol to allow the use of an IPv6 network for transport. A typical scenario that probably requires this feature is IPv4-over- IPv6 hub and spoke tunnel [RFC4925]. In this scenario, IPv4-over- IPv6 tunnel is used to provide IPv4 connectivity to end users (hosts or end networks) across an IPv6 network. If the IPv4 addresses of the end users are provisioned by the concentrator side, then the provisioning process should be able to cross the IPv6 network. One such tunnel mechanism is demonstrated in [I-D.ietf-softwire-public-4over6]. DHCPv4 over IPv6 would be a generic solution for this scenario. Three main flavors of solutions may be considered: o Use DHCPv6 instead of DHCPv4, to provision IPv4-related connectivity. In DHCPv6, the provisioned IPv4 address can be embedded into IPv6 address, or carried within a new option. Along with that, dedicated options are needed to convey IPv4-related information, such as the IPv4 address of DNS server, NTP server, etc. Therefore it will put a certain amount of IPv6-unrelated information into DHCPv6 protocol. o Use DHCPv4 and tunnel DHCPv4-in-IPv4 messages over IPv6. Unlike the previous approach where DHCPv6 is used for both IPv4 and IPv6 connectivity, this approach consists in preserving the separation between IPv4 and IPv6 connectivity information. It allows to maintain the IPv4 service without major modification of IPv6- related provisioning resources, and sustains DHCPv4 to be the IPv4-related information carrier. However, this approach enforces an IPv4-in-IPv6 tunnel on DHCP, and subsequently requires extra efforts to maintain tunnel endpoint information for encapsulation use. o Use DHCPv4 and extend it to work on IPv6 transport. Instead of relying on IPv4-in-IPv6 tunnel, this flavor uses IPv6 directly for DHCP message transport, and it keeps the advantage of separation with IPv6 connectivity information. This document focuses on this flavor. The document defines the behavior of extended DHCPv4 components, as well as a new sub-option of the Relay Agent Information Option, to support DHCPv4 over IPv6. Cui, et al. Expires November 19, 2012 [Page 3] Internet-Draft DHCPv4 over IPv6 May 2012 2. 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 [RFC2119]. 3. Terminology This document makes use of the following terms: o DHCPv4: IPv4 Dynamic Host Configuration Protocol [RFC2131]. o Client Relay Agent(CRA): a special DHCPv4 Relay Agent which works as a "proxy" between DHCPv4 client and the IPv6 network by converting between IPv4 transport and IPv6 transport. A CRA either sits on the same, IPv6-accessable host with the DHCPv4 client, or sits on the same link with the host. o Host Client Relay Agent(HCRA): a CRA which sits on the same, IPv6- accessible host with the DHCPv4 client. o On-Link Client Relay Agent(LCRA): a CRA which sits on the same link with the host that runs DHCPv4 client. o IPv6-Transport Server(TSV): a DHCPv4 Server that supports IPv6 transport. TSV listens on IPv6 for incoming DHCPv4 messages, and sends DHCPv4 messages in IPv6 packets. o IPv6-Transport Relay Agent(TRA): a DHCPv4 Relay Agent that supports IPv6 transport. TRA sits on a machine which has both IPv6 and IPv4 connectivity, and relays DHCP messages between CRA and regular DHCPv4 server. Unlike CRA, TRA sits on the remote end of IPv6 network, and communicates with DHCPv4 server through IPv4. o Client Relay Agent IPv6 Address Sub-option(CRA6ADDR sub-option): a new sub-option of DHCP Relay Agent Information Option [RFC3046] defined in this document. CRA6ADDR sub-option is used by TRA to carry the IPv6 address of a CRA. 4. Protocol Summary The scenario for DHCPv4 over IPv6 transport is shown in Figure 1. DHCPv4 clients and DHCPv4 server/relay are separated by an IPv6 network in the middle. DHCP messages between a client and the server/relay cannot naturally be forwarded to each other because they are by default IPv4 UDP packets, either unicast or broadcast. To Cui, et al. Expires November 19, 2012 [Page 4] Internet-Draft DHCPv4 over IPv6 May 2012 bridge this gap, both the client side and the server/relay side should enable DHCPv4 over IPv6 transport. More precisely, they should support delivering and receiving DHCP messages in IPv6 UDP packets and thereby traverse the IPv6 network. On the client side, a special relay agent called Client Relay Agent is placed on the same host with the client, or on the link of the host. CRA is used to relay DHCP messages from the client to the server, and from the server to the client. CRA sends DHCPv4 messages to the server through unicast IPv6 UDP, and receives unicast IPv6 UDP packets with the DHCPv4 messages from the server. By using CRA, no extension is required on the DHCP client. +-------------------------+ +------+ | |DHCPv4| | |Client| +-------+ +------+ |DHCPv4 | | IPv6 Network |Server/| +------+ |Relay | |DHCPv4| +-------+ |Client| | +------+ | +-------------------------+ Figure 1 Scenario of DHCPv4 over IPv6 Transport The IPv6-Transport DHCPv4 server can receive DHCP messages delivered in IPv6 UDP from CRA, and send out DHCP messages to CRA using IPv6 UDP (figure 2(a)). TSV should send DHCP messages to the IPv6 address from which it receives relevant DHCP messages earlier. When CRAs communicate with an IPv6-Transport Relay Agent rather than with a server directly, the situation will become a little more complicated. Besides the IPv6 communication with CRA, TRA also communicates with a regular DHCPv4 server through IPv4. Therefore, when TRA relays DHCP messages between a CRA and the DHCPv4 server, it receives DHCP message from the CRA in IPv6 and sends it to the server in IPv4, as well as receives DHCP message from the server in IPv4 and sends it to the CRA in IPv6. TRA has to use the DHCP Relay Agent Information Option (Option code 82) to record the IPv6 address of the CRA, which will be used as forwarding destination when relaying a DHCP message from the server. Since Option 82 doesn't have an existing sub-option that fits in the case, this document defines a new Client Relay Agent IPv6 Address Sub-option. The DHCPv4 server MUST support the new sub-option in this case. Cui, et al. Expires November 19, 2012 [Page 5] Internet-Draft DHCPv4 over IPv6 May 2012 +------+ +------+ |client| IPv6 network |TSV | |+HCRA |----------------| | +------+ +------+ +------+ +------+ +------+ |client| |LCRA | IPv6 network |TSV | | |--| |----------------| | +------+ +------+ +------+ (a)client--server case +------+ +------+ +------+ |client| IPv6 network |TRA | IPv4 network |server| |+HCRA |----------------| |--------------| | +------+ +------+ +------+ +------+ +------+ +------+ +------+ |client| |LCRA | IPv6 network |TRA | IPv4 network |server| | |--| |----------------| |--------------| | +------+ +------+ +------+ +------+ (b)client--relay--server case Figure 2 Protocol Summary 5. Client Relay Agent IPv6 Address Sub-option This sub-option MUST be added by a DHCPv4 TRA. It encodes the IPv6 address of the machine from which a DHCPv4-in-IPv6 CRA-to-TRA message was received. It is intended for the TRA to relay DHCPv4 replies back to the proper CRA. To be more specific, the TRA uses the IPv6 address encoded in this sub-option as the destination IPv6 address when relaying a DHCPv4 reply to IPv6 network. The CRA IPv6 address MUST be unique in the IPv6 domain. The CRA6ADDR sub-option has a fixed length of 18 octets. The SubOpt code is tbd by IANA, the length field is 16, and the following 16 octets contain the CRA IPv6 address. DHCP servers handle it following the standard option 82 procedure defined in [RFC3046]. DHCP servers MAY use this sub-option to select parameters specific to particular hosts. Servers MAY parse this sub- option and extract the IPv6 address. Cui, et al. Expires November 19, 2012 [Page 6] Internet-Draft DHCPv4 over IPv6 May 2012 SubOpt Len Agent Remote ID +------+------+------+------+------+- -+------+ | tbd | 16 | a1 | a2 | a3 | ... | a16 | +------+------+------+------+------+- -+------+ Figure 3 Client Relay Agent IPv6 Address Sub-option format 6. Client Relay Agent Behavior A Client Relay Agent sits on the same host with the DHCPv4 client (HCRA), or on the link of the host (LCRA). CRA is a special type of relay agent, which relays DHCPv4 messages between regular client and TSV/TRA. The communication between CRA and the client happens inside the last-hop local network using IPv4, and the communication between CRA and TSV/TRA happens on the IPv6 network using IPv6. A CRA is configured with one or more IPv6 addresses of TSV/TRA. This configuration is provided before DHCPv4 process, for example through DHCPv6 option, or by some other mechanisms depending on the application scenarios. A CRA listens for DHCP messages on IPv4 UDP port 67. When it receives from IPv4 any DHCP message with bootp op field = 1, it forwards the message using the standard DHCP relay agent format, but over UDPv6, with source port 67 and destination port 67. The CRA forwards the message to each of the TSV or TRA with which it is configured. The CRA SHOULD use a global IPv6 address if it has one. A CRA also listens for DHCP messages on IPv6 UDP port 68. When it receives from IPv6 any DHCP message with bootp op field = 2, the CRA checks to see if the message contains option 82, and if so, it discards the message. Otherwise, it delivers the message to the DHCP client using IPv4. The basic functionality of HCRA and LCRA are the same. The difference is that, when relaying DHCP messages, the HCRA MUST NOT include an option 82 or modify the giaddr field of the DHCP message, while in the LCRA case, it SHOULD NOT include an option 82 or modify the giaddr of DHCP message. If it has to, [I-D.ietf-dhc-dhcpv4-relay-encapsulation] can be used as the solution to the coexistence of LCRA and TRA. A HCRA MUST only serve the client inside the same host, while the LCRA SHOULD serve any client on the link. When the IPv6 address of TSV/TRA is provisioned to the DHCP client, it uses HCRA; else the client depends on LCRA. A HCRA serves only one link; the multiple Cui, et al. Expires November 19, 2012 [Page 7] Internet-Draft DHCPv4 over IPv6 May 2012 link case MUST be handled by multiple HCRA instances. A LCRA does not necessarily need an IPv4 address, though it may be configured with one. 7. IPv6-Transport Server Behavior To support IPv6 transport, the behavior of DHCPv4 server is extended. The IPv6-Transport Server can listen on IPv6 port 67 for DHCPv4 messages, and send DHCPv4 messages through IPv6. A TSV listens for DHCP messages on IPv6 UDP port 67. When it receives from IPv6 a DHCP message, it MUST record the IPv6 source address of that message and retain it as the return address of the message. That is to say, when sometime later the TSV responds to this message, it MUST send the reply message to the IPv6 return address retained earlier, with destination port 68. When filling in the server id option of DHCP replies, the TSV MUST choose an IPv4 address which is reachable from the client once the residual IPv4 service is set up. This follows the server id option requirement in [RFC2131]. The rest of TSV DHCP process is the same with normal DHCPv4 server. A TSV MAY also listen on IPv4 UDP port 67 like a normal DHCPv4 server, and process normally when receives IPv4 DHCPv4 message. This document places no new requirements on DHCPv4 servers that do not listen on UDPv6 (other than to support the CRA6ADDR sub-option)--in order to use an IPv4-only DHCPv4 server through an IPv6 connection, a TRA is required. 8. IPv6-Transport Relay Agent Behavior An IPv6-Transport Relay Agent sits between IPv6 network and IPv4 network, and relays DHCPv4 message between CRAs and IPv4-only DHCPv4 server. The communication between CRAs and the TRA uses IPv6, while the communication between the TRA and the server uses IPv4. A TRA listens on IPv6 UDP port 67 for DHCP messages with bootp op field = 1, as well as IPv4 UDP port 68 for DHCP messages with bootp op field = 2. When relaying a DHCP message from CRA to server, TRA MUST add an option 82 with a CRA6ADDR sub-option. This sub-option contains the IPv6 source address of the message (the CRA's IPv6 address) which is retained when the message is received in IPv6. The TRA MUST also store the IPv4 address of itself in the giaddr field of the DHCP message. The TRA MAY include a Link Selection sub-option [RFC3527] to indicate to the DHCP server which link to use when choosing an IP Cui, et al. Expires November 19, 2012 [Page 8] Internet-Draft DHCPv4 over IPv6 May 2012 address. When receiving a DHCP message from the DHCP server, if the option 82 in the message contains no CRA6ADDR sub-option, the TRA MUST discard the message. Otherwise, it processes it as required by [RFC3046], and forwards it to the IPv6 address recorded in the CRA6ADDR sub- option, with source port 67 and destination port number 68. TRA SHOULD drop DHCPv4-over-IPv6 traffic that is not originated from configured server address. 9. Security Consideration This mechanism may rise a new form of DHCP protocol attack. A malicious attacker in IPv6 can interference with the DHCPv4 process by inject fake DHCPv4-in-IPv6 messages which will be handled by TSV or TRA. However, the damage is the same with the known DHCPv4 attack happened in IPv4. The only difference is the attacker and the victim could locate in different address families. Another impact is DHCP filtering. There are firewalls today capable of filtering DHCP traffic (DHCPv4 over IPv4 and DHCPv6 over IPv6 packages). The DHCP messages with the new, DHCPv4-in-IPv6 style may bypass these firewalls. Nevertheless it is not difficult for them to make some slight modification and adapt to the new DHCPv4 message pattern. 10. IANA consideration IANA is requested to assign one new sub-option code from the registry of DHCP Agent Sub-Option Codes maintained in http://www.iana.org/assignments/bootp-dhcp-parameters. This sub- option code will be assigned to the Client Relay Agent IPv6 Address Sub-option. 11. Contributors The following gentlemen also contributed to the effort: Francis Dupont Internet Systems Consortium, Inc. Email: fdupont@isc.org Cui, et al. Expires November 19, 2012 [Page 9] Internet-Draft DHCPv4 over IPv6 May 2012 Tomasz Mrugalski Internet Systems Consortium, Inc. Email: tomasz.mrugalski@gmail.com Dmitry Anipko Microsoft Corporation Email: danipko@microsoft.com 12. Appendix: Discussion on One Host Retrieving Multiple Addresses through One CRA This document is written with the intention of supporting a use case where a single DHCP client is configuring a single tunnel endpoint per physical link. The technique described in this document could be used by a host needing to configure more than one tunnel endpoint on the same physical link, i.e., to retrieve multiple addresses through the same CRA. However, the following additional behavior is REQUIRED to support this case. DHCP server implementing this specification MUST implement Client Identifier Option in DHCP server replies [I-D.ietf-dhc-client-id]. In general this specification is intended not to require modification of DHCP clients. However, DHCP clients being used to configure multiple tunnel endpoints have to be modified; otherwise there is no way for such DHCP clients to differentiate between DHCP responses. Therefore, in such case, the DHCP client using this specification MUST use a different client identifier for each tunnel endpoint being configured. Such DHCP clients MUST examine the response from the DHCP server and use the client identifier to differentiate between the DHCP client state machines for each tunnel endpoint. In order to satisfy the requirement that client identifiers be unique, DHCP clients configuring multiple tunnel endpoints MUST implement Node-specific Client Identifiers for DHCPv4 [RFC4361]. Such clients MUST use a different IAID for each tunnel endpoint. It is assumed here that every client state machine on a multiple- tunnel-endpoint link can hear all the DHCP messages (and subsequently accept the messages intended for it). How this is accomplished is left to the implementor. However, implementations MUST follow this requirement; otherwise, it will be impossible for multiple tunnel endpoints to be successfully configured. The easiest way to Cui, et al. Expires November 19, 2012 [Page 10] Internet-Draft DHCPv4 over IPv6 May 2012 accomplish this is to have a single DHCP client process with multiple DHCP state machines, and to dispatch each DHCP message to the correct DHCP client state machine using the client identifier. However, this is not REQUIRED; any mechanism that results in client state machines receiving the messages that are intended for them will suffice. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, "Link Selection sub-option for the Relay Agent Information Option for DHCPv4", RFC 3527, April 2003. [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006. [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007. 13.2. Informative References [I-D.ietf-dhc-client-id] Swamy, N., Halwasia, G., and S. Unit, "Client Identifier Option in DHCP Server Replies", draft-ietf-dhc-client-id-02 (work in progress), March 2012. [I-D.ietf-dhc-dhcpv4-relay-encapsulation] Lemon, T., Deng, H., and L. Huang, "Relay Agent Encapsulation for DHCPv4", draft-ietf-dhc-dhcpv4-relay-encapsulation-01 (work in progress), July 2011. [I-D.ietf-softwire-public-4over6] Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y. Lee, "Public IPv4 over IPv6 Access Network", Cui, et al. Expires November 19, 2012 [Page 11] Internet-Draft DHCPv4 over IPv6 May 2012 draft-ietf-softwire-public-4over6-01 (work in progress), March 2012. Authors' Addresses Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6260-3059 Email: yong@csnet1.cs.tsinghua.edu.cn Peng Wu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: pengwu.thu@gmail.com 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 Ted Lemon Nominum, Inc. 2000 Seaport Blvd Redwood City 94063 USA Phone: +1-650-381-6000 Email: mellon@nominum.com Cui, et al. Expires November 19, 2012 [Page 12]