One document matched: draft-ietf-mipshop-80211fh-00.txt
Mobile IP
Internet Draft P. McCann
Document: draft-ietf-mipshop-80211fh-00.txt Lucent Technologies
Expires: August 2004 February 2004
Mobile IPv6 Fast Handovers for 802.11 Networks
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes how a Mobile IPv6 Fast Handover [2] could be
implemented on link layers conforming to the 802.11 suite of
specifications [3].
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 [4].
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. Deployment Architectures for Mobile IPv6 on 802.11.............4
4. 802.11 Handovers in Detail.....................................5
McCann Expires - August 2004 [Page 1]
802.11 Fast Handover February 2004
5. FMIPv6 Message Exchanges.......................................7
6. Beacon Scanning and NAR Discovery..............................7
7. Scenarios......................................................8
7.1 Scenario 1abcdef23456g.....................................9
7.2 Scenario ab123456cdefg.....................................9
7.3 Scenario 123456cdefg.......................................9
8. Security Considerations.......................................10
9. Conclusions...................................................11
References.......................................................11
Acknowledgments..................................................13
Author's Address.................................................13
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.
Note that there may be other sources of service interruption that may
be "built-in" to the link-layer handoff. For example, one study has
concluded that the 802.11 beacon scanning function may take several
hundred milliseconds to complete [5] during which time sending and
receiving IP packets is not possible. This sort of interruption may
present an obstacle to real-time service deployment that needs
further optimization; however, such optimization is outside the scope
of this document.
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 removes such Mobile IP registration, which may require
time-consuming Internet round-trips, from the critical path before
real-time service is re-established.
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
McCann Expires - July 2004 [Page 2]
802.11 Fast Handover February 2004
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 give details on how the proposed
Mobile IPv6 Fast Handover protocol would work in this environment.
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):
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.
Inter-Access Point Protocol (IAPP): A protocol defined for use
between access points [6] at handover time that
allows for the old association with the old AP to be
deleted, and for context to be transferred to the new
AP.
McCann Expires - July 2004 [Page 3]
802.11 Fast Handover February 2004
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. Here we consider only the
infrastructure mode [3] of 802.11. A given STA may be associated
with one and only one AP at any given point in time; when a STA moves
out of the coverage area of a given AP it must handover (re-
associate) with a new AP. It is important to understand that 802.11
offers great flexibility, and that handover from one AP to another
does not necessarily mean a change of AR or subnet.
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. Each subnet is implemented as a single LAN or VLAN.
Note that a handover from AP1 to AP2 does not require a change of AR
because all three ARs are link-layer reachable from a STA connected
to any AP1-5. Therefore, such handoffs are outside the scope of IP-
layer handover mechanisms. However, a handoff from AP5 to AP6 would
require a change of AR, because 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.
McCann Expires - July 2004 [Page 4]
802.11 Fast Handover February 2004
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. In this case, every change of AP
would result in a necessary change of AR, which 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 a STA changes its association
from one AP to another ("re-association"). This process consists of
the following steps:
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 the IAPP [6], the new AP
performs a lookup based on MAC-layer address to obtain the IP
McCann Expires - July 2004 [Page 5]
802.11 Fast Handover February 2004
address of the old AP by consulting a local table or RADIUS
server. It opens a UDP or TCP connection, protected by IPSec
encryption, to the old AP. Via the secure connection, it
informs the old AP of the re-association so that information
about the STA is deleted from the old AP. Note that IAPP can
only be invoked based on a re-association message, as the plain
association message does not contain the old AP's MAC-layer
address.
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.
Note that in most existing 802.11 implementations, steps 1-4 are
performed by firmware that is on-board the 802.11 PCMCIA card. This
might make it impossible for the host to take any actions (including
sending or receiving IP packets) before the handoff is complete.
During step 5, IAPP is used to communicate with the old AP. The
IPSec tunnel between the two APs is originally established with key
distribution via RADIUS, but can be subsequently re-used for
different MNs that may need to handover between the same pair of APs.
Note that the SA is between the pair of APs and has nothing to do
with any security association that might be in place between the MN
and either of the APs. During IAPP operation, link-layer context may
be transferred from the old AP to the new AP. The IAPP defines a
container for context information. However, no such context has
currently been defined or standardized by IEEE.
Also note that 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. Usually, this decision is
implemented in firmware and the attached host would have no control
over which AP is chosen.
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. Usually this
step will be performed autonomously by firmware in the NIC using
proprietary scanning algorithms.
The coverage area of a single AP is known as a Basic Service Set
(BSS). Note that both APs in the above description are considered to
belong to the same Extended Service Set (ESS). This is to trigger a
re-association (rather than plain association) from the STA, which
contains information about both the old and new AP. All APs should
therefore broadcast the same ESSID. If two APs belong to different
administrative domains, this may require some inter-domain
McCann Expires - July 2004 [Page 6]
802.11 Fast Handover February 2004
coordination of the ESSID. Otherwise, there may not be sufficient
information to construct the link-layer triggers required by some
handover mechanisms.
A change of BSS within an ESS may or may not require an IP-layer
handover, depending on whether the APs provide STAs access to
different or the same IP subnets. If an IP-layer handover is
required, then FMIPv6 may be used to 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 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 an HI message to the New Access Router (NAR).
e. The NAR sends a HAck message to the PAR.
f. The PAR sends a Fast Binding Acknowledgement (FBack) message to
the MS the new link. The FBack is also optionally sent on the
previous link if the FBU was sent from there.
g. The MN sends FNA to the NAR after attaching to it.
The MN may connect to NAR prior to sending the FBU if the handover is
un-anticipated. 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.
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 by
link layer address in the RtSolPr and associated IP-layer information
McCann Expires - July 2004 [Page 7]
802.11 Fast Handover February 2004
is returned in the PrRtAdv. 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 BSSIDs to fill into the RtSolPr messages. Note
that for this to be possible, the MLME-SCAN.request primitive (See
Section 10.3.2.1 of the 802.11 specification [3]) must be available
to the host, and the card firmware must not make autonomous handover
decisions.
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. 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, 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.
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.
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" 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.
McCann Expires - July 2004 [Page 8]
802.11 Fast Handover February 2004
7.1 Scenario 1abcdef23456g
This scenario is the one most envisioned by the FMIPv6 specification.
Note that in this scenario, the scan request primitive is made
available to the host and the firmware in the 802.11 device does not
autonomously make handover decisions.
There is no guarantee that the RtSolPr/PrRtAdv exchange will complete
especially in a radio environment where the connection to the old AP
is deteriorating rapidly. Also, there is no guarantee that the MN
will actually attach to the given new AP after it has sent the F-BU
to the oAR, because changing radio conditions may cause nAR to be
suddenly unreachable.
7.2 Scenario ab123456cdefg
This is the "reactive handover" 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 handoff 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. One option might be the
Candidate Access Router (CAR) discovery protocol [7] currently being
worked in the Seamoby working group.
McCann Expires - July 2004 [Page 9]
802.11 Fast Handover February 2004
8. Security Considerations
The FBU message (the only FMIPv6 message that sets up forwarding
state) is protected by well-understood Mobile IPv6 security
mechanisms, so the PAR can guarantee it was actually generated by the
MS. 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.
There are several security issues of note with the underlying 802.11
handoff mechanisms. Note that steps 5 and 6 from Section 4 install
layer-2 forwarding state that can redirect user traffic and cause
disruption of service if they can be triggered by malicious nodes.
Note that step 3 from Section 4 could potentially provide some
security; however, due to the identified weaknesses in WEP shared key
security [8], there is currently no authentication algorithm for step
3 that is both standardized and secure.
It may be the case that many deployments are configured as "Open
Systems", which will rely instead on higher-layer authentication such
as 802.1X Port-Based Network Access Control [9]. According to
published standards, such authentication techniques would happen only
after association or re-association takes place, which leaves the re-
association messages unprotected. This would allow malicious nodes
to redirect traffic to a different AP on the same subnet. Work is
currently underway to better integrate 802.1X with 802.11 [10] but it
is not yet complete.
The 802.1X standard defines a way to encapsulate EAP on 802 networks
(EAPOL, for "EAP over LANs"). With this method, the client and AP
participate in an EAP exchange which itself can encapsulate any of
the various EAP authentication methods. The EAPOL exchange can
output a master key, which can then be used to derive transient keys,
which in turn can be used to encipher/authenticate subsequent
traffic. It is possible to use 802.1X pre-authentication [10]
between a 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 both protect the re-association message and
allow fast 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 subnet, where IP
layer handoff mechanisms are not needed anyway. In our case (roaming
across subnet boundaries) the 802.1X exchange would need to be
performed after roaming to, but prior to re-association with, the new
AP. This would introduce additional handover delay while the 802.1X
McCann Expires - July 2004 [Page 10]
802.11 Fast Handover February 2004
exchange takes place, which may also involve round-trips to RADIUS or
Diameter servers.
Perhaps faster cross-subnet authentication could be achieved by
leveraging the context transfer features of the IAPP to carry
security credentials [11], or with the use of pre-authentication
using an IP-layer mechanism such as PANA [12] that would cross subnet
boundaries. To our knowledge this sort of work is not currently
underway in the IEEE. The security considerations of these new
approaches would need to be carefully studied.
9. Conclusions
The Mobile IPv6 Fast Handoff 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.
There are currently serious security problems in the published
specifications that define the 802.11 handover process that must be
fixed before even intra-subnet mobility can be considered secure.
In-progress specifications may fix these problems but may also
introduce additional delay for handover across different subnets.
Usually, only the APs themselves are aware that good link-layer
security is in place. This information could be made available to
ARs with the use of a new protocol, but such mechanisms are prone to
be link-layer specific.
Obtaining the desired PrRtAdv prior to handover requires that
messages be exchanged over the wireless link during a period that is
normally under the control of low-level firmware. The performance
impact of this requirement, and of the failure to meet it in certain
radio conditions, must be critically evaluated with experimental
data. Also, given a particular firmware implementation of handover,
it may be impossible for a host to send the required IP-layer
messages as indicated in the scenario from Section 7.1. However, in
these cases it seems that the scenario from Section 7.2 or at worst
the scenario from Section 7.3 present reasonable fall-back
strategies.
References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
McCann Expires - July 2004 [Page 11]
802.11 Fast Handover February 2004
2 Koodli, R. (editor), "Fast Handovers for Mobile IPv6", draft-ietf-
mipshop-fast-mipv6-01.txt, February 2004. Work In Progress.
3 "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications", ANSI/IEEE Std 802.11, 1999 Edition.
4 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
5 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.
6 "Recommended Practice for Multi-Vendor Access Point
Interoperability via an Inter-Access Point Protocol Across
Distribution Systems Supporting IEEE 802.11 Operation", IEEE Std
802.11f/D4, July 2002. Work In Progress.
7 Liebsch, M., Singh, A. (editors), Chaskar, H., Funato, D., Shim,
E., "Candidate Access Router Discovery", draft-ietf-seamoby-card-
protocol-06.txt, December 2003. Work In Progress.
8 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.
9 "Port-Based Network Access Control", IEEE Std 802.1X-2001,
October, 2001.
10 "Draft Supplement to IEEE 802.11: Specification for Enhanced
Security", IEEE Std 802.11i/D2.2, July 2002. Work In Progress.
11 Aboba, B., and Moore, T., "A Model for Context Transfer in IEEE
802", draft-aboba-context-802-00.txt, October 2003. Work In
Progress.
12 Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., "Protocol for
Carrying Authentication for Network Access (PANA)", draft-ietf-
pana-pana-02.txt, October 2003. Work In Progress.
McCann Expires - July 2004 [Page 12]
802.11 Fast Handover February 2004
Acknowledgments
Thanks to Bob O'Hara for providing explanation and insight on the
802.11 standards. Thanks to James Kempf and Erik Anderlind for
providing comments on an earlier draft.
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
Intellectual Property Statement
At the time of submission the author is not aware of any intellectual
property rights that pertain to the implementation or use of the
technology described in this document. However, this does not
preclude the possibility that Lucent Technologies, Inc. or other
entities may have such rights. The patent licensing policy of Lucent
Technologies, Inc. is on file with the IETF Secretariat.
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights, which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
McCann Expires - July 2004 [Page 13]
802.11 Fast Handover February 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
McCann Expires - July 2004 [Page 14] | PAFTECH AB 2003-2026 | 2026-04-24 04:35:46 |