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