draft-ietf-dhc-dhcpv6-tunnel-00.txt   draft-ietf-dhc-dhcpv6-tunnel-01.txt 
Network Working Group O. Troan Network Working Group O. Troan
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational M. Blanchet Intended status: Informational M. Blanchet
Expires: April 12, 2012 Viagenie Expires: October 28, 2012 Viagenie
X. Xu X. Xu
D. Guo D. Guo
Huawei Technologies Huawei Technologies
W. Townsley W. Townsley
Cisco Cisco
October 10, 2011 April 28, 2012
DHCPv6 through Tunnels DHCPv6 through Tunnels
draft-ietf-dhc-dhcpv6-tunnel-00.txt draft-ietf-dhc-dhcpv6-tunnel-01.txt
Abstract Abstract
The host configuration protocol DHCPv6 [RFC3315] relies on link-local The host configuration protocol DHCPv6 [RFC3315] relies on link-local
addressing and multicast to function. However, most of the existing addresses as source addresses and multicast addresses for destination
6over4 tunnel link types (e.g., 6rd [RFC5969] ) don't support IPv6 addresses. However, some tunnel links (e.g., 6rd [RFC5969] ) do not
link-local addresses and even IPv6 multicast addresses. Taking 6rd have IPv6 link-local addresses and do not support IPv6 multicast
as an example, this document specifies how DHCPv6 can be used across addresses. Taking 6rd as an example, this document specifies how
such tunnel links . DHCPv6 is used across such tunnel links.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 12, 2012. This Internet-Draft will expire on October 28, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
1. Introduction 1. Introduction
Various tunnel techniques are used to deploy IPv6 over IPv4, such as
6rd. The source tunnel end-point typically generates its IPv6 global
address and for some tunnel techniques such as 6rd, generates a
prefix for the downstream network. By some means, the source tunnel
end-point always knows the IPv6 address of the other tunnel end-
point.
The source tunnel end-point often need more configuration data for
itself and its downstream network, such as DNS, SIP, NTP IPv6 server
addresses or else. Therefore, the source tunnel end-point needs to
send DHCPv6 requests over its IPv6 upstream link, the tunnel link.
As specified in the DHCPv6 specification [RFC3315], "...The client As specified in the DHCPv6 specification [RFC3315], "...The client
MUST use a link-local address assigned to the interface for which it MUST use a link-local address assigned to the interface for which it
is requesting configuration information as the source address in the is requesting configuration information as the source address in the
header of the IP datagram." and "...Unless otherwise specified in header of the IP datagram." and "...Unless otherwise specified in
this document, or in a document that describes how IPv6 is carried 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 over a specific type of link (for link types that do not support
multicast), a client sends DHCP messages to the multicast), a client sends DHCP messages to the
All_DHCP_Relay_Agents_and_Servers". All_DHCP_Relay_Agents_and_Servers".
However, link-local addresses and even multicast addresses are not However, link-local addresses and even multicast addresses are not
supported over most of the existing 6over4 tunnel link types. 6rd as supported over some tunnel links such as 6rd [RFC5969] .
described in [RFC5969] is a real example.
Taking 6rd as an example, this document describes how DHCPv6 service Taking 6rd as an example, this document describes how DHCPv6 service
can be provided across such tunnel links . can be provided across such tunnel links .
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. DHCPv6 over 6rd links 3. Using DHCPv6 over Tunnel Links
There are two problems to be solved with regards to providing DHCPv6 There are two problems to be solved with regards to providing DHCPv6
service over a 6rd link: service over a 6rd link:
o A DHCPv6 client uses an IPv6 link-local address as the source o A DHCPv6 client uses an IPv6 link-local address as the source
address when requesting configuration information [RFC3315]. address when requesting configuration information [RFC3315].
Link-local addressing is not supported on an 6rd link. Link-local addressing is not supported on an 6rd link.
o A DHCPv6 client sends a request to the o A DHCPv6 client sends a request to the
All_DHCP_Relay_Agent_and_Servers multicast address. 6rd as All_DHCP_Relay_Agent_and_Servers multicast address. 6rd as
specified in [RFC5969] does not support IPv6 multicast. specified in [RFC5969] does not support IPv6 multicast.
The first problem can be solved by changing the DHCPv6 protocol to This document describes a possible solution to the above two problems
allow for a global address to be used as the source address in which doesn't require any change to the DHCPv6 protocol [RFC3315] .
requests. Another solution that does not require protocol changes, The basic idea of this solution is to send DHCPv6 requests via a
is to send DHCPv6 requests via a local DHCPv6 relay on the 6rd CE. local DHCPv6 relay on the 6rd CE.
The 6rd CE MUST support a local DHCPv6 client and relay. The DHCPv6 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 client running on the 6rd CE's virtual tunnel interface MUST send
DHCPv6 messages through a local DHCPv6 relay that encapsulates the DHCPv6 messages through a local DHCPv6 relay that encapsulates the
client message and forwards it to a DHCPv6 server or relay using one 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. 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 The 6rd CE DHCPv6 relay agent SHOULD use the 6rd BR IPv6 anycast
address as the destination address, section 20 of [RFC3315]. If the address as the destination address, section 20 of [RFC3315]. If the
6rd link supports multicast [I-D.ietf-mboned-auto-multicast] the 6rd 6rd link supports multicast [I-D.ietf-mboned-auto-multicast] the 6rd
CE DHCPv6 relay MAY use the All_DHCP_Servers [RFC3315] as the CE DHCPv6 relay MAY use the All_DHCP_Servers [RFC3315] as the
destination address of Relay-forward messages. destination address of Relay-forward messages.
The 6rd BRs in the 6rd domain must be configured as DHCPv6 relays or The 6rd BRs in the 6rd domain MUST be configured as DHCPv6 relays or
servers on their 6rd virtual interfaces. servers on their 6rd virtual interfaces.
The 6rd CE SHOULD behave according to The 6rd CE SHOULD behave according to
[I-D.ietf-v6ops-ipv6-cpe-router]. In particular it operates a DHCPv6 [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 client on the WAN side (6rd virtual) interface and as a DHCPv6 server
on the LAN-side interface(s). on the LAN-side interface(s).
4. IANA Considerations 4. IANA Considerations
This specification does not require any IANA actions. This specification does not require any IANA actions.
5. Security Considerations 5. Security Considerations
There are no new security considerations pertaining to this document. There are no new security considerations pertaining to this document.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Ted Lemon, Fred Templin and other The authors would like to thank Ted Lemon, Fred Templin, Brian E
people for their valuable comments. Carpenter and other people for their valuable comments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification", Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010. RFC 5969, August 2010.
7.2. Informative References 7.2. Informative References
[I-D.ietf-mboned-auto-multicast] [I-D.ietf-mboned-auto-multicast]
Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., Bumgardner, G., "Automatic Multicast Tunneling",
Pusateri, T., and T. Morin, "Automatic IP Multicast draft-ietf-mboned-auto-multicast-13 (work in progress),
Tunneling", draft-ietf-mboned-auto-multicast-11 (work in April 2012.
progress), July 2011.
[I-D.ietf-v6ops-ipv6-cpe-router] [I-D.ietf-v6ops-ipv6-cpe-router]
Singh, H., Beebee, W., Donley, C., Stark, B., and O. Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge Troan, "Basic Requirements for IPv6 Customer Edge
Routers", draft-ietf-v6ops-ipv6-cpe-router-09 (work in Routers", draft-ietf-v6ops-ipv6-cpe-router-09 (work in
progress), December 2010. progress), December 2010.
Authors' Addresses Authors' Addresses
Ole Troan Ole Troan
 End of changes. 13 change blocks. 
24 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/