Internet DRAFT - draft-gwon-mobileip-efwd-fmipv6
draft-gwon-mobileip-efwd-fmipv6
Network Working Group Youngjune Gwon
draft-gwon-mobileip-efwd-fmipv6-01.txt Alper E. Yegin
Expires: June 24, 2002 DoCoMo USA Labs
Enhanced Forwarding from Previous Care-of Address
for Fast Mobile IPv6 Handovers (eFWD)
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. This is an individual
draft for consideration by the Mobileip Working Group.
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 memo introduces a low latency and low loss handover protocol
that enhances the performance of forwarding from previous care-of
address for Mobile IPv6, namely eFWD. The eFWD allows a mobile node
to control and initiate creation of a bi-directional tunnel between
the old and the new access routers subsequent to link layer
handover. The eFWD handover reduces IP handover latency by
eliminating new care-of address acquisition time and by identifying
new access router information in advance utilizing Candidate Access
Router Information Discovery (CARID) process detailed in this memo.
The eFWD protocol removes extra burden on link layer by eliminating
any requirement on pre-triggers.
Gwon and Yegin Expires June 24, 2003
[Page 2] eFWD December 2002
Table of Contents
1. Introduction....................................................2
2. Terminology.....................................................3
3. Problem Statement and Solution..................................4
4. The Protocol....................................................6
4.1 Overview.....................................................6
4.2 Requirements.................................................8
4.2.1 Control Messages.........................................8
4.2.2 Candidate Access Router Information Discovery (CARID)...13
5. Security Considerations........................................15
6. References.....................................................15
7. Addresses of Authors...........................................16
8. Acknowledgment.................................................16
9. IPR Statement..................................................16
10. Full Copyright Statement......................................17
1. Introduction
The Mobile IP Working Group has considered low latency and low loss
handover protocols for Mobile IPv6 that can seamlessly support real-
time applications. The standard Mobile IPv6 [1] handover process
reveals numerous problems manifested by time-consuming network
layer-based movement detection, non-optimized time sequencing of
handover procedures, and latency of configuring a new care-of
address. The Fast Mobile IPv6 Handover Protocol is designed to solve
these problems. The current proposal of the fast handover protocol
[2] is based on having link layer information available prior to the
actual handover so that the mobile node and the access routers
should prepare/anticipate for IP handover. In general, the fast
handover protocol tends to impose extra set of functions and
requirements over the link layer known as link layer triggers (L2
triggers) [3].
In this memo, an extension of the fast Mobile IPv6 protocol is
proposed that allows a mobile node to control and initiate the
creation of a bi-directional tunnel between the old and new access
routers immediately after link layer handover has been completed,
namely Enhanced Forwarding from Previous Care-of Address (eFWD). The
eFWD optimizes IP handover latency by eliminating new care-of
address acquisition and by identifying new access router information
in advance. It should be noted that eFWD is free from link layer
pre-triggers.
2. Terminology
Mobile Node (MN)
A Mobile Node is a Mobile IPv6 host capable of moving its point
of attachment to the Internet.
Gwon Expires June 24, 2003
[Page 3] eFWD December 2002
Access Router (AR)
An Access Router is the last router between the network and the
mobile node, i.e., the MN has link Layer connectivity to the
Access Router.
Access Point (AP)
A first-hop link layer device between the access router and the
mobile node.
Old Access Router (oAR)
The access router involved in handling a MN's traffic prior to
an L2 Handover.
New Access Router (nAR)
The access router anticipated to be handling a MN's traffic
after completion of an L2 handover.
Old Care-of Address (oCoA)
The care-of address prior to the MN's first movement. In this
memo, it may be reused until the MN determines an appropriate
time to change it, even if the MN changes subnet.
New Care-of Address (nCoA)
The care-of address in the new subnet. In this memo,
configuration with a nCoA does not have to take place
immediately after L2 handover.
Bi-directional tunnel (BT)
A bi-directional tunnel placed between the ARs where the MN
first established its current CoA and a new AR to which the MN
is attached where the CoA would be topologically incorrect if
used. The new AR tunnels packets from the MN and having the
source address as the MN's old CoA to the old AR. The old AR
tunnels packets to the MN and having the destination address as
the MN's old CoA to new AR. The new AR detunnels the MN-
directed packets and sends them over the radio link to the MN
(and hence there is no tunnel overhead on the air link). The
old AR detunnels correspondent node-directed packets and sends
them into the subnet where the old CoA is topologically
correct. BTs allow use of the old CoA without running the risk
of ingress or egress filtering.
Link-layer Handover (L2 Handover)
Movement of a MN's point of layer 2 (L2) connection from one
wireless access point to another. Depending on the L2, an L2
handover may traverse both a wireless and a wired link, or just
a wired link.
IP Handover (L3 handover)
The process by which a MN obtains a new CoA from the AR, thus
updating its routing reachability. L3 handover may occur
Gwon Expires June 24, 2003
[Page 4] eFWD December 2002
partially before and partially after L2 handover, or it may
occur entirely after L2 handover.
Link-layer Trigger (L2 Trigger)
Information from L2 that informs L3 of the detailed events
involved in handover sequencing at L2. L2 triggers are not
specific to any particular L2, but rather represent
generalizations of L2 information available from a wide variety
of L2 protocols.
3. Problem Statement and Solution
The process of Mobile IP network layer handover incurs certain
protocol exchanges. These protocol actions are needed to establish
on-link connectivity at the new network where a mobile node has
moved to, and also to update the remote home agent(s) and end-points
for end-to-end connectivity.
When the standard Mobile IPv6 is used for network layer handovers,
the mobile node first needs to detect the network layer movement.
This can be accomplished via observing network prefixes, or relying
on L2 triggers. The latter provides much quicker detection wherever
such link layer support is available. Secondly, the mobile node
needs to discover the IPv6 subnet prefix, if it is going to use
stateless address auto-configuration. If movement detection were
based on listening to router advertisements, this step is already
covered. Otherwise, the mobile node needs to send a router
solicitation and receive router advertisements from access routers
to learn the IPv6 prefixes available on the link. Third step is
configuring a new care-of address. Mobile node can auto-configure a
new care-of address based on one of the prefixes and has to go
through a duplicate address detection [4] to make sure this address
is unique. Finally, the mobile node has to send binding updates to
its home agent and correspondent nodes to inform them about its new
location.
Mobile node is unreachable from the Internet until its new binding
Update is received by the home agent and the correspondent nodes.
Each of these steps takes time. Therefore, we are motivated to
optimize or eliminate some of these steps to minimize the length of
service disruption.
The L2 triggers are utilized to optimize movement detection process.
This saves waiting time to receive few subsequent router
advertisements. Binding update process is already optimized by the
standard Mobile IPv6 protocol. Binding updates are sent to the old
access router instead of home agent when forwarding from the
previous care-of address is applied. This optimization saves a round
trip time across the Internet. What is left can be summarized as
configuring a new care-of address, which relies on prefix discovery
and duplicate address detection. Depending on the implementation and
configuration, this can be the costliest step among others.
Gwon Expires June 24, 2003
[Page 5] eFWD December 2002
Latency of configuring a new care-of address can be eliminated if IP
address of the new access router (where mobile node has just moved
to) is used as the new care-of address momentarily. If the mobile
node can send a binding update to the old access router, informing
the old care-of address as the home address and IP address of the
new access router as the care-of address, forwarding from the
previous care-of address is established through a tunnel between the
old access router and the new access router. Since the new access
router is the tunnel end-point for forwarded packets, it will have
to play a role to decapsulate the packets for this method. In
standard Mobile IPv6, the new access router does not have this
special role and it simply forwards packets for on-link IP addresses
without being aware of mobile node's mobility. Once forwarding from
the previous care-of address is established, the old access router
intercepts packets sent to the old care-of address and tunnels them
to the new access router. The new access router decapsulates
tunneled packets and forwards them to the mobile node via one of its
interfaces. Similarly, packets sent by the mobile node must be
intercepted by the new router and tunneled back to the old access
router. By doing so, the packets can be forwarded to the mobile node
even before the mobile node has to configure a new care-of address
using the new prefix. This approach provides an optimized solution
for Mobile IPv6 fast handover when accompanied with link-up trigger
[3] for movement detection.
This is a mobile-controlled protocol in which mobile node is in
charge of IP handovers. It only relies on the link-up trigger and
requires no pre-triggers that are based on movement anticipation. In
other words, benefits of this approach are reliability that only a
successful link layer handover triggers subsequent IP handovers and
independence of complexity in pre-signaling before the actual
handover.
4. The Protocol
4.1 Overview
Figure 1 illustrates Enhanced Forwarding from Previous Care-of
Address (eFWD) handover. eFWD is initiated by mobile node when it
receives a link-up trigger immediately after arriving at the new
access point (nAP). The mobile node must send eFWD BU informing the
old access router (oAR) about the new care-of address, therefore new
access router (nAR) information, so that the oAR can send HI message
to the nAR. We describe a method of doing so via Candidate Access
Router Information Discovery (CARID) procedure in detail in 4.2.2 of
this memo. The CARID allows the mobile node to learn handover
candidate access router information at some sufficient time prior to
the actual handover. The list of access routers obtained via CARID
includes all possible next routers a host might handover to. After a
successful link layer handover, mobile node learns the L2 ID of the
Gwon Expires June 24, 2003
[Page 6] eFWD December 2002
new access point (nAP) and maps it to the link layer and network
layer IDs of the corresponding nAR.
_______ 3. HI _______
| |----------------->| |
| |<-----------------| |
| | 4. HAck | |
| oAR | | nAR |
| | 5. BAck | |
| |----------------->| |-+
|_______|<-----------------|_______| |
@ 2. BU @ ^ |
@ @ | |
@ @ | |
@ @ | |
/ \ / \ | |
/oAP\ /nAP\ | |
/_____\ /_____\ | |
| | |
| | | 5. BAck
| 2. | |
1. Link Up | BU | |
| | |
V | |
______ | |
0. MN has performed CARID and moved | |-+ |
==============>| MN |<---+
|______|
Figure 1: eFWD Handover
Once MN identifies the information about the nAR, it constructs a BU
and sends it to the oAR via nAR. In this BU, home address field is
set to the old care-of address, and the care-of address field is set
to the IP address of nAR. When this BU reaches at the oAR, HI and
HACK messages are exchanged between the oAR and nAR to set up a bi-
directional tunnel. With BU being acknowledged (i.e. BAck tunneled
to the nAR and forwarded to the MN), incoming packets destined to
the mobile node's old care-of address are tunneled by the oAR and
the nAR decapsulates and forwards them to the mobile node. Finally,
the mobile node may decide to acquire a new care-of address at
sometime later and update this information with its home agent and
all nodes of interest such as correspondent nodes. It can also
choose to terminate the forwarding from previous care-of address by
sending a de-registration BU to the oAR.
4.2 Requirements
4.2.1 Control Messages
eFWD creates no new control messages. It inherits four control
messages are already defined by the standard and the fast Mobile
Gwon Expires June 24, 2003
[Page 7] eFWD December 2002
IPv6 protocols: Binding Update (BU), Binding Acknowledgment (BAck),
Handover Initiation (HI), and Handover Acknowledgment (HAck)
messages. eFWD requires a slight modification onto the existent
Binding Update (BU) message defined in [1]. P bit is added to
distinguish eFWD handover from other usages. The Binding Update
message used by eFWD is described as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|S|D|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Layer Fields:
L2 Source
L2 ID of MN
L2 Destination
L2 ID of nAR
IP Fields:
Source IP Address
Old care-of address of MN
Destination IP Address
IP address of oAR
Acknowledge (A)
As specified in [1]
Home Registration (H)
Must be set for eFWD
Gwon Expires June 24, 2003
[Page 8] eFWD December 2002
Single Address Only (S)
As specified in [1]
Duplicate Address Detection (D)
As specified in [1]
Enhanced Forwarding from Preivous Care-of Address (P)
Must be set for eFWD
Reserved
As specified in [1]
Sequence #
As specified in [1]
Lifetime
As specified in [1]
Home Address
Old care-of address of mobile node
Mobility options
This BU must include two options, i.e. alternate care-
of address and link-layer address of MN options
Alternate care-of address
The alternate care-of address field of this option must
set to IP address of the nAR. The oAR sends HI message
to this address.
Link-layer address (LLA) of MN
This is a new mobility option that must be supported
for eFWD. The value of this option must be set to link-
layer address of MN so that nAR knows how to forward
packets to the MN when packets destined to the MN
arrives from oAR. This option format is defined as
follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Option Type
TBD
Length
The length of this option, in bytes.
Gwon Expires June 24, 2003
[Page 9] eFWD December 2002
Option Data
Variable length link-layer address of MN. The content and
format of this field (including byte and bit ordering) is
expected to be specified in specific documents that
describe how IPv6 operates over different link layers.
Handover Initiation Message used in eFWD is as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |S|U|H|T|R|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
IP address of oAR
Destination Address
IP address of nAR
ICMP Fields:
Type
TBD
Code
0
Checksum
As specified in [2]
Identifier
As specified in [2]
S
This bit must be unset
U
As specified in [2]
H
This bit must be unset
T
This bit must be unset
R
This bit must be unset
Gwon Expires June 24, 2003
[Page 10] eFWD December 2002
Reserved
Must set to zero and ignored by receiver
Options
Must include both link layer-address of MN option and
old care-of address option as specified by [2]. Link-
layer address of MN is copied from the incoming eFWD BU
(inserted as the new Link Layer Address Option defined
above). Old care-of address option is copied from the
home address field of incoming BU.
Accordingly, Handover Acknowledgment Message for eFWD is as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |H|T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
IP address of nAR
Destination Address
IP address of oAR
ICMP Fields:
Type
TBD
Code
As specified in [2]
Checksum
As specified in [2]
Identifier
As specified in [2]
H
This bit must be unset
T
This bit must be unset
Gwon Expires June 24, 2003
[Page 11] eFWD December 2002
R
This bit must be unset
Reserved
Must set to zero and ignored by receiver
Options
Must contain lifetime option. This indicates the
maximum lifetime that the oAR can put in the lifetime
field of the BAck message.
4.2.2 Candidate Access Router Information Discovery (CARID)
Fast handover domain is defined by a set of access routers and their
associated access points. An access router must maintain either a
complete list of all access routers in the domain, or a partial list
of access routers that are in the same geographic neighborhood,
known as geographically adjacent access routers (GAAR). Subset of
the GAARs becomes potential handover candidate access routers for
visiting mobile nodes. Each entry in the table must contain IP
address of the access router, along with link layer address of the
access router and link layer address of the associated access
points. When a mobile node associates with an access point, all it
can figure out is the link-layer address of the access point. Mobile
node can identify the associated access router by doing a look up on
this table. If such a look up fails, that means fast handover to
this network is not supported and the mobile node has to resort to
regular Mobile IPv6 handover.
Creation and maintenance of this table on the access routers is
outside the scope of this memo. It can be done manually or by some
dynamic means.
Mobile node should be able to request this table from its current
access router anytime, not necessarily right before a handover.
Gwon Expires June 24, 2003
[Page 12] eFWD December 2002
UDP fields:
Source Port
Variable
Destination Port
TBD
The UDP header is followed by the CARID fields shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Data... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-
Type
1 - Request
2 - Response
Length
Length of data in bytes. 0 if this is a Request type.
Data field is used only with Response. This field contains a
sequence of options in the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | Length | Data... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-
Sub-Type
1 - IP address of the access router
2 - Link layer address of the access router
3 - Link layer address of the access point
Length
Length of data in bytes
Sub-type 1 contains IPv6 address of the access router (16 bytes).
Sub-types 2 and 3 are to contain link layer addresses of access
router and access points. The content and format of this field
(including byte and bit ordering) are described in specific
documents that explain how IPv6 operates over different link layers,
such as IPv6 over Ethernet (RFC 2464).
Gwon Expires June 24, 2003
[Page 13] eFWD December 2002
A CARID response carries a list of access routers in its payload.
Information related to each access router must begin with Sub-type 1
field (i.e. access router's IPv6 address). This data must be
followed by the link-layer address(es) of this access router. And
each link-layer address of the access router must be followed by
link-layer address(es) of the associated access points. All Sub-type
2 and Sub-type 3 data before the next sub-type 1 data are associated
with the access router identified by the leading sub-type 1 data
(IPv6 address). All sub-type 3 data before the next sub-type 1 or
sub-type 2 data is associated with the access point identified by
the leading sub-type 2 data.
Data field of a CARID Response must follow an order, such that sub-
type 1 is always followed by sub-type 2, and sub-type 2 is always
followed by sub-type 3.
5. Security Considerations
The protocol exchanges defined in this memo cause routing changes.
After a successful protocol signaling, access routers create bi-
directional tunnels and install host-based routes to direct a given
mobile node's traffic differently than what they would normally do
based on the prefix information. Any protocol signaling that can
cause such changes in routing needs to be secured in order to
prevent malicious nodes taking advantage of them.
It is assumed that access routers in a fast handover domain have
pre-established security associations among themselves. Therefore,
they can use IPSec [5] [6] to secure HI/HAck messages.
We cannot assume that a similar pre-established security association
will be available between the mobile node and every possible access
router. Therefore, this security association needs to be created
dynamically. Since mobile node has been receiving IP service from
the access router even before the signaling of this protocol, it is
assumed that they can establish such a security association based on
link layer or network layer methods [3] [7]. Specifics of these
methods are outside the scope of this work. Once such an association
is established, the mobile node and the access routers can use IPSec
to secure BU/BAck and the CARID Request/Response messaging.
6. References
[1] Johnson, D., B., et al., "Mobility Support in IPv6," draft-ietf-
mobileip-ipv6-19.txt, a work in progress, October 2002
[2] Koodli, R., et al., "Fast Handovers for Mobile IPv6," draft-
ietf-mobileip-fast-mipv6-05.txt, a work in progress, September 2002
[3] Kempf, J., et al., "Supporting Optimized Handover for IP
Mobility - Requirements for Underlying Systems," draft-manyfolks-l2-
mobilereq-02.txt, a work in progress, June 2002
Gwon Expires June 24, 2003
[Page 14] eFWD December 2002
[4] Narten, T., et al., "Neighbor Discovery for IP Version 6
(IPv6)," RFC 2461, December 1998
[5] Kent, S., "IP Authentication Header," draft-ietf-ipsec-
rfc2402bis-01.txt, a work in progress, July 2002
[6] Kent, S., "IP Encapsulating Security Payload (ESP)," draft-ietf-
ipsec-esp-v3-03.txt, a work in progress, July 2002
[7] Penno, R., ôProtocol for Carrying Authentication for Network
Access (PANA) Requirements and Terminology,ö draft-ietf-pana-
requirements-04.txt, a work in progress, October 2002
7. Addresses of Authors
Youngjune Gwon, Editor
DoCoMo Communications Laboratories USA, Inc.
181 Metro Drive, Suite 300 Phone: +1 408 451 4734
San Jose, CA 95110 Fax: +1 408 451 1090
USA email: gyj@docomolabs-usa.com
Alper E. Yegin
DoCoMo Communications Laboratories USA, Inc.
181 Metro Drive, Suite 300 Phone: +1 408 451 4743
San Jose, CA 95110 Fax: +1 408 451 1090
USA email: alper@docomolabs-usa.com
8. Acknowledgment
Authors of this memo thank James Kempf, Atsushi Takeshita, Carl
Williams, Ravi Jain, Daichi Funato, Guangrui Fu, and Jonathan Wood
for their valuable discussion, comments, and support.
9. IPR Statement
The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
10. Full Copyright Statement
Copyright (C) The Internet Society (2001). 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
Gwon Expires June 24, 2003
[Page 15] eFWD December 2002
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.
Gwon Expires June 24, 2003
