MIPSHOP Working Group INTERNET-DRAFT Jaehwoon Lee Expired: January 2006 Dongguk University Sanghyun Ahn University of Seoul July 2005 Flushing Mechanism to Notify Binding Update in MIPv6 draft-jaehwoon-mipshop-flush-mipv6-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 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Mobile IPv6 (MIPv6) is a protocol that allows a mobile node (MN) to maintain connectivity with a correspondent node (CN) via the Internet while changing its point of attachment. In MIPv6, a MN cannot know which packet is the last packet with the previous CoA (PCoA) as the destination address. In this draft, we define the format and the usage of the Flush message, in order for the MN to know the last packet with the PCoA as the destination address sent by the home agent (HA) and/or a CN. draft-jaehwoon-mipshop-flush-mipv6-00.txt Expires - Jan. 2006 [Page 1] Flushing Mechanism to notify Binding Update in MIPv6 July 2005 Table of Contents: 1. Introduction...................................................3 2. Terminology....................................................4 3. Protocol description...........................................4 4. Flush message format...........................................5 5. Applicability Statement........................................6 6. IANA Considerations............................................7 7. Security Considerations........................................7 References........................................................7 Author's Addresses................................................7 Intellectual Property Statement...................................8 Disclaimer of validity............................................8 Copyright Statement...............................................8 draft-jaehwoon-mipshop-flush-mipv6-00.txt Expires - Jan. 2006 [Page 2] Flushing Mechanism to notify Binding Update in MIPv6 July 2005 1. Introduction Mobile IPv6 (MIPv6) defines a protocol that allows a mobile node (MN) to maintain connectivity with a correspondent node (CN) via the Internet while changing its point of attachment [MIPv6]. In MIPv6, a MN is assigned with an IPv6 address as the home address, and the home agent (HA) is the mobility agent which has the same network address as that of the home address of the MN. The access router (AR) is the router prividing the Internet access service to a MN when it is away from home. When a MN visits a foreign network, it is assigned with a care-of address (CoA) and registers its own home address and the CoA (i.e., the binding information) to its HA (if the route optimization is used, this binding information is also registered to the corresponding CN). In MIPv6, no message or procedure is defined for indicating that the HA/CN is about to update its binding cache entry when a MN registers its home address and CoA to its HA/CN by using a binding update message. That is, when a MN moves in a new network, the MN sends a binding update message to its HA/CN in order to register its home address as well as its new CoA (NCoA). However, packets sent from the HA/CN to the MN has the previous CoA (PCoA) as the destination address until the binding update message arrives at the HA/CN and the corresponding binding cache entry is updated. If the binding update message arrives and the binding cache entry is updated at the HA/CN, the MN will receive packets with the NCoA as the destination address. That is, the MN will receive packets by using both routes, one via the PAR and the other via the NAR. In MIPv6, a MN cannot know the last packet with the PCoA as the destination address. Knowing it is especially necessary when a MN tries to deliver the received packets to the upper layer in order. In this draft, we define the format and the usage of the Flush message, in order for a MN to know the last packet sent by the HA/CN just before its updating the binding cache entry. That is, when a MN receives a Flush message with the PCoA as the destination address, the MN can consider those packets sent after the Flush message by the HA/CN as those with the NCoA as the destination address. draft-jaehwoon-mipshop-flush-mipv6-00.txt Expires - Jan. 2006 [Page 3] Flushing Mechanism to notify Binding Update in MIPv6 July 2005 2. Terminology In this draft, we use the terms defined in MIPv6 and FMIPv6, except for the term described below. Flush: the message which is transmitted to a MN from the HA/CN using the PCoA to notify the MN that the HA or CN is going to update its own binding cache entry as soon as it sends out the Flush message 3. Protocol Description MN PAR NAR HA/CN | | | | |<---------------------| | | | Router Advertisement | | | To configure PCoA | | | |--------------------->|------------------------------>| | | Binding Update(PCoA) | | | | Create Binding | | | Cache Entry |<---------------------|<------------------------------| | Binding Ack (If necessary) | |<---------------------|<------------------------------| | Date packet from HA/CN to MN via PAR | | | | | Move from PAR to NAR | | | |<-----------------------------------| | | Router Advertisement | | To configure NCoA | | | |------------------------------------>---------------->| | Binding Update(NCoA) |<---------------------|<------------------------------| | Flush message from HA/CN to MN via PAR | | | | Update Binding | | | Cache Entry |<-----------------------------------|<----------------| | Binding Ack (If necessary) | |<---------------------|-------------|<----------------| | Date packet from HA/CN to MN via NAR | Figure 1: Message exchanging procedure draft-jaehwoon-mipshop-flush-mipv6-00.txt Expires - Jan. 2006 [Page 4] Flushing Mechanism to notify Binding Update in MIPv6 July 2005 Figure 1 shows the message exchanging procedure considered in this draft. If a MN is connected to a foreign network, it constructs a PCoA using the information received from the PAR. And then, the MN sends the binding update message having the PCoA and its Home address to the HA/CN, in order to register the information in the binding cache entry within the HA/CN. After that, Packets transmitted from the HA/CN can be delivered to the MN. When the MN moves to the NAR, it constructs the NCoA from the information provided by the NAR and registers its NCoA and home address to the HA/CN by sending a Binding Update message. Before the Binding Update message is delivered to and updated by the HA/CN, packets from the HA/CN are delivered to the MN via the PAR. If the HA/CN receives the Binding Update message, the HA/CN transmits a Flush message to the MN by using the previous binding information to indicate that its binding cache entry is about to be updated. That is, The Flush message is the last packet with the PCoA as the destination address transmtted from the HA/CN to the MN. After the HA/CN transmits a Flush message, it updates its binding cache entry to the NCoA. And then, the HA/CN can transmit packets with the NCoA as the destination address to the MN. Since it takes time for the Binding Update message with the NCoA and the home address of the MN to arrive at the HA/CN and for the HA/CN to update its binding cache entry, during this period packets sent by the HA/CN to the MN has the PCoA as the destination address. Moreover,those packets transmitted after the update of the binding cache entry of the HA/CN have the NCoA as the destination address. That is, the MN can receive packets sent from the HA/CN by using two routes, one via the PAR and the other via the NAR, which may results in out-of-order packets at the MN. In this case, those packets with the PCoA as the destination address should be processed before those with the NCoA. How to process packets in sequence at a MN is implementation-dependent and this is out of scope of this draft. However, the MN needs to be indicated with the last packet with the PCoA as the destination address. If the MN receives a Flush message from the HA/CN, the MN considers that it is the last packet with the PCoA as the destination address. 4. Flush message format A Flush message is used by the HA/CN to notify a MN that the binding cache entry of the HA/CN is about to be updated. The format of the Flush message is shown as follows: draft-jaehwoon-mipshop-flush-mipv6-00.txt Expires - Jan. 2006 [Page 5] Flushing Mechanism to notify Binding Update in MIPv6 July 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Len | MH Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++++++++++++++++++++++++++| | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Flush Message IP fields: Source address = IP address sending this message Destination Address = MN's PCoA Next Header = Mobility header Mobility header Payload proto = None (to be changed later) MH type = Flush (to be decided by IANA) Mobility options This specification does not define any options valid for the Flush message. 5. Applicability statement The mechanism described in this draft can be applied to FMIPv6 [FMIPv6]. FMIPv6 has been proposed to reduce the handover latency of MIPv6. In FMIPv6, if a MN moves from a network to a new one and the NCoA is not registered yet to the HA/CN, packets from the HA/CN are delivered to the MN via both the PAR and the NAR. Once the MN registers the NCoA to the HA/CN, packets with the PCoA as the draft-jaehwoon-mipshop-flush-mipv6-00.txt Expires - Jan. 2006 [Page 6] Flushing Mechanism to notify Binding Update in MIPv6 July 2005 destination address will arrive at the MN via the PAR and then via the NAR. On the other hand, packets with the NCoA as the destination address will be delivered to the MN via the NAR. This mechanism notifies the MN of the last packet with the PCoA as the destination address delivered by the PAR. The Flush message does not confirm that it is really the last message since there can be route changes in the Internet. It can be the last message when a MN moves from one network to another, only when there is no route changes within the Internet. 6. IANA Considerations This draft document defines a new Mobility Header message which is Flush message. An MH Type value for the Flush message must be assigned by IANA. 7. Security Considerations There is no special security considerations in this draft. References [1] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", RFC 3775. [2] R. Koodli (Editor), et. al, "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-03.txt, work in progress. Authors' Addresses Jaehwoon Lee Dongguk University 26, 3-ga Pil-dong, Chung-gu Seoul 100-715, KOREA Email: jaehwoon@dongguk.edu Sanghyun Ahn University of Seoul 90, Cheonnong-dong, Tongdaemun-gu Seoul 130-743, KOREA Email: ahn@venus.uos.ac.kr draft-jaehwoon-mipshop-flush-mipv6-00.txt Expires - Jan. 2006 [Page 7] Flushing Mechanism to notify Binding Update in MIPv6 July 2005 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. draft-jaehwoon-mipshop-flush-mipv6-00.txt Expires - Jan. 2006 [Page 8]