Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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.

Type            Meaning
00-00-00-00     Use Group Key cipher suite
00-00-00-01     WEP-40
00-00-00-02     TKIP
00-00-00-03     Reserved
00-00-00-04     CCMP  default in an RSNA
00-00-00-05     WEP-104
Other           Undefined

        Dave H.

Date: Mon, 06 Oct 2003 13:32:20 -0400
To: "Hal Keen" <>
From: David Halasz <>
Subject: Re: [802.1] TGi use of OUI 00-00-00
Cc: "Geoff Thompson" <>, "Mike Moreton" <>, "Tony Jeffree" <>, "Johnston, Dj" <>, <>, "IEEE 802.1" <>, <>, <>, <>

Hi Hal,

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 thread.

- 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,
OUISuite TypeMeaning
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.

        Dave H.

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?

Hal Keen

----- Original Message -----
From: "David Halasz" <>
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
> document.
>          Dave H.

Dave Halasz
Cisco Systems, Inc.
4125 Highlander Parkway
Richfield, OH  44286