All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Helge Deller <deller@gmx.de>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, Valdis.Kletnieks@vt.edu
Subject: Re: [PATCH 1/2] UUID: set multicast bit in pseudo-random MAC address
Date: Sun, 21 Oct 2007 07:32:25 -0400	[thread overview]
Message-ID: <20071021113225.GA7045@thunk.org> (raw)
In-Reply-To: <200710202158.40645.deller@gmx.de>

On Sat, Oct 20, 2007 at 09:58:40PM +0200, Helge Deller wrote:
> Fix a bug in the current random UUID generator:
> 
> Section 4.1.6 of RFC 4122 states regarding the "NodeID" of a UUID:
> :  For systems with no IEEE address, a randomly or pseudo-randomly
> :  generated value may be used; see Section 4.5.  The multicast bit must
> :  be set in such addresses, in order that they will never conflict with
> :  addresses obtained from network cards. 
> 
> So up to now it was just pure ("random") luck if this bit was set or not.
> This tiny patch sets the bit explicitely.

NACK.  Your patch degrades the random UUID by a bit, for no good reason.

The part of Section 4.1.6 which you quoted only applies to version 1
UUID's --- i.e., MAC and time based UUID's.  Random uuids are version
4 UUID's, and are already distinguished from version 1 UUID's by the
high 4 bits of the time_hi_and_version field, in octets 6-7 of the
URL.  Hence, there is no danger of conflict.  If you had looked 3
paragraphs later section 4.1.6:

   For UUID version 4, the node field is a randomly or pseudo-randomly
   generated 48-bit value as described in Section 4.4.

And the summary can be found in Section 4.4 of RFRC 4122:

4.4.  Algorithms for Creating a UUID from Truly Random or
      Pseudo-Random Numbers

   The version 4 UUID is meant for generating UUIDs from truly-random or
   pseudo-random numbers.

   The algorithm is as follows:

   o  Set the two most significant bits (bits 6 and 7) of the
      clock_seq_hi_and_reserved to zero and one, respectively.

   o  Set the four most significant bits (bits 12 through 15) of the
      time_hi_and_version field to the 4-bit version number from
      Section 4.1.3.

   o  Set all the other bits to randomly (or pseudo-randomly) chosen
      values.

   See Section 4.5 for a discussion on random numbers.

   	     	    	     	       	  	  - Ted

  reply	other threads:[~2007-10-21 11:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-20 19:39 [PATCH 0/2] Time-based RFC 4122 UUID generator Helge Deller
2007-10-20 19:58 ` [PATCH 1/2] UUID: set multicast bit in pseudo-random MAC address Helge Deller
2007-10-21 11:32   ` Theodore Tso [this message]
2007-10-21 19:09     ` Helge Deller
2007-10-20 20:00 ` [PATCH 2/2] UUID: Time-based RFC 4122 UUID generator Helge Deller
2007-10-21 12:26   ` Theodore Tso
2007-10-21 20:11     ` Helge Deller
2007-11-04 21:42       ` Helge Deller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071021113225.GA7045@thunk.org \
    --to=tytso@mit.edu \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akpm@osdl.org \
    --cc=deller@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.