Network Working Group F. Xia
Internet-Draft B. Sarikaya
Expires: August 26, 2008 Huawei USA
February 23, 2008
Prefix Management for Mobile IPv6 Fast Handover on Point-to-Point Links
draft-xia-mipshop-fmip-ptp-02
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 August 26, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Xia & Sarikaya Expires August 26, 2008 [Page 1]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links February 2008
Abstract
The Mobile IPv6 Fast Handovers (FMIPv6) specification currently does
not explicitly define prefix management over point-to-point links
when a Mobile Node (MN) uses a prefix to formulate a new Care-of-
Address (CoA). In this document a mechanism is proposed for
assigning unique prefixes to the MN by the Previous Access Router
(PAR). The New Access Router (NAR) dynamically assigns an unique
prefix called dedicated prefix to any MN that is performing a
handover. Both reactive and predictive modes of FMIPv6 are
explained.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Prefix Management on Point-to-Point Links . . . . . . . . . . 5
4.1. Predictive mode . . . . . . . . . . . . . . . . . . . . . 5
4.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 6
5. HI and Hack Extension . . . . . . . . . . . . . . . . . . . . 7
5.1. HI Extension . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. HAck Extension . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Dedicated Prefix Option . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative references . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Xia & Sarikaya Expires August 26, 2008 [Page 2]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links February 2008
1. Introduction
Fast handovers for Mobile IPv6 [I-D.ietf-mipshop-fmipv6-rfc4068bis]
aims at reducing the handover latency by reducing the time to
configure a new care-of address (NCoA) for a MN. In FMIPv6, the MN
formulates a prospective NCoA when it is still present on the PAR's
link.
[RFC4968] provides different IPv6 link models that are suitable for
802.16 based networks and provides analysis of various considerations
for each link model and the applicability of each link model under
different deployment scenarios. [RFC5121] specifies the addressing
and operation of IPv6 over the IPv6 specific part of the packet
convergence sublayer of IEEE Std 802.16e [802.16e], and point-to-
point link model is recommended. Also, 3GPP and 3GPP2 have earlier
adopted the point-to-point link model based on the recommendations in
[RFC3314].
In this document, we first explain the problems associated with
FMIPv6 on point-to-point links followed by a detailed description of
prefix management for FMIPv6 operation on point-to-point links.
In Section 3 we describe why the point-to-point link address
formation procedures are needed in FMIPv6, in Section 4 we define a
procedure NAR can use to dynamically assign unique prefixes in point-
to-point links and in Section 5 we define necessary messages/option
for the operation in Section 4.
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 [RFC2119].
The terminology in this document is based on the definitions in
[I-D.ietf-mipshop-fmipv6-rfc4068bis], in addition to the ones
specified in this section.
Point-to-Point Link Model: In this model, a set of MAC transport
connections between a MN and an AR are treated as a single link.
Each link is allocated a separate, unique prefix or a set of
unique prefixes by the AR. Please refer to [RFC4968] for detail.
In this model, a host's only neighbor is its default router.
Xia & Sarikaya Expires August 26, 2008 [Page 3]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links February 2008
Dedicated Prefix: A unique prefix used by a MN in point-to-point
Link Model.
3. Problem Statement
The following are operations as per
[I-D.ietf-mipshop-fmipv6-rfc4068bis]:
o Movement detection. The protocol enables a MN to quickly detect
that it has moved to a new subnet by providing the new access
point and the associated subnet prefix information when the MN is
still connected to its current subnet. For instance, the MN may
discover available access points using link-layer specific
mechanisms (i.e., a "scan" in WLAN) and then request subnet
information corresponding to one or more of those discovered
access points. A MN sends a Router Solicitation for Proxy
Advertisement (RtSolPr) to its access router to resolve one or
more Access Point Identifiers(AP-ID) to subnet-specific
information. In response, the access router sends a Proxy Router
Advertisement (PrRtAdv) message containing one or more [AP-ID, AR-
Info] tuples, which a MN can use in readily detecting movement:
when attachment to an access point with AP-ID takes place, the MN
knows the corresponding new router's coordinates including its
prefix, IP address, and L2 address.
o NCoA configuration. AR-Info contains an access router's L2 and IP
addresses, and the prefix valid on the interface to which the
Access Point (identified by AP-ID) is attached. With the prefix
provided in the PrRtAdv message, the MN formulates a prospective
NCoA.
In point-to-point link model, each MN has one or more dedicated
prefixes, that is, different MNs have different prefixes. The
prefixes could be allocated dynamically. When a MN attaches to an
AR, the AR should delegate one or more dedicated prefixes for it;
when the MN detaches from the AR, the MN's prefixes are released, and
can be reused by other MNs. The number of unique prefixes in this
operation can be huge.
NCoA formulation in point-to-point links requires a PAR to
dynamically request a dedicated prefix from a NAR, and then advertise
it to the MN through a Proxy Router Advertisement (PrRtAdv) message.
[I-D.ietf-mipshop-fmipv6-rfc4068bis] does not specify such
dependencies.
After NCoA is formulated from a dedicated prefix, other operations
such as proxying NCoA with proxy neighbor cache at the NAR and
Xia & Sarikaya Expires August 26, 2008 [Page 4]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links February 2008
duplicate address detection need to be specified.
4. Prefix Management on Point-to-Point Links
The best solution to the problem described in the previous section is
as follows: NARs assign a unique prefix to each MN that could
handover under this NAR. This prefix will be included in AR-Info.
PAR sends this prefix in the PrRtAdv message to MN. In the PrRtAdv
message, A-bit and L-bit MUST be turned on. MN creates its NCoA
based on the prefix received in PrRtAdv message.
4.1. Predictive mode
New FMIPv6 message exchange is introduced for PAR to ask for MN's
dedicated prefix as shown in Figure 1. In
[I-D.ietf-mipshop-fmipv6-rfc4068bis], HI is assumed to be sent after
the FBU for handover indication. Here, modified of HI/Hack messages
are used for prefix request/response. Details are described in
Section 5.
The new AP-ID is included in RtSolPr for PAR to locate the
corresponding NAR.
NAR MAY use DHCP prefix delegation (PD) to request/ release prefixes
from a DHCP server. The DHCP messages is triggered by the HI for
prefix request. NAR MAY also use AAA prefix delegation (PD) to
request/ release prefixes for this MN from an AAA server.
Xia & Sarikaya Expires August 26, 2008 [Page 5]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links February 2008
MN PAR NAR DHCP/AAA Server
| | | |
|------RtSolPr------->| | |
| | HI(Prefix Request) | |
| |------------------------->|Prefix |
| | |-Request->|
| | |<-Reply---|
| | HAck(Prefix Response) | |
| |<-------------------------| |
|<-----PrRtAdv--------| | |
| | |No FBU |
| | |Release |
| | |Prefix |
|------FBU----------->|--------HI--------------->| |
| |<------HAck---------------| |
| <--FBack---|--FBack---> | |
disconnect forward | |
| packets=====================>| |
| | | |
| | | |
connect | | |
| | | |
|--------- UNA --------------------------------->| |
|<=================================== deliver packets |
| | |
Figure 1: Prefix Signaling
In Network-initiated Handover scenario, there isn't specific RtSolPr
to trigger PAR to request a prefix. In this case, implementation
specific trigger SHOULD be used by PAR to send HI message for prefix
request.
4.2. Reactive Mode
In the reactive mode, there are two cases. A MN receives PrRtAdv
message or otherwise.
o The MN receives PrRtAdv message and formulates NCoA before
attaching to the NAR. The MN and the NAR operate in line with
procedure defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis].
o The MN can't formulate NCoA before attaching to the NAR. IP
connectivity should be established at first. The MN can configure
it's IP address using stateless address method, or using stateful
address configuration. In the former case, the NAR SHOULD send
un-solicited RA to expedite MN's address configuration. Once NCoA
formulation is finished, the MN operates according to
[I-D.ietf-mipshop-fmipv6-rfc4068bis].
Xia & Sarikaya Expires August 26, 2008 [Page 6]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links February 2008
In both cases, MN formulates NCoA from the dedicated prefix. Since
MN has already handed over to NAR this prefix is retained.
5. HI and Hack Extension
5.1. HI Extension
The Handover Initiate (HI)defined in
[I-D.ietf-mipshop-fmipv6-rfc4068bis] is an ICMPv6 message sent by an
Access Router (typically PAR) to another Access Router (typically
NAR) to initiate the process of a MN's handover.
In [I-D.ietf-mipshop-fmipv6-rfc4068bis], the PAR uses a Code value of
0 when it processes an FBU with PCoA as source IP address, while uses
a Code value of 1 when it processes an FBU whose source IP address is
not PCoA. A new Code value of 2 is used for the dedicated prefix
request. Dedicated Prefix Option defined in Section 5.3 MAY be
included. NAR allocates dedicated prefix based on the prefix
preference in the option. If the option is not included, NAR
allocates prefix according it's discretion.
5.2. HAck Extension
Handover Acknowledgment message defined in
[I-D.ietf-mipshop-fmipv6-rfc4068bis] is a new ICMPv6 message that
MUST be sent (typically by NAR to PAR) as a reply to the Handover
Initiate message. In this document, HAck is extended to respond to a
dedicated prefix request.
o One new Code value is defined. Here, a Code value of 6 is used
for dedicated prefix response.
o Dedicated Prefix Option defined in Section 5.3 MUST be included
for prefix delegation.
5.3. Dedicated Prefix Option
This option is of the form shown in Figure 2.
Xia & Sarikaya Expires August 26, 2008 [Page 7]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links February 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 | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Dedicated Prefix Option
Type To be assigned by IANA
Length The length of the option in units of 8 octets.
Prefix Length
8-bit unsigned integer. The number of leading bits
in the Prefix that are valid. The value ranges from 0
to 128.
Option-Code
1 Dedicated Prefix
Lifetime 32-bit unsigned integer. The length of time in seconds
(relative to the time the packet is sent). A value of
all one bits (0xffffffff) represents infinity.
Prefix An IP address or a prefix of an IP address. A MN uses it
to formulate NCoA.
6. Security Considerations
Prefix management for FMIPv6 operation on point-to-point links
introduces two messages (HI/Hack) for prefix request and response.
These messages are secured using FMIPv6 security mechanisms and hence
do not introduce any new security threats and the security provided
Xia & Sarikaya Expires August 26, 2008 [Page 8]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links February 2008
by FMIPv6 applies completely.
7. IANA consideration
This document extends existing HI/HAck messages, new Code values need
to be assigned by IANA.
The document defines one new Mobility Option which needs type
assignment from the Mobility Options Type registry at
http://www.iana.org/assignments/mobility-parameters:
1. Dedicated Prefix Option described in Section 5.3.
8. Acknowledgements
The authors would like to thank Heejin Jang, Daniel Park, Vijay
Devarapalli and Rajeev Koodli for valuable comments.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-mipshop-fmipv6-rfc4068bis]
Koodli, R., "Mobile IPv6 Fast Handovers",
draft-ietf-mipshop-fmipv6-rfc4068bis-05 (work in
progress), February 2008.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
Madanapalli, "Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
February 2008.
9.2. Informative references
[802.16e] Institute of Electrical and Electronics Engineer,
"Amendment for Physical and Medium Access Control Layers
for Combined Fixed and Mobile Operation in Licensed
Bands", IEEE 802.16e/D12.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002.
Xia & Sarikaya Expires August 26, 2008 [Page 9]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links February 2008
[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
Based Networks", RFC 4968, August 2007.
Xia & Sarikaya Expires August 26, 2008 [Page 10]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links February 2008
Authors' Addresses
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Xia & Sarikaya Expires August 26, 2008 [Page 11]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links February 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Xia & Sarikaya Expires August 26, 2008 [Page 12]