| Network Working Group | O. Troan |
| Internet-Draft | Cisco |
| Intended status: Informational | M. Blanchet |
| Expires: April 10, 2012 | Viagenie |
| X. Xu | |
| D. Guo | |
| Huawei Technologies | |
| W. M. Townsley | |
| Cisco | |
| October 10, 2011 |
DHCPv6 through Tunnels
draft-ietf-dhc-dhcpv6-tunnel-00.txt
The host configuration protocol DHCPv6 [RFC3315] relies on link-local addressing and multicast to function. However, most of the existing 6over4 tunnel link types (e.g., 6rd [RFC5969] ) don't support IPv6 link-local addresses and even IPv6 multicast addresses. Taking 6rd as an example, this document specifies how DHCPv6 can be used across such tunnel links .
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 10, 2012.
Copyright (c) 2011 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.
As specified 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." and "...Unless otherwise specified in this document, or in a document that describes how IPv6 is carried over a specific type of link (for link types that do not support multicast), a client sends DHCP messages to the All_DHCP_Relay_Agents_and_Servers".
However, link-local addresses and even multicast addresses are not supported over most of the existing 6over4 tunnel link types. 6rd as described in [RFC5969] is a real example.
Taking 6rd as an example, this document describes how DHCPv6 service can be provided across such tunnel links .
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].
There are two problems to be solved with regards to providing DHCPv6 service over a 6rd link:
The first problem can be solved by changing the DHCPv6 protocol to allow for a global address to be used as the source address in requests. Another solution that does not require protocol changes, is to send DHCPv6 requests via a local DHCPv6 relay on the 6rd CE.
The 6rd CE MUST support a local DHCPv6 client and relay. The DHCPv6 client running on the 6rd CE's virtual tunnel interface MUST send DHCPv6 messages through a local DHCPv6 relay that encapsulates the client message and forwards it to a DHCPv6 server or relay using one of the 6rd CE's global unicast addresses as the source address.
The 6rd CE DHCPv6 relay agent SHOULD use the 6rd BR IPv6 anycast address as the destination address, section 20 of [RFC3315]. If the 6rd link supports multicast [I-D.ietf-mboned-auto-multicast] the 6rd CE DHCPv6 relay MAY use the All_DHCP_Servers [RFC3315] as the destination address of Relay-forward messages.
The 6rd BRs in the 6rd domain must be configured as DHCPv6 relays or servers on their 6rd virtual interfaces.
The 6rd CE SHOULD behave according to [I-D.ietf-v6ops-ipv6-cpe-router]. In particular it operates a DHCPv6 client on the WAN side (6rd virtual) interface and as a DHCPv6 server on the LAN-side interface(s).
This specification does not require any IANA actions.
There are no new security considerations pertaining to this document.
The authors would like to thank Ted Lemon, Fred Templin and other people for their valuable comments.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [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. |
| [RFC5969] | Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. |
| [I-D.ietf-mboned-auto-multicast] | Thaler, D, Talwar, M, Aggarwal, A, Vicisano, L, Pusateri, T and T Morin, "Automatic IP Multicast Tunneling", Internet-Draft draft-ietf-mboned-auto-multicast-11, July 2011. |
| [I-D.ietf-v6ops-ipv6-cpe-router] | Singh, H, Beebee, W, Donley, C, Stark, B and O Troan, "Basic Requirements for IPv6 Customer Edge Routers", Internet-Draft draft-ietf-v6ops-ipv6-cpe-router-09, December 2010. |