Techniques for Tracking Inventory Using DHCPv6 DUID
draft-lemon-dhc-inventory-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Ted Lemon | ||
| Last updated | 2013-04-21 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lemon-dhc-inventory-00
Network Working Group T. Lemon
Internet-Draft Nominum, Inc.
Updates: 3315 (if approved) April 22, 2013
Intended status: Standards Track
Expires: October 24, 2013
Techniques for Tracking Inventory Using DHCPv6 DUID
draft-lemon-dhc-inventory-00
Abstract
In the years since DHCPv4 gained widespread popularity, one of the
uses to which organizations have put it is inventory tracking:
associating identifiers scanned from packaging with records in an
inventory database. This document describes various means for
accomplishing the same purpose using DHCPv6. This document also
updates RFC3315 by clarifying the meaning of some normative language
regarding the DUID-LL and DUID-LLT DUID types.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 24, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Lemon Expires October 24, 2013 [Page 1]
Internet-Draft Tracking Inventory with DHCPv6 DUID April 2013
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. General Mechanism . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Entering a new device into inventory . . . . . . . . . . 3
2.2. Distributing the new device . . . . . . . . . . . . . . . 4
2.3. First appearance on the network . . . . . . . . . . . . . 4
3. Using DUID-LL or DUID-LLT . . . . . . . . . . . . . . . . . . 6
4. Using the DHCPv6 Client Link-layer Address Option . . . . . . 7
5. Which algorithm to use . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
In DHCPv4 DHCPv4 [RFC2131], the link-layer address of a DHCP client
is commonly used to identify the client. The link-layer address
appears in the chaddr field of the DHCP packet, and is also
frequently included in the Client Identifier option.
Not coincidentally, the link-layer addresses of network devices are
almost always present as bar codes and machine-readable text on the
outside of the boxes in which these devices are delivered. This is
true of most mobile phones, laptop computers, desktop computers,
network routers and switches, and so on.
Services providers and enterprises have taken advantage of these two
facts in their inventory tracking systems: when a new device arrives,
the bar codes are scanned into a database, and an inventory tracking
number is assigned to the device. When the device is assigned to a
user or to a use, that information can be added to the database.
This means that, for example, when a network router is installed, the
inventory tracking system can be updated both with the physical
location of the router and with its intended purpose: for example,
"router between backbone and first floor network." This information
can in turn be used to provision the router: to send it a
configuration. When a router is replaced, the provisioning system
can then automatically configure the new router simply by knowing
Lemon Expires October 24, 2013 [Page 2]
Internet-Draft Tracking Inventory with DHCPv6 DUID April 2013
that it is the "router between backbone and first floor network";
DHCPv4 takes care of noticing that the device is new on the network,
and that can trigger the provisioning of the device.
Unlike DHCPv4, DHCPv6 [RFC3315] does not directly make use of a
device's link-layer address as an identifier. This is because the
link-layer address is specific to an interface, and it was considered
useful to be able to notice that requests being issued on multiple
interfaces related to the same device. It was also considered useful
that the device's identifier remain stable when network hardware was
added or removed.
Consequently, the inventory management solution in DHCPv6 is somewhat
more complicated than that in DHCPv4. This document describes
several mechanisms that are available to administrators to address
this concern.
2. General Mechanism
This mechanism takes as its input two pieces of information: one of
the link-layer addresses of a device, and the DUID of the device. If
the DUID is known, the link-layer address MUST be ignored. If the
DUID is unknown, the link-layer address is used to find the the
inventory record for the device, and then the the DUID is added to
the inventory record.
2.1. Entering a new device into inventory
We assume that when a new device arrives, the box has one bar code on
the side for the link layer address of each network interface on the
device. The person responsible for receiving the device scans each
bar code off of the box. This person then generates an inventory
control tag for the device, and scans that into the system as well.
The inventory control tag is affixed to the device in a location
where it can be easily scanned or read in the future.
Suppose a new router arrives. It has two network interfaces: one
with a link-layer address of 00:53:01:1f:24:32 and one with a link-
layer address of 00:53:02:05:49:ad. The device is assigned an
inventory control tag number of 11029938. This will produce several
rows in a database table listing link-layer addresses:
+--------------------+------------------+
| link-layer address | inventory number |
+--------------------+------------------+
| 00:53:01:1f:24:32 | 11029938 |
| 00:53:02:05:49:ad | 11029938 |
+--------------------+------------------+
Lemon Expires October 24, 2013 [Page 3]
Internet-Draft Tracking Inventory with DHCPv6 DUID April 2013
Table 1: Link Layer address to Inventory Table
It will also produce one additional row in a database table listing
inventory items:
+------------------+-------------+------+-------+------+
| inventory number | description | DUID | user? | use |
+------------------+-------------+------+-------+------+
| 11029938 | router | NULL | false | NULL |
+------------------+-------------+------+-------+------+
Table 2: Inventory Items Table
Note that the DUID and use fields are NULL at this point, because the
device hasn't yet been assigned a user, and has never been connected
to the network. The user field in this example is a flag indicating
whether the device will be assigned to the user (true), or is
infrastructure equipment (false).
2.2. Distributing the new device
Eventually the new device is moved from inventory to its intended
use: either on a machine room rack somewhere, or to a user's desk,
for example. When this happens, the inventory record is updated; the
link layer address records are not:
+------------------+-------------+------+-------+-----------------+
| inventory number | description | DUID | user? | use |
+------------------+-------------+------+-------+-----------------+
| 11029938 | router | NULL | false | bb::first floor |
+------------------+-------------+------+-------+-----------------+
Table 3: Inventory Items Table (distributed)
In this example the router is marked with a token that will be
meaningful to the provisioning system: "backbone::first floor".
2.3. First appearance on the network
Now the device is plugged into a rack in a distribution closet; one
network interface is plugged into the backbone network; the other is
plugged into the cascade of switches that support the first floor
network. The device is powered on.
Lemon Expires October 24, 2013 [Page 4]
Internet-Draft Tracking Inventory with DHCPv6 DUID April 2013
When the device is powered on, it first does router solicitation and
gets a prefix on the backbone network (we assume that there is no
router on the first floor network, so it doesn't get a prefix there).
The prefix is marked with the 'M' bit, indicating that this is a
managed network, so the router issues a DHCP Solicit message.
The solicit messages is received by the DHCP server. The DHCP server
does not have a record of the DUID presented by the router, so it
logs it as unknown in the provisioning system and does nothing
further. The DHCP server provides both the link-layer address of the
router's interface on the backbone network, and the DUID that the
router presented.
We are assuming in this case that the link-layer address is available
to the DHCP server because it and the router are connected to the
same physical link, so the link-layer address appears in the packet
header of the received Solicit packet. In this example we'll assume
that the link-layer address the router sent is 00:53:01:1f:24:32, and
that the DUID is 00:03:00:01:00:53:02:05:49:ad.
The provisioning system takes the log entry for the unknown device
and does a lookup in the Inventory Items table for the DUID that the
router presented. The DUID is not in the table, so the provisioning
system gets an empty result table, indicating that the DUID is
currently unknown to the provisioning system.
The provisioning system then looks up the link-layer address in the
Link Layer Address to Inventory table. This produces a result table
with a single row:
+--------------------+------------------+
| link-layer address | inventory number |
+--------------------+------------------+
| 00:53:01:1f:24:32 | 11029938 |
+--------------------+------------------+
Table 4: Link Layer address to Inventory Result Table
The provisioning system now uses the inventory number to find the
inventory table entry and update it with the DUID; after this is
done, the record looks like this:
+-----------+-------------+-------------------+---------+-----------+
| inventory | description | DUID | user? | use |
| number | | | | |
+-----------+-------------+-------------------+---------+-----------+
| 11029938 | router | 00:03:00:01 | false | bb::first |
| | | 00:53:02:05:49:ad | | floor |
Lemon Expires October 24, 2013 [Page 5]
Internet-Draft Tracking Inventory with DHCPv6 DUID April 2013
+-----------+-------------+-------------------+---------+-----------+
Table 5: Inventory Items Table (finished)
The provisioning system now has enough information to configure the
DHCP server with an IP address specific to the router, and to
configure the router itself with information about prefixes on the
first floor network. How this is done is beyond the scope of this
document.
3. Using DUID-LL or DUID-LLT
RFC3315 defines the DHCP Unique Identifier (DUID) and describes
several different formats suited to various uses. Two of those
formats, DUID-LL and DUID-LLT, include the link-layer address of the
client. RFC3315 states:
Clients and servers MUST treat DUIDs as opaque values and MUST only
compare DUIDs for equality. Clients and servers MUST NOT in any
other way interpret DUIDs. Clients and servers MUST NOT restrict
DUIDs to the types defined in this document, as additional DUID types
may be defined in the future.
This text is specifically intended to exclude the possibility that
the DHCP server might treat some portion of the DUID, rather than the
entire DUID, as a unique identifier for the client. However, the
text is stated so unequivocally that it is often interpreted to mean
that it's not permissible to look at the contents of the option for
any other reason; this was not the original intent of the
requirement.
We therefore update the above paragraph from RFC3315 as follows:
Clients and servers MUST NOT use any part of a DUID as a unique
identifier. Clients and servers MUST use the entire contents of the
DUID as an opaque token for the purpose of uniquely identifying the
client. Clients and servers MUST NOT restrict DUIDs to the types
defined in this document, as additional DUID types may be defined in
the future. Clients and servers MAY use the semantic contents of the
DUID to generate a one-time mapping between a link-layer address
known to be configured in a specific device, and that device's DUID.
This change to RFC3315 allows DHCP servers or provisioning systems to
use the link-layer address from a DUID-LL or DUID-LLT as input to the
process described in Section 2 for mapping the DUID to a specific
device in an inventory database.
Lemon Expires October 24, 2013 [Page 6]
Internet-Draft Tracking Inventory with DHCPv6 DUID April 2013
It is important to note that the usual reason for using a DUID-LLT,
as opposed to a DUID, is that the network interface used to generate
the DUID-LLT is not permanently installed in the device. This means
that there is no assurance that a device that came with a removable
network interface will not have a new interface installed when it
generates its DUID. In that case, the device will present an unknown
link-layer address to the DHCP server in the DUID-LLT.
For this reason, nodes that contain both removable and fixed
interfaces MUST use the link-layer address of a fixed interface when
generating a DUID-LL or DUID-LLT. Devices using the link-layer
address of a fixed interface to generate the DUID SHOULD use DUID-LL,
not DUID-LLT, since there is no benefit to the additional timestamp
in DUID-LLT.
4. Using the DHCPv6 Client Link-layer Address Option
The DHCPv6 Client Link-layer Address option
[I-D.ietf-dhc-dhcpv6-client-link-layer-addr-opt]is a new DHCPv6
extension which allows the DHCPv6 relay agent to include the client's
link-layer address as an option in the RELAY-FORW message. The DHCP
server can use the provided link-layer address as a key in the lookup
described in Section 2. Note that the link-layer address will come
from the RELAY-FORW message, but the DUID to be mapped will come from
the inner encapsulated packet-\u002Dfor example, a DHCP Solicit or
other client-sourced packet.
5. Which algorithm to use
Since the use of DUID-LL and DUID-LLT is not required, it is best not
to rely on these DUIDs as a source for the client's link-layer
address. If the client is connected to the same link as the server,
the server SHOULD use the link-layer address presented by the client
for the inventory table lookup. If the client is configured through
a relay, and the relay provides the Client Link-layer Address option,
the server SHOULD use the contents of that option to identify the
client.
6. Acknowledgments
This document was motivated by my realization during a private
conversation with Leaf Yeh that although this technique for mapping
client link-layer addresses to inventory tracking systems is well-
known to some experts in the DHCPv4 and DHCPv6 user community, it has
not been documented by the IETF, and that readers of RFC2131 and
RFC3315 might therefore be unaware that this usage pattern exists.
Lemon Expires October 24, 2013 [Page 7]
Internet-Draft Tracking Inventory with DHCPv6 DUID April 2013
7. Security Considerations
This document explaine existing practice with respect to the use of
Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host
Configuration Protocol Version 6 [RFC3315]. The security
considerations for these protocols are described in their
specifications and in related documents that extend these protocols.
This document introduces no new functionality, and hence no new
security considerations.
8. IANA Considerations
The IANA is hereby absolved of any requirement to take any action in
relation to this document.
9. References
9.1. Normative References
[I-D.ietf-dhc-dhcpv6-client-link-layer-addr-opt]
Halwasia, G., Systems, C., and W. Dec, "Client Link-layer
Address Option in DHCPv6", draft-ietf-dhc-dhcpv6-client-
link-layer-addr-opt-05 (work in progress), March 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
9.2. Informative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
Author's Address
Ted Lemon
Nominum, Inc.
2000 Seaport Blvd
Redwood City, CA 94063
USA
Phone: +1-650-381-6000
Email: Ted.Lemon@nominum.com
Lemon Expires October 24, 2013 [Page 8]