OSSP CVS Repository

ossp - Ticket #42
Not logged in
[Honeypot]  [Browse]  [Home]  [Login]  [Reports
[Search]  [Ticket]  [Timeline
  [Attach]  [Edit]  [History

Ticket 42: MSB of node not set to 1 when using `uuid -v1 -m`

I got this UUID when using `uuid -v1 -m` --

    0fd3b64a-853f-11d8-8839-0b0a510b38ad

The MSB of the node field is supposed to be a 1, however, according to the spec, section 4 --

¤http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/draft-l/draft-leach-uuids-guids-01.txt

"The ideal solution is to obtain a 47 bit cryptographic quality random number, and use it as the low 47 bits of the node ID, with the most significant bit of the first octet of the node ID set to 1. This bit is the unicast/multicast bit, which will never be set in IEEE 802 addresses obtained from network cards; hence, there can never be a conflict between UUIDs generated by machines with and without network cards."

To reproduce it, just run it enough times and you'll see it. Any UUIDs with anything from 0x0-0x7 as the first digit of the node are bad.

[Append remarks]

Remarks:

False alarm. The example in the spec, taken over by many authors of documents and software, is wrong. We follow the intention and set the correct multicast bit. Ethernet is a serial transmission media and the first bit hitting the wire makes the packet a unicast or multicast. However, contrary to popular belief, Ethernet shifts the bits to the right so the lowest bit becomes the multicast bit. Ralf wrote patches for all other UUID implementations and notified the authors. He also talked to the authors of RFC2518 and they agreed the spec is wrong and must be corrected. Compatiblity to the wrong spec was removed some time ago, see [4420]
[Append remarks]

Properties:

Type: code           Version: 1.0.0 
Status: closed          Created: 2004-Apr-03 09:35
Severity:          Last Change: 2004-Apr-03 21:28
Priority:          Subsystem: uuid 
Assigned To: rse           Derived From:  
Creator: anonymous 

Related Check-ins:

2004-Feb-13 22:01 Check-in [4420]: remove --with-rfc2518 option and functionality because even the IETF/IESG has finally approved our report about the broken random multicast MAC address generation in the standard (and will fix it in new versions of the draft-mealling-uuid-urn). So, finally get rid of this broken-by-design backward compatibility (By rse)

Attachments:

CVSTrac 2.0.1