--- HISTORY 2004/02/13 21:03:18 1.2
+++ HISTORY 2004/02/13 21:08:17 1.3
@@ -122,11 +122,11 @@
Thanks for writing, Ralf.
- You're correct, and this has been noted by the IESG and will be fixed in
+ You're correct, and this has been noted by the IESG and will be fixed in
the next draft. It's unfortunate we made it this far with the bug.
/r$
- --
+ --
Rich Salz, Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
@@ -147,16 +147,16 @@
FreeBSD src repository
Modified files:
- sys/kern kern_uuid.c
+ sys/kern kern_uuid.c
Log:
Fix generation of random multicast MAC address.
-
+
In case no real/physical IEEE 802 address is available, both the expired
"draft-leach-uuids-guids-01" (section "4. Node IDs when no IEEE 802
network card is available") and RFC 2518 (section "6.4.1 Node Field
Generation Without the IEEE 802 Address") recommend (quoted from RFC
2518):
-
+
"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
@@ -164,24 +164,24 @@
addresses obtained from network cards; hence, there can never be a
conflict between UUIDs generated by machines with and without network
cards."
-
+
Unfortunately, this incorrectly explains how to implement this and
the FreeBSD UUID generator code inherited this generation bug from
the broken reference code in the standards draft. They should instead
specify the "_least_ significant bit of the first octet of the node ID"
as the multicast bit in a memory and hexadecimal string representation
of a 48-bit IEEE 802 MAC address.
-
+
This standards bug arised from a false interpretation, as the multicast
bit is actually the _most_ significant bit in IEEE 802.3 (Ethernet)
_transmission order_ of an IEEE 802 MAC address. The standards authors
forgot that the bitwise order of an _octet_ from a MAC address _memory_
and hexadecimal string representation is still always from left (MSB,
bit 7) to right (LSB, bit 0).
-
+
Fortunately, this UUID generation bug could have occurred on systems
without any Ethernet NICs only.
-
+
Revision Changes Path
1.7 +1 -1 src/sys/kern/kern_uuid.c
@@ -197,17 +197,17 @@
On Thu, Jan 22, 2004 at 05:34:11AM -0800, Ralf S. Engelschall wrote:
> rse 2004/01/22 05:34:11 PST
- >
+ >
> FreeBSD src repository
- >
+ >
> Modified files:
- > sys/kern kern_uuid.c
+ > sys/kern kern_uuid.c
> Log:
> Fix generation of random multicast MAC address.
An excellent catch and an outstanding commit log. Chapeau!
- --
+ --
Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
___________________________________________________________________________
@@ -220,9 +220,9 @@
--- ChangeLog 13 Feb 2004 16:17:07 -0000 1.42
+++ ChangeLog 13 Feb 2004 21:01:07 -0000
@@ -13,6 +13,14 @@
-
+
Changes between 0.9.6 and 0.9.7 (11-Feb-2004 to 13-Feb-2004)
-
+
+ o 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
@@ -243,7 +243,7 @@
+++ uuid.ac 13 Feb 2004 19:20:32 -0000
@@ -71,12 +71,6 @@
AC_CHECK_SIZEOF(unsigned long long, 8)
-
+
dnl # options
- AC_ARG_WITH(rfc2518,
- AC_HELP_STRING([--with-rfc2518], [use incorrect generation of IEEE 802 multicast addresses according to RFC2518]),
@@ -264,7 +264,7 @@
@@ -61,69 +61,9 @@
Unix UTC base time is January 1, 1970) */
#define UUID_TIMEOFFSET "01B21DD213814000"
-
+
-/* IEEE 802 MAC address encoding/decoding bit fields
-
- ATTENTION:
@@ -331,7 +331,7 @@
+/* IEEE 802 MAC address encoding/decoding bit fields */
+#define IEEE_MAC_MCBIT BM_OCTET(0,0,0,0,0,0,0,1)
+#define IEEE_MAC_LOBIT BM_OCTET(0,0,0,0,0,0,1,0)
-
+
/* IEEE 802 MAC address octet length */
#define IEEE_MAC_OCTETS 6
@@ -622,8 +562,8 @@
|
