Internet DRAFT - draft-akiyoshi-netlmm-protocol

draft-akiyoshi-netlmm-protocol





   NETLMM                                                   I. Akiyoshi 
   Internet Draft                                            M. Liebsch 
   draft-akiyoshi-netlmm-protocol-00.txt                            NEC 
   Expires: April 2006                                     October 2005 
    
    
                            NETLMM Protocol 
                   draft-akiyoshi-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 April 17, 2006. 
 

Copyright Notice 

   Copyright (C) The Internet Society (2005). All Rights Reserved. 
    











 
 
I. Akiyoshi              Expires - April 2006                 [Page 1] 
Internet Draft             NETLMM Protocol               October 2005 
 
    
Abstract 
    
   This document specifies a network-based protocol which allows mobile 
   nodes to remain reachable while moving around a certain 
   administrative network called Edge Mobility Domain. This protocol 
   also allows mobile nodes to keep their IP address when the mobile 
   nodes move from one access router to another within the Edge Mobility 
   Domain. 
    
    
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...................................................3 
   2. Terminology....................................................3 
   3. Protocol Overview..............................................3 
   4. Protocol Specification.........................................6 
      4.1 Conceptual Data Structures.................................6 
      4.2 Access Router Operation....................................7 
      4.3 Edge Mobility Anchor Point Operation.......................7 
   Appendix A: Protocol Extensions...................................8 
   References.......................................................13 
   Author's Addresses...............................................14 
   Intellectual Property Statement..................................14 
   Disclaimer of Validity...........................................14 
   Copyright Statement..............................................15 
    
    















 
 
I. Akiyoshi              Expires - April 2006                 [Page 2] 
Internet Draft             NETLMM Protocol               October 2005 
 
 
1. Introduction 
    
   There have been a number of protocol proposals for terminal mobility 
   management such as MIPv6 [2], HIP [9] and MOBIKE [10]. Moreover there 
   is a strong requirement of a hierarchical configuration to such 
   mobility management schemes for achieving a world-wide IP-based 
   mobile network. Provisioning a hierarchical configuration for each 
   individual protocol makes a complex and expensive solution. Rather, 
   providing a unified local mobility management will make a simple and 
   inexpensive solution. 
    
   NETLMM, which is described in this document, is a network-based 
   localized mobility protocol for achieving such a simple solution. 
   This document mainly describes the basic configuration of NETLMM. An 
   advanced configuration is also described in the APPENDIX. 
    
2. Terminology 
    
   Access Router (AR) 
      A router in an Edge Mobility Domain, which registers the 
     association of a mobile node with its point of attachment to an 
     Edge Mobility Anchor Point and provides routing services to the 
     mobile node while registered. 
    
   Edge Mobility Anchor Point (EMAP) 
      A router in an Edge Mobility Domain, which maintains current 
     location for a mobile node when the mobile node is in an Edge 
     Mobility Domain and delivers packets to the mobile node. One or 
     more EMAPs can be deployed in an Edge Mobility Domain. 
    
   Edge Mobility Domain (EMD) 
      An administrative network composed of Access Routers and Edge 
     Mobility Anchor Points. 
    
    
3. Protocol Overview 
    
   NETLMM protocol is a network-based localized mobility management 
   protocol operating within an Edge Mobility Domain (EMD). Each AR 
   advertises the same prefix related to the EMAP's subnet, so that a 
   mobile node (MN) keeps its IP address when it moves from an AR to 
   another within an EMD. 
   This section describes an overview of NETLMM protocol basic 
   configuration. Within the scope of basic configuration of this 
   protocol, it is assumed that a single EMAP exists within a single EMD. 
   The architecture model is shown in Figure 1. 
    
   The EMAP manages mapping of the MN's address to the AR's address 
   where the MN connects. The mapping is used to manage a bi-directional 
 
 
