idnits 2.17.00 (12 Aug 2021) /tmp/idnits49278/draft-lemon-dhc-inventory-02.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 (Using the creation date from RFC3315, updated by this document, for RFC5378 checks: 1995-02-03) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2013) is 3126 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Lemon 3 Internet-Draft Nominum, Inc. 4 Updates: 3315 (if approved) October 22, 2013 5 Intended status: Standards Track 6 Expires: April 25, 2014 8 Techniques for Tracking Inventory Using DHCPv6 DUID 9 draft-lemon-dhc-inventory-02 11 Abstract 13 In the years since DHCPv4 gained widespread popularity, one of the 14 uses to which organizations have put it is inventory tracking: 15 associating identifiers scanned from packaging with records in an 16 inventory database. This document describes various means for 17 accomplishing the same purpose using DHCPv6. This document also 18 updates RFC3315 by clarifying the meaning of some normative language 19 regarding the DUID-LL and DUID-LLT DUID types. 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 April 25, 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 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Scope of applicability . . . . . . . . . . . . . . . . . 3 70 2. General Mechanism . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1. Entering a new device into inventory . . . . . . . . . . 4 72 2.2. Distributing the new device . . . . . . . . . . . . . . . 5 73 2.3. First appearance on the network . . . . . . . . . . . . . 5 74 3. Using DUID-LL or DUID-LLT . . . . . . . . . . . . . . . . . . 7 75 4. Using the DHCPv6 Client Link-layer Address Option . . . . . . 8 76 5. Which algorithm to use . . . . . . . . . . . . . . . . . . . 8 77 6. New labeling requirements . . . . . . . . . . . . . . . . . . 8 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 10.2. Informative References . . . . . . . . . . . . . . . . . 10 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 In DHCPv4 DHCPv4 [RFC2131], the link-layer address of a DHCP client 89 is commonly used to identify the client. The link-layer address 90 appears in the chaddr field of the DHCP packet, and is also 91 frequently included in the Client Identifier option. 93 Not coincidentally, the link-layer addresses of network devices are 94 almost always present as bar codes and machine-readable text on the 95 outside of the boxes in which these devices are delivered. This is 96 true of most mobile phones, laptop computers, desktop computers, 97 network routers and switches, and so on. 99 Services providers and enterprises have taken advantage of these two 100 facts in their inventory tracking systems: when a new device arrives, 101 the bar codes are scanned into a database, and an inventory tracking 102 number is assigned to the device. When the device is assigned to a 103 user or to a use, that information can be added to the database. 105 This means that, for example, when a network router is installed, the 106 inventory tracking system can be updated both with the physical 107 location of the router and with its intended purpose: for example, 108 "router between backbone and first floor network." This information 109 can in turn be used to provision the router: to send it a 110 configuration. When a router is replaced, the provisioning system 111 can then automatically configure the new router simply by knowing 112 that it is the "router between backbone and first floor network"; 113 DHCPv4 takes care of noticing that the device is new on the network, 114 and that can trigger the provisioning of the device. 116 Unlike DHCPv4, DHCPv6 [RFC3315] does not directly make use of a 117 device's link-layer address as an identifier. This is because the 118 link-layer address is specific to an interface, and it was considered 119 useful to be able to notice that requests being issued on multiple 120 interfaces related to the same device. It was also considered useful 121 that the device's identifier remain stable when network hardware was 122 added or removed. 124 Consequently, the inventory management solution in DHCPv6 is somewhat 125 more complicated than that in DHCPv4. This document describes 126 several mechanisms that are available to administrators to address 127 this concern. 129 1.1. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 1.2. Scope of applicability 137 This document is intended to provide guidance to implementors of DHCP 138 servers, network device inventory management systems and provisioning 139 systems as to how to connect information sent over the network by 140 devices with the physical devices that sent the information. 142 Nothing in this document should be construed as a requirement for 143 such systems; rather, it is intended as helpful advice. The 144 normative language in the document applies to implementations that 145 attempt to follow the advice given in this document, and is not 146 intended to apply to systems that solve the same problem in different 147 ways. 149 2. General Mechanism 151 This mechanism takes as its input two pieces of information: one of 152 the link-layer addresses of a device, and the DUID of the device. If 153 the DUID is known, the link-layer address MUST be ignored. If the 154 DUID is unknown, the link-layer address is used to find the the 155 inventory record for the device, and then the the DUID is added to 156 the inventory record. 158 2.1. Entering a new device into inventory 160 We assume that when a new device arrives, the box has one bar code on 161 the side for the link layer address of each network interface on the 162 device. The person responsible for receiving the device scans each 163 bar code off of the box. This person then generates an inventory 164 control tag for the device, and scans that into the system as well. 165 The inventory control tag is affixed to the device in a location 166 where it can be easily scanned or read in the future. 168 Suppose a new router arrives. It has two network interfaces: one 169 with a link-layer address of 00:53:01:1f:24:32 and one with a link- 170 layer address of 00:53:02:05:49:ad. The device is assigned an 171 inventory control tag number of 11029938. This will produce several 172 rows in a database table listing link-layer addresses: 174 +--------------------+------------------+ 175 | link-layer address | inventory number | 176 +--------------------+------------------+ 177 | 00:53:01:1f:24:32 | 11029938 | 178 | 00:53:02:05:49:ad | 11029938 | 179 +--------------------+------------------+ 181 Table 1: Link Layer address to Inventory Table 183 It will also produce one additional row in a database table listing 184 inventory items: 186 +------------------+-------------+------+-------+------+ 187 | inventory number | description | DUID | user? | use | 188 +------------------+-------------+------+-------+------+ 189 | 11029938 | router | NULL | false | NULL | 190 +------------------+-------------+------+-------+------+ 192 Table 2: Inventory Items Table 194 Note that the DUID and use fields are NULL at this point, because the 195 device hasn't yet been assigned a user, and has never been connected 196 to the network. The user field in this example is a flag indicating 197 whether the device will be assigned to the user (true), or is 198 infrastructure equipment (false). 200 2.2. Distributing the new device 202 Eventually the new device is moved from inventory to its intended 203 use: either on a machine room rack somewhere, or to a user's desk, 204 for example. When this happens, the inventory record is updated; the 205 link layer address records are not: 207 +------------------+-------------+------+-------+-----------------+ 208 | inventory number | description | DUID | user? | use | 209 +------------------+-------------+------+-------+-----------------+ 210 | 11029938 | router | NULL | false | bb::first floor | 211 +------------------+-------------+------+-------+-----------------+ 213 Table 3: Inventory Items Table (distributed) 215 In this example the router is marked with a token that will be 216 meaningful to the provisioning system: "backbone::first floor". 218 2.3. First appearance on the network 220 Now the device is plugged into a rack in a distribution closet; one 221 network interface is plugged into the backbone network; the other is 222 plugged into the cascade of switches that support the first floor 223 network. The device is powered on. 225 When the device is powered on, it first does router solicitation and 226 gets a prefix on the backbone network (we assume that there is no 227 router on the first floor network, so it doesn't get a prefix there). 228 The prefix is marked with the 'M' bit, indicating that this is a 229 managed network, so the router issues a DHCP Solicit message. 231 The solicit messages is received by the DHCP server. The DHCP server 232 does not have a record of the DUID presented by the router, so it 233 logs it as unknown in the provisioning system and does nothing 234 further. The DHCP server provides both the link-layer address of the 235 router's interface on the backbone network, and the DUID that the 236 router presented. 238 If the DHCP server and router are connected to the same physical 239 link, the DHCP server can acquire the router's link-layer address 240 from the link-layer framing of the DHCP Solicit message. Otherwise, 241 the server must obtain the link-layer address using the techniques 242 described in Sections 3 or, if possible, 4. 244 In this example we'll assume that the link-layer address the router 245 sent is 00:53:01:1f:24:32, and that the DUID is 246 00:03:00:01:00:53:02:05:49:ad. 248 The provisioning system takes the log entry for the unknown device 249 and does a lookup in the Inventory Items table for the DUID that the 250 router presented. The DUID is not in the table, so the provisioning 251 system gets an empty result table, indicating that the DUID is 252 currently unknown to the provisioning system. 254 The provisioning system then looks up the link-layer address in the 255 Link Layer Address to Inventory table. This produces a result table 256 with a single row: 258 +--------------------+------------------+ 259 | link-layer address | inventory number | 260 +--------------------+------------------+ 261 | 00:53:01:1f:24:32 | 11029938 | 262 +--------------------+------------------+ 264 Table 4: Link Layer address to Inventory Result Table 266 The provisioning system now uses the inventory number to find the 267 inventory table entry and update it with the DUID; after this is 268 done, the record looks like this: 270 +-----------+-------------+-------------------+---------+-----------+ 271 | inventory | description | DUID | user? | use | 272 | number | | | | | 273 +-----------+-------------+-------------------+---------+-----------+ 274 | 11029938 | router | 00:03:00:01 | false | bb::first | 275 | | | 00:53:02:05:49:ad | | floor | 276 +-----------+-------------+-------------------+---------+-----------+ 278 Table 5: Inventory Items Table (finished) 280 The provisioning system now has enough information to configure the 281 DHCP server with an IP address specific to the router, and to 282 configure the router itself with information about prefixes on the 283 first floor network. How this is done is beyond the scope of this 284 document. 286 3. Using DUID-LL or DUID-LLT 288 RFC3315 defines the DHCP Unique Identifier (DUID) and describes 289 several different formats suited to various uses. Two of those 290 formats, DUID-LL and DUID-LLT, include the link-layer address of the 291 client. RFC3315 states: 293 Clients and servers MUST treat DUIDs as opaque values and MUST 294 only compare DUIDs for equality. Clients and servers MUST NOT in 295 any other way interpret DUIDs. Clients and servers MUST NOT 296 restrict DUIDs to the types defined in this document, as 297 additional DUID types may be defined in the future. 299 This text is specifically intended to exclude the possibility that 300 the DHCP server might treat some portion of the DUID, rather than the 301 entire DUID, as a unique identifier for the client. However, the 302 text is stated so unequivocally that it is often interpreted to mean 303 that it's not permissible to look at the contents of the option for 304 any other reason; this was not the original intent of the 305 requirement. 307 We therefore update the above paragraph from RFC3315 as follows: 309 Clients and servers MUST NOT use any part of a DUID as a unique 310 identifier. Clients and servers MUST use the entire contents of 311 the DUID as an opaque token for the purpose of uniquely 312 identifying the client. Clients and servers MUST NOT restrict 313 DUIDs to the types defined in this document, as additional DUID 314 types may be defined in the future. Clients and servers MAY use 315 the semantic contents of the DUID to generate a one-time mapping 316 between a link-layer address known to be configured in a specific 317 device, and that device's DUID. 319 This change to RFC3315 allows DHCP servers or provisioning systems to 320 use the link-layer address from a DUID-LL or DUID-LLT as input to the 321 process described in Section 2 for mapping the DUID to a specific 322 device in an inventory database. 324 It is important to note that the usual reason for using a DUID-LLT, 325 as opposed to a DUID, is that the network interface used to generate 326 the DUID-LLT is not permanently installed in the device. This means 327 that there is no assurance that a device that came with a removable 328 network interface will not have a new interface installed when it 329 generates its DUID. In that case, the device will present an unknown 330 link-layer address to the DHCP server in the DUID-LLT. 332 For this reason, nodes that contain both removable and fixed 333 interfaces MUST use the link-layer address of a fixed interface when 334 generating a DUID-LL or DUID-LLT. Devices using the link-layer 335 address of a fixed interface to generate the DUID SHOULD use DUID-LL, 336 not DUID-LLT, since there is no benefit to the additional timestamp 337 in DUID-LLT. 339 4. Using the DHCPv6 Client Link-layer Address Option 341 The DHCPv6 Client Link-layer Address option [RFC6939] is a new DHCPv6 342 extension which allows the DHCPv6 relay agent to include the client's 343 link-layer address as an option in the RELAY-FORW message. The DHCP 344 server can use the provided link-layer address as a key in the lookup 345 described in Section 2. Note that the link-layer address will come 346 from the RELAY-FORW message, but the DUID to be mapped will come from 347 the inner encapsulated packet-\u002Dfor example, a DHCP Solicit or 348 other client-sourced packet. 350 5. Which algorithm to use 352 Since the use of DUID-LL and DUID-LLT is not required, it is best not 353 to rely on these DUIDs as a source for the client's link-layer 354 address. If the client is connected to the same link as the server, 355 the server SHOULD use the link-layer address presented by the client 356 for the inventory table lookup. If the client is configured through 357 a relay, and the relay provides the Client Link-layer Address option, 358 the server SHOULD use the contents of that option to identify the 359 client. 361 6. New labeling requirements 363 The extra work involved in matching link-layer addresses to DUIDs is 364 only necessary because network equipment boxes typically only have 365 bar code labels for link-layer addresses and not for DUIDs. It would 366 greatly simplify inventory management for dual-stack and IPv6-only 367 sites if these boxes were additionally labeled with DUIDs. 369 However, this is not as simple as it sounds. The problem is the 370 DUID, like a link-layer address, is simply a sequence of octets. A 371 bar code containing a DUID would therefore be difficult to reliably 372 distinguish from a link-layer address. It might be possible for the 373 person receiving the box to scan only the DUID. However, this is an 374 extra bit of training that would be required, and of course it is 375 error-prone. 377 For this reason, manufacturers of DHCPv6-capable network hardware 378 with predetermined DUIDs are strongly encouraged to add a bar code 379 label to the box containing the equipment with a DUID that matches 380 the following ABNF [RFC5234]: 382 label = "DUID:" hex-sequence 383 hex-sequence = hex-octet * ( ":" hex-sequence ) 384 hex-octet = hex-digit hex-digit 385 hex-digit = %x30 - %x39 / %x41 - %x46 387 For example, a device with a DUID in the DUID-LL format might might 388 have a bar code that reads as follows: 390 DUID:00:03:00:01:08:00:2b:4c:3d:9f 392 7. Acknowledgments 394 This document was motivated by my realization during a private 395 conversation with Leaf Yeh that although this technique for mapping 396 client link-layer addresses to inventory tracking systems is well- 397 known to some experts in the DHCPv4 and DHCPv6 user community, it has 398 not been documented by the IETF, and that readers of RFC2131 and 399 RFC3315 might therefore be unaware that this usage pattern exists. 401 Thanks to Sten Carlsen, Niall O'Reilly and Simon Hobson for their 402 careful review and discussion of this work. 404 8. Security Considerations 406 DHCP servers rely on information provided by the DHCP client to 407 identify the client. In DHCPv6, the server typically relies on the 408 DUID to uniquely identify the client; unless the DHCP packet is 409 authenticated in some way, one clients can masquerade as another by 410 presenting that client's DUID instead of its own. 412 This document proposes using one of the client's link-layer addresses 413 as a means of identifying the client when it first connects to the 414 network. This mechanism presents the same sorts of risks as does 415 using the DUID to identify the client. Existing mitigation 416 strategies in RFC3315 will work equally well to prevent clients from 417 presenting fraudulent link-layer identifiers. 419 In addition, there are several factors that make this less of an 420 issue with the mechanisms described in this document. First, the 421 link-layer address is only used as an identifier the first time the 422 client connects to the network; like leap-of-faith authentication, 423 this presents a very brief window of opportunity for an attack using 424 the link-layer address. 426 Secondly, because the attack has to occur the first time the client 427 connects to the network, it's more complicated to effect the attack: 429 the attacker has to snoop the link-layer address from the wire, and 430 then attempt a DHCP transaction before the legitimate client starts 431 its DHCP transaction. Provisioning software can detect such an 432 attack, because two conflicting records for the same client will 433 appear in the log in quick succession. If the attacker happens to 434 guess the same DUID that the client chooses, this attack has no 435 effect at all, since the correct information will be entered into the 436 database. 438 9. IANA Considerations 440 The IANA is hereby absolved of any requirement to take any action in 441 relation to this document. 443 10. References 445 10.1. Normative References 447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 448 Requirement Levels", BCP 14, RFC 2119, March 1997. 450 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 451 and M. Carney, "Dynamic Host Configuration Protocol for 452 IPv6 (DHCPv6)", RFC 3315, July 2003. 454 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 455 Specifications: ABNF", STD 68, RFC 5234, January 2008. 457 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 458 Address Option in DHCPv6", RFC 6939, May 2013. 460 10.2. Informative References 462 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 463 2131, March 1997. 465 Author's Address 467 Ted Lemon 468 Nominum, Inc. 469 2000 Seaport Blvd 470 Redwood City, CA 94063 471 USA 473 Phone: +1-650-381-6000 474 Email: Ted.Lemon@nominum.com