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

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

            Problem Statement for Network-based IP Local Mobility
                         (draft-ietf-netlmm-nohost-ps-01.txt)
                     (draft-ietf-netlmm-nohost-ps-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.
     http://www.ietf.org/1id-abstracts.html.

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

  Abstract

     In this document, the well-known problem of localized

     Localized mobility management
     for IP link handover is given a fresh look. After a short discussion of well understood concept in the
     problem and
     IETF with a couple number of scenarios, solutions already available. This document
     looks at the principal shortcomings of the existing
     solutions solutions, all
     of which involve the host in mobility management, and makes a case
     for network-based local mobility management.

  Contributors

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

  Table of Contents

     1.0  Introduction.....................................................2  Introduction.............................................2
     2.0  The Local Mobility Problem.......................................4 Problem...............................4
     3.0  Scenarios for Localized Mobility Management......................6 Management..............6
     4.0  Problems with Existing Solutions.................................7 Solutions.........................7
     5.0  Security Considerations..........................................9  IANA Considerations......................................9
     6.0  Author Information...............................................9  Security Considerations..................................9
     7.0  Informative References..........................................10  Acknowledgements........................................10
     8.0  IPR Statements..................................................10  Author Information......................................10
     9.0  Informative References...................................9
     10.0 IPR Statements..........................................11
     11.0 Disclaimer of Validity..........................................11
     10.0 Validity..................................11
     12.0 Copyright Notice................................................11 Notice........................................11

  1.0  Introduction

     Localized mobility management has been the topic of much work in
     the IETF
     for some time, and it may seem as if little remains to be said on the topic. IETF. The experimental protocols developed from previous work,
     namely FMIPv6 [1]
     and HMIPv6[2], HMIPv6 [2], involve host-based solutions that mimic require host
     involvement at the IP layer similar to a greater or
     lesser extent the approach taken in addition to that
     required  by  Mobile  IPv6  [3]  for  global  mobility  management.
     However,  recent  developments  in  the  IETF  and  the  WLAN
     infrastructure market suggest that it may be time to take a fresh
     look at localized mobility management. Firstly, new IETF work on
     global mobility management protocols that are not Mobile IPv6, such
     as HIP [4] and Mobike [5], suggests that future wireless IP nodes
     may support a more diverse set of global mobility protocols. While
     it  is  possible  that  existing  localized  mobility  management
     protocols could be used with HIP and Mobike, it would require
     additional effort to implement and deploy these localized mobility
     management protocols in an non-Mobile IPv6 mobile environment.
     Secondly, the success in the WLAN infrastructure market of WLAN
     switches, which perform localized mobility management without any host stack
     involvement, suggests a possible design paradigm that could be used to
     accommodate other global mobility management options on the mobile node while
     reducing host stack software complexity and expanding the range of
     mobile nodes that could be accommodated.

     This document briefly describes the general local mobility problem
     and a few  scenarios  where  localized  mobility  management  would  be
     desirable. Then, it
     describes the two most serious Then problems with existing protocols: the
     requirement for host stack support, and the complex security interactions
     required between the mobile node or proposed IETF localized
     mobility management protocols are briefly discussed. The network-
     based mobility management architecture and the access network. More a short description of
     how  it  solves  these  problems  is  presented.  A  more  detailed
     requirements
     discussion  of  goals  for  a  network-based,  localized  mobility
     management protocol and gap analysis for existing protocols can be
     found in [6]. Note that IPv6 and wireless links are considered to
     be the primary focal points for a network-based localized mobility
     management, so the language in this document reflects that focus.
     However, the conclusions of this document apply equally to IPv4 and
     wired links where nodes are disconnecting and reconnecting.

  1.1 Terminology
        Mobility terminology in this draft follows that in RFC 3753
        [7], with the addition of some new and revised terminology
        given here:

          IP Link

            A set of routers, mobile nodes, and wireless access points
            that share link broadcast capability or its functional
            equivalent. This definition covers one or multiple access
            points under one or several access routers. In the past,
            such a set has been called a subnet, but this term is not
            strictly correct for IPv6, since multiple subnet prefixes
            can be assigned to an IP link in IPv6.

        Access Network (revised)
          An Access Network consists of following three components: wireless or
          other access points, access routers, access network gateways which form
          the boundary to other networks and may shield other networks from the
          specialized routing protocols (if any) run in the Access Network; and
          (optionally) other internal access network routers which may also be
          needed in some cases to achieve a specialized routing protocol.

        Local Mobility

          Local Mobility (revised)
            Local Mobility is mobility over a restricted area of the network
          topology. an access network. Note
            that, although the area of network topology over which the
            mobile node moves may be restricted, the actual geographic
            area could be quite large, depending on the mapping between
            the network topology and the wireless coverage area.

          Localized Mobility Management

            Localized Mobility Management is a generic term for protocols dealing
          with any IP  mobility  management  confined  within  the  access  network.
          Localized mobility management signaling is not routed outside the
          access  network,  although  a  handover  may  trigger  Global  Mobility
          Management signaling. Localized mobility management protocols exploit
            protocol that maintains the locality IP connectivity and reachability
            of movement by confining movement related changes a mobile node when it moves, and whose signalling is
            confined to the an access network.

          Localized Mobility Management Protocol

            A protocol that supports localized mobility management.

          Global Mobility Management Protocol

            A Global Mobility Management Protocol is a mobility protocol
            used by the mobile node to change the global, end-to-end
            routing of packets when movement causes a topology change
            and thus invalidates a global unicast address on the local
            IP link currently in active use by the mobile node. The
          Global Mobility Protocol may also allow the mobile node to maintain a
          mapping between a permanent address and a temporary address on the
          local network for rendezvous with nodes that want to initiate a
          connection. Typically, this This
            protocol will could be Mobile IPv6 [1] IP [1][13] but it could also be HIP
            [4] or Mobike [5] (Note: although Mobike is not considered a
            mobility management protocol in general, for purposes of
            this document, it will be so considered because it manages
            the address map and routing between a fixed VPN endpoint
            address and a changing local address).

          Global Mobility Anchor Point

            A node in the network where the mobile node maintains a
            permanent  address  and  a  mapping  between  the  permanent
            address and the local temporary address where the mobile
            node happens to be currently located. The Global Mobility
            Anchor Point may be used for purposes of rendezvous and
            possibly traffic forwarding. For Mobile IPv6 [1], IP [1][13], this is
            the home agent. For HIP [4], this may be the rendezvous
            server. For Mobike [5], this is the VPN tunnel gateway in the home
            network. Some global mobility management protocols, such as
            HIP, support end to end global mobility management without a
            Global Mobility Anchor Point, at the risk of dropping a
            connection if both sides are mobile and both move at the
            same time.

          Intra-Link Mobility

            Intra-Link Mobility is mobility between wireless access
            points within an IP Link. Typically, this kind of mobility
            only involves Layer 2 mechanisms, so Intra-Link Mobility is
            often called Layer 2 mobility. No IP link configuration is
            required upon movement since the link does not change, but
            some IP signaling may be required for the mobile node to
            confirm whether or not the change of wireless access point
            also resulted in a change of IP link. If the IP link
            consists of a single access point/router combination,  then
            this  type  of  mobility  is typically absent. See Figure 1.

  2.0  The Local Mobility Problem

        The local mobility problem is restricted to providing IP
        mobility management for mobile nodes within an access network.
        The access network aggregation
     routers gateways function as an access network gateway, although in aggregation routers. In
        this case, there is no specialized routing protocol (e.g. GTP,
        Cellular IP, Hawaii, etc.) and the routers function as form a standard IP
        routed network. network (e.g. OSPF, IS-IS, RIP, etc.). This is
        illustrated in Figure 1, where the aggregation access network gateway
        routers are designated as "AggR". "ANG". Transitions between service
        providers in separate autonomous systems or across broader
        topological "boundaries" within the same service provider are
        excluded.

        Figure 1 depicts the scope of local mobility in comparison to
        global mobility. The Aggregation Routers AggR A1 Access Network Gateways (ANGs) GA1 and B1 GB1
        are gateways to the their access
     network. networks. The Access Routers AR A1 (ARs)
        RA1 and A2 RA2 are in Access Network access network A, B1 RB1 is in
     Access Network access network
        B. Note that it is possible to have additional aggregation
        routers between AggR A1 ANG GA1 and AggR B1 ANG GB1 and the access routers if
        the access network is large. Access Points AP A1 (APs) PA1 through A3
        PA3 are in Access Network access network A, B1 PB1 and B2 PB2 are in Access Network access network
        B. Other Aggregation Routers, Access Routers, ANGs, ARs, and Access Points APs are also possible. possible, and other
        routers can separate the ARs from the ANGs. The figure implies
        a star topology for the access network deployment, and the star
        topology is the primary one of interest since it is quite
        common, but the problems discussed here are equally relevant to
        ring or mesh topologies in which access routers ARs are directly connected
        through some part of the network.

               Access Network A         Access Network B

                  +-------+                  +-------+
                        |AggR A1|
                  |ANG GA1| (other AggRs)  |AggR B1| ANGs)     |ANG GB1| (other AggRs) ANGs)
                  +-------+                  +-------+
                   @    @                       @
                  @      @                      @
                 @        @                     @   (other routers)
                @          @                    @
               @            @                   @
              @              @                  @
                 +-----+       +-----+            +-----+
           +------+       +------+            +------+
           |AR A1| RA1|       |AR A2|(other RA2|(other ARs) |AR B1| RB1|  (other ARs)
                 +-----+       +-----+            +-----+
           +------+       +------+            +------+
              *             *                    *
             * *            *                   * *
            *   *           *                  *   *
           *     *          *                 *     *
          *       *         *                *       *
         *         *        * (other APs)   *         * (other APs)
        /\         /\       /\             /\         /\
       /AP\       /AP\     /AP\           /AP\       /AP\
            / A1
      /PA1 \     / A2     /PA2 \   / A3   /PA3 \       / B1         /PB1 \     / B2     /PB2 \
      ------     ------   ------         ------     ------

         +--+      +--+      +--+         +--+
         |MN|----->|MN|----->|MN|-------->|MN|
         +--+      +--+      +--+         +--+
       Intra-link      Local        Global
       (Layer 2)      Mobility     Mobility
        Mobility

          Figure 1. Scope of Local and Global Mobility Management

     As shown in the figure, a global mobility protocol is may be necessary
     when a mobile node (MN) moves between two access networks. Exactly
     what the scope of the access networks is depends on deployment
     considerations.  Mobility  between  two access points  APs  under  the  same access router  AR
     constitutes Intra-
     link mobility, and intra-link, or Layer 2, mobility, and is typically
     handled by Layer 2 mobility protocols (if there is only one access point/cell AP/cell
     per access router, AR, then intra-link mobility may be lacking). Between these two
     lies local mobility. Local mobility occurs when a mobile node moves
     between two access points APs connected to two different access routers. ARs.

     Global  mobility  protocols  allow  a  mobile  node  to  maintain
     reachability when
     a change between access routers occurs, the MN's globally routable IP address changes. It
     does this by updating the address mapping between the permanent
     address and temporary local address at the global mobility anchor
     point, or even end to end by changing the temporary local address
     directly at the node with which the mobile node is corresponding. A
     global mobility management protocol can therefore be used between access
     routers
     ARs for handling local mobility. However, there are three well-known well-
     known problems involved in using a global mobility protocols protocol for
     every transition movement between access routers. ARs. Briefly, they are:

     1) Update latency. If the global mobility anchor point and/or
         correspondent node (for route optimized traffic) is at some
         distance from the mobile node's access network, the global
         mobility update may require a considerable amount of time.
         During this time, during which time packets continue to be routed to the old
         temporary local address and are essentially dropped.
     2) Signaling overhead. The amount of signaling required when a
         mobile node moves from one IP link to another can be quite
         extensive, including all the signaling required to configure an
         IP address on the new link and global mobility protocol
         signaling back into the network for changing the permanent to
         temporary local address mapping. The signaling volume may
         negatively  impact  wireless  bandwidth  usage  and  real  time
         service performance.
      3) Location privacy. The change in temporary local address as the
         mobile  node  moves  exposes  the  mobile  node's  topological
         location to correspondents and potentially to eavesdroppers. An
         attacker that can assemble a mapping between subnet prefixes in
         the mobile node's access network and geographical locations can
         determine exactly where the mobile node is located. This can
         expose the mobile node's user to threats on their location
         privacy. A more detailed discussion of location privacy for
         Mobile IPv6 can be found in [12].

     These problems suggest that a protocol to localize the management
     of topologically small movements is preferable to using a global
     mobility management protocol on each IP link move. In addition to
     these problems, localized mobility management can provide a measure
     of  local  control,  so  mobility  management  can  be  tuned  for
     specialized local conditions. Note also that if localized mobility
     management is provided, it is not strictly required for a mobile
     node  to  support  a  global  mobility  management  protocol  since
     movement  within  a  restricted  IP  access  network  can  still
     be accommodated. Without such support, however, a mobile node
     experiences a disruption in its traffic when it moves beyond the
     border of the localized mobility management domain.

  3.0  Scenarios for Localized Mobility Management

     There are a variety of scenarios in which localized mobility
     management is
     attractive. useful.

  3.1 Large Campus with Diverse Physical Interconnectivity

     One  scenario  where  localized  mobility  management  would  be
     attractive is for a large campus wireless LAN deployment in which deployment.  Having a
     single broadcast domain for all WLAN access points doesn't scale
     very well.  Also, sometimes parts of the campus are connected cannot be covered
     by one VLAN for other reasons (e.g., some links that are other than 802.3 or in which it is not possible to cover
     the campus by one VLAN.
     802.3).

     In this case, the campus is divided into separate IP links each
     served by one or more access routers. This kind of deployment is
     served today by wireless LAN switches that co-ordinate IP mobility
     between them, effectively providing localized mobility management
     at the link layer. Since the protocols are proprietary and not
     interoperable, any deployments that require IP mobility necessarily
     require switches from the same vendor.

  3.2 Advanced Cellular Network

     Next generation cellular protocols such as 802.16e [8] and Super
     3G/3.9G [9] have the potential to run IP deeper into the access
     network than the current 3G cellular protocols, similar to today's
     WLAN networks. This means that the access network can become a
     routed IP network. Interoperable localized mobility management can
     unify local mobility across a diverse set of wireless protocols all
     served by IP, including advanced cellular, WLAN, and personal area
     wireless  technologies  such  as UWB  UltraWide  Band  (UWB)  [10]  and Bluetooth.
     Bluetooth [11]. Localized mobility management at the IP layer does
     not  replace  Layer  2  mobility  (where  available)  but  rather
     complements it. A standardized, interoperable localized mobility
     management protocol for IP can remove the dependence on IP layer
     localized mobility protocols that are specialized to specific link
     technologies or proprietary, which is the situation with today's 3G
     protocols. The expected benefit is a reduction in maintenance cost
     and deployment complexity. See [6] for a more detailed discussion
     of the
     requirements goals for a network-based localized mobility management. management
     protocol.

  3.3 Picocellular Network with Small But Node-Dense IP Links

     Future radio link protocols at very high frequencies may be
     constrained to very short, line of sight operation. Even some
     existing protocols, such as UWB and Bluetooth, are designed for low
     transmit  power,  short  range  operation.  For  such  protocols,
     extremely small picocells become more practical. Although picocells
     do not necessarily imply "pico IP links", wireless sensors and
     other advanced applications may end up making such picocellular
     type  networks  node-dense,  requiring  subnets  that  cover  small
     geographical areas, such as a single room. The ability to aggregate
     many subnets under a localized mobility management scheme can help
     reduce the amount of IP signaling required on IP link movement.

  4.0  Problems with Existing Solutions

     Existing solutions for localized mobility management fall into
     three classes:

     1) Interoperable IP level protocols that require changes to the
        mobile node's IP stack and handle localized mobility management
        as a service provided to the mobile node by the access network,
     2) Link specific or proprietary protocols that handle localized
        mobility for any mobile node but only for a specific type of
        link layer, namely 802.11 running on an 802.3 wired network
        backhaul.
     3) Use of a standard IGP such as OSPF or IS-IS to distribute host routes, and
        updating the host routes when the mobile node moves.

     The dedicated localized mobility management IETF protocols for
     Solution 1 are not yet widely deployed, but work continues on
     standardization.  Some  Mobile  IPv4  deployments  use  localized
     mobility management. For Solution 1, the following are specific
     problems:

     1) The host stack software requirement limits broad usage even if
        the modifications are small. The success of WLAN switches
        indicates that network operators and users prefer no host stack
        software modifications. This preference is likely to be independent of the
        lack of widespread Mobile IPv4 deployment, since it is much
        easier to deploy and use the network.
     2) Future mobile nodes may choose other global mobility management
        protocols, such as HIP or Mobike. The existing localized
        mobility management solutions all depend on Mobile IP or
        derivatives.
     3) Existing localized mobility management solutions do not support
        both IPv4 and IPv6.
     4) Security for the existing Existing host-based localized mobility management solutions
        requires complex
        require setting up additional security associations with network
        elements for no
        improvement in security over what is available if localized mobility
        management is not used. In addition to the additional signaling required
        to set up these security associations, provisioning a mobile node with
        credentials for roaming to all the access networks where the mobile node
        might end up may prove difficult, acting as a barrier domain.

     Market acceptance of WLAN switches has been very large, so Solution
     2 is widely deployed and continuing to deployment. grow. Solution 2 has the
     following problems:

     1) Existing solutions only support WLAN networks with Ethernet
        backhaul and therefore are not available for advanced cellular
        networks or picocellular protocols, or other types of wired
        backhaul.
     2) Each WLAN switch vendor has its own proprietary protocol that
        does not interoperate with other vendor's equipment.
     3) Because the solutions are based on layer 2 routing, they may not
        scale up to a metropolitan area, or local province.

     Solution 3 has the following problems:

     1) Each router in the

     Having an interoperable, standardized localized mobility management domain
     protocol   that is required to
        maintain a host route table and scalable to search the topologically large networks, but
     requires  no  host route table for
        routing each packet, limiting the memory and processing power
        scalability.
     2) After handover, until host routes propagate back along the current path
        of traffic to the localized mobility management domain border, traffic
        packets for the mobile node are sent to the old router, causing the
        packets to drop. Since IGPs typically propagate routing updates through
        flooding, the delay in host route propagation also limits the topological
        span of the localized mobility management domain.
     3) Rapid movement by the mobile node faster than the rate at which flooding
        can propagate host routes could lead to a cascading series of host route
        messages that never stabilize.

     Having an interoperable, standardized localized mobility management protocol
     that is scalable to topologically large networks, but requires no host stack
     involvement  stack  involvement  for  localized  mobility
     management is a highly desirable solution. Mobility routing anchor
     points within the backbone network maintain a collection of routes
     for individual mobile nodes. The routes point to the access routers ARs on which
     mobile nodes currently are located. Packets for the mobile node are
     routed to and from the mobile node through the mobility anchor
     point. When a mobile node moves from one access router AR to another, the access routers ARs
     send a route update to the mobility anchor point. While some mobile
     node involvement is necessary and expected for generic mobility
     functions such as movement detection and to inform the
     access router AR about
     mobile node movement, no specific mobile node to network protocol
     will be required for localized mobility management itself.

     The advantages that this solution has over the Solutions 1 through 3 and 2
     above are as follows:

     1) Compared with Solution 1, a network-based solution requires no
        localized mobility management support on the mobile node and is
        independent of global mobility management protocol, so it can
        be used with any or none of the existing global mobility
        management protocols. The result is a more modular mobility
        management architecture that better accommodates changing
        technology and market requirements.
     2) Compared with Solution 2, an IP level network-based localized
        mobility management solution works for link protocols other
        than Ethernet, and for wide area networks.
     3) Compared with Solution 3, the framework described above for network-based
        localized mobility management only requires the involvement of the access
        routers and the mobility anchor. All other routers within the localized
        mobility management domain do not need to handle host routes, making the
        architecture more scalable. In addition, because updating the routes
        requires communication between only two routers, propagation of routes on
        handover is likely to be much faster.

  5.0  IANA Considerations

     There are no IANA considerations in this document.

  6.0  Security Considerations

     Localized mobility management has certain security considerations,
     one of which - need for access network to mobile node security -
     was touched on in this document. Existing Host-based localized mobility
     management solutions increase protocols have all the
     need for mobile node security problems involved with
     providing a service to access a host. Network-based localized mobility
     management requires security among network signaling elements equivalent to
     what is needed for routing information security, and provisioning of the
     mobile node with credentials without increasing the security beyond
     between the host and network equivalent to what is
     available if needed for
     network access, but no localized mobility management solution is used. more. A more complete discussion of the
     security requirements goals for network-based localized mobility management can
     be found in [6].

   6.0 Author Information

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

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

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

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

        Gerardo Giaretta
        Telecom Italia Lab
        via G. Reiss Romoli, 274
        10148 Torino
        Italy
        Phone: +39 011 2286904
        Email: gerardo.giaretta@tilab.com

        Marco Liebsch
        NEC Network Laboratories
        Kurfuersten-Anlage 36
        69115 Heidelberg
        Germany
        Phone: +49 6221-90511-46
        Email: marco.liebsch@ccrle.nec.de

  7.0  References

  7.1 Informative References

      [1] Koodli, R., editor, "Fast Handovers for Mobile IPv6," RFC
          4068, July, 2005.
      [2] Soliman,  H.,  editor,  "Hierarchical  Mobile  IPv6  Mobility
          Management," RFC 4140, August, 2005.
      [3] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in
          IPv6," RFC 3775.
      [4] Moskowitz, R., and Nikander, P., Jokela, P., and Henderson, T., "Host Identity Protocol", Internet Draft, work in progress. Protocol (HIP)
          Architecture", RFC 4423, May, 2006.
      [5] Kivinen, T., Eronen, P., editor, "IKEv2 Mobility and Tschopfening, H., "Design of the MOBIKE Protocol", Multihoming Protocol
          (MOBIKE)", Internet Draft, work in progress.
      [6] Kempf, J., Leung, K., Roberts, P., Giaretta, G., Liebsch, M., and
          Nishita, K.., "Requirements and Gap Analysis editor, "Goals for Network-based Localized Mobility
          Management", Internet Draft, work in progress.
      [7] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC
          3753, June, 2004.
      [8] IEEE, "Air Interface for Mobile Broadband Wireless Access
          Systems", 802.16e, 2005.

      [9] 3GPP, "3GPP System Architecture Evolution: Report on Technical
          Options     and     Conclusions",     TR     23.882,     2005, http://www.3gpp.org/ftp/Specs/html-
          info/23882.htm.
          http://www.3gpp.org/ftp/Specs/html-info/23882.htm.
     [10] http://www.ieee802.org/15/pub/TG3a.htm
     [11] Bluetooth  SIG,  "Specification  of  the  Bluetooth  System",
          November, 2004, available at http://www.bluetooth.com.
     [12] Koodli, R., "IP Address Location Privacy and Mobile IPv6:
          Problem Statement", Internet Draft, work in progress.
     [13] Perkins, C., editor, " IP Mobility Support for IPv4", RFC
          3220, August, 2002.

  8.0  Acknowledgements

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

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

  10.0     IPR Statements

     The IETF takes no position regarding the validity or scope of any
     Intellectual Property Rights or other rights that might be claimed
     to pertain to the implementation or use of the technology described
     in this document or the extent to which any license under such
     rights might or might not be available; nor does it represent that
     it has made any independent effort to identify any such rights.
     Information on the procedures with respect to rights in RFC
     documents can be found in BCP 78 and BCP 79.

     Copies of IPR disclosures made to the IETF Secretariat and any
     assurances of licenses to be made available, or the result of an
     attempt made to obtain a general license or permission for the use
     of such proprietary rights by implementers or users of this
     specification can be obtained from the IETF on-line IPR repository
     at http://www.ietf.org/ipr.

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

   9.0 ietf-
     ipr@ietf.org.

  11.0     Disclaimer of Validity

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

   10.0

  12.0    Copyright Notice

     Copyright (C) The Internet Society (2006).  This document is
     subject to the rights, licenses and restrictions contained in BCP
     78, and except as set forth therein, the authors retain all their
     rights.