Internet Draft                                       J. Kempf, Editor
  Document: draft-ietf-netlmm-nohost-req-03.txt

  Expires: December, 2006                              June, draft-ietf-netlmm-nohost-req-04.txt        August, 2006

  Expires: Feburary, 2007

        Goals for Network-based Localized Mobility Management (NETLMM)
                    (draft-ietf-netlmm-nohost-req-03.txt)
                    (draft-ietf-netlmm-nohost-req-04.txt)

  Status of this Memo

     By submitting this Internet-Draft, each author represents that any
     applicable patent or other IPR claims of which he or she is aware
     have been or will be disclosed, and any of which he or she becomes
     aware will be disclosed, in accordance with Section 6 of BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups. Note that
     other groups may also distribute working documents as Internet-
     Drafts.

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

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

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

  Contributors

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

  Abstract

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

  Table of Contents

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

  1.0    Introduction

     In [1], [9], the basic problems that occur when a global mobility
     protocol is used for managing local mobility are described, and two
     basic approaches to localized mobility management - the host-based
     approach that is used by most IETF protocols, and the proprietary
     WLAN switch approach used between WLAN switches in different
     subnets - are examined. The conclusion from the problem statement
     document is that none of the approaches has a complete solution to
     the problem. While the WLAN switch approach is most convenient for
     network operators and users because it requires no software on the
     mobile  node  other  than  the  standard  drivers  for  WiFi,  the
     proprietary nature limits interoperability and the restriction to a
     single wireless link type and wired backhaul link type restricts
     scalablity.
     scalability. The IETF host-based protocols require host software
     stack changes that may not be compatible with all global mobility
     protocols,  and  also  require  specialized  and  complex  security
     transactions with the network that may limit deployability. The 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]. [20]. The architecture of the NETLMM
     protocol for which the goals in this document have been formulated
     is described in Section 4 5 of [1]. [9].

  1.1 Terminology

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

  2.0    Goals for Localized Mobility Management

     Section 2 of [1] [9] describes three problems with using a global
     mobility management protocol for localized mobility management. Any
     localized mobility management protocol must naturally address these
     three problems. In addition, the side effects of introducing such a
     solution into the network need to be limited. In this section, we
     address goals on a localized mobility solution including both
     solving the basic problems (Goals 1, 2, 3) and limiting the side
     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 specialized network equipment. A good discussion of their
     applicability to IETF protocols can be found in [4]. [3].

     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
     subnet  configuration  and  global  mobility  management  signaling
     completes. During this time the mobile node is unreachable at its
     former topological location on the old link where correspondents
     are sending packets and to which 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, in the IETF and elsewhere, to reduce the latency in IP
     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 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. This delay is difficult to quantify, but for voice
     traffic, the entire handover delay including Layer 2 handover time
     and IP handover time should be between 40-70 ms to avoid any
     degradation in call quality.

     A goal of the protocol is to reduce the loss of accurate forwarding
     to reduce interruptions which may cause user-perceptible service
     degradation for real time traffic such as 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  using  address  autoconfiguration  is  required  to
     reconfigure on every move between links, the following signaling
     must be performed:

     1) Movement detection using DNA [6] or possibly a link specific
        protocol,
     2) Any link layer or IP Link layer AAA signaling, such as signaling required for handover and reauthentication.
        For example, in 802.11 [6] this is the Reassociate message
        together with 802.1x [7] or
        PANA [8]. reauthentication using EAP.
     2) Active   IP   level   movement   detection,   including   router
        reachability.    The    DNA    protocol    [4]    uses    Router
        Solicitation/Router Advertisement for this purpose. In addition,
        if SEND [1] is used and the mobile node may also or instead does not have to obtain a
        router  authorization
        certificate  using  SEND  [9],  if cached for the
        certificate is not already cached, router, the mobile node must use
        Certification Path Solicitation/Certification Path Advertisement
        to obtain a certification path.
     3) Router discovery which may be part Two Multicast Listener Discovery (MLD) [19] REPORT messages, one
        for each of movement detection,
     4) If  stateless  address  autoconfiguration  is  used, the solicited node multicast addresses corresponding
        to the link local address
        configuration and Duplicate Address Detection (unless optimistic
        Duplicate Address Detection [10] is used) including the global address,
     4) Two Neighbor Solicitation (NS) messages for duplicate address
        detection, one for the link local addresses. If stateful address configuration is used, then
        DHCP is used and one for address configuration, the global
        address. If the addresses are unique, no response will be
        forthcoming.
     5) Two NS messages from the router for address resolution of the
        link local and global addresses, and two Neighbor Advertisement
        messages in response from the mobile node,
     6) Binding Update to Update/Binding Acknowledgement between the mobile node
        and home agent,
     6) If route optimization is in effect, return agent to update the care of address binding,
     7) Return routability signaling between the correspondent node and
        mobile node to establish the binding key,
     7) consisting of one Home
        Test Init/Home Test and Care of Test Init/Care of Test,
     8) Binding Update to Update/Binding Acknowledgement between the correspondent nodes
        node and mobile node for route optimization.

     Note that Steps 1-2 will always may be necessary, even for intra-link
     mobility. Step 3 will be necessary even mobility,
     if the mobile node's care-
     of wireless link protocol doesn't provide much help for IP
     handover.  Step  3-5  will  be  different  if  stateful  address can remain the same when it moves
     configuration is used, since additional messages are required to a new access
     router.
     obtain the address. Steps 5 through 7 6-8 are only necessary when Mobile IPv6
     is used. The result is approximately 10 18 messages at the IP level level,
     where the exact number depends on various specific factors such as
     whether the mobile node has a router certificate cached or not,
     before a mobile node can be ensured that it is established on a
     link and has full IP connectivity. 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  for  Mobile  IPv6  have  been
     discussed in
     [11], [12], 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 If the mobile node sources packets with its local
     IP address in the clear, for example through route optimization in
     Mobile IPv6, the correspondent node or an 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. 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. Others are attacks in which the correspondent
     itself is the attacker, and the correspondent deliberately starts a
     session with the mobile node in order to track its location by
     noting the source address of packets originating from the mobile
     node. Note that the location privacy referred to here is different
     from the location privacy discussed in [14][15][16]. [12]. 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 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. 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
     granularity of the location information.

  2.4 Efficient Use of Wireless Resources (Goal #4)

     Advances in wireless physical layer and 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 physical layer. It is not possible to lay an extra
     cable if the link becomes increasingly congested as is the case
     with wired links.

     While header compression technology can remove header overhead, 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 Limit the Signaling Overhead in the Network (Goal #5)

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

     If the access router deduces mobile node movement based on active
     IP-level movement detection by the mobile node, then authentication
     is required for the IP-level movement detection messages from the
     mobile node to ensure that the mobile node is authorized to possess
     the address used for the movement detection. The authorization may
     be at the IP level or it may be tied to the original network 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 the NETLMM protocol are discussed in
     [2].
     [20].

     In summary, ruling out mobile node involvement in local mobility
     management simplifies security by removing the need for service-
     specific credentials to authenticate and authorize the mobile node
     for localized mobility management in the network. This puts
     localized mobility management on the same level as basic IP
     routing. Hosts obtain this service as part of their network access.
     If the 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 how some
     networks restrict routing to the Internet before network access
     authentication and open it afterwards.

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

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

     The goal is that the localized mobility management protocol should
     not use any wireless link specific information for basic routing
     management, though it may be used for other purposes, such as
     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 localized
     mobility management. Being able to accommodate unmodified mobile
     nodes enables a service provider to offer service to as many
     customers as possible, the only constraint being that the customer
     is authorized for network access.

     Another advantage of minimizing mobile node software for localized
     mobility management is that multiple global mobility management
     protocols can be supported. There are a variety of global mobility
     management  protocols  that  might  also  need  support,  including
     proprietary or wireless link technology-specific protocols needing
     support for backward compatibility reasons. Within the Internet,
     both HIP [12] [14] and Mobike [13] [5] 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 and
     maintain session continuity, although no global mobility protocol
     is required if the mobile node only moves within the coverage area
     of  the  localized  mobility  management  protocol  or  no  session
     continuity is required during global movement. Also, every wireless
     link protocol requires handover support on the mobile node in the
     physical  and  medium  access  control  layers,  typically  in  the
     wireless interface driver. Information passed from the medium
     access control layer to the IP layer on the mobile node may be
     necessary to trigger IP signaling for IP handover. Such movement
     detection support at the IP level may be required in order to
     determine  whether  the  mobile  node's  default  router  is  still
     reachable after the move to a new access point has occurred at the
     medium access control layer. Whether or not such support is
     required depends on whether the medium access control layer can
     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 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 the decision for handover is
     entirely in the hands of the mobile node, IP layer movement
     detection signaling from the mobile node may be required to trigger
     a routing update.

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

  2.11 Localized Mobility Management Independent of Global Mobility
       Management

     Localized  mobility  management  should  be  implementable  and
     deployable  independently  of  any  global  mobility  management
     protocol. This enables the choice of local and global mobility
     management to be made independently of particular protocols that
     are implemented and deployed to solve the two different sorts of
     mobility management problems. The operator can choose a particular
     localized mobility management protocol according to the specific
     features of their access network. It can subsequently upgrade the
     localized mobility management protocol on its own, without even
     informing the mobile nodes. Similarly, the mobile nodes can use a
     global  mobility  management  protocol  that  best  suits  their
     requirements, or even not use one at all. Also, a mobile node can
     move into a new access network without having to check that it
     understands the localized mobility management  protocol being used
     there.

     The goal is that the implementation and deployment of the localized
     mobility management protocol should not restrict, or be restricted
     by, the choice of global mobility management protocol.

  2.12 Configurable Data Plane Forwarding between Mobility Anchor and
       Access Router

     Different  network  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  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
     localized mobility management domain runs over a public access
     network and the network operator wants to protect the traffic.

     A goal of the NETLMM protocol is to allow the forwarding between
     the mobility anchor and access routers to be configurable depending
     on the particulars of the network deployment. Configurability is
     not expected to be dynamic as in controlled by the arrival of a
     mobile node; but rather, configuration is expected to be similar in
     time scale to configuration for routing. The NETLMM protocol may
     designate a default forwarding mechanism. It is also possible that
     additional work may be required to specify the interaction between
     a particular forwarding mechanism and the NETLMM protocol, but this
     work is not in scope of the NETLMM base protocol.

  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 network-based
     localized mobility management: security between the mobile node and
     the network, and security between network elements that participate
     in the network-based localized mobility management protocol

     Security between the mobile node and the network itself consists of
     two parts: threats involved in localized mobility management in
     general,  and  threats  to  the  network-based  localized  mobility
     management from the host. The first is discussed above in Sections
     2.3 and 2.6. The second is discussed in the threat analysis
     document [2]. [20].

     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 mutual authentication and authorization of network
     elements that participate in the network-based localized mobility
     management  protocol,  and  data  origin  authentication  on  the
     signaling traffic between network elements.

  5.0    Acknowledgements

     The  authors  would  like  to  acknowledge  the  following  for
     particularly diligent reviewing: Vijay Devarapalli, Peter McCann,
     Gabriel  Montenegro,  Vidya  Narayanan,  Pekka  Savola,  and  Fred
     Templin.

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

  7.0    Informative References

       [1] Arkko, J., Kempf, J., editor, "Problem Statement for IP Local Mobility,"
           Internet Draft, Work in Progress. Zill, B., and Nikander, P., "SEcure
           Neighbor Discovery (SEND)", RFC 3971, March, 2005.
       [2] Vogt, Campbell, A., Gomez, J., Kim, S., Valko, A., and Wan, C.,
           "Design, Implementation and Kempf, J., "Security Threats to Network-based
           Localized Mobillity Management", Internet draft, Work in
           Progress. Evaluation of Cellular IP", IEEE
           Personal Communications, June/July 2000.
       [3] Manner, J., and 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., and Arkko, J., "Mobility Support in
           IPv6", RFC 3775.
       [6] Choi, J,
       [4] Choi, J, and Daley, G., "Goals of Detecting Network
           Attachment in IPv6", Internet Draft, work Work in progress. Progress.
       [5] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol
           (MOBIKE)", RFC 4555, June 2006.
       [6] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical
           Layer (PHY) specifications", IEEE Std. 802.11, 1999.
       [7] IEEE, "Port-based Access Control", IEEE LAN/MAN Standard
           802.1x, June, 2001.
       [8] Forsberg, Johnson, D., Ohba, Y., Patil, B., Tschofenig, H., Perkins, C., and Yegin,
           A., "Protocol for Carrying Authentication Arkko, J., "Mobility Support in
           IPv6", RFC 3775.
       [9] Kempf, J., editor, "Problem Statement for Network Access
           (PANA)", IP Local Mobility,"
           Internet Draft, work Work in progress.
       [9] Arkko, J., Progress.
      [10] Kempf, J., Zill, B., and Nikander, P., "SEcure
           Neighbor Discovery (SEND)", RFC 3971, March, 2005.
      [10] Moore, N., "Optimistic Neighbor Discovery", Koodli, R., "Distributing a Symmetric FMIPv6
           Handover Key using SEND", Internet Draft, Work in Progress.
      [11] Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., Park,
           S.D., and Patil, B., "Privacy Koodli, R., editor, "Fast Handovers for Mobile IPv6", RFC
           4068, July, 2005.
      [12] Koodli, R., " IP Address Location Privacy and Multi-homed
           Nodes: MoMiPriv Mobile IPv6:
           Problem Statement", Internet Draft, work Work in
           progress.
      [12] Progress.
      [13] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC
           3753, June, 2004.
      [14] Moskowitz, R., and Nikander, P., "Host Identity Protocol
           (HIP) Architecture", RFC 4423, May, 2006.
      [13] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol
           (MOBIKE)", Internet Draft, Work in Progress.
      [14] Koodli, R., "IP Address Location Privacy and IP Mobility",
           Internet Draft, Work in Progress.
      [15] Koodli, R., Devarapalli, Narayanan, V., Flinck, Venkitaraman, N., Tschofenig, H., Giaretta,
           G., and Perkins, C.,
           "Solutions for IP Address Location Privacy in the presence of
           IP Mobility", Bournelle, J., "Handover Keys Using AAA", Internet
           Draft, Work in Progress.

      [16] Bao, F., Deng, Ramjee, R., Kempf, J., Qui, Y., La Porta, T., Thuel, S., and Zhou, J.,
           "Protocol Varadhan, K.,
           "HAWAII: A domain-based approach for Protecting Movement of Mobile Nodes supporting mobility in Mobile
           IPv6", Internet Draft, Work
           wide-area wireless networks", in Progress. Proceedings of the
           International Conference on Networking Protocols (ICNP),
           1999.
      [17] Soliman, H., Tsirtsis, G., Devarapalli, V., Kempf, J.,
           Levkowetz, H., Thubert, P, and Wakikawa, R. "Dual Stack
           Mobile IPv6 (DSMIPv6) for Hosts and Routers", Internet Draft,
           Work in Progress.
      [18] Koodli, R., editor, "Fast Handovers for Mobile IPv6", RFC
           4068, July, 2005.
      [19] Soliman, H., Castelluccia, C., El Malki, K., and Bellier, L.,
           "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC
           4140, August, 2005.
      [19] Vida, R., and Costa, L., " Multicast Listener Discovery
           Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
      [20] Vogt, C., and Kempf, J., and Koodli, R., "Distributing a Symmetric FMIPv6
           Handover Key using SEND", Internet Draft, work in progress.
      [21] Narayanan, V., Venkitaraman, N., Tschofenig, H., Giaretta,
           G., and Bournelle, J., "Handover Keys Using AAA", "Security Threats to Network-based
           Localized Mobillity Management", Internet Draft, Work in
           Progress.
      [22] Campbell, A., Gomez, J., Kim, S., Valko, A., and Wan, C.,
           "Design, Implementation and Evaluation of Cellular IP", IEEE
           Personal Communications, June/July 2000.
      [23] Ramjee, R., La Porta, T., Thuel, S., and Varadhan, K.,
           "HAWAII: A domain-based approach

  8.0   Appendix: Gap Analysis

     This section discusses a gap analysis between existing proposals
     for supporting solving localized mobility management and the goals in
           wide-area wireless networks", Section.
     2.0.

  8.1  Mobile IPv6 with Local Home Agent

     One option is to deploy Mobile IPv6 with a locally assigned home
     agent in Proceedings of the
           International Conference on Networking Protocols (ICNP),
           1999.

  8.0  IPR Statements

     The IETF takes no position regarding local network. This solution requires the validity or scope of any
     Intellectual Property Rights or other rights that might be claimed
     to pertain mobile node
     to somehow be assigned a home agent in the implementation or use local network when it
     boots up. This home agent is used instead of the technology described home agent in the
     home network. The advantage of this document or option is that no special
     solution is required for edge mobility - the extent to which any license under such
     rights might or might not be available; nor does it represent mobile node reuses the
     global mobility management protocol for that
     it has made any independent effort to identify any such rights.
     Information on purpose - if the procedures with respect to rights in RFC
     documents can be found in BCP 78 and BCP 79.

     Copies
     mobile node is using Mobile IPv6.

     The analysis of IPR disclosures made to this approach against the IETF Secretariat and any
     assurances of licenses to be made available, or goals above is the result of an
     attempt made
     following.

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

     Goal #2 Reduction in Handover-related Signaling Volume: Similarly
     to obtain a general license or permission Goal #1, signaling volume is reduced if no route optimization
     signaling is done on handover.

     Goal  #3  Location  privacy:  Location  privacy  is  preserved  for the use
     external correspondents as long as all of such proprietary rights by implementers or users the mobile node's traffic
     is routed through the local HA.

     Goal #4 Efficient Use of this
     specification can be obtained from Wireless Resources: If traffic is not
     route optimized, the IETF on-line IPR repository
     at http://www.ietf.org/ipr.

     The IETF invites any interested party to bring to its attention any
     copyrights, patents or patent applications, or other proprietary
     rights that may cover technology that may be required mobile node still pays for an over-the-air
     tunnel to implement
     this standard.  Please address the information to locally assigned home agent. The overhead here is
     exactly the IETF at ietf-
     ipr@ietf.org.

  9.0  Disclaimer of Validity

     This document and same as if the information contained herein are provided on
     an "AS IS" basis mobile node's home agent in the home
     network is used and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
     REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
     THE  INTERNET  ENGINEERING  TASK  FORCE  DISCLAIM  ALL  WARRANTIES,
     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
     THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
     ANY  IMPLIED  WARRANTIES  OF  MERCHANTABILITY  OR  FITNESS  FOR  A
     PARTICULAR PURPOSE.

  10.0     Copyright Notice

     Copyright (C) The Internet Society (2006).  This document route optimization is
     subject to not done.

     Goal #5 Limit the rights, licenses and restrictions contained Signaling Overhead in BCP
     78, and except as set forth therein, the authors retain all their
     rights.

  11.0     Appendix: Gap Analysis

     This section discusses a gap analysis between existing proposals
     for solving Network: If the
     localized mobility management and domain is large, the goals in Section.
     2.0.

  11.1 Mobile IPv6 with Local Home Agent

     One option mobile node may
     suffer from unoptimzed routes. RFC 3775 [8] provides no support for
     notifying a mobile node that another localized home agent is to deploy Mobile IPv6 with
     available for a locally assigned more optimized route, or for handing over between
     home agents. A mobile node would have to perform the full home
     agent in bootstrap procedure, including establishing a new IPsec SA
     with the new home agent.

     Goal #6 No Extra Security Between Mobile Node and Network: A local network. This solution
     home agent in a roaming situation requires the guest mobile node to somehow be assigned a
     have the proper credentials to authenticate with the local home
     agent in the local serving network. The credentials used for network when it
     boots up. This home agent is
     access  authentication  could  also  be  used instead of  for  mobile  service
     authentication and authorization if the local home agent in uses EAP
     over IKEv2 to authenticate the mobile node with its home network. The advantage of this option is that no special
     solution is required for edge mobility - AAA
     server. This may require additional authorization between the mobile node reuses home
     and visited networks to use the
     global mobility management protocol same credentials for that purpose - a different
     service, however. In addition, as in Goal #3, if binding updates
     are done in cleartext over the access network or the mobile node is using Mobile IPv6.

     The analysis of this approach against
     has become infected with malware, the goals above is local home agent's address
     could be revealed to attackers and the
     following.

     Goal #1 Handover Performance Improvement: If local home agent could
     become the mobile node does
     not perform route optimization, target of a DoS attack. So a local home agent would
     provide no benefit for this goal.

     Goal #7 Support for Heterogeneous Wireless Link Technologies: This
     solution reduces, but does not
     eliminate, supports multiple wireless technologies with separate IP handover related performance problems.

     Goal #2 Reduction in Handover-related Signaling Volume: Similarly
     to Goal #1, signaling volume is reduced if no route optimization
     signaling
     subnets for different links. No special work is done on handover. required to
     interface a local home agent to different wireless technologies.

     Goal  #3  Location  privacy:  Location  privacy  is  preserved #8 Support for
     external correspondents, but the Unmodified Mobile Nodes: The mobile node itself still maintains
     a  local  care-of  address.  If  the must
     support Mobile IPv6 in order for this option to work. So mobile
     node  performs  route
     optimization,  location  privacy  may  be  compromised,    but changes are required and other IP mobility protocols are not
     performing route optimization is no better than having a remote
     home agent.
     supported.

     Goal #4 Efficient Use of Wireless Resources: If traffic is not
     route optimized, the mobile node still pays #9 Support for an over-the-air
     tunnel to the locally assigned home agent. IPv4 and IPv6: The overhead here Mobile IPv6 working group is
     exactly the same as if
     working on modifying the mobile node's home agent protocol to allow registration of IPv4
     care of addresses in the an IPv6 home
     network is used agent, and route optimization is not done. also to allow a mobile
     node to have an IPv4 care of address [17].

     Goal #5 Limit the Signaling Overhead in the Network: If the #10 Re-use of Existing Protocols Where Sensible: This solution
     re-uses an existing protocol, Mobile IPv6.

     Goal  #11  Localized  Mobility  Management  Independent  of  Global
     Mobility  Management:  This  solution  merges  localized  mobility
     management domain is large, and global mobility management, so it does not support
     the mobile node may
     suffer from unoptimzed routes. RFC 3775 [5] goal.

  8.2  Hierarchical Mobile IPv6 (HMIPv6)

     HMIPv6  [18]  provides no support for
     notifying a mobile node that another  the  most  complete  localized home agent is  mobility
     management  solution  available for  today.  In  HMIPv6,  a more optimized route, or  localized
     mobility anchor called a MAP serves as a routing anchor for handing over between
     home agents. A a
     regional care of address. When a mobile node would have moves from one access
     router to perform another, the full home
     agent bootstrap procedure, including establishing a new IPsec SA
     with mobile node changes the new home agent.

     Goal #6 No Extra Security Between Mobile Node binding between its
     regional care of address and Network: A local
     home agent in a roaming situation requires care of address at the guest mobile node to
     have MAP. No
     global mobility management signaling is required, since the proper credentials care of
     address seen by correspondents does not change. This part of HMIPv6
     is similar to authenticate with the local home
     agent solution outlined in Section 8.1; however, HMIPv6
     also allows a mobile node to hand over between MAPs.

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

     The analysis of this approach against the local home agent uses EAP
     over IKEv2 to authenticate goals above is the mobile node
     following.

     Goal #1 Handover Performance Improvement: This solution shortens,
     but does not eliminate, the latency associated with its home AAA
     server, IP handover,
     since it reduces the two sets amount of credentials are in principle different, signaling and
     could require additional credential provisioning. In addition, as
     in the length of the
     signaling paths.

     Goal #3, if binding updates are done #2 Reduction in cleartext over Handover-related Signaling Volume: Signaling
     volume is reduced simply because no route optimization signaling is
     done on handover within the
     access network or coverage area of the MAP.

     Goal  #3  Location  privacy:  Location  privacy  is  preserved  for
     external correspondents.

     Goal #4 Use of Wireless Resources: The mobile node has become infected with malware,
     the local home agent's address could be revealed always pays for
     an over-the-air tunnel to attackers and the local MAP. If the mobile node is tunneling
     through a global home agent could become or VPN gateway, the target 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 Network: From Goal #1
     and Goal #4, the signaling overhead is no more or less than for
     mobile nodes whose global mobility management anchor is local.
     However, because MAP handover is possible, 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  expense  of  the  configuration  and
     management overhead involved in maintaining multiple MAP coverage
     areas.

     Goal #6 Extra Security Between Mobile Node and Network: In a DoS attack. So
     roaming situation, the guest mobile node must have the proper
     credentials to authenticate with the MAP in the serving network. In
     addition, since the mobile node is required to have a unicast
     address for the MAP that is either globally routed or routing
     restricted  to  the  local home agent would provide no benefit  administrative  domain,  the  MAP  is
     potentially a target for this goal. DoS attacks across a wide swath of network
     topology.

     Goal #7 Support for 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 home agent to different wireless technologies.

     Goal #8 Support for Unmodified Mobile Nodes: The This solution requires
     modification to the mobile node must
     support nodes. In addition, the HMIPv6 design
     has been optimized for Mobile IPv6 in order for this option to work. So mobile
     node changes are required nodes, and other IP mobility protocols are is not
     supported. a good
     match for other global mobility management protocols.

     Goal #9 Support for Currently, there is no IPv4 and IPv6: The version of this protocol;
     although there is an expired Internet draft with a design for a
     regional registration protocol for Mobile IPv6 working group IPv4 that has similar
     functionality.  It  is
     working on modifying  possible  that  the protocol to allow registration of  same  IPv4
     care-of addresses in an  transition
     solution as used for Mobile IPv6 home agent, and also to allow a mobile
     node to have an IPv4 care of address [17]. could be used [17] above.

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

     Goal  #11  Localized  Mobility  Management  Independent  of  Global
     Mobility  Management:  This  solution  merges  localized  mobility
     management  While  HIMPv6  is  technically  a  separate
     protocol from MIPv6 and global mobility management, so it does not support could in principle be implemented and
     deployed  without  MIPv6,  the goal.

  11.2 Hierarchical Mobile IPv6 (HMIPv6)

     HMIPv6  [19]  provides  design  is  very  similar  and
     implementation and deployment would be easier if 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 moves from one access
     router nodes
     supported MIPv6.

  8.3  Combinations of Mobile IPv6 with Optimizations

     One approach to another, the mobile node changes the binding between its
     regional care-of address and local care-of address at the MAP. No
     global mobility management signaling is required, since that has received much attention in
     the care-of
     address seen by correspondents does not change. This part past and has been thought to provide a solution is combinations
     of HMIPv6 protocols. The general approach is similar to try to cover gaps in the
     solution outlined in Section 11.1; however,
     HMIPv6 also allows a mobile node to hand over between MAPs.

     Handover between MAPs and MAP discovery requires configuration on
     the routers. MAP addresses are advertised provided by access routers.
     Handover happens MIPv6 by overlapping MAP coverage areas so that, using other protocols. In this
     section, gap analyses for
     some number MIPv6 + FMIPv6 and HMIPv6 + FMIPv6 are
     discussed.

  8.3.1 MIPv6 with local home agent + FMIPv6

     As discussed in Section 8.1, the use of access routers, more than one MAP may be advertised. MIPv6 with a dynamically
     assigned, local home agent cannot fulfill the goals. A fundamental
     limitation is that Mobile nodes need IPv6 cannot provide seamless handover
     (i.e. Goal #1). FMIPv6 [11] above has been defined with the intent
     to switch MAPs in improve the transition area, handover performance of MIPv6. For this reason, the
     combined usage of FMIPv6 and then
     must  perform  global MIPv6 with a dynamically assigned
     local home agent has been proposed to handle local mobility.

     Note that this gap analysis only applies to localized mobility  management  update
     management, and  route
     optimization to the new regional care-of address, if appropriate. it is possible that MIPv6 and FMIPv6 might still be
     acceptable for global mobility management.

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

     Goal  #1  Handover  Performance  Improvement: This  FMIPv6  provides  a
     solution shortens,
     but does not eliminate, the latency associated with IP handover,
     since it reduces for handover performance improvement that should fulfill
     the amount goals raised by real-time applications in terms of signaling jitter,
     delay and the length packet loss. The location of the
     signaling paths. home agent (in local or
     home domain) does not affect the handover latency.

     Goal #2 Reduction in Handover-related Signaling Volume: Signaling
     volume is reduced simply because no FMIPv6
     requires the mobile node to perform extra signaling with the access
     router (i.e. exchange of RtSolPr/PrRtAdv and FBU/FBA). Moreover, as
     in standard MIPv6, whenever the mobile node moves to another link,
     it must send a Binding Update to the home agent. If route
     optimization signaling  is
     done on handover within  used,  the coverage area  mobile  node  also  performs  return
     routability and sends a Binding Update to each correspondent node.
     Nonetheless, it is worth noting that FMIPv6 should result in a
     reduction of the MAP. amount of IPv6 Neighbor Discovery signaling on the
     new link.

     Goal #3 Location privacy:  Location  privacy The mobile node maintains a local care of
     address. If route optimization is  preserved  for
     external correspondents. not used, location privacy can be
     achieved using bi-directional tunneling.

     Goal #4 Use of Wireless Resources: The mobile node always pays As stated for
     an Goal #2, the
     combination of MIPv6 and FMIPv6 generates extra signaling overhead.
     For data packets, in addition to the Mobile IPv6 over-the-air
     tunnel, there is a further level of tunneling between the mobile
     node and the previous access router during handover. This tunnel is
     needed to forward incoming packets to the MAP. If the mobile node addressed to
     the previous care of address. Another reason is tunneling
     through that, even if the
     mobile node has a global home agent or VPN gateway, valid new care of address, the wired link
     experiences double tunneling. Over-the-air mobile node cannot
     use the new care of address directly with its correspondents
     without performing route optimization to the new care of address.
     This implies that the transient tunnel overhead can be
     removed by header compression, however. is in place even
     for route optimized traffic.

     Goal #5 Limit the Signaling Overhead in the Network: From Goal #1
     and Goal #4, the FMIPv6
     generates extra signaling overhead is no more 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 between the previous access
     router  and  handing  over,  at  the  expense  new  access  router  for  the  HI/HAck  exchange.
     Concerning data packets, the use of FMIPv6 for handover performance
     improvement implies a tunnel between the  configuration previous access router and
     management
     the mobile node that adds some overhead involved in maintaining multiple MAP coverage
     areas. the wired network. This
     overhead has more impact on star topology deployments, since
     packets are 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 a
     roaming situation, the guest mobile node must have the proper
     credentials addition
     to authenticate with the MAP analysis for Mobile IPv6 with local home agent in the serving network. In
     addition, since Section
     8.1, FMIPv6 requires the mobile node is required and the previous access router
     to have  share  a unicast
     address for the MAP that is either globally routed or routing
     restricted  security  association  in  order  to  secure  FBU/FBA
     exchange. Two solutions have been proposed: a SEND-based solution
     [10] above and an AAA-based solution [15]. Both solutions require
     additional support on the  local  administrative  domain, mobile node and in the  MAP network beyond
     what is
     potentially a target required for DoS attacks across a wide swath of network
     topology. access authentication.

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

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

     Goal #9 Currently, there is no Support for IPv4 version of this protocol;
     although there and IPv6: Work is an expired Internet draft underway to extend MIPv6
     with a design for a
     regional registration protocol for Mobile the capability to run over both IPv6-enabled and IPv4-only
     networks [17] above. FMIPv6 only supports IPv6. Even though an IPv4 that
     version of FMIP has similar
     functionality.  It been recently proposed, it is  possible  that  the  same  IPv4  transition
     solution as used for Mobile IPv6 not clear how it
     could be used [17]. 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 an existing protocol, HMIPv6. protocols, Mobile IPv6 and FMIPv6.

     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  This  solution  merges  localized  mobility
     management and deployment would be easier if global mobility management, so it does not support
     the mobile nodes
     supported MIPv6.

  11.3 Combinations goal.

  8.3.2 HMIPv6 + FMIPv6

     HMIPv6 provides several advantages in terms of Mobile IPv6 with Optimizations

     One approach to local mobility that has received much attention
     management. However, as seen in Section 8.2, it does not fulfill
     all the past and has been thought to provide a solution is combinations
     of protocols. The general approach is to try to cover gaps goals identified in the
     solution provided by MIPv6 by using other protocols. Section 2.0. In this
     section, gap analyses for MIPv6 + FMIPv6 and particular, HMIPv6 + FMIPv6 are
     discussed.

  11.3.1   MIPv6 with local home agent + FMIPv6
     As discussed in Section 11.1, the use of MIPv6 with a dynamically
     assigned, local home agent cannot fulfill the 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 does
     not completely eliminate the IP handover performance of MIPv6. latency. For this reason, the
     combined usage of
     FMIPv6 and MIPv6 could be used together with a dynamically assigned
     local home agent has been proposed HMIPv6 in order to handle local mobility. cover the
     gap.

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

     The analysis of this combined approach against the goals follows.

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

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

     Goal #3 Location privacy: The mobile node mantains a local care-of
     address. If route optimization is not used, HMIPv6 may preserve location privacy can be
     achieved using bi-directional tunneling. privacy,
     depending on the dimension of the geographic area covered by the
     MAP.

     Goal #4 Use of Wireless Resources: As stated mentioned for Goal #2, the
     combination of MIPv6 HMIPv6 and FMIPv6 generates extra a lot of signaling overhead.
     For data packets,
     overhead in the network. Concerning payload data, 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 the previous access router during handover. This tunnel is
     needed to forward incoming packets to the mobile node addressed to
     the previous care-of address. Another reason is that, even if the
     mobile node has a valid new care-of address, the mobile node cannot
     use the new care of address directly with its correspondents
     without performing route optimization to the new care of address.
     This implies MAP. Notice that the transient this tunnel overhead is
     in place even for route optimized traffic.

     Goal #5 Limit the Signaling Overhead in the Network: Moreover, if FMIPv6
     generates extra signaling overhead between the previous access
     router  and  the  new  access  router  for  the  HI/HAck  exchange.
     Concerning data packets, the use of FMIPv6 for handover performance
     improvement implies is
     directly applied to HMIPv6 networks, there is a third temporary
     handover-related tunnel between the mobile node and previous access router
     router. Again, there is much work in the academic literature and
     IETF on ways to reduce the mobile node that adds some extra tunnel overhead on handover by
     combining HMIP and FMIP tunneling.

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

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

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

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

     Goal #9 Support for IPv4 and IPv6: Work Currently there is no IPv4
     version of HMIPv6. There 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 has been recently proposed, but it is not
     clear how it could be 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, Mobile IPv6 HMIPv6 and FMIPv6.

     Goal  #11  Localized  Mobility  Management  Independent  of  Global
     Mobility  Management:  This  solution  merges  localized  mobility
     management  While  HIMPv6  is  technically  a  separate
     protocol from MIPv6 and global mobility management, so it does not support could in principle be implemented and
     deployed  without  MIPv6,  the goal.

  11.3.2   HMIPv6 + FMIPv6

     HMIPv6 provides several advantages  design  is  very  similar  and
     implementation and deployment would be easier if the mobile nodes
     supported MIPv6.

  8.4  Micromobility Protocols

     Researchers  have  defined  some  protocols  that  are  often
     characterized as micromobility protocols. Two typical protocols in terms of
     this category are Cellular-IP [2] and HAWAII [16]. Researchers
     defined these protocols before local mobility
     management. However, optimizations for
     Mobile IP such as seen FMIP and HMIP were developed, in order to reduce
     handover latency. Cellular-IP and HAWAII were proposed in Section 11.2, it does not fulfill
     all the goals identified IETF
     for standardization, but after some study in Section 2.0. In particular, HMIPv6 does
     not completely eliminate the IP handover latency. For this reason,
     FMIPv6 could be used together with HMIPv6 IRTF, were
     dropped. There are many micromobility protocols defined in order to cover the
     gap.

     Note that even if
     academic literature, but in this solution is used, document, the mobile node term is likely used
     specifically to need MIPv6 for global refer to Cellular-IP and HAWAII.

     The  micromobility  approach  to  localized  mobility management, in contrast with  management
     requires  host  route  propagation  from  the
     MIPv6 with dynamically assigned local home agent + FMIPv6 solution.
     Thus, this solution should really be considered MIPv6 + HMIPv6 +
     FMIPv6.

     The analysis  mobile  node  to  a
     collection  of this combined approach against  specialized  routers  in  the goals follows.

     Goal #1 Handover Performance Improvement: HMIPv6 and FMIPv6 both
     shorten  localized  mobility
     management domain along a path back to a boundary router at the latency associated
     edge of the localized mobility management domain. A boundary router
     is  a  kind  of  localized  mobility  management  domain  gateway.
     Localized mobility management is authorized with IP handovers. In particular,
     FMIPv6 the access router,
     but reauthorization with each new access router is expected necessary on
     link movement, in addition to fulfill any reauthorization for basic network
     access. The host routes allow the goals mobile node to maintain the same
     IP address when it moves to a new link, and still continue to
     receive packets on jitter, delay the new link.

     Cellular IP and packet
     loss raised by real-time applications.

     Goal #2 Reduction HAWAII have a few things in Handover-related Signaling Volume: common.  Both FMIPv6
     and HMIPv6 require extra signaling compared are
     compatible with Mobile IPv6. As IP and are intended to provide a
     whole the mobile node performs signaling message exchanges at each higher
     level of handover that are RtSolPr/PrRtAdv, FBU/FBA, LBU/LBA and BU/BA.
     However, as mentioned performance in Section 11.2, the local networks than was previously
     available with Mobile IP without such extensions as HMIP and FMIP.
     Both use host routes installed in a number of HMIPv6 reduces routers within a
     restricted routing domain. Both define specific messaging to update
     those  routes  along  the signaling overhead since no route optimization signaling is
     done for intra-MAP handovers. In addition, naive combinations of
     FMIPv6  forwarding  path  and HMIPv6 often result in redundant signaling. There  specify  how  the
     messaging is
     much work in to be used to update the academic literature routing tables and forwarding
     tables along the IETF on more refined
     ways of combining signaling from path between the two mobile and a micromobility domain
     boundary router at which point Mobile IP is to used to handle
     global mobility in a scalable way. Unlike the FMIP and HMIP
     protocols, however, these protocols do not require the mobile node
     to avoid
     redundant signaling.

     Goal #3 Location privacy: HMIPv6 may preserve location privacy,
     depending obtain a new care of address on each access router as it moves;
     but rather, the dimension mobile node maintains the same care of address
     across the geographic area covered by micromobility domain. From outside the
     MAP.

     Goal #4 Use of Wireless Resources: As mentioned for Goal #2, micromobility
     domain, the
     combination care of HMIPv6 and FMIPv6 generates a lot address is routed using traditional longest
     prefix matching IP routing to the domain's boundary router, so the
     care of signaling
     overhead in address is conceptually withain the network. Concerning payload data, in addition to micromobility domain
     boundary router's subnet. Within the over-the-air MIPv6 tunnel, a further level micromobility domain, the care
     of tunneling address is
     established routed to the correct access router using host
     routes.

     Micromobility  protocols  have  some  potential  drawbacks  from  a
     deployment and scalability standpoint. Both protocols involve every
     routing element between the mobile node device and MAP. Notice that this tunnel is the micromobility
     domain boundary router in place even all packet forwarding decisions specific
     to care of addresses for route optimized traffic. Moreover, if FMIPv6 mobile nodes. Scalability is
     directly applied limited
     because each care of address corresponding to HMIPv6 networks, there is a third temporary
     handover-related tunnel between the mobile node
     generates a routing table entry, and previous access
     router. Again, there is much work perhaps multiple forwarding
     table entries, in every router along the academic literature and
     IETF on ways to reduce path. Since mobile nodes
     can have multiple global care of addresses in IPv6, this can result
     in a large expansion in router state throughout the extra tunnel overhead on handover by
     combining HMIP and FMIP tunneling.

     Goal #5 Limit micromobility
     routing  domain.  Although  the Signaling Overhead in  extent  of  the Network: The signaling
     overhead  scalability  for
     micromobility protocols is still not clearly understood from a
     research standpoint, it seems certain that they will be less
     scalable than the Mobile IP optimization enhancements, and will
     require more specialized gear in the network wired network.

     The following is not reduced by HMIPv6, as mentioned a gap analysis of the micromobility protocols
     against the goals in Section 11.2. Instead, FMIPv6 generates extra signaling overhead 2.0:

     Goal  #1  Handover  Performance  Improvement:  The  micromobility
     protocols reduce handover latency by quickly fixing up routes
     between the previous access boundary router and new access router for
     HI/HAck exchange. For payload data, the same considerations as for
     Goal #4 are applicable.

     Goal #6 Security Between access router. While some
     additional latency may be expected during host route propagation,
     it is typically much less than experienced with standard Mobile Node and Network: FMIPv6 requires IP.

     Goal  #2  Reduction  in  Handover-related  Signaling  Volume:  The
     micromobility protocols require signaling from the mobile node and to
     the previous access router to share a security
     association in order to secure initiate the FBU/FBA exchange. In addition,
     HMIPv6 requires host route propagation, but that
     is a considerable reduction over the amount of signaling required
     to configure to a new link.

     Goal #3 Location privacy: No care of address changes are exposed to
     correspondent nodes or the mobile node and MAP share an IPsec
     security association itself while the mobile node
     is moving in order to secure LBU/LBA exchange. the micromobility-managed network.

     Goal #4 Use of Wireless Resources: The only
     well understood approach additional over-the-air
     signaling is involved in propagating host routes from the mobile
     node to set up an IPsec security association the 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 use wired network. The volume of certificates, but this may raise deployment issues.
     Thus,
     signaling could be more or less depending on the combination speed of FMIPv6 mobile
     node movement and HMIPv6 doubles the amount size of the wired network.

     Goal #6 Security Between Mobile Node and Network: The mobile node to network security protocol required, since
     only requires a security
     for both FMIP and HMIP 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 be deployed.  prove
     authorization to hold the address.

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

     Goal #8 Support for Unmodified Mobile Nodes: The mobile node must
     support both HMIPv6 and FMIPv6 protocols, so some way of signaling the access router on link handover,
     but this goal is not
     fulfilled. required for movement detection anyway. The nature of
     the signaling for the micromobility protocols may require mobile
     node software changes, however.

     Goal #9 Re-use of Existing Protocols Where Sensible: Support for
     IPv4 and IPv6: Currently there is no IPv4
     version of HMIPv6. There is an IPv4 version Most of FMIP the work on the micromobility protocols was
     done in IPv4, but it is not
     clear how it little difference could be used together with FMIPv6 in order to handle
     fast handovers across any wired network. expected for IPv6.

     Goal #10 Re-use of Existing Protocols Where Sensible: This solution re-uses does not reuse an existing protocols, HMIPv6 and FMIPv6. protocol because
     there is currently no Internet Standard protocol for micromobility.

     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 This solution separates global and deployment would be easier if local
     mobility management, since the mobile nodes
     supported MIPv6.

  11.4 Micromobility Protocols

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

  8.5  Summary

     The following table summarizes the IETF
     for standardization, but after some study discussion in Section 9.1
     through 9.5. In the IRTF, were
     dropped. There are many micromobility protocols defined in table, a "M" indicates that the
     academic literature, but in this document, protocol
     completely meets the term is used
     specifically to refer to Cellular-IP and HAWAII.

     The  micromobility  approach  to  localized  mobility  management
     requires  host  route  propagation  from  the  mobile  node  to goal, a
     collection  of  specialized  routers  in "P" indicates that it partially meets
     the  localized  mobility
     management domain along a path back to a boundary router at goal, and an "X" indicates that it does not meet the
     edge 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

  9.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 localized mobility management domain. A boundary router
     is  a  kind implementation or use of  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 movement, technology described
     in addition this document or the extent to which any reauthorization for basic network
     access. The host routes allow the mobile node license under such
     rights might or might not be available; nor does it represent that
     it has made any independent effort to maintain identify any such rights.
     Information on the same
     IP address when it moves procedures with respect to a new link, and still continue to
     receive packets on the new link.

     Cellular IP and HAWAII have a few things rights in common.  Both are
     compatible with Mobile IP and are intended to provide a higher
     level of handover performance RFC
     documents can be found in local networks than was previously
     available with Mobile IP without such extensions as HMIP BCP 78 and FMIP.
     Both use host routes installed in a number BCP 79.

     Copies of routers within a
     restricted routing domain. Both define specific messaging IPR disclosures made to update
     those  routes  along the  forwarding  path IETF Secretariat and  specify  how  the
     messaging is any
     assurances of licenses to be used to update made available, or the routing tables and forwarding
     tables along result of an
     attempt made to obtain a general license or permission for the path between use
     of such proprietary rights by implementers or users of this
     specification can be obtained from the mobile and a micromobility domain
     boundary router IETF on-line IPR repository
     at which point Mobile IP is http://www.ietf.org/ipr.

     The IETF invites any interested party to used bring to handle
     global mobility in a scalable way. Unlike the FMIP and HMIP
     protocols, however, these protocols do not require the mobile node its attention any
     copyrights, patents or patent applications, or other proprietary
     rights that may cover technology that may be required to obtain a new care of implement
     this standard.  Please address on each access router as it moves;
     but rather, the mobile node maintains information to the same care IETF at ietf-
     ipr@ietf.org.

  10.0   Disclaimer of address
     across the micromobility domain. From outside Validity

     This document and the micromobility
     domain, the care of address is routed using traditional longest
     prefix matching IP routing to the domain's boundary router, so the
     care of address conceptually is within the micromobiity domain
     boundary router's subnet. Within the micromobility domain, the care
     of address is routed to the correct access router using host
     routes.

     Micromobility  protocols  have  some  potential  drawbacks  from  a
     deployment and scalability standpoint. Both protocols involve every
     routing element between the mobile device and the micromobility
     domain boundary router in all packet forwarding decisions specific
     to care of addresses for mobile nodes. Scalability is limited
     because each care of address corresponding to a mobile node
     generates a routing table entry, and perhaps multiple forwarding
     table entries, in every router along the path. Since mobile nodes
     can have multiple global care of addresses in IPv6, this can result
     in a large expansion in router state throughout the micromobility
     routing  domain.  Although  the  extent  of  the  scalability  for
     micromobility protocols is still not clearly understood from a
     research standpoint, it seems certain that they will be less
     scalable than the Mobile IP optimization enhancements, and will
     require more specialized gear in the wired network.

     The following is a gap analysis of the micromobility protocols
     against the goals in Section 2.0:

     Goal  #1  Handover  Performance  Improvement:  The  micromobility
     protocols reduce handover latency by quickly fixing up routes
     between the boundary router and 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  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 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 micromobility-managed network.

     Goal #4 Use of Wireless Resources: The only additional over-the-air
     signaling is involved in propagating host routes from the mobile
     node to the 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 Support for Heterogeneous Wireless Link Technologies:
     HMIPv6  The  micromobility  protocols  support  multiple  wireless
     technologies, so this goal is satisfied.

     Goal #8 Support for Unmodified Mobile Nodes: The mobile node must
     support some way of signaling the access router on link handover,
     but this is required for movement detection anyway. The nature of
     the signaling for the micromobility protocols may require mobile
     node software changes, however.

     Goal #9 Re-use of Existing Protocols Where Sensible: Support for
     IPv4 and 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 does not reuse information contained herein are provided on
     an existing 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 "AS IS" basis and local
     mobility management, since the micromobility protocols only support
     localized mobility management.

  11.5 Summary 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.

  11.0   Copyright Notice
     Copyright (C) The following table summarizes Internet Society (2006).  This document is
     subject to the discussion rights, licenses and restrictions contained 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, BCP
     78, and an "X" indicates that it does not meet except as set forth therein, 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 authors retain all their
     rights.