Goals for Network-Based Localized Mobility Management (NETLMM)
draft-ietf-netlmm-nohost-req-05

Internet Draft                                       J. Kempf, Editor 
  Document: draft-ietf-netlmm-nohost-req-05.txt        October, 2006 
  Expires: April, 2007                                  

      
      
        Goals for Network-based Localized Mobility Management (NETLMM) 
                    (draft-ietf-netlmm-nohost-req-05.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. 
      
  Contributors 
      
     Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and 
     Marco Liebsch all contributed major effort to this document. Their 
     names are not included in the authors' section due to the RFC 
     Editor's limit of 5 names. 
      
  Abstract 
   
     In this document, design goals for a network-based localized 
     mobility management (NETLMM) protocol are discussed.  
   
  Table of Contents 
   
     1.0  Introduction............................................2 
     2.0  NETLMM Functional Architecture..........................3 
     3.0  Goals for the NETLMM Protocol...........................3 
     4.0  IANA Considerations....................................10 
     5.0  Security Considerations................................11 
      
     Kempf, editor               Expires April, 2007       [Page 1] 

     Internet Draft              NETLMM Goals         October, 2006 
      
   
     6.0  Acknowledgements.......................................11 
     7.0  Author's Addresses.....................................11 
     8.0  Normative References...................................12 
     9.0  Informative References.................................12 
     10.0 IPR Statements.........................................13 
     11.0 Disclaimer of Validity.................................13 
     12.0 Copyright Notice.......................................13 
   
  1.0   Introduction 
         
     In [1], the basic problems that occur when a global mobility 
     protocol is used for managing local mobility are described, and two 
     currently used approaches to localized mobility management - the 
     host-based approach that is used by most IETF protocols, and the 
     proprietary WLAN switch approach used between WLAN switches in 
     different subnets - are examined. The conclusion from the problem 
     statement document is that none of the approaches has a complete 
     solution to the problem. While the WLAN switch approach is most 
     convenient for network operators and users because it requires no 
     software on the mobile node other than the standard drivers for 
     WiFi,  the  proprietary  nature  limits  interoperability  and  the 
     restriction to a single last hop link type and wired backhaul link 
     type restricts scalability. The IETF host-based protocols require 
     host software stack changes that may not be compatible with all 
     global mobility protocols, and also require specialized and complex 
     security   transactions   with   the   network   that   may   limit 
     deployability.  The  conclusion  was  that  a  localized  mobility 
     management protocol that was network based and required no software 
     on the host for localized mobility management is desirable. 
      
     This document develops a brief functional architecture and detailed 
     goals for a network-based localized mobility management protocol 
     (NETLMM). Section 2.0 describes the functional architecture of 
     NETLMM. In Section 3.0, a list of goals that are desirable in the 
     NETLMM  protocol  is  presented.  Section  4.0  concerns  IANA 
     considerations.   Section   5.0   briefly   outlines   security 
     considerations. More discussion of security can be found in the 
     threat analysis document [2]. 
      
  1.1 Terminology 
      
     Mobility terminology in this draft follows that in RFC 3753 [10] 
     and in [1]. In addition, the following terms are related to the 
     functional architecture described in Section 2.0: 
      
          Localized Mobility Management Domain 
      
            An Access Network in the sense defined in [1] in which 
            mobility is handled by the NETLMM protocol. 
      
          Mobile Access Gateway 
      
     Kempf, editor            Expires April, 2007            [Page 2] 

     Internet Draft              NETLMM Goals         October, 2006 
      
   
           
            A Mobile Access Gateway (MAG) is a functional network 
            element that terminates a specific edge link and tracks 
            mobile node IP level mobility between edge links, through 
            NETLMM signaling with the Localized Mobility Anchor. The MAG 
            also terminates host routed data traffic from the Localized 
            Mobility Anchor for mobile nodes currently located within 
            the edge link under the MAG's control, and forwards data 
            traffic from mobile nodes on the edge link under its control 
            to the Localized Mobility Anchor. 
           
          Local Mobility Anchor 
      
            A Local Mobility Anchor (LMA) is a router that maintains a 
            collection  of  host  routes  and  associated  forwarding 
            information for mobile nodes within a localized mobility 
            management domain under its control. Together with the MAGs 
            associated with it, the LMA uses the NETLMM protocol to 
            manage  IP  node  mobility  within  the  localized  mobility 
            management domain. Routing of mobile node data traffic is 
            anchored at the LMA as the mobile node moves around within 
            the localized mobility management domain. 
      
  2.0   NETLMM Functional Architecture 
      
     The NETLMM architecture consists of the following components. 
     Localized Mobility Anchors (LMAs) within the backbone network 
     maintain a collection of routes for individual mobile nodes within 
     the localized mobility management domain. The routes point to the 
     Mobile Access Gateways (MAGs) managing the links on which the 
     mobile nodes currently are located. Packets for a mobile node are 
     routed to and from the mobile node through tunnels between the LMA 
     and MAG. When a mobile node moves from one link to another, the MAG 
     sends a route update to the LMA. While some mobile node involvement 
     is necessary and expected for generic mobility functions such as 
     movement  detection  and  to  inform  the  MAG  about  mobile  node 
     movement, no specific mobile node to network protocol will be 
     required for localized mobility management itself. Host stack 
     involvement in mobility management is thereby limited to generic 
     mobility functions at the IP layer, and no specialized localized 
     mobility management software is required. 
      
      
  3.0   Goals for the NETLMM Protocol 
      
     Section 2 of [1] describes three problems with using a global 
     mobility management protocol for localized mobility management. Any 
     localized mobility management protocol must naturally address these 
     three problems. In addition, the side effects of introducing such a 
     solution into the network need to be limited. In this section, we 
     address goals for NETLMM including both solving the basic problems 
     (Goals 1, 2, 3) and limiting the side effects (Goals 4+). 
      
     Kempf, editor            Expires April, 2007            [Page 3] 

     Internet Draft              NETLMM Goals         October, 2006 
      
   
      
     Some basic goals of all IETF protocols are not discussed in detail 
     here, but any solution is expected to satisfy them. These goals are 
     fault tolerance, robustness, interoperability, scalability, and 
     minimal specialized network equipment. A good discussion of their 
     applicability to IETF protocols can be found in [4]. 
      
     Out of scope for the initial goals discussion are QoS and dormant 
     mode/paging. While these are important functions for mobile nodes, 
     they are not part of the base localized mobility management 
     problem.  In  addition,  mobility  between  localized  mobility 
     management domains is not covered here. It is assumed that this is 
     covered by the global mobility management protocols. 
       
  3.1 Handover Performance Improvement (Goal #1) 
      
     Handover packet loss occurs because there is usually latency 
     between when the link handover starts and when the IP subnet 
     configuration and global mobility management signaling completes. 
     During this time the mobile node is unreachable at its former 
     topological location on the old link where correspondents are 
     sending packets. Such misrouted packets are dropped. This aspect of 
     handover performance optimization has been the subject of much 
     work, both in other SDOs and in the IETF, in order to reduce the 
     latency in IP handover. Many solutions to this problem have been 
     proposed at the link layer and at the IP layer. One aspect of this 
     goal for localized mobility management is that the processing delay 
     for changing the forwarding after handover must approach as closely 
     as possible the sum of the delay associated with link layer 
     handover and the delay required for active IP layer movement 
     detection, in order to avoid excessive packet loss. Ideally, if 
     network-side link layer support is available for handling movement 
     detection prior to link handover or as part of the link handover 
     process,  the  routing  update  should  complete  within  the  time 
     required for link handover. This delay is difficult to quantify, 
     but for voice traffic, the entire handover delay including Layer 2 
     handover time and IP handover time should be between 40-70 ms to 
     avoid any degradation in call quality. Of course, if the link layer 
     handover  latency  is  too  high,  sufficient  IP  layer  handover 
     performance for good real time service cannot be matched. 
      
     A goal of the NETLMM protocol - in networks where the link layer 
     handover latency allows it - is to reduce the amount of latency in 
     IP handover, so that the combined IP and link layer handover 
     latency is less than 70 ms. 
      
  3.2 Reduction in Handover-related Signaling Volume (Goal #2) 
      
     Considering Mobile IPv6 [9] as the global mobility protocol (other 
     mobility protocols require about the same or somewhat less), if a 
     mobile  node  using  address  autoconfiguration  is  required  to 

      
     Kempf, editor            Expires April, 2007            [Page 4] 

     Internet Draft              NETLMM Goals         October, 2006 
      
   
     reconfigure on every move between links, the following signaling 
     must be performed: 
      
     1) Link layer signaling required for handover and reauthentication. 
        For example, in 802.11 [7] this is the Reassociate message 
        together with 802.1x [8] reauthentication using EAP. 
     2) Active   IP   level   movement   detection,   including   router 
        reachability.    The    DNA    protocol    [5]    uses    Router 
        Solicitation/Router Advertisement for this purpose. In addition, 
        if SEND [3] is used and the mobile node does not have a 
        certificate cached for the router, the mobile node must use 
        Certification Path Solicitation/Certification Path Advertisement 
        to obtain a certification path.  
     3) Two Multicast Listener Discovery (MLD) [14] REPORT messages, one 
        for each of the solicited node multicast addresses corresponding 
        to the link local address and the global address, 
     4) Two Neighbor Solicitation (NS) messages for duplicate address 
        detection, one for the link local address and one for the global 
        address. If the addresses are unique, no response will be 
        forthcoming. 
     5) Two NS messages from the router for address resolution of the 
        link local and global addresses, and two Neighbor Advertisement 
        messages in response from the mobile node, 
     6) Binding Update/Binding Acknowledgement between the mobile node 
        and home agent to update the care of address binding, 
     7) Return routability signaling between the correspondent node and 
        mobile node to establish the binding key, consisting of one Home 
        Test Init/Home Test and Care of Test Init/Care of Test, 
     8) Binding Update/Binding Acknowledgement between the correspondent 
        node and mobile node for route optimization. 
      
     Note that Steps 1-2 may be necessary even for intra-link mobility, 
     if the last hop link protocol doesn't provide much help for IP 
     handover.  Step  3-5  will  be  different  if  stateful  address 
     configuration is used, since additional messages are required to 
     obtain the address. Steps 6-8 are only necessary when Mobile IPv6 
     is used. The result is approximately 18 messages at the IP level, 
     where the exact number depends on various specific factors such as 
     whether the mobile node has a router certificate cached or not, 
     before a mobile node can be ensured that it is established on a 
     link and has full IP connectivity. In addition to handover related 
     signaling,  if  the  mobile  node  performs  Mobile  IPv6  route 
     optimization, it may be required to renew its return routability 
     key periodically (on the order of every 7 minutes) even if it is 
     not moving, resulting in additional signaling. 
      
     The signaling required has a large impact on the performance of 
     handover,  impacting  Goal  #1.  Perhaps  more  importantly,  the 
     aggregate impact from many mobile nodes of such signaling on 
     expensive shared links (such as wireless where the capacity of the 
     link cannot easily be expanded) can result in reduced last hop link 

      
     Kempf, editor            Expires April, 2007            [Page 5] 

     Internet Draft              NETLMM Goals         October, 2006 
      
   
     capacity for data traffic. Additoinally, in links where the end 
     user is charged for IP traffic, IP signaling is not without cost. 
      
     To address the issue of signaling impact described above, the goal 
     is that handover signaling volume from the mobile node to the 
     network should be no more than what is needed for the mobile node 
     to perform secure IP level movement detection, in cases where no 
     link layer support exists. Furthermore, NETLMM should not introduce 
     any additional signaling during handover beyond what is required 
     for IP level movement detection. If link layer support exists for 
     IP level movement detection, the mobile node may not need to 
     perform  any  additional  IP  level  signaling  after  link  layer 
     handover. 
      
  3.3 Location Privacy (Goal #3) 
      
     In any IP network, there is a threat that an attacker can determine 
     the physical location of a network node from the node's topological 
     location. Depending on how an operator deploys their network, an 
     operator may choose to assign subnet coverage in a way that is 
     tightly bound to geography at some timescale or it may choose to 
     assign it in ways in which the threat of someone finding a node 
     physically  based  on  its  IP  address  is  smaller. Allowing 
     the L2 attachment and L3 address to be less tightly bound is one 
     tool for reducing this threat to location privacy. 
      
     Mobility introduces an additional threat. An attacker can track a 
     mobile node's geographical location in real time, if the victim 
     mobile node must change its IP address as it moves from one subnet 
     to  another  through  the  covered  geographical  area.  If  the 
     granularity of the mapping between the IP subnets and geographical 
     area is small for the particular link type in use, the attacker can 
     potentially assemble enough information to find the victim in real 
     time.  
      
     In order to reduce the risk from location privacy compromises as a 
     result of IP address changes, the goal for NETLMM is to remove the 
     need to change IP address as a mobile node moves across links in an 
     access  network.  Keeping  the  IP  address  fixed  over  a  large 
     geographical region fuzzes out the resolution of the mapping 
     between the IP subnets and geographical area, regardless of how 
     small the natural deployment granularity may be. This reduces the 
     chance that the attacker can deduce the precise geographic location 
     of the mobile node. 
      
  3.4 Limit Overhead in the Network (Goal #4) 
      
     Access networks, including both the wired and wireless parts, tend 
     to  have  somewhat  stronger  bandwidth  and  router  processing 
     constraints than the backbone. In the wired part of the network, 
     these constraints are a function of the cost of laying fiber or 
     wiring  to  the  wireless  access  points  in  a  widely  dispersed 
      
     Kempf, editor            Expires April, 2007            [Page 6] 

     Internet Draft              NETLMM Goals         October, 2006 
      
   
     geographic area. In the wireless part of the network, these 
     constraints are due to the limitation on the number of bits per 
     Hertz imposed by the physical layer protocol. Therefore, any 
     solutions  for  localized  mobility  management  should  minimize 
     overhead within the access network.  
      
  3.5 Simplify Mobile Node Mobility Management Security by Deriving from  
      IP Network Access and/or IP Movement Detection Security (Goal #5) 
      
     Localized mobility management protocols that have host involvement 
     may require an additional security association between the mobile 
     node and the mobility anchor, and establishing this security 
     association may require additional signaling between the mobile 
     node and the mobility anchor (see [13] for an example). The 
     additional  security  association  requires  extra  signaling  and 
     therefore extra time to negotiate. Reducing the complexity of 
     mobile node to network security for localized mobility management 
     can  therefore  reduce  barriers  to  deployment  and  improve 
     responsiveness. Naturally, such simplification must not come at the 
     expense of maintaining strong security guarantees for both the 
     network and mobile node. 
      
     In  NETLMM,  the  network  (specifically  the  MAG)  derives  the 
     occurrence of a mobility event requiring a routing update for a 
     mobile node from link layer handover signaling or IP layer movement 
     detection signaling from the mobile node. This information is used 
     to update routing for the mobile node at the LMA. The handover or 
     movement detection signaling must provide the network with proper 
     authentication  and  authorization  so  that  the  network  can 
     definitively  identify  the  mobile  node  and  determine  its 
     authorization. The authorization may be at the IP level, for 
     example, using something like SEND [3] to secure IP movement 
     detection signaling, or it may be at the link level. Proper 
     authentication and authorization must be implemeted on link layer 
     handover signaling and/or IP level movement detection signaling in 
     order for the MAG to securely deduce mobile node movement events. 
     Security threats to the NETLMM protocol are discussed in [2]. 
      
     The  goal  is  that  security  for  NETLMM  mobile  node  mobility 
     management should derive from IP network access and/or IP movement 
     detection security, such as SEND or network access authentication, 
     and not require any additional security associations or additional 
     signaling between the mobile node and the network. 
      
  3.6 Link Technology Agnostic (Goal #6) 
      
     The number of wireless link technologies available is growing, and 
     the growth seems unlikely to slow down. Since the standardization 
     of a wireless link physical and medium access control layers is a 
     time consuming process, reducing the amount of work necessary to 
     interface a particular wireless link technology to an IP network is 
     necessary. When the last hop link is a wireless link, a localized 
      
     Kempf, editor            Expires April, 2007            [Page 7] 

     Internet Draft              NETLMM Goals         October, 2006 
      
   
     mobility management solution should ideally require minimal work to 
     interface with a new wireless link technology. 
      
     In addition, an edge mobility solution should provide support for 
     multiple wireless link technologies. It is not required that the 
     localized mobility management solution support handover from one 
     wireless link technology to another without change in IP address, 
     but this possibility should not be precluded. 
      
     The goal is that the localized mobility management protocol should 
     not use any wireless link specific information for basic routing 
     management, though it may be used for other purposes, such as 
     securely identifying a mobile node.  
      
      
  3.7 Support for Unmodified Mobile Nodes (Goal #7) 
      
     In the wireless LAN switching market, no modification of the 
     software on the mobile node is required to achieve localized 
     mobility management. Being able to accommodate unmodified mobile 
     nodes enables a service provider to offer service to as many 
     customers as possible, the only constraint being that the customer 
     is authorized for network access. 
       
     Another advantage of minimizing mobile node software for localized 
     mobility management is that multiple global mobility management 
     protocols can be supported. There are a variety of global mobility 
     management  protocols  that  might  also  need  support,  including 
     proprietary or link technology-specific protocols needing support 
     for backward compatibility reasons. Within the Internet, both HIP 
     [11] and Mobike [6] are likely to need support in addition to 
     Mobile  IPv6  [9],  and  Mobile  IPv4  [12]  support  may  also  be 
     necessary. 
      
     Note that this goal does NOT mean that the mobile node has no 
     software at all associated with mobility. The mobile node must have 
     some kind of global mobility protocol if it is to move from one 
     domain of edge mobility support to another and maintain session 
     continuity, although no global mobility protocol is required if the 
     mobile node only moves within the coverage area of the localized 
     mobility management protocol or no session continuity is required 
     during global movement. Also, if the last hop link is a wireless 
     link, every wireless link protocol requires handover support on the 
     mobile node in the physical and medium access control layers, 
     typically in the wireless interface driver. Information passed from 
     the medium access control layer to the IP layer on the mobile node 
     may be necessary to trigger IP signaling for IP handover. Such 
     movement detection support at the IP level may be required in order 
     to determine whether the mobile node's default router is still 
     reachable after the move to a new access point has occurred at the 
     medium access control layer. Whether or not such support is 
     required depends on whether the medium access control layer can 
      
     Kempf, editor            Expires April, 2007            [Page 8] 

     Internet Draft              NETLMM Goals         October, 2006 
      
   
     completely hide link movement from the IP layer. For cellular type 
     wireless link protocols, the mobile node and network undergo an 
     extensive negotiation at the medium access control layer prior to 
     handover, so it may be possible to trigger routing update without 
     any IP protocol involvement. However, for a wireless link protocol 
     such as IEEE 802.11 [7] in which the decision for handover is 
     entirely in the hands of the mobile node, IP layer movement 
     detection signaling from the mobile node may be required to trigger 
     a routing update.    
      
     The goal is that the localized mobility management solution should 
     be able to support any mobile node that joins the link and that has 
     a  interface  that  can  communicate  with  the  network,  without 
     requiring localized mobility management software on the mobile 
     node. 
      
  3.8 Support for IPv4 and IPv6 (Goal #8) 
      
     While most of this document is written with IPv6 in mind, localized 
     mobility management is a problem in IPv4 networks as well. A 
     solution for localized mobility that works for both versions of IP 
     is desirable, though the actual protocol may be slightly different 
     due to the technical details of how each IP version works. From 
     Goal #7 (Section 3.7), minimizing mobile node support for localized 
     mobility means that ideally no IP version-specific changes should 
     be required on the mobile node for localized mobility, and that 
     global  mobility  protocols  for  both  IPv4  and  IPv6  should  be 
     supported. Any IP version-specific features should be confined to 
     the network protocol. 
      
  3.9  Re-use of Existing Protocols Where Sensible (Goal #9) 
      
     Many existing protocols are available as Internet Standards upon 
     which the NETLMM protocol can be built. The design of the protocol 
     should have a goal to re-use existing protocols where it makes 
     architectural and engineering sense to do so. The design should 
     not, however, attempt to re-use existing protocols where there is 
     no real architectural or engineering reason. For example, the suite 
     of Internet Standards contains several good candidate protocols for 
     the transport layer, so there is no real need to develop a new 
     transport protocol specifically for NETLMM.  Re-use is clearly a 
     good  engineering  decision  in  this  case,  since  backward 
     compatibility with existing protocol stacks is important. On the 
     other  hand,  the  network-based,  localized  mobility  management 
     functionality  being  introduced  by  NETLMM  is  a  new  piece  of 
     functionality, and therefore any decision about whether to re-use 
     an existing global mobility management protocol should carefully 
     consider whether re-using such a protocol really meets the needs of 
     the functional architecture for network-based localized mobility 
     management. The case for re-use is not so clear in this case, since 
     there is no compelling backward compatibility argument. 
      
      
     Kempf, editor            Expires April, 2007            [Page 9] 

     Internet Draft              NETLMM Goals         October, 2006 
      
   
  3.10 Localized Mobility Management Independent of Global Mobility 
       Management (Goal #10) 
      
     Localized  mobility  management  should  be  implementable  and 
     deployable  independently  of  any  global  mobility  management 
     protocol. This enables the choice of local and global mobility 
     management to be made independently of particular protocols that 
     are implemented and deployed to solve the two different sorts of 
     mobility management problems. The operator can choose a particular 
     localized mobility management protocol according to the specific 
     features of their access network. It can subsequently upgrade the 
     localized mobility management protocol on its own, without even 
     informing the mobile nodes. Similarly, the mobile nodes can use a 
     global  mobility  management  protocol  that  best  suits  their 
     requirements, or even not use one at all. Also, a mobile node can 
     move into a new access network without having to check that it 
     understands the localized mobility management protocol being used 
     there.  
      
     The goal is that the implementation and deployment of the localized 
     mobility management protocol should not restrict, or be restricted 
     by, the choice of global mobility management protocol.  
      
  3.11 Configurable Data Plane Forwarding between Local Mobility Anchor 
       and Mobile Access Gateway (Goal #11) 
      
     Different  network  operators  may  require  different  types  of 
     forwarding options between the LMA and the MAGs for mobile node 
     data plane traffic. An obvious forwarding option that has been used 
     in past IETF localized mobility management protocols is IP-IP 
     encapsulation for bidirectional tunneling. The tunnel endpoints are 
     the LMA and the MAGs. But other options are possible. Some network 
     deployments may prefer routing-based solutions. Others may require 
     security tunnels using IPsec ESP encapsulation if part of the 
     localized mobility management domain runs over a public access 
     network and the network operator wants to protect the traffic.  
      
     A goal of the NETLMM protocol is to allow the forwarding between 
     the LMA and MAGs to be configurable depending on the particulars of 
     the network deployment. Configurability is not expected to be 
     dynamic as in controlled by the arrival of a mobile node; but 
     rather, configuration is expected to be similar in time scale to 
     configuration for routing. The NETLMM protocol may designate a 
     default forwarding mechanism. It is also possible that additional 
     work  may  be  required  to  specify  the  interaction  between  a 
     particular forwarding mechanism and the NETLMM protocol, but this 
     work is not in scope of the NETLMM base protocol.  
       
  4.0   IANA Considerations 
      
     There are no IANA considerations for this document. 

      
     Kempf, editor            Expires April, 2007            [Page 10] 

     Internet Draft              NETLMM Goals         October, 2006 
      
   
    
  5.0   Security Considerations 
      
     There are two kinds of security issues involved in network-based 
     localized mobility management: security between the mobile node and 
     the network, and security between network elements that participate 
     in  the  NETLMM  protocol.  The  security-related  goals  in  this 
     document, described in Section 3.3 and 3.5, focus on the former, 
     because those are unique to network-based mobility management. The 
     threat analysis document [2] contains a more detailed discussion of 
     both kinds of threats, which the protocol design must address.  
      
  6.0   Acknowledgements 
      
     The  authors  would  like  to  acknowledge  the  following  for 
     particularly diligent reviewing: Vijay Devarapalli, Peter McCann, 
     Gabriel  Montenegro,  Vidya  Narayanan,  Pekka  Savola,  and  Fred 
     Templin. 
      
      
  7.0   Author's Addresses 
         
        James Kempf 
        DoCoMo USA Labs 
        181 Metro Drive, Suite 300 
        San Jose, CA 95110 
        USA 
        Phone: +1 408 451 4711 
        Email: kempf@docomolabs-usa.com 
         
        Kent Leung 
        Cisco Systems, Inc. 
        170 West Tasman Drive 
        San Jose, CA 95134 
        USA 
        EMail: kleung@cisco.com 
         
        Phil Roberts 
        Motorola Labs 
        Schaumberg, IL 
        USA 
        Email: phil.roberts@motorola.com 
         
        Katsutoshi Nishida 
        NTT DoCoMo Inc. 
        3-5 Hikarino-oka, Yokosuka-shi 
        Kanagawa,  
        Japan 
        Phone: +81 46 840 3545 
        Email: nishidak@nttdocomo.co.jp 
         
        Gerardo Giaretta 
      
     Kempf, editor            Expires April, 2007            [Page 11] 

     Internet Draft              NETLMM Goals         October, 2006 
      
   
        Telecom Italia Lab  
        via G. Reiss Romoli, 274   
        10148 Torino  
        Italy  
        Phone: +39 011 2286904  
        Email: gerardo.giaretta@tilab.com 
         
        Marco Liebsch  
        NEC Network Laboratories  
        Kurfuersten-Anlage 36 
        69115 Heidelberg  
        Germany  
        Phone: +49 6221-90511-46  
        Email: marco.liebsch@ccrle.nec.de 
         
  8.0   Normative References 
   
       [1] Kempf, J., editor, "Problem Statement for IP Local Mobility," 
           Internet Draft, Work in Progress. 
       [2] Vogt, C., and Kempf, J., "Security Threats to Network-based 
           Localized Mobility Management", Internet Draft, Work in 
           Progress. 
   
  9.0   Informative References 
      
       [3] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure 
           Neighbor Discovery (SEND)", RFC 3971, March, 2005. 
       [4] Carpenter, B., "Architectural Principles of the Internet," 
           RFC 1958, June, 1996. 
       [5] Choi, J, and Daley, G., "Goals of Detecting Network 
           Attachment in IPv6", Internet Draft, Work in Progress. 
       [6] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol 
           (MOBIKE)", RFC 4555, June 2006. 
       [7] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical 
           Layer (PHY) specifications", IEEE Std. 802.11, 1999. 
       [8] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 
           802.1x, June, 2001. 
       [9] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in 
           IPv6", RFC 3775, June, 2004. 
      [10] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC 
           3753, June, 2004. 
      [11] Moskowitz, R., and Nikander, P., "Host Identity Protocol 
           (HIP) Architecture", RFC 4423, May, 2006.  
      [12] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 
           August, 2002. 
      [13] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L., 
           "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 
           4140, August, 2005. 
      [14] Vida, R., and Costa, L., " Multicast Listener Discovery 
           Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 

      
     Kempf, editor            Expires April, 2007            [Page 12] 

     Internet Draft              NETLMM Goals         October, 2006 
      
   
   
  10.0  IPR Statements 
   
     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. 
       
  11.0  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.  
      
  12.0  Copyright Notice 
   

     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. 
      

      
     Kempf, editor            Expires April, 2007            [Page 13]