I. Akiyoshi              Expires - April 2006                 [Page 3] 
Internet Draft             NETLMM Protocol               October 2005 
 
   tunnel between a particular MN's current AR and its EMAP for 
   forwarding packets from a correspondent node (CN) to the MN. 
    
                     +----------------------+ 
                     | Edge Mobility Domain |  +----------+ 
                     |                      |  |          | 
            +----+   |  +----+     +------+ |  | External |   +----+ 
            | MN |-+----| AR |--+--| EMAP |-------------------| CN | 
            +----+ | |  +----+  |  +------+ |  | Network  |   +----+ 
                   | |          |           |  |          | 
            +----+ | |  +----+  |           |  +----------+ 
            | MN |-+ |  | AR |--+           | 
            +----+   |  +----+              | 
                     |                      | 
                     +----------------------+ 
    
                       Figure 1: Architecture Model 
    
    
   The procedure when a MN visits an EMD is shown in Figure 2. When a 
   MN attaches to the EMD just after its power-on, the MN first acquires 
   its IP address through a conventional mechanism, such as stateless 
   [7] or stateful configuration [8] via an AR. Then the MN sends attach 
   message including the MN's IP address (MN-IP) to the AR (AR1). The 
   message may be related to Neighbor Discovery Protocol [4] such as 
   Router Solicitation, Neighbor Solicitation for Duplicated Address 
   Detection (DAD) and so on. 
    
   Receiving the attach message, AR1 detects 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). A MN-ID is needed to identify each MN by an 
   identifier except the MN's IP address, since all ARs have the same 
   prefix as EMAP's subnet. And then, AR1 creates a cache entry of 
   "Location Registration List (LR List)". The cache entry includes 
   mapping between the MN's IP address and the EMAP's address. 
    
   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 then EMAP also performs the 
   mechanism for intercepting any packets addressed to the MN's IP 
   address such as proxy Neighbor Discovery [4]. 
    
 
 
I. Akiyoshi              Expires - April 2006                 [Page 4] 
Internet Draft             NETLMM Protocol               October 2005 
 
   The procedure of handover is shown in Figure 3. When the MN moves 
   from AR1 to AR2, AR2 performs in the same way as AR1 in Figure 2. 
   Receiving a LR Req message, the EMAP verifies if it has already had 
   the LR cache entry for the MN or not. If the EMAP already has the 
   entry and the AR address in the entry is different from the AR 
   address in the LR Req message which the EMAP receives, the EMAP sends 
   a Location Deregistration Request (LD Req) message to AR1 to delete 
   the LR List entry on the AR1. Receiving the LD Req message, the AR1 
   deletes the LR List entry and sends a Location Deregistration 
   Acknowledgement (LD Ack) to the EMAP. 
    
   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                AR1                  EMAP 
               |                  |                     | 
               |      Attach      |                     | 
               |----------------->|                     | 
               |     (MN-IP)      |                     | 
               |                  |                     | 
               |              Location Registration Request 
               |                  |-------------------->| 
               |                  |(MN-ID, MN-IP, AR1-IP) 
               |                  |                     | 
               |          Location Registration Acknowledgement 
               |                  |<--------------------| 
               |                  |                     | 
               |                  |                     | 
    
                      Figure 2: Attachment procedure 
    















 
 
I. Akiyoshi              Expires - April 2006                 [Page 5] 
Internet Draft             NETLMM Protocol               October 2005 
 
    
   MN                AR2                   AR1                   EMAP 
   |                  |                     |                     | 
   |      Attach      |                     |                     | 
   |----------------->|                     |                     | 
   |     (MN-IP)      |                     |                     | 
   |                  |                     |                     | 
   |                  |       Location Registration Request       | 
   |                  |------------------------------------------>| 
   |                  |           (MN-ID, MN-IP, AR2-IP)          | 
   |                  |                     |                     | 
   |                  |   Location Registration Acknowledgement   | 
   |                  |<------------------------------------------| 
   |                  |                     |                     | 
   |                  |                     |                     | 
   |                  |                  Location Deregistration Request 
   |                  |                     |<--------------------| 
   |                  |                     |   (MN-ID, MN-IP)    | 
   |                  |                     |                     | 
   |                  |          Location Deregistration Acknowledgement 
   |                  |                     |-------------------->| 
   |                  |                     |                     | 
    
                       Figure 3: Handover procedure 
    
