Network Working Group                                         F. Templin
Internet-Draft                                                S. Russert
Expires: December 4, 2006                                    I. Chakeres
                                                                   S. Yi
                                                    Boeing Phantom Works
                                                            June 2, 2006


            Network Localized Mobility Management using DHCP
               draft-templin-autoconf-netlmm-dhcp-01.txt

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on December 4, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Mobile nodes that require global Internet access must have a way to
   automatically configure globally routable and unique IP addresses
   that remain stable across localized mobility events.  This document
   specifies mechanisms for address autoconfiguration (AUTOCONF) and
   network localized mobility management (NETLMM) based on the Dynamic
   Host Configuration Protocol (DHCP).  Solutions for both IPv4 and IPv6



Templin, et al.         Expires December 4, 2006                [Page 1]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


   are given.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Model of Operation . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Functional Specification . . . . . . . . . . . . . . . . . . .  6
     4.1.  Mobile Node (MN) Operation . . . . . . . . . . . . . . . .  6
     4.2.  Access Router (AR) Operation . . . . . . . . . . . . . . .  7
     4.3.  Mobility Anchor Point (MAP) Operation  . . . . . . . . . .  8
     4.4.  Functions Specified Only in this Document  . . . . . . . .  8
   5.  Additional Considerations  . . . . . . . . . . . . . . . . . .  9
     5.1.  IPv6 Advantages  . . . . . . . . . . . . . . . . . . . . .  9
     5.2.  ARP/Neighbor Cache Management  . . . . . . . . . . . . . . 10
     5.3.  Global Mobility Management . . . . . . . . . . . . . . . . 10
     5.4.  Duplicate Address Detection (DAD)  . . . . . . . . . . . . 10
     5.5.  Multi-link Subnet Considerations . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Nested LMMD Model . . . . . . . . . . . . . . . . . . 14
   Appendix B.  Control Message Loss Implications for NETLMM  . . . . 16
     B.1.  Implications for Network-Based Signaling . . . . . . . . . 16
     B.2.  Implications for Host-based Signaling  . . . . . . . . . . 17
     B.3.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Appendix C.  Changes since -00 . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20

















Templin, et al.         Expires December 4, 2006                [Page 2]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


1.  Introduction

   Access networks (e.g., campus LANs, cellular wireless, WiFi, MANETs,
   etc.) that connect nodes to the Internet may be prone to disturbances
   such as congestion, signal intermittence, node movements, partitions/
   merges, equipment failure, etc.  From a node's point of view, these
   disturbances appear as mobility events that may cause its default
   access router connection to fail or degrade, i.e., the node appears
   to be mobile with respect to the access network.  Such mobile nodes
   therefore require a means to quickly select another access router as
   network conditions change.  Moreover, a mobile node requires a means
   to procure unique and globally routable IP addresses that remain
   stable even if its default access router changes.  This can be
   accomplished when access routers connect mobile nodes to the Internet
   via stable backhaul networks with mobility anchor points that
   delegate IP addresses and maintain mobile node to access router
   mappings.

   Mobile nodes, access routers and mobility anchor points can use the
   Bootstrap Protocol (BOOTP) [RFC0951] and Dynamic Host Configuration
   Protocol (DHCPv4) [RFC2131] for IPv4, or DHCPv6 [RFC3315] for IPv6,
   as well as the associated mechanisms specified in this document to
   provision globally routable and unique IP addresses that remain
   stable within a localized mobility management domain.

   Using these mechanisms, the mobile node selects a specific primary
   access router among possibly many candidates thereby minimizing
   control message overhead and eliminating ambiguity.  In particular,
   the mobile node is uniquely qualified to select the best primary
   access router among possibly many candidates and is also uniquely
   qualified to determine when it should change to a new primary access
   router.  Additionally, the mobile node receives positive/negative
   confirmation that the correct IP address delegations and route/tunnel
   state have been registered within the localized mobility management
   domain such that communication failures due to black holes, address
   duplications, etc., will not occur.

   The model of operation described in this document corresponds to that
   proposed for the IETF Network Localized Mobility Management (NETLMM)
   working group [I-D.ietf-netlmm-nohost-ps] [I-D.ietf-netlmm-nohost-
   req].  Solutions for both IPv4 [RFC0791] and IPv6 [RFC2460] are
   given.


2.  Terminology

   The terminology in the normative references apply; the following
   terms are defined within the scope of this document:



