From: Helge Deller <deller@gmx.de>
To: Theodore Tso <tytso@mit.edu>
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 21:09:18 +0200 [thread overview]
Message-ID: <200710212109.18559.deller@gmx.de> (raw)
In-Reply-To: <20071021113225.GA7045@thunk.org>
On Sunday 21 October 2007, Theodore Tso wrote:
> 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.
Hi Ted,
Thanks for looking into it and pointing to the important RFC pieces.
Of course you are right and I mixed that up.
Herewith I withdraw this patch.
Helge
next prev parent reply other threads:[~2007-10-21 19:10 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
2007-10-21 19:09 ` Helge Deller [this message]
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=200710212109.18559.deller@gmx.de \
--to=deller@gmx.de \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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.