idnits 2.17.1 draft-ietf-dhc-dhcpv6-tunnel-00.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 (October 10, 2011) is 4579 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-11 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: April 12, 2012 Viagenie 6 X. Xu 7 D. Guo 8 Huawei Technologies 9 W. Townsley 10 Cisco 11 October 10, 2011 13 DHCPv6 through Tunnels 14 draft-ietf-dhc-dhcpv6-tunnel-00.txt 16 Abstract 18 The host configuration protocol DHCPv6 [RFC3315] relies on link-local 19 addressing and multicast to function. However, most of the existing 20 6over4 tunnel link types (e.g., 6rd [RFC5969] ) don't support IPv6 21 link-local addresses and even IPv6 multicast addresses. Taking 6rd 22 as an example, this document specifies how DHCPv6 can be used across 23 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 April 12, 2012. 42 Copyright Notice 44 Copyright (c) 2011 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 As specified in the DHCPv6 specification [RFC3315], "...The client 60 MUST use a link-local address assigned to the interface for which it 61 is requesting configuration information as the source address in the 62 header of the IP datagram." and "...Unless otherwise specified in 63 this document, or in a document that describes how IPv6 is carried 64 over a specific type of link (for link types that do not support 65 multicast), a client sends DHCP messages to the 66 All_DHCP_Relay_Agents_and_Servers". 68 However, link-local addresses and even multicast addresses are not 69 supported over most of the existing 6over4 tunnel link types. 6rd as 70 described in [RFC5969] is a real example. 72 Taking 6rd as an example, this document describes how DHCPv6 service 73 can be provided across such tunnel links . 75 2. Conventions 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [RFC2119]. 81 3. DHCPv6 over 6rd links 83 There are two problems to be solved with regards to providing DHCPv6 84 service over a 6rd link: 85 o A DHCPv6 client uses an IPv6 link-local address as the source 86 address when requesting configuration information [RFC3315]. 87 Link-local addressing is not supported on an 6rd link. 88 o A DHCPv6 client sends a request to the 89 All_DHCP_Relay_Agent_and_Servers multicast address. 6rd as 90 specified in [RFC5969] does not support IPv6 multicast. 92 The first problem can be solved by changing the DHCPv6 protocol to 93 allow for a global address to be used as the source address in 94 requests. Another solution that does not require protocol changes, 95 is to send DHCPv6 requests via a local DHCPv6 relay on the 6rd CE. 97 The 6rd CE MUST support a local DHCPv6 client and relay. The DHCPv6 98 client running on the 6rd CE's virtual tunnel interface MUST send 99 DHCPv6 messages through a local DHCPv6 relay that encapsulates the 100 client message and forwards it to a DHCPv6 server or relay using one 101 of the 6rd CE's global unicast addresses as the source address. 103 The 6rd CE DHCPv6 relay agent SHOULD use the 6rd BR IPv6 anycast 104 address as the destination address, section 20 of [RFC3315]. If the 105 6rd link supports multicast [I-D.ietf-mboned-auto-multicast] the 6rd 106 CE DHCPv6 relay MAY use the All_DHCP_Servers [RFC3315] as the 107 destination address of Relay-forward messages. 109 The 6rd BRs in the 6rd domain must be configured as DHCPv6 relays or 110 servers on their 6rd virtual interfaces. 112 The 6rd CE SHOULD behave according to 113 [I-D.ietf-v6ops-ipv6-cpe-router]. In particular it operates a DHCPv6 114 client on the WAN side (6rd virtual) interface and as a DHCPv6 server 115 on the LAN-side interface(s). 117 4. IANA Considerations 119 This specification does not require any IANA actions. 121 5. Security Considerations 123 There are no new security considerations pertaining to this document. 125 6. Acknowledgements 127 The authors would like to thank Ted Lemon, Fred Templin and other 128 people for their valuable comments. 130 7. References 132 7.1. Normative References 134 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 135 Requirement Levels", BCP 14, RFC 2119, March 1997. 137 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 138 and M. Carney, "Dynamic Host Configuration Protocol for 139 IPv6 (DHCPv6)", RFC 3315, July 2003. 141 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 142 Infrastructures (6rd) -- Protocol Specification", 143 RFC 5969, August 2010. 145 7.2. Informative References 147 [I-D.ietf-mboned-auto-multicast] 148 Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., 149 Pusateri, T., and T. Morin, "Automatic IP Multicast 150 Tunneling", draft-ietf-mboned-auto-multicast-11 (work in 151 progress), July 2011. 153 [I-D.ietf-v6ops-ipv6-cpe-router] 154 Singh, H., Beebee, W., Donley, C., Stark, B., and O. 155 Troan, "Basic Requirements for IPv6 Customer Edge 156 Routers", draft-ietf-v6ops-ipv6-cpe-router-09 (work in 157 progress), December 2010. 159 Authors' Addresses 161 Ole Troan 162 Cisco 163 Oslo, 164 Norway 166 Email: ot@cisco.com 168 Marc Blanchet 169 Viagenie 170 2875 boul. Laurier, suite D2-630 171 Quebec, 172 Canada 174 Phone: 175 Fax: 176 Email: Marc.Blanchet@viagenie.ca 177 URI: 179 Xiaohu Xu 180 Huawei Technologies 181 No.3 Xinxi Rd., Shang-Di Information Industry Base 182 Beijing, 100085 183 P.R. China 185 Phone: +86 10 82882573 186 Email: xuxh@huawei.com 188 Dayong Guo 189 Huawei Technologies 190 No.3 Xinxi Rd., Shang-Di Information Industry Base 191 Beijing, Hai-Dian District 100085 192 P.R. China 194 Phone: +86-10-82882578 195 Email: guoseu@huawei.com 197 Mark Townsley 198 Cisco 199 Paris, 200 France 202 Email: mark@townsley.net