RE: Re: [802.1] TGi use of OUI 00-00-00
- To: "'David V James'" <firstname.lastname@example.org>, "'David Halasz'" <email@example.com>, "'Geoff Thompson'" <firstname.lastname@example.org>, "'Mike Moreton'" <Mike.Moreton@synad.com>, "'Tony Jeffree'" <email@example.com>, "'Johnston, Dj'" <firstname.lastname@example.org>, <email@example.com>, "'IEEE 802.1'" <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, <Hal.Keen@att.net>
- Subject: RE: Re: [802.1] TGi use of OUI 00-00-00
- From: "Mick Seaman" <firstname.lastname@example.org>
- Date: Mon, 6 Oct 2003 15:33:55 -0700
- Importance: Normal
- In-Reply-To: <FMEBLOEMFEFGGFLELMLNIEKGCNAA.email@example.com>
- Reply-To: "Mick Seaman" <firstname.lastname@example.org>
- Sender: email@example.com
I agree with DVJ that 00-00-00 should not be used (without Xerox's
permission, has anyone tried to get this?). Since it appears that
preliminary equipment has been shipped with another OUI in the field, chnage
the text to expalin that 00-00-00 is not an OUI but a something else appears
to be a flagrant attempt to downgrade Xeroz's OUI. That can't stand.
I object to DVJ's objection (1), wearing all my hats - IEEE member, RAC
member, 802.1 interworking task group chair. I disagree that all public code
points derived from the OUI need to be EUI-48 or longer. To demand that TGi
change the length of this field is simply unnecessary torture.
[mailto:firstname.lastname@example.org]On Behalf Of David V James
Sent: Monday, October 06, 2003 12:24 PM
To: David Halasz; Geoff Thompson; Mike Moreton; Tony Jeffree; Johnston,
Dj; email@example.com; IEEE 802.1; firstname.lastname@example.org;
email@example.com; firstname.lastname@example.org; Hal.Keen@att.net
Subject: RE: Re: [802.1] TGi use of OUI 00-00-00
In response to:
>> Any objections to 802.11i changing the Suite selector to the following?
Not sure is this question was directed to myself (DVJ),
or simply forwarded as an observer. Assuming opinion
Objection from DVJ as IEEE/RAC member:
1) Distinctive numbers shold be EUI-48 based.
a) More standard.
b) Allows continued usage of IABs.
2) The all zero OUI should not be used.
This usage identifies Xerox as the authority for
ensuring uniqueness of following dependentIDs,
which is not the case.
David V. James
3180 South Ct
Palo Alto, CA 94306
[mailto:email@example.com]On Behalf Of David Halasz
Sent: Monday, October 06, 2003 12:11 PM
To: Geoff Thompson; Mike Moreton; Tony Jeffree; Johnston, Dj;
firstname.lastname@example.org; IEEE 802.1; email@example.com; firstname.lastname@example.org;
Subject: Fwd: Re: [802.1] TGi use of OUI 00-00-00
Any objections to 802.11i changing the Suite selector to the following?
Suite Type - 4 octets in length.
00-00-00-00 Use Group Key cipher suite
00-00-00-04 CCMP default in an RSNA
Date: Mon, 06 Oct 2003 13:32:20 -0400
To: "Hal Keen" <Hal.Keen@att.net>
From: David Halasz <email@example.com>
Subject: Re: [802.1] TGi use of OUI 00-00-00
Cc: "Geoff Thompson" <firstname.lastname@example.org>, "Mike Moreton"
<Mike.Moreton@synad.com>, "Tony Jeffree" <email@example.com>, "Johnston,
Dj" <firstname.lastname@example.org>, <email@example.com>, "IEEE 802.1"
<firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>,
This is a rather large email thread. Instead of answering your question
directly, I would prefer to include the answer, in a summary of the email
- The IEEE 802.11i draft has "Suite Selectors". The Suite selector is sent
in an RSN Information Element
- The Suite selector has the format
OUI 3 octets, Suite Type 1 octet
- The Cipher Suite Selector table is currently the following,
00:00:000Use Group Key cipher suite
00:00:004CCMP default in an RSNA
Vendor OUIOtherVendor Specific
- From an earlier email, "...would rather TGi not use 00-00-00 because that
OUI has special meaning in other uses, most notably RFC1042....."
- From an earlier email (paraphrasing): "Hey, 00-00-00 is Xerox's"
- A suggestion (I like it, but others don't): "...Use some other encoding to
carry the semantics "this field does not contain an OUI value". For example,
given that OUIs will presumably not be allocated that would have the I/G bit
set when used to generate MAC addresses (this is the LS bit of first
octet ), maybe this could be used to achieve the desired goal..."
- A comment, "2) If, by some screw-up, #1 has been violated then the
screw-up should be fixed. Any proposed repair that proposes to continue an
incursion into the use of an assigned OUI by an entity other than the entity
that owns that OUI without the express written permission of the current
appropriate designated agent of the owner of the OUI is not OK!"
- Response to above comment(This is the answer to your question),
- Please see clause 10.5 of O&A
10.5 Encapsulation of Ethernet frames over LLC
This subclause specifies the standard method for conveying Ethernet frames
across IEEE 802 LANs that offer only the LLC sublayer, and not the Ethernet
sublayer, directly above the MAC sublayer. An Ethernet frame conveyed on an
LLC-only LAN shall be encapsulated in a SNAP PDU contained in an LLC PDU of
type UI, as follows (see Figure 18):
a) The Protocol Identification field of the SNAP PDU shall contain a
protocol identifier in which
1) The three OUI octets each take the value zero.
I suggested that, the person making the comment, take his own words to heart
and take appropriate action.
At 10:52 AM 10/6/2003, Hal Keen wrote:
Okay, I'll bite; I'm one (actually half) of the 802.2 committee in
hibernation and a longtime student of the evolution of the O&A. (Not by any
means the most senior; quite a number of us in 802.1 remember when the "OUI"
term was invented.)
What do you imagine needs to be fixed, with regard to this matter, in 802.2?
and, for that matter, in the O&A?
----- Original Message -----
From: "David Halasz" <email@example.com>
Sent: Monday, October 06, 2003 7:38 AM
Subject: RE: [802.1] TGi use of OUI 00-00-00
> Thanks Geoff,
> I trust you will proceed to fix 802.2 and the 802 Overview and
> Dave H.
Cisco Systems, Inc.
4125 Highlander Parkway
Richfield, OH 44286