4. Protocol Specification 
 
   This section provides the detailed description of the protocol. As 
   mentioned in the overview section, the entities that are introduced 
   in this document 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. 
    
      - Location Registration Cache (LR Cache) 
      - Location Registration List (LR List) 
    
   An EMAP maintains a LR Cache of bindings between the MN and the AR 
   where the MN connects. A separate LR Cache entry should be maintained 
   for each MN. Each LR Cache entry contains the following fields:  
    
      - The Identifier which identifies a MN. Network Access Identifier 
       (NAI) [3] or L2-specific ID such as MAC address is assumed. 
    
 
 
I. Akiyoshi              Expires - April 2006                 [Page 6] 
Internet Draft             NETLMM Protocol               October 2005 
 
      - The IP address of the MN. 
    
      - The IP address of the AR where the MN is located. This is 
        updated based on LR Req message received by the AR. 
    
   An AR maintains a LR List. A separate LR List entry should be 
   maintained for each MN. Each LR List entry contains the following 
   fields: 
                                                    
      - The Identifier which identifies a MN. Network Access Identifier 
       (NAI) [3] or L2-specific ID such as MAC address is assumed. 
    
      - The IP address of the MN. 
    
      - The IP address of AR where the MN is located. 
    
      - The IP address of the node to which a LR Req was sent. 
    
    
4.2. Access Router Operation 
    
   All ARs within an EMD controlled by a singular EMAP sends Router 
   Advertisement which includes the same prefix as the EMAP's subnet. 
   Also the AR must be a default router for the MN. 
    
   An AR sends a LR Req to an EMAP whenever a new MN attaches on its 
   link. The LR Req includes the identifier of the MN, IP address of the 
   MN and IP address of the AR itself. When sending the LR Req to the 
   EMAP, the AR creates the corresponding LR List entry. 
    
   When the AR receives a LR Ack with a status code indicating 
   successful registration, it sets up a bi-directional tunnel for the 
   MN. The endpoints of the tunnel are the AR and the EMAP. 
    
   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 the AR receives a LD Req from the EMAP, it must remove the LR 
   List entry for the MN. And then it sends a LD Ack back to the EMAP. 
    
   Traffic from/to the MN goes through a bi-directional tunnel between 
   the AR and the EMAP. So, the AR encapsulates packets from the MN to 
   the CN and decapsulates packets from the CN to the MN on the other 
   hand. 
    
    
4.3. Edge Mobility Anchor Point Operation 
    
 
 
I. Akiyoshi              Expires - April 2006                 [Page 7] 
Internet Draft             NETLMM Protocol               October 2005 
 
   When an EMAP receives a LR Req including an identifier and an IP 
   address of a MN, it must verify the MN's IP address is unique or not 
   in the EMD by means of searching LR Caches using the identifier and 
   the IP address of the MN as a key. 
    
   If the LR Req message is valid, the EMAP must then create a new 
   entry in its LR Cache for this MN or update its existing LR Cache 
   entry, if the entry already exists. 
    
   Unless this EMAP already has a LR Cache entry for the MN, the EMAP 
   must perform Duplicate Address Detection on the EMAP's link before 
   returning the LR Ack. This ensures that no other node on the link was 
   using the MN's IP address when the LR Req arrived. If this Duplicate 
   Address Detection fails for the MN's address, then the EMAP must send 
   the AR a LR Ack with a status code indicating Duplicate Address 
   Detection failure. 
    
   If all checks performed after receiving the LR Req have been 
   successful, the EMAP sends the AR a LR Ack with successful code. 
    
   If the EMAP already has the LR Cache entry and the AR address in the 
   entry is different from the AR address in the LR Req message which 
   the EMAP receives, the EMAP sends a LD Req message to the AR in the 
   cache to delete the cache entry on the AR after sending a LR Ack. 
    
   Traffic from/to the MN goes through a bi-directional tunnel between 
   the AR and the EMAP. So, the EMAP decapsulates packets from the MN to 
   the CN and encapsulates packets from the CN to the MN on the other 
   hand. 
    
    
