idnits 2.17.1 draft-ietf-dhc-addr-registration-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3716 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3633' is defined on line 261, but no explicit reference was found in the text == Unused Reference: 'RFC3971' is defined on line 265, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group S. Jiang 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Standards Track G. Chen 5 Expires: August 18, 2014 China Mobile 6 S. Krishnan 7 Ericsson 8 R. Asati 9 Cisco Systems 10 February 14, 2014 12 Registering self-generated IPv6 Addresses in DNS using DHCPv6 13 draft-ietf-dhc-addr-registration-04 15 Abstract 17 In networks that are centrally managed, self-generated addresses 18 cause some traceability issues due to their decentralized nature. 19 One of the most important issues in this regard is the inability to 20 register such addresses in DNS. This document defines a mechanism to 21 register self-generated and statically configured addresses in DNS 22 through a DHCPv6 server. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 18, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. DHCPv6 ADDR-REGISTRATION-REQUEST Message . . . . . . . . . . . 4 62 5. DHCPv6 Address Registration Procedure . . . . . . . . . . . . . 5 63 5.1. DHCPv6 Address Registration Request . . . . . . . . . . . . 5 64 5.2. Registration expiry and refresh . . . . . . . . . . . . . . 5 65 5.3. Acknowledging successful registration . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 In several common network scenarios, IPv6 addresses are self- 77 generated by the end-hosts by appending a self-generated interface 78 identifier to a network-specified prefix. Examples of self-generated 79 addresses include those created using IPv6 Stateless Address 80 Configuration [RFC4862] , temporary addresses [RFC4941] and 81 Cryptographically Generated Addresses (CGA) [RFC3972] etc. In 82 several tighly controlled networks, hosts with self-generated 83 addresses may face some limitations. One such limitation is related 84 to the inability of nodes with self-generated addresses to register 85 their IPv6-address-to-FQDN bindings in DNS. This is related to the 86 fact that, in such networks, only certain nodes (e.g. The DHCPv6 87 server) are allowed to update these bindings in order to prevent end- 88 hosts from registering arbitrary addresses for their FQDNs or 89 associating their addresses with arbitrary domain names. 91 For nodes that obtain their addresses through DHCPv6, a solution has 92 been specified in [RFC4704]. The solution works by including a 93 Client FQDN option in the SOLICIT, REQUEST, RENEW or REBIND messages 94 during the process of acquiring an address through DHCPv6. This 95 document provides an analogous mechanism to register self-generated 96 addresses in DNS. 98 A new ADDR-REGISTRATION-REQUEST DHCPv6 message type is defined to 99 initiate the address registration request, and two new Status codes 100 is defined to indicate registration errors on the server side. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. Solution Overview 110 After successfully assigning a self-generated IPv6 address on one of 111 its interfaces, an end-host implementing this specification SHOULD 112 send an ADDR-REGISTRATION-REQUEST message to a DHCPv6 address 113 registration server. After receiving the address registration 114 request, the DHCPv6 server registers the IPv6 address to FQDN binding 115 towards a configured DNS server. An acknowledgement MAY be sent back 116 to the end host to indicate whether or not the registration operation 117 succeeded.. 119 +----+ +-----------+ +---------------+ 120 |Host| |Edge router| |Addr-Reg Server| 121 +----+ +-----------+ +---------------+ 122 | SLAAC | | 123 |<--------->| | 124 | | | 125 | | ADDR-REGISTRATION-REQUEST | 126 |------------------------------------------------->| 127 | | |Register 128 | | |address 129 | | Optional Acknowledgment |in DNS 130 |<-------------------------------------------------| 132 Figure 1: Address Registration Procedure 134 4. DHCPv6 ADDR-REGISTRATION-REQUEST Message 136 The DHCPv6 client sends an ADDR-REGISTRATION-REQUEST message to a 137 server to request an address to be registered in the DNS. The format 138 of the ADDR-REGISTRATION-REQUEST message is described as follows: 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | msg-type | transaction-id | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | | 146 . options . 147 . (variable) . 148 | | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 msg-type Identifies the DHCPv6 message type; 151 Set to ADDR-REGISTRATION-REQUEST (TBA1). 153 transaction-id The transaction ID for this message exchange. 155 options Options carried in this message. 157 DHCPv6 ADDR-REGISTRATION-REQUEST message 159 The ADDR-REGISTRATION-REQUEST message MUST NOT contain server- 160 identifier option and MUST contain the IA_NA option and the DHCPv6 161 FQDN option [RFC4704]. 163 Clients MUST discard any received ADDR-REGISTRATION-REQUEST messages. 164 Servers MUST discard any ADDR-REGISTRATION-REQUEST messages that do 165 not include a Client Identifier option or that do include a Server 166 Identifier option. 168 5. DHCPv6 Address Registration Procedure 170 The DHCPv6 protocol is used as the address registration protocol when 171 a DHCPv6 server performs the role of an address registration server. 172 The DHCPv6 IA_NA option [RFC3315] and the DHCPv6 FQDN option 173 [RFC4704] are reused in order to fulfill the address registration 174 interactions. 176 5.1. DHCPv6 Address Registration Request 178 The end-host sends a DHCPv6 ADDR-REGISTRATION-REQUEST message to the 179 address registration server to the All_DHCP_Relay_Agents_and_Servers 180 multicast address (ff02::1:2). 182 The end-host MUST include a Client Identifier option in the ADDR- 183 REGISTRATION-REQUEST message to identify itself to the server. The 184 DHCPv6 ADDR-REGISTRATION-REQUEST message MUST contain exactly one 185 IA_NA option and exactly one FQDN option. The IA_NA option MUST 186 contain at least one IA Address option. The valid-lifetime field of 187 the IA Address option MUST be set to the period for which the client 188 would like to register the binding in DNS. 190 After receiving this ADDR-REGISTRATION-REQUEST message, the address 191 registration server MUST register the binding between the provided 192 FQDN and address(es) in DNS. If the DHCPv6 server does not support 193 address registration function, a Reply message with includes a Status 194 Code option with the value the RegistrationNotSupported (TBA2) MAY be 195 sent back to the initiated client. 197 5.2. Registration expiry and refresh 199 The address registration client MUST refresh the registration before 200 it expires (i.e. before the valid-lifetime of the IA address elapses) 201 by sending a new ADDR-REGISTRATION-REQUEST to the address 202 registration server. If the address registration server does not 203 receive such a refresh after the valid-lifetime has passed, it SHOULD 204 remove the IPv6-address-to-FQDN bindings in DNS. 206 5.3. Acknowledging successful registration 208 After all the addresses have been successfully registered in DNS, the 209 address registration server MAY send a Reply message as the response 210 to registration requests. The server generates a Reply message and 211 includes a Status Code option with value Success, a Server Identifier 212 option with the server's DUID, and a Client Identifier option with 213 the client's DUID. For each IA in the ADDR-REGISTRATION-REQUEST 214 message for which the server does not succeed in registering, the 215 server adds an IA option using the IAID from the ADDR-REGISTRATION- 216 REQUEST message, and includes a Status Code option with the value 217 RegistrationDenied (TBA3) in the IA option. No other options are 218 included in the IA option. 220 6. Security Considerations 222 An attacker may attempt to register large number of addresses in 223 quick succession in order to overwhelm the address registration 224 server. These attacks may be prevented generic DHCPv6 protection by 225 using the AUTH option [RFC3315] or Secure DHCPv6 226 [I-D.ietf-dhc-secure-dhcpv6]. 228 7. IANA Considerations 230 This document defines a new DHCPv6 message, the ADDR-REGISTRATION- 231 REQUEST message (TBA1) described in Section 5, that requires an 232 allocation out of the registry defined at 234 http://www.iana.org/assignments/dhcpv6-parameters/ 236 This document defines two new DHCPv6 Status code, the 237 RegistrationNotSupported (TBA2) and RegistrationDenied (TBA3) 238 described in Section 6, that requires an allocation out of the 239 registry defined at 241 http://www.iana.org/assignments/dhcpv6-parameters/ 243 8. Acknowledgements 245 The authors would like to thank Ralph Droms, Ted Lemon, Bernie Volz, 246 Sten Carlsen, Erik Kline, Lorenzo Colitti, Joel Jaeggli, Sten 247 Carlsen, Mark Smith, Marcin Siodelski and other members of dhc and 248 v6ops working groups for their valuable comments. 250 9. References 252 9.1. Normative References 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 258 and M. Carney, "Dynamic Host Configuration Protocol for 259 IPv6 (DHCPv6)", RFC 3315, July 2003. 261 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 262 Host Configuration Protocol (DHCP) version 6", RFC 3633, 263 December 2003. 265 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 266 Neighbor Discovery (SEND)", RFC 3971, March 2005. 268 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 269 RFC 3972, March 2005. 271 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 272 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 273 Option", RFC 4704, October 2006. 275 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 276 Address Autoconfiguration", RFC 4862, September 2007. 278 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 279 Extensions for Stateless Address Autoconfiguration in 280 IPv6", RFC 4941, September 2007. 282 9.2. Informative References 284 [I-D.ietf-dhc-secure-dhcpv6] 285 Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", 286 draft-ietf-dhc-secure-dhcpv6-07 (work in progress), 287 September 2012. 289 Authors' Addresses 291 Sheng Jiang 292 Huawei Technologies Co., Ltd 293 Q14, Huawei Campus 294 No.156 Beiqing Road 295 Hai-Dian District, Beijing 100095 296 P.R. China 298 Email: jiangsheng@huawei.com 299 Gang Chen 300 China Mobile 301 53A, Xibianmennei Ave., Xuanwu District, Beijing 302 P.R. China 304 Phone: 86-13910710674 305 Email: phdgang@gmail.com 307 Suresh Krishnan 308 Ericsson 309 8400 Decarie Blvd. 310 Town of Mount Royal, QC 311 Canada 313 Phone: +1 514 345 7900 x42871 314 Email: suresh.krishnan@ericsson.com 316 Rajiv Asati 317 Cisco Systems 319 Email: rajiva@cisco.com