NETLMM Hui Wang Internet Draft Yanfeng Zhang Draft-wanghui-netlmm-protocol-00.txt Yong Xia NEC Labs China Expires: Oct. 2006 April 10, 2006 NETLMM Protocol draft-wanghui-netlmm-protocol-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 2006. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract This document specifies a network-based localized mobility management (NETLMM) protocol which enables mobile nodes remaining reachable while moving across different access routers in a certain access network zone called Edge Mobility Domain (EMD). This protocol requires no extra host stack support and no complex security and H. Wang Expires October 10, 2006 [Page 1] Internet-Draft NETLMM Protocol April 2006 signaling interactions between mobile node and the access network. Especially, by utilizing the neighbor Access Router (AR) information, NETLMM can achieve very fast and smooth handover performance to fit the requirements of most real-time and interactive multimedia applications. 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 [1]. Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. Protocol Overview...........................................4 3.1. MN Attaching Procedure..................................5 3.2. Communication Initialization Procedure..................6 3.3. Fast Handover Procedure.................................7 4. Protocol Specification......................................11 4.1. Conceptual Data Structures.............................11 4.2. Access Router Operation................................11 4.3. Edge Mobility Anchor Point Operation...................13 5. Security Considerations.....................................14 6. IANA Considerations........................................14 7. Acknowledgments............................................14 8. References.................................................14 Author's Addresses............................................16 Intellectual Property Statement................................16 Disclaimer of Validity........................................17 Copyright Statement...........................................17 Acknowledgment................................................17 1. Introduction A number of protocol proposals for terminal mobility management have been proposed in IETF, such as MIPv6 [2], HIP [9] and MOBIKE [10]. They could be view as global mobility protocols, which allow a mobile node to maintain reach-ability when changing its attaching access routers, by updating the address mapping between the home address and care-of address at the global mobility anchor point, or even changing the mapping directly at the corresponding node end to end. Global mobility management protocols can be used between access routers to H. Wang Expires October 10, 2006 [Page 2] Internet-Draft NETLMM Protocol April 2006 handle local mobility. However there are many well-known problems, such as possibly long location update latency, large signaling cost and etc. An extensive discussion on these problems can be found in [5]. Instead of using a global mobility management protocol on each IP link move, a protocol to localize the management of topologically small movements is more preferable to handle local movements. And the requirements and gap analysis for IP local mobility are discussed in [6]. This document describes a Network-based Localized Mobility Management (NETLMM) protocol, which is aimed to achieve the goals proposed in [5] and [6]. This document describes the efficient support for mobile nodes communicating with peers both outside and inside the same mobility domain when mobile nodes moves across different access routers, which requires no extra host stack support, no complex security and signaling interactions between mobile node and the access network. By utilizing the neighbor Access Router information, NETLMM can achieve very fast and smooth handover performance to fit the requirements of most real-time and interactive multimedia applications. 2. Terminology Access Router (AR) A router in an Edge Mobility Domain, which handles the movement events of a mobile node, registers the association of a mobile node with its point of attachment to an Edge Mobility Anchor Point and provides routing services to mobile nodes. Edge Mobility Anchor Point (EMAP) EMAP is a light location server in an Edge Mobility Domain, which maintains current location (the attaching AR) for a mobile node when the mobile node is in an Edge Mobility Domain. EMAP is generally embedded in the gateway of an Edge Mobility Domain, and thus it also takes the role of delivering the packets to mobile hosts. Edge Mobility Domain (EMD) An administrative network composed of Access Routers and Edge Mobility Anchor Points. Besides ARs and EMAPs, an EMD can also contain other internal networking components, such as a common router, to construct the whole EMD. But the common routers cannot provide access service with mobility support. H. Wang Expires October 10, 2006 [Page 3] Internet-Draft NETLMM Protocol April 2006 3. Protocol Overview NETLMM protocol, operating within an Edge Mobility Domain (EMD), is a network-based localized mobility management protocol, which supports both IPv6 and IPv4. In this draft, we use IPv6 for illustration. The IP address configuration for a mobile node (MN) is the same as in standard IPv6 system, by either using DHCP or stateless IP address configuration. As for DHCP method, the DHCP server will assign the same subnet address to all mobile nodes; as for stateless IP address configuration, each AR advertises the same prefix which is called the EMD subnet prefix, so that a MN keeps its IP address unchanged when it moves among different ARs within an EMD. This section describes an overview of NETLMM protocol configuration. It is assumed that only one single EMAP exists within this EMD. The architecture model is shown in Figure 1. The communications between both MN-CN and MN1-MN2 will be discussed, with the fast handover procedure. NETLMM utilizes link layer identifier to help to do fast and efficient handover. The architecture model in Figure 1 is a little different from the network model depicted as Figure 1 in the problem statement document [5]. Compared with the later, the Access Points (APs) is omitted on Figure 1 in this draft. The reason is that when the MN moves between two APs belonging to the same AR, the AR knows nothing about this movement. Since this NETLMM protocol is focusing on layer 3 handover between ARs, we just simply this architecture model. From this point of view, the architecture model in this draft is consistent with that in the problem statement draft [5]. +----------------------+ | Edge Mobility Domain | +----------+ | | | | +-----+ | +----+ +------+ | | External | +----+ | MN1 |-+---| AR |--+--| EMAP |-------------------| CN | +-----+ | +----+ | +------+ | | Network | +----+ | | | | | +-----+ | +----+ | | +----------+ | MN2 |-+---| AR |--+ | +-----+ | +----+ | | | +----------------------+ Figure 1 : Architecture Model The EMAP works as a local domain location server, managing mapping of the MN's address to the AR's address where the MN attaches. On one hand, the mapping is used to manage a bi-directional tunnel between a particular MN's current AR and its EMAP for forwarding packets H. Wang Expires October 10, 2006 [Page 4] Internet-Draft NETLMM Protocol April 2006 between a correspondent node (CN) outside the EMD and the MN. On the other hand, while for support intra EMD communications between local mobile nodes, this mapping will provide a location information to help to build the bi-directional tunnel to forward data between the two ARs which the MNs attaching to. The detailed processes will be given below. 3.1. MN Attaching Procedure Figure 2 gives the procedure when a MN newly attaches to an AR in an EMD. When a MN attaches to the AR just after its power-on, the MN first starts a link layer association process with AR. In the real deployment, other link layer devices such as access points may be used between AR and MN, in this case MN directly associates with an AP; and then AP will send this association event to AR and/or AR will actively sense this event. For example, the multiple 802.11 access points are interconnected by means of a distribution system - typically an Ethernet which an AR attaches to. When the MN associates with one of the APs, a layer-2 update frame is broadcasted in order to register the mobile node's current location with all bridges and switches in the distribution system. And the AR can learn those events at the same time. The association process is radio technology specific, which is beyond the scope of this draft. To make the discussion clearer, we just say that MN directly does association/de- association/re-associations with AR in the following. And we assume that when those association/re-association/de-association/ events are accomplished, AR is able to recognize them and know the peer link layer ID (for example, if the 802.11 technology is adopted, the link layer ID is MAC address of the mobile node's wireless interface). We will use MN-ID to denote the mobile node's ID. After the link layer association process is finished, MN will try to acquire its IP address through a conventional mechanism, such as stateless [7] or stateful configuration [8] via the attaching AR. On the network side, the AR will recognize this attaching and know the mapping of MN's IP address (MN-IP) and its MN-ID. For stateless configuration, AR can learn MN's IP address through many ways such as Router Solicitation, Neighbor Solicitation for Duplicated Address Detection (DAD) and so on. If stateful IP address configuration is used, AR acts as DHCP relay between DHCP server and MN, so it can know MN-IP and MN-ID naturally. The default route/gateway in MN is set to be the same default router/gateway of this EMD. Thus, when MN moves among different ARs, the layer 3 configurations, including its IP address and the default router, will always keep unchanged. H. Wang Expires October 10, 2006 [Page 5] Internet-Draft NETLMM Protocol April 2006 After the MN-IP is configured, AR1 takes that the MN has connected to it. Then AR1 sends a Location Registration Request (LR Req) message to the EMAP within the EMD. The message includes the MN's identifier (MN-ID), the MN's IP address (MN-IP) and the AR's IP address (AR-IP). And then, AR1 creates a cache entry of "Local Registered MN List (LR List)". The cache entry includes mapping among the MN-ID, the MN-IP and the EMAP's address, which makes the AR1 know which MN is attaching to it. When the EMAP receives the LR Req message, the EMAP creates a cache entry of mapping between the MN's IP address and AR1's address, which is called "Location Registration Cache (LR Cache)" in this document. And then, the EMAP sends a Location Registration Acknowledgement (LR Ack) back to AR1. After the LR Req/Ack exchange, the EMAP and AR1 establish a bi- directional tunnel between the EMAP and AR1. The tunnel is used for forwarding packets from/to the MN, and enables MN to visit the Internet through this EMD. But the intra EMD communication will not go through EMAP (refer to next section 3.2). MN AR1 EMAP | | | Link layer association | | |----------------->| {AR1 gets MN-ID} | Configure IP address | | |<---------------->| {AR1 gets MN-IP} | | | | | | | | Location Registration Request | |-------------------->| | |(MN-ID, MN-IP, AR1-IP) | | | | Location Registration Acknowledgement | |<--------------------| | | | | | | Figure 2 : Attachment procedure 3.2. Communication Initialization Procedure If MN wants to send packets to a CN outside of his EMD (i.e. CN and MN have different IP subnet prefix), MN will send the packets to its default router - the EMD default router/gateway. When MN sends Neighbor Solicitation (IPv6) or ARP Request (IPv4) for the default router/gateway, the attaching AR will reply to it as to cheat the MN H. Wang Expires October 10, 2006 [Page 6] Internet-Draft NETLMM Protocol April 2006 that it is the default router. Then AR will forward the intercepted packets via the bi-tunnel to the real default router of this EMD, normally, the EMAP. EMAP, acting the gateway of this EMD, will further forward the packets to external network. If CN and MN are in the same EMD, there will be a little difference. Figure 3 denotes the basic process. Since MN and CN have the same IP subnet prefix, MN will send Neighbor Solicitation (IPv6) or ARP Request (IPv4) message to resolve the link layer address of CN before sending the real data packets. On receiving such messages, the attaching AR (AR1) will check its Local Registered MN List to see if he has the binding information for this CN-IP. If it has no entry with this CN-IP, AR1 will send a CN Location Query message to EMAP with the key of CN-IP. On receiving this CN Location Query message, EMAP will look up its local Location Registration Cache and return back the current attaching AR-IP (AR2) of the CN-IP via a CN Location Reply message. Then AR1 gets the AR2-IP, and it sends Tunnel Setup Request message to AR2 with the information of "MN-IP, AR1-IP, CN-IP, AR2-IP". Optionally, AR2 will send a Tunnel Built Acknowledgement message back to AR1. After this procedure, a bi-tunnel between AR1 and AR2 is built up. AR1 and AR2 sends reply to MN's Neighbor Solicitation or ARP request, and then intercept the packets destined to CN and MN respectively. And thus MN can build data communication with CN via the bi-tunnel between AR1 and AR2. MN AR1 EMAP AR2 CN | | | | | |-------->| {MN sends Neighbor Solicitation message} | | | | | | | CN Location Query (CN-IP) | | | |------------->| | | | CN Location Reply (CN-IP, AR2-IP)| | | |<-------------| | | | Tunnel Setup Request (MN-IP, AR1-IP, CN-IP, AR2-IP) | |---------------------------->| | | Tunnel Built Acknowledgement | | | |<----------------------------| | | | | | |<~~~~~~~>|<===========================>|<~~~~~~~~~~~>| | | | | Figure 3 : Communication process when MN & CN are in the same EMD 3.3. Fast Handover Procedure NETLMM implements a neighbor AR information assisted fast handover scheme. First, neighboring AR can build neighbor information with H. Wang Expires October 10, 2006 [Page 7] Internet-Draft NETLMM Protocol April 2006 each other through other methods such as neighbor information broadcast or CARD protocols [11]. How to build the neighborhood relationship will not be discussed in this draft. The entire neighbor ARs are considered to be the possible candidate ARs when a MN moves out of current AR. By utilizing the neighbor AR information, NETLMM can achieve a very fast and smooth handover to fit the requirements of most real-time and interactive multimedia applications. The procedure of handover is shown in Figure 4 and Figure 5. Figure 4 gives the scenario when CN is outside the EMD, while Figure 5 depicts the scenario when CN is in the same EMD as MN. The operations for both scenarios can be combined together as seen in section 4 - protocol specification. Neighbor MN AR2 AR1 EMAP ARs | | {Link layer de-association} | | 0<-------------- X ------------>|{AR1 gets the MN-ID} | | | | |{AR1 starts to buffer data} | | | MN Movement Notification & MN's context| | | |<--------------------|---------------------------->| | | (MN-ID, MN-IP, AR1-IP) | | | | | | | 0-------->|{Link layer (re-)association} | | | |{AR2 gets the MN-ID} | | | | | | | | | | MN Fast Handover Notification (MN-ID, MN-IP, AR2-IP) | |-------------------->| | | | | Buffered data | | | |<~~~~~~~~|<====================| | | | | | | | | | MN Location Update Request (AR2-IP, MN-IP)| | | |------------------------------------------>| | | | | MN Location Update | | | | |<--------------------| | | | | (MN-ID, MN-IP) | | | | | | | | | Location Registration Acknowledgement | | | |<------------------------------------------| | | | | | | |<~~~~~~~>|<=========================================>| | Figure 4 : Handover procedure (1) Figure 4 gives the handover procedure when the MN moves from AR1 to AR2. First, MN performs link layer de-association with AR1. AR1 immediately recognizes this de-association and knows the MN-ID. Then H. Wang Expires October 10, 2006 [Page 8] Internet-Draft NETLMM Protocol April 2006 AR1 starts to buffer the packets destined to MN-IP (MN-ID), and sends a MN Movement Notification message and MN's context to its neighboring ARs, containing the MN-ID and MN-IP. At the same time, MN's movement causes its link layer do re-associations with new AR (say, AR2). Once the re-association completes, AR2 recognizes the new attachment with the MN-ID. Since AR2 has already received a MN Movement Notification message with this MN-ID, AR2 knows this MN has moved to its service coverage area and is not a new joiner for the EMD. AR2 sends a MN Fast Handover Notification message to AR1, and also a MN Location Update Request to EMAP as described in section 3.1. On receiving the MN Fast Handover Notification message, AR1 will first forward the buffered packets to AR2 (and then the packets will be forwarded to MN). Before the new data path between EMAP and AR has been setup, AR1 will keep forwarding the packets destined to MN-IP (MN-ID) as to keep the handover packet lossless. On the other hand, once EMAP receives the MN Location Update Request message, EMAP will look up its "Location Registration Cache" and updates the Location Registration Cache with the new AR-IP for this MN-IP and build new bi-tunnel between EMAP and AR2 to forward data from/to MN-IP. After tunnel is setup, EMAP will send a MN Location Update message to AR1 to update the "Local Registered MN List" in AR1 and the tunnel between AR1 and EMAP for this MN will be removed. Thus the handover process completes. Figure 5 gives the handover procedure when the communication is between two MN inside the same EMD. The basic process is the same. After the detection of MN-ID's link layer de-association, AR1 performs the same as described in Figure 4: buffer the packets destined to MN-IP (MN-ID), and sends a MN Movement Notification message and MN's context to its neighboring ARs. Also when AR2 detects the link layer attachment of MN-ID, it performs the same: sends a MN Fast Handover Notification message to AR1, and a MN Location Update Request to EMAP. On one hand, EMAP deals with this MN Location Update Request message the same way as in Figure 4. On the other hand, on receiving the MN Fast Handover Notification message, AR1 not only forwards the buffered data to AR2, but also sends a Tunnel Update Request message to AR3 (CN is attaching to AR3) containing the MN-IP, AR1-IP, CN-IP and AR2-IP. AR3 acts to this Tunnel Update Request message by sending a Tunnel Setup Request message to AR2 with AR3-IP, CN-IP, AR2-IP and MN-IP. AR2 will return a Tunnel Built Acknowledgement message to AR3. On receiving the Tunnel Built Acknowledgement message from AR2, AR3 will remove the old bi-tunnel setting between AR3 and AR1, and then send a Tunnel Remove message to notify AR1 to remove the related bi-tunnel between AR1 and AR3. Thus the new bi-tunnel between AR2 and AR3 is built to forward packets between MN and CN. And the whole handover process completes. H. Wang Expires October 10, 2006 [Page 9] Internet-Draft NETLMM Protocol April 2006 When the procedure which a MN detaches from an EMD such as power-off happens, an EMAP and an AR should delete the cache entry and the associated tunnel for the MN. The detail of the detach procedure is undefined in this document now. But the AR may send the EMAP a message for deletion of the cache entry or the EMAP and the AR may have a lifetime in each cache entry. MN AR2 AR1 EMAP AR3 CN | | | | | | |Data Packet | | | | | |<~~~~~~~~~~~~~~~~~~~~~~~~>|<=========================>|<~~~~~~~~~~>| | | | | | | 0 ---------X-------------->|{Link layer de-association,AR1 gets MN-ID} | | |{AR1 starts to buffer data}| | | | | | | | | |< ---------- |MN movement notification & MN's context | | | | | | | | {Link layer (re-)association with AR2; AR2 gets MN-ID} | 0----------->| | | | | | MN Fast Handover Notification (MN-ID, MN-IP, AR2-IP) | | |------------>| | | | | | MN Location Update Request (AR2-IP, MN-IP) | | |-------------------------->| | | | | | | | | | |Buffered data| | | | |<~~~~~~~~~~~|<============| | | | | | | | | | | | | Tunnel Update Request | | | | |-------------------------->| | | | | (MN-IP, AR2-IP, AR3-IP, CN-IP) | | | | | | | | | Tunnel Setup Request (AR3-IP, CN-IP, AR2-IP, MN-IP) | | |<----------------------------------------| | | | | | | | | Tunnel Built Acknowledgement (AR3-IP, CN-IP, AR2-IP, MN-IP) | | |---------------------------------------->| | | | | | | | | Tunnel Remove Notification (AR3-IP, CN-IP, AR1-IP, MN-IP) | | | |<--------------------------| | | | | | | | |Data Packet | | | | | |<~~~~~~~~~~>|<=======================================>|<~~~~~~~~~~>| Figure 5 : Handover procedure (2) H. Wang Expires October 10, 2006 [Page 10] Internet-Draft NETLMM Protocol April 2006 4. Protocol Specification As described in the previous sections, the entities that are introduced in NETLMM protocol are the Access Router (AR) and the Edge Mobility Anchor Point (EMAP): the detailed operation of both of them is described in following sections. Before that, the conceptual data structures that AR and EMAP need to implement are described. 4.1. Conceptual Data Structures The conceptual data structures used in this protocol are the following. - MN Location Registration Cache (LR Cache) - MN Location Registration List (LR List) LR Cache keeps the bindings between the MN and the AR where the MN attaches to for each MH, which is maintained by the EMAP. One LR Cache entry contains the following fields: - The Identifier which identifies a MN (MN-ID). In this protocol, link layer specific ID such as MAC address is assumed to be the MN-ID. - The IP address of the MN (MN-IP). - The IP address of the AR where the MN is attaching to. (AR-IP) The LR List is maintained in each AR, which records all the MH that attaches to this AR. Each LR List entry contains the following fields: MN-ID, MN-IP, EMAP-IP (the EMAP the MN location is registered). The LR List can be seen as a subset of the LR Cache in EMAP. 4.2. Access Router Operation All ARs within an EMD send Router Advertisement which includes the same prefix as the EMD subnet prefix. Also the AR advertise the EMAP or the gateway of this EMD to be the default router for the MN, which allows no any L3 change to the MN (IP address and the default router) when it moves among different ARs. An AR sends a MN Location Registration Request (LR Req) to an EMAP whenever a new MN attaches on its link. The LR Req includes the MN-ID, MN-IP and AR-IP. When sending the LR Req to the EMAP, the AR creates the corresponding LR List entry. H. Wang Expires October 10, 2006 [Page 11] Internet-Draft NETLMM Protocol April 2006 When the AR receives a Location Registration Acknowledgement with a status code indicating successful registration, it sets up a bi- directional tunnel with EMAP for the MN. When the AR receives a LR Ack with a status code indicating an error, it must remove the LR List entry. In particular, if the error code indicates DAD failed, it must notify the MN that the IP address currently in use is no longer valid. When AR catches the Neighbor Solicitation (IPv6) or ARP Request message from MN (IPv4), it must send a CN Location Query message to EMAP with the CN-IP embedded. And afterwards, when it receives the CN Location Reply from the EMAP with a successful code, AR (AR1) can know the AR (AR2) which CN is now attaching to. Then AR1 sends a Tunnel Setup Request message to AR2 containing (MN-IP, AR1-IP, CN-IP, AR2-IP). When the AR receives a Tunnel Setup Request from another AR, it must setup a tunnel using the endpoint information (MN-IP, CN-IP, AR1-IP, and AR2-IP) contained in the request message, and then send back a Tunnel Built Acknowledgement. Traffic from/to the MN goes through a bi-directional tunnel between the AR and the EMAP, or between the two ARs. So, the AR encapsulates and decapsultes packets from/to the MN. When AR1 receives a link layer de-association event from MN-ID, it must buffer the packets that are destined to MN-ID and send MN Movement Notification message to all of its neighboring ARs containing MN-ID, MN-IP and AR1-IP. When AR2 receives a link layer (re-)association event from MN-ID, it looks up local MN movement notification list. If the MN-ID is notified earlier from AR1, it must send MN Fast Handover Notification message (MN-ID, MN-IP, AR2-IP) to AR1. At the same time, it must send MN Location Registration Request to EMAP with (AR2-IP,MN-IP). On receiving a MN Fast Handover Notification message, AR1 must forward the buffered data to AR2. And at the same time, AR1 must check to see if there exists bi-tunnel with other ARs for this MN-ID. If this kind of bi-tunnels exists, AR1 must send Tunnel Update Request message, containing the new endpoint (say, AR2) of this tunnel (MN-IP, AR2-IP, AR3-IP, CN-IP), to AR3 that is the other endpoint of this bi-tunnel. On receiving a Tunnel Update Request message from the peer endpoint of a bi-tunnel, AR (AR3) must sends a Tunnel Setup Request message to H. Wang Expires October 10, 2006 [Page 12] Internet-Draft NETLMM Protocol April 2006 AR2. On receiving Tunnel Setup Request message, AR2 must setup bi- tunnel with AR3 to forward packet from MN-IP and CN-IP, and send back a Tunnel Built Acknowledgement message to AR3. When AR3 gets this acknowledgement message, it must remove the current bi-tunnel with AR1 and send a Tunnel Remove Notification to AR1 which lets AR1 to remove the related tunnel setting. On receiving a MN Location Update message from EMAP, AR must update its local LR List and remove the related bi-tunnel setting. 4.3. Edge Mobility Anchor Point Operation When an EMAP receives a MN Location Registration Request including MN-IP, MN-ID and AR-IP, it must verify the MN-IP is unique or not in the EMD by means of searching LR Caches using the MN-ID and/or MN-IP as a key. If the LR Req message is valid, EMAP must create a new entry in its LR Cache for this MN or update its existing LR Cache entry, if the entry already exists. If MN obtains its IP address through stateless IPv6 address configuration, and unless this EMAP already has a LR Cache entry for the MN, the EMAP must lookup to see if there is already a same IP address in the LR Caches before returning the LR Ack. Since the LR Caches in EMAP contain all the MN's information (MAC-ID, MN-IP, AR- IP), this lookup operation ensures that no other node is using the same IP address inside this EMD and the Duplicate Address Detection process can be skipped. If this lookup returns that there is collision for the MN's address, the EMAP must send the AR a LR Ack with a status code indicating Duplicate Address Detection failure. If MN's IP address is configured through stateful address configuration protocols by a center DHCP server, the above DAD procedure can be removed. In fact, we can put the DHCP server inside EMAP. The EMAP sends the AR a LR Ack with successful code if all checks performed after receiving the LR Req have been successful. On receiving the Location Update Request message from ARs, EMAP just updates the LR cache, removes its local tunnel settings related to the old AR for this MN and sends a MN Location Update message to the AR in the cache to remove the cache entry on the AR. On receiving the Location Query message (MN-IP) from ARs, EMAP performs a lookup of the LR Caches with the key of MN-IP. If it finds an entry for this MN-IP, EMAP returns a MN Location Reply message to the AR containing the MH-IP and AR-IP; if it fails to find the related entry, it returns a MN Location Reply message to the AR containing a failure code. H. Wang Expires October 10, 2006 [Page 13] Internet-Draft NETLMM Protocol April 2006 Normally, EMAP is embedded in the gateway, so the bi-tunnel between AR and EMAP is setup to enable MN to visit Internet. The EMAP should de-capsulate packets from the MN to the Internet and encapsulates packets from the Internet to the MN on the other hand. 5. Security Considerations Since NETLMM provides mobility support without any extra signaling between the mobile node and network, it requires no extra security association between the mobile node and the network entity that protect such kind of signaling messages. Also removing mobile node involvement in localized mobility management limits the possibility of DoS attacks on network infrastructural elements [6]. The security problem between the entities among NETLMM network side is to protect the NETLMM signaling messages. IPSec can be applied here to guarantee the messages. The security associations between NETLMM entities can be built through static configuration or from other infrastructures, which is currently not analyzed in this draft. 6. IANA Considerations This document will register with the IANA the protocol parameters set; details of these registrations will appear in a later version of the draft. 7. Acknowledgments The authors would like to thank Jinling Wang, Yichuan Wu, Yingang Yuan for their reviews and comments on this document. 8. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Aboba, et. al., B., "The Network Access Identifier", RFC2486, Jan. 1999. [4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. H. Wang Expires October 10, 2006 [Page 14] Internet-Draft NETLMM Protocol April 2006 [5] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G., Liebsch, M., "Problem Statement for IP Local Mobility", Internet-Draft, draft-ietf-netlmm-nohost-ps-00, Feburary, 2006, working in progress. [6] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G., Liebsch, M., "Requirements and Gap Analysis for IP Local Mobility", Internet-Draft, draft-ietf-netlmm-nohost-req-00, Feburary, 2006, working in progress. [7] Thomson, S., Narten, T., Jinmei, T., "IPv6 Stateless Address Autoconfiguration", Internet-Draft, draft-ietf-ipv6-rfc2462bis- 08, May 2005. [8] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., Carney, M., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [9] Moskowitz, R., Nikander, P., Jokela, P., and Henderson, T., "Host Identity Protocol", Internet Draft, work in progress. [10] Kivinen, T., and Tschopfening, H., "Design of the MOBIKE Protocol", Internet Draft, work in progress. [11] Marco Liebsch, et al. "Candidate Access Router Discovery", Internet Draft, draft-ietf-seamoby-card-protocol-08.txt, work in progress H. Wang Expires October 10, 2006 [Page 15] Internet-Draft NETLMM Protocol April 2006 Author's Addresses Hui Wang NEC Laboratories China 11/F, Bldg.A, Innovation Plaza, Tsinghua Science Park No.1, Zhong Guan Chun East Road, Beijing China Phone: +81 10 6270 5962 ext# 323 Email: wanghui@research.nec.com.cn Yanfeng Zhang NEC Laboratories China 11/F, Bldg.A, Innovation Plaza, Tsinghua Science Park No.1, Zhong Guan Chun East Road, Beijing China Phone: +81 10 6270 5962 ext# 210 Email: zhangyanfeng@research.nec.com.cn Yong Xia NEC Laboratories China 11/F, Bldg.A, Innovation Plaza, Tsinghua Science Park No.1, Zhong Guan Chun East Road, Beijing China Phone: +81 10 6270 5962 ext# 320 Email: xiayong@research.nec.com.cn Comments are solicited and should be addressed to the working group's mailing list at netlmm@ngnet.it and/or the author(s) 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. H. Wang Expires October 10, 2006 [Page 16] Internet-Draft NETLMM Protocol April 2006 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. H. Wang Expires October 10, 2006 [Page 17]