Templin, et al.         Expires December 4, 2006                [Page 3]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


   link
      the same as defined in ([RFC2461], Section 2.1).

   access network
      a link that connects Mobile Nodes and Access Routers and may be
      subject to congestion, signal intermittence, node movements,
      network partitions/merges, equipment failure, etc.

   backhaul network
      a network that connects Access Routers and Mobility Anchor
      Point(s) and also connects the Localized Mobility Management
      Domain to the global Internet.

   Mobile Node (MN)
      a node on an access network that also acts as a DHCP client.

   Access Router (AR)
      a router that connects access networks to a backhaul network and
      also acts as a DHCP/BOOTP relay agent.

   Mobility Anchor Point (MAP)
      a backhaul network router (and its associated DHCP server) that
      aggregates IP prefixes in a Localized Mobility Management Domain.

   Localized Mobility Management Domain (LMMD)
      a set of MAPs (and their associated ARs and MNs) that provision
      addresses from the same IP subnet prefix(es).


3.  Model of Operation

   The Dynamic Host Configuration Protocol (DHCP) has seen significant
   operational experience in fielded deployments.  Using the DHCP-based
   mechanisms specified in Section 4, MNs on access networks can send
   DHCP requests via ARs to MAPs in the backhaul network to configure
   global IP addresses and establish MN->AR routes/tunnels in MAP IP
   forwarding tables.  Moreover, these mechanisms allow MNs to retain
   their global IP addresses even if they change ARs within the LMMD.
   The following figure provides a reference diagram for the DHCP-based
   network localized mobility management solution space:











Templin, et al.         Expires December 4, 2006                [Page 4]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


         /-------------------------\
        /         Internet          \
        \                           /
         \-------+---------+-------/
                 |         |
         /-------+---------+-------\  ----
        /                           \    ^
       /         +-----+             \   |
       |         | MAP |-+           |   |
       |         +-----+ |-+         |   |
       |           +-----+ |         |   |
       |             +-----+         |   |
       |       Backhaul Network      |
       |    +-----+       +-----+    |   L
       |- - | AR1 | ..... | ARn | - -|   M
       |    +-----+       +-----+    |   M
       |      / \  Access   / \      |   D
       |     /   \ Network /   \     |
       |    /     \       /     \    |   |
       |    +----+                   |   |
       |    | MN | ------->          |   |
       \    +----+ AR change         /   |
        \                           /    v
         \-------------------------/  ----

   Figure 1: Reference Network Diagram

   Using the mechanisms specified in Section 4, a MN discovers ARs via
   standard IP router discovery and selects a primary AR.  The MN then
   send a unicast DHCP request to the primary AR which relays the
   request to a MAP.  The MAP delegates an IP address for the MN and
   also creates a route/tunnel to the MN via the primary AR.  The MAP
   then sends a DHCP reply to the MN via the primary AR, and the AR
   relays the reply to the MN.  The MN now knows that it has received a
   unique IP address delegation and knows that the MAP has established
   the correct route and address delegation cache state.  Moreover, the
   MN can change to a new primary AR as network conditions require and
   can immediately inform the MAP of the change.  The following figure
   presents a message exchange diagram that outlines this model of
   operation:











Templin, et al.         Expires December 4, 2006                [Page 5]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


   MN                      AR                      MAP
   |                        |                       |
   |  Router Advertisement  |                       |
   |<-----------------------|                       |
   |      DHCP Request      |                       |
   |----------------------->|  Relayed DHCP Request |
   |                        |---------------------->| create route
   |                        |      DHCP Reply       | to MN via AR
   |   Relayed DHCP Reply   |<----------------------|
   |<-----------------------|                       |
   |                        |                       |
   ...
   |                        |                       |
   |                        |                       | data packet
   |                        |    Tunneled Packet    | for MN
   |    Forwarded Packet    |<======================|
   |<-----------------------|                       |

   Figure 2: Message Exchange Diagram


4.  Functional Specification

   The following subsections specify operation of MNs, ARs and MAPs in
   support of address configuration and localized mobility management.
   Items marked with (*) denote functions that are specified only in
   this document (see: Section 4.4):

