Network Working Group Youngjune Gwon draft-gwon-mobileip-efwd-fmipv6-01.txt Alper E. Yegin Expires: June 24, 2002 DoCoMo USA Labs Enhanced Forwarding from Previous Care-of Address for Fast Mobile IPv6 Handovers (eFWD) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This is an individual draft for consideration by the Mobileip Working Group. 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. ABSTRACT This memo introduces a low latency and low loss handover protocol that enhances the performance of forwarding from previous care-of address for Mobile IPv6, namely eFWD. The eFWD allows a mobile node to control and initiate creation of a bi-directional tunnel between the old and the new access routers subsequent to link layer handover. The eFWD handover reduces IP handover latency by eliminating new care-of address acquisition time and by identifying new access router information in advance utilizing Candidate Access Router Information Discovery (CARID) process detailed in this memo. The eFWD protocol removes extra burden on link layer by eliminating any requirement on pre-triggers. Gwon and Yegin Expires June 24, 2003 [Page 2] eFWD December 2002 Table of Contents 1. Introduction....................................................2 2. Terminology.....................................................3 3. Problem Statement and Solution..................................4 4. The Protocol....................................................6 4.1 Overview.....................................................6 4.2 Requirements.................................................8 4.2.1 Control Messages.........................................8 4.2.2 Candidate Access Router Information Discovery (CARID)...13 5. Security Considerations........................................15 6. References.....................................................15 7. Addresses of Authors...........................................16 8. Acknowledgment.................................................16 9. IPR Statement..................................................16 10. Full Copyright Statement......................................17 1. Introduction The Mobile IP Working Group has considered low latency and low loss handover protocols for Mobile IPv6 that can seamlessly support real- time applications. The standard Mobile IPv6 [1] handover process reveals numerous problems manifested by time-consuming network layer-based movement detection, non-optimized time sequencing of handover procedures, and latency of configuring a new care-of address. The Fast Mobile IPv6 Handover Protocol is designed to solve these problems. The current proposal of the fast handover protocol [2] is based on having link layer information available prior to the actual handover so that the mobile node and the access routers should prepare/anticipate for IP handover. In general, the fast handover protocol tends to impose extra set of functions and requirements over the link layer known as link layer triggers (L2 triggers) [3]. In this memo, an extension of the fast Mobile IPv6 protocol is proposed that allows a mobile node to control and initiate the creation of a bi-directional tunnel between the old and new access routers immediately after link layer handover has been completed, namely Enhanced Forwarding from Previous Care-of Address (eFWD). The eFWD optimizes IP handover latency by eliminating new care-of address acquisition and by identifying new access router information in advance. It should be noted that eFWD is free from link layer pre-triggers. 2. Terminology Mobile Node (MN) A Mobile Node is a Mobile IPv6 host capable of moving its point of attachment to the Internet. Gwon Expires June 24, 2003 [Page 3] eFWD December 2002 Access Router (AR) An Access Router is the last router between the network and the mobile node, i.e., the MN has link Layer connectivity to the Access Router. Access Point (AP) A first-hop link layer device between the access router and the mobile node. Old Access Router (oAR) The access router involved in handling a MN's traffic prior to an L2 Handover. New Access Router (nAR) The access router anticipated to be handling a MN's traffic after completion of an L2 handover. Old Care-of Address (oCoA) The care-of address prior to the MN's first movement. In this memo, it may be reused until the MN determines an appropriate time to change it, even if the MN changes subnet. New Care-of Address (nCoA) The care-of address in the new subnet. In this memo, configuration with a nCoA does not have to take place immediately after L2 handover. Bi-directional tunnel (BT) A bi-directional tunnel placed between the ARs where the MN first established its current CoA and a new AR to which the MN is attached where the CoA would be topologically incorrect if used. The new AR tunnels packets from the MN and having the source address as the MN's old CoA to the old AR. The old AR tunnels packets to the MN and having the destination address as the MN's old CoA to new AR. The new AR detunnels the MN- directed packets and sends them over the radio link to the MN (and hence there is no tunnel overhead on the air link). The old AR detunnels correspondent node-directed packets and sends them into the subnet where the old CoA is topologically correct. BTs allow use of the old CoA without running the risk of ingress or egress filtering. Link-layer Handover (L2 Handover) Movement of a MN's point of layer 2 (L2) connection from one wireless access point to another. Depending on the L2, an L2 handover may traverse both a wireless and a wired link, or just a wired link. IP Handover (L3 handover) The process by which a MN obtains a new CoA from the AR, thus updating its routing reachability. L3 handover may occur Gwon Expires June 24, 2003 [Page 4] eFWD December 2002 partially before and partially after L2 handover, or it may occur entirely after L2 handover. Link-layer Trigger (L2 Trigger) Information from L2 that informs L3 of the detailed events involved in handover sequencing at L2. L2 triggers are not specific to any particular L2, but rather represent generalizations of L2 information available from a wide variety of L2 protocols. 3. Problem Statement and Solution The process of Mobile IP network layer handover incurs certain protocol exchanges. These protocol actions are needed to establish on-link connectivity at the new network where a mobile node has moved to, and also to update the remote home agent(s) and end-points for end-to-end connectivity. When the standard Mobile IPv6 is used for network layer handovers, the mobile node first needs to detect the network layer movement. This can be accomplished via observing network prefixes, or relying on L2 triggers. The latter provides much quicker detection wherever such link layer support is available. Secondly, the mobile node needs to discover the IPv6 subnet prefix, if it is going to use stateless address auto-configuration. If movement detection were based on listening to router advertisements, this step is already covered. Otherwise, the mobile node needs to send a router solicitation and receive router advertisements from access routers to learn the IPv6 prefixes available on the link. Third step is configuring a new care-of address. Mobile node can auto-configure a new care-of address based on one of the prefixes and has to go through a duplicate address detection [4] to make sure this address is unique. Finally, the mobile node has to send binding updates to its home agent and correspondent nodes to inform them about its new location. Mobile node is unreachable from the Internet until its new binding Update is received by the home agent and the correspondent nodes. Each of these steps takes time. Therefore, we are motivated to optimize or eliminate some of these steps to minimize the length of service disruption. The L2 triggers are utilized to optimize movement detection process. This saves waiting time to receive few subsequent router advertisements. Binding update process is already optimized by the standard Mobile IPv6 protocol. Binding updates are sent to the old access router instead of home agent when forwarding from the previous care-of address is applied. This optimization saves a round trip time across the Internet. What is left can be summarized as configuring a new care-of address, which relies on prefix discovery and duplicate address detection. Depending on the implementation and configuration, this can be the costliest step among others. Gwon Expires June 24, 2003 [Page 5] eFWD December 2002 Latency of configuring a new care-of address can be eliminated if IP address of the new access router (where mobile node has just moved to) is used as the new care-of address momentarily. If the mobile node can send a binding update to the old access router, informing the old care-of address as the home address and IP address of the new access router as the care-of address, forwarding from the previous care-of address is established through a tunnel between the old access router and the new access router. Since the new access router is the tunnel end-point for forwarded packets, it will have to play a role to decapsulate the packets for this method. In standard Mobile IPv6, the new access router does not have this special role and it simply forwards packets for on-link IP addresses without being aware of mobile node's mobility. Once forwarding from the previous care-of address is established, the old access router intercepts packets sent to the old care-of address and tunnels them to the new access router. The new access router decapsulates tunneled packets and forwards them to the mobile node via one of its interfaces. Similarly, packets sent by the mobile node must be intercepted by the new router and tunneled back to the old access router. By doing so, the packets can be forwarded to the mobile node even before the mobile node has to configure a new care-of address using the new prefix. This approach provides an optimized solution for Mobile IPv6 fast handover when accompanied with link-up trigger [3] for movement detection. This is a mobile-controlled protocol in which mobile node is in charge of IP handovers. It only relies on the link-up trigger and requires no pre-triggers that are based on movement anticipation. In other words, benefits of this approach are reliability that only a successful link layer handover triggers subsequent IP handovers and independence of complexity in pre-signaling before the actual handover. 4. The Protocol 4.1 Overview Figure 1 illustrates Enhanced Forwarding from Previous Care-of Address (eFWD) handover. eFWD is initiated by mobile node when it receives a link-up trigger immediately after arriving at the new access point (nAP). The mobile node must send eFWD BU informing the old access router (oAR) about the new care-of address, therefore new access router (nAR) information, so that the oAR can send HI message to the nAR. We describe a method of doing so via Candidate Access Router Information Discovery (CARID) procedure in detail in 4.2.2 of this memo. The CARID allows the mobile node to learn handover candidate access router information at some sufficient time prior to the actual handover. The list of access routers obtained via CARID includes all possible next routers a host might handover to. After a successful link layer handover, mobile node learns the L2 ID of the Gwon Expires June 24, 2003 [Page 6] eFWD December 2002 new access point (nAP) and maps it to the link layer and network layer IDs of the corresponding nAR. _______ 3. HI _______ | |----------------->| | | |<-----------------| | | | 4. HAck | | | oAR | | nAR | | | 5. BAck | | | |----------------->| |-+ |_______|<-----------------|_______| | @ 2. BU @ ^ | @ @ | | @ @ | | @ @ | | / \ / \ | | /oAP\ /nAP\ | | /_____\ /_____\ | | | | | | | | 5. BAck | 2. | | 1. Link Up | BU | | | | | V | | ______ | | 0. MN has performed CARID and moved | |-+ | ==============>| MN |<---+ |______| Figure 1: eFWD Handover Once MN identifies the information about the nAR, it constructs a BU and sends it to the oAR via nAR. In this BU, home address field is set to the old care-of address, and the care-of address field is set to the IP address of nAR. When this BU reaches at the oAR, HI and HACK messages are exchanged between the oAR and nAR to set up a bi- directional tunnel. With BU being acknowledged (i.e. BAck tunneled to the nAR and forwarded to the MN), incoming packets destined to the mobile node's old care-of address are tunneled by the oAR and the nAR decapsulates and forwards them to the mobile node. Finally, the mobile node may decide to acquire a new care-of address at sometime later and update this information with its home agent and all nodes of interest such as correspondent nodes. It can also choose to terminate the forwarding from previous care-of address by sending a de-registration BU to the oAR. 4.2 Requirements 4.2.1 Control Messages eFWD creates no new control messages. It inherits four control messages are already defined by the standard and the fast Mobile Gwon Expires June 24, 2003 [Page 7] eFWD December 2002 IPv6 protocols: Binding Update (BU), Binding Acknowledgment (BAck), Handover Initiation (HI), and Handover Acknowledgment (HAck) messages. eFWD requires a slight modification onto the existent Binding Update (BU) message defined in [1]. P bit is added to distinguish eFWD handover from other usages. The Binding Update message used by eFWD is described as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|S|D|P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Layer Fields: L2 Source L2 ID of MN L2 Destination L2 ID of nAR IP Fields: Source IP Address Old care-of address of MN Destination IP Address IP address of oAR Acknowledge (A) As specified in [1] Home Registration (H) Must be set for eFWD Gwon Expires June 24, 2003 [Page 8] eFWD December 2002 Single Address Only (S) As specified in [1] Duplicate Address Detection (D) As specified in [1] Enhanced Forwarding from Preivous Care-of Address (P) Must be set for eFWD Reserved As specified in [1] Sequence # As specified in [1] Lifetime As specified in [1] Home Address Old care-of address of mobile node Mobility options This BU must include two options, i.e. alternate care- of address and link-layer address of MN options Alternate care-of address The alternate care-of address field of this option must set to IP address of the nAR. The oAR sends HI message to this address. Link-layer address (LLA) of MN This is a new mobility option that must be supported for eFWD. The value of this option must be set to link- layer address of MN so that nAR knows how to forward packets to the MN when packets destined to the MN arrives from oAR. This option format is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Option Type TBD Length The length of this option, in bytes. Gwon Expires June 24, 2003 [Page 9] eFWD December 2002 Option Data Variable length link-layer address of MN. The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers. Handover Initiation Message used in eFWD is as follows: 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier |S|U|H|T|R|P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address IP address of oAR Destination Address IP address of nAR ICMP Fields: Type TBD Code 0 Checksum As specified in [2] Identifier As specified in [2] S This bit must be unset U As specified in [2] H This bit must be unset T This bit must be unset R This bit must be unset Gwon Expires June 24, 2003 [Page 10] eFWD December 2002 Reserved Must set to zero and ignored by receiver Options Must include both link layer-address of MN option and old care-of address option as specified by [2]. Link- layer address of MN is copied from the incoming eFWD BU (inserted as the new Link Layer Address Option defined above). Old care-of address option is copied from the home address field of incoming BU. Accordingly, Handover Acknowledgment Message for eFWD is as follows: 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier |H|T|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address IP address of nAR Destination Address IP address of oAR ICMP Fields: Type TBD Code As specified in [2] Checksum As specified in [2] Identifier As specified in [2] H This bit must be unset T This bit must be unset Gwon Expires June 24, 2003 [Page 11] eFWD December 2002 R This bit must be unset Reserved Must set to zero and ignored by receiver Options Must contain lifetime option. This indicates the maximum lifetime that the oAR can put in the lifetime field of the BAck message. 4.2.2 Candidate Access Router Information Discovery (CARID) Fast handover domain is defined by a set of access routers and their associated access points. An access router must maintain either a complete list of all access routers in the domain, or a partial list of access routers that are in the same geographic neighborhood, known as geographically adjacent access routers (GAAR). Subset of the GAARs becomes potential handover candidate access routers for visiting mobile nodes. Each entry in the table must contain IP address of the access router, along with link layer address of the access router and link layer address of the associated access points. When a mobile node associates with an access point, all it can figure out is the link-layer address of the access point. Mobile node can identify the associated access router by doing a look up on this table. If such a look up fails, that means fast handover to this network is not supported and the mobile node has to resort to regular Mobile IPv6 handover. Creation and maintenance of this table on the access routers is outside the scope of this memo. It can be done manually or by some dynamic means. Mobile node should be able to request this table from its current access router anytime, not necessarily right before a handover. Gwon Expires June 24, 2003 [Page 12] eFWD December 2002 UDP fields: Source Port Variable Destination Port TBD The UDP header is followed by the CARID fields shown 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 | Data... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... +-+-+-+-+-+- Type 1 - Request 2 - Response Length Length of data in bytes. 0 if this is a Request type. Data field is used only with Response. This field contains a sequence of options in the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | Length | Data... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... +-+-+-+-+-+- Sub-Type 1 - IP address of the access router 2 - Link layer address of the access router 3 - Link layer address of the access point Length Length of data in bytes Sub-type 1 contains IPv6 address of the access router (16 bytes). Sub-types 2 and 3 are to contain link layer addresses of access router and access points. The content and format of this field (including byte and bit ordering) are described in specific documents that explain how IPv6 operates over different link layers, such as IPv6 over Ethernet (RFC 2464). Gwon Expires June 24, 2003 [Page 13] eFWD December 2002 A CARID response carries a list of access routers in its payload. Information related to each access router must begin with Sub-type 1 field (i.e. access router's IPv6 address). This data must be followed by the link-layer address(es) of this access router. And each link-layer address of the access router must be followed by link-layer address(es) of the associated access points. All Sub-type 2 and Sub-type 3 data before the next sub-type 1 data are associated with the access router identified by the leading sub-type 1 data (IPv6 address). All sub-type 3 data before the next sub-type 1 or sub-type 2 data is associated with the access point identified by the leading sub-type 2 data. Data field of a CARID Response must follow an order, such that sub- type 1 is always followed by sub-type 2, and sub-type 2 is always followed by sub-type 3. 5. Security Considerations The protocol exchanges defined in this memo cause routing changes. After a successful protocol signaling, access routers create bi- directional tunnels and install host-based routes to direct a given mobile node's traffic differently than what they would normally do based on the prefix information. Any protocol signaling that can cause such changes in routing needs to be secured in order to prevent malicious nodes taking advantage of them. It is assumed that access routers in a fast handover domain have pre-established security associations among themselves. Therefore, they can use IPSec [5] [6] to secure HI/HAck messages. We cannot assume that a similar pre-established security association will be available between the mobile node and every possible access router. Therefore, this security association needs to be created dynamically. Since mobile node has been receiving IP service from the access router even before the signaling of this protocol, it is assumed that they can establish such a security association based on link layer or network layer methods [3] [7]. Specifics of these methods are outside the scope of this work. Once such an association is established, the mobile node and the access routers can use IPSec to secure BU/BAck and the CARID Request/Response messaging. 6. References [1] Johnson, D., B., et al., "Mobility Support in IPv6," draft-ietf- mobileip-ipv6-19.txt, a work in progress, October 2002 [2] Koodli, R., et al., "Fast Handovers for Mobile IPv6," draft- ietf-mobileip-fast-mipv6-05.txt, a work in progress, September 2002 [3] Kempf, J., et al., "Supporting Optimized Handover for IP Mobility - Requirements for Underlying Systems," draft-manyfolks-l2- mobilereq-02.txt, a work in progress, June 2002 Gwon Expires June 24, 2003 [Page 14] eFWD December 2002 [4] Narten, T., et al., "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December 1998 [5] Kent, S., "IP Authentication Header," draft-ietf-ipsec- rfc2402bis-01.txt, a work in progress, July 2002 [6] Kent, S., "IP Encapsulating Security Payload (ESP)," draft-ietf- ipsec-esp-v3-03.txt, a work in progress, July 2002 [7] Penno, R., ôProtocol for Carrying Authentication for Network Access (PANA) Requirements and Terminology,ö draft-ietf-pana- requirements-04.txt, a work in progress, October 2002 7. Addresses of Authors Youngjune Gwon, Editor DoCoMo Communications Laboratories USA, Inc. 181 Metro Drive, Suite 300 Phone: +1 408 451 4734 San Jose, CA 95110 Fax: +1 408 451 1090 USA email: gyj@docomolabs-usa.com Alper E. Yegin DoCoMo Communications Laboratories USA, Inc. 181 Metro Drive, Suite 300 Phone: +1 408 451 4743 San Jose, CA 95110 Fax: +1 408 451 1090 USA email: alper@docomolabs-usa.com 8. Acknowledgment Authors of this memo thank James Kempf, Atsushi Takeshita, Carl Williams, Ravi Jain, Daichi Funato, Guangrui Fu, and Jonathan Wood for their valuable discussion, comments, and support. 9. IPR Statement The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 10. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing Gwon Expires June 24, 2003 [Page 15] eFWD December 2002 the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Gwon Expires June 24, 2003