Network working group X. Xu Internet Draft D. Guo Category: Standard Track Huawei Technologies Expires: February 2011 August 24, 2010 IPv6 Host Configuration in 6rd draft-guo-softwire-6rd-ipv6-config-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 24, 2011. 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. Xu, et al. Expires February 24, 2011 [Page 1] Internet-Draft IPv6 Host Configuration in 6rd August 2010 Abstract This document proposes a new DHCPv4 option containing the addresses of DHCPv6 servers through which the 6rd CPE could obtain the IPv6 addresses of DHCPv6 servers. Thus, the 6rd CPE as a DHCP relay agent could relay DHCP messages from IPv6 hosts which is located in 6rd home networks to one of the known DHCPv6 servers. Conventions used in this document 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]. Table of Contents 1. Introduction.................................................3 2. DHCPv6 Server Option in DHCPv4...............................4 3. DHCPv6 Deployment in 6rd.....................................4 4. Security Considerations......................................5 5. IANA Considerations..........................................5 6. Acknowledgements.............................................5 7. References...................................................5 7.1. Normative References....................................5 7.2. Informative References..................................6 Authors' Addresses..............................................6 Xu, et al. Expires February 24, 2011 [Page 2] Internet-Draft IPv6 Host Configuration in 6rd August 2010 1. Introduction IPv6 rapid deployment on IPv4 infrastructures (6rd) [RFC5969] enables a service provider to rapidly deploy IPv6 unicast service to customer sites via its IPv4 network. Besides IPv6 addresses, IPv6-only hosts in residential sites may also need to obtain other configuration information (e.g., DNS servers, NTP servers or SIP servers etc.). DNS Proxy [RFC5625]is a mature mechanism but only for DNS configuration. However, stateless DHCPv6 [RFC3736] is a standard approach for obtaining other configuration information besides DNS. As stated in the DHCPv6 specification [RFC3315], "...The client MUST use a link-local address assigned to the interface for which it is requesting configuration information as the source address in the header of the IP datagram." Since the link-local address can not travel through the 6rd domain, the CPE SHOULD act as a DHCPv6 relay agent. However, relaying DHCP request messages destined for All_DHCP_Relay_Agent_and_Servers multicast address is not optimal in 6rd scenario since the only available way of forwarding this multicast message in 6rd is to tunnel it to a BR. If a 6rd SP deployed multiple BRs for load-balancing purpose, each BR SHOULD be configured either as a DHCP server or as a DHCP relay agent. In addition, in case that the DHCP server/relay on a given BR is unavailable due to some reason but the other functions on it (e.g., the route towards its anycast address) are still available, once the DHCP message is tunneled to that BR, the DHCP service is not available any more. Since the DHCP information-request can not be relayed to other DHCP servers/relays, it's impossible to achieve high availability for DHCP servers/relay agents. As an alternative, if the CPE as a DHCP relay agent has already known at least one DHCPv6 server address, the CPE could send the DHCP relay-forward message to one of the learnt DHCP server in unicast. Since 6rd can support unicast in a much flexible way, the DHCP server can be located either on/behind any BR or behind a 6rd CPE which is owned by the 6rd SP. Since 6rd CPEs derive the 6rd prefix from a new DHCPv4 option according to [RFC5969], the DHCPv6 server addresses can be learnt in a much similar way (i.e., via a new DHCPv4 option). Details about this new DHCPv4 option and the related procedure of running DHCPv6 in 6rd are described in Section 2 and 3, respectively. Xu, et al. Expires February 24, 2011 [Page 3] Internet-Draft IPv6 Host Configuration in 6rd August 2010 2. DHCPv6 Server Option in DHCPv4 The DHCPv6 Server Option is shown in Figure 1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPT_DHCPv6 | option-length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | IPv6 Address(es) of DHCPv6 Server(s) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: DHCPv6 Server Option Format Fields: OPT_DHCPv6 TBD. option-length The length of the DHCP option in octets. IPv6 Address(es) of DHCPv6 Server(s) One or more 128-bit IPv6 addresses of the DHCPv6 servers. 3. DHCPv6 Deployment in 6rd The DHCPv6 server is deployed in an IPv6 network, DHCPv6 messages MUST pass through IPv4 network with 6rd encapsulation. IPv6 hosts behind the 6rd CPE SHOULD follow procedure depicted in Figure 2 when they use DHCPv6 to obtain configuration information: (1) The 6rd CPE acting as a DHCPv6 relay agent obtains the addresses of the DHCPv6 servers according to the received DHCPv6 Server Option from DHCPv4 server. Note that the CPE SHOULD have a 6rd address in order to behave as a relay agent. (2) When receiving a DHCPv6 Information-request packet from an IPv6 host, the 6rd CPE SHOULD relay the message according to Relay Agent Behavior defined in [RFC3315]. (3) The DHCPv6 Relay-forward message travels through the 6rd domain and is sent to a DHCPv6 server. Xu, et al. Expires February 24, 2011 [Page 4] Internet-Draft IPv6 Host Configuration in 6rd August 2010 (4) 6rd CPE receives the DHCPv6 Relay-reply message encapsulated in 6rd tunnel. (5) 6rd CPE relays the DHCPv6 reply message to the DHCP client. Customer Site-> | <-IPv4 Provider Network-> |<-IPv6 Network IPv6 Host 6rd CPE DHCPv4 6rd BR/CPE DHCPv6 (DHCPv6 Relay ) Server Server ----+----------+--------------+------------+-----------+----- | | | | | | |DHCPv6 Option | | | (1) | | <----------> | | | | DHCPv6 | | | Information-request | | (2) | -------->| DHCPv6 Relay-forward | | | | in 6rd Tunnel | DHCPv6 Relay-forward (3) | |==========================>|---------->| | | DHCPv6 Relay-reply | | | | in 6rd Tunnel | DHCPv6 Relay-reply (4) | DHCPv6 |<==========================|<----------| | Reply | | | (5) | <--------| | | Figure 2: Running DHCPv6 in 6rd 4. Security Considerations To be defined. 5. IANA Considerations IANA is requested to allocate a DHCPv4 Option code for the DHCPv6 Server Option. 6. Acknowledgements Thanks to Ole Troan for his valuable comments. 7. References 7.1. Normative References [RFC2119] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Xu, et al. Expires February 24, 2011 [Page 5] Internet-Draft IPv6 Host Configuration in 6rd August 2010 7.2. Informative References [RFC2131] Droms R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3315] Droms R., et al., "Dynamic Host Configure Protocol for IPv6", RFC3315, July 2003. [RFC3736] Droms R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC5969] Townsley W., and Troan O., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, Auguest 2010. [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009. Authors' Addresses Xiaohu Xu Huawei Technologies, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085, P.R. China Phone: +86 10 82882573 Email: xuxh@huawei.com Dayong Guo Huawei Technologies, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085, P.R. China Phone: 86-10-82882578 Email: guoseu@huawei.com