idnits 2.17.1 draft-ietf-dhc-dhcpv6-tunnel-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3315], [RFC5969]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 28, 2012) is 4380 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-13 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Troan 3 Internet-Draft Cisco 4 Intended status: Informational M. Blanchet 5 Expires: October 28, 2012 Viagenie 6 X. Xu 7 D. Guo 8 Huawei Technologies 9 W. Townsley 10 Cisco 11 April 28, 2012 13 DHCPv6 through Tunnels 14 draft-ietf-dhc-dhcpv6-tunnel-01.txt 16 Abstract 18 The host configuration protocol DHCPv6 [RFC3315] relies on link-local 19 addresses as source addresses and multicast addresses for destination 20 addresses. However, some tunnel links (e.g., 6rd [RFC5969] ) do not 21 have IPv6 link-local addresses and do not support IPv6 multicast 22 addresses. Taking 6rd as an example, this document specifies how 23 DHCPv6 is used across such tunnel links. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 28, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 1. Introduction 59 Various tunnel techniques are used to deploy IPv6 over IPv4, such as 60 6rd. The source tunnel end-point typically generates its IPv6 global 61 address and for some tunnel techniques such as 6rd, generates a 62 prefix for the downstream network. By some means, the source tunnel 63 end-point always knows the IPv6 address of the other tunnel end- 64 point. 66 The source tunnel end-point often need more configuration data for 67 itself and its downstream network, such as DNS, SIP, NTP IPv6 server 68 addresses or else. Therefore, the source tunnel end-point needs to 69 send DHCPv6 requests over its IPv6 upstream link, the tunnel link. 71 As specified in the DHCPv6 specification [RFC3315], "...The client 72 MUST use a link-local address assigned to the interface for which it 73 is requesting configuration information as the source address in the 74 header of the IP datagram." and "...Unless otherwise specified in 75 this document, or in a document that describes how IPv6 is carried 76 over a specific type of link (for link types that do not support 77 multicast), a client sends DHCP messages to the 78 All_DHCP_Relay_Agents_and_Servers". 80 However, link-local addresses and even multicast addresses are not 81 supported over some tunnel links such as 6rd [RFC5969] . 83 Taking 6rd as an example, this document describes how DHCPv6 service 84 can be provided across such tunnel links . 86 2. Conventions 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 3. Using DHCPv6 over Tunnel Links 94 There are two problems to be solved with regards to providing DHCPv6 95 service over a 6rd link: 96 o A DHCPv6 client uses an IPv6 link-local address as the source 97 address when requesting configuration information [RFC3315]. 98 Link-local addressing is not supported on an 6rd link. 99 o A DHCPv6 client sends a request to the 100 All_DHCP_Relay_Agent_and_Servers multicast address. 6rd as 101 specified in [RFC5969] does not support IPv6 multicast. 103 This document describes a possible solution to the above two problems 104 which doesn't require any change to the DHCPv6 protocol [RFC3315] . 105 The basic idea of this solution is to send DHCPv6 requests via a 106 local DHCPv6 relay on the 6rd CE. 108 The 6rd CE MUST support a local DHCPv6 client and relay. The DHCPv6 109 client running on the 6rd CE's virtual tunnel interface MUST send 110 DHCPv6 messages through a local DHCPv6 relay that encapsulates the 111 client message and forwards it to a DHCPv6 server or relay using one 112 of the 6rd CE's global unicast addresses as the source address. 114 The 6rd CE DHCPv6 relay agent SHOULD use the 6rd BR IPv6 anycast 115 address as the destination address, section 20 of [RFC3315]. If the 116 6rd link supports multicast [I-D.ietf-mboned-auto-multicast] the 6rd 117 CE DHCPv6 relay MAY use the All_DHCP_Servers [RFC3315] as the 118 destination address of Relay-forward messages. 120 The 6rd BRs in the 6rd domain MUST be configured as DHCPv6 relays or 121 servers on their 6rd virtual interfaces. 123 The 6rd CE SHOULD behave according to 124 [I-D.ietf-v6ops-ipv6-cpe-router]. In particular it operates a DHCPv6 125 client on the WAN side (6rd virtual) interface and as a DHCPv6 server 126 on the LAN-side interface(s). 128 4. IANA Considerations 130 This specification does not require any IANA actions. 132 5. Security Considerations 134 There are no new security considerations pertaining to this document. 136 6. Acknowledgements 138 The authors would like to thank Ted Lemon, Fred Templin, Brian E 139 Carpenter and other people for their valuable comments. 141 7. References 143 7.1. Normative References 145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 146 Requirement Levels", BCP 14, RFC 2119, March 1997. 148 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 149 and M. Carney, "Dynamic Host Configuration Protocol for 150 IPv6 (DHCPv6)", RFC 3315, July 2003. 152 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 153 Infrastructures (6rd) -- Protocol Specification", 154 RFC 5969, August 2010. 156 7.2. Informative References 158 [I-D.ietf-mboned-auto-multicast] 159 Bumgardner, G., "Automatic Multicast Tunneling", 160 draft-ietf-mboned-auto-multicast-13 (work in progress), 161 April 2012. 163 [I-D.ietf-v6ops-ipv6-cpe-router] 164 Singh, H., Beebee, W., Donley, C., Stark, B., and O. 165 Troan, "Basic Requirements for IPv6 Customer Edge 166 Routers", draft-ietf-v6ops-ipv6-cpe-router-09 (work in 167 progress), December 2010. 169 Authors' Addresses 171 Ole Troan 172 Cisco 173 Oslo, 174 Norway 176 Email: ot@cisco.com 177 Marc Blanchet 178 Viagenie 179 2875 boul. Laurier, suite D2-630 180 Quebec, 181 Canada 183 Phone: 184 Fax: 185 Email: Marc.Blanchet@viagenie.ca 186 URI: 188 Xiaohu Xu 189 Huawei Technologies 190 No.3 Xinxi Rd., Shang-Di Information Industry Base 191 Beijing, 100085 192 P.R. China 194 Phone: +86 10 82882573 195 Email: xuxh@huawei.com 197 Dayong Guo 198 Huawei Technologies 199 No.3 Xinxi Rd., Shang-Di Information Industry Base 200 Beijing, Hai-Dian District 100085 201 P.R. China 203 Phone: +86-10-82882578 204 Email: guoseu@huawei.com 206 Mark Townsley 207 Cisco 208 Paris, 209 France 211 Email: mark@townsley.net