4.1.  Mobile Node (MN) Operation

   MNs discover ARs via standard ICMP Router Solicitation (RS) and
   Router Advertisement (RA) messages per [RFC1256] (IPv4) or [RFC2461]
   (IPv6).  Mechanisms for detection of network attachment (DNA) for
   IPv4 [RFC4436] or IPv6 [I-D.ietf-dna-protocol] can also be used to
   more quickly detect and respond to AR changes.

   When a MN first powers on, activates a network interface or when it
   receives an indication of link change or movement to a new LMMD, it
   uses standard mechanisms to receive RAs from neighboring ARs and (if
   none are heard) send a small number of RSs to elicit immediate RAs.
   After the MN receives RAs from one or more AR, it selects one or more
   ARs as default routers and selects one AR as its primary default
   router.

   After the MN discovers ARs, it requests IP address delegations and/or
   IP prefix delegations (IPv6-only [RFC3633]) by sending DHCPDISCOVER
   (IPv4) or Solicit (IPv6) messages to the IP unicast address of the
   primary AR (*).  To reduce control message overhead, the MN can use



Templin, et al.         Expires December 4, 2006                [Page 6]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


   the Rapid Commit option for DHCPv4 [RFC4039] or DHCPv6 [RFC3315] to
   enable address assignment with the exchange of just two messages
   instead of four.

   After address/prefix configuration, the MN issues DHCPREQUEST (IPv4),
   Confirm or Renew (IPv6) messages to the unicast address of the
   primary AR (*) to refresh its address lease lifetimes as long as it
   requires continued global IP addressing services.

   If the MN's primary AR fails (or appears to be failing), the MN
   selects a new primary AR and sends an immediate DHCPREQUEST (IPv4),
   Confirm or Renew (IPv6) message to the unicast address of the new
   primary AR (*) so that the MAP(s) can quickly update their IP
   forwarding tables (see: Section 4.3).

   MNs can send IP packets to off-link destinations using any of the ARs
   in their default router list as the next hop.

4.2.  Access Router (AR) Operation

   ARs send periodic and solicited RAs on their attached access networks
   per [RFC1256] (IPv4) or [RFC2461] (IPv6).  ARs should send periodic
   RAs at small intervals to provide beacons for MNs to quickly discover
   nearby ARs and detect AR failures.  (The beacon interval should be
   determined based on link characteristics of the particular access
   network, and possibly also the mechanisms for detection of network
   attachment (DNA).)  In the IPv6 case, the RAs sent by ARs should also
   include prefix options with the 'L' bit set to 0 for advertisement of
   IPv6 prefixes owned by the MAP(s).

   ARs configure a BOOTP (IPv4) or DHCPv6 (IPv6) relay agent.  When an
   AR receives a MN's DHCPDISCOVER, DHCPREQUEST (IPv4), Solicit, Confirm
   or Renew (IPv6) message, it relays the request to one or more MAPs in
   the backhaul network.  (When the MAP and AR are co-located, the
   request is handled by the local DHCP server.)  When the AR relays the
   request, it writes the IP address of its access network interface in
   the BOOTP 'giaddr' field (IPv4) or DHCPv6 'peer-address' field
   (IPv6).  This means that an AR's access network interfaces must be
   provisioned with IP addresses that are injected as host routes into
   the backhaul network's intra-domain routing protocol.  ARs must also
   be provisioned with the IP address(es) of the MAP(s).

   When an AR relays a MAP's DHCPACK (IPv4) or Reply (IPv6) to a MN, it
   examines the message for delegated IP addresses/prefixes.  If
   delegated IP addresses/prefixes are included, the MN creates routes
   in its IP forwarding table that associate the delegated IP addresses/
   prefixes with the MN's address in the BOOTP 'chaddr' field (for
   DHCPv4) or the 'peer-address' (for DHCPv6) (*).



Templin, et al.         Expires December 4, 2006                [Page 7]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


   ARs can optionally be configured to participate as a middle party in
   MN-to-MAP DHCP exchanges, e.g., so that appropriate policy decisions
   can be implemented.

