Internet DRAFT - draft-wood-netlmm-emp-base

draft-wood-netlmm-emp-base










      
      
                                                                     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]