Appendix A: Protocol Extensions 
    
   In this section, support for plural EMAPs and route optimization is 
   described as protocol extensions. 
    
   When an EMD is a large network such as cellular network, plural 
   EMAPs and route optimization within a single EMD may be required from 
   the viewpoint of load sharing and efficient use of wired network 
   resources. In this case, all EMAPs should be on the same link to 
   preserve location privacy. So, all ARs within the EMD to advertise 
   EMAPs prefix as well as above basic description. 
    
   This extension requires the MN to send the message to an AR for 
   handover. Since context transfer between ARs is needed to take over 
   some information of the MN, such as the EMAP address which manages 
   the MN and the AR address where a CN connects, when the MN 
   communicating with the CN on the optimized routing path moves from 
   one router to another. 
    
 
 
I. Akiyoshi              Expires - April 2006                 [Page 8] 
Internet Draft             NETLMM Protocol               October 2005 
 
   Attachment procedure is shown in Figure 4. AR1 performs almost in 
   the same way as in Figure 2. The difference is that AR1 performs EMAP 
   discovery procedure to get an EMAP's IP address for the MN, when AR1 
   detects the attachment. The mechanism is that AR1 obtains the EMAP 
   address by requesting from a control server which manages states of 
   EMAPs or performing similar procedure as Dynamic Home Agent Discovery 
   procedure of MIPv6[2]. After EMAP discovery procedure, the AR1 sends 
   LR Req to the MN's EMAP (EMAP1). 
    
   EMAP1 operation is the same as the operation described in Figure 2. 
   When EMAP1 performs DAD on the local link representing the EMAPs 
   prefix, other EMAPs should listen to associated solicitations and 
   perform kind of Proxy DAD for the registered MN. 
    
                 MN                AR1                  EMAP1 
                 |                  |                     | 
                 |      Attach      |                     | 
                 |----------------->|                     | 
                 |     (MN-IP)      |                     | 
                 |                  |                     | 
                 |         +-----------------+            | 
                 |         |  EMAP Discovery |            | 
                 |         +-----------------+            | 
                 |                  |                     | 
                 |              Location Registration Request 
                 |                  |-------------------->| 
                 |                  |(MN-ID, MN-IP, AR1-IP) 
                 |                  |                     | 
                 |          Location Registration Acknowledgement 
                 |                  |<--------------------| 
                 |                  |                     | 
                 |                  |                     | 
    
                      Figure 4: Attachment procedure 
    
    
   Route optimization procedure is shown in Figure 5. The arrows with a 
   wiggly line and a dual line in this figure indicate original data 
   flows and tunneled data flows respectively. When AR1 receives a data 
   packet from the MN to a CN attached to AR2 within the same EMD, AR1 
   verifies if the destination address has a same prefix as the EMAPs 
   subnet. If the destination address has the same prefix, AR1 starts 
   route optimization procedure. Otherwise AR1 performs packet 
   processing operation described in subsection 4.2. 
    
   AR1 tries to get the EMAP which manages the CN to inquire an AR 
   address where the CN attaches. The detailed mechanism is still 
   undefined, but AR1 may inquire it from EMAPs. The key for the inquiry 
   is the CN's IP address. And then, the AR1 sends an AR query message 
   to the EMAP2. The message includes the CN's IP address. 
 
 