4.3.  Mobility Anchor Point (MAP) Operation

   The MAP(s) in the backhaul network act as DHCP servers and IP routers
   for MNs in access networks.  All MAPs within the same LMMD delegate
   addresses from a common set of IP subnet prefixes and inject the
   prefixes into the backhaul network's intra-domain routing protocol.
   When multiple MAPs are present within the same LMMD, they synchronize
   state to maintain a consistent view of address delegations and IP
   routes.

   When a MAP receives a DHCPDISCOVER (IPv4) or Solicit (IPv6) message,
   it delegates an IP address for the MN.  (Optionally in IPv6, the MAP
   can delegate IP prefixes for the MN to be further sub-delegated to
   its associated hosts.)  After the MAP delegates an IP address/prefix,
   it notes the unicast address of the AR from either the BOOTP 'giaddr'
   field (IPv4) or the DHCPv6 'peer-address' field (IPv6) then
   configures a route in its IP forwarding table and (if necessary) a
   tunnel interface used for directing packets destined for the MN to
   the correct AR (*).  After the route is configured, the MAP returns a
   DHCPOFFER (IPv4) or Advertise (IPv6) to the unicast address of the
   AR.  If Rapid Commit is in use, the MAP instead returns an immediate
   DHCPACK (IPv4) or Reply (IPv6).

   Following DHCP address delegation and IP route/tunnel configuration,
   when a packet destined for a MN arrives at a MAP, the MAP either: a)
   encapsulates the packet with the MN's primary AR as the destination
   address in the outer header (i.e., tunnels the packet to the AR), or
   b) inserts an IPv4 source routing header (likewise IPv6 routing
   header) (*) to ensure that the packet will be forwarded through the
   MN's primary AR.

   The MAP retains address/prefix delegations and route/tunnel
   configurations as long as the MN continues to use the same primary AR
   and continues to refresh the lease lifetimes.  When the MN signals a
   change to a new primary AR, the MAP updates its cached route/tunnel
   configurations to point to the new AR (*).  When lease lifetimes
   expire, the MAP deletes the cached address/prefix delegations and
   their corresponding route/tunnel configurations (*).

4.4.  Functions Specified Only in this Document

   MNs must tightly couple their DHCP operations with the IP router
   discovery process.  In particular, MNs must send their DHCP requests
   to the unicast address(es) of ARs discovered in RAs.  Also, in order



Templin, et al.         Expires December 4, 2006                [Page 8]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


   to support mobility, MNs must send immediate DHCP requests whenever
   they change to a new primary AR as a signal for MAPs to update their
   route/tunnel entries.

   ARs must examine DHCPACK (IPv4) or Reply (IPv6) messages and create
   routes in their IP forwarding tables that associate delegated IP
   addresses/prefixes with the MN's address.

   MAPs must tightly couple the delegation of IP addresses/prefixes with
   the establishment of routes/tunnels in their IP forwarding tables.
   Following address/prefix delegation, MAPs must also closely monitor a
   MN's DHCP requests to detect changes in ARs and make corresponding
   changes to existing IP forwarding table and tunnel entries if
   necessary.  MAPs may optionally arrange for the insertion of routing
   headers in the packets they forward instead of tunneling (e.g., to
   reduce tunneling header overhead) but should note that this may
   result in excessive TTL/Hop Limit decrementation.  Finally MAPs must
   delete existing IP forwarding table and tunnel entries when their
   corresponding IP address delegations expire.


5.  Additional Considerations

5.1.  IPv6 Advantages

   IPv6 RAs can carry prefix options for IPv6 stateless address
   autoconfiguration [RFC2462] whereas IPv4 RAs only carry the
   address(es) of routers.  In the IPv6 case, all ARs in the LMMD can
   advertise the same IPv6 prefixes on their attached access networks
   with the 'L' bit set to 0 so that MNs can use the prefixes for
   address auto-configuration but not on-link determination.

   IPv6 MNs can auto-configure addresses from advertised prefixes and
   propose them to the MAP's DHCPv6 server instead of allowing the
   DHCPv6 server to select addresses.  (The DHCPv6 server will return
   failure codes for proposed addresses that are duplicates).  This
   allows IPv6 MNs a degree of control (not available in IPv4) to
   configure their own addresses with interface identifiers created
   using mechanisms such as CGAs [RFC3972] or privacy addresses
   [I-D.ietf-ipngwg-temp-addresses-v2].

   MNs must quickly detect movement between different LMMDs.  In IPv6,
   the MN will see a different set of IP prefixes in RAs when it moves
   from one LMMD to another.  In IPv4, the MN can only detect movement
   to a different LMMD based on DHCPREQUEST failures when it tries to
   connect to a new AR (since DHCPv4 servers in different LMMDs will
   manage different sets of IP addresses).




