Internet Engineering Task Force T. Baldwin Internet-Draft May 29, 2010 Intended status: Standards Track Expires: November 30, 2010 Anycast DHCPv4 draft-baldwin-dhc-softwire-anycast-dhcp-00 Abstract This document specifies a anycast address for DHCP servers and extensions to DHCP to allow NAT transversal. This will allow a host on a typical residential LAN to obtain information from one of a service provider's DHCP servers. 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 30, 2010. Copyright Notice Copyright (c) 2010 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. Baldwin Expires November 30, 2010 [Page 1] Internet-Draft Anycast DHCPv4 May 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 3. DHCPv4 anycast address . . . . . . . . . . . . . . . . . . . . 3 4. Anycast DHCP control DHCP option . . . . . . . . . . . . . . . 3 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4 6. Relay Agents . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Baldwin Expires November 30, 2010 [Page 2] Internet-Draft Anycast DHCPv4 May 2010 1. Introduction In IPv4 broadband deployments it is common practice for a customer's hosts to be connected via an IPv4 NAT router which acts a DHCP [RFC2131] server for the customer's LAN. It is often infeasible to configure the DHCP server function to provide additional configuration information such as the remote endpoint of an IPv6 tunnel. Typical deployment scenario +--------+ +------------+ +----------+ | DHCP | | IPv4 CPE | | Customer | | Server |----+----| NAT/Router |---------| PC | +--------+ | +------------+ +----------+ | +--------+ | | Tunnel |----+ | Server | +--------+ Anycast DHCP solves this problem by allowing the hosts to directly contact a service providers DHCP servers. It is intended to supplement existing means of configuration, and is carried out after configuration of an IPv4 address. 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 RFC 2119 [RFC2119]. 3. DHCPv4 anycast address The value of this address is 192.0.0.TBD1. It SHOULD NOT advertised in BGP or an IGP beyond the edge of any organisations network, except as aggregated in a default route. 4. Anycast DHCP control DHCP option Unless a node has been manually configured to use or not to use Anycast DHCP it MUST request and obey the following option. Baldwin Expires November 30, 2010 [Page 3] Internet-Draft Anycast DHCPv4 May 2010 Code Len Value +------+-----+-----+ | TBD2 | 1 | X | +------+-----+-----+ If X = 0 then Anycast DHCP MUST NOT be used. If X = 2, then Anycast DHCP MUST be used. If the option is not present or X = 1 then Anycast DHCP should be used unless the node can determine it is managed. Due care MUST be taken to avoid problems caused by IPv4 DNS servers which fail to respond correctly to AAAA queries. [RFC4074] 5. Protocol Description The client obtains configuration information using DHCP as normal. After configuring IPv4 connectivity The client sends a DHCPINFORM message to 192.0.0.TBD1, UDP port 67. It SHOULD select an ephemeral source port and MUST NOT use port 67 or port 68 as a source port. The client should use a retransmission strategy. The server responds with a DHCPACK message. The yiaddr field of the response MUST contain the IPv4 address of the client as seen in the domain in which the provided configuration information is valid, for example the 6RD [I-D.ietf-softwire-ipv6-6rd] DHCP option. This will typically be the client's address seen by the DHCP server. 6. Relay Agents A modified relay agent can be used with an unmodified DHCP server. Upon receiving a DHCPINFORM message addressed to the anycast address the relay agent sets the chaddr field of the message to the source IPv4 address and port of the message and the htype field to TBD3, then forwards the message to the DHCP server. When the reply is received back from the DHCP server the client IPv4 address is copied from the chaddr field to the yiaddr field, then the message is forwarded to the IPv4 address and UDP port contained in hwaddr field of the message. Baldwin Expires November 30, 2010 [Page 4] Internet-Draft Anycast DHCPv4 May 2010 Format of chaddr field 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client IPv4 Address | +-------------------------------+-------------------------------+ | Port Number | Padding | +-------------------------------+-------------------------------+ | Padding | +---------------------------------------------------------------+ | Padding | +---------------------------------------------------------------+ 7. IANA Considerations IANA is requested to allocate a IPv4 address from the IPv4 special purpose address registry (TBD1), a DHCP option (TBD2), and an 8-bit ARP hardware type value (TBD3). 8. Security Considerations If Anycast DHCP is enabled by default the node could obtain global IPv6 connectivity by means of a tunnel without the knowledge of the administrator, and therefore have an inappropriate security policy. If Anycast DHCP is included in an automatic update this risk is even greater, and nodes SHOULD NOT except incoming IPv6 connections via tunnels configured by Anycast DHCP by default unless global connectivity is explicitly requested. If the Anycast DHCP address is not filtered at the edge of service providers network, a third party could provide malicious configuration and thereby intercept all IPv6 traffic from the client. A malicious server could provide an invalid configuration. 9. References 9.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. Baldwin Expires November 30, 2010 [Page 5] Internet-Draft Anycast DHCPv4 May 2010 9.2. Informative References [I-D.ietf-softwire-ipv6-6rd] Townsley, M. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", draft-ietf-softwire-ipv6-6rd-10 (work in progress), May 2010. [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS Queries for IPv6 Addresses", RFC 4074, May 2005. Author's Address Timothy Baldwin Email: T.E.Baldwin99@members.leeds.ac.uk Baldwin Expires November 30, 2010 [Page 6]