idnits 2.17.1 draft-ietf-dhc-addr-registration-03.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 (August 29, 2013) is 3892 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 246, but no explicit reference was found in the text == Unused Reference: 'RFC3971' is defined on line 250, 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: March 2, 2014 China Mobile 6 S. Krishnan 7 Ericsson 8 August 29, 2013 10 Registering self-generated IPv6 Addresses in DNS using DHCPv6 11 draft-ietf-dhc-addr-registration-03 13 Abstract 15 In networks that are centrally managed, self-generated addresses 16 cause some traceability issues due to their decentralized nature. 17 One of the most important issues in this regard is the inability to 18 register such addresses in DNS. This document defines a mechanism to 19 register self-generated addresses in DNS through a DHCPv6 server. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 2, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. DHCPv6 ADDR-REGISTRATION-REQUEST Message . . . . . . . . . . . 4 59 5. DHCPv6 Address Registration Procedure . . . . . . . . . . . . . 5 60 5.1. DHCPv6 Address Registration Request . . . . . . . . . . . . 5 61 5.2. Acknowledging successful registration . . . . . . . . . . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 In several common network scenarios, IPv6 addresses are self- 73 generated by the end-hosts by appending a self-generated interface 74 identifier to a network-specified prefix. Examples of self-generated 75 addresses include those created using IPv6 Stateless Address 76 Configuration [RFC4862] , temporary addresses [RFC4941] and 77 Cryptographically Generated Addresses (CGA) [RFC3972] etc. In 78 several tighly controlled networks, hosts with self-generated 79 addresses may face some limitations. One such limitation is related 80 to the inability of nodes with self-generated addresses to register 81 their IPv6-address-to-FQDN bindings in DNS. This is related to the 82 fact that, in such networks, only certain nodes (e.g. The DHCPv6 83 server) are allowed to update these bindings in order to prevent end- 84 hosts from registering arbitrary addresses for their FQDNs or 85 associating their addresses with arbitrary domain names. 87 For nodes that obtain their addresses through DHCPv6, a solution has 88 been specified in [RFC4704]. The solution works by including a 89 Client FQDN option in the SOLICIT, REQUEST, RENEW or REBIND messages 90 during the process of acquiring an address through DHCPv6. This 91 document provides an analogous mechanism to register self-generated 92 addresses in DNS. 94 A new ADDR-REGISTRATION-REQUEST DHCPv6 message type is defined to 95 initiate the address registration request, and two new Status codes 96 is defined to indicate registration errors on the server side. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. Solution Overview 106 After successfully assigning a self-generated IPv6 address on one of 107 its interfaces, an end-host implementing this specification SHOULD 108 send an ADDR-REGISTRATION-REQUEST message to a DHCPv6 address 109 registration server. After receiving the address registration 110 request, the DHCPv6 server registers the IPv6 address to FQDN binding 111 towards a configured DNS server. An acknowledgement MAY be sent back 112 to the end host to indicate whether or not the registration operation 113 succeeded.. 115 +----+ +-----------+ +---------------+ 116 |Host| |Edge router| |Addr-Reg Server| 117 +----+ +-----------+ +---------------+ 118 | SLAAC | | 119 |<--------->| | 120 | | 121 | ADDR-REGISTRATION-REQUEST | 122 |------------------------------------->| 123 | |Register 124 | |address 125 | Optional Acknowledgment |in DNS 126 |<-------------------------------------| 128 Figure 1: Address Registration Procedure 130 4. DHCPv6 ADDR-REGISTRATION-REQUEST Message 132 The DHCPv6 client sends an ADDR-REGISTRATION-REQUEST message to a 133 server to request an address to be registered in the DNS. The format 134 of the ADDR-REGISTRATION-REQUEST message is described as follows: 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | msg-type | transaction-id | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 . options . 143 . (variable) . 144 | | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 msg-type Identifies the DHCPv6 message type; 147 Set to ADDR-REGISTRATION-REQUEST (TBA1). 149 transaction-id The transaction ID for this message exchange. 151 options Options carried in this message. 153 DHCPv6 ADDR-REGISTRATION-REQUEST message 155 The ADDR-REGISTRATION-REQUEST message MUST NOT contain server- 156 identifier option and MUST contain the IA_NA option and the DHCPv6 157 FQDN option [RFC4704]. 159 Clients MUST discard any received ADDR-REGISTRATION-REQUEST messages. 160 Servers MUST discard any ADDR-REGISTRATION-REQUEST messages that do 161 not include a Client Identifier option or that do include a Server 162 Identifier option. 164 5. DHCPv6 Address Registration Procedure 166 The DHCPv6 protocol is used as the address registration protocol when 167 a DHCPv6 server performs the role of an address registration server. 168 The DHCPv6 IA_NA option [RFC3315] and the DHCPv6 FQDN option 169 [RFC4704] are reused in order to fulfill the address registration 170 interactions. 172 5.1. DHCPv6 Address Registration Request 174 The end-host sends a DHCPv6 ADDR-REGISTRATION-REQUEST message to the 175 address registration server to the All_DHCP_Relay_Agents_and_Servers 176 multicast address (ff02::1:2). 178 The end-host MUST include a Client Identifier option in the ADDR- 179 REGISTRATION-REQUEST message to identify itself to the server. The 180 DHCPv6 ADDR-REGISTRATION-REQUEST message MUST contain exactly one 181 IA_NA option and exactly one FQDN option. The IA_NA option MUST 182 contain at least one IA Address option. 184 After receiving this ADDR-REGISTRATION-REQUEST message, the address 185 registration server MUST register the binding between the provided 186 FQDN and address(es) in DNS. If the DHCPv6 server does not support 187 address registration function, a Reply message with includes a Status 188 Code option with the value the RegistrationNotSupported (TBA2) MAY be 189 sent back to the initiated client. 191 5.2. Acknowledging successful registration 193 After all the addresses have been successfully registered in DNS, the 194 address registration server MAY send a Reply message as the response 195 to registration requests. The server generates a Reply message and 196 includes a Status Code option with value Success, a Server Identifier 197 option with the server's DUID, and a Client Identifier option with 198 the client's DUID. For each IA in the Release message for which the 199 server does not succeed in registering, the server adds an IA option 200 using the IAID from the ADDR-REGISTRATION-REQUEST message, and 201 includes a Status Code option with the value RegistrationDenied 202 (TBA3) in the IA option. No other options are included in the IA 203 option. 205 6. Security Considerations 207 An attacker may attempt to register large number of addresses in 208 quick succession in order to overwhelm the address registration 209 server. These attacks may be prevented generic DHCPv6 protection by 210 using the AUTH option [RFC3315] or Secure DHCPv6 211 [I-D.ietf-dhc-secure-dhcpv6]. 213 7. IANA Considerations 215 This document defines a new DHCPv6 message, the ADDR-REGISTRATION- 216 REQUEST message (TBA1) described in Section 5, that requires an 217 allocation out of the registry defined at 219 http://www.iana.org/assignments/dhcpv6-parameters/ 221 This document defines two new DHCPv6 Status code, the 222 RegistrationNotSupported (TBA2) and RegistrationDenied (TBA3) 223 described in Section 6, that requires an allocation out of the 224 registry defined at 226 http://www.iana.org/assignments/dhcpv6-parameters/ 228 8. Acknowledgements 230 The authors would like to thank Ralph Droms, Ted Lemon, Bernie Volz, 231 Sten Carlsen, Erik Kline, Lorenzo Colitti, Joel Jaeggli, Sten 232 Carlsen, Mark Smith and other members of dhc and v6ops working groups 233 for their valuable comments. 235 9. References 237 9.1. Normative References 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, March 1997. 242 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 243 and M. Carney, "Dynamic Host Configuration Protocol for 244 IPv6 (DHCPv6)", RFC 3315, July 2003. 246 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 247 Host Configuration Protocol (DHCP) version 6", RFC 3633, 248 December 2003. 250 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 251 Neighbor Discovery (SEND)", RFC 3971, March 2005. 253 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 254 RFC 3972, March 2005. 256 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 257 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 258 Option", RFC 4704, October 2006. 260 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 261 Address Autoconfiguration", RFC 4862, September 2007. 263 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 264 Extensions for Stateless Address Autoconfiguration in 265 IPv6", RFC 4941, September 2007. 267 9.2. Informative References 269 [I-D.ietf-dhc-secure-dhcpv6] 270 Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", 271 draft-ietf-dhc-secure-dhcpv6-07 (work in progress), 272 September 2012. 274 Authors' Addresses 276 Sheng Jiang 277 Huawei Technologies Co., Ltd 278 Q14, Huawei Campus 279 No.156 Beiqing Road 280 Hai-Dian District, Beijing 100095 281 P.R. China 283 Email: jiangsheng@huawei.com 285 Gang Chen 286 China Mobile 287 53A, Xibianmennei Ave., Xuanwu District, Beijing 288 P.R. China 290 Phone: 86-13910710674 291 Email: phdgang@gmail.com 292 Suresh Krishnan 293 Ericsson 294 8400 Decarie Blvd. 295 Town of Mount Royal, QC 296 Canada 298 Phone: +1 514 345 7900 x42871 299 Email: suresh.krishnan@ericsson.com