I. Akiyoshi              Expires - April 2006                 [Page 9] 
Internet Draft             NETLMM Protocol               October 2005 
 
    
   Receiving the AR query message, EMAP2 searches an AR address where 
   the CN attached. The key for the search is the CN's IP address 
   included in the AR query message. And then EMAP2 sends a Reply 
   message to notify AR1 of the AR address where the CN attaches. 
    
   AR1 sends a LR Req to AR2 after getting the AR address where the CN 
   attaches. The message is used to notify AR2 of the mapping between 
   the MN and AR1 where the MN attaches. The LR Req may not include the 
   MN-ID. And then, AR1 creates a LR List entry for route optimization. 
    
   Receiving the LR Req message, AR2 verifies if the LR Cache entry for 
   route optimization already exists or not. Unless AR2 already has the 
   entry, AR2 creates a new entry in its LR Cache entry for it. If AR2 
   already has the entry, AR2 updates the entry. If necessary, AR2 may 
   send a LR Ack message to AR1. 
    
   After the route optimization procedure, AR2 tunnels data packets, 
   whose source and destination are IP address of the CN and the MN 
   respectively, to AR1 directly. 
    
   MN          AR1          EMAP1         EMAP2          AR2          CN 
   |            |             |             |             |            | 
   |Data Packet |             |             |             |            | 
   |~~~~~~~~~~~>|============>|~~~~~~~~~~~~>|============>|~~~~~~~~~~~>| 
   |            |             |             |             |            | 
   |            |          AR Query         |             |            | 
   |            |-------------------------->|             |            | 
   |            |          (CN-IP)          |             |            | 
   |            |             |             |             |            | 
   |            |           Reply           |             |            | 
   |            |<--------------------------|             |            | 
   |            |      (CN-IP, AR2-IP)      |             |            | 
   |            |             |             |             |            | 
   |            |       Location Registration Request     |            | 
   |            |---------------------------------------->|            | 
   |            |             (MN-IP, AR1-IP)             |            | 
   |            |             |             |             |            | 
   |         Location Registration Acknowledgement (If necessary)      | 
   |            |<----------------------------------------|            | 
   |            |             |             |             |            | 
   |Data Packet |             |             |             |            | 
   |<~~~~~~~~~~~|<========================================|<~~~~~~~~~~~| 
   |            |             |             |             |            | 
   |            |             |             |             |            | 
    
                  Figure 5: Route Optimization procedure 
    
    

 
 
I. Akiyoshi              Expires - April 2006                [Page 10] 
Internet Draft             NETLMM Protocol               October 2005 
 
   Handover procedure is shown in Figure 6. When the MN moves from AR1 
   to AR3, the MN sends a handover message to AR2. The message should 
   include some information related to a previous AR, since the new AR 
   needs to take over some contexts related to the MN from the previous 
   AR. The context includes an EMAP address which manages the MN and an 
   AR address where the CN attaches at least. 
    
   Receiving the handover message, AR3 derives AR1 address from 
   previous AR information included in the handover message. And then, 
   AR3 sends a Context Transfer Request message to AR1. 
    
   When AR1 receives the Context Transfer Request message, AR1 sends 
   EMAP1 address which manages the MN and AR2 address which the MN 
   communicates, if any. 
    
   Receiving the Context Transfer Acknowledgement message, AR3 creates 
   the LR List entry for the registration to EMAP1. If AR address is 
   transferred, AR3 also creates the LR List entry for the registration 
   to the AR. Then AR3 sends a LR Req message to EMAP1 to register the 
   MN's new location. 
    
   When EMAP1 receives the LR Req message, EMAP1 updates the LR Cache 
   entry and send a LR Ack message back to AR3. And then EMAP1 also 
   sends a LD Req message to AR1 to delete the cache entry on it. 
    
   If AR address is transferred from AR1 to AR3, the AR3 sends a LR Req 
   message to let AR2 update the entry in its LR Cache entry for it. 
   Updating the cache, AR2 may send a LR Ack message as the reply, if 
   necessary. 





















 
 
