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

  Expires: October, December, 2006                                        April,                              June, 2006

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

     Internet-Drafts are draft documents valid for a maximum of six
     months  and  may  be  updated,  replaced,  or  obsoleted  by  other
     documents at any time. It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress."

     The  list  of  current  Internet-Drafts  can  be  accessed  at
     http://www.ietf.org/ietf/1id-abstracts.txt.

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

  Contributors

     Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and
     Marco Liebsch all contributed major effort to this document. Their
     names are not included in the authors' section due to the RFC
     Editor's limit of 5 names.

  Abstract

     In this document, design goals for a network-based localized
     mobility management protocol are discussed.

  Table of Contents

     1.0  Introduction.....................................................2  Introduction.............................................2
     2.0  Goals for Localized Mobility Management..........................2 Management..................2
     3.0  Security Considerations..........................................8  IANA Considerations.....................................10
     4.0  Author Information...............................................9  Security Considerations.................................10
     5.0  Informative References..........................................10  Author's Addresses......................................11
     6.0  IPR Statements..................................................11  Informative References..................................12
     7.0  IPR Statements..........................................13
     8.0  Disclaimer of Validity..........................................12
     8.0  Copyright Notice................................................12 Validity..................................13
     9.0  Copyright Notice........................................14
     10.0 Appendix: Gap Analysis..........................................12 Analysis..................................14

  1.0  Introduction

     In [1], the basic problems that occur when a global mobility
     protocol is used for managing local mobility are described, and three two
     basic approaches to localized mobility management - the host-based
     approach that is used by most IETF protocols, and the proprietary
     WLAN switch approach, and using a standard routing
     IGP to distribute host routes approach used between WLAN switches in different
     subnets - are examined. The conclusion from the problem statement
     document is that none of the approaches has a complete solution to
     the problem. While the WLAN switch approach is most convenient for
     network operators and users because it requires no software on the
     mobile  node support,  other  than  the  standard  drivers  for  WiFi,  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 goals for a network-based
     localized mobility management protocol. In Section 2.0, we review a
     list of goals that are desirable in a network-based localized
     mobility management solution. Section 3.0 briefly outlines security
     considerations. More discussion of security can be found in the
     threat analysis document [2]. The architecture of the NETLMM
     protocol for which the goals in this document have been formulated
     is described in Section 4 of [1].

  1.1 Terminology

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

  2.0  Goals for Localized Mobility Management

     Section 2 of [1] describes three problems with using a global
     mobility management protocol for localized mobility management. Any
     localized mobility solution management protocol must naturally address the these
     three problems
     described in [1]. problems. In addition, the side effects of introducing such a
     solution into the network need to be limited. In this section, we
     address goals on a localized mobility solution including both
     solving the basic problems (Goals 1, 2, 3) and limiting the side effects.
     effects (Goals 4+).

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

     Out of scope for the initial goals discussion are QoS, multicast,
     and dormant mode/paging. While these are important functions for
     mobile nodes, they are not part of the base localized mobility
     management  problem.  In  addition,  mobility  between  localized
     mobility management domains is not covered here. It is assumed that
     this is covered by the global mobility management protocols.

  2.1 Handover Performance Improvement (Goal #1)

     Handover packet loss occurs because there is usually latency
     between when the wireless link handover starts and when the IP link handover
     subnet  configuration  and  global  mobility  management  signaling
     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. they are being forwarded. 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 goal
     for localized mobility management is that the processing delay for
     changing the routing forwarding after handover must approach as closely as
     possible the sum of the delay associated with link layer handover
     and the delay required for active IP layer movement detection, in
     order to avoid excessive packet loss. Ideally, if network-side link
     layer support is available for handling movement detection prior to
     link handover or as part of the link handover process, the routing
     update should complete within the time required for 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 [6] and HIP [7] 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, This delay is difficult to  re-establish  the
     connection, quantify, but there may be substantial packet loss until for voice
     traffic, the problem is
     discovered. Another aspect of this entire handover delay including Layer 2 handover time
     and IP handover time should be between 40-70 ms to avoid any
     degradation in call quality.

     A goal is that of the solution must ensure
     that connectivity protocol is not lost when both ends are mobile and move at the same
     time.

     In both cases, to reduce the loss of accurate routing causes the connection forwarding
     to
     experience an interruption reduce interruptions which may cause user-perceptible service
     degradation for real time traffic such as voice voice.

  2.2 Reduction in Handover-related Signaling Volume (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: performed:

     1) Movement detection using DNA [8] [6] or possibly a link specific
        protocol,
     2) Any link layer or IP layer AAA signaling, such as 802.1x [9] [7] or
        PANA
        [10]. [8]. The mobile node may also or instead have to obtain a
        router  authorization  certificate  using  SEND [11],  [9],  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 [12] [10] is used). used) including for link
        local addresses. 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
     mobility. Step 3 will be necessary even if the mobile node's care-of care-
     of address can remain the same when it moves to a new access
     router. Steps 5 through 7 are only necessary when Mobile IPv6 is
     used.

     The result is approximately 10 messages at the IP level before a
     mobile node can be ensured that it is established on a link and has
     full IP 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 goal is that handover signaling volume from the mobile node to
     the network should be no more than what is needed for the mobile
     node to perform secure IP level movement detection, in cases where
     no link layer support exists. If link layer support exists for IP
     level movement detection, the mobile node may not need to perform
     any additional IP level signaling after handover.

  2.3 Location privacy (Goal #3)

     Although general location privacy issues have been discussed in [14],
     [11], the location privacy referred to here focuses on the IP
     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 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 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 privacy or even cause
     harm to the user. The geographical location information should not
     be revealed to nor be deducible by the correspondent node or an
     eavesdropper without the authorization of
     the mobile node's owner.

     The threats to location privacy come in a variety of forms. Perhaps least
     likely One 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 that. Others are attacks in which the correspondent is the attacker or the correspondent or even the mobile node
     itself is relaying information on the local address change to an attacker.
     The owner of attacker, and the correspondent or deliberately starts a
     session with the mobile node might not even be aware of the
     problem if an attacker has installed spyware or some other kind of exploit
     and the malware is relaying the change in local address order to track its location by
     noting the attacker.
     Host-based  localized  mobility  management  solutions  in  which  the
     correspondent only sees a regional address but the host still maintains a
     local source address are unsatisfactory because they still have a potential for
     malware on of packets originating from the mobile node itself to reveal a change in the local address.
     node. Note that the location privacy referred to here is different
     from the location privacy discussed in [16][17][18]. [14][15][16]. 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.

     In order to reduce the risk from location privacy compromises as a
     result of IP address changes, the goal for NETLMM is to remove the
     need to change IP address as mobile node moves across IP links.
     Keeping the IP address fixed removes any possibility for the
     correspondent node to deduce the precise geographic location of the
     mobile node without the user's authorization, as
     well as any possibility that malware on the mobile node could inadvertently
     reveal the mobile node's location to an attacker. authorization. Note that keeping the
     address constant doesn't completely remove the possibility of
     deducing the geographical location, since a local address still is
     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 is
     somewhere  in  a  large  geographic  area,  like,  for  example,  a
     metropolitan region or even a small country, reducing reducing the possibility that
     the attacker can cause harm to
     granularity of the user. location information.

  2.4 Efficient Use of Wireless Resources (Goal #4)

     Advances in wireless PHY physical layer and MAC medium access control layer
     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. physical layer. 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 it
     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. Header compression also requires
     special software on the host, which may or may not be present.
     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 goal.

     The 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 Limit the Signaling Overhead in the Network (Goal #5)

     While bandwidth and router processing resources are typically not
     as constrained in the wired network, wired access networks tend to have higher
     somewhat stronger 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 (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,

     If the access router deduces mobile node is movement based on active
     IP-level movement detection by the mobile node, then authentication
     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 IP-level movement detection messages from the
     mobile nodes are properly
     authenticated. A properly authenticated node to ensure that the mobile node can either willfully is authorized to possess
     the address used for the movement detection. The authorization may
     be at the IP level or
     inadvertently  give it may be tied to the original network  infrastructural  element  address access
     authentication and wireless link layer authorization for handover.
     Some wireless link layers, especially cellular protocols, feature
     full support and strong security for handover at the link level,
     and require no IP support for handover. If such wireless link
     security is not available, however, then it must be provided at the
     IP level. Security threats to  an
     attacker. the NETLMM protocol are discussed in
     [2].

     In summary, ruling out mobile node involvement in local mobility
     management simplifies security by removing the need for service-specific service-
     specific credentials to authenticate and authorize the mobile node
     for localized mobility management in the network. This puts
     localized mobility management on the same level as basic IP
     routing. Hosts obtain this service as part of their network and by limiting access.
     If the possibility access network policy wants to deny localized mobility
     management to a mobile node, it can do so at the time network
     access authentication occurs, in a manner the reverse of DoS attacks on how some
     networks restrict routing to the Internet before network
     infrastructural elements. access
     authentication and open it afterwards.

     The goal is that support for localized mobility management should
     not require additional security between the mobile node and the network. network other
     than that required for network access or local link security (such
     as SEND [9]).

  2.7 Support for Heterogeneous Wireless Link Technologies (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 physical and MAC medium access control layers is a
     time consuming process, reducing the amount of work necessary to
     interface a particular wireless link technology to an IP network is
     necessary. 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. technologies. It is not required that the
     localized mobility management solution support handover from one
     wireless link technology to another without change in IP address. address,
     but this possibility should not be precluded.

     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 goal 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 (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). 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 supported. There are a variety of global mobility
     management  protocols  that  might  also  need  support,  including
     proprietary or wireless link technology-specific protocols needing
     support for backward compatibility reasons. Within IETF, the Internet,
     both HIP [12] and Mobike [13] are likely to need support in
     addition to Mobile IPv6, and Mobile IPv4 support may also be
     necessary.

     Note that this 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, another and
     maintain session continuity, although no global mobility protocol
     is required if the mobile node only moves within the coverage area
     of  the  localized  mobility  management protocol.  protocol  or  no  session
     continuity is required during global movement. Also, every wireless
     link protocol requires handover support on the mobile node in the
     physical  and MAC  medium  access  control  layers,  typically  in  the
     wireless interface driver. Information passed from the MAC medium
     access control layer to the IP layer on the mobile 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
     medium access control layer. Whether or not such support is
     required depends on whether the MAC medium access control 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 medium access control layer
     prior to handover, so it may be possible to trigger routing update
     without any IP protocol involvement. However, for a wireless link
     protocol such as IEEE 802.11 in which there the decision for handover is no network involvement
     entirely in handover, the hands of the mobile node, IP layer movement
     detection signaling from the mobile node may be required to trigger
     a routing update.

     The goal is that the localized mobility management solution should
     be able to support any mobile node that walks up to joins the link and that 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 (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
     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.

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

     Many existing protocols are available as Internet Standards upon
     which the NETLMM protocol can be built. The design of the protocol
     should have a goal to re-use existing protocols where it makes
     architectural and engineering sense to do so. The design should
     not, however, attempt to re-use existing protocols where there is
     no real architectural or engineering reason. For example, the suite
     of Internet Standards contains several good candidate protocols for
     the transport layer, so there is no real need to develop a new
     transport protocol specifically for NETLMM.  Re-use is clearly a
     good  engineering  decision  in  this  case,  since  backward
     compatibility with existing protocol stacks is important. On the
     other  hand,  the  network-based,  localized  mobility  management
     functionality  being  introduced  by  NETLMM  is  a  new  piece  of
     functionality, and therefore any decision about whether to re-
     use re-use
     an existing global mobility management protocol should carefully
     consider whether re-using such a protocol really meets the needs of
     the functional architecture for network-based localized mobility
     management. The case for re-use is not so clear in this case, since
     there is no compelling backward compatibility argument.

   3.0 Security Considerations
     There are two kinds

  2.11 Localized Mobility Management Independent of security issues involved in network-based localized Global Mobility
       Management

     Localized  mobility management: security between the mobile node  management  should  be  implementable  and
     deployable  independently  of  any  global  mobility  management
     protocol. This enables the network, choice of local and
     security between network elements that participate in the network-based
     localized global mobility
     management protocol

     Security between the mobile node to be made independently of particular protocols that
     are implemented and deployed to solve the network itself consists of two
     parts: threats involved in different sorts of
     mobility management problems. The operator can choose a particular
     localized mobility management in general, and
     threats protocol according to the network-based specific
     features of their access network. It can subsequently upgrade the
     localized mobility management from protocol on its own, without even
     informing the host.
     The first is discussed above in Sections 2.3 and 2.6. The second is
     discussed in mobile nodes. Similarly, the threat analysis document [28].

     For threats to network-based localized mobile nodes can use a
     global  mobility management,  management  protocol  that  best  suits  their
     requirements, or even not use one at all. Also, a mobile node can
     move into a new access network without having to check that it
     understands the basic threat localized mobility management  protocol being used
     there.

     The goal is an attempt by an unauthorized party to signal a bogus that the implementation and deployment of the localized
     mobility event.
     Such an event must management protocol should not restrict, or be detectable. This requires proper bidirectional
     authentication and authorization restricted
     by, the choice of global mobility management protocol.

  2.12 Configurable Data Plane Forwarding between Mobility Anchor and
       Access Router

     Different  network elements  operators  may  require  different  types  of
     forwarding options between the mobility anchor and the access
     routers for mobile node data plane traffic. An obvious forwarding
     option  that participate  has  been  used  in  past  IETF  localized  mobility
     management  protocols  is  IP-IP  encapsulation  for  bidirectional
     tunneling. The tunnel endpoints could be the mobility anchor and
     the access routers. But other options are possible. Some network
     deployments may prefer routing-based solutions. Others may require
     security tunnels using IPsec ESP encapsulation if part of the
     network-based
     localized mobility management  protocol, domain runs over a public access
     network and  data  origin
     authentication on the signaling traffic network operator wants to protect the traffic.

     A goal of the NETLMM protocol is to allow the forwarding between
     the mobility anchor and access routers to be configurable depending
     on the particulars of the network 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 Gwon, Y., "Problem Statement deployment. Configurability is
     not expected to be dynamic as in controlled by the arrival of a
     mobile node; but rather, configuration is expected to be similar in
     time scale to configuration for IP Local Mobility," Internet
           Draft, routing. The NETLMM protocol may
     designate a default forwarding mechanism. It is also possible that
     additional work in progress.
       [2] Vogt, C., and Kempf, J., "Security Threats may be required to Network-based Localized
           Mobillity Management", Internet draft, specify the interaction between
     a particular forwarding mechanism and the NETLMM protocol, but this
     work is not in progress.
       [3] Manner, J., and 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 scope of the Internet," RFC 1958,
           June, 1996.
       [6] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support NETLMM base protocol.

  3.0  IANA Considerations

     There are no IANA considerations for this document.

  4.0  Security Considerations

     There are two kinds of security issues involved in IPv6",
           RFC 3775.
       [7] Moskowitz, R., Nikander, P., Jokela, P., network-based
     localized mobility management: security between the mobile node and Henderson, T., "Host
           Identity Protocol", Internet Draft, work
     the network, and security between network elements that participate
     in progress.
       [8] Choi, J, the network-based localized mobility management protocol

     Security between the mobile node and Daley, G., "Goals the network itself consists of Detecting Network Attachment in
           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 Carrying Authentication for Network Access (PANA)",
           Internet Draft, work
     two parts: threats involved in progress.
      [11] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "SEcure Neighbor
           Discovery (SEND)", RFC 3971, March, 2005.
      [12] Moore, N., "Optimistic Neighbor Discovery", Internet Draft, Work localized mobility management in
           Progress.
      [13] Ackerman, L., Kempf, J., and Miki, T., "Wireless Location Privacy: Law
     general,  and Policy in  threats  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 and Multi-homed Nodes: MoMiPriv Problem
           Statement", Internet Draft, work in progress.
      [15] Kivinen, T., and Tschopfening, H., "Design of  network-based  localized  mobility
     management from the MOBIKE Protocol",
           Internet Draft, work in progress.
      [16] Koodli, R., "IP Address Location Privacy and IP Mobility", Internet
           Draft, work host. The first is discussed above in progress.

      [17] Koodli, R., Devarapalli, V., Flinck, H., Sections
     2.3 and Perkins, C., "Solutions
           for IP Address Location Privacy 2.6. The second is discussed in the presence of IP Mobility",
           Internet Draft, work in progress.
      [18] Bao, F., Deng, R., Kempf, J., Qui, Y., threat analysis
     document [2].

     For threats to network-based localized mobility management, the
     basic threat is an attempt by an unauthorized party to signal a
     bogus mobility event. Such an event must be detectable. This
     requires proper bidirectional authentication and Zhou, J., "Protocol for
           Protecting Movement authorization of Mobile Nodes in Mobile IPv6", Internet Draft,
           work
     network elements that participate in progress.
      [19] Soliman, H., Tsirtsis, G., Devarapalli, V., the network-based localized
     mobility management protocol, and data origin authentication on the
     signaling traffic between network elements.

  5.0  Author's Addresses

        James Kempf
        DoCoMo USA Labs
        181 Metro Drive, Suite 300
        San Jose, CA 95110
        USA
        Phone: +1 408 451 4711
        Email: kempf@docomolabs-usa.com

        Kent Leung
        Cisco Systems, Inc.
        170 West Tasman Drive
        San Jose, CA 95134
        USA
        EMail: kleung@cisco.com

        Phil Roberts
        Motorola Labs
        Schaumberg, IL
        USA
        Email: phil.roberts@motorola.com

        Katsutoshi Nishida
        NTT DoCoMo Inc.
        3-5 Hikarino-oka, Yokosuka-shi
        Kanagawa,
        Japan
        Phone: +81 46 840 3545
        Email: nishidak@nttdocomo.co.jp

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

  6.0  Informative References

       [1] Kempf, J., Levkowetz, H.,
           Thubert, P, and Wakikawa, R. "Dual Stack Mobile IPv6 (DSMIPv6) editor, "Problem Statement for
           Hosts and Routers", IP Local Mobility,"
           Internet Draft, work Work in progress.
      [20] Koodli, R., editor, "Fast Handovers for Mobile IPv6", RFC 4068, July,
           2005.
      [21] Soliman, H., Castelluccia, Progress.
       [2] Vogt, 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 Symmetric IPv6 Handover Key
           from SEND", "Security Threats to Network-based
           Localized Mobillity Management", Internet Draft, work draft, Work in progress.
      [23] Campbell, A., Gomez,
           Progress.
       [3] Manner, J., Kim, S., Valko, A., and Wan, Kojo, M., "Mobility Related Terminology", RFC
           3753, June, 2004.
       [4] Carpenter, B., "Architectural Principles of the Internet,"
           RFC 1958, June, 1996.
       [5] Johnson, D., Perkins, 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", Arkko, J., "Mobility Support in Proceedings
           IPv6", RFC 3775.
       [6] Choi, J, and Daley, G., "Goals of the International Conference on Networking
           Protocols (ICNP), 1999.
      [25] "Mobile VPN Detecting Network Configuration Alternatives", IP Unplugged,
           http://www.ipunplugged.com/pdf/Network-blueprints_A.pdf.
      [26] Oran,
           Attachment in IPv6", Internet Draft, work in progress.
       [7] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard
           802.1x, June, 2001.
       [8] Forsberg, D., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142,
           Feburary, 1990.
      [27] Moy, Ohba, Y., Patil, B., Tschofenig, H., and Yegin,
           A., "Protocol for Carrying Authentication for Network Access
           (PANA)", Internet Draft, work in progress.
       [9] Arkko, J., "OSPF Version 2", STD 54, April, 1998.
      [28] Threat analysis draft, TBD

   6.0 IPR Statements

     The  IETF  takes  no  position  regarding  the  validity  or  scope  of  any
     Intellectual Property Rights or other rights that might be claimed to
     pertain to the implementation or use of the technology described Kempf, J., Zill, B., and Nikander, P., "SEcure
           Neighbor Discovery (SEND)", RFC 3971, March, 2005.
      [10] Moore, N., "Optimistic Neighbor Discovery", Internet Draft,
           Work in this
     document or the extent to which any license under such rights might or might
     not be available; nor does it represent that it has made any independent
     effort to identify any such rights. Information on the procedures with
     respect to rights Progress.
      [11] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., Park,
           S.D., and Patil, B., "Privacy for Mobile and Multi-homed
           Nodes: MoMiPriv Problem Statement", Internet Draft, work in
           progress.
      [12] Moskowitz, R., and Nikander, P., "Host Identity Protocol
           (HIP) Architecture", RFC documents can be found 4423, May, 2006.
      [13] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol
           (MOBIKE)", Internet Draft, Work in BCP 78 Progress.
      [14] Koodli, R., "IP Address Location Privacy and BCP 79.

     Copies of IPR disclosures made to the IETF Secretariat IP Mobility",
           Internet Draft, Work in Progress.
      [15] Koodli, R., Devarapalli, V., Flinck, H., and any assurances of
     licenses to be made available, or the result of an attempt made to obtain a
     general license or permission Perkins, C.,
           "Solutions for IP Address Location Privacy in the use of such proprietary rights by
     implementers or users presence of this specification can be obtained from the IETF
     on-line IPR repository at http://www.ietf.org/ipr.

     The IETF invites any interested party to bring to its attention any
     copyrights, patents or patent applications, or other proprietary rights that
     may cover technology that may be required to implement this standard.
     Please address the information to the IETF at ietf-ipr@ietf.org.

   7.0 Disclaimer
           IP Mobility", Internet Draft, Work in Progress.
      [16] Bao, F., Deng, R., Kempf, J., Qui, Y., and Zhou, J.,
           "Protocol for Protecting Movement of Validity

     This document Mobile Nodes in Mobile
           IPv6", Internet Draft, Work in Progress.
      [17] Soliman, H., Tsirtsis, G., Devarapalli, V., Kempf, J.,
           Levkowetz, H., Thubert, P, and the information contained herein are provided on an "AS
     IS" basis Wakikawa, R. "Dual Stack
           Mobile IPv6 (DSMIPv6) for Hosts 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 Routers", Internet Society (2006).  This document is subject to the
     rights, licenses and restrictions contained Draft,
           Work in BCP 78, and except as set
     forth therein, the authors retain all their rights.

   9.0 Appendix: Gap Analysis

     This section discusses a gap analysis between existing proposals Progress.
      [18] Koodli, R., editor, "Fast Handovers for solving
     localized mobility management and the goals in Section. 2.0.

  9.1 Mobile IPv6 with Local Home Agent

     One option is to deploy IPv6", RFC
           4068, July, 2005.

      [19] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L.,
           "Hierarchical Mobile IPv6 with a locally assigned home agent in
     the local network. This solution requires the mobile node to somehow be
     assigned a home agent in the local network when it boots up. This home agent
     is used instead of the home agent in the home network. The advantage of this
     option is that no special solution is required for edge mobility - the
     mobile node reuses the global mobility management protocol for that purpose
     - if 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 Mobility Management (HMIPv6)", RFC
           4140, August, 2005.
      [20] Kempf, J., and complex.

     The analysis of this approach against the 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 if no route
     optimization signaling is done on handover.

     Goal #3: Location privacy is preserved for external correspondents, but the
     mobile node itself still maintains a local care-of address which Koodli, R., "Distributing a worm or
     other  exploit  could  misuse.  If  the  mobile  node  does  perform  route
     optimization, location privacy may be compromised, Symmetric FMIPv6
           Handover Key using SEND", Internet Draft, work in progress.
      [21] Narayanan, V., Venkitaraman, N., Tschofenig, H., Giaretta,
           G., and this solution is no
     better than having a remote home agent.

     Goal #4: If traffic is not route optimized, the mobile node still pays for
     an over-the-air tunnel to the locally assigned home agent. The overhead here
     is exactly the same as if the mobile node's home agent Bournelle, J., "Handover Keys Using AAA", Internet
           Draft, Work in the home network
     is used Progress.
      [22] Campbell, A., Gomez, J., Kim, S., Valko, A., and route optimization is not done.

     Goal #5: If the localized mobility management domain is large, the mobile
     node may suffer from unoptimzed routes. RFC 3775 [6] provides no support for
     notifying a mobile node that another localized home agent is available for a
     more optimized route, or for handing over between home agents. A mobile node
     would have to perform the full home agent bootstrap procedure, including
     establishing a new IPsec SA with the new home agent.

     Goal #6: 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 local home agent domain-based approach for supporting mobility in a roaming situation requires the guest mobile
     node to have the proper credentials to authenticate with the local home
     agent
           wide-area wireless networks", in Proceedings of the serving network. Although
           International Conference on Networking Protocols (ICNP),
           1999.

  7.0  IPR Statements

     The IETF takes no position regarding the credentials used for network
     access authentication could also validity or scope of any
     Intellectual Property Rights or other rights that might be used for mobile service authentication
     and  authorization  if  the  local  home  agent  uses  EAP  over  IKEv2 claimed
     to pertain to
     authenticate the mobile node with its home AAA server, the two sets implementation or use of
     credentials  are  in  principle  different,  and  could  require  additional
     credential provisioning. In addition, as in Goal #3, if binding updates are
     done in cleartext over the access network technology described
     in this document or the mobile node extent to which any license under such
     rights might or might not be available; nor does it represent that
     it has become
     infected with malware, made any independent effort to identify any such rights.
     Information on the local home agent's address could be revealed procedures with respect to
     attackers rights in RFC
     documents can be found in BCP 78 and BCP 79.

     Copies of IPR disclosures made to the local home agent could become the target IETF Secretariat and any
     assurances of a 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 licenses to be made available, or the result of an
     attempt made to interface obtain a local home agent
     to different wireless technologies.

     Goal #8: The mobile node must support Mobile IPv6 in order general license or permission for the use
     of such proprietary rights by implementers or users of this option
     specification can be obtained from the IETF on-line IPR repository
     at http://www.ietf.org/ipr.

     The IETF invites any interested party to work. So mobile node changes are bring to its attention any
     copyrights, patents or patent applications, or other proprietary
     rights that may cover technology that may be required to implement
     this standard.  Please address the information to the IETF at ietf-
     ipr@ietf.org.

  8.0  Disclaimer of Validity

     This document and other IP mobility protocols the information contained herein are not supported.

     Goal #9: 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.

  9.0  Copyright Notice

     Copyright (C) The Mobile IPv6 working group Internet Society (2006).  This document is working on modifying the protocol
     subject to allow registration of IPv4 care-of addresses the rights, licenses and restrictions contained in an IPv6 home agent, BCP
     78, and
     also to allow a mobile node to have an IPv4 care of address [19].

     Goal #10 except as set forth therein, the authors retain all their
     rights.

  10.0     Appendix: Gap Analysis

     This solution re-uses an section discusses a gap analysis between existing protocol, proposals
     for solving localized mobility management and the goals in Section.
     2.0.

  10.1 Mobile IPv6.

  9.2     Hierarchical IPv6 with Local Home Agent

     One option is to deploy Mobile IPv6 (HMIPv6)

     HMIPv6  [21]  provides with a locally assigned home
     agent in the  most  complete  localized  mobility  management local network. This 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 to another, requires the mobile node
     changes
     to somehow be assigned a home agent in the binding between its regional care-of address and local care-of
     address at the MAP. No global mobility management signaling network when it
     boots up. This home agent is required,
     since used instead of the care-of address seen by correspondents does not change. This part home agent in the
     home network. The advantage of HMIPv6 this option is similar to the that no special
     solution outlined in Section 9.1; however,
     HMIPv6 also allows a is required for edge mobility - the 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 reuses the
     transition area, and then must perform
     global mobility management update and
     route optimization to the new regional care-of address, protocol for that purpose - if appropriate. the
     mobile node is using Mobile IPv6.

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

     Goal #1 This Handover Performance Improvement: If the mobile node does
     not perform route optimization, this solution shortens, reduces, 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. handover related performance problems.

     Goal #2 Reduction in Handover-related Signaling Volume: Similarly
     to Goal #1, signaling volume is reduced simply because if no route optimization
     signaling is done on handover within the coverage area of the MAP. handover.

     Goal  #3  Location  privacy:  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.

     Goal #4 The mobile node always pays for an over-the-air tunnel to the MAP.  address.  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  performs  route
     optimization,  location  privacy  may  be removed by header compression, however.

     Goal #5 From Goal #1 and Goal #4, the signaling overhead  compromised,    but  not
     performing route optimization is no more or less better 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.

     Goal #6 In having a roaming situation, the guest mobile node must have the proper
     credentials to authenticate with the MAP in the serving network. In
     addition, since remote
     home agent.

     Goal #4 Efficient Use of Wireless Resources: If traffic is not
     route optimized, the mobile node is required to have a unicast address still pays for
     the MAP that is either globally routed or routing restricted an over-the-air
     tunnel to the local
     administrative domain, the MAP locally assigned home agent. The overhead here 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
     exactly the mobile nodes. In
     addition, same as if the HMIPv6 design has been optimized for Mobile IPv6 mobile nodes, node's home agent in the home
     network is used and route optimization is not a good match for other global done.

     Goal #5 Limit the Signaling Overhead in the Network: If the
     localized mobility management protocols.

     Goal #9 Currently, there domain is large, the mobile node may
     suffer from unoptimzed routes. RFC 3775 [5] provides no IPv4 version of this protocol; although there
     is an expired Internet draft with a design support for
     notifying a regional registration
     protocol for Mobile IPv4 mobile node that has similar functionality. It another localized home agent is possible that
     the same IPv4 transition solution as used
     available for Mobile IPv6 could be used
     [19]. a more optimized route, or for handing over between
     home agents. A mobile node would have to perform the full home
     agent bootstrap procedure, including establishing a new IPsec SA
     with the new home agent.

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

  9.3 Combinations of #6 No Extra Security Between Mobile IPv6 with Optimizations

     One approach to Node and Network: A local mobility that has received much attention
     home agent in the past
     and has been thought to provide a solution is combinations of protocols. The
     general approach is to try roaming situation requires the guest mobile node to cover gaps
     have the proper credentials to authenticate with the local home
     agent in the solution provided by MIPv6
     by using other protocols. In this section, gap analyses serving network. Although the credentials used for MIPv6 + FMIPv6
     network access authentication could also be used for mobile service
     authentication and HMIPv6 + FMIPv6 are discussed.

  9.3.1 MIPv6 + FMIPv6

     As discussed in Section 9.1, authorization if the use of MIPv6 with a dynamically assigned, local home agent cannot fulfill uses EAP
     over IKEv2 to authenticate the goals. A fundamental limitation is that
     Mobile IPv6 cannot provide seamless handover (i.e. mobile node with its home AAA
     server, the two sets of credentials are in principle different, and
     could require additional credential provisioning. In addition, as
     in Goal #1). FMIPv6 #3, if binding updates are done in cleartext over the
     access network or the mobile node has been
     defined become infected with malware,
     the intent local home agent's address could be revealed to improve attackers and
     the handover performance of MIPv6. For
     this reason, local home agent could become the combined usage target of FMIPv6 and MIPv6 with a dynamically
     assigned DoS attack. So a
     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 and FMIPv6 might still be acceptable would provide no benefit for
     global mobility management.

     The analysis of this combined approach against the goals follows. goal.

     Goal #1 FMIPv6 provides a solution #7 Support for handover performance improvement that
     should fulfill the goals raised by real-time applications in terms of
     jitter, delay and packet loss. The location of the home agent (in Heterogeneous Wireless Link Technologies: This
     solution supports multiple wireless technologies with separate IP
     subnets for different links. No special work is required to
     interface a local or home domain) does not affect the handover latency.

     Goal #2 FMIPv6 requires the mobile node agent to perform extra signaling with the
     access router (i.e. exchange of RtSolPr/PrRtAdv and FBU/FBA). Moreover, as
     in standard MIPv6, whenever the different wireless technologies.

     Goal #8 Support for Unmodified Mobile Nodes: The mobile node moves to another IP link, it must send a Binding Update
     support Mobile IPv6 in order for this option to the home agent. If route optimization is used,
     the work. So mobile
     node also performs return routability changes are required and sends a Binding Update
     to each correspondent node. Nonetheless, it is worth noting that FMIPv6
     should result in a reduction of the amount of other IP mobility protocols are not
     supported.

     Goal #9 Support for IPv4 and IPv6: The Mobile IPv6 Neighbor Discovery
     signaling working group is
     working on modifying the new link.

     Goal #3 The mobile node mantains a local protocol to allow registration of IPv4
     care-of address. If route
     optimization is not used, location privacy can be achieved using bi-
     directional tunneling. However, as mentioned addresses in Section 9.1, an IPv6 home agent, and also to allow a worm or other
     malware can exploit this mobile
     node to have an IPv4 care of address by sending it to a third malicious
     node. [17].

     Goal #4 As stated for #10 Re-use of Existing Protocols Where Sensible: This solution
     re-uses an existing protocol, Mobile IPv6.

     Goal #2, the combination  #11  Localized  Mobility  Management  Independent  of MIPv6  Global
     Mobility  Management:  This  solution  merges  localized  mobility
     management and FMIPv6 generates
     extra signaling overhead. For data packets, in addition to global mobility management, so it does not support
     the goal.

  10.2 Hierarchical Mobile IPv6
     over-the-air tunnel, there is a further level of tunneling between (HMIPv6)

     HMIPv6  [19]  provides  the  most  complete  localized  mobility
     management  solution  available  today.  In  HMIPv6,  a  localized
     mobility anchor called a MAP serves as a routing anchor for a
     regional care-of address. When a mobile node and the previous moves from one access
     router during handover. This tunnel is
     needed to forward incoming packets to another, the mobile node addressed to changes the
     previous binding between its
     regional care-of address. Another reason address and local care-of address at the MAP. No
     global mobility management signaling is that, even if required, since the mobile node
     has a valid new care-of address,
     address seen by correspondents does not change. This part of HMIPv6
     is similar to the solution outlined in Section 10.1; however,
     HMIPv6 also allows a mobile node cannot use to hand over between MAPs.

     Handover between MAPs and MAP discovery requires configuration on
     the new care routers. MAP addresses are advertised by access routers.
     Handover happens by overlapping MAP coverage areas so that, for
     some number of
     address  directly  with  its  correspondents  without  performing 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 care regional care-of address, if appropriate.

     The analysis of address. This implies that this approach against the transient
     tunnel overhead goals above is the
     following.

     Goal #1 Handover Performance Improvement: This solution shortens,
     but does not eliminate, the latency associated with IP handover,
     since it reduces the amount of signaling and the length of the
     signaling paths.

     Goal #2 Reduction in place even for Handover-related Signaling Volume: Signaling
     volume is reduced simply because no route optimized traffic.

     Goal #5 FMIPv6 generates extra optimization signaling overhead between is
     done on handover within the previous
     access router and coverage area of the new access router MAP.

     Goal  #3  Location  privacy:  Location  privacy  is  preserved  for the HI/HAck exchange. Concerning
     data packets, the use
     external correspondents.

     Goal #4 Use of FMIPv6 Wireless Resources: The mobile node always pays for handover performance improvement implies
     a
     an over-the-air tunnel between to the previous access router and MAP. If the mobile node that adds
     some 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.

     Goal #5 Limit the Signaling Overhead in the wired network. This Network: From Goal #1
     and Goal #4, the signaling overhead has is no more impact on star
     topology deployments, since packets are routed down to or less than for
     mobile nodes whose global mobility management anchor is local.
     However, because MAP handover is possible, forwarding across large
     localized mobility management domains can be improved thereby
     improving wired network resource utilization by using multiple MAPs
     and  handing  over,  at  the old access
     router, then back up to  expense  of  the aggregation router  configuration  and then back down to the new
     access router.
     management overhead involved in maintaining multiple MAP coverage
     areas.

     Goal #6 In addition to the analysis for Extra Security Between Mobile IPv6 with local home agent in
     Section 9.1, FMIPv6 requires Node and Network: In a
     roaming situation, the guest mobile node and must have the previous access router
     to share a security association in order to secure FBU/FBA exchange. So far,
     only a SEND-based solution has been proposed and this requires proper
     credentials to authenticate with the MAP in the serving network. In
     addition, since the mobile node is required to use autoconfigured Cryptographically Generated Addresses (CGAs)[22].
     This precludes stateful address allocation using DHCP, which might be have a
     necessary deployment in certain circumstances. Another solution based on AAA unicast
     address for the MAP that is under study but it could require extra signaling overhead over either globally routed or routing
     restricted  to  the air
     and in  local  administrative  domain,  the wired  MAP  is
     potentially a target for DoS attacks across a wide swath of network and it could raise performance issues.
     topology.

     Goal #7 MIPv6 and FMIPv6 support Support for Heterogeneous Wireless Link Technologies: This
     solution supports multiple wireless technologies, so this
     goal is fufilled. technologies with separate IP
     subnets for different links.

     Goal #8 The Support for Unmodified Mobile Nodes: This solution requires
     modification to the mobile node must support both MIPv6 nodes. In addition, the HMIPv6 design
     has been optimized for Mobile IPv6 mobile nodes, and FMIPv6, so it is not
     possible to satisfy this goal. a good
     match for other global mobility management protocols.

     Goal #9 Work Currently, there is underway to extend MIPv6 no IPv4 version of this protocol;
     although there is an expired Internet draft with a design for a
     regional registration protocol for Mobile IPv4 that has similar
     functionality.  It  is  possible  that  the  same  IPv4  transition
     solution as used for Mobile IPv6 could be used [17].

     Goal #10 Re-use of Existing Protocols Where Sensible: This solution
     re-uses an existing protocol, HMIPv6.

     Goal  #11  Localized  Mobility  Management  Independent  of  Global
     Mobility  Management:  While  HIMPv6  is  technically  a  separate
     protocol from MIPv6 and could in principle be implemented and
     deployed  without  MIPv6,  the  design  is  very  similar  and
     implementation and deployment would be easier if the capability mobile nodes
     supported MIPv6.

  10.3 Combinations of Mobile IPv6 with Optimizations

     One approach to run over
     both IPv6-enabled local mobility that has received much attention in
     the past and IPv4-only networks [19]. FMIPv6 only supports IPv6.
     Even though an IPv4 version of FMIP has been recently proposed, it thought to provide a solution is combinations
     of protocols. The general approach is not
     clear how it could be used together with FMIPv6 in order to handle fast
     handovers across any wired network.

     Goal #10 This try to cover gaps in the
     solution re-uses existing protocols, Mobile IPv6 provided by MIPv6 by using other protocols. In this
     section, gap analyses for MIPv6 + FMIPv6 and FMIPv6.

  9.3.2 HMIPv6 + FMIPv6

     HMIPv6 provides several advantages in terms of are
     discussed.

  10.3.1   MIPv6 with local mobility management.
     However, as seen home agent + FMIPv6

     As discussed in Section 9.2, it does not 10.1, the use of MIPv6 with a dynamically
     assigned, local home agent cannot fulfill all the goals
     identified in Section 2.0. In particular, HMIPv6 does not completely
     eliminate goals. A fundamental
     limitation is that Mobile IPv6 cannot provide seamless handover
     (i.e. Goal #1). FMIPv6 [18] has been defined with the intent to
     improve the IP link handover latency. performance of MIPv6. For this reason, the
     combined usage of FMIPv6 could be
     used together and MIPv6 with HMIPv6 in order a dynamically assigned
     local home agent has been proposed to cover the gap. handle local mobility.

     Note that even if this solution is used, the mobile node is likely gap analysis only applies to need
     MIPv6 for global localized mobility
     management, in contrast with the and it is possible that MIPv6 with
     dynamically assigned local home agent + and FMIPv6 solution. Thus, this solution
     should really might still be considered MIPv6 + HMIPv6 + FMIPv6.
     acceptable for global mobility management.

     The analysis of this combined approach against the goals follows.

     Goal  #1 HMIPv6 and FMIPv6 both shorten the latency associated with IP link
     handovers. In particular,  Handover  Performance  Improvement:  FMIPv6 is expected to  provides  a
     solution for handover performance improvement that should fulfill
     the goals on raised by real-time applications in terms of jitter,
     delay and packet loss raised by real-time applications. loss. The location of the home agent (in local or
     home domain) does not affect the handover latency.

     Goal #2 Both Reduction in Handover-related Signaling Volume: FMIPv6 and HMIPv6 require extra signaling compared with Mobile
     IPv6. As a whole
     requires the mobile node performs to perform extra signaling message exchanges at
     each handover that are RtSolPr/PrRtAdv, FBU/FBA, LBU/LBA with the access
     router (i.e. exchange of RtSolPr/PrRtAdv and BU/BA. However, FBU/FBA). Moreover, as mentioned
     in Section 9.2, standard MIPv6, whenever the use of HMIPv6 reduces mobile node moves to another link,
     it must send a Binding Update to the signaling
     overhead since no home agent. If route
     optimization signaling  is done for intra-MAP
     handovers. In addition, na´ve combinations of FMIPv6  used,  the  mobile  node  also  performs  return
     routability and HMIPv6 often result
     in redundant signaling. There sends a Binding Update to each correspondent node.
     Nonetheless, it is much work worth noting that FMIPv6 should result in a
     reduction of the academic literature and
     the IETF on more refined ways amount of combining IPv6 Neighbor Discovery signaling from on the two protocols
     to avoid redundant signaling.
     new link.

     Goal #3 HMIPv6 may preserve location privacy, depending on the dimension of
     the geographic area covered by the MAP. As discussed in Section 9.2, the Location privacy: The mobile node still maintains mantains a local care-of address that
     address. If route optimization is not used, location privacy can be exploited by
     worms or other malware.
     achieved using bi-directional tunneling.

     Goal #4 Use of Wireless Resources: As mentioned stated for Goal #2, the
     combination of HMIPv6 MIPv6 and FMIPv6 generates a lot of extra signaling overhead in the network. Concerning payload
     data, overhead.
     For data packets, in addition to the Mobile IPv6 over-the-air MIPv6
     tunnel, there is a further level of tunneling is established between the mobile
     node and MAP. Notice that this the previous access router during handover. This tunnel is in place even for route optimized traffic. Moreover, if FMIPv6 is
     directly applied
     needed to forward incoming packets to HMIPv6 networks, there is a third temporary handover-
     related tunnel between the mobile node and addressed to
     the previous access router. Again,
     there care-of address. Another reason is much work in that, even if the academic literature and IETF on ways
     mobile node has a valid new care-of address, the mobile node cannot
     use the new care of address directly with its correspondents
     without performing route optimization to reduce the
     extra new care of address.
     This implies that the transient tunnel overhead on handover by combining HMIP and FMIP tunneling. is in place even
     for route optimized traffic.

     Goal #5 The signaling overhead in Limit the network is not reduced by HMIPv6, as
     mentioned Signaling Overhead in Section 9.2. Instead, the Network: FMIPv6
     generates extra signaling overhead between the previous access
     router  and  the  new  access  router  for  the  HI/HAck  exchange. For payload data,
     Concerning data packets, the same considerations as use of FMIPv6 for Goal #4 handover performance
     improvement implies a tunnel between the previous access router and
     the mobile node that adds some overhead in the wired network. This
     overhead has more impact on star topology deployments, since
     packets are
     applicable. routed down to the old access router, then back up to
     the aggregation router and then back down to the new access router.

     Goal #6 Extra Security Between Mobile Node and Network: In addition
     to the analysis for Mobile IPv6 with local home agent in Section
     10.1, FMIPv6 requires the mobile node and the previous access
     router to share a security association in order to secure the FBU/FBA
     exchange. In
     addition, HMIPv6 requires that Two solutions have been proposed: a SEND-based solution
     [20]  and  an  AAA-based  solution  [21].  Both  solutions  require
     additional support on the mobile node and MAP share an IPsec
     security association in order to secure LBU/LBA exchange. The only well
     understood approach to set up an IPsec security association using of
     certificates, but this may raise deployment issues. Thus, the combination of
     FMIPv6 and HMIPv6 doubles the amount of mobile node to network security
     protocol required, since security beyond
     what is required for both FMIP and HMIP must be deployed. network access authentication.

     Goal #7 HMIPv6 Support for Heterogeneous Wireless Link Technologies: MIPv6
     and FMIPv6 support multiple wireless technologies, so this goal is
     fufilled.

     Goal #8 Support for Unmodified Mobile Nodes: The mobile node must
     support both HMIPv6 MIPv6 and FMIPv6 protocols, FMIPv6, so
     this goal it is not fulfilled. possible to satisfy
     this goal.

     Goal #9 Currently there is no Support for IPv4 version of HMIPv6. There and IPv6: Work is underway to extend MIPv6
     with the capability to run over both IPv6-enabled and IPv4-only
     networks [17]. FMIPv6 only supports IPv6. Even though an IPv4
     version of FMIP but 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, HMIPv6 and FMIPv6.

  9.4 Micromobility Protocols

     Researchers have defined some protocols that are often characterized as
     micromobility  protocols.  Two  typical  protocols  in  this  category  are
     Cellular-IP [23] and HAWAII [24]. Researchers defined these protocols before
     local mobility optimizations for Mobile IP such as FMIP and HMIP were
     developed, in order to reduce handover latency.

     The micromobility approach to localized mobility management requires host
     route propagation from the mobile node to a collection of specialized
     routers in the localized mobility management domain along a path back to a
     boundary router at the edge fast
     handovers across any wired network.

     Goal #10 Re-use of the localized mobility management domain. A
     boundary router is a kind Existing Protocols Where Sensible: This solution
     re-uses existing protocols, Mobile IPv6 and FMIPv6.

     Goal  #11  Localized  Mobility  Management  Independent  of  Global
     Mobility  Management:  This  solution  merges  localized  mobility
     management domain gateway.
     Localized and global mobility management is authorized with management, so it does not support
     the access router, but
     reauthorization with each new access router is necessary on IP link
     movement, goal.

  10.3.2   HMIPv6 + FMIPv6

     HMIPv6 provides several advantages in addition to any reauthorization for basic network access. The
     host routes allow the mobile node to maintain the same IP address when terms of local mobility
     management. However, as seen in Section 10.2, it
     moves to a new IP link, and still continue to receive packets on does not fulfill
     all the new IP
     link.

     Cellular IP and HAWAII have a few things goals identified in common.  Both are compatible
     with Mobile Section 2.0. In particular, HMIPv6 does
     not completely eliminate the IP and are intended to provide a higher level of handover
     performance in local networks than was previously available latency. For this reason,
     FMIPv6 could be used together with Mobile IP
     without such extensions as HMIP and FMIP.  Both use host routes installed HMIPv6 in
     a number of routers within a restricted routing domain. Both define specific
     messaging order to update those routes along cover the forwarding path and specify how
     gap.

     Note that even if this solution is used, the messaging mobile node is likely
     to need MIPv6 for global mobility management, in contrast with the
     MIPv6 with dynamically assigned local home agent + FMIPv6 solution.
     Thus, this solution should really be used to update considered MIPv6 + HMIPv6 +
     FMIPv6.

     The analysis of this combined approach against the routing tables goals follows.

     Goal #1 Handover Performance Improvement: HMIPv6 and forwarding
     tables along the path between FMIPv6 both
     shorten the mobile and a micromobility domain boundary
     router at which point Mobile latency associated with IP handovers. In particular,
     FMIPv6 is expected to used to handle scalable global
     mobility. Unlike fulfill the FMIP goals on jitter, delay and HMIP protocols, however, these protocols do
     not packet
     loss raised by real-time applications.

     Goal #2 Reduction in Handover-related Signaling Volume: Both FMIPv6
     and HMIPv6 require extra signaling compared with Mobile IPv6. As a
     whole the mobile node to obtain a new care of address on performs signaling message exchanges at each access
     router
     handover that are RtSolPr/PrRtAdv, FBU/FBA, LBU/LBA and BU/BA.

     However, as it moves; but rather, the mobile node maintains mentioned in Section 10.2, the same care use of
     address across HMIPv6 reduces
     the micromobility domain. From outside signaling overhead since no route optimization signaling is
     done for intra-MAP handovers. In addition, naive combinations of
     FMIPv6 and HMIPv6 often result in redundant signaling. There is
     much work in the micromobility
     domain, academic literature and the care IETF on more refined
     ways of address is routed using traditional longest prefix
     matching IP routing combining signaling from the two protocols to avoid
     redundant signaling.

     Goal #3 Location privacy: HMIPv6 may preserve location privacy,
     depending on the domain's boundary router, so dimension of the care geographic area covered by the
     MAP.

     Goal #4 Use of address
     conceptually is within Wireless Resources: As mentioned for Goal #2, the micromobiity domain boundary router's subnet.
     Within
     combination of HMIPv6 and FMIPv6 generates a lot of signaling
     overhead in the micromobility domain, network. Concerning payload data, in addition to
     the care over-the-air MIPv6 tunnel, a further level of address tunneling is routed
     established between mobile node and MAP. Notice that this tunnel is
     in place even for route optimized traffic. Moreover, if FMIPv6 is
     directly applied to HMIPv6 networks, there is a third temporary
     handover-related tunnel between the
     correct access router using host routes.

     Cellular IP mobile node and HAWAII differ previous access
     router. Again, there is much work in a few aspects.  Cellular IP seems the academic literature and
     IETF on ways to be
     restricted, based reduce the extra tunnel overhead on handover by
     combining HMIP and FMIP tunneling.

     Goal #5 Limit the nature of Signaling Overhead in the protocol, to tree-based network
     topologies.  HAWAII claims to be applicable Network: The signaling
     overhead in both tree-based and more
     complete the network topologies.  HAWAII documents more functionality is not reduced by HMIPv6, as mentioned in
     Section 10.2. Instead, FMIPv6 generates extra signaling overhead
     between the
     realm of reliability previous access router and QoS interworking.  Both protocols involve the
     mobile node itself in mobility operations, although this is also true of the
     Mobile IP based optimizations, so both protocols raise new access router for
     HI/HAck exchange. For payload data, the same security
     concerns with respect to authorizing address update considerations as the for
     Goal #4 are applicable.

     Goal #6 Security Between Mobile IP based
     optimizations.    HAWAII  provides  some  analysis  of  network  deployment
     scenarios including scale, density, Node and efficiency, but some of these
     assumptions seem very conservative compared Network: FMIPv6 requires
     the mobile node and the previous access router to realistic cellular type
     deployments.

     Micromobility protocols have some potential drawbacks from share a deployment and
     scalability standpoint. Both protocols involve every routing element between security
     association in order to secure the FBU/FBA exchange. In addition,
     HMIPv6 requires that the mobile device node and the micromobility domain boundary router MAP share an IPsec
     security association in all packet
     forwarding decisions specific order to care of addresses for mobile nodes.
     Scalability secure LBU/LBA exchange. The only
     well understood approach to set up an IPsec security association is limited because each care
     the use of certificates, but this may raise deployment issues.
     Thus, the combination of FMIPv6 and HMIPv6 doubles the amount of address corresponding to a
     mobile node generates a routing table entry, to network security protocol required, since security
     for both FMIP and perhaps HMIP must be deployed.

     Goal #7 Support for Heterogeneous Wireless Link Technologies:
     HMIPv6 and FMIPv6 support multiple forwarding
     table entries, in every router along the path. Since wireless technologies, so this
     goal is fufilled.

     Goal #8 Support for Unmodified Mobile Nodes: The mobile nodes can have
     multiple global care of addresses in IPv6, node must
     support both HMIPv6 and FMIPv6 protocols, so this can result in a large
     expansion in router state throughout the micromobility routing domain.
     Although the extent of the scalability goal is not
     fulfilled.

     Goal #9 Support for micromobility protocols IPv4 and IPv6: Currently there is no IPv4
     version of HMIPv6. There is an IPv4 version of FMIP but it is still not clearly understood from a research standpoint,
     clear how it seems certain that
     they will could be less scalable than the Mobile IP optimization enhancements, used together with FMIPv6 in order to handle
     fast handovers across any wired network.

     Goal #10 Re-use of Existing Protocols Where Sensible:  This
     solution re-uses existing protocols, HMIPv6 and FMIPv6.

     Goal  #11  Localized  Mobility  Management  Independent  of  Global
     Mobility  Management:  While  HIMPv6  is  technically  a  separate
     protocol from MIPv6 and
     will require more specialized gear could in principle be implemented and
     deployed  without  MIPv6,  the wired network.

     The following  design  is a gap analysis of  very  similar  and
     implementation and deployment would be easier if the mobile nodes
     supported MIPv6.

  10.4 Micromobility Protocols

     Researchers  have  defined  some  protocols  that  are  often
     characterized as micromobility protocols. Two typical protocols against the
     goals in Section 2.0:

     Goal #1 The micromobility
     this category are Cellular-IP [22] and HAWAII [23]. Researchers
     defined these protocols before local mobility optimizations for
     Mobile IP such as FMIP and HMIP were developed, in order to reduce
     handover latency by quickly
     fixing up routes between the boundary router latency. Cellular-IP and HAWAII were proposed in 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, IETF
     for standardization, 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 after some study in 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 IRTF, were
     dropped. There are many micromobility protocols defined in
     propagating host routes from the mobile node to the network upon movement.
     Since this signaling would be required for movement detection
     academic literature, but in any case,
     it this document, the term is expected used
     specifically to be minimal. Mobile node traffic experiences no overhead.

     Goal #5 Host refer to Cellular-IP and HAWAII.

     The  micromobility  approach  to  localized  mobility  management
     requires  host  route  propagation is required throughout the wired network. The
     volume of signaling could be more or less depending on the speed of mobile
     node movement and the size of  from  the wired network.

     Goal #6 The  mobile  node only requires  to  a security association
     collection  of some type
     with the access router. Because the signaling is causing routes to  specialized  routers  in  the
     mobile  node's  care-of  address  localized  mobility
     management domain along a path back to  change, a boundary router at the  signaling  must  prove
     authorization to hold
     edge of the address.

     Goal #7 The micromobility protocols support multiple wireless technologies,
     so this goal localized mobility management domain. A boundary router
     is satisfied.

     Goal #8 The mobile node must support some way  a  kind  of signaling  localized  mobility  management  domain  gateway.
     Localized mobility management is authorized with the access router,
     but reauthorization with each new access router is necessary on
     link handover, but this is required movement, in addition to any reauthorization for movement detection anyway. basic network
     access. The
     nature of the signaling for host routes allow the micromobility protocols may mobile node
     software changes, however.

     Goal #9  Most of to maintain the work same
     IP address when it moves to a new link, and still continue to
     receive packets on the micromobility protocols was done in IPv4,
     but little difference could be expected for IPv6.

     Goal #10 This solution does not reuse an existing protocol because there is
     currently no Internet Standard protocol for micromobility.

  9.5 Standard Internal Gateway Route Distribution Protocols (OSPF the new link.

     Cellular IP and IS-IS)

      It  has  also  been  suggested  that  instead  of  using HAWAII have a  specialized
     micromobility  routing  protocol few things in  the  access  network, common.  Both are
     compatible with Mobile IP and are intended to provide a  standardized
     Internal Gateway route distribution Protocol (IGP) higher
     level of handover performance in local networks than was previously
     available with Mobile IP without such extensions as IS-IS [26] or
     OSPF [27] should be used to distribute HMIP and FMIP.
     Both use host routes. Host route messages are
     formatted routes installed in the IGPs by including a subnet mask in number of routers within a
     restricted routing domain. Both define specific messaging to update
     those  routes  along  the route information
     update, indicating that  forwarding  path  and  specify  how  the address
     messaging is a /32 for IPv4 or a /128 for IPv6
     instead  of  a  subnet  prefix.  Since  IGPs  typically  distribute  route
     information by flooding, every router in to be used to update the domain obtains a copy of routing tables and forwarding
     tables along the
     host route eventually. Using an IGP instead of path between the mobile and a micromobility protocol has
     the advantage that standardized routing equipment can be domain
     boundary router at which point Mobile IP is to used for all
     routers to handle
     global mobility in the access network, and, if a particular router goes down, scalable way. Unlike the
     host routes maintained along alternate routes should be sufficient to
     continue routing, unlike micromobility FMIP and HMIP
     protocols, however, these protocols where only targeted routers
     have do not require the host routes.

     Distributing host routes with an IGP has some significant disadvantages
     however. One is that flooding requires mobile node
     to obtain a certain amount new care of time to converge;
     so for some period after address on each access router as it moves;
     but rather, the link handover blackout, delivery to a mobile node that has moved will be disrupted until convergence along maintains the same care of address
     across the routes
     traveled by micromobility domain. From outside the mobile node's traffic has occurred. Because micromobility
     protocols target host routes back
     domain, the care of address is routed using traditional longest
     prefix matching IP routing to the micromobility domain border domain's boundary router,
     convergence can potentially be achieved more quickly. Tunnel-based solutions
     such as HMIP don't suffer from convergence latency because only so the two
     endpoints need to know
     care of address conceptually is within the routing.  As a result, micromobiity domain
     boundary router's subnet. Within the internal routing
     tables updated by micromobility domain, the IGP remain stable when a mobile node moves. The
     movement does not affect routing of traffic to other mobile nodes due to
     intensive path computation.

     Another disadvantage care
     of using an IGP address is that each router in routed to the domain must
     maintain a full correct access router using host route table for all hosts. This goal raises
     routes.

     Micromobility  protocols  have  some  potential  drawbacks  from  a
     deployment and scalability issue. For example, an experiment [25]  using OSPF standpoint. Both protocols involve every
     routing element between the mobile device and the micromobility
     domain boundary router in all packet forwarding decisions specific
     to distribute
     host routes through an access network consisting of a collection care of rather
     smallish enterprise routers indicated that about 25,000 routes could be
     supported in 22 Mb addresses for mobile nodes. Scalability is limited
     because each care of memory before performance started to degrade. This
     works out address corresponding to 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 San
     Francisco) would require about 8.8 Gb of memory per router. While memory
     costs continue to drop, mobile node
     generates a routing table entry, and perhaps multiple forwarding
     table entries, in every router along the amount path. Since mobile nodes
     can have multiple global care of processing power for searching addresses in IPv6, this can result
     in a
     routing database of that size essentially means that each router large expansion in router state throughout the
     domain must have micromobility
     routing  domain.  Although  the same processing power as a high end, border router.
     Micromobility and tunnel- based solutions don't suffer from this problem,
     because  extent  of  the host route  scalability  for
     micromobility protocols is local to still not clearly understood from a
     research standpoint, it seems certain that they will be less
     scalable than the tunnel endpoints. Other routers Mobile IP optimization enhancements, and will
     require more specialized gear in the domain route based on highly scalable shortest matching network prefix
     method. wired network.

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

     Goal  #1 Host route distribution using an IGP is likely to suffer from
     increased  Handover  Performance  Improvement:  The  micromobility
     protocols reduce handover latency due to a lag time as by quickly fixing up routes converge over the
     access network. The exact amount of latency depends on the convergence
     characteristics of
     between the particular IGP boundary router and the topology of the access
     network, i.e. how fast convergence occurs along routes taken by the mobile
     node's traffic. 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 Host route distribution using an IGP requires  Reduction  in  Handover-related  Signaling  Volume:  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. However, if a mobile node is moving quickly, the
     flooding traffic necessary to propagate a host route may not converge before
     the mobile node hands over again. This could result in 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
     ensure convergence places an upper bound on the size of the domain or
     expected movement speed of the mobile nodes. new link.

     Goal #3 Location privacy: No care-of address changes are exposed to
     correspondent nodes or the mobile node itself while the mobile node
     is moving in the localized mobility
     management domain. 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. micromobility-managed network.

     Goal #4 Use of Wireless Resources: The only additional over-the-air
     signaling involved is signaling involved in propagating host routes from the mobile
     node to the access router indicating that the mobile node
     has moved. network upon movement. Since this signaling would be
     required for movement detection in any case, it is expected to be
     minimal. Mobile node traffic experiences no overhead.

     Goal #5 Limit the Signaling Overhead in the Network: Host route
     propagation is required throughout the wired network. The volume of
     signaling could be more or less depending on the speed of mobile
     node movement and the size of the wired network.

     Goal #6 Security Between Mobile Node and Network: 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 This Support for Heterogeneous Wireless Link Technologies:
     HMIPv6  The  micromobility  protocols  support  multiple  wireless
     technologies, so this goal is satisfied by default, since the IGPs are used over the
     wired backbone. satisfied.

     Goal #8 Support for Unmodified Mobile Nodes: The mobile node needs to perform must
     support some kind of active movement
     detection with proof way of identity to trigger signaling the host route distribution, access router on link handover,
     but this kind of signaling is needed required for movement regardless detection anyway. The nature of whether
     localized mobility management is deployed. Depending on
     the wireless link
     type, this may be handled by signaling for the wireless link layer. micromobility protocols may require mobile
     node software changes, however.

     Goal #9  Since the IGPs support both Re-use of Existing Protocols Where Sensible: Support for
     IPv4 and IPv6, both are supported by
     this technique. IPv6: Most of the work on the micromobility protocols was
     done in IPv4, but little difference could be expected for IPv6.

     Goal #10 This solution re-uses does not reuse an existing protocols, OSPF or IS-IS.

  9.6 protocol because
     there is currently no Internet Standard protocol for micromobility.

     Goal  #11  Localized  Mobility  Management  Independent  of  Global
     Mobility Management: This solution separates global and local
     mobility management, since the micromobility protocols only support
     localized mobility management.

  10.5 Summary

     The following table summarizes the discussion in Section 9.1
     through 9.5. In the table, a "M" indicates that the protocol
     completely meets the goal, a "P" indicates that it partially meets
     the goal, and an "X" indicates that it does not meet the 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