idnits 2.17.1 draft-wkumari-dhc-addr-notification-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 : ---------------------------------------------------------------------------- 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 (7 March 2022) is 780 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration W. Kumari 3 Internet-Draft Google, LLC 4 Intended status: Experimental S. Krishnan 5 Expires: 8 September 2022 Kaloom 6 S. Jiang 8 R. Asati 9 Cisco Systems, Inc. 10 7 March 2022 12 Registering Self-generated IPv6 Addresses using DHCPv6 13 draft-wkumari-dhc-addr-notification-00 15 Abstract 17 This document defines a method to inform a DHCPv6 server that a 18 device has a self-generated or statically configured address. 20 About This Document 22 This note is to be removed before publishing as an RFC. 24 The latest revision of this draft can be found at 25 https://wkumari.github.io/draft-wkumari-dhc-addr-notification/draft- 26 wkumari-dhc-addr-notification.html. Status information for this 27 document may be found at https://datatracker.ietf.org/doc/draft- 28 wkumari-dhc-addr-notification/. 30 Discussion of this document takes place on the Dynamic Host 31 Configuration Working Group mailing list (mailto:dhcwg@ietf.org), 32 which is archived at https://mailarchive.ietf.org/arch/browse/dhcwg/. 34 Source for this draft and an issue tracker can be found at 35 https://github.com/wkumari/draft-wkumari-dhc-addr-notification. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on 8 September 2022. 54 Copyright Notice 56 Copyright (c) 2022 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Revised BSD License text as 65 described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Revised BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 72 3. Description of Mechanism . . . . . . . . . . . . . . . . . . 4 73 4. DHCPv6 ADDR-REG-NOTIFICATION Message . . . . . . . . . . . . 4 74 5. DHCPv6 Address Registration Procedure . . . . . . . . . . . . 5 75 5.1. DHCPv6 Address Registration Request . . . . . . . . . . . 6 76 5.2. Registration Expiry and Refresh . . . . . . . . . . . . . 6 77 5.3. Acknowledging Registration and Retransmission . . . . . . 7 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 7.1. Value Description Reference . . . . . . . . . . . . . . . 8 81 7.2. Code Name Reference . . . . . . . . . . . . . . . . . . . 9 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 8.2. Informative References . . . . . . . . . . . . . . . . . 9 85 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 89 1. Introduction 91 It is very common operational practice, especially in enterprise 92 networks, to use IPv4 DHCP logs for troubleshooting or security 93 purposes. Examples of this include a helpdesk dealing with a ticket 94 such as "The CEO's laptop cannot connect to the printer"; if the MAC 95 address of the printer is known (for example from an inventory 96 system), the IPv4 address can be retrieved from the DHCP logs and the 97 printer pinged to determine if it is reachable. Another common 98 example is a Security Operations team discovering suspicious events 99 in outbound firewall logs and then consulting DHCP logs to determine 100 which employee's laptop had that IPv4 address at that time so that 101 they can quarantine it and remove the malware. 103 This operational practice relies on the DHCP server knowing the IP 104 address assignments. Therefore, the practice does not work if static 105 IP addresses are manually configured on devices or self-assigned 106 addresses (such as when self-configuring an IPv6 address using SLAAC 107 [RFC4862]) are used. 109 The lack of this parity with IPv4 is one of the reasons that some 110 enterprise networks are unwilling to deploy IPv6. 112 This document provides a mechanism for a device to inform the DHCPv6 113 server that it has a self-configured IPv6 address (or has a 114 statically configured address), and thus provides parity with IPv4 in 115 this aspect. 117 This document borrows heavily from a previous document, draft-ietf- 118 dhc-addr-registration, which defined "a mechanism to register self- 119 generated and statically configured addresses in DNS through a DHCPv6 120 server". 122 2. Conventions and Definitions 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in 127 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 3. Description of Mechanism 132 After successfully assigning a self-generated IPv6 address on one of 133 its interfaces, an end-host implementing this specification SHOULD 134 send an ADDR-REG-NOTIFICATION message to a DHCPv6 address 135 registration server. After receiving the address registration 136 request, the DHCPv6 server records and logs the IPv6 address. An 137 acknowledgement MUST be sent back to the end host to indicate whether 138 or not the registration operation succeeded. 140 +----+ +-----------+ +---------------+ 141 |Host| |Edge router| |Addr-Reg Server| 142 +----+ +-----------+ +---------------+ 143 | SLAAC | | 144 |<--------->| | 145 | | | 146 | | ADDR-REG-NOTIFICATION | 147 |-------------------------------------------->| 148 | | |Register / log 149 | | |address 150 | | Acknowledgment | 151 |<--------------------------------------------| 153 Figure 1: Address Registration ProcedureAddress Registration 154 Procedure 156 The registration server MAY apply certain filter/accept criteria for 157 address registration requests (for example to deny registration of 158 addresses that are not appropriate for the link, etc.) 160 4. DHCPv6 ADDR-REG-NOTIFICATION Message 162 The DHCPv6 client sends an ADDR-REG-NOTIFICATION message to a server 163 to request that the use of this address be registered and logged. 164 The format of the ADDR-REG-NOTIFICATION message is described as 165 follows: 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | msg-type | transaction-id | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | | 173 . options . 174 . (variable) . 175 | | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 msg-type Identifies the DHCPv6 message type; 178 Set to ADDR-REG-NOTIFICATION (TBA1). 180 transaction-id The transaction ID for this message exchange. 182 options Options carried in this message. 184 Figure 2: DHCPv6 ADDR-REG-NOTIFICATION message 186 The ADDR-REG-NOTIFICATION message MUST NOT contain server-identifier 187 option and MUST contain the IA Address option. The ADDR-REG- 188 NOTIFICATION message is dedicated for clients to initiate an address 189 registration request toward an address registration server. 190 Consequently, clients MUST NOT put any Option Request Option(s) in 191 the ADDR-REG-NOTIFICATION message. 193 Clients MUST discard any received ADDR-REG-NOTIFICATION messages. 195 Servers MUST discard any ADDR-REG-NOTIFICATION messages that meet any 196 of the following conditions: 198 * the message does not include a Client Identifier option; 200 * the message includes a Server Identifier option; 202 * the message does not include at least one IA Address option; 204 * the message includes an Option Request Option. 206 5. DHCPv6 Address Registration Procedure 208 The DHCPv6 protocol is used as the address registration protocol when 209 a DHCPv6 server performs the role of an address registration server. 210 The DHCPv6 IA Address option [RFC3315]is adopted in order to fulfill 211 the address registration interactions. 213 5.1. DHCPv6 Address Registration Request 215 The end-host sends a DHCPv6 ADDR-REG-NOTIFICATION message to the 216 address registration server to the All_DHCP_Relay_Agents_and_Servers 217 multicast address (ff02::1:2). The host SHOULD send the packet from 218 the address being registered. 220 The end-host MUST include a Client Identifier option and at least one 221 IA Address option in the ADDR-REG-NOTIFICATION message. The host 222 SHOULD send separate messages for each address (so each message 223 include only one IA Address option) but MAY send a single packet 224 containing multiple options. 226 The host MUST NOT send the ADDR-REG-NOTIFICATION message for 227 addresses which are not in "preferred" (RFC4862) state. 229 {TODO (WK): DHCPv6 uses "DHCP Unique Identifier (DUID)" to identify 230 clients. This doesn't really meet our design goal of "what IP does 231 the printer have?!". One of the DUID types is "DUID Based on Link- 232 layer Address (DUID-LL)", but this is "any one network interface(s)" 233 - this is probably good enough for the inventory use case, but still 234 not ideal} 236 After receiving this ADDR-REG-NOTIFICATION message, the address 237 registration server MUST register the binding between the provided 238 Client Identifier and IPv6 address. If the DHCPv6 server does not 239 support the address registration function, it MUST drop the message 240 (and may log the event). 242 5.2. Registration Expiry and Refresh 244 For every successful binding registration, the address registration 245 server MUST record the Client-Identifier-to-IPv6-address bindings and 246 associated valid-lifetimes in its storage, and SHOULD log this 247 information in a manner similar to if it had performed the 248 assignment. 250 If a ADDR-REG-NOTIFICATION message updates the existing Client- 251 Identifier-to-IPv6-address binding the server MAY log the event. 253 The address registration client MUST refresh the registration before 254 it expires (i.e. before the preferred lifetime of the IA address 255 elapses) by sending a new ADDR-REG-NOTIFICATION to the address 256 registration server. If the address registration server does not 257 receive such a refresh after the preferred lifetime has passed, it 258 SHOULD remove the record of the Client-Identifier-to-IPv6-address 259 binding. 261 It is RECOMMENDED that clients initiate a refresh at about 85% of the 262 preferred lifetime. Because RAs may periodically 'reset' the 263 preferred- lifetime, the refresh timer MUST be independently 264 maintained from the address valid-lifetime. Clients SHOULD set a 265 refresh timer to 85% of the preferred lifetime when they complete a 266 registration operation and only update this timer if 85% of any 267 updated preferred lifetime would be sooner than the timer. 269 {TODO: is the preferred lifetime a good idea? The default value is 7 270 days which seems rather long. Indeed we might say that it's an 271 administrator's job to configure non-default lifetime... Also, what 272 about statically assigned addresses or PIOs with the inifinite 273 lifetime??} 275 5.3. Acknowledging Registration and Retransmission 277 After an address registration server accepts an address registration 278 request, it MUST send a Reply message as the response to the client. 279 The acceptance reply only means that the server has taken 280 responsibility to remember and log the client, not that it has yet 281 done so. 283 The server generates a Reply message and includes a Status Code 284 option with value Success, a Server Identifier option with the 285 server's DUID, and a Client Identifier option with the client's DUID. 287 If there is no reply received within some interval, the client SHOULD 288 retransmit the message according to section 14 of [RFC3315], using 289 the following parameters: 291 * IRT ADDR_REG_TIMEOUT 293 * MRT ADDR_REG_MAX_RT 295 * MRC ADDR_REG_MAX_RC 297 * MRD 0 299 The below presents a table of values used to describe the message 300 transmission behavior of clients and servers: 302 Parameter Default Description 303 --------------------------------------------------------------------- 304 ADDR_REG_TIMEOUT 1 secs Initial Addr Registration Request timeout 305 ADDR_REG_MAX_RT 60 secs Max Addr Registration Request timeout value 306 ADDR_REG_MAX_RC 5 Max Request retry attempts 307 For each IA Address option in the ADDR-REG-NOTIFICATION message for 308 which the server does not accept its associated registration request, 309 the server adds an IA Address option with the associated IPv6 310 address, and includes a Status Code option with the value 311 RegistrationDenied (TBA2) in the IA Address option. No other options 312 are included in the IA Address option. 314 Upon receiving a RegistrationDenied error status code, the client MAY 315 also resend the message following normal retransmission routines 316 defined in [RFC3315] with above parameters. The client MUST wait out 317 the retransmission time before retrying. 319 6. Security Considerations 321 An attacker may attempt to register a large number of addresses in 322 quick succession in order to overwhelm the address registration 323 server and / or fill up log files. These attacks may be mitigated by 324 using generic DHCPv6 protection such as the AUTH option [RFC3315]. 326 One of the primary use-cases for the mechanism described in this 327 document is to identify which device is infected with malware (or is 328 otherwise doing bad things) so that it can be blocked from accessing 329 the network. As the device itself is responsible for informing the 330 DHCPv6 server that it is using an address, malware (or a malicious 331 client) can simply not send the ADDR-REG-NOTIFICATION message. This 332 is an informational, optional mechanism, and is designed to aid in 333 debugging. It is not intended to be a strong security access 334 mechanism. 336 7. IANA Considerations 338 This document defines a new DHCPv6 message, the ADDR-REG-NOTIFICATION 339 message (TBA1) described in Section 4, that requires an allocation 340 out of the registry of Message Types defined at 341 http://www.iana.org/assignments/dhcpv6-parameters/ 343 7.1. Value Description Reference 345 TBA1 ADDR-REG-NOTIFICATION this document 347 This document defines a new DHCPv6 Status code, the 348 RegistrationDenied (TBA2) described in Section 5, that requires an 349 allocation out of the registry of Status Codes defined at 350 http://www.iana.org/assignments/dhcpv6-parameters/ 352 7.2. Code Name Reference 354 TBA2 RegistrationDenied this document 356 8. References 358 8.1. Normative References 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, 362 DOI 10.17487/RFC2119, March 1997, 363 . 365 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 366 C., and M. Carney, "Dynamic Host Configuration Protocol 367 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 368 2003, . 370 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 371 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 372 May 2017, . 374 8.2. Informative References 376 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 377 Address Autoconfiguration", RFC 4862, 378 DOI 10.17487/RFC4862, September 2007, 379 . 381 Acknowledgments 383 "We've Been Trying To Reach You About Your Car's Extended Warranty" 385 Much thanks to Jen Linkova for additional text on client behavior. 386 Also, much thanks to Erik Kline and Lorenzo Colitti for significant 387 discussion and feedback. 389 Contributors 391 Gang Chen 392 China Mobile 393 53A, Xibianmennei Ave. 394 Xuanwu District 395 Beijing 396 P.R. China 397 Email: phdgang@gmail.com 399 Authors' Addresses 401 Warren Kumari 402 Google, LLC 403 Email: warren@kumari.net 405 Suresh Krishnan 406 Kaloom 407 Email: suresh@kaloom.com 409 Sheng Jiang 410 Beijing 411 P.R. China 412 Email: jiangsheng@gmail.com 414 Rajiv Asati 415 Cisco Systems, Inc. 416 7025 Kit Creek road 417 Research Triangle Park, 27709-4987 418 United States of America 419 Email: rajiva@cisco.com