doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc4260.txt b/doc/rfc/rfc4260.txt
new file mode 100644
index 0000000..2998208
--- /dev/null
+++ b/doc/rfc/rfc4260.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                         P. McCann
+Request for Comments: 4260                          Lucent Technologies
+Category: Informational                                   November 2005
+
+
+            Mobile IPv6 Fast Handovers for 802.11 Networks
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes how a Mobile IPv6 Fast Handover could be
+   implemented on link layers conforming to the 802.11 suite of
+   specifications.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Conventions Used in This Document ..........................2
+   2. Terminology .....................................................2
+   3. Deployment Architectures for Mobile IPv6 on 802.11 ..............3
+   4. 802.11 Handovers in Detail ......................................5
+   5. FMIPv6 Message Exchanges ........................................7
+   6. Beacon Scanning and NAR Discovery ...............................8
+   7. Scenarios .......................................................9
+      7.1. Scenario 1abcdef23456g .....................................9
+      7.2. Scenario ab123456cdefg ....................................10
+      7.3. Scenario 123456abcdefg ....................................10
+   8. Security Considerations ........................................10
+   9. Conclusions ....................................................12
+   10. References ....................................................13
+      10.1. Normative References .....................................13
+      10.2. Informative References ...................................13
+   11. Acknowledgements ..............................................13
+
+
+
+
+
+
+
+
+
+McCann                       Informational                      [Page 1]
+
+RFC 4260                  802.11 Fast Handover             November 2005
+
+
+1.  Introduction
+
+   The Mobile IPv6 Fast Handover protocol [2] has been proposed as a way
+   to minimize the interruption in service experienced by a Mobile IPv6
+   node as it changes its point of attachment to the Internet.  Without
+   such a mechanism, a mobile node cannot send or receive packets from
+   the time that it disconnects from one point of attachment in one
+   subnet to the time it registers a new care-of address from the new
+   point of attachment in a new subnet.  Such an interruption would be
+   unacceptable for real-time services such as Voice-over-IP.
+
+   The basic idea behind a Mobile IPv6 fast handover is to leverage
+   information from the link-layer technology to either predict or
+   rapidly respond to a handover event.  This allows IP connectivity to
+   be restored at the new point of attachment sooner than would
+   otherwise be possible.  By tunneling data between the old and new
+   access routers, it is possible to provide IP connectivity in advance
+   of actual Mobile IP registration with the home agent or correspondent
+   node.  This allows real-time services to be reestablished without
+   waiting for such Mobile IP registration to complete.  Because Mobile
+   IP registration involves time-consuming Internet round-trips, the
+   Mobile IPv6 fast handover can provide for a smaller interruption in
+   real-time services than an ordinary Mobile IP handover.
+
+   The particular link-layer information available, as well as the
+   timing of its availability (before, during, or after a handover has
+   occurred), differs according to the particular link-layer technology
+   in use.  This document gives a set of deployment examples for Mobile
+   IPv6 Fast Handovers on 802.11 networks.  We begin with a brief
+   overview of relevant aspects of basic 802.11 [3].  We examine how and
+   when handover information might become available to the IP layers
+   that implement Fast Handover, both in the network infrastructure and
+   on the mobile node.  Finally, we trace the protocol steps for Mobile
+   IPv6 Fast Handover in this environment.
+
+1.1.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [1].
+
+2.  Terminology
+
+   This document borrows all of the terminology from Mobile IPv6 Fast
+   Handovers [2], with the following additional terms from the 802.11
+   specification [3] (some definitions slightly modified for clarity):
+
+
+
+
+
+McCann                       Informational                      [Page 2]
+
+RFC 4260                  802.11 Fast Handover             November 2005
+
+
+   Access Point (AP): Any entity that has station functionality and
+                  provides access to the distribution services, via the
+                  wireless medium (WM) for associated stations.
+
+   Association:   The service used to establish access point/station
+                  (AP/STA) mapping and enable STA access to the
+                  Distribution System.
+
+   Basic Service Set (BSS): A set of stations controlled by a single
+                  coordination function, where the coordination function
+                  may be centralized (e.g., in a single AP) or
+                  distributed (e.g., for an ad hoc network).  The BSS
+                  can be thought of as the coverage area of a single AP.
+
+   Distribution System (DS): A system used to interconnect a set of
+                  basic service sets (BSSs) and integrated local area
+                  networks (LANs) to create an extended service set
+                  (ESS).
+
+   Extended Service Set (ESS): A set of one or more interconnected basic
+                  service sets (BSSs) and integrated local area networks
+                  (LANs) that appears as a single BSS to the logical
+                  link control layer at any station associated with one
+                  of those BSSs.  The ESS can be thought of as the
+                  coverage area provided by a collection of APs all
+                  interconnected by the Distribution System.  It may
+                  consist of one or more IP subnets.
+
+   Station (STA): Any device that contains an IEEE 802.11 conformant
+                  medium access control (MAC) and physical layer (PHY)
+                  interface to the wireless medium (WM).
+
+3.  Deployment Architectures for Mobile IPv6 on 802.11
+
+   In this section, we describe the two most likely relationships
+   between Access Points (APs), Access Routers (ARs), and IP subnets
+   that are possible in an 802.11 network deployment.  In this document,
+   our focus is mainly on the infrastructure mode [3] of 802.11.
+   Usually, a given STA is associated with one and only one AP at any
+   given instant; however, implementations are possible [4] where
+   multiple associations per STA may be maintained as long as the APs
+   are connected to disjoint DSs.  An STA may be in communication with
+   an AP only when radio propagation conditions permit.  Note that, as
+   with any layer-2 technology, handover from one layer-2 point of
+   attachment (AP) to another does not necessarily mean a change of AR
+   or subnet.
+
+
+
+
+
+McCann                       Informational                      [Page 3]
+
+RFC 4260                  802.11 Fast Handover             November 2005
+
+
+                  AR                              AR
+            AR     |    AR                   AR    |     AR
+              \    |   /                       \   |    /
+               Subnet 1                         Subnet 2
+             /  /  |  \  \                    /  /  |  \  \
+            /  /   |   \  \                  /  /   |   \  \
+           /   |   |   |   \                /   |   |   |   \
+        AP1  AP2  AP3  AP4  AP5          AP6  AP7  AP8  AP9  AP10
+
+             Figure 1.  An 802.11 deployment with relay APs.
+
+   Figure 1 depicts a typical 802.11 deployment with two IP subnets,
+   each with three Access Routers and five Access Points.  Note that the
+   APs in this figure are acting as link-layer relays, which means that
+   they transport Ethernet-layer frames between the wireless medium and
+   the subnet.  Note that APs do not generally implement any particular
+   spanning tree algorithm, yet are more sophisticated than simple
+   bridges that would relay all traffic; only traffic addressed to STAs
+   known to be associated on a given AP would be forwarded.  Each subnet
+   is on top of a single LAN or VLAN, and we assume in this example that
+   APs 6-10 cannot reach the VLAN on which Subnet 1 is implemented.
+   Note that a handover from AP1 to AP2 does not require a change of AR
+   (here we assume the STA will be placed on the same VLAN during such a
+   handoff) because all three ARs are link-layer reachable from an STA
+   connected to any AP1-5.  Therefore, such handoffs would not require
+   IP-layer mobility management, although some IP-layer signaling may be
+   required to determine that connectivity to the existing AR is still
+   available.  However, a handover from AP5 to AP6 would require a
+   change of AR, because AP6 cannot reach the VLAN on which Subnet 1 is
+   implemented and therefore the STA would be attaching to a different
+   subnet.  An IP-layer handover mechanism would need to be invoked in
+   order to provide low-interruption handover between the two ARs.
+
+                                Internet
+                               /    |   \
+                              /     |    \
+                             /      |     \
+                           AR      AR      AR
+                           AP1     AP2     AP3
+
+        Figure 2. An 802.11 deployment with integrated APs/ARs.
+
+   Figure 2 depicts an alternative 802.11 deployment where each AP is
+   integrated with exactly one AR on a disjoint VLAN.  In this case,
+   every change of AP would result in a necessary change of AR, which
+
+
+
+
+
+
+McCann                       Informational                      [Page 4]
+
+RFC 4260                  802.11 Fast Handover             November 2005
+
+
+   would require some IP-layer handover mechanism to provide for low-
+   interruption handover between the ARs.  Also, the AR shares a MAC-
+   layer identifier with its attached AP.
+
+   In the next section, we examine the steps involved in any 802.11
+   handover.  Subsequent sections discuss how these steps could be
+   integrated with an IP-layer handover mechanism in each of the above
+   deployment scenarios.
+
+4.  802.11 Handovers in Detail
+
+   An 802.11 handover takes place when an STA changes its association
+   from one AP to another ("re-association").  This process consists of
+   the following steps:
+
+     0. The STA realizes that a handoff is necessary due to degrading
+        radio transmission environment for the current AP.
+
+     1. The STA performs a scan to see what APs are available.  The
+        result of the scan is a list of APs together with physical layer
+        information, such as signal strength.
+
+     2. The STA chooses one of the APs and performs a join to
+        synchronize its physical and MAC-layer timing parameters with
+        the selected AP.
+
+     3. The STA requests authentication with the new AP.  For an "Open
+        System", such authentication is a single round-trip message
+        exchange with null authentication.
+
+     4. The STA requests association or re-association with the new AP.
+        A re-association request contains the MAC-layer address of the
+        old AP, while a plain association request does not.
+
+     5. If operating in accordance with 802.11i [6], the STA and AP
+        would execute 802.1X EAP-on-LAN procedures to authenticate the
+        association (step 3 would have executed in "Open System" mode).
+
+     6. The new AP sends a Layer 2 Update frame on the local LAN segment
+        to update the learning tables of any connected Ethernet bridges.
+
+   Although we preface step 1 with step 0 for illustration purposes,
+   there is no standardized trigger for step 1.  It may be performed as
+   a result of decaying radio conditions on the current AP or at other
+   times as determined by local implementation decisions.  Some network
+   interface cards (NICs) may do scanning in the background,
+   interleaving scans between data packets.  This decreases the time
+   required to roam if the performance of the current AP proves
+
+
+
+McCann                       Informational                      [Page 5]
+
+RFC 4260                  802.11 Fast Handover             November 2005
+
+
+   unsatisfactory, but it imposes more of a burden on the AP, since
+   typically the STA places it in power-save mode prior to the scan,
+   then once the scan is complete, returns to the AP channel in order to
+   pick up queued packets.  This can result in buffer exhaustion on the
+   AP and attendant packet loss.
+
+   During step 2, the STA performs rate adjustment where it chooses the
+   best available transmission rate.  Rate adjustment can be quite
+   time-consuming as well as unpredictable.
+
+   Note that in some existing 802.11 implementations, steps 1-4 are
+   performed by firmware in rapid succession (note that even in these
+   implementations step 3 is sometimes performed in a host driver,
+   especially for newer implementations).  This might make it impossible
+   for the host to take any actions (including sending or receiving IP
+   packets) before the handover is complete.  In other 802.11
+   implementations, it is possible to invoke the scan (step 1) and join
+   (step 2) operations independently.  This would make it possible to,
+   e.g., perform step 1 far in advance of the handover and perhaps in
+   advance of any real-time traffic.  This could substantially reduce
+   the handover latency, as one study has concluded that the 802.11
+   beacon scanning function may take several hundred milliseconds to
+   complete [8], during which time sending and receiving IP packets is
+   not possible.  However, scanning too far in advance may make the
+   information out-of-date by the time of handover, which would cause
+   the subsequent joint operation to fail if radio conditions have
+   changed so much in the interim that the target AP is no longer
+   reachable.  So, a host may choose to do scanning based on, among
+   other considerations, the age of the previously scanned information.
+   In general, performing such subsequent scans is a policy issue that a
+   given implementation of FMIPv6 over 802.11 must consider carefully.
+
+   Even if steps 1 and 2 are performed in rapid succession, there is no
+   guarantee that an AP found during step 1 will be available during
+   step 2 because radio conditions can change dramatically from moment
+   to moment.  The STA may then decide to associate with a completely
+   different AP.  Often, this decision is implemented in firmware and
+   the attached host would have no control over which AP is chosen.
+   However, tools such as the host AP driver [10] offer full control
+   over when and to which AP the host needs to associate.  Operation as
+   an Independent BSS (IBSS) or "ad-hoc mode" [3] may also permit the
+   necessary control, although in this latter case attachment to an
+   infrastructure AP would be impossible.  Implementers can make use of
+   such tools to obtain the best combination of flexibility and
+   performance.
+
+
+
+
+
+
+McCann                       Informational                      [Page 6]
+
+RFC 4260                  802.11 Fast Handover             November 2005
+
+
+   The coverage area of a single AP is known as a Basic Service Set
+   (BSS).  An Extended Service Set (ESS) is formed from a collection of
+   APs that all broadcast the same ESSID.  Note that an STA would send a
+   re-association (which includes both the old and new AP addresses)
+   only if the ESSID of the old and new APs are the same.
+
+   A change of BSS within an ESS may or may not require an IP-layer
+   handover, depending on whether the APs can send packets to the same
+   IP subnets.  If an IP-layer handover is required, then FMIPv6 can
+   decrease the overall latency of the handover.  The main goal of this
+   document is to describe the most reasonable scenarios for how the
+   events of an 802.11 handover may interleave with the message
+   exchanges in FMIPv6.
+
+5.  FMIPv6 Message Exchanges
+
+   An FMIPv6 handover nominally consists of the following messages:
+
+     a. The mobile node (MN) sends a Router Solicitation for Proxy
+        (RtSolPr) to find out about neighboring ARs.
+
+     b. The MN receives a Proxy Router Advertisement (PrRtAdv)
+        containing one or more [AP-ID, AR-Info] tuples.
+
+     c. The MN sends a Fast Binding Update (FBU) to the Previous Access
+        Router (PAR).
+
+     d. The PAR sends a Handover Initiate (HI) message to the New Access
+        Router (NAR).
+
+     e. The NAR sends a Handover Acknowledge (HAck) message to the PAR.
+
+     f. The PAR sends a Fast Binding Acknowledgement (FBack) message to
+        the MS on the new link.  The FBack is also optionally sent on
+        the previous link if the FBU was sent from there.
+
+     g. The MN sends Fast Neighbor Advertisement (FNA) to the NAR after
+        attaching to it.
+
+   The MN may connect to the NAR prior to sending the FBU if the
+   handover is unanticipated.  In this case, the FNA (step g) would
+   contain the FBU (listed as step c above) and then steps d, e, and f
+   would take place from there.
+
+
+
+
+
+
+
+
+McCann                       Informational                      [Page 7]
+
+RFC 4260                  802.11 Fast Handover             November 2005
+
+
+6.  Beacon Scanning and NAR Discovery
+
+   The RtSolPr message is used to request information about the
+   router(s) connected to one or more APs.  The APs are specified in the
+   New Access Point Link-Layer Address option in the RtSolPr and
+   associated IP-layer information is returned in the IP Address Option
+   of the PrRtAdv [2].  In the case of an 802.11 link, the link-layer
+   address is the BSSID of some AP.
+
+   Beacon scanning (step 1 from Section 4) produces a list of available
+   APs along with signal strength information for each.  This list would
+   supply the necessary addresses for the New Access Point Link-Layer
+   Address option(s) in the RtSolPr messages.  To obtain this list, the
+   host needs to invoke the MLME-SCAN.request primitive (see Section
+   10.3.2.1 of the 802.11 specification [3]).  The BSSIDs returned by
+   this primitive are the link-layer addresses of the available APs.
+
+   Because beacon scanning takes on the order of a few hundred
+   milliseconds to complete, and because it is generally not possible to
+   send and receive IP packets during this time, the MN needs to
+   schedule these events with care so that they do not disrupt ongoing
+   real-time services.  For example, the scan could be performed at the
+   time the MN attaches to the network prior to any real-time traffic.
+   However, if the interval between scanning and handover is too long,
+   the neighbor list may be out of date.  For example, the signal
+   strengths of neighboring APs may have dramatically changed, and a
+   handover directed to the apparently best AP from the old list may
+   fail.  If the handover is executed in firmware, the STA may even
+   choose a new target AP that is entirely missing from the old list
+   (after performing its own scan).  Both cases would limit the ability
+   of the MN to choose the correct NAR for the FBU in step c during an
+   anticipated handover.  Ongoing work in the IEEE 802.11k task group
+   may address extensions that allow interleaving beacon scanning with
+   data transmission/reception along with buffering at APs to minimize
+   packet loss.
+
+   Note that, aside from physical layer parameters such as signal
+   strength, it may be possible to obtain all necessary information
+   about neighboring APs by using the wildcard form of the RtSolPr
+   message.  This would cause the current access router to return a list
+   of neighboring APs and would not interrupt ongoing communication with
+   the current AP.  This request could be made at the time the MN first
+   attaches to the access router and periodically thereafter. This would
+   enable the MN to cache the necessary [AP-ID, AR-Info] tuples and
+   might enable it to react more quickly when a handover becomes
+   necessary due to a changing radio environment.  However, because the
+   information does not include up-to-date signal strength, it would not
+   enable the MN to predict accurately the next AP prior to a handover.
+
+
+
+McCann                       Informational                      [Page 8]
+
+RFC 4260                  802.11 Fast Handover             November 2005
+
+
+   Also, if the scale of the network is such that a given access router
+   is attached to many APs, then it is possible that there may not be
+   room to list all APs in the PrRtAdv.
+
+   The time taken to scan for beacons is significant because it involves
+   iteration through all 802.11 channels and listening on each one for
+   active beacons.  A more targeted approach would allow the STA to
+   scan, e.g., only one or two channels of interest, which would provide
+   for much shorter interruption of real-time traffic.  However, such
+   optimizations are currently outside the scope of 802.11
+   specifications.
+
+7.  Scenarios
+
+   In this section, we look at a few of the possible scenarios for using
+   FMIPv6 in an 802.11 context.  Each scenario is labeled by the
+   sequence of events that take place, where the numbered events are
+   from Section 4 and the lettered events are from Section 5.  For
+   example, "1abcde23456fg" represents step 1 from Section 4 followed by
+   steps a-e from Section 5 followed by steps 2-6 from Section 4
+   followed by steps f and g from Section 5.  This is the sequence where
+   the MN performs a scan, then the MN executes the FMIPv6 messaging to
+   obtain NAR information and send a binding update, then the PAR
+   initiates HI/HAck exchange, then the 802.11 handover completes, and
+   finally the HAck is received at the PAR and the MN sends an FNA.
+
+   Each scenario is followed by a brief description and discussion of
+   the benefits and drawbacks.
+
+7.1.  Scenario 1abcdef23456g
+
+   This scenario is the predictive mode of operation from the FMIPv6
+   specification.  In this scenario, the host executes the scan sometime
+   prior to the handover and is able to send the FBU prior to handover.
+   Only the FNA is sent after the handover.  This mode of operation
+   requires that the scan and join operations (steps 1 and 2) can be
+   performed separately and under host control, so that steps a-f can be
+   inserted between 1 and 2.  As mentioned previously, such control may
+   be possible in some implementations [10] but not in others.
+
+   Steps 1ab may be executed far in advance of the handover, which would
+   remove them from the critical path.  This would minimize the service
+   interruption from beacon scanning and allow at least one
+   RtSolPr/PrRtAdv exchange to complete so that the host has link-layer
+   information about some NARs.  Note that if steps ab were delayed
+   until handover is imminent, there would be no guarantee that the
+   RtSolPr/PrRtAdv exchange would complete especially in a radio
+   environment where the connection to the old AP is deteriorating
+
+
+
+McCann                       Informational                      [Page 9]
+
+RFC 4260                  802.11 Fast Handover             November 2005
+
+
+   rapidly.  However, if there were a long interval between the scan and
+   the handover, then the FBU (step c) would be created with out-of-date
+   information.  There is no guarantee that the MN will actually attach
+   to the desired new AP after it has sent the FBU to the oAR, because
+   changing radio conditions may cause NAR to be suddenly unreachable.
+   If this were the case, then the handover would need to devolve into
+   one of the reactive cases given below.
+
+7.2.  Scenario ab123456cdefg
+
+   This is the reactive mode of operation from the FMIPv6 specification.
+   This scenario does not require host intervention between steps 1 and
+   2.
+
+   However, it does require that the MN obtain the link-layer address of
+   NAR prior to handover, so that it has a link-layer destination
+   address for outgoing packets (default router information).  This
+   would then be used for sending the FNA (with encapsulated FBU) when
+   it reaches the new subnet.
+
+7.3.  Scenario 123456abcdefg
+
+   In this scenario, the MN does not obtain any information about the
+   NAR prior to executing the handover.  It is completely reactive and
+   consists of soliciting a router advertisement after handover and then
+   sending an FNA with encapsulated FBU immediately.
+
+   This scenario may be appropriate when it is difficult to learn the
+   link-layer address of the NAR prior to handover.  This may be the
+   case, e.g., if the scan primitive is not available to the host and
+   the wildcard PrRtAdv form returns too many results.  It may be
+   possible to skip the router advertisement/solicitation steps (ab) in
+   some cases, if it is possible to learn the NAR's link-layer address
+   through some other means.  In the deployment illustrated in Figure 2,
+   this would be exactly the new AP's MAC-layer address, which can be
+   learned from the link-layer handover messages.  However, in the case
+   of Figure 1, this information must be learned through router
+   discovery of some form.  Also note that even in the case of Figure 2,
+   the MN must somehow be made aware that it is in fact operating in a
+   Figure 2 network and not a Figure 1 network.
+
+8.  Security Considerations
+
+   The security considerations applicable to FMIPv6 are described in the
+   base FMIPv6 specification [2].  In particular, the PAR must be
+   assured of the authenticity of the FBU before it begins to redirect
+   user traffic.  However, if the association with the new AP is not
+
+
+
+
+McCann                       Informational                     [Page 10]
+
+RFC 4260                  802.11 Fast Handover             November 2005
+
+
+   protected using mutual authentication, it may be possible for a rogue
+   AP to fool the MN into sending an FBU to the PAR when it is not in
+   its best interest to do so.
+
+   Note that step 6 from Section 4 installs layer-2 forwarding state
+   that can redirect user traffic and cause disruption of service if it
+   can be triggered by a malicious node.
+
+   Note that step 3 from Section 4 could potentially provide some
+   security; however, due to the identified weaknesses in Wired
+   Equivalent Privacy (WEP) shared key security [9] this should not be
+   relied upon.  Instead, the Robust Security Network [6] will require
+   the STA to undergo 802.1X Port-Based Network Access Control [5]
+   before proceeding to steps 5 or 6. 802.1X defines a way to
+   encapsulate Extensible Authentication Protocol (EAP) on 802 networks
+   (EAPOL, for "EAP over LANs").  With this method, the client and AP
+   participate in an EAP exchange that itself can encapsulate any of the
+   various EAP authentication methods.  The EAPOL exchange can output a
+   Master Session Key (MSK) and Extended Master Session Key (EMSK),
+   which can then be used to derive transient keys, which in turn can be
+   used to encrypt/authenticate subsequent traffic.  It is possible to
+   use 802.1X pre-authentication [6] between an STA and a target AP
+   while the STA is associated with another AP; this would enable
+   authentication to be done in advance of handover, which would allow
+   faster resumption of service after roaming.  However, because EAPOL
+   frames carry only MAC-layer instead of IP-layer addresses, this is
+   currently only specified to work within a single VLAN, where IP-layer
+   handover mechanisms are not necessarily needed anyway.  In the most
+   interesting case for FMIPv6 (roaming across subnet boundaries), the
+   802.1X exchange would need to be performed after handover to the new
+   AP.  This would introduce additional handover delay while the 802.1X
+   exchange takes place, which may also involve round-trips to RADIUS or
+   Diameter servers.  The EAP exchange could be avoided if a preexisting
+   Pairwise Master Key (PMK) is found between the STA and the AP, which
+   may be the case if the STA has previously visited that AP or one that
+   shares a common back-end infrastructure.
+
+   Perhaps faster cross-subnet authentication could be achieved with the
+   use of pre-authentication using an IP-layer mechanism that could
+   cross subnet boundaries.  To our knowledge, this sort of work is not
+   currently under way in the IEEE.  The security considerations of
+   these new approaches would need to be carefully studied.
+
+
+
+
+
+
+
+
+
+McCann                       Informational                     [Page 11]
+
+RFC 4260                  802.11 Fast Handover             November 2005
+
+
+9.  Conclusions
+
+   The Mobile IPv6 Fast Handover specification presents a protocol for
+   shortening the period of service interruption during a change in
+   link-layer point of attachment.  This document attempts to show how
+   this protocol may be applied in the context of 802.11 access
+   networks.
+
+   Implementation of FMIPv6 must be done in the context of a particular
+   link-layer implementation, which must provide the triggers for the
+   FMIPv6 message flows.  For example, the host must be notified of such
+   events as degradation of signal strength or attachment to a new AP.
+
+   The particular implementation of the 802.11 hardware and firmware may
+   dictate how FMIPv6 is able to operate.  For example, to execute a
+   predictive handover, the scan request primitive must be available to
+   the host and the firmware must execute join operations only under
+   host control [10], not autonomously in response to its own handover
+   criteria.  Obtaining the desired PrRtAdv and sending an FBU
+   immediately prior to handover requires that messages be exchanged
+   over the wireless link during a period when connectivity is
+   degrading.  In some cases, the scenario given in Section 7.1 may not
+   complete successfully or the FBU may redirect traffic to the wrong
+   NAR.  However, in these cases the handover may devolve to the
+   scenario from Section 7.2 or the scenario from Section 7.3.
+   Ultimately, falling back to basic Mobile IPv6 operation [7] and
+   sending a Binding Update directly to the Home Agent can be used to
+   recover from any failure of the FMIPv6 protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCann                       Informational                     [Page 12]
+
+RFC 4260                  802.11 Fast Handover             November 2005
+
+
+10.  References
+
+10.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July
+        2005.
+
+   [3]  "Wireless LAN Medium Access Control (MAC) and Physical Layer
+        (PHY) Specifications", ANSI/IEEE Std 802.11, 1999 Edition.
+
+   [4]  Bahl, P., Bahl, P., and Chandra, R., "MultiNet: Enabling
+        Simultaneous Connections to Multiple Wireless Networks Using a
+        Single Radio", Microsoft Tech Report, MSR-TR-2003-46, June 2003.
+
+   [5]  "Port-Based Network Access Control", IEEE Std 802.1X-2004, July
+        2004.
+
+   [6]  "Medium Access Control (MAC) Security Enhancements", IEEE Std
+        802.11i-2004, July 2004.
+
+   [7]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
+        IPv6", RFC 3775, June 2004.
+
+10.2.  Informative References
+
+   [8]  Mitra, A., Shin, M., and Arbaugh, W., "An Empirical Analysis of
+        the IEEE 802.11 MAC Layer Handoff Process", CS-TR-4395,
+        University of Maryland Department of Computer Science, September
+        2002.
+
+   [9]  Borisov, N., Goldberg, I., and Wagner, D., "Intercepting Mobile
+        Communications: The Insecurity of 802.11", Proceedings of the
+        Seventh Annual International Conference on Mobile Computing and
+        Networking, July 2001, pp. 180-188.
+
+   [10] Malinen, J., "Host AP driver for Intersil Prism2/2.5/3 and WPA
+        Supplicant", http://hostap.epitest.fi/, July 2004.
+
+11.  Acknowledgements
+
+   Thanks to Bob O'Hara for providing explanation and insight on the
+   802.11 standards.  Thanks to James Kempf, Erik Anderlind, Rajeev
+   Koodli, and Bernard Aboba for providing comments on earlier versions.
+
+
+
+
+
+McCann                       Informational                     [Page 13]
+
+RFC 4260                  802.11 Fast Handover             November 2005
+
+
+Author's Address
+
+   Pete McCann
+   Lucent Technologies
+   Rm 9C-226R
+   1960 Lucent Lane
+   Naperville, IL  60563
+
+   Phone: +1 630 713 9359
+   Fax:   +1 630 713 1921
+   EMail: mccap@lucent.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCann                       Informational                     [Page 14]
+
+RFC 4260                  802.11 Fast Handover             November 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+McCann                       Informational                     [Page 15]
+