Capwap Mailing List: Re: Last call comments for capwap-protocol-binding-ieee80211-07

[Pat Calhoun (pacalhou) (pcalhoun]

> > > I wasn't thinking about ad-hoc mode, but rather a STA sending a 
> > > packet to an AP where the 802.3 source address would be different 
> > > from the transmitting STA address.  Is this possible? (Perhaps a 
> > > "wireless Ethernet bridge", which connects to PC via wired
Ethernet, 
> > > but looks like STA to the AP? Although I'm not quite sure how the 
> > > address fields really look in this situation...)
> > 
> > Yes, you are correct that bridges work this way, but this is not a
use 
> > case we are trying to address in this working group. An access point

> > uses the IEEE 802.11 primitives for populating its learning table 
> > (e.g., association request), while a bridge needs to use other means

> > (e.g., spanning tree). Trying to add wireless bridges to this 
> > specification would not only expand the scope of the WG and
protocol, 
> > but would require lots more work.
> 
> Large bridges are indeed different, but small "wireless bridges" are
marketed for e.g. connecting a printer with wired Ethernet jack to
office WLAN.
> 
> Does this mean if the office WLAN switches to CAPWAP-based access
points, and uses split MAC with 802.3 frames, those would stop working? 
> 
> (I don't think there's a need to expand the scope of the WG --
accurately documenting what parts of 802.11 don't 100% work with CAPWAP
is IMHO quite sufficient.)

The size of the bridge is actually irrelevant. The use of the four
address frame format is the question. I would point you to the IEEE
802.11-2007 specification, section 7.1.3.1.3, which specifically states:

<standards quote>
To DS = 1, From DS = 1
   A data frame using the four-address format. This standard does not
define procedures for
   using this combination of field values.
</standards quote>

So to that end, I am proposing a modification to the last paragraph of
the introduction section:

<modified text>
1.  Introduction
[...]
   Note that this binding only supports the IEEE 802.11-2007
   specification.  Of note, this binding does not support the ad-hoc
   network mode defined in the IEEE 802.11-2007 standard.  This
   specification also does not cover the use of data frames with the
   four-address format, commonly referred to as Wireless Bridges, whose
   use is not specified in the IEEE 802.11-2007 standard.  New protocol
   specifications published outside of this document (e.g., IEEE
   802.11n, IEEE 802.11r) are therefore not supported through this
   binding, and must be addressed either through a separate CAPWAP
   binding, or an update to this binding.
</modified text>

> > > This is contradicted by text in e.g. Section 6.15, which requires 
> > > the WTP to process (beyond copying to beacons) the IE received
from 
> > > AC even in Split MAC mode.
> > 
> > OK, fair enough. That is one exception, but that one is described in

> > the spec. The spec even includes:
> > 
> > <current text>
> > 2.2.1.  Split MAC
> > [...]
> > 
> >    o  The WTP generates the IEEE 802.11 Beacon frames, using 
> >       information
> >       provided to it through the IEEE 802.11 Add WLAN (see 
> >       Section 6.1)
> >       message element, including the RSNIE, which indicates support
of
> >       802.1X and AES-CCMP.
> > </current text>
> 
> Yes, but the spec isn't very clear on how the RSN IE exactly is
processed by the WTP (the IE has number of different fields).

The WTP does not need to perform any processing of the RSN IE. The IE is
included in the Beacon and Probe Responses as-is by the WTP. Any
cryptographic policies are sent by the AC either through the Add Station
or the Session Key message elements. So in order to provide more
clarity, I propose adding the first sentence in the last paragraph of
the following text:

<modified text>
6.1.  IEEE 802.11 Add WLAN
[...]
  Power Constraint information element

   EDCA Parameter Set information element

   QoS Capability information element

   WPA information element  [WPA]

   RSN information element

   WMM information element  [WMM]

   These IEEE 802.11 information elements are stored by the WTP and
   included in any Probe Responses and Beacons generated, as specified
   in the IEEE 802.11 standard [IEEE.802-11.2007].  If present, the RSN
   information element is sent with the IEEE 802.11 Add WLAN message
   element to instruct the WTP on the usage of the Key field.
</modified text>

> > Actually, re-reading the spec, I don't see where it dictates that
the 
> > WTP needs to process IEs. It does mention that the WTP needs to look

> > at the Result-Code in the (re-)Association Response. It also does 
> > mention that the AC MAY send a Disassocation Request to the station,

> > through the WTP, and that the WTP should take the Disassocation 
> > Request as an indication that service for the station is to be 
> > terminated.
> > 
> > Otherwise, there are no IE processing requirements.
> 
> Again, except for the RSN IE, whose processing is mentioned, but not
described in detail.

I believe this is now covered above.