Templin, et al.         Expires December 4, 2006                [Page 9]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


   DHCPv6 provides a prefix delegation mechanism [RFC3633] that can be
   used for assigning IP prefixes for subnets within access networks;
   DHCPv4 does not provide a similar mechanism.

   MNs can use local addressing for intra-access network communications
   that do not require backhaul network transit.  IPv6 provides a unique
   local addressing (ULA) mechanism [RFC4193] which assures a high
   probability of uniqueness even when access networks partition and
   merge.  The local addressing mechanisms provided by IPv4 [RFC1918]
   [RFC3927] cannot assure high probability of uniqueness.

5.2.  ARP/Neighbor Cache Management

   In highly dynamic environments, communication failures can result due
   to stale IPv4 ARP [RFC0826] (similarly IPv6 Neighbor Discovery
   [RFC2461]) cache entries.  MNs and ARs must therefore carefully
   manage their IPv4 ARP (similarly IPv6 neighbor) caches to quickly
   flush stale entries.  Note that this is also true for the NETLMM
   approach.

5.3.  Global Mobility Management

   When a MN leaves a LMMD and enters a new LMMD, its global IP
   addresses are no longer topologically correct and global mobility
   management mechanisms are needed.  Currently available global
   mobility mechanisms for IPv6 include MIPv6, HIP and MobIKE, while
   MIPv4 is available for IPv4.  A problem statement for global IP
   mobility management is given in [I-D.njedjou-netlmm-globalmm-ps].

5.4.  Duplicate Address Detection (DAD)

   DAD procedures in LMMDs are the same as for any link using the
   mechanisms of ARP (IPv4) or IPv6 stateless address autoconfiguration
   [RFC2462] (IPv6).

   Additionally, a MAP's DHCP server will only delegate IP addresses/
   prefixes that are unique within the LMMD and will return error codes
   for address collisions.

5.5.  Multi-link Subnet Considerations

   The model of operation proposed by this document (and by NETLMM)
   constitutes a multi-link subnet in the MAP->MN direction but not in
   the MN->Internet direction.  In particular, packets destined for a MN
   via the MAP have their IPv4 TTL (likewise IPv6 Hop Limit) decremented
   once as they are forwarded by the MAP, possibly additional times as
   they are forwarded along the MAP->AR path, and once as they are
   forwarded by the AR.



Templin, et al.         Expires December 4, 2006               [Page 10]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


   Future versions of this document will investigate a neighbor
   discovery proxy approach [RFC4389] to avoid multi-link subnet issues
   (see: [I-D.thaler-intarea-multilink-subnet-issues]).


6.  IANA Considerations

   ARs are defined as comprising both an IP router and BOOTP/DHCPv6
   relay agent function, but backward compatibility for legacy routers
   on access networks may be desired (TBD).

   If backward compatibility for legacy IPv4 routers is needed, the
   "icmp-parameters" registry could define a new code for the ICMPv4 RA
   type (type 9) called "BOOTP Relay Agent Present" to be included in
   the ICMPv4 RAs sent by ARs but not those sent by legacy routers.

   If backward compatibility for legacy IPv6 routers is needed, a new
   bit (the 'D' bit) could be defined from the ICMPv6 RA "Reserved"
   field.  This bit would be set to 1 in ICMPv6 RAs sent by ARs with
   DHCPv6 relay agents but not those sent by legacy routers.


7.  Security Considerations

   Threats relating to NETLMM [I-D.ietf-netlmm-threats] and the security
   considerations for DHCP [RFC2131] [RFC3315] apply to this document.

   The base DHCPv4 specification [RFC2131] does not specify securing
   mechanisms, but DHCPv4 message authentication is specified in
   [RFC3118].  ([RFC3315], Section 21) specifies mechanisms for DHCPv6
   message authentication.

   The ARP mechanism used by IPv4 is insecure, while IPv6 Neighbor
   Discovery can use the securing mechanisms of SEND [RFC3971].


8.  Related Work

   The Mitre MobileMesh approach suggests a serverless backhaul network
   with a fully-connected mesh of tunnels between ARs.  Telcordia has
   proposed DHCP-related solutions for the CECOM MOSAIC program.  The
   Cisco LAM mechanism operates by injecting host routes for MNs into
   the backhaul network's intra-domain routing protocol.  Hierarchical
   Mobile IPv6 (HMIPv6) has each AR advertise a different IP subnet
   prefix on the access network.  The IETF NETLMM approach advocates
   intelligent ARs for handling mobility and simple MNs that do not get
   involved with mobility-related signaling.  Various proposals targeted
   for the IETF AUTOCONF working group have suggested stateless



