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

[Jari Arkko <jari.arkko@kolumbus.fi>]

Bernard Aboba wrote:

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

A couple of observations:

1) All this is pretty complicated, given that there are multiple
    levels of selection: SSID, VLAN, multiple routers, multiple prefixes.
    If we don't know enough at the beacon time, we are potentially forced to
    include a large amount of data. Say, 2 SSIDs, 2 VLANs, 2 routers, 2
    prefixes => 16 prefixes to announce in a beacon... some of which
    might be the same (but perhaps still from a different network).

2) Lets think about the required semantics for a while. In order
    to make a wise pre-movement decision, it would be enough to have
    knowledge that a suitable prefix exists in the AP. For instance,
    the currently used prefix exists in a nearby AP, so I would
    prefer going there over another AP that does not have that
    prefix => perhaps less need for address configuration, MIPv6
    signaling etc.

    But this information can not be fully relied upon. Maybe
    the access point has the prefix you wanted, but in an
    SSID that you can't or won't use. Unless there's semantic
    information in the beacons that ties together the specific
    offered and negotiated parameters to the particular prefixes,
    we might still end up in an AP that doesn't have the prefix.

    For post-movement speedup, it would be beneficial to know
    in advance the parameters and do only a small packet-size
    probe test at IP layer. E.g., if you get back to a router
    you've seen before you can just ping it with NS/NA, which
    would consume less bandwith than an RS/RA with all the
    prefixes listed. But the win is not that big... To get rid
    of the ping you could perhaps delegate that task to the
    AP, but that would be a big deviation from the current
    architecture.

3) If all this goes over 802.11i and 802.1X, there appears to
    be relatively lengthy ping pongs between the client and the
    AP in any case. For post-movement speedup, it might be
    best just to cache an RA and replay it during the 4-way
    handshake, for instance. Then the SSID and VLAN information
    would already be known, and still no new messages would
    be needed. Anyway, you can't *do* anything with the
    prefix information before the 4-way handshake is done.

--Jari