Point-to-Point Protocol Extensions Working Group Internet Draft Youngjun Park Kyungjoo Suh Youngchul Kim Hyunok Kim Document: draft-park-pppext-mip6-co-00.txt Samsung Electronics Expires: January 2005 July 2004 New IPv6CP Configuration Option for Mobile-IPv6 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668 [1]. 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 12, 2005. Abstract This memo proposes an alternative to IPv6CP interface identifier negotiation in RFC 2472. Shorter PPP setup time is preferable to Mobile-IPv6 in order to prevent from the packet loss of ongoing data session. New IPv6CP Configuration Option and interface identifier negotiation process proposed here are designed to minimize latency in IPv6 address configuration when Mobile-IPv6 mobile node moves to new PDSN. Park, et al. Expires - January 2005 [Page 1] Configuration Option for MIPv6 July 2004 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents 1. Introduction...................................................3 2. Mobile-IPv6 using IPv6CP with PPP..............................3 3. New IPv6CP Configuration Option................................4 3.1. Mobile-IPv6 Configuration Option........................5 3.2. Mobile Node Operations..................................6 3.3. PDSN Operations.........................................7 4. Example........................................................8 Security Considerations...........................................9 References.......................................................10 Author's Addresses...............................................10 Intellectual Property Statement..................................11 Disclaimer of Validity...........................................11 Copyright Statement..............................................11 Park, et al. Expires - January 2005 [Page 2] Configuration Option for MIPv6 July 2004 1. Introduction In some wireless communication systems such as cdma2000, MN (Mobile Node) uses PPP (Point-to-Point Protocol) for establishing link with access router. PPP gives IP connectivity to mobile node as well by using Network Control Protocols [3]. IPCP (IP Control Protocol) associated with PPP provides IPv4 addresses during the network phase of PPP link operation. In the similar manner, IPv6CP (IPv6 Control Protocol) specifies negotiating procedure for interface identifiers of IPv6 addresses [4]. When Mobile-IPv6 is implemented on top of PPP, the time elapsed in configuring IPv6 addresses is crucial consideration. Because PPP connections takes place during data packets are exchanged, long PPP setup time including IPv6 address ?which are CoA (Care-of-Address) of MN - configuration may disrupt the communication with correspondent nodes [5]. In IPv6CP, interface identifiers are decided by symmetric negotiations between communicating peers, but it may result to the PPP setup latency. In some situation, unilateral assignment of interface identifiers can be a better solution from the point of "Rapid IP re-connectivity after MN moves". This memo deals with asymmetric interface identifier negotiation by which mobile nodes are able to configure IPv6 addresses more rapidly. 2. Mobile-IPv6 using IPv6CP with PPP Whenever MN changes the point of attachment from an access router to other access point, MN shall re-configure its CoA - local IP addresses - to obtain IP connectivity. These addresses can be formulated by statefully or statelessly. In UMTS, IPv6 addresses are granted statefully by DHCP (Dynamic Host Configuration Protocol) server. In cdma2000, IPv6 addresses can be configured statelessly by using PPP connection with PDSN (Packet Data Serving Node) [6]. PPP connection is established in the phased manner [3]. When a physical link between two PPP peer is activated, logical link becomes open in the "Establish" phase by Link Control Protocol. Then the network layer protocols are configured and exchanged in the "Network" phase by Network Control Protocols on top of Link Control Protocol. IPv6CP is current standard Network Control Protocol for configuration and exchange of IPv6 [4]. Upon completion of "Establish" and "Network" phase negotiation, hosts can configure IPv6 address and start IP packet transmission. For non-Mobile-IPv6 host, IP packet transmission happens within established PPP session. Therefore IP addresses don't change during Park, et al. Expires - January 2005 [Page 3] Configuration Option for MIPv6 July 2004 IP packet transmission. PPP setup has no effect on the performance of non-Mobile-IPv6 host. However, in Mobile-IPv6, MN changes the attached PDSN from time to time regardless whether it is during receiving packets or not. Whenever MN changes its PDSN of attachment, it shall establish PPP connection with new PDSN. Because new PPP connection takes significant time, MN may endure receiving IP packet loss. Packet loss occurs until MN finishes binding updates to its home agent and correspondent nodes. Interface identifier negotiation in RFC 2472 permits that duplicate interface identifiers can be chosen multiple times, and it may extend negotiation time [4]. The reason of multiple duplications is that two endpoints choose new interface identifier value independently and respectively. Instead, if the interface identifier value of one endpoint is fixed, duplication occurs at most only one time. Current Mobile-IPv6 performs some kind of operations to detect movement. However, these procedures are omitted in PPP because it is obvious that MN has moved if new PPP connection is established. For example, Neighbor Unreachability Detection and Duplicate Address Detection are executed in Mobile-IPv6 [5], but they are ignored in PPP [4]. We can skip theses steps by configuring IPv6 address in IPv6CP. 3. New IPv6CP Configuration Option Two types of IPv6CP Configuration Options have been specified in [4], which are Interface-Identifier and IPv6-Compression-Protocol. Interface-Identifier Options are exchanged between two PPP peers to negotiate the interface identifier. We propose new Configuration Option which is customized for Mobile-IPv6. As stated in previous section, new Configuration Option is designed to achieve two objects. First, its operation makes it possible that MN's interface identifier is allocated by PDSN when default interface identifiers of both MN and PDSN are duplicated. Also, PDSN can allocate new interface identifier to MN in administrative reason. Second, new Configuration Option can provide the method by which it is possible that MN configures its IPv6 addresses and omits unnecessary movement detection processes. Park, et al. Expires - January 2005 [Page 4] Configuration Option for MIPv6 July 2004 3.1. Mobile-IPv6 Configuration Option New Configuration Option format is defined below. 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 | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (MS Bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (LS Bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 Length 12 Subtype This field indicates the type of Value field. When Subtype = 0, Value field contains 64 bits interface identifier and when Subtype = 1, the Value field contains prefix of PDSN. Configure Option with Subtype = 1 is transmitted only by PDSN included in Configure-Ack. Value This field contains the value of interface identifier or prefix of PDSN according to the Subtype. As like the existing Configuration Options, new Mobile-IPv6 Configuration Option is transmitted being inserted to the Option field of PPP Link Control Protocol packet. Park, et al. Expires - January 2005 [Page 5] Configuration Option for MIPv6 July 2004 3.2. Mobile Node Operations When an MN changes its PDSN of attachment by the consequence of handover to adjacent cell, the physical link between MN and new PDSN becomes active. PPP link between MN and PDSN is established by the exchange of Link Control Protocol. In "Network" phase, Mobile-IPv6 IPv6CP Configure-Options are exchanged to configure IPv6 address of MN. When PPP link is established, MN sends Configure-Request with Configure Option Mobile- IPv6. The Configure Option has Type 3, Length 12, Subtype 0, and the default interface identifier of MN contained in its Value field. The interface identifier MN used when attached to the previous PDSN would be a good default interface identifier, but the Choice of default identifier is dictated in [4] and out of scope of the memo. After sending Configure-Request, MN waits for receiving message from PDSN. - If a Configure-Request is received, a Configure-Ack shall be sent to PDSN regardless of the received interface identifier. MN continues waiting for reception of Configure-Ack or Configure-Nak from PDSN. - If a Configure-Nak is received, the interface identifier of MN shall be changed to the value of Configure-Nak and a Configure- Request with new interface identifier shall be sent again. MN continues waiting for reception of Configure-Ack or Configure-Nak from PDSN. - If a Configure-Ack is received, the interface identifier negotiation is complete and MN can use the interface identifier of recently sent Configure-Request. MN checks if Mobile-IPv6 Configuration Option is appended to Configure-Ack. It Mobile-IPv6 Configuration Option with Subtype 1 is appended, then MN shall use the Value of Configuration Option as future prefix value when configuring CoA. MN repeats "Send Configure-Request" -> "Receive Configure-Nak" -> "Send Configure-Request" until it receives Configure-Ack successfully as specified in [4]. However, the iteration occurs only one time in the worst case when the default interface identifier values of MN and PDSN are equal. Park, et al. Expires - January 2005 [Page 6] Configuration Option for MIPv6 July 2004 3.3. PDSN Operations PDSN plays a role of access router as well as PPP peer to MN when MN implements Mobile-IPv6 on top of PPP. IPv6CP supports stateless IPv6 address configuration, however, in certain wireless communication systems, IPv6 addresses shall be configured statefully in administrative reason. When PPP link is established, PDSN sends Configure-Request with Configure Option Mobile-IPv6. The Configure Option has Type 3, Length 12, Subtype 0, and the default interface identifier of PDSN contained in its Value field. After sending Configure-Request, PDSN waits for receiving message from MN. - When a Configure-Request is received with the Mobile-IPv6 Configuration Option, PDSN compares received interface identifier value with the recently-sent interface identifier value included in Configure-Request or Configure-Nak. 1. If two interface identifiers are different but the received interface identifier is zero, a Configure-Nak is sent with non- zero interface identifier value. 2. If two interface identifiers are different and the received interface identifier is non zero, a Configure-Ack is sent. Prefix value of PDSN may be included in Configure-Ack. In this case, the Subtype of Configuration Option appended to the Configure-Ack shall be set to 1. 3. If two interface identifiers are equal and not zero, a Configure-Nak must be sent with non-zero interface identifier value. A different value shall be chosen as a new interface identifier. 4. If two interface identifiers are equal to zero, the interface identifiers negotiation must be terminated by transmitting the Configure-Reject with the interface identifier value set to zero. - If a Configure-Nak is received, a Configure-Request with interface identifier of recently-sent Configure-Request is sent again. - If a Configure-Ack is received, the interface identifier negotiation is complete and PDSN can use the interface identifier of recently-sent Configure-Request. Actually, this value is default interface identifier of PDSN. PDSN may want to provide MN with particular IPv6 IP addresses for administrative reason. In this case, PDSN sends Configure-Nak with the interface identifier of interest. By the rules of 3.2, MN shall Park, et al. Expires - January 2005 [Page 7] Configuration Option for MIPv6 July 2004 change its interface identifier to which PDSN allocates to the MN. PDSN can allocate IPv6 address of MN statefully by forcing interface identifier with Configure-Nak and forcing prefix with Configure-Ack. 4. Example One simple example of proposal is shown below. [MN] [PDSN] | | | | a. Configure-Request (A)+--------------->| | | | | |<---------------+b. Configure-Request (A) | | | | c. Configure-Ack+--------------->| | (Decides interface identifier) | | |<---------------+d. Configure-Nak (B) | | | | e. Configure-Request(B)+--------------->| | | | | |<---------------+f. Configure-Ack (prefix) (Decides interface identifier) | | | | | Park, et al. Expires - January 2005 [Page 8] Configuration Option for MIPv6 July 2004 When the PPP link is establish, two endpoints of the link send Configure-Request to the peer respectively. In this example, MN sends its Configure-Request with default interface identifier "A" (a). PDSN also sends Configure-Request with its own default interface identifier "A" (b). Accidentally, two endpoints choose same tentative interface identifiers. Even if MN receives Configure-Request of PDSN which contains same interface identifier equal to its own, MN responds with Configure- Ack. This means MN has no intend to change PDSN's current interface identifier and to allow for PDSN to use current interface identifier "A" (c). Upon reception of Configure-Ack of MN, PDSN decides to use interface identifier "A". However, PDSN acts in different way when it receives Configure- Request from MN with interface identifier equal to its own. PDSN chooses new interface identifier "B" which is different from the received interface identifier. PDSN sends Configure-Nak with interface identifier "B" indicating for MN to change interface identifier to new value "B" (d). MN receives this request and changes its interface identifier to "B" and sends Configure-Request to PDSN again with new interface identifier "B"(e). Because two interface identifiers of both endpoints are successfully negotiated, PDSN responds to MN with Configure-Ack. For faster address configuration, prefix information of PDSN can be included in Configure-Ack (f). When MN receives Configure-Ack from PDSN, it confirms using "B" as its interface identifier and all the interface identifier negotiation process is complete. Security Considerations New IPv6CP Configuration Option can be used with all defined PPP authentication. The authentication of MN in case of wireless communication system is out of the scope of this document. Park, et al. Expires - January 2005 [Page 9] Configuration Option for MIPv6 July 2004 References Normative References [1] S. Bradner, "Intellectual Property Rights in IETF Technology", BCP: 79, RFC 3668, February 2004 [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [3] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, July 1994 [4] D. Haskin, E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998 [5] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004 [6] 3GPP2 X.S0011-002-C, "cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP Access Services", August 2003 [7] J. Solomon, S. Glass, "Mobile-IPv4 Configuration Option for PPP IPCP", RFC 2290, February 1998 [8] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998 Author's Addresses Youngjun Park Samsung Electronics Email: youngjun74.park@samsung.com Kyungjoo Suh Email: joo.suh@samsung.com Youngchul Kim Email: pertzs.kim@samsung.com Hyunok Kim Email: dada.kim@samsung.com Park, et al. Expires - January 2005 [Page 10] Configuration Option for MIPv6 July 2004 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Park, et al. Expires - January 2005 [Page 11]