Re: [DNA-BOF] Using L2 to provide Instantaneous Movement

[Bernard Aboba <aboba@internaut.com>]

> I agree that using several SSIDs on AP is a way to use an AP for
> different networks/operators.
> But my point was the fact that the specification does not deal with a
> single AP advertising several SSIDs.

In many ways, IEEE 802.11-1999 does not define an AP at all.  For example,
it does not define the forwarding behavior of an AP or map it to the
bridging model of IEEE 802.1D.  And today we have a wide variety of AP
architectures -- including dumb AP/switch combinations that have many
BSSIDs, operate on multiple channels, but still use a single key cache
(since within the AAA definition, the conglomeration constitutes a single
NAS).

> In IEEE 802.11 specification, it is written "the SSID element indicates
> the identity of an ESS" (p55). And of course an ESS has no relation with
> network (it can be a single LAN or everything else).

Yes. An ESS does not correspond to a single LAN; it can be a routed
network.

> Ok I see, it's very interesting. But once more, I think this is not
> really specification, this is a way to use it.

Yes.

> And by doing this, you mean that APs with 4 different SSIDs, will send 4
> times more beacons ?

Yes. This is not a very large proportion of the bandwidth, particularly
for the higher rates (IEEE 802.11a or g).  And in some circumstances (such
as a hotspot trying to support both Web portal and WPA or an AP shared by
multiple operators) it is essential for operations.

> Your second point is not possible. The BSSID is the identifier of the
> BSS and in infrastructure mode it is the MAC address of the AP. So when
> a single AP has several SSID, it always has a single BSSID.

The problem is that many drivers cannot handle this.  They see one
adverisement, and store the capabilities.  Then they see another
advertisement originating from the same BSSID, with different
capabilities, and they over-write the initial advertisement, assuming that
the AP has been re-configured.

> That is why I say before that maybe a specification is needed to deal
> with this...

Unfortunately, it's somewhat late, because millions of NICs and APs have
already shipped.  That means that there are backward compatibility issues
with a number of otherwise seemingly reasonable approaches.

> But this is not the task of IETF of course...

Or apparently of IEEE 802.11 either (since several of the approaches
appear to be legal within IEEE 802.11-1999).  The WFA Public Access WG is
dealing with the issue at this point.

> I think that puting L3 information into L2 frames can be very relevant
> for mobility operation. As we (IETF) need this information, it could be
> good to work on this and have a consensus on what we need exactly. Then
> we can submit our request to IEEE as the result of our work.

The problem is understanding the right L2 frames to include this
information in.  The Beacon and Probe Response are not secured, and also
are relatively early in the process so that they might not reflect the
actual VLAN that the station is assigned to.  So probably the best that
can be achieved in prior to association is to advertise *all* the prefixes
associated with a given BSSID.  This might be a single prefix (in the case
where the BSSID/SSID corresponds to a single VLAN) or it might be multiple
(in the case where the VLAN is dynamically assigned and can vary).  The
station can make its decision as to which AP to associate based on the
advertisements, but they are only a "hint" because it is possible that the
actual prefix to which the station is connected may not be the expected
one. The station will do a reachability test on the assumption that the
prefix is the expected one, but if this fails it must be prepared to
obtain an address by conventional means (DHCPv4, RS/RA, DHCPv6, etc.).