Network Working Group David. HU
Internet-Draft Chunqaing. Li
Intended status: Standards Track Huawei Technologies
Expires: January 6, 2009 July 5, 2008
New Care-of CGA Configuration for FMIPv6
draft-li-mipshop-fmipv6-ncoa-cgaconfig-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 January 6, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
HU & Li Expires January 6, 2009 [Page 1]
Internet-Draft NCoA-CGA Configuration July 2008
Abstract
Fast Mobile IPv6 defines the necessary IP protocol messages to reduce
the handover latency resulting from the Mobile IPv6 procedures. One
of the important functionality is new care-of address configuration.
This document introduces two possible methods for configuring NCoA
based on CGA in FMIPv6.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. NAR generates a new care-of CGA for the MN . . . . . . . . 5
3.2. Multiple new care-of addresses for MN . . . . . . . . . . 6
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. NCoA's CGA Parameters Option . . . . . . . . . . . . . . . 9
4.2. Collision Count Option . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
HU & Li Expires January 6, 2009 [Page 2]
Internet-Draft NCoA-CGA Configuration July 2008
1. Introduction
Fast Mobile IPv6 RFC4068Bis [1] defines the necessary IP protocol
messages to reduce the handover latency resulting from the Mobile
IPv6 procedures.In order to reduce the Binding Update latency, FMIPv6
specifies a binding between the Previous CoA (PCoA) and NCoA. A MN
sends a "Fast Binding Update" message to its Previous Access Router
to establish this tunnel. In order to secure the Fast Binding
Update(FBU), the document RFC5269 [2]specifies how to distribute a
symmetric FMIPv6 handover key using SEND [4], which requires the MN's
previous care-of address(PCoA) is Cryptographically Generated
Addresses(CGA). During the next handover, the current NCoA becomes
the PCoA, so the NCoA is also required to be Cryptographically
Generated Address. However, if the NCoA contained in the FBU message
collides with any other address on the new access link, the New AR
will assign a new address as the MN's NCoA, which can't be a CGA. In
this situation, how to protect the FMIPv6 by SEND?
There are two possible solutions to solve the problem. One is the
New AR will assign a CGA as the MN's NCoA when NCoA address collision
ocurrs, which requires that the MN sends its CGA parameters to NAR.
The other is the MN accepts the NCoA assigned by NAR and the NCoA
only can be used in the fast handover process; then the MN configs a
new CGA as the care-of address for home and correspondent bindings
after swithing to the new access link.
HU & Li Expires January 6, 2009 [Page 3]
Internet-Draft NCoA-CGA Configuration July 2008
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 [3].
HU & Li Expires January 6, 2009 [Page 4]
Internet-Draft NCoA-CGA Configuration July 2008
3. Overview
3.1. NAR generates a new care-of CGA for the MN
The protocol utilizes the signaling of FMIPv6 to transfer NCoA's CGA
parameters from MN to NAR. First, when a MN receives a PrRtAdv
message which includes a new router prefix information option, the MN
generates a CGA as NCoA, in accordance with RFC3972 [5]. Then the MN
sends a FBU message to PAR with the NCoA's CGA Parameters Option (see
Section 4.1),the PAR then forwards the NCoA's CGA Parameters Option
to NAR in HI message. If detecting the NCoA duplication on new link,
the NAR will use the NCoA's CGA Parameters contained in HI to
recalculate NCoA. During NAR recalculates a CGA as NCoA, NAR has
only modified collision count in the NCoA's CGA Parameters Option, so
the NAR MUST sends final collision count in Collision Count Option
(see Section 4.2) back to the MN through the HAck and Fback message.
The process is illustrated in Figure 1.
HU & Li Expires January 6, 2009 [Page 5]
Internet-Draft NCoA-CGA Configuration July 2008
MN PAR NAR
| | |
|------RtSolPr-------->| |
|<-----PrRtAdv---------| |
| | |
generate a New | |
Care-of CGA | |
| | |
|--------FBU---------->|----------HI--------->|
|(including the NCoA's |(including the NCoA's |
| CGA parameters) | CGA parameters) |
| | |
| | if NCoA collision, generate
| | a CGA as NCoA
| | |
| |<--------HAck---------|
| | (including collision |
| | count) |
| | |
| <--FBack---|--FBack---> |
| (including collision | (including collision |
| count) | count) |
| | |
disconnect forward |
| packets ===============>|
| | |
| | |
connect | |
| | |
|------------UNA ---------------------------->|
|<==================================== deliver packets
| |
Figure 1: NAR calculates a CGA as NCoA
3.2. Multiple new care-of addresses for MN
Upon receipt of PrRtAdv message, the MN gets the New Router Prefix
Information to formulates a CGA as its NCoA(named as NCoA_0), and
send an FBU message to the PAR prior to switching to the new link.
If detecting the NCoA_0 duplication, the PAR will assign new address
(named as NCoA_1) for the MN, and then the MN utilize the NCoA_1 to
perform the fast handover process. At the same time, the MN configs
a new CGA as the care-of address for home correspondent bindings
after swithing to the new access link. The process is illustrated in
Figure 2 and Figure 3.
HU & Li Expires January 6, 2009 [Page 6]
Internet-Draft NCoA-CGA Configuration July 2008
MN PAR NAR
| | |
|------RtSolPr-------->| |
|<-----PrRtAdv---------| |
| | |
generate a CGA | |
as NCoA (NCoA_0) | |
| | |
|--------FBU---------->|----------HI--------->|
| | |
| | if NCoA collision, assign
| | a NCoA (NCoA_1)
| | |
| |<--------HAck---------|
| | |
| <--FBack---|--FBack---> |
| | |
recalculate a CGA | |
as NCoA (NCoA_2) forward |
| packets ===============>|
| | |
| | |
connect | |
| | |
|------------UNA ---------------------------->|
| (Source Address: NCoA_1) |
| |
|<==================================== deliver packets
| (Destination Address: NCoA_1) |
| |
|------------NA ----------------------------->|
| (Source Address: NCoA_2) |
| |
Figure 2: Predictive Fast Handover
HU & Li Expires January 6, 2009 [Page 7]
Internet-Draft NCoA-CGA Configuration July 2008
MN PAR NAR
| | |
|------RtSolPr-------->| |
|<-----PrRtAdv---------| |
| | |
generate a CGA | |
as NCoA (NCoA_0) | |
| | |
connect | |
|-------UNA------------|--------------------->|
| (Source Address: NCoA_0) |
| | if NCoA collision, assign
| | a NCoA (NCoA_1)
| | |
|-------FBU------------|---------------------)|
| (Source Address: NCoA_1) |
| |<-------FBU----------)|
recalculate a CGA |<------HI/HAck------->|
as NCoA (NCoA_2) | (if necessary) |
| forward |
| packets (including FBAck)=====>|
| | |
|<==================================== deliver packets
| (Destination Address: NCoA_1) |
| |
|-------NA ---------------------------------->|
| (Source Address: NCoA_2) |
| |
Figure 3: Reactive Fast Handover
In above scenarios, upon attaching to new link, the MN SHOULD send
additional Neighbor Advertisement message with the 'O' bit set, to
the all-nodes multicast address. This message allows MN's neighbors
to update their neighbor cache entries.Especially, when NAR receives
the Neighbor Advertisement message, NAR should reserve its proxy
neighbor cache entry about NCoA_1, and add a new neighbor cache entry
about NCoA_2.
HU & Li Expires January 6, 2009 [Page 8]
Internet-Draft NCoA-CGA Configuration July 2008
4. Message Formats
4.1. NCoA's CGA Parameters Option
This option is sent in the Fast Binding Update and Handover Initiate
messages.
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 | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. NCoA's CGA Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NCoA's CGA Parameters Option
Fields: Type: To be assigned by IANA.
Length: The length of the option (including the Type, Length, Option-
Code, Pad Length, NCoA's CGA Parameters, and Padding fields) in units
of 8 octets.
Option-Code: 0 Pad
Length: The number of padding octets beyond the end of the NCoA's CGA
Parameters field but within the length specified by the Length field.
Padding octets MUST be set to zero by senders and ignored by
receivers.
NCoA's CGA Parameters: A variable-length field containing the CGA
Parameters data structure described in RFC3972.
Padding: A variable-length field making the option length a multiple
of 8, containing as many octets as specified in the Pad Length field.
HU & Li Expires January 6, 2009 [Page 9]
Internet-Draft NCoA-CGA Configuration July 2008
4.2. Collision Count Option
This option is sent in the Handover Acknowledge and Fast Binding
Acknowledgment messages.
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 |Collision Count|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Collision Count Option
Fields: Type: To be assigned by IANA.
Length: The size of this option in 8 octets including the Type,
Option-Code and Length fields. The length is 1.
Option-Code: 0: recalculating a CGA as NCoA is successful
1: recalculating a CGA as NCoA is failed.
If the Option-Code is 0, MN MUST accepted the new collision count in
this option.
Collision Count: This is an eight-bit unsigned integer that MUST be
0, 1, or 2. The collision count is incremented during CGA generation
to recover from an address collision, See RFC3972 [5].
Reserved: MUST be set to zero by the sender and MUST be ignored by
the receiver.
HU & Li Expires January 6, 2009 [Page 10]
Internet-Draft NCoA-CGA Configuration July 2008
5. Security Considerations
This draft introduces the NCoA's CGA Parameters Option and Collision
Count Option. The CGA Parameters Option may be carried by FBU or HI
and the Collision Count Option may be included in FBack or HAck. The
FBU and FBack can be protected by the security association shared
between MN and PAR established by SeND mechanism; The PAR and NAR
implement IPsec for protecting the HI and HAck messages; so
delivering of these tow new options is secure. For more security
considerations, please refer to the document RFC5269 [2].
HU & Li Expires January 6, 2009 [Page 11]
Internet-Draft NCoA-CGA Configuration July 2008
6. IANA Considerations
The NCoA's CGA Parameters Option and Collision Count Option are
defined, and require a appropriate option type code from IANA.
HU & Li Expires January 6, 2009 [Page 12]
Internet-Draft NCoA-CGA Configuration July 2008
7. References
[1] R. Koodli, "Mobile IPv6 Fast Handovers", February 2008.
[2] James Kempf , "Distributing a Symmetric FMIPv6 Handover Key
using SEND", June 2008.
[3] Bradner, S, "Key words for use in RFCs to Indicate Requirement
Levels", March 1997.
[4] Arkko, J., Kempf, J. , Zill, B., , and Nikander, P., "SEcure
Neighbor Discovery (SEND)", March 2005.
[5] Aura, T., "Cryptographically Generated Addresses", March 2005.
HU & Li Expires January 6, 2009 [Page 13]
Internet-Draft NCoA-CGA Configuration July 2008
Authors' Addresses
David Hu
Huawei Technologies
Email: huyinliang@huawei.com
Chunqiang Li
Huawei Technologies
Email: li.chunqiang@huawei.com
HU & Li Expires January 6, 2009 [Page 14]
Internet-Draft NCoA-CGA Configuration July 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).
HU & Li Expires January 6, 2009 [Page 15]