Network Working Group H. Yokota
Internet-Draft KDDI Lab
Intended status: Standards Track K. Chowdhury
Expires: April 30, 2009 R. Koodli
Starent Networks
B. Patil
Nokia
F. Xia
Huawei USA
October 27, 2008
Fast Handovers for Proxy Mobile IPv6
draft-ietf-mipshop-pfmipv6-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on April 30, 2009.
Yokota, et al. Expires April 30, 2009 [Page 1]
Internet-Draft Proxy-based Fast Handover October 2008
Abstract
This document specifies the usage of Fast Mobile IPv6 (FMIPv6) when
Proxy Mobile IPv6 is used as the mobility management protocol.
Necessary extensions are specified for FMIPv6 to support the scenario
when the mobile node does not have IP mobility functionality and
hence is not involved with either MIPv6 or FMIPv6 operations.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Proxy-based FMIPv6 Protocol Overview . . . . . . . . . . . . . 7
4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 7
4.2. IPv4 Support Considerations . . . . . . . . . . . . . . . 13
5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 16
6.1.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . 16
6.1.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . 17
6.2. Mobility options . . . . . . . . . . . . . . . . . . . . . 19
6.2.1. Context Request Option . . . . . . . . . . . . . . . . 19
6.2.2. Local Mobility Anchor Address (LMAA) Option . . . . . 20
6.2.3. IPv4 Address Option . . . . . . . . . . . . . . . . . 21
6.2.4. Mobile Node Interface Identifier (MN IID) Option . . . 21
6.2.5. GRE Key Option . . . . . . . . . . . . . . . . . . . . 22
7. ICMPv6-based HI/HAck messages . . . . . . . . . . . . . . . . 23
7.1. ICMPv6-baqsed Handover Initiate . . . . . . . . . . . . . 23
7.2. ICMPv6-based Handover Acknowledge . . . . . . . . . . . . 24
7.3. Context Request Option . . . . . . . . . . . . . . . . . . 26
7.4. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 27
7.5. Mobile Node Interface Identifier (MN IID) Option . . . . . 28
7.6. New option-code for the IP Address Option . . . . . . . . 28
7.7. IPv4 Address Option . . . . . . . . . . . . . . . . . . . 28
7.8. Vendor Specific Option . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.1. Normative References . . . . . . . . . . . . . . . . . . . 33
10.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Handoff Type Considerations . . . . . . . . . . . . . 34
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37
Yokota, et al. Expires April 30, 2009 [Page 2]
Internet-Draft Proxy-based Fast Handover October 2008
1. Requirements notation
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 [RFC2119].
Yokota, et al. Expires April 30, 2009 [Page 3]
Internet-Draft Proxy-based Fast Handover October 2008
2. Introduction
Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node
that does not possess Mobile IPv6 [RFC3775] functionality. A proxy
agent in the network performs the mobility management signaling on
behalf of the mobile node. This model transparently provides
mobility for Mobile Nodes within a PMIPv6 domain. Nevertheless, the
basic performance of PMIPv6 in terms of handover latency and packet
loss is considered not any different from that of Mobile IPv6.
Fast Handovers for Mobile IPv6 is specified in [RFC5268]. This
document applies the same Fast Handovers protocol for Proxy Mobile
IPv6 (PFMIPv6), in order to provide handover delay, packet loss and
transfer of network-resident contexts. This document also specifies
necessary extensions to FMIPv6 for operation in a PMIPv6 domain.
Yokota, et al. Expires April 30, 2009 [Page 4]
Internet-Draft Proxy-based Fast Handover October 2008
3. Terminology
This document refers to [RFC5213][RFC5268][RFC3775] for terminology.
The following terms and abbreviations are additionally used in this
document. The reference network is illustrated in Figure 1.
Previous Access Network (P-AN):
The access network to which the MN is attached before handover.
New Access Network (N-AN):
The access network to which the MN is attached after handover.
Previous Mobile Access Gateway (PMAG):
The MAG that manages mobility related signaling for the MN
before handover. In this document, the MAG and the Access
Router (AR) are collocated.
New Mobile Access Gateway (NMAG):
The MAG that manages mobility related signaling for the MN after
handover. In this document, the MAG and the Access Router (AR)
are collocated.
HO-Initiate:
A generic signaling that indicates the handover of the MN sent
from the P-AN to the PMAG. While this signaling is dependent on
the access technology, it is assumed that HO-Initiate can carry
the information to identify the MN and to assist the PAR resolve
the NAR (e.g., the new access point or base station to which the
MN is moving).
Yokota, et al. Expires April 30, 2009 [Page 5]
Internet-Draft Proxy-based Fast Handover October 2008
+----------+
| LMA |
| |
+----------+
/ \
/ \
/ \
+........../..+ +..\..........+
. +-------+-+ .______. +-+-------+ .
. | PAR |()_______)| NAR | .
. | (PMAG) | . . | (NMAG) | .
. +----+----+ . . +----+----+ .
. | . . | .
. ___|___ . . ___|___ .
. / \ . . / \ .
. ( P-AN ) . . ( N-AN ) .
. \_______/ . . \_______/ .
. | . . | .
. +----+ . . +----+ .
. | MN | ----------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
Figure 1: Reference network for fast handover
Yokota, et al. Expires April 30, 2009 [Page 6]
Internet-Draft Proxy-based Fast Handover October 2008
4. Proxy-based FMIPv6 Protocol Overview
In order to improve the performance during handover (when operations
such as attachment to a new network and signaling between mobility
agents are involved), the PFMIPv6 protocol in this document specifies
a bi-directional tunnel between the Previous MAG (PMAG) and the New
MAG (NMAG). In order to enable the NMAG to send the Proxy Binding
Update (PBU), the Handover Initiate (HI) and Handover Acknowledge
(HAck) messages in [RFC5268] are used for context transfer, in which
parameters such as MN's NAI, Home Network Prefix (HNP), IPv4 Home
Address, are transferred from the PMAG.
In this document, the Previous Access Router (PAR) and New Access
Router (NAR) are interchangeable with the PMAG and NMAG,
respectively.
Since a MN is not directly involved with IP mobility protocol
operations, it follows that the MN is not directly involved with fast
handover procedures either. Hence, the messages involving the MN in
[RFC5268] are not used when PMIPv6 is in use. Such messages are the
Router Solicitation for Proxy Advertisement (RtSolPr), Proxy Router
Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast Binding
Acknowledgment (FBack) and Unsolicited Neighbor Advertisement (UNA).
4.1. Protocol Operation
There are two modes of operation in FMIPv6 [RFC5268]. In the
predictive mode of fast handover, a bi-directional tunnel between the
PAR and NAR is established prior to the MN's attachment to the NAR.
In the reactive mode, this tunnel establishment takes place after the
MN attaches to the NAR. Since the MN is not involved in IP mobility
signaling in PMIPv6, the sequence of events illustrating the
predictive fast handover are shown in Figure 2.
Yokota, et al. Expires April 30, 2009 [Page 7]
Internet-Draft Proxy-based Fast Handover October 2008
PMAG NMAG
MN P-AN N-AN (PAR) (NAR) LMA
| | | | | |
| Report | | | | |
(a) |-(MN ID,-->| | | | |
| New AP ID)| | | | |
| | HO Initiate | | |
(b) | |--(MN ID, New AP ID)-->| | |
| | | | | |
| | | | HI | |
(c) | | | |-(MN ID, ->| |
| | | MN-HoA,MN IID,LMA) |
| | | | | |
(d) | | | |<---HAck---| |
| | | | (MN ID) | |
| | | | | |
| | | | HI/HAck | |
(e) | | | |<--------->| |
(f) | | | |==DL data=>| |
| | | | | |
(g) ~~~ | | | | |
~~~ | | | | |
| MN-AN connection | AN-MAG connection | |
(h) |<---establishment---->|<----establishment----->| |
| | | (substitute for UNA) | |
| | | | | |
(i) |<==================DL data=====================| |
| | | | | |
(j) |===================UL data====================>|# |
| | | #|<==========|# |
| | | #|===================>|
| | | |HI/HAck(optional) |
(k) | | | |<- - - - ->| |
/ | | | | | | \
|(l) | | | | |--PBU-->| |
| | | | | | | |
|(m) | | | | |<--PBA--| |
\ | | | | | | /
Figure 2: Predictive fast handover for PMIPv6 (PAR initiated)
The detailed descriptions are as follows:
(a) The MN detects that a handover is imminent and reports the
identifications of itself (MN ID) and the access point (New AP
ID) to which the MN is most likely to move. The MN ID could be
the NAI or a Link Layer Address (LLA), or any other suitable
identifier. This step is access technology specific. In some
Yokota, et al. Expires April 30, 2009 [Page 8]
Internet-Draft Proxy-based Fast Handover October 2008
cases, the P-AN will determine which AP ID the MN is moving to.
(b) The previous access network (P-AN), to which the MN is currently
attached, indicates the handover of the MN to the PAR (PMAG).
(c) The PAR sends the HI to the NAR. The HI message MUST include
the MN ID and SHOULD include the MN-HoA, the MN-HNP, the MN-IID
and the address of the LMA that is currently serving the MN.
(d) The NAR sends the HAck back to the PAR.
(e) The NAR requests the PAR to buffer or forward packets by setting
U or F flags in the HI message, respectively.
(f) If the F flag is set in the previous step, a bi-directional
tunnel is established between the PAR and NAR and packets
destined for the MN are forwarded from the PAR to the NAR over
this tunnel. After decapsulation, those packets may be buffered
at the NAR. If the connection between the N-AN and NAR has
already been established, those packet may be forwarded towards
the N-AN; this is access technology specific.
(g) The MN undergoes handover to the New Access Network (N-AN).
(h) The MN establishes a connection (e.g., radio channel) with the
N-AN, which in turn triggers the establishment of the connection
between the N-AN and NAR if it has not been established already
(access technology specific). This can be regarded as a
substitute for the UNA.
(i) The NAR starts to forward packets destined for the MN via the
N-AN.
(j) The uplink packets from the MN are sent to the NAR via the N-AN
and the NAR forwards them to the PAR. The PAR then sends the
packets to the LMA that is currently serving the MN.
(k) The PAR MAY send the HI message to indicate that the packet
forwarding is completed.
(l) The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA,
whose address is provided in (c). Steps (l) and (m) are not
part of the fast handover procedure, but shown for reference.
(m) The LMA sends back the Proxy Binding Acknowledgment (PBA) to the
NAR (NMAG). From this time on, the packets to/from the MN go
through the NAR instead of the PAR.
Yokota, et al. Expires April 30, 2009 [Page 9]
Internet-Draft Proxy-based Fast Handover October 2008
According to Section 4 of [RFC5268], the PAR establishes a binding
between the PCoA and NCoA to forward packets for the MN to the NAR,
and the NAR creates a proxy NCE to receive those packets for the NCoA
before the MN arrives. In the case of PMIPv6, however, the only
address that is used by the MN is MN-HoA. Hence the PAR forwards
MN's packets to the NAR instead of the NCoA. FMIPv4 [RFC4988]
specifies forwarding when the MN uses HoA as its on-link address
rather than the care-of address. The usage in PMIPv6 is similar to
that in FMIPv4, where the address is used by the MN is based on Home
Network Prefix. Hence the PAR forwards MN's packets to the NAR
instead of the NCoA. The NAR then simply decapsulates those packets
and delivers them to the MN. Since the NAR obtains the LLA (MN IID)
and MN-HoA by the HI, it can create the NCE for the MN and deliver
packets to it even before the MN can perform Neighbor Discovery. For
the uplink packets from the MN after handover in (j), the NAR
forwards the packets to the PAR through the tunnel established in
step (f). The PAR then decapsulates and sends them to the LMA.
The timing of the context transfer and that of packet forwarding may
be different. Thus, a new flag 'F' and the Option Code values for it
in the HI message are defined to request forwarding. To request
buffering, 'U' flag has already been defined in [RFC5268]. If the
PAR receives the HI message with F flag set and the Option Code value
being 2, it starts forwarding packets for the MN. The HI message
with U flag set may be sent earlier if the timing of buffering is
different from that of forwarding. If packet forwarding is
completed, the PAR MAY send the HI message with F flag set and the
Option Code value being 3. By this message, the ARs on both ends can
tear down the forwarding tunnel synchronously.
The IP addresses in the headers of those user packets are summarized
below:
In (f),
Inner source address: IP address of the CN
Inner destination address: HNP or IPv4-HoA
Outer source address: IP address of the PAR (PMAG)
Outer destination address: IP address of the NAR (NMAG)
In (i),
Yokota, et al. Expires April 30, 2009 [Page 10]
Internet-Draft Proxy-based Fast Handover October 2008
Source address: IP address of the CN
Destination address: HNP or IPv4-HoA
In (j),
- from the MN to the NMAG,
Source address: HNP or IPv4-HoA
Destination address: IP address of the CN
- from the NMAG to the PMAG,
Inner source address: HNP or IPv4-HoA
Inner destination address: IP address of the CN
Outer source address: IP address of the NAR (NMAG)
Outer destination address: IP address of the PAR (PMAG)
- from the PMAG to the LMA,
Inner source address: HNP or IPv4-HoA
Inner destination address: IP address of the CN
Outer source address: IP address of the PAR (PMAG)
Outer destination address: IP address of the LMA
If the network that the MN has moved to does not support PMIPv6 but
only MIPv6 (i.e. there exists a MIPv6 HA) and the MN supports MIPv6
at the same time, the MN and HA can exchange BU/BA instead of PBU/PBA
in steps (j) and (k). If this is the case, the LMA and HA will most
likely be collocated and the LMA (HA) address should be maintained in
the new network for communication continuity. Since the LMA (HA)
address is transferred to the NAR in step (c), the MN can retrieve it
at or after step (g) by e.g. the authentication or DHCP procedure
(not shown in the figure).
In the case of the reactive handover for PMIPv6, since the MN does
not send either the FBU or UNA, it would be more natural that the NAR
sends the HI to the PAR after the MN has moved to the new network.
Figure 3 illustrates the reactive fast handover procedures for
PMIPv6, where the bi-directional tunnel establishment is initiated by
the NAR.
Yokota, et al. Expires April 30, 2009 [Page 11]
Internet-Draft Proxy-based Fast Handover October 2008
PMAG NMAG
MN P-AN N-AN (PAR) (NAR) LMA
| | | | | |
(a) ~~~ | | | | |
~~~ | | | | |
| MN-AN connection | AN-MAG connection | |
(b) |<--establishment-->|<-------establishment------>| |
| (MN ID) | (MN ID) | |
| | |(substitute for UNA and FBU)| |
| | | | | |
| | | | HI | |
(c) | | | |<---(MN ID) ---| |
| | | | | |
| | | | HAck | |
(d) | | | |---(MN ID, --->| |
| | | MN-HoA,MN IID,LMA) |
| | | | | |
(e) | | | |===DL data====>|# |
|<====================DL data====================|# |
| | | | | |
(f) |=====================UL data===================>|# |
| | | #=|<==============|# |
| | | #=|=======================>|
(g) | | | |<---HI/HAck--->| |
| | | | | |
/ | | | | | | \
|(h) | | | | |--PBU-->| |
| | | | | | | |
|(i) | | | | |<--PBA--| |
\ | | | | | | /
Figure 3: Reactive fast handover for PMIPv6 (NAR initiated)
The detailed descriptions are as follows:
(a) The MN undergoes handover from the P-AN to the N-AN.
(b) The MN establishes a connection (e.g., radio channel) with the
N-AN, which triggers the establishment of the connection between
the N-AN and NAR. The MN ID is transferred to the NAR for the
subsequent procedures. This can be regarded as a substitute for
the UNA and FBU.
Yokota, et al. Expires April 30, 2009 [Page 12]
Internet-Draft Proxy-based Fast Handover October 2008
(c) The NAR sends the HI to the PAR. The HI message MUST include
the MN ID. The Context Request Option MAY be included to
request additional context information on the MN to the PAR.
(d) The PAR sends the HAck back to the NAR. The HAck message MUST
include the HNP and/or IPv4-HoA that is corresponding to the MN
ID in the HI message and SHOULD include the MN-IID and the LMA
address that is currently serving the MN. The context
information requested by the NAR MUST be included.
(e) If F flag in the HI is set, a bi-directional tunnel is
established between the PAR and NAR and packets destined for the
MN are forwarded from the PAR to the NAR over this tunnel.
After decapsulation, those packets are delivered to the MN via
the N-AN.
(f) The uplink packets from the MN are sent to the NAR via the N-AN
and the NAR forwards them to the PAR. The PAR then sends the
packets to the LMA that is currently serving the MN.
(g) The PAR MAY send the HI message to indicate that the packet
forwarding is completed.
Steps (h)-(i) are the same as (l)-(m) in the predictive fast handover
procedures.
In step (c), The IP address of the PAR needs to be resolved by the
NAR to send the HI to the PAR. This information may come from the
N-AN or some database that the NAR can access.
Also, in step (c), the NAR could send an unsolicited HAck message to
the PAR, which then triggers the HI message from the PAR. By doing
so, the directions of HI/HAck messages are aligned with the
predictive (PAR-initiated) fast handover. Further study is needed if
this call flow is more appropriate than the current one.
4.2. IPv4 Support Considerations
The motivation and usage scenarios of IPv4 protocol support by PMIPv6
are described in [IPv4PMIPv6]. The scope of IPv4 support covers the
following two features:
o IPv4 Home Address Mobility Support, and
o IPv4 Transport Support.
As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home
Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to
Yokota, et al. Expires April 30, 2009 [Page 13]
Internet-Draft Proxy-based Fast Handover October 2008
transfer IPv4-MH-HoA to the NMAG, which is the inner destination
address of the packets forwarded on the downlink. In order to
support IPv4-MN-HoA, a new option called IPv4 Address Option is
defined in this document. In order to provide IPv4 Transport
Support, the NMAG needs to know the IPv4 address of the LMA (IPv4-
LMAA) to send PMIPv6 signaling messages to the LMA in the IPv4
transport network. The above IPv4 Address Option is defined so as to
be able to convey IPv4-LMAA. The details of this option are
described in [IPv4PMIPv6].
Yokota, et al. Expires April 30, 2009 [Page 14]
Internet-Draft Proxy-based Fast Handover October 2008
5. Other Considerations
The protocol specified in this document enables the NMAG to obtain
parameters which would otherwise be available only by communicating
with the LMA. For instance, the HNP and/or IPv4-HoA of a MN are made
available to the NMAG through context transfer. This allows the NMAG
to perform some procedures which may be beneficial. For instance,
the NMAG could send a Router Advertisement (RA) with the HNP option
to the MN as soon as it's link attachment is detected (e.g., via
receipt of a Router Solicitation message). Such an RA is
recommended, for example, in scenarios where the MN uses a new radio
interface while attaching to the NMAG; since the MN does not have
information regarding the new interface, it will not be able to
immediately send packets without first receiving an RA with HNP.
However, if the subsequent PMIPv6 binding registration for the HNP
fails for some reason, then the NMAG MUST withdraw the advertised HNP
by sending another RA with zero prefix lifetime for the HNP in
question. This operation is the same as that described in Section
6.12 of [RFC5213].
The protocol specified in this document is applicable regardless of
whether link-layer addresses are used between a MN and its access
router. A MN should be able to continue sending packets on the
uplink even when it changes link. When link-layer addresses are
used, the MN performs Neighbor Unreachability Detection (NUD)
[RFC4861], after attaching to a new link, probing the reachability of
its default router. If the new router's interface is configured to
respond to queries sent to link-layer addresses than it's own (e.g.,
set to promiscuous mode), then it can respond to the NUD probe,
providing its link-layer address in the solicited Neighbor
Advertisement. While the MN is performing NUD, it can continue to
send uplink packets.
Yokota, et al. Expires April 30, 2009 [Page 15]
Internet-Draft Proxy-based Fast Handover October 2008
6. Message Formats
This document defines new Mobility Header messages for the extended
HI and Hack and new mobility options for conveying context
information.
Editor's note: this document also defines ICMPv6-based HI/Hack in
Section 7. Whether either one or both of the types is/are
specified will be resolved in later versions.
6.1. Mobility Header
6.1.1. Handover Initiate (HI)
The MH Type value of the HI Mobility Header is TBD1. The format of
the Message Data field in the Mobility Header is as follows:
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
+---------------+-+-+-----------+
| Code |U|F| Reserved |
+-------------------------------+---------------+-+-+-----------+
| Reserved | Identifier |
+-------------------------------+-------------------------------+
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
IP Fields:
Source Address
The IP address of PMAG or NMAG
Destination Address
The IP address of the peer MAG
Message Data:
Code If F flag is not set, the Code MUST be set to zero.
Otherwise, the Code value has the following meaning:
Yokota, et al. Expires April 30, 2009 [Page 16]
Internet-Draft Proxy-based Fast Handover October 2008
0: Reserved
1: Forwarding is not requested
2: Request forwarding
3: Indicate the completion of forwarding
U flag Buffer flag. Same as [RFC5268].
F flag Forwarding flag. Used to request to forward the packets
for the MN.
Reserved These fields are unused. They MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Identifier Same as [RFC5268].
Mobility options:
This field contains one or more mobility options, whose encoding and
formats are defined in [RFC3775]. At least one mobility option MUST
uniquely identify the target MN (e.g., the Mobile Node Identifier
Option defined in RFC4283) and the transferred context MUST be for
one MN per message. In addition, the NAR can request necessary
mobility options by the Context Request Option defined in this
document.
Context Request Option
This option is used to request context information typically
by the NAR to the PAR in the NAR-initiated fast handover.
6.1.2. Handover Acknowledge (HAck)
The MH Type value of the HAck Mobility Header is TBD2. The format of
the Message Data field in the Mobility Header is as follows:
Yokota, et al. Expires April 30, 2009 [Page 17]
Internet-Draft Proxy-based Fast Handover October 2008
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
+---------------+---------------+
| Code | Reserved |
+-------------------------------+---------------+---------------+
| Reserved | Identifier |
+-------------------------------+-------------------------------+
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
IP Fields:
Source Address
Copied from the destination address of the
Handover Initiate message to which this message
is a response.
Destination Address
Copied from the source address of the Handover
Initiate message to which this message is a
response.
Message Data:
Code:
0: Handover Accepted
5: Context Transferred successfully, more context
available
6: Context Transferred successfully, no more
context available
128: Handover Not Accepted
129: Administratively prohibited
130: Insufficient resources
Yokota, et al. Expires April 30, 2009 [Page 18]
Internet-Draft Proxy-based Fast Handover October 2008
131: Requested Context Not Available
132: Forwarding Not Available
Reserved These fields are unused. They MUST be initialized to
zero by the sender and MUST be ignored by the receiver.
Identifier Copied from the corresponding field in the Handover
Initiate message to which this message is a response.
Mobility options:
This field contains one or more mobility options, whose encoding and
formats are defined in [RFC3775]. The mobility option that uniquely
identifies the target MN MUST be copied from the corresponding HI
message and the transferred context MUST be for one MN per message.
Requested option(s) All the context information requested by the
Context Request Option in the HI message MUST be present in
the HAck message. Otherwise, the Code value MUST be set to
131.
6.2. Mobility options
6.2.1. Context Request Option
This option is sent in the HI message to request context information
on the MN.
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
+---------------+---------------+---------------+---------------+
| Option-Type | Option-Length | Reserved |
+---------------+---------------+-------------------------------+
| Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 |
+---------------------------------------------------------------+
| ... |
Context Request Option is typically used for the reactive (NAR-
initiated) fast handover mode to retrieve the context information
from the PAR. When this option is included in the HI message, the
requested option(s) MUST be included in the HAck message.
Option-Type TBD3
Yokota, et al. Expires April 30, 2009 [Page 19]
Internet-Draft Proxy-based Fast Handover October 2008
Option-Length The length in octets of this option, not including the
Option Type and Option Length fields.
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Req-type-n The type value for the n'th requested option.
Req-length-n The length of the n'th requested option excluding the
Req-type-n and Req-length-n fields.
In the case where there are only Req-type-n and Req-length-n fields,
the value of the Req-length-n is set to zero. If additional
information besides the Req-type-n is necessary to uniquely specify
the requested context, such information follows after the
Req-length-n. For example, when the requested context is the Vendor-
Specific Option defined in RFC5094, the requested option format looks
as follows:
| ... |
+---------------+---------------+-------------------------------+
| Req-type-N=19 | Req-length-N=6| Vendor-ID |
+-------------------------------+-------------------------------+
| Vendor-ID | Sub-Type |
+---------------------------------------------------------------+
| ... |
6.2.2. Local Mobility Anchor Address (LMAA) Option
This option is used to transfer the Local Mobility Anchor Address
(LMAA), with which the MN is currently registered. The detailed
definition of the LMAA is described in [RFC5213].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Type | Option-Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Local Mobility Anchor Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Yokota, et al. Expires April 30, 2009 [Page 20]
Internet-Draft Proxy-based Fast Handover October 2008
Option-Type TBD4
Option-Length 18
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Local Mobility Anchor Address
The LMA address, with which the MN is currently
registered.
6.2.3. IPv4 Address Option
As described in Section 4.2, if the MN is IPv4-only mode or dual-
stack mode, the MN requires IPv4 home address (IPv4-MN-HoA). The
IPv4 address of the LMA (IPv4-LMAA) is also needed to send PMIP
signaling messages when the ARs and LMA are in an IPv4 transport
network. This option has alignment requirement of 4n.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Type | Option-Length | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option-Type TBD5
Option-Length 6
Option-Code
0 IPv4-MN-HoA
1 IPv4-LMAA
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
IPv4 Address IPv4 address specified in Option-Code
6.2.4. Mobile Node Interface Identifier (MN IID) Option
This option is used to transfer the interface identifier of the MN
that is used in the P-AN. The format of the interface identifier
follows the Mobile Node Interface Identifier Option defined in
[RFC5213].
Yokota, et al. Expires April 30, 2009 [Page 21]
Internet-Draft Proxy-based Fast Handover October 2008
6.2.5. GRE Key Option
This document extends the GRE Key option defined in [grekey] to
specify the direction of the packets and the tunnel to which the GRE
key is assigned. This option has alignment requirement of 4n.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Type | Option-Length | Reserved | Tunnel-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option-Type See [grekey].
Option-Length 6
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Tunnel-Type
1 GRE Key for UL packets over MAG-LMA tunnel
2 GRE Key for UL packets over MAG-MAG tunnel
3 GRE Key for DL packets over MAG-MAG tunnel
GRE Key Identifier See [grekey].
Yokota, et al. Expires April 30, 2009 [Page 22]
Internet-Draft Proxy-based Fast Handover October 2008
7. ICMPv6-based HI/HAck messages
This document extends the HI and HAck defined in [RFC5268] to work
with PMIPv6 and further defines new options and option-codes for the
IP Address option to convey context information.
7.1. ICMPv6-baqsed Handover Initiate
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 | Code | Checksum |
+---------------+-+-+-+-+-------+-------------------------------+
| Subtype |S|U|P|F|Resv'd | Identifier |
+---------------+-+-+-+-+-------+-------------------------------+
| Options ...
+-------------------------
IP Fields:
Source Address
The IP address of PAR or NAR
Destination Address
The IP address of the peer AR
All the other fields follow [RFC5268].
ICMP Fields:
Code If P flag is not set, the Code value follows [RFC5268]. If
P flag is set but F flag is not set, the Code MUST be set
to zero. If both P flag and F flag are set, the Code value
has the following meaning:
0, 1: See [RFC5268].
2: Request forwarding
3: Indicate the completion of forwarding
Yokota, et al. Expires April 30, 2009 [Page 23]
Internet-Draft Proxy-based Fast Handover October 2008
S flag not used when P flag is set and MUST be set to zero.
U flag Buffer flag. Same as [RFC5268].
P flag Proxy flag. When set, PMIPv6 instead of MIPv6 is assumed
for the mobility management protocol. All the involved
nodes MUST perform based on this document for fast handover
procedures.
F flag Forwarding flag. Used to request to forward the packets
for the MN.
All the other fields follow [RFC5268].
Valid options:
MN ID This identifier can be the link-layer address of the MN or
any other type of information that can uniquely identify
the MN. If the link-layer address is used as the MN ID,
the Link-Layer Address (LLA) option defined in [RFC5268]
MUST be used.
MN-HoA This information is stored in the IP Address option.
MN-IID This information is stored in the MN Interface Identifier
option.
Context Request Option Context Request Option This option is used to
request context information typically by the NAR to the PAR
in the NAR-initiated fast handover.
7.2. ICMPv6-based Handover Acknowledge
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 | Code | Checksum |
+---------------+-+-------------+--------------------------------+
| Subtype |P| Reserved | Identifier |
+---------------+-+-------------+--------------------------------+
| Options ...
+------------------------
IP Fields:
Yokota, et al. Expires April 30, 2009 [Page 24]
Internet-Draft Proxy-based Fast Handover October 2008
Source Address
Copied from the destination address of the
Handover Initiate message to which this message
is a response.
Destination Address
Copied from the source address of the Handover
Initiate message to which this message is a
response.
All the other fields follow [RFC5268].
ICMP Fields:
Code:
0: Handover Accepted
5: Context Transferred successfully, more context
available
6: Context Transferred successfully, no more
context available
128: Handover Not Accepted
129: Administratively prohibited
130: Insufficient resources
131: No context available
132: Forwarding Not Available
P flag Proxy flag. When set, PMIPv6 instead of MIPv6 is assumed
for the mobility management protocol. All the involved
nodes MUST perform based on this document for fast handover
procedures.
Valid options:
MN ID Copied from the corresponding HI message.
Yokota, et al. Expires April 30, 2009 [Page 25]
Internet-Draft Proxy-based Fast Handover October 2008
MN-HoA Stored in the IP Address option so that the NAR can use
this address for the PBU.
MN-IID This information is stored in the MN Interface Identifier
option.
LMA Stored in the IP Address option so that the NAR can use
this address for the PBU.
Requested option(s) All the other context information requested by
the Context Request Option in the HI message.
7.3. Context Request Option
This option is sent in the HI message to request context information
on the MN.
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 | Option-Code | Reserved |
+---------------+---------------+---------------+---------------+
| Req-type-1 | Req-option-1 | Req-type-2 | Req-option-2 |
+-------------------------------+---------------+---------------+
. ... .
. .
+---------------+---------------+-------------------------------+
| Req-type-N | Req-option-N | Vendor/Org-ID |
+-------------------------------+-------------------------------+
| Vendor/Org-ID | VS-Type |
+---------------------------------------------------------------+
. ... .
. .
Context Request Option is typically used for the reactive (NAR-
initiated) fast handover mode to retrieve the context information
from the PAR. When this option is included in the HI message, the
requested option(s) MUST be included in the HAck message.
Type TBD6
Length Number of requested context(s)+1.
Option-Code 0
Yokota, et al. Expires April 30, 2009 [Page 26]
Internet-Draft Proxy-based Fast Handover October 2008
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Req-type-n The Type value for the requested option.
Req-option-n The Option-Code for the requested option.
Vendor/Org-ID When the Vendor Specific Option is requested, the 3rd
to 6th octets are used for the Vendor/Org-ID defined
in Section 7.8.
VS-Type When the Vendor Specific Option is requested, the 7th
to 8th octets are used for the VS-Type defined in
Section 7.8.
7.4. GRE Key Option
This option is used to transfer the GRE keys that identify GRE
tunnels between the LMA and MAG and between MAGs.
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 | Option-Code | Reserved |
+---------------------------------------------------------------+
| GRE Key ID |
+---------------------------------------------------------------+
Type TBD7
Length 1
Option-Code
1 GRE Key for UL packets over MAG-LMA tunnel
2 GRE Key for UL packets over MAG-MAG tunnel
3 GRE Key for DL packets over MAG-MAG tunnel
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
GRE Key ID GRE Key value.
Yokota, et al. Expires April 30, 2009 [Page 27]
Internet-Draft Proxy-based Fast Handover October 2008
7.5. Mobile Node Interface Identifier (MN IID) Option
This option is used to transfer the interface identifier of the MN
that is used in the P-AN. The format of the interface identifier
follows the Mobile Node Interface Identifier Option defined in
[RFC5213].
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 | Option-Code | MN IID-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD8
Length The size of this option is in 8 octets including the
Type, Length and Option-Code.
Option-Code 0
MN IID-Length The length of the MN IID in octets
Interface Identifier
The Interface Identifier value of the MN that is used
in the P-AN.
7.6. New option-code for the IP Address Option
To convey the MN-HoA and LMA in the HI or HAck message, new Option-
Codes for the IP Address Option[RFC5268] are defined:
Option-Code
4 MN-HoA
5 LMA
7.7. IPv4 Address Option
As described in Section 4.2, if the MN is IPv4-only mode or dual-
stack mode, the MN requires IPv4 home address (IPv4-MN-HoA). The
IPv4 address of the LMA (IPv4-LMAA) is also needed to send PMIP
signaling messages when the ARs and LMA are in an IPv4 transport
network.
Yokota, et al. Expires April 30, 2009 [Page 28]
Internet-Draft Proxy-based Fast Handover October 2008
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 | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD9
Length 1
Option-Code
0 IPv4-MN-HoA
1 IPv4-LMAA
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
IPv4 Address IPv4 address specified in Option-Code
7.8. Vendor Specific Option
This option is to send other information than defined in this
document. Many of the context information can be vendor specific
(access technology specific). This option is used for such
information.
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 | Option-Code | Reserved |
+---------------------------------------------------------------+
| Vendor/Org-ID |
+-------------------------------+-------------------------------+
| VS-Type | VS-Length |
+---------------------------------------------------------------+
| VS-Value ...
+------------------------------
Type TBD10
Length The size of this option is in 8 octets including the
Type, Length and Option-Code.
Yokota, et al. Expires April 30, 2009 [Page 29]
Internet-Draft Proxy-based Fast Handover October 2008
Option-Code 0
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Vendor/Org-ID The SMI Network Management Private Enterprise Code of
the Vendor/Organization as defined by IANA.
VS-Type The type of the Vendor-Specific information carried in
this option. The type value is defined by the vendor
or organization specified by Vendor/Org-ID.
VS-Length The length of the Vendor-Specific information carried
in this option.
VS-Value The value of the Vendor-Specific information carried
in this option.
Yokota, et al. Expires April 30, 2009 [Page 30]
Internet-Draft Proxy-based Fast Handover October 2008
8. Security Considerations
Security issues for this document follow those for PMIPv6[RFC5213]
and FMIPv6[RFC5268]. In PMIPv6, MAG and LMA are assumed to share
security association. In FMIPv6, the access routers (i.e., the PMAG
and NMAG in this document) are assumed to share security association.
No new security risks are identified. Support for integrity
protection using IPsec is required, but support for confidentiality
is not necessary.
Yokota, et al. Expires April 30, 2009 [Page 31]
Internet-Draft Proxy-based Fast Handover October 2008
9. IANA Considerations
This document defines two new Mobility Header types: the Handover
Initiate (HI) and the Handover Acknowledge (HAck), which need to be
assigned from the same space as the Mobility Header defined in
[RFC3775].
Mobility Header
Value Description Reference
----- ----------------------------- -------------
TBD1 Handover Initiate Section 6.1.1
TBD2 Handover Acknowledge Section 6.1.2
This document defines two new mobility options, which are described
in Section 6.2. The Type value for these options are assigned from
the same numbering space as allocated for the other mobility options,
as defined in [RFC3775].
Mobility Options
Value Description Reference
----- ------------------------------------- -------------
TBD3 Context Request Option Section 6.2.1
TBD4 Local Nobility Anchor Address Option Section 6.2.2
TBD5 IPv4 Address Option Section 6.2.3
This document defines five new IPv6 Neighbor Discovery options, which
are described in Section 7. The Type value for these options are
assigned from the same space as the IPv6 Neighbor Discovery Options
defined in RFC4861.
Neighbor Discovery Options
Value Description Reference
----- ----------------------------- -------------
TBD6 Context Request Option Section 7.3
TBD7 GRE Key Option Section 7.4
TBD8 MN IID Option Section 7.5
TBD9 IPv4 Address Option Section 7.7
TBD10 Vendor Specific Option Section 7.8
Yokota, et al. Expires April 30, 2009 [Page 32]
Internet-Draft Proxy-based Fast Handover October 2008
10. References
10.1. Normative References
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268,
June 2008.
[RFC3775] Johnson, D., "Mobility Support in IPv6", RFC 3775,
June 2004.
[RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers",
RFC 4988, October 2007.
10.2. Informative References
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[IPv4PMIPv6]
Wakikawa, R., Ed. and S. Gundavelli, "IPv4 Support for
Proxy Mobile IPv6",
draft-ietf-netlmm-pmip6-ipv4-support-02.txt,
November 2007.
[grekey] Muhanna, A., Ed., "GRE Key Option for Proxy Mobile IPv6",
draft-ietf-netlmm-grekey-option-01.txt , October 2008.
Yokota, et al. Expires April 30, 2009 [Page 33]
Internet-Draft Proxy-based Fast Handover October 2008
Appendix A. Handoff Type Considerations
PMIPv6 [RFC5213] defines the Handoff Indicator Option and describes
the type of the handoff and the values to set to the option. This
document proposes one approach to determining the handoff type.
According to [RFC5213], the following handoff types are defined:
0) Reserved
1) Attachment over a new interface
2) Handoff between two different interfaces of the mobile node
3) Handoff between mobile access gateways for the same interface
4) Handoff state unknown
5) Handoff state not changed (Re-registration)
By using the MN Interface Identifier (MN IID) option, which is
defined in this document, the following solution can be considered.
When the NMAG receives the MN IID used in the P-AN from the PMAG via
the HI or HAck messages, the NMAG compares it with the new MN IID
that is obtained from the MN in the N-AN. If these two MN IIDs are
the same, the handover type falls into 3) and the Handoff Indicator
value is set to 3. If these two MN IIDs are different, the handover
is likely to be 2) since the HI/HAck message exchange implies that
this is a handover not a multi-homing, therefore the Handoff
Indicator value can be set to 2. If there is no HI/Hack exchange
performed prior to the network attachment of the MN in the new
network, the NMAG may infer that this is a multi-homing case and set
the Handoff Indicator value to 1. In the case of re-registration,
the MAG, to which the MN is attached, can determine if the handoff
state is not changed, so the MAG can set the HI value to 5 without
any additional information. If none of them can be assumed, the NMAG
may set the value to 4.
Yokota, et al. Expires April 30, 2009 [Page 34]
Internet-Draft Proxy-based Fast Handover October 2008
Appendix B. Change Log
o Added separate sections for MH and ICMP.
o Clarified usage of HNP and IPv4-HoA throughout the document.
o Added IANA Considerations.
o Added section on Other Considerations, including operation of
uplink packets when using link-layer addresses, multiple interface
usage and transmission of RA to withdraw HNP in the event of
failure of PMIP6 registration.
o Revised Security Considerations.
Yokota, et al. Expires April 30, 2009 [Page 35]
Internet-Draft Proxy-based Fast Handover October 2008
Authors' Addresses
Hidetoshi Yokota
KDDI Lab
2-1-15 Ohara, Fujimino
Saitama, 356-8502
JP
Email: yokota@kddilabs.jp
Kuntal Chowdhury
Starent Networks
30 International Place
Tewksbury, MA 01876
US
Email: kchowdhury@starentnetworks.com
Rajeev Koodli
Starent Networks
30 International Place
Tewksbury, MA 01876
US
Email: rkoodli@starentnetworks.com
Basavaraj Patil
Nokia
6000 Connection Drive
Irving, TX 75039
US
Email: basavaraj.patil@nokia.com
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
US
Email: xiayangsong@huawei.com
Yokota, et al. Expires April 30, 2009 [Page 36]
Internet-Draft Proxy-based Fast Handover October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Yokota, et al. Expires April 30, 2009 [Page 37]
