Mobile IP Working Group Hee Young Jung, ETRI
Internet Draft Seok Joo Koh, ETRI
Internet Engineering Task Force Jun Seob Lee, ETRI
Expires December 2003 Hesham Soliman, Flarion
June 2003 Karim El-Malki, Ericsson
Fast Handover for Hierarchical MIPv6 (F-HMIPv6)
<draft-jung-mobileip-fastho-hmipv6-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 [1].
Internet-Drafts are 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 a "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 addresses Fast Handover over HMIPv6 networks. A simple
integration of FMIPv6 with HMIPv6 may induce unnecessary processing
overhead for re-tunneling at the previous Access Router and
inefficient usage of network bandwidth. This document describes the
Fast Handover for HMIPv6 (F-HMIPv6), which is designed to be friendly
with the data transport feature of HMIPv6. In F-HMIPv6, the Mobile
Nodes inform the MAP about its movement anticipation and thus the bi-
directional tunnels for fast handover are established between MAP and
NAR, not between PAR and NAR. The F-HMIPv6 scheme utilizes the
existing FMIPv6 messages, without defining any new control messages.
Jung, Koh, Lee, Soliman, El-Malki [Page 1]
INTERNET DRAFT Fast Handover for HMIPv6 June 2003
Table of Contents
1. Introduction..................................................3
2. Terminology...................................................3
3. Data Flows by F-HMIPv6........................................4
4. Generic Operations for F-HMIPv6...............................7
5. Variants of F-HMIPv6..........................................9
5.1 Network-initiated Handover................................9
5.2 No Anticipation...........................................9
6. Messages for F-HMIPv6.........................................9
6.1 A New Flag in the HMIPv6 MAP Option......................10
6.2 Use of FMIPv6 messages...................................10
7. Enhancement of F-HMIPv6 Operations...........................11
7.1 F-HMIPv6 with Tunnel Extension to MN.....................11
7.2 F-HMIPv6 with Bicasting..................................12
8. Security Considerations......................................13
9. Acknowledgement..............................................14
10. References..................................................14
Author's Addresses..............................................15
Jung, Koh, Lee, Soliman, El-Malki [Page 2]
INTERNET DRAFT Fast Handover for HMIPv6 June 2003
1. Introduction
The Hierarchical MIPv6 (HMIPv6) facilitates to reduce the delay
concerned with the location update, in which an MN sends a local
Binding Updates (BU) to the local MAP, rather than the Home Agent and
Correspondent Nodes that are typically further away. On the other
hand, the Fast Handover for MIPv6 (FMIPv6) uses L2 signals for
earlier movement detection and configuration of a new CoA for the new
access router in advance, so as to minimize the disruption of
services during handover. Both the FMIPv6 and HMIPv6 schemes have
been developed to reduce the handover latency in their own ways. This
document aims at finding a proper combination of those two schemes to
provide better handover performance.
This document addresses Fast Handover over HMIPv6 networks in terms
of data flows and control operations. At a glance, it may be
straightforward to simply integrate the FMIPv6 scheme with HMIPv6.
However, such simple integration may induce unnecessary processing
overhead for re-tunneling at the previous Access Routers and also
inefficient usage of network bandwidth. The main reason for this is
that the data transport of HMIPv6 is based on the tunneling from the
MAP to MNs not ARs, while the FMIPv6 uses the tunneling between the
previous and new Access Routers for fast handover.
This document describes Fast Handover scheme for HMIPv6 (F-HMIPv6),
in which a bi-directional tunnels for fast handover is established
between MAP and NAR, not between PAR and NAR. For this purpose, the
Fast BU (FBU) message is sent to MAP, not PAR, by MN. In addition, we
discuss further enhancements of F-HMIPv6 by considering the data
transport feature of HMIPv6, which include the tunnel extension from
MAP to MN, not NAR, and the bicasting of MAP. The F-HMIPv6 utilizes
the well-defined FMIPv6 messages, without defining any new messages.
2. Terminology
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 [2].
This document uses all the terminology described in the MIPv6 [3],
HMIPv6 [4], and FMIPv6 [5] documents. In addition, this document uses
the following terms for the on-link Care of Address (LCoA):
PLCoA: MN's LCoA valid on the Previous Access Router (PAR). It
corresponds to the PCoA of the FMIPv6.
NLCoA: MN's LCoA valid on the New Access Router (NAR). It corresponds
to the NCoA of the FMIPv6.
Jung, Koh, Lee, Soliman, El-Malki [Page 3]
INTERNET DRAFT Fast Handover for HMIPv6 June 2003
3. Data Flows by F-HMIPv6
Figure 1 illustrates a reference configuration for fast handover in
HMIPv6 networks. In the figure, the MAP acts as an aggregation router
in the hierarchical domain. In the domain, a mobile node (MN) moves
from the previous AR (PAR) region into the new AR (NAR) region, and
the corresponding LCoA will change from PLCoA to NLCoA.
+-------+
| HA |
+-------+
|
| +----+
| | CN |
| +----+
+-----+ |
| |
| +---+
| |
+-------+
| MAP | RCoA
+-------+
| |
| +--------+
| |
| |
+-----+ +-----+
PLCoA | PAR | | NAR | NLCoA
+-----+ +-----+
+----+
| MN |
+----+ ------------>
Movement
Figure 1: Fast Handover in HMIPv6 networks
A natural choice for fast handover in HMIPv6 networks may be to apply
the existing FMIPv6 scheme over the HMIPv6 networks. In this case, a
bi-directional tunnel will be established between PAR and NAR by the
FMIPv6 procedures.
However, it is noted that such simple integration of FMIPv6 with
HMIPv6 may possibly induce additional processing overhead for re-
tunneling at PAR and also inefficient usage of network bandwidth.
Jung, Koh, Lee, Soliman, El-Malki [Page 4]
INTERNET DRAFT Fast Handover for HMIPv6 June 2003
Figure 2 shows the data flow by the simple integration of FMIPv6 with
HMIPv6. According to the HMIPv6 operations, the data packets sent by
CN will arrive at MAP and then be tunneled to MN over PLCoA.
CN PAR(MN) MAP NAR
| | | |
| MIPv6 | |
|---------------------->| |
| | | |
| | HMIPv6 | |
| |<----------| |
| | | |
| | FMIPv6 |
| |---------------------->|
| | | |
Figure 2: Data flows by simple integration of FMIPv6 with HMIPv6
When the handover is initiated, a bi-directional tunnel will be
established between PAR and NAR according to the FMIPv6 procedures.
To forward the data packets to the NAR by using the tunnel, the PAR
must first intercept those data packets flowing from the MAP, and
then perform the re-tunneling process. This may be done by adding a
new outer IP header of <Source = PAR, Destination = NAR> to the data
packets sent by MAP according to the HMIPv6 operations.
In the viewpoint of the HMIPv6 operations, the above approach has the
following disadvantages:
(1) The PAR must perform the tunneling operations for fast handover,
in addition to the HMIPv6 tunneling from MAP to MN. To do this,
the PAR must first intercept the data packets flowing from the
MAP, which will be an additional overhead for HMIPv6. It is noted
that the data delivery in HMIPv6 is performed based on MAP.
(2) In HMIPv6, the actual data path of the bi-directional tunnel
between PAR and NAR may include the MAP (i.e., PAR-MAP-NAR).
Accordingly, the data packets will flow twice along the path
between PAR and MAP. This induces inefficiency of network
bandwidth usage, especially when ARs are connected to the network
through bandwidth-limited links.
(3) From such detouring feature, the overall handover latency may
possibly increase during the handover period.
Jung, Koh, Lee, Soliman, El-Malki [Page 5]
INTERNET DRAFT Fast Handover for HMIPv6 June 2003
From the observations described above, it is clear that the fast
handover for HMIPv6 needs to be designed by considering the data
transport features of the HMIPv6 (i.e., in HMIPv6, all data packets
are intercepted by MAP and delivered over the tunnel between MAP and
MNs).
This document describes the scheme of Fast Handover for HMIPv6 (F-
HMIPv6), in which the MAP performs the tunneling for fast handover
instead of the PAR. By the F-HMIPv6 scheme, the data packets sent by
CN will be tunneled by the MAP toward the NAR during the handover.
Figure 3 illustrates the data flows by the F-HMIPv6.
CN PAR(MN) MAP NAR
| | | |
| MIPv6 | | |
|---------------------->| |
| | | |
| | HMIPv6 | |
| |<----------| |
| | | |
| | | F-HMIPv6 |
| | |---------->|
| | | |
Figure 3: Data flows by F-HMIPv6
Before handover, according to the HMIPv6 operations, the data packets
sent by CN are tunneled by MAP to MN with the following IP fields:
o Inner IP header: <Source = CN, Destination = RCoA of MN>
o Outer IP header: <Source = MAP, Destination = PLCoA of MN>
When the F-HMIPv6 handover is triggered (e.g., by receiving the FBU
message from the MN), the MAP will establish a bi-directional tunnel
with the NAR, and then begin to forward the data packets to the NAR
over the tunnel. By the tunnel, each data packet has an additional
outer IP header to the normal HMIPv6 headers with the following IP
fields:
o Additional outer IP header: <S = MAP, Destination = NAR>
When receiving the tunneled data packets from the MAP, the NAR will
de-capsulate them and then be caching the de-capsulated data packets.
When the MN moves into the NAR region, the NAR will deliver the
cached data packets to the MN, as done in FMIPv6.
Jung, Koh, Lee, Soliman, El-Malki [Page 6]
INTERNET DRAFT Fast Handover for HMIPv6 June 2003
4. Generic Operations for F-HMIPv6
Figure 4 illustrates the generic procedures for F-HMIPv6 operations.
The control messages for F-HMIPv6 are identical to those for FMIPv6,
except for the source/destination addresses of IP fields. The
Correspondent Node (CN) and Home Agent (HA) operations will not be
affected.
MN(at PAR) PAR MAP NAR MN(at NAR)
| | | | |
| HMIPv6 Data (before HO) | | |
|<===========================>| | |
| | | | |
| RtSolPr | | | |
|------------->| | | |
| PrRtAdv | | | |
|<-------------| | | |
| FBU | | HI | |
|---------------------------->|------------->| |
| | | HACK | |
| | |<-------------| |
Disconnect | FBACK | FBACK | |
| <--------------------------|-------------------------> |
| | |Packet Forward| |
| | |=============>| |
Connect | | | RS and RA |
| | | |<----------->|
| | | Packet Delivery|
| | | |============>|
| | | | |
| | | Local BU and BA |
| | |<-------------------------->|
| | | | |
| | | HMIPv6 Data (after HO) |
| | |<==========================>|
| | | | |
Figure 4: F-HMIPv6 Control Flows
Basically, the F-HMIPv6 procedures are based on the assumption that
each AR has already the necessary information of its neighboring ARs
such as the link-layer address and network prefix of the concerned AR.
In addition, the control flows of Figure 4 are derived under the
following conditions:
Jung, Koh, Lee, Soliman, El-Malki [Page 7]
INTERNET DRAFT Fast Handover for HMIPv6 June 2003
a) The handover is initiated by MN (mobile-initiated HO).
b) The MN can anticipate the handover (anticipated HO).
c) The tunnel for HO is established between MAP and NAR.
d) DAD optimization (like optimistic DAD) is not supported.
A more detailed description for each control flow of F-HMIPv6 is
given below:
1) Based on L2 handover anticipation, the MN sends RtSolPr message
to PAR. The RtSolPr SHOULD include information about the link
layer addresses of the MN and the NAR concerned.
2) In response to the RtSolPr message, the MAP sends the PrRtAdv
message to the MN, which SHOULD contain information about the
NLCoA for the MN to use in the NAR region.
It is assumed that the NAR already knows the network prefix and
link layer address of all the neighboring NARs.
The NLCoA can be auto-configured using the network prefix of
NAR and the link layer address of MN by PAR. In a certain case,
the NLCoA may be allocated by a stateful address management
scheme.
3) The MN sends Fast Binding Update (FBU) message to MAP. The FBU
message contains PLCoA and IP address of the NAR.
4) After receiving the FBU message from MN, the MAP will send a
Handover Initiate (HI) message to the NAR so as to establish a
bi-directional tunnel.
5) In response to the HI message, the NAR will set up a host route
entry for the MN's PLCoA and then respond with a Handover
Acknowledge (HACK) message.
As a result, a bi-directional tunnel between MAP and NAR will
be established. Over the tunnel, the data packets sent by MAP
have the additional outer IP header with the following IP
fields of <Source = MAP, Destination = NAR>. The NAR may cache
those data packets flowing from the MAP, until it receives the
RS (with FNA option) message from the newly incoming MN.
6) The MAP sends Fast Binding ACK (FBACK) messages toward the MN
over PLCoA and NLCoA.
Jung, Koh, Lee, Soliman, El-Malki [Page 8]
INTERNET DRAFT Fast Handover for HMIPv6 June 2003
Then, the MAP will begin to forward the data packets destined
to MN to the NAR by using the established tunnel.
7) The MN exchanges the RS and RA messages with NAR, when it
detects that it is moved in the link layer, and receives the
responding RA from the NAR.
Then the NAR delivers the buffered data packets to the MN over
NLCoA.
8) The MN then follows the normal HMIPv6 operations by sending a
Local BU to MAP, as done in HMIPv6.
The MAP will clear the tunnel for fast handover, when it
receives the new Local Binding Update with NLCoA from the MN.
5. Variants of F-HMIPv6
5.1 Network-initiated Handover
The generic procedures described in Figure 4 correspond to the case
of the mobile-initiated handover. In the network-initiated HO case,
the RtSolPr will be omitted. In this case, after detecting that the
MN is moving toward the NAR, the PAR will send an unsolicited RA
message to the MN, which MUST include the NLCoA for the MN to use in
the NAR region.
5.2 No Anticipation
When the handover anticipation cannot be supported, the F-HMIPv6 will
follow the normal HMIPv6 operation. The MN just sends the Local BU to
the MAP. In fact, the fast handover cannot be supported.
6. Messages for F-HMIPv6
The F-HMIPv6 is designed to exploit all the messages defined in
FMIPv6 and HMIPv6 with the following exceptions:
- A new flag is defined in the HMIPv6 MAP option, so as to indicate
whether the MAP supports the F-HMIPv6 or not within the HMIPv6
domain.
- Some of the FMIPv6 messages have different IP source and
destination addresses in the respective IP fields. In particular,
the MAP address is used instead of the PAR address.
Jung, Koh, Lee, Soliman, El-Malki [Page 9]
INTERNET DRAFT Fast Handover for HMIPv6 June 2003
The different usage and format of those control messages will be
identified and specified, as the FMIPv6 and HMIPv6 mechanisms are
changed.
6.1 A New Flag in the HMIPv6 MAP Option
When a MN moves into a new MAP domain, it receives the Router
Advertisement with a MAP option from an access router. When the F bit
set in the MAP option indicates that the mobile node MAY use F-HMIPv6.
If the MN is not aware of F-HMIPv6, or the F bit is not set, it
SHOULD NOT use F-HMIPv6.
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 | Dist | Pref |R|I|P|V|F| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Global IP Address for MAP +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: A new flag in the MAP option
Fields:
F When set indicates that the MAP support
Fast Handover.
6.2 Use of FMIPv6 messages
F-HMIPv6 uses the messages for fast handover defined in FMIPv6, with
different source and destination IP addresses. Table 1 summarizes the
use of these messages.
Jung, Koh, Lee, Soliman, El-Malki [Page 10]
INTERNET DRAFT Fast Handover for HMIPv6 June 2003
Table 1. Use of FMIPv6 Messages in F-HMIPv6
+--------------+-----------+-------------+---------------------+
| F-HMIPv6 | Source IP | Destination | Usage in FMIPv6 |
| Messages | address | IP address | |
+--------------+-----------+-------------+---------------------+
| RtSolPr | MN | PAR | Identical |
+--------------+-----------+-------------+---------------------+
| PrRtAdv | PAR | MN | Identical |
+--------------+-----------+-------------+---------------------+
| FBU | MN | MAP | Destination = PAR |
+--------------+-----------+-------------+---------------------+
| FBACK | MAP | MN | Source = PAR |
| | |(via PAR/NAR)| |
+--------------+-----------+-------------+---------------------+
| HI | MAP | NAR | Source = PAR |
+--------------+-----------+-------------+---------------------+
| HACK | NAR | MAP | Destination = PAR |
+--------------+-----------+-------------+---------------------+
7. Enhancement of F-HMIPv6 Operations
In this section, we describe the enhance scenarios for F-HMIPv6, with
the help of additional techniques such as a stateful LCoA management
scheme and/or a bicasting of MAP by simultaneous binding.
7.1 F-HMIPv6 with Tunnel Extension to MN
In F-HMIPv6, the bi-directional tunnel from MAP to NAR could be
replaced with the tunnel between MAP and MN, as done in the normal
HMIPv6.
For this purpose, the HI/HACK messages need to be eliminated in the
F-HMIPv6 with the help of an appropriate DAD optimization or LCoA
configuration scheme to ensure that the NLCoA confirmation (via the
DAD process) is not needed in the NAR.
Such the configuration schemes MAY be implemented by using the
Optimistic DAD [6], Advance DAD [7]. In addition to these schemes,
the other LCoA configuration and allocation schemes (e.g., enhanced
DHCPv6) MAY be used, where the pre-configured globally unique LCoAs
will be managed between PAR and NARs via the DHCPv6 server.
Jung, Koh, Lee, Soliman, El-Malki [Page 11]
INTERNET DRAFT Fast Handover for HMIPv6 June 2003
If the tunnel extension to MN is used along with an appropriated LCoA
management scheme, the HI/HACK messages and the bi-directional tunnel
between MAP and NAR could be eliminated.
Furthermore, the Local BU (LBU) message of HMIPv6 will also be able
to replace the FBU message. That is, the MN does not need to send the
FBU message to MAP. Instead, the MN sends the LBU to the MAP directly.
As a result, Figure 4 could be changed as Figure 6
MN(at PAR) PAR MAP NAR MN(at NAR)
| | | | |
| HMIPv6 Data (before HO) | | |
|<===========================>| | |
| | | | |
| RtSolPr | | | |
|------------->| | | |
| PrRtAdv | | | |
|<-------------| | | |
| LBU | | |
|---------------------------->| | |
Disconnect | LBA | LBA | |
| <--------------------------|-------------------------> |
Connect | | HMIPv6 Data (after HO) |
| | |<==========================>|
| | | | |
Figure 6: F-HMIPv6 with Tunnel to MN
As shown in the figure, as soon as the MAP receives the FBU from the
MN, it begins to communicate with MN over NLCoA.
7.2 F-HMIPv6 with Bicasting
It is noted that the bicasting along with simultaneous binding [8]
can be used to enhance the handover performance, in particular, for
addressing the ping-pong effect. In F-HMIPv6, it is strongly
recommended that the bicasting be used for stable handover, when
anticipation is used.
In addition to the scenario described in the preceding section, the
bicasting is applied along with simultaneous binding in F-HMIPv6, as
shown in Figure 7. Note in this case that the LBU/LBACK messages are
used to indicate when the MAP stops the bicasting.
Jung, Koh, Lee, Soliman, El-Malki [Page 12]
INTERNET DRAFT Fast Handover for HMIPv6 June 2003
MN(at PAR) PAR MAP NAR MN(at NAR)
| | | | |
| HMIPv6 Data (before HO) | | |
|<===========================>| | |
| | | | |
| RtSolPr | | | |
|------------->| | | |
| PrRtAdv | | | |
|<-------------| | | |
| FBU | | |
|---------------------------->| | |
Disconnect | FBACK | FBACK | |
| <--------------------------|-------------------------> |
| | Bicasting | |
|<============================|===========================>|
Connect | | | |
| | | LBU and LBA |
| | |<-------------------------->|
| | | HMIPv6 Data (after HO) |
| | |<==========================>|
| | | | |
Figure 7: F-HMIPv6 with Bicasting
In F-HMIPv6, if the bicasting is enabled, when the packet forwarding
to the NAR is indicated, the MAP will also continue to send the data
packets to the MN (over PLCoA). That is, after transmitting the FBACK
messages, the MAP will send the data packets destined to MN toward
the NAR over the established tunnel as well as the MN over the PLCoA.
The packet forwarding to the MN over PLCoA will stop, when the MAP
receives a new Local Binding Update (by HMIPv6) from the MN that has
moved into the NAR.
8. Security Considerations
The security issues on F-HMIPv6 are basically the same with those on
FMIPv6 and HMIPv6.
Noting that the MN and the MAP could have an IPsec SA in the HMIPv6,
the PrRtSol and PrRtAdv messages can be protected with IPsec. This
feature actually provides an advantage over FMIPv6 where ND messages
cannot be secured in its present form.
Jung, Koh, Lee, Soliman, El-Malki [Page 13]
INTERNET DRAFT Fast Handover for HMIPv6 June 2003
In addition, the MAP MUST ensure that the RtSolPr and FBU packets
arrived from an MN that legitimately owns the RCoA. Otherwise, a
bogus node could attempt to disrupt packets meant for the MN and
redirect them to some access router.
Further Security issues will be identified, as the F-HMIPv6 work is
progressing.
9. Acknowledgement
The Authors would like to give special thanks to the following people
for their valuable contributions:
Sung Han Kim (sh-kim@etri.re.kr), ETRI
Jae Hong Min (jhmin@etri.re.kr), ETRI
10. References
[1] S. Bradner, "The Internet Standards Process -- Revision 3", BCP,
RFC 2026, October 1996.
[2] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP, RFC 2119, March 1997.
[3] D. Johnson, et al., "Mobility Support in IPv6", draft-ietf-
mobileip-ipv6-21, February 2003.
[4] H. Soliman, et al., "Hierarchical Mobile IPv6 mobility management
(HMIPv6)", draft-ietf-mobileip-hmipv6-07, October 2002.
[5] R. Koodli, et al., "Fast Handovers for Mobile IPv6", draft-ietf-
mobileip-fast-mipv6-06, March 2003.
[6] N. Moore, "Optimistic Duplicate Address Detection", draft-moore-
ipv6-optimistic-dad-02, February 2003.
[7] Y. Han, J. Choi, and S. Park, "Advance Duplicate Address
Detection", draft-han-mobileip-adad-00, May 2003.
[8] K. ElMalki and H. Soliman, "Simultaneous Bindings for Mobile IPv6
Fast Handoffs", draft-elmalki-mobileip-bicasting-v6-02, Work in
progress.
Jung, Koh, Lee, Soliman, El-Malki [Page 14]
NTERNET DRAFT Fast Handover for HMIPv6 June 2003
Author's Addresses
Hee Young Jung
hyjung@etri.re.kr
Protocol Engineering Center, ETRI
Seok Joo Koh
sjkoh@etri.re.kr
Protocol Engineering Center, ETRI
Jun Seob Lee
juns@etri.re.kr
Protocol Engineering Center, ETRI
Hesham Soliman
H.Soliman@flarion.com
Flarion
Karim El Malki
Karim.El-Malki@era.ericsson.se
Ericsson Radio Systems AB
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 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."
ung, Koh, Lee, Soliman, El-Malki [Page 15]