idnits 2.17.1 draft-ietf-dhc-addr-registration-06.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 (July 20, 2014) is 3568 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: 'RFC2136' is defined on line 332, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-21) exists of draft-ietf-dhc-sedhcpv6-03 Summary: 2 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: January 21, 2015 China Mobile 6 S. Krishnan 7 Ericsson 8 R. Asati 9 Cisco Systems, Inc. 10 July 20, 2014 12 Registering Self-generated IPv6 Addresses in DNS using DHCPv6 13 draft-ietf-dhc-addr-registration-06 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 January 21, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 Registration and Retransmission . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 9.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 are 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 Certificate In this document, the term "Certificate" is all referred 109 to public key certificate. 111 3. Solution Overview 113 After successfully assigning a self-generated IPv6 address on one of 114 its interfaces, an end-host implementing this specification SHOULD 115 send an ADDR-REGISTRATION-REQUEST message to a DHCPv6 address 116 registration server. After receiving the address registration 117 request, the DHCPv6 server registers the IPv6 address to FQDN binding 118 towards a configured DNS server. An acknowledgement MUST be sent 119 back to the end host to indicate whether or not the registration 120 operation succeeded. 122 +----+ +-----------+ +---------------+ 123 |Host| |Edge router| |Addr-Reg Server| 124 +----+ +-----------+ +---------------+ 125 | SLAAC | | 126 |<--------->| | 127 | | | 128 | | ADDR-REGISTRATION-REQUEST | 129 |-------------------------------------------->| 130 | | |Register 131 | | |address 132 | | Acknowledgment |in DNS 133 |<--------------------------------------------| 135 Figure 1: Address Registration Procedure 137 It is RECOMMENDED to only set up one address registration server 138 within an administration domain, although there may be multiple 139 DHCPv6 servers. While multiple address registration servers does 140 potentially increase the load on DNS, because of how [RFC4703] and 141 [RFC4704] work, this should NOT be an issue - the servers should work 142 correctly in updating DNS (either adding or removing the entries). 143 The broken part with multiple servers is the 'extension' of the 144 registration. If there are two address registration servers and both 145 receive the initial registration and (correctly) update DNS, the 146 problem comes when the client extends this but one of the servers 147 does not receive this extension. Then, the server that missed the 148 extension removes the entry prematurely (i.e., when it expired 149 originally). The coordination of multiple address registration 150 servers is out of scope. 152 4. DHCPv6 ADDR-REGISTRATION-REQUEST Message 154 The DHCPv6 client sends an ADDR-REGISTRATION-REQUEST message to a 155 server to request an address to be registered in the DNS. The format 156 of the ADDR-REGISTRATION-REQUEST message is described as follows: 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | msg-type | transaction-id | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | | 164 . options . 165 . (variable) . 166 | | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 msg-type Identifies the DHCPv6 message type; 169 Set to ADDR-REGISTRATION-REQUEST (TBA1). 171 transaction-id The transaction ID for this message exchange. 173 options Options carried in this message. 175 DHCPv6 ADDR-REGISTRATION-REQUEST message 177 The ADDR-REGISTRATION-REQUEST message MUST NOT contain server- 178 identifier option and MUST contain the IA_NA option and the DHCPv6 179 FQDN option [RFC4704]. The ADDR-REGISTRATION-REQUEST message is 180 dedicated for clients to initiate an address registration request 181 toward an address registration server. Consequently, clients MUST 182 NOT put any Option Request Option(s) in the ADDR-REGISTRATION-REQUEST 183 message. 185 Clients MUST discard any received ADDR-REGISTRATION-REQUEST messages. 187 Servers MUST discard any ADDR-REGISTRATION-REQUEST messages that meet 188 any of the following conditions: 190 o the message does not include a Client Identifier option. 192 o the message includes a Server Identifier option. 194 o the message does not include at least one IA_NA option. 196 o the message does not include an IAADDR option encapsulated within 197 the IA_NA option(s). 199 o the message does not include FQDN option (or include multiple FQDN 200 options). 202 o the message includes an Option Request Option. 204 Servers MUST discard any ADDR-REGISTRATION-REQUEST messages that do 205 not Servers MUST discard any ADDR-REGISTRATION-REQUEST messages that 206 do include any Option Request Option(s). 208 5. DHCPv6 Address Registration Procedure 210 The DHCPv6 protocol is used as the address registration protocol when 211 a DHCPv6 server performs the role of an address registration server. 212 The DHCPv6 IA_NA option [RFC3315] and the DHCPv6 FQDN option 213 [RFC4704] are adopted in order to fulfill the address registration 214 interactions. 216 5.1. DHCPv6 Address Registration Request 218 The end-host sends a DHCPv6 ADDR-REGISTRATION-REQUEST message to the 219 address registration server to the All_DHCP_Relay_Agents_and_Servers 220 multicast address (ff02::1:2). 222 The end-host MUST include a Client Identifier option in the ADDR- 223 REGISTRATION-REQUEST message to identify itself to the server. The 224 DHCPv6 ADDR-REGISTRATION-REQUEST message MUST contain at least one 225 IA_NA option and exactly one FQDN option. The IA_NA option MUST 226 contain at least one IA Address option. The valid-lifetime field of 227 the IA Address option MUST be set to the period for which the client 228 would like to register the binding in DNS. 230 After receiving this ADDR-REGISTRATION-REQUEST message, the address 231 registration server MUST register the binding between the provided 232 FQDN and address(es) in DNS. If the DHCPv6 server does not support 233 address registration function, a Reply message with includes a Status 234 Code option with the value the RegistrationNotSupported (TBA2) MAY be 235 sent back to the initiated client. 237 5.2. Registration Expiry and Refresh 239 For every successful binding registration, the address registration 240 server MUST record the IPv6-address-to-FQDN bindings and associated 241 valid-lifetimes in its storage. 243 The address registration client MUST refresh the registration before 244 it expires (i.e. before the valid-lifetime of the IA address elapses) 245 by sending a new ADDR-REGISTRATION-REQUEST to the address 246 registration server. If the address registration server does not 247 receive such a refresh after the valid-lifetime has passed, it SHOULD 248 remove the IPv6-address-to-FQDN bindings in DNS, also the local 249 record. 251 It is RECOMMENDED that clients initiate a refresh at about 85% of the 252 valid-lifetime. Because RAs may periodically 'reset' the valid- 253 lifetime, the refresh timer MUST be independently maintained from the 254 address valid-lifetime. Clients SHOULD set a refresh timer to 85% of 255 the valid-lifetime when they complete a registration operation and 256 only update this timer if 85% of any updated valid-lifetime would be 257 sooner than the timer. 259 5.3. Acknowledging Registration and Retransmission 261 After an address registration server accepts an address registration 262 request, it MUST send a Reply message as the response to registration 263 The server is responsilbe to register all the addresses in DNS. The 264 server generates a Reply message and includes a Status Code option 265 with value Success, a Server Identifier option with the server's 266 DUID, and a Client Identifier option with the client's DUID. 268 If there is no reply received within some interval, the client SHOULD 269 retransmits the message according to section 14 of [RFC3315], using 270 the following parameters: 272 o IRT ADDR_REG_TIMEOUT 274 o MRT ADDR_REG_MAX_RT 276 o MRC ADDR_REG_MAX_RC 278 o MRD 0 280 Where ADDR_REG_TIMEOUT might be 1 second, ADDR_REG_MAX_RT might be 30 281 minutes and ADDR_REG_MAX_RC might be 5. 283 For each IA in the ADDR-REGISTRATION-REQUEST message for which the 284 server does not accept its associated in registration request, the 285 server adds an IA option using the IAID from the ADDR-REGISTRATION- 286 REQUEST message, and includes a Status Code option with the value 287 RegistrationDenied (TBA3) in the IA option. No other options are 288 included in the IA option. 290 Upon receiving a RegistrationDenied error status code, the client MAY 291 also resend the message following normal retransmission routines 292 defined in [RFC3315] with above parameters. 294 6. Security Considerations 296 An attacker may attempt to register large number of addresses in 297 quick succession in order to overwhelm the address registration 298 server. These attacks may be prevented generic DHCPv6 protection by 299 using the AUTH option [RFC3315] or Secure DHCPv6 300 [I-D.ietf-dhc-sedhcpv6]. 302 7. IANA Considerations 304 This document defines a new DHCPv6 message, the ADDR-REGISTRATION- 305 REQUEST message (TBA1) described in Section 4, that requires an 306 allocation out of the registry defined at 308 http://www.iana.org/assignments/dhcpv6-parameters/ 310 This document defines two new DHCPv6 Status code, the 311 RegistrationNotSupported (TBA2) and RegistrationDenied (TBA3) 312 described in Section 5, that requires an allocation out of the 313 registry defined at 315 http://www.iana.org/assignments/dhcpv6-parameters/ 317 8. Acknowledgements 319 The authors would like to thank Ralph Droms, Ted Lemon, Bernie Volz, 320 Sten Carlsen, Erik Kline, Lorenzo Colitti, Joel Jaeggli, Sten 321 Carlsen, Mark Smith, Marcin Siodelski, Darpan Malhotra, Tomek 322 Mrugalski and other members of dhc and v6ops working groups for their 323 valuable comments. 325 9. References 327 9.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, March 1997. 332 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 333 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 334 RFC 2136, April 1997. 336 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 337 and M. Carney, "Dynamic Host Configuration Protocol for 338 IPv6 (DHCPv6)", RFC 3315, July 2003. 340 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 341 RFC 3972, March 2005. 343 [RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified 344 Domain Name (FQDN) Conflicts among Dynamic Host 345 Configuration Protocol (DHCP) Clients", RFC 4703, October 346 2006. 348 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 349 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 350 Option", RFC 4704, October 2006. 352 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 353 Address Autoconfiguration", RFC 4862, September 2007. 355 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 356 Extensions for Stateless Address Autoconfiguration in 357 IPv6", RFC 4941, September 2007. 359 9.2. Informative References 361 [I-D.ietf-dhc-sedhcpv6] 362 Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure 363 DHCPv6 with Public Key", draft-ietf-dhc-sedhcpv6-03 (work 364 in progress), June 2014. 366 Authors' Addresses 368 Sheng Jiang 369 Huawei Technologies Co., Ltd 370 Q14, Huawei Campus 371 No.156 Beiqing Road 372 Hai-Dian District, Beijing 100095 373 P.R. China 375 Email: jiangsheng@huawei.com 376 Gang Chen 377 China Mobile 378 53A, Xibianmennei Ave., Xuanwu District, Beijing 379 P.R. China 381 Phone: 86-13910710674 382 Email: phdgang@gmail.com 384 Suresh Krishnan 385 Ericsson 386 8400 Decarie Blvd. 387 Town of Mount Royal, QC 388 Canada 390 Phone: +1 514 345 7900 x42871 391 Email: suresh.krishnan@ericsson.com 393 Rajiv Asati 394 Cisco Systems, Inc. 395 7025 Kit Creek road 396 Research Triangle Park, NC 27709-4987 397 USA 399 Email: rajiva@cisco.com