I. Akiyoshi              Expires - April 2006                [Page 11] 
Internet Draft             NETLMM Protocol               October 2005 
 
    
   MN          AR1           AR3          EMAP1          AR2          CN 
   |            |             |             |             |            | 
   |Data Packet |             |             |             |            | 
   |~~~~~~~~~~~>|========================================>|~~~~~~~~~~~>| 
   |            |             |             |             |            | 
   O Move to AR3|             |             |             |            | 
   |            |             |             |             |            | 
   |         Handover         |             |             |            | 
   |------------------------->|             |             |            | 
   (MN-ID or MN-IP, previous AR info)       |             |            | 
   |            |             |             |             |            | 
   |        Context Transfer Request        |             |            | 
   |            |<------------|             |             |            | 
   |            (MN-Id or MN-IP)            |             |            | 
   |            |             |             |             |            | 
   |    Context Transfer Acknowledgement    |             |            | 
   |            |------------>|             |             |            | 
   |           (EMAP1-IP, AR2-IP)           |             |            | 
   |            |             |             |             |            | 
   |            |       Location Registration Request     |            | 
   |            |             |------------>|             |            | 
   |            |          (MN-ID, MN-IP, AR3-IP)         |            | 
   |            |             |             |             |            | 
   |            |  Location Registration Acknowledgement  |            | 
   |            |             |<------------|             |            | 
   |            |             |             |             |            | 
   |            |             |             |             |            | 
   |           Location Deregistration Request            |            | 
   |            |<--------------------------|             |            | 
   |            |       (MN-ID, MN-IP)      |             |            | 
   |            |             |             |             |            | 
   |        Location Registration Acknowledgement         |            | 
   |            |-------------------------->|             |            | 
   |            |             |             |             |            | 
   |            |             |             |             |            | 
   |            |             Location Registration Request            | 
   |            |             |-------------------------->|            | 
   |            |             |      (MN-IP, AR3-IP)      |            | 
   |            |             |             |             |            | 
   |            |   Location Registration Acknowledgement (If necessary) 
   |            |             |<--------------------------|            | 
   |            |             |             |             |            | 
   |Data Packet |             |             |             |            | 
   |<~~~~~~~~~~~~~~~~~~~~~~~~~|<==========================|<~~~~~~~~~~~| 
   |            |             |             |             |            | 
   |            |             |             |             |            | 
    
                       Figure 6: Handover procedure 
    
 
 
I. Akiyoshi              Expires - April 2006                [Page 12] 
Internet Draft             NETLMM Protocol               October 2005 
 
    
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. 
 
  [5]    Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G., 
     Liebsch, M., "Problem Statement for IP Local Mobility", Internet-
     Draft, draft-kempf-netlmm-nohost-ps-00, June 2005. 
 
  [6]    Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G., 
     Liebsch, M., "Requirements and Gap Analysis for IP Local Mobility", 
     Internet-Draft, draft-kempf-netlmm-nohost-req-00, July 2005. 
 
  [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. 
    
    











 
 
I. Akiyoshi              Expires - April 2006                [Page 13] 
Internet Draft             NETLMM Protocol               October 2005 
 
Author's Addresses 
    
   Ippei Akiyoshi 
   NEC Corporation 
   1753, Shimonumabe, Nakahara-Ku, 
   Kawasaki, Kanagawa, 
   Japan 
   Phone: +81 44 396 2807 
   Email: i-akiyoshi@ah.jp.nec.com 
    
   Marco Liebsch   
   NEC Network Laboratories   
   Kurfuersten-Anlage 36  
   69115 Heidelberg   
   Germany   
   Phone: +49 6221-90511-46   
   Email: marco.liebsch@netlab.nec.de 
    
    
Intellectual Property Statement 

   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at 
   ietf-ipr@ietf.org. 
    
    
Disclaimer of Validity 

   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
 
 
I. Akiyoshi              Expires - April 2006                [Page 14] 
Internet Draft             NETLMM Protocol               October 2005 
 
   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 
    
 






































 
 
I. Akiyoshi              Expires - April 2006                [Page 15]