| Date: | Fri, 18 Aug 2017 17:56:25 -0600 |
| From: | "Philip Prindeville" <philipp@redfish-solutions.com> |
| Subject: | Implementing RFC-6355 |
| To: | dhcp-bugs@isc.org |
Hi.
I was going through the sources of 4.3.5, in particular, how the DUID_LL is generated, and it seems wrong.
Quoting the RFC, we have:
4. DUID-UUID Format
The DUID-UUID is carried within Client Identifier or Server
Identifier options. It has the following format:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type (4) | UUID (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 1: DUID-UUID Format
DUID-Type - DUID-UUID (4) - (16 bits)
UUID - An [RFC4122] UUID (128 bits)
but the code fragment:
} else {
putUShort(duid->buffer->data, DUID_LL);
putUShort(duid->buffer->data + 2, ip->hw_address.hbuf[0]);
memcpy(duid->buffer->data + 4, ip->hw_address.hbuf + 1,
ip->hw_address.hlen - 1);
}
in client/dhclient.c circa line 3485 does something entirely different.
The first putUShort() is correct, but the code should look like this:
// typedef char uuid_t[16];
uuid_t *uuid;
char digest[ISC_MD5_DIGESTLENGTH];
isc_md5_t ctx;
isc_md5_init(&ctx);
isc_md5_update(&ctx, NameSpace_OID, sizeof(NameSpace_OID));
isc_md5_update(&ctx, &ip->hw_address.buf[1], ip->hw_address.hlen - 1);
// alternatively, you could also run the hash over the type
// isc_md5_update(&ctx, ip->hw_address.buf, ip->hw_address.hlen);
isc_md5_final(&ctx, digest);
putUShort(duid->buffer->data, DUID_LL);
// build UUID in-place
uuid = (uuid_t *) &duid->buffer->data + 2;
memcpy(uuid, digest, sizeof(uuid_t));
uuid[6] &= ~(0xf << 4);
uuid[6] |= (3 << 4); // version 3, MD5
uuid[8] &= ~(0x7 << 5);
uuid[8] |= (4 << 5); // DCE variant
duid->len = 2 + sizeof(uuid_t);
And NameSpace_OID (which comes from RFC-4122, section C) would look like:
const uuid_t NameSpace_OID = {
0x6b, 0xa7, 0xb8, 0x12, 0x9d, 0xad, 0x11, 0xd1,
0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
};
Unless I’m missing something obvious.
But Section 4 of RFC-6355 seems pretty unequivocal about the DUID-UUID being 2 bytes of type (0x0004) followed by 16 bytes of UUID.
That is not what is currently going on in the current code.
Thanks,
-Philip