J. Kempf,
                                                                     Editor
  Internet Draft                                                   K. Leung
  Document: draft-ietf-netlmm-nohost-req-00.txt draft-ietf-netlmm-nohost-req-01.txt                  P. Roberts
                                                                 K. Nishida
                                                                G. Giaretta
                                                                 M. Liebsch

  Expires: August, October, 2006                                         Feburary,                                        April, 2006

                  Requirements and Gap Analysis

            Goals for IP Local Network-based Localized Mobility
                         (draft-ietf-netlmm-nohost-req-00.txt) Management (NETLMM)
                         (draft-ietf-netlmm-nohost-req-01.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.

  Abstract

     In draft-kempf-netlmm-nohost-ps, the problems with using global IP mobility
     management protocols for local mobility and some problems with existing
     localized mobility management protocols are described. In this document, we
     explore requirements design goals for a network-based localized mobility
     management in more detail. An
     extensive gap analysis against the protocols illustrates where existing
     protocols are able to fulfill the requirements and where they protocol are lacking. discussed.

  Table of Contents

     1.0  Introduction.....................................................2
     2.0  Requirements  Goals for Localized Mobility Management...................3 Management..........................2
     3.0  Gap Analysis.....................................................8
     4.0  Security Considerations.........................................18
     5.0  Recommendation..................................................18
     6.0 Considerations..........................................8
     4.0  Author Information..............................................19
     7.0 Information...............................................9
     5.0  Informative References..........................................20
     8.0 References..........................................10
     6.0  IPR Statements..................................................21
     9.0 Statements..................................................11
     7.0  Disclaimer of Validity..........................................22
     10.0 Validity..........................................12
     8.0  Copyright Notice................................................22
     11.0 Changes in 01 (remove before publication).......................22 Notice................................................12
     9.0  Appendix: Gap Analysis..........................................12
   1.0 Introduction

     In draft-kempf-netlmm-nohost-ps [1], the basic problems that occur when a global mobility protocol is
     used for managing local mobility are described, and two three basic approaches
     to localized mobility management - the host-based approach that is used by
     most IETF protocols and protocols, the WLAN switch approach approach, and using a standard routing
     IGP to distribute host routes - are examined. The conclusion from the
     problem statement document is that
     neither approach 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 mobile node support,
     the proprietary nature limits interoperability and the restriction to a
     single wireless link type and wired backhaul link type restricts scalablity.
     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 use of an IGP to distribute host routes has
     scalability and deployment limitations.

     This document develops more detailed requirements goals for a network-based localized
     mobility management  protocol  and  analyzes  existing  protocols  against  those
     requirements. protocol. In Section 2.0, we review a list of requirements goals that
     are desirable in a network-based localized mobility management solution.
     Section 3.0 performs
     a gap analysis against the requirements of proposed solutions to localized
     mobility management. Section 4.0 briefly outlines security considerations.
     Finally, More discussion of
     security can be found in Section 5.0, a recommendation is made the threat analysis document [2]. The architecture
     of the NETLMM protocol for which the development goals in this document have been
     formulated is described in Section 4 of a
     network-based approach to localized mobility management. [1].

  1.1 Terminology

     Mobility terminology in this draft follows that in RFC 3753 [2] [3] and in [2]. [1].

   2.0 Goals for Localized Mobility Management

     Any localized mobility solution must naturally address the three problems
     described in [1]. In addition, the following terms are used here:

        Node
          A node can be either an end host or router that is served by the
          localized mobility management domain.  Such side effects of introducing such a node may perform global
          mobility management (e.g. NEMO [3] or MIPv6[5]).
     solution into the network need to be limited. In this case, the IP section, we address obtained by the node from the
     goals on a localized mobility management
          domain is solution including both solving the care-of address.

        Host-Based Approach
          A host-based approach to localized mobility management requires binding
          between a local care-of address basic
     problems and a regional care-of address at a
          mobility anchor within limiting the localized mobility management domain. The
          binding side effects.

     Some basic goals of all IETF protocols are not discussed in detail here, but
     any solution is maintained by the mobile node expected to satisfy them. These goals are interoperability,
     scalability, and requires software minimal goal for specialized network equipment. A good
     discussion of their applicability to IETF protocols can be found in [5].

     Out of scope for the initial goals discussion are QoS, multicast, and
     dormant mode/paging. While these are important functions for mobile node's stack to perform nodes,
     they are not part of the binding. The base localized mobility
          service is authorized with the mobility anchor point separately from
          network access. An example is HMIPv6 [20]. A management problem. In
     addition, mobility anchor is a kind
          of between localized mobility management domain gateway. The regional care-of
          address domains is fixed at not
     covered here. It is assumed that this is covered by the global mobility anchor while the local care-of address
          on
     management protocols.

  2.1 Handover Performance Improvement (Goal #1)

     Handover packet loss occurs because there is usually latency between when
     the access router changes wireless link handover starts and when the mobile node moves to a new IP
          link.

        Micromobility Approach
          A micromobility approach to localized mobility management requires host
          route propagation from link handover completes.
     During this time the mobile node to a collection of specialized
          routers in the localized mobility management domain along a path back
          to a boundary router is unreachable at its former topological
     location on the edge of the localized mobility management
          domain. A boundary router old IP link where correspondents are sending packets and to
     which the routing system is a kind routing them. Such misrouted packets are
     dropped. This aspect of localized mobility management
          domain gateway. Localized mobility management is authorized with handover performance optimization has been the
          access router, but reauthorization with each new access router is
          necessary on IP link movement,
     subject of an enormous amount of work, both in addition other SDOs, to any reauthorization for
          basic network access. The host routes allow reduce the mobile node to maintain
     latency of wireless link handover, and in the same IP address when it moves to a new IP link, IETF and still continue elsewhere, to receive packets on reduce
     the new latency in IP link.

        Edge Mobility Approach
          In the edge mobility approach link handover. Many solutions to localized mobility management, the
          access routers update bindings between this problem have been
     proposed at the mobile node's care-of
          address wireless link layer and at the mobile node's current IP link. The bindings are
          maintained at an edge mobility anchor point. The mobile node is not
          involved in localized mobility management beyond movement detection.
          The mobile node requires no special authorization layer. One aspect of this
     goal for localized mobility management service beyond is that the authorization required processing delay for basic
          network access. A mobile node's IP address does not change when
     changing the
          mobile node moves from one access router to another within routing after handover must approach as closely as possible the coverage
          area
     sum of the edge mobility anchor point, because the mobility anchor delay associated with link layer handover and
          access routers take care of changing the routing.

   2.0 Requirements delay required
     for Localized Mobility Management

     Any localized mobility solution must naturally address the three problems
     described active IP layer movement detection, in [1]. In addition, the side effects 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 introducing such a
     solution into the network need to be limited. In this section, we address
     requirements on a localized mobility solution including both solving link handover
     process, the
     basic problems and limiting routing update should complete within the side effects.

     Some basic requirements of all IETF protocols time required for
     wireless link handover.

     Note that a related problem occurs when traffic packets are not discussed in detail
     here, but any solution is expected to satisfy them. These requirements are
     interoperability,  scalability, routed
     through a global mobility anchor such as a Mobile IP home agent. Route
     optimized Mobile IPv6 [6] and  minimal  requirement  for  specialized
     network  equipment. HIP [7] are examples. A  good  discussion loss of  their  applicability  to  IETF
     protocols connectivity
     can be found in [4].

     Out occur when both sides of scope for the initial requirements discussion are QoS, multicast, and
     dormant mode/paging. While these IP conversation are important functions for mobile nodes, and 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 both
     hand over at the same time. The two sides must use a global mobility
     management protocols.

  2.1     Handover Performance Improvement (Requirement #1)

     Handover anchor
     point,  like  a  home  agent  or  rendezvous  server,  to  re-establish  the
     connection, but there may be substantial packet loss occurs because there is usually latency between when
     the wireless link handover starts and when the IP link handover completes.
     During this time the mobile node is unreachable at its former topological
     location on the old IP link where correspondents are sending packets and to
     which the routing system is routing them. Such misrouted packets are
     dropped. This aspect of handover performance optimization has been the
     subject of an enormous amount of work, both in other SDOs, to reduce the
     latency of wireless link handover, and in the IETF and elsewhere, to reduce
     the latency in IP link handover. Many solutions to this problem have been
     proposed at the wireless link layer and at the IP layer. One aspect of this
     requirement for localized mobility management is that the processing delay
     for changing the routing after handover must be minimal, in order to avoid
     excessive packet loss. Ideally, if network-side link layer support is
     available  for  handling  movement  detection,  the  routing  update  should
     complete within the time required for wireless link handover.

     Note that a related problem occurs when traffic packets are not routed
     through a global mobility anchor such as a Mobile IP home agent. Route
     optimized Mobile IPv6 [5] and HIP [6] are examples. A loss of connectivity
     can occur when both sides of the IP conversation are mobile and they both
     hand over at the same time. The two sides must use a global mobility anchor
     point,  like  a  home  agent  or  rendezvous  server,  to  re-establish  the
     connection, but there may be substantial packet loss until until the problem is
     discovered. Another aspect of this requirement goal is that the solution must ensure
     that connectivity is not lost when both ends are mobile and move at the same
     time.

     In both cases, the loss of accurate routing caused causes the connection to
     experience an interruption which may cause service degradation for real time
     traffic such as voice

  2.2 Reduction in Handover-related Signaling Volume (Requirement (Goal #2)

     Considering Mobile IPv6 as the global mobility protocol (other mobility
     protocols require about the same or somewhat less), if a mobile node is
     required to reconfigure on every move between IP links, the following set of
     signaling messages must be done:

     1) Movement detection using DNA [7] [8] or possibly a link specific protocol,
     2) Any link layer or IP layer AAA signaling, such as 802.1x [8] [9] or PANA [9].
        [10]. The mobile node may also or instead have to obtain a router
        certificate using SEND [10], [11], if the certificate is not already cached,
     3) Router discovery which may be part of movement detection,
     4) If stateless address autoconfiguration is used, address configuration and
        Duplicate  Address  Detection  (unless  optimistic  Duplicate  Address
        Detection [11] [12] is used). If stateful address configuration is used, then
        DHCP is used for address configuration,
     5) Binding Update to the home agent,
     6) If route optimization is in effect, return routability to establish the
        binding key,
     7) Binding Update to correspondent nodes for route optimization.

     Note that Steps 1-2 will always be necessary, even for intra-link mobility,
     and Step 3 will be necessary even if the mobile node's care-of address can
     remain the same when it moves to a new access router.

     This

     The result is approximately 10 messages at the IP level before a lot of signaling just to get up mobile node
     can  be  ensured  that  it  is  established  on  a new  link  and  has  full  IP link.
     connectivity. Furthermore, in some cases, the mobile node may need to engage
     in "heartbeat signaling" to keep the connection with the correspondent or
     global mobility anchor fresh, for example, return routability in Mobile IPv6
     must be done at a maximum every 7 minutes even if the mobile node is
     standing still.

     The requirement goal is that handover signaling volume from the localized mobility management
     protocol mobile node to the
     network should be no more than what is needed to securely redirect a for the mobile
     node's traffic within node to perform
     secure IP level movement detection, in cases where no link layer support
     exists. If link layer support exists for IP level movement detection, the localized mobility management domain.
     mobile node may not need to perform any additional IP level signaling after
     handover.

  2.3 Location privacy (Requirement (Goal #3)

     Location privacy in the context of IP mobility refers to hiding the
     geographic location of mobile users.

     Although general location privacy issues have been discussed in [13], [14], the
     location privacy referred to here focuses on the IP layer and involves layer. In most wireless
     IP network deployments, different IP subnets are used to cover different
     geographical areas. It is therefore possible to derive a topological to
     geographical map, in which particular IPv6 subnet prefixes are mapped to
     particular geographical locations. The precision of the basic property map depends on the
     size of the geographic area covered by a particular subnet: if the area is
     large, then knowing the subnet prefix won't provide much information about
     the precise geographical location of a mobile node within the subnet.

     When a mobile node moves geographically, it also moves topologically between
     subnets. In order to maintain routability, the mobile node must change its
     local IP address
     that may change due when it moves between subnets. A correspondent node or
     eavesdropper can use the topological to geographical map to deduce in real
     time where a mobile node - and therefore its user - is located. Depending on
     how precisely the geographical location can be deduced, this information
     could be used to compromise the mobility. privacy or even cause harm to the user. The
     geographical location information should not be revealed to nor deduced be deducible
     by the correspondent node or an eavesdropper without the authorization of
     the mobile node's owner. Since the localized mobility management protocol
     is responsible for the mobile node's mobility within the local mobility management
     domain,  it  should  conceal  geographical  movement  of  the  mobile  node.

     The threats to location privacy come in a variety of forms. Perhaps least
     likely  is  a  man  in  the  middle  attack  in  which  traffic  between  a
     correspondent and the mobile node is intercepted and the mobile node's
     location is deduced from that, since man in the middle attacks in the
     Internet tend to be fairly rare. More likely are attacks in which the
     correspondent is the attacker or the correspondent or even the mobile node
     itself are is relaying information on the care-of local address change to someone. an attacker.
     The owner of the correspondent or mobile node might not even be aware of the
     problem if an attacker has installed spyware or some other kind of exploit
     on the mobile node
     and the malware is relaying the change in care-of local address to an the attacker.
     Host-based  localized  mobility  management  solutions  in  which  the
     correspondent only sees a regional address but the host still maintains a
     local address are unsatisfactory because they still have a potential for
     malware on the mobile node itself to reveal a change in the local address.

     Note that the location privacy referred to here is different from the
     location privacy discussed in [15][16][17]. [16][17][18]. The location privacy discussed
     in these drafts primarily concerns modifications to the Mobile IPv6 protocol
     to eliminate places where an eavesdropper could track the mobile node's
     movement by correlating home address and care of address.

     The requirement is that

     In order to reduce the risk from location information should not be revealed privacy compromises as a result of
     IP address changes, the goal for NETLMM is to
     nor deduced by remove the need to change IP
     address as mobile node moves across IP links. Keeping the IP address fixed
     removes any possibility for the correspondent node without to deduce the authorization precise
     geographic location of the mobile node's owner node without the user's authorization, as long
     well as any possibility that malware on the mobile node remains within could inadvertently
     reveal the localized
     mobility management domain. Since mobile node's location to an attacker. Note that keeping the localized mobility management protocol
     address constant doesn't completely remove the possibility of deducing the
     geographical location, since a local address still is responsible for required. However, it
     does allow the network to be deployed such that the mapping between the
     geographic and topological location is considerably less precise. If the
     mapping is not precise, an attacker can only deduce in real time that the
     mobile node mobility within is somewhere in a large geographic area, like, for example, a
     metropolitan region or even a small country, reducing the localized mobility
     management domain, it should conceal possibility that
     the geographical movement of attacker can cause harm to the mobile
     node. user.

  2.4 Efficient Use of Wireless Resources (Requirement (Goal #4)

     Advances in wireless PHY and MAC technology continue to increase the
     bandwidth available from limited wireless spectrum, but even with technology
     increases, wireless spectrum remains a limited resource. Unlike wired
     network links, wireless links are constrained in the number of bits/Hertz by
     their coding technology and use of physical spectrum, which is fixed by the
     PHY. It is not possible to lay an extra cable if the link becomes
     increasingly congested as is the case with wired links.

     Some existing localized mobility management solutions increase packet size
     over the wireless link by adding tunneling or other per packet overhead.
     While header compression technology can remove header overhead, header
     compression does not come without cost. Requiring header compression on the
     wireless access points increases the cost and complexity of the access
     points, and increases the amount of processing required for traffic across
     the wireless link. Since the access points tend to be a critical bottleneck
     in wireless access networks for real time traffic (especially on the
     downlink), reducing the amount of per-packet processing is important. While
     header compression probably cannot be completely eliminated, especially for
     real time media traffic, simplifying compression to reduce processing cost
     is an important requirement. goal.

     The requirement goal is that the localized mobility management protocol should not
     introduce any new signaling or increase existing signaling over the air.

  2.5 Reduction of Signaling Overhead in the Network (Requirement (Goal #5)

     While bandwidth and router processing resources are typically not as
     constrained in the wired network, wired networks tend to have higher
     bandwidth  and  router  processing  constraints  than  the  backbone.  These
     constraints are a function of the cost of laying fiber or wiring to the
     wireless access points in a widely dispersed geographic area. Therefore, any
     solutions for localized mobility management should minimize signaling within
     the wired network as well.

  2.6 No Extra Security Between Mobile Node and Network (Requirement (Goal #6)

     Localized mobility management protocols that have signaling between the
     mobile node and network require a security association between the mobile
     node  and  the  network  entity  that  is  the  target  of  the  signaling.
     Establishing a security association specifically for localized mobility
     service in a roaming situation may prove difficult, because provisioning a
     mobile node with security credentials for authenticating and authorizing
     localized  mobility  service  in  each  roaming  partner's  network  may  be
     unrealistic from a deployment perspective. Reducing the complexity of mobile
     node to network security for localized mobility management can therefore
     reduce barriers to deployment.

     Removing mobile node involvement in localized mobility management also
     limits the possibility of DoS attacks on network infrastructural elements.
     In a host based approach, the mobile node is required to have a global or
     restricted routing local IP address for a network infrastructure element,
     the mobility anchor point. The network infrastructural element therefore
     becomes a possible target for DoS attacks, even if mobile nodes are properly
     authenticated. A properly authenticated mobile node can either willfully or
     inadvertently  give  the  network  infrastructural  element  address  to  an
     attacker.

     In summary, ruling out mobile node involvement in local mobility management
     simplifies security by removing the need for service-specific credentials to
     authenticate and authorize the mobile node for localized mobility management
     in the network and by limiting the possibility of DoS attacks on network
     infrastructural elements. The requirement goal is that support for localized mobility
     management should not require additional security between the mobile node
     and the network.

  2.7 Support for Heterogeneous Wireless Link Technologies (Requirement (Goal #7)

     The number of wireless link technologies available is growing, and the
     growth seems unlikely to slow down. Since the standardization of a wireless
     link PHY and MAC is a time consuming process, reducing the amount of work
     necessary to interface a particular wireless link technology to an IP
     network is necessary. A localized 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 within the network in separate subnets. It is not
     required that the localized mobility management solution support handover
     from one wireless link technology to another without change in IP address.
     The reason is because a change in network interface typically requires that
     the hardware interface associated with one wireless link technology be
     brought up and configured, and this process typically requires that the IP
     stack for the new interface card be configured on the mobile node from the
     driver up. Requiring that the mobile node IP stack circumvent this process
     to keep the IP address constant would be a major change in the way the IP
     stack software is implemented.

     The requirement 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 identifying a mobile node.

  2.8 Support for Unmodified Mobile Nodes (Requirement (Goal #8)

     In the wireless LAN switching market, no modification of the software on the
     mobile node is required to achieve "IP mobility" (which means 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 with a localized mobility management solution that does not have
     mobile node involvement. While Mobile IPv6 is clearly the global mobility
     management protocol of primary interest going forward, there are a variety
     of global mobility management protocols that might also need support,
     including proprietary protocols needing support for backward compatibility
     reasons. Within IETF, both HIP and Mobike are likely to need support in
     addition to Mobile IPv6, and Mobile IPv4 support may also be necessary.

     Note that this requirement goal does NOT mean that the mobile node has no software at
     all associated with mobility or wireless. 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, although no global mobility protocol is
     required if the mobile node only moves within the coverage area of the
     localized mobility management protocol. Also, every wireless link protocol
     requires handover support on the mobile node in the physical and MAC layers,
     typically in the wireless interface driver. Information passed from the MAC
     layer to the IP layer on the mobile nodenode node may be necessary to trigger IP
     signaling for IP link 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 MAC layer. Whether or not such support is required depends
     on whether the MAC layer can completely hide link movement from the IP
     layer. For a wireless link protocol such as the 3G protocols, the mobile
     node and network undergo an extensive negotiation at the MAC 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 in which there is no network involvement in handover, IP layer
     movement detection signaling from the mobile node may be required to trigger
     routing update.

     The requirement goal is that the localized mobility management solution should be able
     to support any mobile node that walks up to the link and has a wireless
     interface that can communicate with the network, without requiring localized
     mobility management software on the mobile node.

  2.9 Support for IPv4 and IPv6 (Requirement (Goal #9)

     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 Requirement Goal #8 (Section 2.8), minimizing mobile node support
     for localized mobility means that ideally no IP version-specific changes
     would 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 would be confined to the network protocol.

   3.0 Gap Analysis
     This section discusses a gap analysis between

  2.10 Re-use of Existing Protocols Where Sensible (Goal #10)

     Many existing proposals for solving
     localized mobility management 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 requirements in Section. 2.0.

  3.1 Mobile IPv6 with Local Home Agent

     One option suite of Internet Standards contains several good candidate
     protocols for the transport layer, so there is no real need to deploy Mobile IPv6 with develop a locally assigned home agent 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 local network. This solution requires other hand, the mobile node network-based,
     localized mobility management functionality being introduced by NETLMM is a
     new piece of functionality, and therefore any decision about whether to somehow be
     assigned re-
     use  an  existing  global  mobility  management  protocol  should  carefully
     consider whether re-using such a home agent in protocol really meets the local network when it boots up. This home agent
     is used instead needs of the home agent in the home network.
     functional architecture for network-based localized mobility management. The advantage of
     case for re-use is not so clear in this
     option case, since there is that the no special solution is required for edge compelling
     backward compatibility argument.

   3.0 Security Considerations
     There are two kinds of security issues involved in network-based localized
     mobility - management: security between the mobile node reuses and the global network, and
     security between network elements that participate in the network-based
     localized mobility management protocol for that purpose
     - if

     Security between the mobile node is using Mobile IPv6. One disadvantage is that Mobile
     IP has no provision for handover between home agents. Although such handover
     should be infrequent, it could be quite lengthy and complex.

     The analysis of this approach against the requirements above is the
     following.

     Requirement #1: If the mobile node does not perform route optimization, this
     solution  reduces,  but  does  not  eliminate,  IP  link  handover  related
     performance problems.

     Requirement #2: Similarly to Requirement #1, signaling volume is reduced if
     no route optimization signaling is done on handover.

     Requirement #3: Location privacy is preserved for external correspondents,
     but the mobile node network itself still maintains a local care-of address which a
     worm or other exploit could misuse. If the mobile node does perform route
     optimization, location privacy may be compromised, consists of two
     parts: threats involved in localized mobility management in general, and this solution is no
     better than having a remote home agent.

     Requirement #4: If traffic is not route optimized, the mobile node still
     pays for an over-the-air tunnel
     threats to the locally assigned home agent. network-based localized mobility management from the host.
     The
     overhead here first is exactly the same as if the mobile node's home agent discussed above in the
     home network is used Sections 2.3 and route optimization 2.6. The second is not done.

     Requirement #5: If
     discussed in the threat analysis document [28].

     For threats to network-based localized mobility management domain is large, management, the
     mobile node may suffer from unoptimzed routes since handover and mobility
     between home agents basic threat
     is not supported.

     Requirement #6: A local home agent in an attempt by an unauthorized party to signal a roaming situation bogus mobility event.
     Such an event must be detectable. This requires the guest
     mobile node to have the proper credentials to authenticate with the local
     home agent in the serving network. In addition, as in Requirement #3, the
     local home agent's address could become the target of a DoS attack if
     revealed to an attacker. So a local home agent would provide no benefit for
     this requirement.

     Requirement #7: This solution supports multiple wireless technologies in
     separate IP link subnets. No special work is required to interface a local
     home agent to different wireless technologies.

     Requirement #8: The mobile node must support Mobile IPv6 in order for this
     option to work. So mobile node changes are required and other IP mobility
     protocols are not supported.

     Requirement #9: This solution requires separate locally assigned home agents
     for Mobile IPv4 bidirectional
     authentication and Mobile IPv6 since the local home agent should have MIP
     functions or IPv4 or IPv6 in conjunction with IP version of global mobility
     protocol, or some way to register an IPv4 care of address to home address
     mapping in an Mobile IPv6 home agent. While there are a couple authorization of proposals
     currently active network elements that participate in the IETF for this (see [18] for one), it is not clear at
     this point whether they will be adopted for standards track development.

  3.2     Hierarchical Mobile IPv6 (HMIPv6)

     HMIPv6  [20]  provides  the  most  complete
     network-based  localized  mobility  management
     solution available today as an Internet RFC. In HMIPv6, a localized mobility
     anchor called a MAP serves as a routing anchor for a regional care-of
     address. When a mobile node moves from one access router to another, the
     mobile node changes the binding between its regional care-of address  protocol,  and
     local care-of address at  data  origin
     authentication on the MAP. No global mobility management signaling is
     required, since the care-of address seen by correspondents does not change.
     This part of HMIPv6 is similar to the solution outlined in Section 3.1;
     however, HMIPv6 also allows a mobile node to hand over between MAPs.

     Handover between MAPs and MAP discovery requires configuration on the
     routers. MAP addresses are advertised by access routers. Handover happens by
     overlapping MAP coverage areas so that, for some number of access routers,
     more than one MAP may be advertised. Mobile nodes need to switch MAPs in the
     transition area, and then must perform global mobility management update and
     route optimization to the new regional care-of address, if appropriate.

     The analysis of this approach against the requirements above is the
     following.

     Requirement #1 This solution shortens, but does not eliminate, the latency
     associated with IP link handover, since it reduces the amount of signaling
     and the length of the signaling paths.

     Requirement  #2  Signaling  volume  is  reduced  simply  because  no  route
     optimization signaling is done on handover within the coverage area of the
     MAP.

     Requirement #3 Location privacy is preserved for external correspondents,
     but the mobile node itself still maintains a local care-of address which a
     worm or other exploit could access by sending the local care-of address to
     third malicious node to enable it to track the mobile node's location.

     Requirement #4 The mobile node always pays for an over-the-air tunnel to the
     MAP. If the mobile node is tunneling through a global home agent or VPN
     gateway, the wired link experiences double tunneling. Over-the-air tunnel
     overhead can be removed by header compression, however.

     Requirement #5 From Requirement #1 and Requirement #4, the signaling
     overhead is no more or less than for mobile nodes whose global mobility
     management anchor is local. However, because MAP handover is possible,
     routes across large localized mobility management domains can be improved
     thereby improving wired network resource utilization by using multiple MAPs
     and handing over, at the expense of the configuration and management
     overhead involved in maintaining multiple MAP coverage areas.

     Requirement #6 In a roaming situation, the guest mobile node must have the
     proper credentials to authenticate with the MAP in the serving network. In
     addition, since the mobile node is required to have a unicast address for
     the MAP that is either globally routed or routing restricted to the local
     administrative domain, the MAP is potentially a target for DoS attacks
     across a wide swath of traffic between network topology.

     Requirement #7 This solution supports multiple wireless technologies in
     separate IP link subnets.

     Requirement #8 This solution requires modification to the mobile nodes. In
     addition, the HMIPv6 design has been optimized for Mobile IPv6 mobile nodes, elements.

   4.0 Author Information

        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
        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

   5.0 Informative References

       [1] Kempf, J., Leung, K., Roberts, P., Nishda, K., Giaretta, G., Liebsch,
           M., and is not a good match Gwon, Y., "Problem Statement for other global mobility management protocols.

     Requirement #9 Currently, there is no IPv4 version of this protocol;
     although there is an expired IP Local Mobility," Internet draft with a design for a regional
     registration protocol for Mobile IPv4 that has similar functionality.

  3.3 Combinations of Mobile IPv6 with Optimizations

     One approach to local mobility that has received much attention in the past
     and has been thought to provide a solution is combinations of protocols. The
     general approach is to try to cover gaps in the solution provided by MIPv6
     by using other protocols. In this section, gap analyses for MIPv6 + FMIPv6
     and HMIPv6 + FMIPv6 are discussed.

  3.3.1 MIPv6 + FMIPv6

     As discussed
           Draft, work in Section 3.1, the use of MIPv6 with a dynamically assigned,
     local home agent cannot fulfill the requirements. A fundamental limitation
     is that Mobile IPv6 cannot provide seamless handover (i.e. Requirement #1).
     FMIPv6 has been defined with the intent to improve the handover performance
     of MIPv6. For this reason, the combined usage of FMIPv6 and MIPv6 with a
     dynamically assigned local home agent has been proposed to handle local
     mobility.

     Note that this gap analysis only applies to localized mobility management,
     and it is possible that MIPv6 progress.
       [2] Vogt, C., and FMIPv6 might still be acceptable for
     global mobility management.

     The analysis of this combined approach against the requirements follows.

     Requirement  #1  FMIPv6  provides  a  solution  for  handover  performance
     improvement  that  should  fulfill  the  requirements  raised  by  real-time
     applications Kempf, J., "Security Threats to Network-based Localized
           Mobillity Management", Internet draft, work in terms of jitter, delay progress.
       [3] Manner, J., and packet loss. The location Kojo, M., "Mobility Related Terminology", RFC 3753,
           June, 2004.
       [4] Devarapalli,V., Wakikawa, R., Petrescu, A., Thubert, P., "Network
           Mobility (NEMO) Basic Support Protocol", RFC 3963, January, 2005.
       [5] Carpenter, B., "Architectural Principles of the
     home agent (in local or home domain) does not affect the handover latency.

     Requirement #2 FMIPv6 requires the mobile node to perform extra signaling with the
     access router (i.e. exchange of RtSolPr/PrRtAdv Internet," RFC 1958,
           June, 1996.
       [6] Johnson, D., Perkins, C., and FBU/FBA). Moreover, as Arkko, J., "Mobility Support in standard MIPv6, whenever the mobile node moves to another IP link, it
     must send a Binding Update to the home agent. If route optimization is used,
     the mobile node also performs return routability IPv6",
           RFC 3775.
       [7] Moskowitz, R., Nikander, P., Jokela, P., and sends a Binding Update
     to each correspondent node. Nonetheless, it is worth noting that FMIPv6
     should result Henderson, T., "Host
           Identity Protocol", Internet Draft, work in a reduction of the amount progress.
       [8] Choi, J, and Daley, G., "Goals of IPv6 Neighbor Discovery
     signaling on the new link.

     Requirement #3 The mobile node mantains a local care-of address. If route
     optimization is not used, location privacy can be achieved using bi-
     directional tunneling. However, as mentioned Detecting Network Attachment in Section 3.1, a worm or other
     malware can exploit this care of address by sending it to a third malicious
     node.

     Requirement #4 As stated
           IPv6", Internet Draft, work in progress.
       [9] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 802.1x, June,
           2001.
      [10] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and Yegin, A.,
           "Protocol for Requirement #2, the combination of MIPv6 Carrying Authentication for Network Access (PANA)",
           Internet Draft, work in progress.
      [11] Arkko, J., Kempf, J., Zill, B., and
     FMIPv6 generates extra signaling overhead. For data packets, Nikander, P., "SEcure Neighbor
           Discovery (SEND)", RFC 3971, March, 2005.
      [12] Moore, N., "Optimistic Neighbor Discovery", Internet Draft, Work in
           Progress.
      [13] Ackerman, L., Kempf, J., and Miki, T., "Wireless Location Privacy: Law
           and Policy in addition to the US, EU, and Japan", ISOC Member Briefing #15,
           http://www.isoc.org/briefings/015/index.shtml
      [14] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., Park, S.D., and
           Patil, B., "Privacy for Mobile IPv6 over-the-air tunnel, there is a further level and Multi-homed Nodes: MoMiPriv Problem
           Statement", Internet Draft, work in progress.
      [15] Kivinen, T., and Tschopfening, H., "Design of tunneling
     between the mobile node MOBIKE Protocol",
           Internet Draft, work in progress.
      [16] Koodli, R., "IP Address Location Privacy and IP Mobility", Internet
           Draft, work in progress.

      [17] Koodli, R., Devarapalli, V., Flinck, H., and Perkins, C., "Solutions
           for IP Address Location Privacy in the previous access router during handover. This
     tunnel is needed to forward incoming packets to the mobile node addressed to
     the previous care-of address. Another reason is that, even if the mobile
     node has a valid new care-of address, the mobile node cannot use the new
     care presence of address directly with its correspondents without performing route
     optimization to the new care IP Mobility",
           Internet Draft, work in progress.
      [18] Bao, F., Deng, R., Kempf, J., Qui, Y., and Zhou, J., "Protocol for
           Protecting Movement of address. This implies that the transient
     tunnel overhead is Mobile Nodes in place even for route optimized traffic.

     Requirement #5 FMIPv6 generates extra signaling overhead between previous
     the access router Mobile IPv6", Internet Draft,
           work in progress.
      [19] Soliman, H., Tsirtsis, G., Devarapalli, V., Kempf, J., Levkowetz, H.,
           Thubert, P, and the new access router Wakikawa, R. "Dual Stack Mobile IPv6 (DSMIPv6) for the HI/HAck exchange.
     Concerning  data  packets,  the  use  of  FMIPv6
           Hosts and Routers", Internet Draft, work in progress.
      [20] Koodli, R., editor, "Fast Handovers for  handover  performance
     improvement implies Mobile IPv6", RFC 4068, July,
           2005.
      [21] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L.,
           "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140,
           August, 2005.
      [22] Kempf, J., and Koodli, R., "Bootstrapping a tunnel between the previous access router Symmetric IPv6 Handover Key
           from SEND", Internet Draft, work in progress.
      [23] Campbell, A., Gomez, J., Kim, S., Valko, A., and the
     mobile node that adds some overhead Wan, C., "Design,
           Implementation and Evaluation of Cellular IP", IEEE Personal
           Communications, June/July 2000.
      [24] Ramjee, R., La Porta, T., Thuel, S., and Varadhan, K., "HAWAII: A
           domain-based approach for supporting mobility in wide-area wireless
           networks", in Proceedings of the wired network. This overhead has
     more impact International Conference on star topology deployments, since packets are routed down to
     the old access router, then back up to Networking
           Protocols (ICNP), 1999.
      [25] "Mobile VPN Network Configuration Alternatives", IP Unplugged,
           http://www.ipunplugged.com/pdf/Network-blueprints_A.pdf.
      [26] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142,
           Feburary, 1990.
      [27] Moy, J., "OSPF Version 2", STD 54, April, 1998.
      [28] Threat analysis draft, TBD

   6.0 IPR Statements

     The  IETF  takes  no  position  regarding  the aggregation router and then back
     down  validity  or  scope  of  any
     Intellectual Property Rights or other rights that might be claimed to the new access router.

     Requirement #6 In addition
     pertain to the analysis for Mobile IPv6 with local home
     agent in Section 3.1, FMIPv6 requires the mobile node and implementation or use of the previous
     access router to share a security association technology described in order to secure FBU/FBA
     exchange. So far, only a SEND-based solution has been proposed and this
     requires
     document or the mobile node extent to use autoconfigured Cryptographically Generated Addresses
     (CGAs)[21]. This precludes stateful address allocation using DHCP, which any license under such rights might or might
     not be a necessary deployment in certain circumstances. Another solution
     based on AAA is under study but it could require extra signaling overhead
     over the air and in the wired network and available; nor does it could raise performance issues.

     Requirement #7 MIPv6 and FMIPv6 support multiple wireless technologies, so
     this requirement is fufilled.

     Requirement #8 The mobile node must support both MIPv6 and FMIPv6, so represent that it is
     not possible to satisfy this requirement.

     Requirement #9 Work is underway to extend MIPv6 with the capability to run
     over both IPv6-enabled and IPv4-only networks [18]. FMIPv6 only supports
     IPv6. Even though an IPv4 version of FMIP has been recently proposed, it is
     not clear how it could be used together with FMIPv6 in order to handle fast
     handovers across made any wired network.

  3.3.2 HMIPv6 + FMIPv6

     HMIPv6 provides several advantages in terms of local mobility management.
     However, as seen in Section 3.2, it does not fulfill all independent
     effort to identify any such rights. Information on the requirements
     identified procedures with
     respect to rights in Section 2.0. In particular, HMIPv6 does not completely
     eliminate the IP link handover latency. For this reason, FMIPv6 could RFC documents can be
     used together with HMIPv6 found in order BCP 78 and BCP 79.

     Copies of IPR disclosures made to cover the gap.

     Note that even if this solution is used, IETF Secretariat and any assurances of
     licenses to be made available, or the mobile node is likely result of an attempt made to need
     MIPv6 obtain a
     general license or permission for global mobility management, in contrast with the MIPv6 with
     dynamically assigned local home agent + FMIPv6 solution. Thus, use of such proprietary rights by
     implementers or users of this solution
     should really specification can be considered MIPv6 + HMIPv6 + FMIPv6. obtained from the IETF
     on-line IPR repository at http://www.ietf.org/ipr.

     The analysis of 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 combined approach against standard.
     Please address the requirements follows.

     Requirement #1 HMIPv6 information to the IETF at ietf-ipr@ietf.org.

   7.0 Disclaimer of Validity

     This document and FMIPv6 both shorten the latency associated with IP
     link  handovers.  In  particular,  FMIPv6 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.

   8.0 Copyright Notice

     Copyright (C) The Internet Society (2006).  This document is  expected subject to  fulfill the
     requirements  on  jitter,  delay  and  packet  loss  raised  by  real-time
     applications.

     Requirement #2 Both FMIPv6
     rights, licenses and HMIPv6 require extra signaling compared with
     Mobile IPv6. As a whole the mobile node performs signaling message exchanges
     at each handover that are RtSolPr/PrRtAdv, FBU/FBA, LBU/LBA restrictions contained in BCP 78, and BU/BA.
     However, except as mentioned in Section 3.2, the use of HMIPv6 reduces set
     forth therein, the
     signaling overhead since no route optimization signaling is done authors retain all their rights.

   9.0 Appendix: Gap Analysis

     This section discusses a gap analysis between existing proposals for intra-
     MAP handovers. In addition, na´ve combinations of FMIPv6 solving
     localized mobility management and HMIPv6 often
     result the goals in redundant signaling. There Section. 2.0.

  9.1 Mobile IPv6 with Local Home Agent

     One option is much work in the academic literature
     and the IETF on more refined ways of combining signaling from the two
     protocols to avoid redundant signaling.

     Requirement #3 HMIPv6 may preserve location privacy, depending on the
     dimension of the geographic area covered by the MAP. As discussed deploy Mobile IPv6 with a locally assigned home agent in Section
     3.2,
     the local network. This solution requires the mobile node still maintains a local care-of address that can to somehow be
     exploited by worms or other malware.

     Requirement #4 As mentioned for Requirement #2, the combination of HMIPv6
     and FMIPv6 generates
     assigned a lot of signaling overhead home agent in the network. Concerning
     payload data, local network when it boots up. This home agent
     is used instead of the home agent in addition to the over-the-air MIPv6 tunnel, a further level home network. The advantage of tunneling this
     option is established between mobile node and MAP. Notice that this
     tunnel no special solution is in place even required for route optimized traffic. Moreover, if FMIPv6 is
     directly applied to HMIPv6 networks, there is a third temporary handover-
     related tunnel between edge mobility - the
     mobile node and previous access router. Again,
     there is much work in reuses the academic literature and IETF on ways to reduce global mobility management protocol for that purpose
     - if the
     extra tunnel overhead on mobile node is using Mobile IPv6. One disadvantage is that Mobile
     IP has no provision for handover by combining HMIP between home agents. Although such handover
     should be infrequent, it could be quite lengthy and FMIP tunneling.

     Requirement #5 complex.

     The signaling overhead in analysis of this approach against the network goals above is the following.

     Goal #1: If the mobile node does not perform route optimization, this
     solution  reduces,  but  does  not  eliminate,  IP  link  handover  related
     performance problems.

     Goal #2: Similarly to Goal #1, signaling volume is reduced by
     HMIPv6, as mentioned in Section 3.2. Instead, FMIPv6 generates extra if no route
     optimization signaling overhead between the previous access router and new access router is done on handover.

     Goal #3: Location privacy is preserved for HI/HAck exchange. For payload data, external correspondents, but the same considerations as for
     Requirement #4 are applicable.

     Requirement #6 FMIPv6 requires
     mobile node itself still maintains a local care-of address which a worm or
     other  exploit  could  misuse.  If  the  mobile  node  does  perform  route
     optimization, location privacy may be compromised, and the previous access
     router to share this solution is no
     better than having a security association in order to secure the FBU/FBA
     exchange. In addition, HMIPv6 requires that remote home agent.

     Goal #4: If traffic is not route optimized, the mobile node and MAP share still pays for
     an
     IPsec security association in order over-the-air tunnel to secure LBU/LBA exchange. the locally assigned home agent. The only
     well understood approach to set up an IPsec security association using of
     certificates, but this may raise deployment issues. Thus, overhead here
     is exactly the combination of
     FMIPv6 and HMIPv6 doubles same as if the amount of mobile node to node's home agent in the home network security
     protocol required, since security for both FMIP and HMIP must be deployed.

     Requirement #7 HMIPv6 and FMIPv6 support multiple wireless technologies, so
     this requirement
     is fufilled.

     Requirement  #8  The  mobile  node  must  support  both  HMIPv6 used and  FMIPv6
     protocols, so this requirement route optimization is not fulfilled.

     Requirement #9 Currently there done.

     Goal #5: If the localized mobility management domain is large, the mobile
     node may suffer from unoptimzed routes. RFC 3775 [6] provides no IPv4 version of HMIPv6. There is an
     IPv4 version of FMIP but it is not clear how it could be used together with
     FMIPv6 in order to handle fast handovers across any wired network.

  3.4 Micromobility Protocols

     Researchers have defined some protocols support for
     notifying a mobile node that are often characterized as
     micromobility  protocols.  Two  typical  protocols  in  this  category  are
     Cellular-IP [22] and HAWAII [23]. Researchers defined these protocols before
     local mobility optimizations another localized home agent is available for Mobile IP such as FMIP and HMIP were
     developed, in order to reduce handover latency.

     Cellular IP and HAWAII a
     more optimized route, or for handing over between home agents. A mobile node
     would have a few things in common.  Both are compatible
     with Mobile IP and are intended to provide perform the full home agent bootstrap procedure, including
     establishing a higher level of handover
     performance in local networks than was previously available new IPsec SA with Mobile IP
     without such extensions as HMIP and FMIP.  Both use host routes installed the new home agent.

     Goal #6: A local home agent in a number of routers within a restricted routing domain. Both define specific
     messaging to update those routes along roaming situation requires the forwarding path and specify how guest mobile
     node to have the messaging is proper credentials to authenticate with the local home
     agent in the serving network. Although the credentials used for network
     access authentication could also be used for mobile service authentication
     and  authorization  if  the  local  home  agent  uses  EAP  over  IKEv2  to update
     authenticate the routing tables mobile node with its home AAA server, the two sets of
     credentials  are  in  principle  different,  and forwarding
     tables along  could  require  additional
     credential provisioning. In addition, as in Goal #3, if binding updates are
     done in cleartext over the path between access network or the mobile node has become
     infected with malware, the local home agent's address could be revealed to
     attackers and the local home agent could become the target of a micromobility domain boundary
     router at which point Mobile DoS attack.
     So a local home agent would provide no benefit for this goal.

     Goal #7: This solution supports multiple wireless technologies in separate
     IP link subnets. No special work is required to used interface a local home agent
     to handle scalable global
     mobility. Unlike the FMIP different wireless technologies.

     Goal #8: The mobile node must support Mobile IPv6 in order for this option
     to work. So mobile node changes are required and HMIP protocols, however, these other IP mobility protocols do
     are not require supported.

     Goal #9: The Mobile IPv6 working group is working on modifying the protocol
     to allow registration of IPv4 care-of addresses in an IPv6 home agent, and
     also to allow a mobile node to obtain a new have an IPv4 care of address on each [19].

     Goal #10 This solution re-uses an existing protocol, Mobile IPv6.

  9.2     Hierarchical Mobile IPv6 (HMIPv6)

     HMIPv6  [21]  provides  the  most  complete  localized  mobility  management
     solution available today as an RFC. In HMIPv6, a localized mobility anchor
     called a MAP serves as a routing anchor for a regional care-of address. When
     a mobile node moves from one access router as it moves; but rather, to another, the mobile node maintains
     changes the same care of binding between its regional care-of address across the micromobility domain. From outside and local care-of
     address at the micromobility
     domain, MAP. No global mobility management signaling is required,
     since the care of care-of address seen by correspondents does not change. This part
     of HMIPv6 is routed using traditional longest prefix
     matching IP routing similar to the domain's boundary router, solution outlined in Section 9.1; however,
     HMIPv6 also allows a mobile node to hand over between MAPs.

     Handover between MAPs and MAP discovery requires configuration on the
     routers. MAP addresses are advertised by access routers. Handover happens by
     overlapping MAP coverage areas so that, for some number of access routers,
     more than one MAP may be advertised. Mobile nodes need to switch MAPs in the care
     transition area, and then must perform global mobility management update and
     route optimization to the new regional care-of address, if appropriate.

     The analysis of address
     conceptually this approach against the goals above is within the micromobiity domain boundary router's subnet.

     Within following.

     Goal #1 This solution shortens, but does not eliminate, the micromobility domain, latency
     associated with IP link handover, since it reduces the care amount of address is routed to the
     correct access router using host routes.

     Cellular IP signaling
     and HAWAII differ in a few aspects.  Cellular IP seems to be
     restricted, based on the nature length of the protocol, to tree-based network
     topologies.  HAWAII claims to be applicable in both tree-based and more
     complete network topologies.  HAWAII documents more functionality in signaling paths.

     Goal #2 Signaling volume is reduced simply because no route optimization
     signaling is done on handover within the
     realm coverage area of reliability and QoS interworking.  Both protocols involve the MAP.

     Goal #3 Location privacy is preserved for external correspondents, but the
     mobile node itself in mobility operations, although this is also true of the
     Mobile IP based optimizations, so both protocols raise still maintains a local care-of address which a worm or
     other exploit could access by sending the same security
     concerns with respect to authorizing local care-of address update as to third
     malicious node to enable it to track the Mobile IP based
     optimizations.    HAWAII  provides  some  analysis  of  network  deployment
     scenarios including scale, density, and efficiency, but some of these
     assumptions seem very conservative compared mobile node's location.

     Goal #4 The mobile node always pays for an over-the-air tunnel to realistic cellular type
     deployments.

     Micromobility protocols have some potential drawbacks from the MAP.
     If the mobile node is tunneling through a deployment and
     scalability standpoint. Both protocols involve every routing element between global home agent or VPN gateway,
     the mobile device wired link experiences double tunneling. Over-the-air tunnel overhead
     can be removed by header compression, however.

     Goal #5 From Goal #1 and Goal #4, the micromobility domain boundary router in all packet
     forwarding decisions specific to care of addresses signaling overhead is no more or less
     than for mobile nodes.
     Scalability nodes whose global mobility management anchor is limited local.
     However, because each care MAP handover is possible, routes across large localized
     mobility management domains can be improved thereby improving wired network
     resource utilization by using multiple MAPs and handing over, at the expense
     of address corresponding to  the  configuration  and  management  overhead  involved  in  maintaining
     multiple MAP coverage areas.

     Goal #6 In a roaming situation, the guest mobile node generates a routing table entry, and perhaps multiple forwarding
     table entries, must have the proper
     credentials to authenticate with the MAP in every router along the path. Since serving network. In
     addition, since the mobile nodes can node is required to have
     multiple global care of addresses in IPv6, this can result in a large
     expansion in router state throughout unicast address for
     the micromobility MAP that is either globally routed or routing domain.
     Although restricted to the extent local
     administrative domain, the MAP is potentially a target for DoS attacks
     across a wide swath of network topology.

     Goal #7 This solution supports multiple wireless technologies in separate IP
     link subnets.

     Goal #8 This solution requires modification to the scalability mobile nodes. In
     addition, the HMIPv6 design has been optimized for micromobility protocols Mobile IPv6 mobile nodes,
     and is not a good match for other global mobility management protocols.

     Goal #9 Currently, there is no IPv4 version of this protocol; although there
     is still
     not clearly understood from an expired Internet draft with a research standpoint, it seems certain design for a regional registration
     protocol for Mobile IPv4 that has similar functionality. It is possible that
     they will be less scalable than
     the same IPv4 transition solution as used for Mobile IP optimization enhancements, and
     will require more specialized gear IPv6 could be used
     [19].

     Goal #10 This solution re-uses an existing protocol, HMIPv6.

  9.3 Combinations of Mobile IPv6 with Optimizations

     One approach to local mobility that has received much attention in the wired network.

     The following is past
     and has been thought to provide a gap analysis solution is combinations of protocols. The
     general approach is to try to cover gaps in the micromobility protocols against the
     requirements solution provided by MIPv6
     by using other protocols. In this section, gap analyses for MIPv6 + FMIPv6
     and HMIPv6 + FMIPv6 are discussed.

  9.3.1 MIPv6 + FMIPv6

     As discussed in Section 2.0:

     Requirement #1 The micromobility protocols reduce handover latency by
     quickly fixing up routes between 9.1, the boundary router and use of MIPv6 with a dynamically assigned,
     local home agent cannot fulfill the access router.
     While some additional latency may be expected during host route propagation,
     it goals. A fundamental limitation is typically much less than experienced with standard that
     Mobile IP.

     Requirement #2 The micromobility protocols require signaling from IPv6 cannot provide seamless handover (i.e. Goal #1). FMIPv6 has been
     defined with the mobile
     node intent to improve the access router to initiate handover performance of MIPv6. For
     this reason, the host route propagation, but combined usage of FMIPv6 and MIPv6 with a dynamically
     assigned local home agent has been proposed to handle local mobility.

     Note that this gap analysis only applies to localized mobility management,
     and it is a considerable reduction over the amount possible that MIPv6 and FMIPv6 might still be acceptable for
     global mobility management.

     The analysis of signaling required to
     configure to a new IP link.

     Requirement #3 No care-of address changes are exposed to correspondent nodes
     or this combined approach against the  mobile  node  itself  while goals follows.

     Goal #1 FMIPv6 provides a solution for handover performance improvement that
     should fulfill the  mobile  node  is  moving goals raised by real-time applications in terms of
     jitter, delay and packet loss. The location of the
     micromobility-managed network. Because there is no home agent (in local care-of address,
     there is no threat from malware that exposes or
     home domain) does not affect the location by sending handover latency.

     Goal #2 FMIPv6 requires the
     care-of address mobile node to an adversary.

     Requirement #4 The only additional over-the-air perform extra signaling is involved with the
     access router (i.e. exchange of RtSolPr/PrRtAdv and FBU/FBA). Moreover, as
     in
     propagating host routes from standard MIPv6, whenever the mobile node moves to the network upon movement.

     Since this signaling would be required for movement detection in any case, another IP link, it is expected
     must send a Binding Update to be minimal. Mobile node traffic experiences no overhead.

     Requirement #5 Host the home agent. If route propagation optimization is required throughout the wired
     network. The volume of signaling could be more or less depending on used,
     the
     speed of mobile node movement also performs return routability and the size of the wired network.

     Requirement #6 The mobile node only requires sends a security association Binding Update
     to each correspondent node. Nonetheless, it is worth noting that FMIPv6
     should result in a reduction of some
     type with the access router. Because the amount of IPv6 Neighbor Discovery
     signaling is causing routes to on the new link.

     Goal #3 The mobile  node's node mantains a local care-of address. If route
     optimization is not used, location privacy can be achieved using bi-
     directional tunneling. However, as mentioned in Section 9.1, a worm or other
     malware can exploit this care of address by sending it to  change, a third malicious
     node.

     Goal #4 As stated for Goal #2, the combination of MIPv6 and FMIPv6 generates
     extra signaling  must  prove
     authorization overhead. For data packets, in addition to hold the address.

     Requirement  #7  The  micromobility  protocols  support  multiple  wireless
     technologies, so this requirement Mobile IPv6
     over-the-air tunnel, there is satisfied.

     Requirement #8 The a further level of tunneling between the
     mobile node must support some way of signaling and the previous access router on link handover, but this during handover. This tunnel is required for movement detection anyway.
     The nature of the signaling for
     needed to forward incoming packets to the micromobility protocols may mobile node
     software changes, however.

     Requirement #9  Most of the work on the micromobility protocols was done in
     IPv4, but little difference could be expected for IPv6.

  3.5 Standard Internal Gateway Route Distribution Protocols (OSPF and IS-IS)

      It  has  also  been  suggested  that  instead  of  using  a  specialized
     micromobility  routing  protocol  in  the  access  network,  a  standardized
     Internal Gateway route distribution Protocol (IGP) such as IS-IS [25] or
     OSPF [26] should be used addressed to distribute host routes. Host route messages are
     formatted in the IGPs by including a subnet mask in the route information
     update, indicating that the address
     previous care-of address. Another reason is that, even if the mobile node
     has a /32 for IPv4 or a /128 for IPv6
     instead valid new care-of address, the mobile node cannot use the new care of  a  subnet  prefix.  Since  IGPs  typically  distribute
     address  directly  with  its  correspondents  without  performing  route
     information by flooding, every router in
     optimization to the domain obtains a copy new care of address. This implies that the
     host transient
     tunnel overhead is in place even for route eventually. Using an IGP instead of a micromobility protocol has optimized traffic.

     Goal #5 FMIPv6 generates extra signaling overhead between the advantage that standardized routing equipment can be used for all
     routers in previous
     access router and the new access network, and, if a particular router goes down, for the
     host routes maintained along alternate routes should be sufficient to
     continue routing, unlike micromobility protocols where only targeted routers
     have HI/HAck exchange. Concerning
     data packets, the host routes.

     Distributing host routes with an IGP has some significant disadvantages
     however. One is that flooding requires a certain amount use of time to converge;
     so FMIPv6 for some period after the link handover blackout, delivery to performance improvement implies
     a tunnel between the previous access router and the mobile node that has moved will be disrupted until convergence along the routes
     traveled by adds
     some overhead in the mobile node's traffic wired network. This overhead has occurred. Because micromobility
     protocols target host routes back more impact on star
     topology deployments, since packets are routed down to the micromobility domain border old access
     router,
     convergence can potentially be achieved more quickly. Tunnel-based solutions
     such as HMIP don't suffer from convergence latency because only then back up to the two
     endpoints need aggregation router and then back down to know the routing.  As a result, new
     access router.

     Goal #6 In addition to the internal routing
     tables updated by analysis for Mobile IPv6 with local home agent in
     Section 9.1, FMIPv6 requires the IGP remain stable when a mobile node moves. The
     movement does not affect routing of traffic and the previous access router
     to other share a security association in order to secure FBU/FBA exchange. So far,
     only a SEND-based solution has been proposed and this requires the mobile nodes due
     node to
     intensive path computation.

     Another disadvantage of use autoconfigured Cryptographically Generated Addresses (CGAs)[22].
     This precludes stateful address allocation using an IGP DHCP, which might be a
     necessary deployment in certain circumstances. Another solution based on AAA
     is that each router under study but it could require extra signaling overhead over the air
     and in the domain must
     maintain a full host route table for all hosts. This requirement raises a
     scalability issue. For example, an experiment [24]  using OSPF to distribute
     host routes through an access wired network consisting of a collection of rather
     smallish enterprise routers indicated that about 25,000 routes and it could be
     supported in 22 Mb of memory before raise performance started to degrade. This
     works out issues.

     Goal #7 MIPv6 and FMIPv6 support multiple wireless technologies, so this
     goal is fufilled.

     Goal #8 The mobile node must support both MIPv6 and FMIPv6, so it is not
     possible to about 0.88 kb/host. Scaling satisfy this up to, say, 10 million hosts
     (what one might expect in a large metropolitan area such as Tokyo or San
     Francisco) would require about 8.8 Gb of memory per router. While memory
     costs continue goal.

     Goal #9 Work is underway to drop, extend MIPv6 with the amount capability to run over
     both IPv6-enabled and IPv4-only networks [19]. FMIPv6 only supports IPv6.
     Even though an IPv4 version of processing power for searching a
     routing database FMIP has been recently proposed, it is not
     clear how it could be used together with FMIPv6 in order to handle fast
     handovers across any wired network.

     Goal #10 This solution re-uses existing protocols, Mobile IPv6 and FMIPv6.

  9.3.2 HMIPv6 + FMIPv6

     HMIPv6 provides several advantages in terms of that size essentially means that each router local mobility management.
     However, as seen in Section 9.2, it does not fulfill all the
     domain must have goals
     identified in Section 2.0. In particular, HMIPv6 does not completely
     eliminate the same processing power as a high end, border router.
     Micromobility and tunnel- based solutions don't suffer from IP link handover latency. For this problem,
     because the host route is local to the tunnel endpoints. Other routers reason, FMIPv6 could be
     used together with HMIPv6 in order to cover the domain route based on highly scalable shortest matching network prefix
     method.

     The following gap.

     Note that even if this solution is a gap analysis of host route distribution using a
     standardized IGP against used, the requirements in Section 2.0:

     Requirement #1 Host route distribution using an IGP mobile node is likely to suffer from
     increased handover latency due to a lag time as routes converge over need
     MIPv6 for global mobility management, in contrast with the
     access network. MIPv6 with
     dynamically assigned local home agent + FMIPv6 solution. Thus, this solution
     should really be considered MIPv6 + HMIPv6 + FMIPv6.

     The exact amount of latency depends on the convergence
     characteristics analysis of this combined approach against the particular IGP goals follows.

     Goal #1 HMIPv6 and FMIPv6 both shorten the topology of latency associated with IP link
     handovers. In particular, FMIPv6 is expected to fulfill the access
     network, i.e. how fast convergence occurs along routes taken goals on jitter,
     delay and packet loss raised by the mobile
     node's traffic.

     Requirement real-time applications.

     Goal #2 Host route distribution using an IGP requires Both FMIPv6 and HMIPv6 require extra signaling from compared with Mobile
     IPv6. As a whole the mobile node to performs signaling message exchanges at
     each handover that are RtSolPr/PrRtAdv, FBU/FBA, LBU/LBA and BU/BA. However,
     as mentioned in Section 9.2, the access router to initiate use of HMIPv6 reduces the host signaling
     overhead since no route propagation,
     but that optimization signaling is a considerable reduction over done for intra-MAP
     handovers. In addition, na´ve combinations of FMIPv6 and HMIPv6 often result
     in redundant signaling. There is much work in the amount academic literature and
     the IETF on more refined ways of combining signaling required
     to configure to a new IP link. However, if a mobile node is moving quickly, from the flooding traffic necessary two protocols
     to propagate a host route avoid redundant signaling.

     Goal #3 HMIPv6 may not converge
     before preserve location privacy, depending on the dimension of
     the geographic area covered by the MAP. As discussed in Section 9.2, the
     mobile node hands over again. This could result in still maintains a cacscading
     series of host route updates local care-of address that never converge. Whether can be exploited by
     worms or not this effect
     occurs depends on the size of the localized mobility domain, and so the need
     to ensure convergence places an upper bound on other malware.

     Goal #4 As mentioned for Goal #2, the size combination of the domain or
     expected movement speed HMIPv6 and FMIPv6
     generates a lot of signaling overhead in the mobile nodes.

     Requirement #3 No care-of address changes are exposed network. Concerning payload
     data, in addition to correspondent nodes
     or the mobile node itself while the over-the-air MIPv6 tunnel, a further level of
     tunneling is established between mobile node and MAP. Notice that this
     tunnel is moving in the localized
     mobility management domain. Because there place even for route optimized traffic. Moreover, if FMIPv6 is no local care-of address,
     directly applied to HMIPv6 networks, there is no threat from malware that exposes a third temporary handover-
     related tunnel between the location by sending mobile node and previous access router. Again,
     there is much work in the care-of
     address academic literature and IETF on ways to an adversary.

     Requirement #4 reduce the
     extra tunnel overhead on handover by combining HMIP and FMIP tunneling.

     Goal #5 The only additional over-the-air signaling involved overhead in the network is not reduced by HMIPv6, as
     mentioned in Section 9.2. Instead, FMIPv6 generates extra signaling from the mobile node to overhead
     between the previous access router indicating that and new access router for HI/HAck
     exchange. For payload data, the same considerations as for Goal #4 are
     applicable.

     Goal #6 FMIPv6 requires the mobile node has moved. Mobile node traffic experiences no overhead.

     Requirement #5 Host route propagation is required throughout and the wired
     network. The volume of signaling could be more or less depending on previous access router to
     share a security association in order to secure the FBU/FBA exchange. In
     addition, HMIPv6 requires that the
     speed of mobile node movement and the size of the wired network.

     Requirement #6 MAP share an IPsec
     security association in order to secure LBU/LBA exchange. The mobile node only requires a well
     understood approach to set up an IPsec security association using of some
     type with the access router. Because
     certificates, but this may raise deployment issues. Thus, the signaling is causing routes to combination of
     FMIPv6 and HMIPv6 doubles the amount of mobile  node's  care-of  address node to  change,  the  signaling network security
     protocol required, since security for both FMIP and HMIP must  prove
     authorization to hold the address.

     Requirement be deployed.

     Goal #7 This requirement HMIPv6 and FMIPv6 support multiple wireless technologies, so this
     goal is satisfied by default, since the IGPs are
     used over the wired backbone.

     Requirement fufilled.

     Goal #8 The mobile node needs to perform some kind of active movement
     detection with proof of identity to trigger the host route distribution, but must support both HMIPv6 and FMIPv6 protocols, so
     this kind goal is not fulfilled.

     Goal #9 Currently there is no IPv4 version of signaling HMIPv6. There is needed for movement regardless an IPv4
     version of whether
     localized mobility management FMIP but it is deployed. Depending on the wireless link
     type, this may not clear how it could be handled by the wireless link layer.

     Requirement #9  Since the IGPs support both IPv4 used together with
     FMIPv6 in order to handle fast handovers across any wired network.

     Goal #10 This solution re-uses existing protocols, HMIPv6 and IPv6, both FMIPv6.

  9.4 Micromobility Protocols

     Researchers have defined some protocols that are
     supported by often characterized as
     micromobility  protocols.  Two  typical  protocols  in  this technique.

   4.0    Security Considerations

     There  category  are two kinds of security issues involved in network-based localized
     mobility management: security between the mobile node
     Cellular-IP [23] and the network, HAWAII [24]. Researchers defined these protocols before
     local mobility optimizations for Mobile IP such as FMIP and
     security between network elements that participate HMIP were
     developed, in the network-based order to reduce handover latency.

     The micromobility approach to localized mobility management protocol

     Security between requires host
     route propagation from the mobile node and the network itself consists to a collection of two
     parts: threats involved specialized
     routers in the localized mobility management in general, and
     threats domain along a path back to a
     boundary router at the edge of the network-based localized mobility management from domain. A
     boundary router is a kind of localized mobility management domain gateway.
     Localized mobility management is authorized with the host.
     The first access router, but
     reauthorization with each new access router is discussed above necessary on IP link
     movement, in Sections 2.3 and 2.6. addition to any reauthorization for basic network access. The second is
     discussed in
     host routes allow the threat analysis document [27].

     For threats mobile node to network-based localized mobility management, maintain the basic threat
     is an attempt by an unauthorized party same IP address when it
     moves to signal a bogus mobility event.
     Such an event must be detectable. This requires proper bidirectional
     authentication new IP link, and authorization still continue to receive packets on the new IP
     link.

     Cellular IP and HAWAII have a few things in common.  Both are compatible
     with Mobile IP and are intended to provide a higher level of network elements that participate handover
     performance in local networks than was previously available with Mobile IP
     without such extensions as HMIP and FMIP.  Both use host routes installed in
     a number of routers within a restricted routing domain. Both define specific
     messaging to update those routes along the forwarding path and specify how
     the messaging is to be used to update the
     network-based  localized  mobility  management  protocol, routing tables and  data  origin
     authentication on forwarding
     tables along the signaling traffic path between network elements.

   5.0    Recommendation

     In view of the gap analysis in Section 3.0, none of the existing solutions
     provide complete coverage of the requirements. FMIPv6 provides mobile and a complete
     solution micromobility domain boundary
     router at which point Mobile IP is to Requirement 3.1 but used to no other requirement. FMIP, HMIP handle scalable global
     mobility. Unlike the FMIP and
     micromobility HMIP protocols, however, these protocols do
     not require that the mobile node is modified to support the
     additional functionality. But as analyzed above, the functionality provided
     by obtain a new care of address on each protocol is does not fully support access
     router as it moves; but rather, the set of requirements discussed
     in Section 2.0.

     We  therefore  recommend  that  a  new,  network  based  localized  mobility
     management protocol be developed that minimizes or eliminates mobile node
     involvement in localized mobility management. Such a localized mobility
     management protocol can be treated as part maintains the same care of
     address across the network infrastructure.
     This kind micromobility domain. From outside the micromobility
     domain, the care of architecture address is required routed using traditional longest prefix
     matching IP routing to the domain's boundary router, so the care of address
     conceptually is within the gaps with existing
     protocols described in Section 3.0. The new localized mobility management
     protocol can be paired with a link layer specific IP link handover
     optimization protocol, such as are provided by wireless LAN switches, or an
     IP link handover optimization protocol, such as FMIPv6, to eliminate
     handover related packet latency. The protocol should minimize micromobiity domain boundary router's subnet.
     Within the number micromobility domain, the care of
     specialized routers address is routed to the
     correct access router using host routes.

     Cellular IP and HAWAII differ in the localized mobility management domain a few aspects.  Cellular IP seems to reduce be
     restricted, based on the amount nature of state update needed upon movement and the protocol, to allow standardized tree-based network equipment
     topologies.  HAWAII claims to be used where mobility support is not required.

     With applicable in both tree-based and more
     complete network topologies.  HAWAII documents more functionality in the
     realm of reliability and QoS interworking.  Both protocols involve the edge mobility approach, a
     mobile node has a single itself in mobility operations, although this is also true of the
     Mobile IP based optimizations, so both protocols raise the same security
     concerns with respect to authorizing address that
     does not change when update as the mobile node moves Mobile IP based
     optimizations.    HAWAII  provides  some  analysis  of  network  deployment
     scenarios including scale, density, and efficiency, but some of these
     assumptions seem very conservative compared to realistic cellular type
     deployments.

     Micromobility protocols have some potential drawbacks from one access a deployment and
     scalability standpoint. Both protocols involve every routing element between
     the mobile device and the micromobility domain boundary router in all packet
     forwarding decisions specific to
     another, care of addresses for mobile nodes.
     Scalability is limited because the mobility anchor and access routers take each care of
     changing the routing. An edge mobility approach does not require address corresponding to a separate
     security association with
     mobile node generates a network element, reducing routing table entry, and perhaps multiple forwarding
     table entries, in every router along the path. Since mobile nodes can have
     multiple global care of addresses in IPv6, this can result in a large
     expansion in router state throughout the micromobility routing domain.
     Although the amount extent of overhead
     required to get a connection up on the network. In an edge mobility approach,
     mobile nodes only have link local addresses scalability for access routers, so it is
     much more difficult to mount off-link DoS attacks, and on-link attacks are
     easier to trace and stop. With the edge mobility approach, no authentication
     and authorization micromobility protocols is necessary beyond still
     not clearly understood from a research standpoint, it seems certain that necessary for initial network
     access and whatever additional authentication and authorization is required
     by the wireless link layer upon movement between access points.

   6.0 Author Information

        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
        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

   7.0 Informative References

       [1] Kempf, J., Leung, K., Roberts, P., Nishda, K., Giaretta, G., Liebsch,
           M., and Gwon, Y., "Problem Statement for IP Local Mobility," Internet
           Draft, work in progress.
       [2] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC 3753,
           June, 2004.
       [3] Devarapalli,V., Wakikawa, R., Petrescu, A., Thubert, P., "Network
           Mobility (NEMO) Basic Support Protocol", RFC 3963, January, 2005.
       [4] Carpenter, B., "Architectural Principles of
     they will be less scalable than the Internet," RFC 1958,
           June, 1996.
       [5] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in IPv6",
           RFC 3775.
       [6] Moskowitz, R., Nikander, P., Jokela, P., Mobile IP optimization enhancements, and Henderson, T., "Host
           Identity Protocol", Internet Draft, work
     will require more specialized gear in progress.
       [7] Choi, J, and Daley, G., " Goals the wired network.

     The following is a gap analysis of Detecting Network Attachment in
           IPv6", Internet Draft, work in progress.
       [8] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard 802.1x, June,
           2001.
       [9] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and Yegin, A.,
           "Protocol for Carrying Authentication for Network Access (PANA)",
           Internet Draft, work the micromobility protocols against the
     goals in progress.
      [10] Arkko, J., Kempf, J., Zill, B., Section 2.0:

     Goal #1 The micromobility protocols reduce handover latency by quickly
     fixing up routes between the boundary router and Nikander, P., "SEcure Neighbor
           Discovery (SEND)", RFC 3971, March, 2005.
      [11] Moore, N., "Optimistic Neighbor Discovery", Internet Draft, Work the access router. While
     some additional latency may be expected during host route propagation, it is
     typically much less than experienced with standard Mobile IP.

     Goal #2 The micromobility protocols require signaling from the mobile node
     to the access router to initiate the host route propagation, but that is a
     considerable reduction over the amount of signaling required to configure to
     a new IP link.

     Goal #3 No care-of address changes are exposed to correspondent nodes or the
     mobile node itself while the mobile node is moving in
           Progress.
      [12] Ackerman, L., Kempf, J., and Miki, T., "Wireless Location Privacy: Law
           and Policy the micromobility-
     managed network. Because there is no local care-of address, there is no
     threat from malware that exposes the location by sending the care-of address
     to an adversary.

     Goal  #4  The  only  additional  over-the-air  signaling  is  involved  in
     propagating host routes from the US, EU, and Japan", ISOC Member Briefing #15,
           http://www.isoc.org/briefings/015/index.shtml
      [13] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., Park, S.D., and
           Patil, B., "Privacy mobile node to the network upon movement.
     Since this signaling would be required for Mobile and Multi-homed Nodes: MoMiPriv Problem
           Statement", Internet Draft, work movement detection in progress.
      [14] Kivinen, T., and Tschopfening, H., "Design any case,
     it is expected to be minimal. Mobile node traffic experiences no overhead.

     Goal #5 Host route propagation is required throughout the wired network. The
     volume of signaling could be more or less depending on the MOBIKE Protocol",
           Internet Draft, work in progress.
      [15] Koodli, R., "IP Address Location Privacy and IP Mobility", Internet
           Draft, work in progress.
      [16] Koodli, R., Devarapalli, V., Flinck, H., speed of mobile
     node movement and Perkins, C., "Solutions the size of the wired network.

     Goal #6 The mobile node only requires a security association of some type
     with the access router. Because the signaling is causing routes to the
     mobile  node's  care-of  address  to  change,  the  signaling  must  prove
     authorization to hold the address.

     Goal #7 The micromobility protocols support multiple wireless technologies,
     so this goal is satisfied.

     Goal #8 The mobile node must support some way of signaling the access router
     on link handover, but this is required for movement detection anyway. The
     nature of the signaling for IP Address Location Privacy in the presence micromobility protocols may mobile node
     software changes, however.

     Goal #9  Most of IP Mobility",
           Internet Draft, the work on the micromobility protocols was done in progress.
      [17] Bao, F., Deng, R., Kempf, J., Qui, Y., and Zhou, J., "Protocol IPv4,
     but little difference could be expected for
           Protecting Movement of Mobile Nodes in Mobile IPv6", IPv6.

     Goal #10 This solution does not reuse an existing protocol because there is
     currently no Internet Draft,
           work in progress.
      [18] Soliman, H., Tsirtsis, G., Devarapalli, V., Kempf, J., Levkowetz, H.,
           Thubert, P, and Wakikawa, R. "Dual Stack Mobile IPv6 (DSMIPv6) Standard protocol for
           Hosts micromobility.

  9.5 Standard Internal Gateway Route Distribution Protocols (OSPF and Routers", Internet Draft, work IS-IS)

      It  has  also  been  suggested  that  instead  of  using  a  specialized
     micromobility  routing  protocol  in progress.
      [19] Koodli, R., editor, "Fast Handovers for Mobile IPv6", RFC 4068, July,
           2005.
      [20] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L.,
           "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140,
           August, 2005.
      [21] Kempf, J., and Koodli, R., "Bootstrapping  the  access  network,  a Symmetric IPv6 Handover Key
           from SEND", Internet Draft, work  standardized
     Internal Gateway route distribution Protocol (IGP) such as IS-IS [26] or
     OSPF [27] should be used to distribute host routes. Host route messages are
     formatted in progress.
      [22] Campbell, A., Gomez, J., Kim, S., Valko, A., and Wan, C., "Design,
           Implementation and Evaluation of Cellular IP", IEEE Personal
           Communications, June/July 2000.
      [23] Ramjee, R., La Porta, T., Thuel, S., and Varadhan, K., "HAWAII: A
           domain-based approach the IGPs by including a subnet mask in the route information
     update, indicating that the address is a /32 for supporting mobility IPv4 or a /128 for IPv6
     instead  of  a  subnet  prefix.  Since  IGPs  typically  distribute  route
     information by flooding, every router in wide-area wireless
           networks", the domain obtains a copy of the
     host route eventually. Using an IGP instead of a micromobility protocol has
     the advantage that standardized routing equipment can be used for all
     routers in Proceedings the access network, and, if a particular router goes down, the
     host routes maintained along alternate routes should be sufficient to
     continue routing, unlike micromobility protocols where only targeted routers
     have the host routes.

     Distributing host routes with an IGP has some significant disadvantages
     however. One is that flooding requires a certain amount of time to converge;
     so for some period after the International Conference on Networking
           Protocols (ICNP), 1999.
      [24] "Mobile VPN Network Configuration Alternatives", IP Unplugged,
           http://www.ipunplugged.com/pdf/Network-blueprints_A.pdf.
      [25] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142,
           Feburary, 1990.
      [26] Moy, J., "OSPF Version 2", STD 54, April, 1998.
      [27] Threat analysis draft, TBD

   8.0 IPR Statements

     The  IETF  takes  no  position  regarding link handover blackout, delivery to a mobile
     node that has moved will be disrupted until convergence along the  validity  or  scope routes
     traveled by the mobile node's traffic has occurred. Because micromobility
     protocols target host routes back to the micromobility domain border router,
     convergence can potentially be achieved more quickly. Tunnel-based solutions
     such as HMIP don't suffer from convergence latency because only the two
     endpoints need to know the routing.  As a result, the internal routing
     tables updated by the IGP remain stable when a mobile node moves. The
     movement does not affect routing of  any
     Intellectual Property Rights or traffic to other rights mobile nodes due to
     intensive path computation.

     Another disadvantage of using an IGP is that might each router in the domain must
     maintain a full host route table for all hosts. This goal raises a
     scalability issue. For example, an experiment [25]  using OSPF to distribute
     host routes through an access network consisting of a collection of rather
     smallish enterprise routers indicated that about 25,000 routes could be claimed
     supported in 22 Mb of memory before performance started to
     pertain degrade. This
     works out to the implementation about 0.88 kb/host. Scaling this up to, say, 10 million hosts
     (what one might expect in a large metropolitan area such as Tokyo or use San
     Francisco) would require about 8.8 Gb of memory per router. While memory
     costs continue to drop, the technology described amount of processing power for searching a
     routing database of that size essentially means that each router in the
     domain must have the same processing power as a high end, border router.
     Micromobility and tunnel- based solutions don't suffer from this
     document or problem,
     because the extent host route is local to which any license under such rights might or might
     not be available; nor does it represent that it has made any independent
     effort the tunnel endpoints. Other routers in
     the domain route based on highly scalable shortest matching network prefix
     method.

     The following is a gap analysis of host route distribution using a
     standardized IGP against the goals in Section 2.0:

     Goal #1 Host route distribution using an IGP is likely to identify any such rights. Information suffer from
     increased handover latency due to a lag time as routes converge over the
     access network. The exact amount of latency depends on the procedures with
     respect to rights in RFC documents can be found in BCP 78 and BCP 79.

     Copies convergence
     characteristics of IPR disclosures made to the IETF Secretariat particular IGP and any assurances of
     licenses to be made available, or the result topology of an attempt made to obtain a
     general license or permission for the use of such proprietary rights access
     network, i.e. how fast convergence occurs along routes taken by
     implementers or users of this specification can be obtained the mobile
     node's traffic.

     Goal #2 Host route distribution using an IGP requires signaling 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
     mobile node to implement this standard.
     Please address the information access router to initiate the IETF at ietf-ipr@ietf.org.

   9.0Disclaimer 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.

   10.0   Copyright Notice

     Copyright (C) The Internet Society (2006).  This document host route propagation, but
     that is subject a considerable reduction over the amount of signaling required to
     configure to a new IP link. However, if a mobile node is moving quickly, the
     rights, licenses and restrictions contained in BCP 78, and except as set
     forth therein,
     flooding traffic necessary to propagate a host route may not converge before
     the authors retain all their rights.

   11.0   Changes mobile node hands over again. This could result in 01 (remove before publication)

     - Changed wording so as a cacscading series
     of host route updates that never converge. Whether or not this effect occurs
     depends on the size of the localized mobility domain, and so the need to seem to exclude
     ensure convergence places an upper bound on the size of the domain or
     expected movement speed of the mobile routers;

         . Changed "host" nodes.

     Goal #3 No care-of address changes are exposed to "mobile node" when correspondent nodes or the wireless device
     mobile node itself while the mobile node is meant,
         . Changed "host" or "host-based" when moving in the localized mobility
     management domain. Because there is
         described no local care-of address, there is no
     threat from malware that exposes the location by sending the care-of address
     to an adversary.

     Goal #4 The only additional over-the-air signaling involved is signaling
     from the mobile node to the access router indicating that the mobile node
     has moved. Mobile node traffic experiences no overhead.

     Goal #5 Host route propagation is required throughout the wired network. The
     volume of signaling could be "mobile node",

         . Removed definition for "host" more or less depending on the speed of mobile
     node movement and added the size of the wired network.

     Goal #6 The mobile node only requires a definition to Section 1.1
         for "mobile node" to indicate that security association of some type
     with the end device access router. Because the signaling is meant to apply causing routes to the
     mobile routers that use a global mobility management protocol such as
         NEMO in addition to terminals,

     - Modified Section 2.7  node's  care-of  address  to indicate that support for multiple wireless link
     technologies is not meant  change,  the  signaling  must  prove
     authorization to include keeping hold the same IP address when a new
     wireless interface address.

     Goal #7 This goal is activated on satisfied by default, since the mobile device,

     - Modified Section 2.8 to indicate that unmodified IGPs are used over the
     wired backbone.

     Goal #8 The mobile node support is
     meant needs to apply only perform some kind of active movement
     detection with proof of identity to localized mobility management, and trigger the host route distribution, but
     this kind of signaling is not meant to
     exclude global needed for movement regardless of whether
     localized mobility management or driver changes needed to support
     handover at is deployed. Depending on the wireless link layer,

     - Changed the text in Section 4.0 to clarify
     type, this may be handled by the difference in wireless link layer.

     Goal #9  Since the threat
     from host-side malware for global mobility protocols such as Mobile IPv6 and
     localized mobility management,
     - Rewrote Section 4 to remove text that duplicates discussions in Section
     2.3 and 2.6, IGPs support both IPv4 and focused instead on the threat to IPv6, both are supported by
     this technique.

     Goal #10 This solution re-uses existing protocols, OSPF or IS-IS.

  9.6 Summary

     The following table summarizes the NETLMM protocol
     itself.

     - Added Section 3.5 discussing use of standardized IGPs for host route
        distribution.

     - Added text to each subsection discussion in Section 2 9.1 through 9.5. In
     the table, a "M" indicates that clearly and explicitly
        states the  requirement  for protocol completely meets the  NETLMM  protocol.  Previously, goal, a
     "P" indicates that it partially meets the
        requirements were in some cases only implicit in goal, and an "X" indicates that it
     does not meet the discussion.

     - Added reference to Threat Analysis draft (TBD). goal.

     Protocol     #1    #2    #3    #4    #5    #6    #7    #8    #9    #10
     --------     --    --    --    --    --    --    --    --    --    ---

     MIPv6         P     X     X     X     X     X     M     X     M     M

     HMIPv6        P     X     X     X     P     X     M     X     X     M

     MIPv6 +
     FMIPv6        M     X     X     X     P     X     M     X     P     M

     HMIPv6 +
     FMIPv6        M     X     X     X     X     X     M     X     X     M

     Micro.        M     M     M     M     P     M     M     M     P     X

     IGP           X     M     M     M     X     M     M     M     M     M