Templin, et al.         Expires December 4, 2006               [Page 11]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


   mechanisms for address configuration.


9.  Acknowledgements

   The Naval Research Lab (NRL) Information Technology Division uses
   DHCP in their MANET research testbeds.  Alexandru Petrescu mentioned
   DHCP in NETLMM mailing list discussions.

   The following individuals (in chronological order) have provided
   valuable input: Marcelo Albuquerque, Thomas Henderson, Wojtek
   Furmanski, Long Ho.


10.  References

10.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
              converting network protocol addresses to 48.bit Ethernet
              address for transmission on Ethernet hardware", STD 37,
              RFC 826, November 1982.

   [RFC0951]  Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951,
              September 1985.

   [RFC1256]  Deering, S., "ICMP Router Discovery Messages", RFC 1256,
              September 1991.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.



Templin, et al.         Expires December 4, 2006               [Page 12]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


10.2.  Informative References

   [E2E]      Salzer, J., Reed, D., and D. Clark, "End-to-end Arguments
              in System Design", ACM ToCS , November 1984.

   [I-D.ietf-dna-protocol]
              Kempf, J., "Detecting Network Attachment in IPv6 Networks
              (DNAv6)", draft-ietf-dna-protocol-00 (work in progress),
              February 2006.

   [I-D.ietf-ipngwg-temp-addresses-v2]
              Narten, T., "Privacy Extensions for Stateless Address
              Autoconfiguration in IPv6",
              draft-ietf-ipngwg-temp-addresses-v2-00 (work in progress),
              September 2002.

   [I-D.ietf-netlmm-mn-ar-if]
              Laganier, J. and S. Narayanan, "Network-based Localized
              Mobility Management Interface between Mobile Node  and
              Access Router", draft-ietf-netlmm-mn-ar-if-00 (work in
              progress), April 2006.

   [I-D.ietf-netlmm-nohost-ps]
              Kempf, J., "Problem Statement for IP Local Mobility",
              draft-ietf-netlmm-nohost-ps-01 (work in progress),
              April 2006.

   [I-D.ietf-netlmm-nohost-req]
              Kempf, J., "Goals for Network-based Localized Mobility
              Management (NETLMM)", draft-ietf-netlmm-nohost-req-01
              (work in progress), April 2006.

   [I-D.ietf-netlmm-threats]
              Kempf, J. and C. Vogt, "Security Threats to Network-based
              Localized Mobility Management",
              draft-ietf-netlmm-threats-00 (work in progress),
              April 2006.

   [I-D.njedjou-netlmm-globalmm-ps]
              Njedjou, E. and J. Riera, "Problem Statement for Global IP
              Mobility Management", draft-njedjou-netlmm-globalmm-ps-01
              (work in progress), May 2006.

   [I-D.thaler-intarea-multilink-subnet-issues]
              Thaler, D., "Issues With Protocols Proposing Multilink
              Subnets", draft-thaler-intarea-multilink-subnet-issues-00
              (work in progress), March 2006.




Templin, et al.         Expires December 4, 2006               [Page 13]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927,
              May 2005.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

   [RFC4039]  Park, S., Kim, P., and B. Volz, "Rapid Commit Option for
              the Dynamic Host Configuration Protocol version 4
              (DHCPv4)", RFC 4039, March 2005.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC4389]  Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
              Proxies (ND Proxy)", RFC 4389, April 2006.

   [RFC4436]  Aboba, B., Carlson, J., and S. Cheshire, "Detecting
              Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.


Appendix A.  Nested LMMD Model

   The MAP function can be distributed among the ARs if each AR
   configures a DHCP server that delegates addresses from its own IP
   prefix range that is distinct from the IP prefix ranges delegated by
   other ARs.  In that case, each MN would receive IP address/prefix
   delegations that are relative to their "home" AR and distinct from
   the IP addresses/prefixes delegated by other ARs.  In other words,
   each AR (and its associated MNs) appears as a nested LMMD within a
   larger encompassing LMMD.

   In this scenario, each AR configures a DHCP server that delegates IP
   addresses/prefixes from an IP prefix range that is distinct from



