J. Wood Internet Draft DoCoMo USA Labs K. Nishida NTT DoCoMo Inc. Expires: April 2006 October 17, 2005 Edge Mobility Protocol (EMP) draft-wood-netlmm-emp-base-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. This document may only be posted in an Internet-Draft. 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 April 17, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Wood, et. al. Expires April 17, 2006 [Page 1] Internet-Draft Edge Mobility Protocol (EMP) October 2005 Abstract This document specifies a protocol for localized mobility management which allows the mobile node to keep using the same IP address while it is in the same localized mobility management domain. The protocol enables the edge mobility anchor point to manage the routing path for the mobile node in the domain, so that the packet form the correspondent node can be delivered to the access router of MN currently connecting. For routing path management, the protocol also specifies the functionality of the access router to provide the MN's IP address, MN identifier to edge mobility anchor point. The protocol does not require the mobile node to involve in the mobility management if link layer technology can provide MN related information necessary for this protocol. 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. Table of Contents 1. Acronyms and Conventions.......................................3 2. Protocol Overview..............................................3 3. Protocol Specification.........................................7 3.1. Message Formats...........................................9 3.1.1. Message Header.......................................9 3.1.2. IPv6 Address Option.................................10 3.1.3. MN ID Option........................................10 3.2. Message Codes............................................11 3.3. Message Types............................................12 3.3.1. HELLO...............................................12 3.3.2. Query...............................................13 3.3.3. Update..............................................13 3.3.4. Reply...............................................14 3.4. AAR Specification........................................14 3.5. EMAP Specification.......................................16 3.6. Host Specification.......................................17 APPENDIX A: 802.11 EMP Binding...................................18 A.1. Power-On.................................................20 A.2. Inter-EMD Handover.......................................21 A.3. MN Power-Off, Crash, or Departure from Coverage Area.....22 4. References....................................................23 4.1. Informative References...................................23 Author's Addresses...............................................24 Wood, et. al. Expires April 17, 2006 [Page 2] Internet-Draft Edge Mobility Protocol (EMP) October 2005 Intellectual Property Statement..................................24 Disclaimer of Validity...........................................25 Copyright Statement..............................................25 1. Acronyms and Conventions EMD: Edge Mobility Domain EMAP: Edge Mobility Anchor Point AAR: Advanced Access Router CoA: Care of Address MN: Mobile Node, also known as a Host. MNID: Mobile Node Identifier CN: Correspondent Node SCTP: Stream Control Transmission Protocol (RFC 2960) RS: Router Solicitation (RFC 2461) RA: Router Advertisement (RFC 2461) NS: Neighbor Solicitation (RFC 2461) NA: Neighbor Advertisement (RFC2461) DAD: Duplicate Address Detection oDAD: Optimistic Duplicate Address Detection TLV: Type-Length-Value Sometimes messages and their contents will be abbreviated in this document, as follows: MSG[CODE](TLVs) MSG refers to the message type, [CODE] is the code set in the message header, and (TLVs) are the TLVs following the message header. For example, UPDATE[DUP](MNID,ADDR) represents an UPDATE message with the code set to DUP, and containing 1 MN ID and 1 ADDR TLV. If the code is 0, [CODE] may be omitted. 2. Protocol Overview This section contains a high-level overview of how EMP works. A detailed specification is given in subsequent sections. In an EMD, AARs and an EMAP collaborate to allow a MN to move within the EMD without acquiring new CoAs. An EMD's globally routed prefixes are owned by the EMAP, so to a CN, it appears that the EMAP is the Wood, et. al. Expires April 17, 2006 [Page 3] Internet-Draft Edge Mobility Protocol (EMP) October 2005 last hop router for a MN. The EMAP maintains this illusion by forwarding a MN's traffic through a tunnel to the correct AAR. All AARs in an EMD advertise the EMAP's set of prefixes, so when a MN moves to a new AAR, it does not need to configure a new CoA (following RFCs 2461 and 2462). The EMAP handles the move by switching the MN's traffic to the tunnel to the new AAR. The EMP protocol specified in the document allows AARs and an EMAP in an EMD to communicate routing information about MNs' network location. For further information and context about EMP, see [1] and [2]. This document focuses on signaling between AAR and EMAP. Interactions between the MN and AAR depend on the actual link layer used, and so are not specified in this document. For this reason, some elements of the EMP protocol (such as specific triggers for some signaling) are left vague Some link layers may provide capabilities that others do not. These capabilities will shape the interactions between the MN and AAR. A specific set of interactions between MN and AAR is called an EMP binding in this document. An appendix details an EMP binding for the 802.11 link technology; reading this may provide some clarification. EMP uses a MN identifier, referred to as a MNID in this document, to manage tunnel information or forwarding entries at the EMAP or AAR. The MNID must be unique and unchanging in the EMD, and is used to associate the MN with its related information. Some examples of MNIDs are a Network Access Identifier, a Mobile IP Home Address, and a link dependent identifier. In the case of the 802.11 binding, the ID will be simply the 802.11 MAC address. The AAR must be able to set the MNID in all EMP messages it sends. If the link-layer technology is unable to provide such functionality, the AAR must keep some state on the MNID. It should be noted that although MNID must be contained all EMP signalings, how the EMAP and AAR's actually utilize a MNID to organize state for a MN is implementation dependant. EMP uses SCTP as its transport protocol. The EMAP binds to and listens on a well-known port (TBD) for incoming AAR connections. An EMAP must maintain all the state required to keep the routing up to date for each MN in the EMD. Each message an EMAP sends to an AAR contains all the information an AAR needs to execute the required operation. This lessens the amount of state an AAR must keep. Wood, et. al. Expires April 17, 2006 [Page 4] Internet-Draft Edge Mobility Protocol (EMP) October 2005 A MN communicates with an AAR via IPv6 protocols defined in RFCs 2461 and 2462. Either special link-layer support or some modifications beyond RFCs 2461 and 2462 are needed on the MN for movement detection; these are specified below, in the "Host Specification" section. MNs can have one or more global and link-local addresses. These IP addresses are insufficient for identifying the complete address set used by a MN within an EMD. Therefore the EMAP uses the MNID to manage the address set for the MN. The MNID must not change while a MN is in an EMD. When an AAR starts up, it initiates a SCTP association to the EMAP. EMAP discovery is currently undefined; multicast could be used. It then exchanges initialization information (such as tunnel method negotiation, EMAP prefixes, authentication and authorization tokens, and possibly other TBD) with the EMAP, and both parties set up tunnel endpoints. MN AAR EMAP | | | | NS(link-local DAD) | UPDATE(MNID,LL addr) | |---------------------->|---------------------->| | |REPLY[OK](MNID,LL addr)| | |<----------------------| | RS | QUERY(MNID) | |---------------------->|---------------------->| | RA | REPLY[OK](MNID) | |<----------------------|<----------------------| | | | | NS(CoA DAD) | UPDATE(MNID,CoA) | |---------------------->|---------------------->| | | REPLY[OK](MNID,CoA) | | |<----------------------| | | | Figure 1: Power-On, 802.11 Binding Example EMP must handle these basic scenarios: 1. A MN powers-on in the EMD (Figure 1). 2. A MN moves to a new AAR in the same EMD (intra-EMD handover, Figure 2). 3. A MN crashes, powers-off, leaves the coverage area, or moves to a different EMD (Figure 3) It should be noted that EMP works when an inter-EMD handover occurs, but the global mobility protocol should also work to register the fact MN changed the connecting EMD on global mobility anchor point. Wood, et. al. Expires April 17, 2006 [Page 5] Internet-Draft Edge Mobility Protocol (EMP) October 2005 When an AAR detects that a MN has connected to its link (i.e. by receipt of a RS), it does not know if scenario 1 or 2 is occurring, so it queries the EMAP for information about the MN. If scenario 1 is occurring, the EMAP has no state for the MN, so it replies with a message empty except for the MNID (Figure 1). Otherwise, the EMAP has an entry for the MN, and it sends the AAR the MN's IP addresses so the AAR can update its forwarding state (Figure 2). It also deduces that the MN has moved to a new AAR in its EMD, so it switches the MN's traffic to the tunnel to the new AAR, and informs the old AAR so that it can clean up state. A MN can configure a new address at any time, however it is most likely to do so when it enters a new EMD. Once an AAR detects that a MN has configured a new address (i.e. by receipt of a DAD NS for the new CoA), it sends a routing update message to the EMAP (Figure 1). The EMAP ensures that the new address is not duplicate, and answers with a status message. If the address is rejected by the EMAP, the AAR sends the MN an NA containing the new address, which will cause the MN's DAD process to fail. Otherwise, the AAR and EMAP configure their routing such that traffic to the new address will reach the MN, if the address is a global address. MN AAR1 EMAP AAR2 | | | | | RS | QUERY(MNID) | | |--------------->|-------------------->| | | | REPLY[OK] | UPDATE[DEL] | | RA | (MNID,CoA1,...) | (MNID,CoA1,...) | |<---------------|<--------------------|--------------------->| | | | | Figure 2: Intra-EMD Handover, 802.11 Binding Example The EMAP tracks both link local and global addresses for all MNs in its EMD. It tracks link locals only to ensure that they are unique. A MN that has been optimized for EMP could therefore reconfirm its link locals only when it enters a new EMD. Link local addresses are only valid and used within a single AAR's broadcast domain, and packets with link-local destination addresses are never forwarded within an EMD. If the AAR determines that scenario three has happened (by periodic probing at L2 or L3, for example), it informs the EMAP so that the EMAP can clean up state (Figure 3). If the link layer cannot provide this information, the AAR utilizes some other method to detect such an event (this is handled in the EMP binding for the specific link layer). Wood, et. al. Expires April 17, 2006 [Page 6] Internet-Draft Edge Mobility Protocol (EMP) October 2005 MN AAR EMAP | | | | | UPDATE[DEL](MNID) | | X--(disconnected)----|------------------------>| | |UPDATE[DEL](MNID,CoA1,...| | |<------------------------| | | | Figure 3: MN Crashes, Powers-Off, or Leaves Coverage Area Stateless and stateful address configuration both work with the protocol specified in this document. EMP does not mandate any topology regarding the placement of the EMAP and AARs. It is possible, if fact, to co-locate the EMAP with an AAR. A well-written implementation using the Null tunnel method (described below) should support this scenario seamlessly. 2.1. EMP and Tunnels EMP uses tunnels to create a virtual link between the EMAP and an AAR. These tunnels are one-way, carrying either the MNs' incoming or outgoing traffic. The tunnel for incoming traffic is mandatory and is always set up. The EMAP can optionally request that an AAR set up a reverse tunnel back to the EMAP to carry outgoing traffic. EMP can use a number of different tunnel methods. In fact, EMP is agnostic about the tunnel method used, except for the tunnel negotiation exchange. An AAR and EMAP negotiate a tunnel method during the initial HELLO exchange. In its HELLO message, the AAR sends the EMAP a tunnel method option containing a list of tunnel methods it supports. The EMAP selects one method from this list and in its HELLO message to the AAR includes a tunnel method option containing the selected method, and optionally requests that a reverse tunnel be set up. The EMAP thus has the final say over which tunnel method is to be used. The EMAP can choose different tunnel methods for different AARs. If the EMAP requests a reverse tunnel, the tunnel method for the reverse tunnel must be the same as for the forward tunnel. To ensure interoperability, one tunnel method, GRE, is mandatory. All EMAPs and AARs MUST support this method, and AARs MUST include it as one of the supported methods in the initial HELLO. How and when the EMAP and AAR create and manage the negotiated tunnel is implementation dependent. The EMAP should arrange for packets destined to the MN to be encapsulated according to the tunnel method Wood, et. al. Expires April 17, 2006 [Page 7] Internet-Draft Edge Mobility Protocol (EMP) October 2005 chosen, and forwarded to the MN's current AAR. Likewise, the AAR should arrange for the arriving packets to be decapsulated and forwarded on to the MN. The mechanisms for setting up encapsulation, decapsulation, and forwarding on the EMAP and AAR are also implementation dependent. A MN's outgoing traffic can be forwarded by standard IPv6 routing. Hence, there is no requirement in EMP for an AAR to set up a reverse tunnel back to the EMAP or some other node for the MN's outgoing traffic. The EMAP MAY request via the R bit in the HELLO message that the AAR set up a reverse tunnel back to the EMAP. If the EMAP does not request a reverse tunnel, the AAR MAY do this (i.e. for traffic engineering purposes), but if so it must use some mechanism other than EMP to arrange for the tunnel exit point to be set up. Currently the following tunnel methods are defined for EMP. 2.1.1. IPv6 / IPv6 [6] IPv6 packets destined to the MN are encapsulated at the EMAP in an IPv6 tunnel terminating at the MN's current AAR. This has the advantage of utilizing the IPv6 routing topology that is likely to be in place. However, due to the size of IPv6 headers, this method may impose a larger overhead, relative to other tunnel methods. 2.1.2. GRE [7] IPv6 packets destined to the MN are encapsulated at the EMAP in a GRE tunnel.The GRE tunnel terminates at the MN's current AAR. 2.1.3. MPLS [8] IPv6 packets destined to the MN are assigned to a forwarding equivalence class (FEC) by the EMAP. The packets then traverse a label switched path (LSP) mapped to the MN's FEC. The LSP terminates at the AAR (i.e. the AAR is the LSP egress). The mechanism used to create LSPs is out of the scope of this document. Some mechanisms that could be used are static, pre- configured LSPs, or a label distribution protocol (LDP) such as LDP [9] or RSVP-TE [10]. When creating a MPLS tunnel for a MN, an EMAP can use a pre-existing LSP, or it can trigger a LDP to create a new LSP dynamically. How the EMAP interacts with MPLS infrastructure and mechanisms is implementation dependent. Wood, et. al. Expires April 17, 2006 [Page 8] Internet-Draft Edge Mobility Protocol (EMP) October 2005 Similarly, the actions taken by an AAR to become an LSP egress are implementation dependent. Typically, the AAR will need only to participate in an LDP, or be statically configured with an LSP. An AAR may also route outgoing traffic along another LSP for traffic engineering purposes. For some networks, MPLS may have a number of benefits compared to other tunnel methods. Its forwarding overhead can be lower and it can utilize simpler routers, and the encapsulating header can be smaller than that required by other tunnel methods. It also lends itself to the application of traffic engineering within an EMD, permitting traffic optimization techniques such as load balancing, routing around failures, and enhanced QOS. It may also be possible to enhance a LDP to perform route optimization for traffic between MNs in the same EMD. However, MPLS tunnels may also entail more complexity than other tunnel methods, since it may require significantly more effort to set up and manage the protocols and infrastructure necessary. 2.1.4. Null Method This is a pseudo tunnel method. When using it, the EMAP and AAR do not set up any sort of tunnel. It can be used when tunneling is not necessary (i.e. when the EMAP is co-located with an AAR) or some other mechanism is in place to deliver the packets to the AAR. 3. Protocol Specification 3.1. Message Formats An EMP message consists of a header followed by zero or more options. EMP options follow the same format and alignment requirements as RFC2461 neighbor discovery options: they are in TLV format, 8 byte aligned, and the length field contains the length of the option (including the type, length, and padding) in units of 8 bytes. All option payloads whose length is not a unit of 8 bytes must be padded to the correct alignment. 3.1.1. Message Header All EMP messages start with a common header. 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 | Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wood, et. al. Expires April 17, 2006 [Page 9] Internet-Draft Edge Mobility Protocol (EMP) October 2005 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Type: See "Message Types", below Code: 0, except if the type is an UPDATE or UPDATE REPLY, see below Options: MN ID and / or IPv6 Address Option(s). All options are 8- byte aligned. 3.1.2. IPv6 Address Option The IPv6 address option contains some fields for future use. Currently only the IPv6 field is used. 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 | Code | Plen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 0 Length: 3 Code: Future use Plen: Future use Address: The IPv6 address 3.1.3. MN ID Option The MN ID option contains the MN identifier used in the EMD. It is variable length. 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 Wood, et. al. Expires April 17, 2006 [Page 10] Internet-Draft Edge Mobility Protocol (EMP) October 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Binding ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Length | ID ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1 Length: Variable Binding ID: Identifies the EMP binding that created this MNID. This ensures that one EMP binding cannot create MNIDs that collide with another EMP binding's MNIDs. Network byte order. See [3] for ID assignments. ID Length: length of the MN's ID in bytes, network byte order ID: The MN's ID, represented as a sequence of bytes 3.1.4. Tunnel Method Option The tunnel method option contains one or more supported tunnel methods. It is variable length. 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 |R| Reserved | Method Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Method 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Method n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 2 Length: Variable Method Count: A count of the number of tunnel methods listed in the option. R: If set when sent by the EMAP, requests that the AAR set up a reverse tunnel. Tunnel Method: A value encoding of a supported tunnel method. The following tunnel method types are defined: Tunnel Method Value Null 0 IPv6 / IPv6 [6] 1 Wood, et. al. Expires April 17, 2006 [Page 11] Internet-Draft Edge Mobility Protocol (EMP) October 2005 GRE [7] 2 MPLS [8] 3 3.2. Message Codes EMP UPDATE and UPDATE REPLY messages can use the following codes: 1. OK 2. DELETE: delete a MN 3. DELADDR: delete an IP address 4. DUP: proposed IP address is duplicate 5. NO_RESOURCES: EMAP is out of resources 6. INVALID_MSG: protocol message is malformed See below for code usage. 3.3. Message Types Following are the defined types for the EMP message header. 3.3.1. HELLO Type: 0 Code: 0, or INVALID MSG Options: 1 EMP Tunnel Option HELLO messages are exchanged between an AAR and the EMAP during AAR startup. An AAR includes a tunnel option in its HELLO message to the EMAP. The tunnel option contains the tunnel methods supported by the AAR. At least one method, the mandatory GRE tunnel method, MUST be in the method list. Upon receipt of the HELLO message, the EMAP selects one tunnel method from the list proposed by the AAR. In its answering HELLO message, the EMAP includes only the selected method. The AAR MUST use this tunnel method. The EMAP also optionally sets the R bit to request reverse tunneling. If the EMAP cannot select a suitable tunnel method (i.e. if the mandatory method is missing), it sets the code in the HELLO reply to INVALID MSG and aborts the association set up. If the EMAP receives any unknown tunnel methods, it should ignore them. Receipt and successful processing of a HELLO message on an EMAP or AAR may be used to trigger tunnel creation. Wood, et. al. Expires April 17, 2006 [Page 12] Internet-Draft Edge Mobility Protocol (EMP) October 2005 3.3.2. Query Type: 1 Code: 0 Options: 1 MN ID When an AAR detects that a MN has joined its link, it sends a QUERY containing the MNs ID to the EMAP. The EMAP responds with an UPDATE REPLY containing the MN's ID and all global addresses belonging to the MN, if any are known. 3.3.3. Update Type: 2 Code: 0, DELETE, or DELADDR Options: 1 MN ID; 1 or more global or link local IPv6 Addresses Either an AAR or the EMAP can send an UPDATE. When sent from an AAR to the EMAP with the code set to 0, the message contains the MN ID and a new IP Address for verification, and the AAR expects a reply. When the EMAP sends an AAR an UPDATE[DELETE], it is informing the AAR of a MN's movement, and no reply is expected. The MN ID and all of the MN's IP addresses must be included. When an AAR sends the EMAP an UPDATE[DELETE], it is informing the EMAP of the MN's departure. Just the MN ID option is included in the UPDATE. The EMAP must reply with an UPDATE[DELETE] as above containing the MN ID and all the MN's global addresses so that the AAR can clean up state. When an AAR detects that a MN IP address is no longer active, it sends the EMAP an UPDATE[DELADDR] containing the MN ID and the IP address to be deleted. No reply is expected. Following is a summary of the contents of the message for each of these scenarios: AAR sends EMAP new address for verification and update: UPDATE[0](MNID, ADDR) AAR tells EMAP to delete MN: UPDATE[DELETE](MNID) EMAP tells AAR to delete MN: UPDATE[DELETE](MNID, ADDR1, ADDR2, ...) AAR tells EMAP to delete a MN's IP address: UPDATE[DELADDR](MNID, ADDR) Wood, et. al. Expires April 17, 2006 [Page 13] Internet-Draft Edge Mobility Protocol (EMP) October 2005 3.3.4. Reply Type: 3 Code: DUP, NO_RESOURCES, INVALID_MSG, or ADMIN_PROHIB Options: MNID, 1 or more global or link local IPv6 Address REPLY messages are sent from the EMAP to the AAR in response to an UPDATE or a QUERY. Each REPLY message always contains a MNID. If the REPLY is sent in response to an UPDATE, the address is the same address that was in the UPDATE, and conveys status information to the AAR. If the REPLY is sent in response to a QUERY, the reply contains all known IP addresses belonging to the MN. 3.4. AAR Specification Upon startup an AAR exchanges HELLO messages with the EMAP, and sets up a tunnel endpoint from the EMAP. The HELLO messages may be piggybacked on top of the SCTP handshake, if the SCTP stack supports this functionality. The HELLO message conveys tunnel negotiations. When sending its HELLO message to the EMAP, the AAR MUST include all the tunnel methods it supports, including at least the mandatory method. The AAR sets up a decapsulation endpoint for the type of tunnel selected by the EMAP. If the EMAP has set the R bit in the HELLO message, the AAR must also set up an encapsulation endpoint for a tunnel to the EMPA, and route all MN traffic through this tunnel. The reverse tunnel method must be the same as the forward tunnel. The AAR acts as a router per RFC2461, with some modifications for EMP: - The AAR is RECOMMENDED to use link layer dependent signaling if available for movement detection to trigger EMP. - The AAR is REQUIRED to implement DNA[4] to trigger EMP if no link layer dependent signaling is available. - The RA beacon multicast interval should set to very long intervals or turned off. - The AAR will advertise only the prefixes assigned to the EMD. - Each prefix must be advertised as off link. - Some MNs may nonetheless configure addresses they consider to be on link (i.e. via stateful configuration), resulting in the addition of an on-link prefix route. If this happens, hosts may attempt to resolve addresses formed from the local EMD prefix with neighbor discovery. However, neighbor discovery will not succeed if the correspondent node is on a AAR's link within the local EMD. So to force MNs to route all packets through the AAR, the AAR must answer all NS queries for non link-local addresses with its own link address. Wood, et. al. Expires April 17, 2006 [Page 14] Internet-Draft Edge Mobility Protocol (EMP) October 2005 When an AAR detects that a MN has joined its link (i.e. via a RS), it must first obtain the MN's ID. The ID and method of acquisition may vary for different link types. On 802.11 links, for example, the ID will be the MN's MAC address, and will be in the RS. The AAR then sends a QUERY message containing the MN's ID to the EMAP. The EMAP will send an REPLY with the MN ID and 0 or more CoAs belonging to the MN. If the reply contains 0 CoAs, the AAR takes no further action. Otherwise, for each CoA in the reply the AAR adds a forwarding entry (i.e. a host route in the routing table) for the CoA pointing to its wireless interface. It may also add a neighbor cache entry for the CoA, but neighbor cache management is outside the scope of EMP. If an AAR determines that a MN has configured a new link-local or global address (i.e. from a DAD NS), it sends an UPDATE message containing the MN's ID and the new address in an IPv6 address option to the EMAP. The EMAP will send an REPLY message with a status code and containing the MNID and the address in question. If the status code is OK and the address is of global scope, the AAR adds a forwarding entry for the address pointing its access network interface. If the status code is OK and the address is a link-local, the AAR is not required to take any further action, although the EMP- binding may need to track link-local addresses (i.e. for neighbor cache or inactive address management). Otherwise, the AAR must cause the MN's DAD process to fail. The method the AAR uses is link-layer specific, but for the 802.11 binding, it will multicast a NA with the target address set to the proposed address (per RFC2461). If the EMAP sends an AAR an UPDATE message with the code set to DELETE and containing a MN's ID and one or more of the MN's IP addresses, it should remove all forwarding entries for the MN's addresses and clean up any other state it has for the MN. The AAR must be able to detect if a MN has crashed, powered-off, or left the coverage area. If the link layer does not provide this information to the AAR, it must utilize some other mechanism to detect this (such as periodically probing the MN with NSs). Note that this case is different from the case where the MN completes an intra- EMD handover, since in the latter case the EMAP will send the previous AAR an UPDATE[DELETE] message. If an AAR sends the EMAP an UPDATE[DELETE] message and the MN is handing over, the EMAP will lose the MN's routing state, and no packets will be routed to the MN. If the AAR detects that the MN has crashed, powered-off, or left the EMD, it sends an UPDATE to the EMAP with the code set to DELETE and Wood, et. al. Expires April 17, 2006 [Page 15] Internet-Draft Edge Mobility Protocol (EMP) October 2005 containing the MN's ID in a MNID option. The EMAP will respond with an UPDATE[DELETE] containing the MNID and the MN's IP addresses. The AAR should remove all forwarding entries for the MN's global addresses and clean up any other state it has for the MN. If a MN changes IP addresses often, eventually the EMAP's MN binding entry for the MN will become full with inactive addresses. To alleviate this problem, AARs should take measures to detect inactive global IP addresses (by probing addresses with neighbor solicitations, for example). This becomes especially important when the number of MN global IP addresses approaches the maximum set by the EMAP. When an AAR determines that a global IP address is no longer active, it sends the EMAP an UPDATE[DELADDR] containing the MN's ID and the inactive address and removes the forwarding entry for that address. No reply is expected. If a MN temporarily leaves the EMD, by the time it returns the AAR may have deleted state for some of the MN's IP addresses or even all state for the MN. This may pose a problem in some EMP bindings. If the link-layer is capable enough, the EMP-binding for that link-layer should resynchronize with the MN (although this outside the scope of EMP). 3.5. EMAP Specification The EMAP binds to and listens on a well-known SCTP port (TBD) for new connections from AARs. If it receives a HELLO message from an AAR, it must send a HELLO message in response. If it wishes to set up a reverse tunnel with the AAR, the EMAP MUST set the R bit in the HELLO message sent to the AAR. The EMAP selects one tunnel method from the list provided by the AAR, and sets that method in the HELLO message sent to the AAR. At this time, it may also set up a tunnel endpoint to the AAR. If the EMAP receives an UPDATE message containing a MN's ID and an address in an IPv6 address option, it must send an REPLY message in response. The response contains the MN's ID and the address. It must verify that the address is unique in the EMD. If the address is not unique, the code in the response is set to DUP. If the address passes all checks and is of global scope, the EMAP adds a forwarding entry for the address pointing to the tunnel going to the AAR that sent the UPDATE. If the EMAP receives an UPDATE message containing a MN's ID and with the code set to DELETE, the EMAP removes all forwarding entries for that MN's addresses, cleans up any other state associated with the Wood, et. al. Expires April 17, 2006 [Page 16] Internet-Draft Edge Mobility Protocol (EMP) October 2005 MN, and replies with an UPDATE[DELETE] containing the MN's ID and the MN's IP addresses. If the EMAP receives a QUERY message containing a MN's ID, it must send an REPLY message in response. If the EMAP has a binding entry for the MN, it includes the MN's ID and all the MN's IP addresses in the response as a sequence of IPv6 address options. Otherwise, the response contains only the MN's ID. If the EMAP has a binding entry for the MN, and the QUERY is from a different AAR than the AAR in the MN's binding entry, the MN has moved to a new AAR. In this case for each of the MN's global addresses the EMAP removes the forwarding entry pointing to the old AAR's tunnel and creates a forwarding entry pointing to the new AAR's tunnel. The EMAP then notifies the old AAR of the move by sending it an UPDATE message with the code set to DELETE and containing the MN's ID and all the MN's IP addresses as a sequence of IPv6 addresses options. The EMAP should limit the number of IP addresses a MN can configure to prevent resource-draining attacks. If a MN has configured the maximum number of allowed addresses and tries to configure a new one, triggering an UPDATE message, the EMAP replies with an REPLY with the code set to NO_RESOURCES. AARs are responsible for detecting inactive global IP addresses and notifying the EMAP when this happens. If the EMAP receives an UPDATE[DELADDR] with the MN's ID and an address, it removes the forwarding entry for the address and removes the address from the MN's binding entry. 3.6. Host Specification Hosts are RECOMMENDED to use link dependent technology if such technology provides the AAR with a link address or other unique identifier for the host to enable EMP Update, or if such technology provides enough IP-level information for the host: - To give the AAR's the host's MNID when the host moves to a new link - To determine whether or not it has moved to a new AAR and provides the host with enough information to configure on the new AAR Hosts using solution C MUST include a Source Link Layer Address Option when sending a RS. For this reason, hosts MUST NOT use oDAD when sending the RS, since then they cannot provide a Source Link Layer Address Option on the RS to act as a unique identifier for the mobile node. Wood, et. al. Expires April 17, 2006 [Page 17] Internet-Draft Edge Mobility Protocol (EMP) October 2005 If not using solution A, hosts should follow the rules described below: - Hosts MUST NOT use beaconed RAs. An EMP binding may use a RS to trigger the AAR to send QUERY message and detect whether MN moves as intra-EMP handover or inter-EMD handover. Therefore, the host should not depend on beaconed RAs for movement detection. - Host MUST use DAD to confirm the uniqueness of all link local and global addresses. This is true regardless of whether stateful or stateless configuration was used to generate the address. An EMP binding may use a DAD NS to register an IP address at the EMAP. To minimize chance of failure in registering the IP address, hosts should use multiple DAD probes to increase the likelihood that a DAD NS will not be lost. 4. Security Considerations Ensuring that the MNID is bound to the correct MN is crucial to the security of EMP. If an ID can be bound to a non-legitimate MN, a number of attacks become possible: - An attacker could trick EMP into believing a victim MN has moved when it has not, causing denial of service. - An attacker could associate its own IP address with a victim's ID, potentially causing the victim's traffic to be routed to the attacker. - If an attacker can create arbitrary MNIDs, it could mount a resource draining attack on the EMAP and AARs by creating a large number of false MNIDs and registering them with EMP. All these threats originate with how the EMP binding acquires and manages MNIDs. Hence it is the responsibility of the EMP binding to ensure that it is not possible to spoof a MNID. If the EMP binding uses a MAC address as the MNID (as the example 802.11 binding does in this document's appendix), it must counter a number of threats to satisfy EMP security requirements: 1. An attacker could falsify its MAC address in the neighbor discovery process, thereby tricking the EMP binding into associating the victim's MAC address with the attackers IP address, or the victim's IP address with the attackers MAC address. 2. An attacker could send packets with the source IP address of a victim (i.e. in order to traffic-bomb another node). Wood, et. al. Expires April 17, 2006 [Page 18] Internet-Draft Edge Mobility Protocol (EMP) October 2005 Threat 1 can be countered with a combination of appropriate link security, such as 802.11i, and Secure Neighbor Discovery (SEND) [11]. Link security can prevent an attacker from falsifying its MAC address. However, even if link security is in place, an attacker could still include a false MAC address as an option in a ND message (i.e. a source linkaddr option); this will not be prevented by link security or SEND. An AR should therefore obtain a MN's MAC address from the link layer rather than a ND option. SEND will prevent an attacker from claiming a victim's IP address. Threat 2 can be countered with a firewall on the AAR that only allows outgoing traffic with a verified (by SEND) IP-MAC pair. EMP bindings must take measures to prevent MNs from using source IP addresses that are not in the EMD unless the EMP binding can ensure the IP address used by the MN is authorized. This will hinder MNs from participating in bombing attacks on arbitrary nodes in the Internet. The EMAP should limit the number of IP addresses associated with a single MNID to prevent resource draining attacks. EMP assumes a secure, trusted association between each AAR and EMAP. It is recommended that IKE be used to authenticate AARs and EMAPs to one another, and to set up IPSec SAs to protect subsequent signaling. Internal IP addresses of individual components in an EMD infrastructure (i.e. EMAPs, AARs, and other routers) are never revealed via EMP signaling to any end hosts. This makes it more difficult to mount attacks on an EMD infrastructure. To ensure that internal IP addresses do not leak out, measures should be taken to prevent end hosts from using traceroute mechanisms. Wood, et. al. Expires April 17, 2006 [Page 19] Internet-Draft Edge Mobility Protocol (EMP) October 2005 APPENDIX A: 802.11 EMP Binding This appendix describes the 802.11 EMP binding, which may also be suitable for other link layers as well. This section is broken down into a number of scenarios, each with detailed steps taken by all parties (MN, AAR, and EMAP). Note that the MN follows RFC2461 exactly, but additionally must perform movement detection and routing table updates during handover. A.1. Power-On 1.MN autoconfigures a link-local address 2.MN sends a DAD NS for the link-local per RFC2461. 3.AAR sends EMAP an UPDATE(MNID,link-local addr). 4.EMAP checks the link-local and ensures that it is not duplicate. 4.1.If the address is duplicate, the EMAP responds with REPLY[DUP](MNID,link-local addr]. 4.2.If the address is OK, the EMAP responds with REPLY[OK](MNID,ADDR). 5.If the address was rejected by the EMAP for any reason, the AAR multicasts a NA with the target field of the ICMPv6 NA set to the proposed link-local address. 5.1.Upon receipt of this NA, the MN marks the link-local as duplicate and does not use it. It then configures a new link- local address. 6.MN sends a RS on all mobility-enabled interfaces per RFC2461. 7.AAR uses MN MAC address as MN ID, and sends QUERY(MN ID) to EMAP. 8.AAR sends MN RA per RFC2461. 9.EMAP sends AAR REPLY[OK](MNID), containing no addresses since MN is new to the EMD. 10.MN receives RA and acquires CoAs 10.1.For each prefix with the autonomous flag set, MN autoconfigures a global address 10.2.If the RA's managed flag is set, the MN obtains an address Wood, et. al. Expires April 17, 2006 [Page 20] Internet-Draft Edge Mobility Protocol (EMP) October 2005 from DHCPv6. 11.For each new global address, MN sends a DAD NS per RFC2461. 12.For each received NS, the AAR sends the EMAP an UPDATE(MNID,ADDR). 13.For each UPDATE, the EMAP checks the address and ensures that is it not duplicate. 13.1.If the address is duplicate, the EMAP responds with REPLY[DUP](MNID,ADDR]. 13.2.If the address is OK, the EMAP responds with REPLY[OK](MNID,ADDR). 14.If the address was rejected by the EMAP for any reason, the AAR multicasts a NA with the target field of the ICMPv6 NA set to the proposed address. 14.1.Upon receipt of this NA, the MN marks the address as duplicate and does not use it. 15.If the address was accepted by the EMAP, the AAR adds a host route for the new address pointing to the interface serving the MN. 15.1.The MN completes DAD successfully, and proceeded to use the new address. 15.2.The AAR starts a timer to periodically probe one of the MN's addresses. See the Power-Off section, below for this timer logic A.2. Intra-EMD Handover 1.MN detects that it has reassociated and is ready to send IP packets. 1.1.If no 802.l1 security is in use, this is when the reassociate exchange completes. 1.2.If 802.11 security is in use, this is when the security exchange completes. 2.The MN sends a RS. 3.The AAR sends a QUERY(MNID) to the EMAP. 4.The AAR sends a RA to the MN. 4.1.The MN examines the AAR and using movement detection logic Wood, et. al. Expires April 17, 2006 [Page 21] Internet-Draft Edge Mobility Protocol (EMP) October 2005 determines that it is now using a different AAR with the same prefixes. It changes its default route to use the new AAR. Note that these steps are NOT specified by RFC2461. 5.Since the MN is already known to the EMD, the EMAP has the MN's global addresses. It sends these to the AAR: REPLY[OK](ADDR1, ADDR2, ...). 6.The EMAP informs the AAR from which the MN just moved about the handover by sending it an UPDATE[DELETE](MNID,ADDR1,ADDR2). 6.1.The previous AAR removes all host routes for the MN, and cleans up any other state is has for the MN. 7.For each address in the REPLY, the AAR adds a host route for the address pointing to the interface serving the MN. 8.The AAR starts a timer to periodically probe one of the MN's addresses. See the Power-Off section, below for this timer logic. A.3. MN Power-Off, Crash, or Departure from Coverage Area This section is necessary only if an AAR is unable to obtain mobile station status information from the 802.11 AP. This logic could also easily be adapted to probe for inactive global IP addresses. 1.The AAR starts a probe timer. 2.When the timer expires, the AAR unicasts a NS to any one of the MN's global unicast addresses, with the target set to the probed address. 3.If the MN is still on-link and active, it responds with a NA, per RFC2461. 4.If the MN is not on-link and active, it does not respond. The AAR retransmits the NS a number of times. The number of retransmissions and retransmit interval should be configurable. Recommended values are 3 retransmits, spaced one second apart. 4.1.After the AAR has sent the maximum number of NS probes, it considers the MN gone. 4.1.1.It sends an UPDATE[DELETE](MNID) to the EMAP. 4.1.2.The AAR then removes host routes for all the MN's global addresses, and cleans up any other state it may have for the MN. Wood, et. al. Expires April 17, 2006 [Page 22] Internet-Draft Edge Mobility Protocol (EMP) October 2005 5. References 5.1. Informative References [1] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G., Liebsch, M., "Problem Statement for IP Local Mobility", Internet Draft, work in progress. [2] Kempf, J., Leung, K., Roberts, P., Giaretta, G., Liebsch, M., Nishida, K., "Requirements and Gap Analysis for Localized Mobility Management", Internet Draft, work in progress. [3] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", Internet Draft, work in progress. [4] Narayanan, S., Nordmark, E., Pentland, B., "Detecting Network Attachment in IPv6 Networks (DNAv6)", Internet Draft, work in progress. [5] Narayanan, S., Daley, G., Montavont, N., "Detecting Network Attachment in IPv6 - Best Current Practices for hosts", Internet Draft, work in progress. [6] Conta, A., Deering, S., "Generic Packet Tunneling in IPv6 Specification", RFC 2473, September 1998 [7] Farinacci, D., Li, T., Hanks, S., Meyer, D., Traina, P., "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000 [8] Rosen, R., Viswanathan, A., Callon, R., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001 [9] Andersson, L., Doolan, P., Feldman, N., Fredette, A., Thomas, B., "LDP Specification", RFC 3036, January 2001 [10] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., Swallow, G., "RSVE-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001 [11] Arkko, J., Kempf, J., Zill, B., Nikander, P., "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005 Wood, et. al. Expires April 17, 2006 [Page 23] Internet-Draft Edge Mobility Protocol (EMP) October 2005 Author's Addresses Jonathan Wood DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110 USA Email: jonwood@speakeasy.net Katsutoshi Nishida NTT DoCoMo Inc. 3-5 Hikarino-oka, Yokosuka-shi Kanagawa, Japan Phone: +81 46 840 3545 Email: nishidak@nttdocomo.co.jp 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. Wood, et. al. Expires April 17, 2006 [Page 24] Internet-Draft Edge Mobility Protocol (EMP) October 2005 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 (2005). 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. Wood, et. al. Expires April 17, 2006 [Page 25]