idnits 2.17.00 (12 Aug 2021) /tmp/idnits20358/draft-ietf-dhc-addr-registration-07.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 11, 2014) is 2802 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 352, 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: 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: March 15, 2015 China Mobile 6 S. Krishnan 7 Ericsson 8 R. Asati 9 Cisco Systems, Inc. 10 September 11, 2014 12 Registering Self-generated IPv6 Addresses in DNS using DHCPv6 13 draft-ietf-dhc-addr-registration-07 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 March 15, 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 . . . . . . . . . . . 6 64 5.2. Registration Expiry and Refresh . . . . . . . . . . . . . 6 65 5.3. Acknowledging Registration and Retransmission . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 9.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 tightly 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. The 90 administrators may not want to distribute the address of 91 authoritative name-server. Also, there is no way to propagate the 92 address of authoritative name server by any protocols. It is 93 preferred that the address registration server, which is under the 94 same management with the authoritative name-server, to know the 95 address of the authoritative name-server and make registration 96 requests on behalf of clients. It is preferred by administrators to 97 establish and manage one trust relationship between a single DHCPv6 98 (address registration) server and the DNS authoritative name-server, 99 rather than to distribute and manage trust relationships between many 100 clients and the DNS authoritative name-server. 102 For nodes that obtain their addresses through DHCPv6, a solution has 103 been specified in [RFC4704]. The solution works by including a 104 Client FQDN option in the SOLICIT, REQUEST, RENEW or REBIND messages 105 during the process of acquiring an address through DHCPv6. This 106 document provides an analogous mechanism to register self-generated 107 addresses in DNS. 109 A new ADDR-REGISTRATION-REQUEST DHCPv6 message type is defined to 110 initiate the address registration request, and two new Status codes 111 are defined to indicate registration errors on the server side. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 Certificate In this document, the term "Certificate" is all referred 120 to public key certificate. 122 3. Solution Overview 124 After successfully assigning a self-generated IPv6 address on one of 125 its interfaces, an end-host implementing this specification SHOULD 126 send an ADDR-REGISTRATION-REQUEST message to a DHCPv6 address 127 registration server. After receiving the address registration 128 request, the DHCPv6 server registers the IPv6 address to FQDN binding 129 towards a configured DNS server. An acknowledgement MUST be sent 130 back to the end host to indicate whether or not the registration 131 operation succeeded. 133 +----+ +-----------+ +---------------+ 134 |Host| |Edge router| |Addr-Reg Server| 135 +----+ +-----------+ +---------------+ 136 | SLAAC | | 137 |<--------->| | 138 | | | 139 | | ADDR-REGISTRATION-REQUEST | 140 |-------------------------------------------->| 141 | | |Register 142 | | |address 143 | | Acknowledgment |in DNS 144 |<--------------------------------------------| 146 Figure 1: Address Registration Procedure 148 Furthermore, the registration server MAY apply certain filter/accept 149 criteria for the address registration requests, particularly for the 150 client chosen domain names. 152 It is RECOMMENDED to only set up one address registration server 153 within an administration domain, although there may be multiple 154 DHCPv6 servers. While using multiple address registration servers 155 does potentially increase the load on DNS, because of how [RFC4703] 156 and [RFC4704] work, this should NOT be an issue - the servers should 157 work correctly in updating DNS (either adding or removing the 158 entries). The broken part with multiple servers is the 'extension' 159 of the registration. If there are two address registration servers 160 and both receive the initial registration and (correctly) update DNS, 161 the problem comes when the client extends this but one of the servers 162 does not receive this extension. Then, the server that missed the 163 extension removes the entry prematurely (i.e., when it expired 164 originally). 166 4. DHCPv6 ADDR-REGISTRATION-REQUEST Message 168 The DHCPv6 client sends an ADDR-REGISTRATION-REQUEST message to a 169 server to request an address to be registered in the DNS. The format 170 of the ADDR-REGISTRATION-REQUEST message is described as follows: 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | msg-type | transaction-id | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | | 178 . options . 179 . (variable) . 180 | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 msg-type Identifies the DHCPv6 message type; 183 Set to ADDR-REGISTRATION-REQUEST (TBA1). 185 transaction-id The transaction ID for this message exchange. 187 options Options carried in this message. 189 DHCPv6 ADDR-REGISTRATION-REQUEST message 191 The ADDR-REGISTRATION-REQUEST message MUST NOT contain server- 192 identifier option and MUST contain the IA Address option and the 193 DHCPv6 FQDN option [RFC4704]. The ADDR-REGISTRATION-REQUEST message 194 is dedicated for clients to initiate an address registration request 195 toward an address registration server. Consequently, clients MUST 196 NOT put any Option Request Option(s) in the ADDR-REGISTRATION-REQUEST 197 message. 199 Clients MUST discard any received ADDR-REGISTRATION-REQUEST messages. 201 Servers MUST discard any ADDR-REGISTRATION-REQUEST messages that meet 202 any of the following conditions: 204 o the message does not include a Client Identifier option; 206 o the message includes a Server Identifier option; 208 o the message does not include at least one IA Address option; 210 o the message does not include FQDN option (or include multiple FQDN 211 options); 213 o the message includes an Option Request Option. 215 5. DHCPv6 Address Registration Procedure 217 The DHCPv6 protocol is used as the address registration protocol when 218 a DHCPv6 server performs the role of an address registration server. 219 The DHCPv6 IA Address option [RFC3315] and the DHCPv6 FQDN option 221 [RFC4704] are adopted in order to fulfill the address registration 222 interactions. 224 5.1. DHCPv6 Address Registration Request 226 The end-host sends a DHCPv6 ADDR-REGISTRATION-REQUEST message to the 227 address registration server to the All_DHCP_Relay_Agents_and_Servers 228 multicast address (ff02::1:2). 230 The end-host MUST include a Client Identifier option in the ADDR- 231 REGISTRATION-REQUEST message to identify itself to the server. The 232 DHCPv6 ADDR-REGISTRATION-REQUEST message MUST contain at least one IA 233 Address option and exactly one FQDN option. The valid-lifetime field 234 of the IA Address option MUST be set to the period for which the 235 client would like to register the binding in DNS. 237 After receiving this ADDR-REGISTRATION-REQUEST message, the address 238 registration server MUST register the binding between the provided 239 FQDN and address(es) in DNS. If the DHCPv6 server does not support 240 address registration function, it MUST sliently drop the message. 242 5.2. Registration Expiry and Refresh 244 For every successful binding registration, the address registration 245 server MUST record the IPv6-address-to-FQDN bindings and associated 246 valid-lifetimes in its storage. 248 The address registration client MUST refresh the registration before 249 it expires (i.e. before the valid-lifetime of the IA address elapses) 250 by sending a new ADDR-REGISTRATION-REQUEST to the address 251 registration server. If the address registration server does not 252 receive such a refresh after the valid-lifetime has passed, it SHOULD 253 remove the IPv6-address-to-FQDN bindings in DNS, also the local 254 record. 256 It is RECOMMENDED that clients initiate a refresh at about 85% of the 257 valid-lifetime. Because RAs may periodically 'reset' the valid- 258 lifetime, the refresh timer MUST be independently maintained from the 259 address valid-lifetime. Clients SHOULD set a refresh timer to 85% of 260 the valid-lifetime when they complete a registration operation and 261 only update this timer if 85% of any updated valid-lifetime would be 262 sooner than the timer. 264 5.3. Acknowledging Registration and Retransmission 266 After an address registration server accepts an address registration 267 request, it MUST send a Reply message as the response to the client. 268 The acceptence reply only means that the server has taken 269 responsiblity to registry for the client. It may not have actually 270 completed the update yet. The server is responsible to register all 271 the addresses in DNS. The server generates a Reply message and 272 includes a Status Code option with value Success, a Server Identifier 273 option with the server's DUID, and a Client Identifier option with 274 the client's DUID. 276 If there is no reply received within some interval, the client SHOULD 277 retransmits the message according to section 14 of [RFC3315], using 278 the following parameters: 280 o IRT ADDR_REG_TIMEOUT 282 o MRT ADDR_REG_MAX_RT 284 o MRC ADDR_REG_MAX_RC 286 o MRD 0 288 The below presents a table of values used to describe the message 289 transmission behavior of clients and servers: 291 Parameter Default Description 292 --------------------------------------------------------------------- 293 ADDR_REG_TIMEOUT 1 secs Initial Addr Registration Request timeout 294 ADDR_REG_MAX_RT 60 secs Max Addr Registration Request timeout value 295 ADDR_REG_MAX_RC 5 Max Request retry attempts 297 For each IA Address option in the ADDR-REGISTRATION-REQUEST message 298 for which the server does not accept its associated registration 299 request, the server adds an IA Address option with the associated 300 IPv6 address, and includes a Status Code option with the value 301 RegistrationDenied (TBA2) in the IA Address option. No other options 302 are included in the IA Address option. 304 Upon receiving a RegistrationDenied error status code, the client MAY 305 also resend the message following normal retransmission routines 306 defined in [RFC3315] with above parameters. The client MUST wait out 307 the retransmission time before retrying. 309 6. Security Considerations 311 An attacker may attempt to register large number of addresses in 312 quick succession in order to overwhelm the address registration 313 server. These attacks may be prevented generic DHCPv6 protection by 314 using the AUTH option [RFC3315] or Secure DHCPv6 315 [I-D.ietf-dhc-sedhcpv6]. 317 7. IANA Considerations 319 This document defines a new DHCPv6 message, the ADDR-REGISTRATION- 320 REQUEST message (TBA1) described in Section 4, that requires an 321 allocation out of the registry of Message Types defined at 322 http://www.iana.org/assignments/dhcpv6-parameters/ 324 Value Description Reference 325 ----------------------------------------------------- 326 TBA1 ADDR-REGISTRATION-REQUEST this document 328 This document defines a new DHCPv6 Status code, the 329 RegistrationDenied (TBA2) described in Section 5, that requires an 330 allocation out of the registry of Status Codes defined at 331 http://www.iana.org/assignments/dhcpv6-parameters/ 333 Code Name Reference 334 ---------------------------------------------------- 335 TBA2 RegistrationDenied this document 337 8. Acknowledgements 339 The authors would like to thank Ralph Droms, Ted Lemon, Bernie Volz, 340 Sten Carlsen, Erik Kline, Lorenzo Colitti, Joel Jaeggli, Sten 341 Carlsen, Mark Smith, Marcin Siodelski, Darpan Malhotra, Tomek 342 Mrugalski, Jinmei Tatuya and other members of dhc and v6ops working 343 groups for their valuable comments. 345 9. References 347 9.1. Normative References 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 353 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 354 RFC 2136, April 1997. 356 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 357 and M. Carney, "Dynamic Host Configuration Protocol for 358 IPv6 (DHCPv6)", RFC 3315, July 2003. 360 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 361 RFC 3972, March 2005. 363 [RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified 364 Domain Name (FQDN) Conflicts among Dynamic Host 365 Configuration Protocol (DHCP) Clients", RFC 4703, October 366 2006. 368 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 369 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 370 Option", RFC 4704, October 2006. 372 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 373 Address Autoconfiguration", RFC 4862, September 2007. 375 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 376 Extensions for Stateless Address Autoconfiguration in 377 IPv6", RFC 4941, September 2007. 379 9.2. Informative References 381 [I-D.ietf-dhc-sedhcpv6] 382 Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure 383 DHCPv6 with Public Key", draft-ietf-dhc-sedhcpv6-03 (work 384 in progress), June 2014. 386 Authors' Addresses 388 Sheng Jiang 389 Huawei Technologies Co., Ltd 390 Q14, Huawei Campus 391 No.156 Beiqing Road 392 Hai-Dian District, Beijing 100095 393 P.R. China 395 Email: jiangsheng@huawei.com 397 Gang Chen 398 China Mobile 399 53A, Xibianmennei Ave., Xuanwu District, Beijing 400 P.R. China 402 Phone: 86-13910710674 403 Email: phdgang@gmail.com 404 Suresh Krishnan 405 Ericsson 406 8400 Decarie Blvd. 407 Town of Mount Royal, QC 408 Canada 410 Phone: +1 514 345 7900 x42871 411 Email: suresh.krishnan@ericsson.com 413 Rajiv Asati 414 Cisco Systems, Inc. 415 7025 Kit Creek road 416 Research Triangle Park, NC 27709-4987 417 USA 419 Email: rajiva@cisco.com