Templin, et al.         Expires December 4, 2006               [Page 14]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


   other ARs.  Each AR also advertises reachability to its IP prefix
   range via the intra-domain routing protocol on the backhaul network,
   and configures an IP address for itself from the prefix range, e.g.,
   '2001:DB8::1'.

   When a MN first enters a LMMD, it discovers a home AR (based on IP
   router advertisements) and sends DHCPDISCOVER (IPv4) or Solicit
   (IPv6) messages to the IP unicast address of the AR to request an IP
   address/prefix delegation.  After the MN receives IP address/prefix
   delegations, it sends periodic DHCPREQUEST (IPv4), Confirm or Renew
   (IPv6) messages to the unicast address of the primary AR to refresh
   its address lease lifetimes as long as it requires continued global
   IP addressing services.

   If the MN loses its connection with its home AR, it selects a
   "visited" AR and sends an immediate DHCPREQUEST (IPv4), Confirm or
   Renew (IPv6) message to the unicast address of the visited AR.  The
   DHCP entity on the visited AR will note that the MNs address is
   delegated from a different IP prefix range within the LMMD and will
   relay the request to the IP address of the MNs home AR, e.g., '2001:
   DB8::1".  This implies that the DHCP entity on the visited AR must
   act as a hybrid relay/server.

   When the home AR (acting as a MAP) receives the relayed request, it
   notes the address of the relaying AR from the BOOTP 'giaddr' field or
   the DHCPv6 'peer-address' field then configures a route in its IP
   forwarding table and (if necessary) a tunnel interface used for
   directing packets destined for the MN to the visited AR.  After the
   route is configured, the MAP returns a DHCPOFFER (IPv4) or Advertise
   (IPv6) to the unicast address of the visited AR.  (In other words,
   the home AR performs the same function that a centralized MAP would
   ordinarily perform on behalf of MNs that are away from home.)

   In this model, failure of an AR would result in IP readdressing and
   dropped calls for MNs that associated with the failed AR.  Such
   failure cases can possibly be mitigated by supporting functions in
   the backhaul network (TBD).

   Also in this model, all ARs within the LMMD must delegate IP
   addresses/prefixes from prefix ranges that are covered by the IP
   prefix served by the aggregated LMMD.  For example, the aggregated
   LMMD could serve the prefix '2001:DB8::/48', and ARs within the LMMD
   could serve subordinate prefixes such as '2001:DB8::/56', '2001:DB8:
   0:100::/56', etc.  In other words, the ARs represent nested LMMDs
   within the aggregated LMMD.






Templin, et al.         Expires December 4, 2006               [Page 15]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


Appendix B.  Control Message Loss Implications for NETLMM

   [I-D.ietf-netlmm-mn-ar-if] specifies a network-based mechanism that
   uses a MN's duplicate address detection procedure to implicitly
   trigger address registration signaling between the AR and the MAP,
   while this document specifies a host-based mechanism that uses a MNs
   DHCP requests to explicitly trigger address registration signaling
   between the MN and the MAP.  Control message loss implications for
   both scenarios are analyzed in the following sections:

B.1.  Implications for Network-Based Signaling

   In the network-based signaling method specified in [I-D.ietf-netlmm-
   mn-ar-if], if the MN configures a tentative address and sends a
   Neighbor Solicitation (NS) message to the solicited-node multicast
   address (see: [RFC2462], Section 5.4.2), but a control message is
   lost somewhere on the MN<->AR<->MAP paths, the MN could incorrectly
   conclude that its tentative address was both unique and successfully
   registered with the MAP.  The following scenarios can occur:

   1.  If the MN's multicast NS message is lost on the MN->AR path, the
       AR will not perform address registration and the MN will receive
       no indication that address registration failed.  The MN will then
       incorrectly assign the tentative address to an interface after
       RetransTimer msecs (see: [RFC2462], Section 5.4).

   2.  If the AR attempts to register a MN's tentative address with the
       MAP and the MAP returns an indication that the address was a
       duplicate, the AR will defend the MN's tentative address by
       sending a Neighbor Advertisement (NA) message to the all-nodes
       multicast address on the AR->MN path as specified in ([RFC2461],
       Section 7.2.4).  But, if the NA message is lost, the MN will
       incorrectly assign the tentative address to an interface after
       RetransTimer msecs.

   3.  If a control message is lost on the AR<->MAP paths, the AR can
       assume loss after a timeout period and retry the registration
       until an acknowledgement is received.  If the retries are not
       completed within RetransTimer msecs and the address registration
       fails (due to address duplication and/or excessive retries), the
       MN will incorrectly assign the tentative address to an interface.

   One possible mitigation is for the MN to set DupAddrDetectTransmits
   (see: [RFC2462], Section 5.4) to some value greater than 1 at the
   expense of extra control message overhead and extra delay, but this
   mitigation can fail when more than DupAddrDetectTransmits control
   messages are lost.  A complementary mitigation is for the AR to set
   its retry timer to some value smaller than RetransTimer/N (where N is



Templin, et al.         Expires December 4, 2006               [Page 16]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


   the desired number of retries) and/or for the MN to set RetransTimer
   to some value larger than the default of 1000 msecs.  But, since the
   MN<->AR<->MAP paths may be carried over links with arbitrarily-long
   delays, selecting appropriate timer values may be problematic in some
   use cases.  Also, this mitigation can fail when a NS/NA message is
   lost on the MN<->AR paths.  Finally, the network could attempt a
   "just-in-time" registration for a MN that sends packets without
   previously registering its address but such mitigations could be
   susceptible to security and robustness-related issues.

