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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox