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]