B.2.  Implications for Host-based Signaling

   In the DHCP-based MN-driven case specified in this document, if a
   control message is lost on the MN<->AR<->MAP paths, the MN will retry
   the DHCP request until a DHCP reply is received.  If excessive
   failures occur and the MN abandons its efforts, the DHCP server may
   have created useless address delegation state that will expire after
   the lease lifetime expires but the MN will not incorrectly assign an
   address to an interface.  The MN is also free to try again using
   different ARs which should lead to successful address registration
   and acknowledgement.

   DHCPv4 requests encode a Transaction ID ('xid') used by the client to
   match incoming messages with pending requests, and ([RFC2131],
   Section 4.1) states that: "Selecting a new 'xid' for each
   retransmission is an implementation decision.  A client may choose to
   reuse the same 'xid' or select a new 'xid' for each retransmitted
   message.".  DHCPv6 requests likewise encode a Transaction ID
   ('transaction-id'), but ([RFC3315], Section 15.1) states that: "A
   client MUST leave the transaction ID unchanged in retransmissions of
   a message.".

   So, for MNs that implement a DHCPv4 client that selects a new 'xid'
   for each retransmission, address registration may fail even after
   successive retries if the delay across the MN<->AR<->MAP paths is
   longer than the retransmission time.  For MNs that implement a
   DHCPv4/DHCPv6 client that uses the same Transaction ID for successive
   retries, address registration should succeed since any DHCP reply
   will complete the (retransmitted) DHCP request.

B.3.  Summary

   The network-based signaling mechanisms specified in [I-D.ietf-netlmm-
   mn-ar-if] leave opportunity for the MN to incorrectly assign an
   address to an interface, while the host-based signaling mechanisms
   specified in this document do not.  Therefore, applicability of the
   network-based model must be carefully analyzed for specific use cases
   and compared against MN complexity in the host-based method.



Templin, et al.         Expires December 4, 2006               [Page 17]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


Appendix C.  Changes since -00

   o  updated figure 1.

   o  added new appendices on nested LMMD model and failure cases for
      the network-based signaling.

   o  added text under "AR operation" and "Non-Standard Behavior" for
      route management.

   o  removed "over the backhaul network" from "MAP operation" in the
      passage on MAP synchronization.

   o  changed "IP Version Differences" section title to "IPv6
      Advantages".

   o  changed document title.


































Templin, et al.         Expires December 4, 2006               [Page 18]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


Authors' Addresses

   Fred L. Templin
   Boeing Phantom Works
   P.O. Box 3707 MC 7L-49
   Seattle, WA  98124
   USA

   Email: fred.l.templin@boeing.com


   Steven W. Russet
   Boeing Phantom Works
   P.O. Box 3707 MC 7L-49
   Seattle, WA  98124
   USA

   Email: steven.w.russert@boeing.com


   Ian D. Chakeres
   Boeing Phantom Works
   P.O. Box 3707 MC 7L-49
   Seattle, WA  98124
   USA

   Email: ian.chakeres@gmail.com


   Seung Yi
   Boeing Phantom Works
   P.O. Box 3707 MC 7L-49
   Seattle, WA  98124
   USA

   Email: seung.yi@boeing.com















Templin, et al.         Expires December 4, 2006               [Page 19]


Internet-Draft  Localized Mobility Management using DHCP       June 2006


Intellectual Property Statement

   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.


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.


Copyright Statement

   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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Templin, et al.         Expires December 4, 2006               [Page 20]