Network Working Group                                    F. Templin, Ed.
Internet-Draft                                           S. Russert, Ed.
Intended status: Standards Track                    Boeing Phantom Works
Expires: April 26, 2007                                    K. Grace, Ed.
                                                   The MITRE Corporation
                                                        October 23, 2006


            Network Localized Mobility Management using DHCP
               draft-templin-autoconf-netlmm-dhcp-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.

   This Internet-Draft will expire on April 26, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Mobile nodes require a means to automatically configure globally
   routable IP addresses/prefixes that remain stable across localized
   mobility events.  This document specifies mechanisms for network
   localized mobility management (NETLMM) using the Dynamic Host
   Configuration Protocol (DHCP).  Solutions for both IPv4 and IPv6 are
   given.



Templin, et al.          Expires April 26, 2007                 [Page 1]


Internet-Draft              NETLMM using DHCP               October 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Additional Authors . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Model of Operation . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Functional Specification . . . . . . . . . . . . . . . . . . .  7
     5.1.  Mobile Node (MN) Specification . . . . . . . . . . . . . .  7
       5.1.1.  Initialization . . . . . . . . . . . . . . . . . . . .  7
       5.1.2.  Address/Prefix Configuration . . . . . . . . . . . . .  7
       5.1.3.  MN Movement to a New AR  . . . . . . . . . . . . . . .  8
     5.2.  Access Router (AR) Specification . . . . . . . . . . . . .  8
       5.2.1.  NETLMM-Specific DHCP Client Behavior . . . . . . . . .  8
       5.2.2.  NETLMM-Specific DHCP Relay Behavior  . . . . . . . . .  9
       5.2.3.  Startup and MAP Registration . . . . . . . . . . . . .  9
       5.2.4.  MN Movement to a new AR  . . . . . . . . . . . . . . . 10
       5.2.5.  MN Movement from an Old AR . . . . . . . . . . . . . . 10
       5.2.6.  AR Forwarding Model  . . . . . . . . . . . . . . . . . 11
     5.3.  Mobility Anchor Point (MAP) Specification  . . . . . . . . 11
       5.3.1.  AR Registration  . . . . . . . . . . . . . . . . . . . 11
       5.3.2.  MN Address/Prefix Configuration  . . . . . . . . . . . 12
       5.3.3.  MN Movement to a New AR  . . . . . . . . . . . . . . . 12
       5.3.4.  MN Movement from an Old AR . . . . . . . . . . . . . . 13
       5.3.5.  MN Departure from the LMMD . . . . . . . . . . . . . . 13
       5.3.6.  MAP Forwarding Model . . . . . . . . . . . . . . . . . 14
     5.4.  Reconfigure Message option . . . . . . . . . . . . . . . . 14
   6.  Additional Considerations  . . . . . . . . . . . . . . . . . . 14
     6.1.  IPv6 Advantages  . . . . . . . . . . . . . . . . . . . . . 14
     6.2.  Global Mobility Management . . . . . . . . . . . . . . . . 15
     6.3.  Multilink Subnet Considerations  . . . . . . . . . . . . . 15
   7.  RFC Editor Notes . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   10. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 17
   11. Implementation Status  . . . . . . . . . . . . . . . . . . . . 17
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     13.2. Informative References . . . . . . . . . . . . . . . . . . 19
   Appendix A.  Nested LMMD Model . . . . . . . . . . . . . . . . . . 20
   Appendix B.  Change Log  . . . . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23








Templin, et al.          Expires April 26, 2007                 [Page 2]


Internet-Draft              NETLMM using DHCP               October 2006


1.  Introduction

   Access networks (e.g., campus LANs, cellular wireless, WiFi, MANETs,
   etc.) may be prone to congestion, signal intermittence, node
   movements, partitions/merges, equipment failure, etc.  From a node's
   viewpoint, these disturbances appear as mobility events that cause
   communications to fail or degrade, i.e., the node appears to be
   mobile with respect to the access network.  Such mobile nodes require
   a means to procure globally routable IP addresses/prefixes that
   remain stable across mobility events.  This can be accommodated when
   access routers connect mobile nodes via backhaul networks with
   mobility anchor points that delegate IP addresses/prefixes and
   maintain mobile node to access router mappings.

   Access routers and mobility anchor points can use the Bootstrap
   Protocol (BOOTP) [RFC0951] and Dynamic Host Configuration Protocol
   (DHCPv4) [RFC2131] [I-D.ietf-dhc-subnet-alloc] for IPv4, or DHCPv6
   [RFC3315][RFC3633] for IPv6, as well as the mechanisms specified in
   this document to provision mobile nodes with globally routable and
   unique IP addresses/prefixes that remain stable within a localized
   mobility management domain.

   The model of operation described in this document corresponds to
   [I-D.ietf-netlmm-nohost-ps] [I-D.ietf-netlmm-nohost-req].  Solutions
   for both IPv4 [RFC0791] and IPv6 [RFC2460] are given.


2.  Additional Authors

   Ian Chakeres (ian.chakeres@gmail.com) and Seung Yi
   (seung.yi@boeing.com) made significant contributions to this effort.


3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in "Key words for use in
   RFCs" [RFC2119].

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

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






Templin, et al.          Expires April 26, 2007                 [Page 3]


Internet-Draft              NETLMM using DHCP               October 2006


   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 and client.

   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/prefixes from a set of aggregated prefixes.

   Classless Static Route (CSR) option
      a DHCP option with (address/prefix, nexthop) information
      pertaining to a MN.  For DHCPv4, the CSR option is specified in
      [RFC3442].  For DHCPv6, [I-D.ietf-dhc-dhcpv6-agentopt-delegate]
      specifies a "Relay Agent Assignment Notification (RAAN)" option
      that this document refers to as the "CSR option for DHCPv6".

   Server Reply Sequence Number (SRSN) option
      a DHCPv6 option specified in [I-D.volz-dhc-dhcpv6-srsn-option]
      that carries a sequence number pertaining to CSRs.


4.  Model of Operation

   The Dynamic Host Configuration Protocol (DHCP) has seen significant
   operational experience in fielded deployments.  The DHCP-based
   mechanisms for NETLMM specified in Section 5 support IP address/
   prefix configuration and stability as well as dynamic route
   management in an LMMD.  The following figure provides a reference
   diagram for the localized mobility management solution space:






Templin, et al.          Expires April 26, 2007                 [Page 4]


Internet-Draft              NETLMM using DHCP               October 2006


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

                    Figure 1: Reference Network Diagram

   In this model, the MAP uses DHCP-based mechanisms to delegate IP
   addresses/prefixes for a MN.  The MAP then creates routes in its IP
   forwarding table that point to a specific AR and signals the AR to
   create routes in its IP forwarding table that associate the MN with
   the correct access link.  When the MN moves from an old AR to a new
   AR, the MAP and ARs update their IP forwarding tables using either an
   MN-initiated exchange or an AR-initiated exchange.

   An MN-initiated exchange begins when an MN sends a DHCP request to
   the MAP either on the first network join or when changing to a new
   AR.  The MAP includes routing information in its reply to the MN via
   the new AR and simultaneously initiates a FORCERENEW (DHCPv4)
   [RFC3203] or Reconfigure (DHCPv6) exchange that deletes routing
   information in the old AR.  Figure 2 presents the MN-initiated
   exchange:









Templin, et al.          Expires April 26, 2007                 [Page 5]


Internet-Draft              NETLMM using DHCP               October 2006


   MN                 New AR                    MAP               Old AR
    |                      |                      |                    |
    | Router Advertisement |                      |                    |
    |    (or L2 event)     |                      |                    |
    |<---------------------|                      |                    |
    |     DHCP Request     |                      |                    |
    |--------------------->| Relayed DHCP Request |                    |
    |                      |--------------------->| create route to    |
    |                      |                      | MN via new AR      |
    |                      |                      |                    |
    |                      |      DHCP Reply      |  DHCP Reconfigure  |
    |  Relayed DHCP Reply  |<---------------------|------------------->|
    |<---------------------|create routes         |  DHCP Info-request |
    |                      |to MN                 |<-------------------|
    |                      |                      |   DHCP Reply       |
    |                      |                      |------------------->|
    |                      |                      |       delete routes|
    |                      |                      |               to MN|
    |                      |                      |                    |
    ...
    |                      |                      |
    |                      |                      | data packet
    |                      |   Tunneled Packet    | for MN
    |   Forwarded Packet   |<=====================|
    |<---------------------|                      |

              Figure 2: MN-initiated Message Exchange Diagram

   An AR-initiated exchange begins when an AR detects an L2 mobility
   event or (for IPv6) when an MN sends a Neighbor Solicitation (NS) for
   the purpose of Duplicate Address Detection (DAD) during StateLess
   Address Auto-Configuration (SLAAC).  This new AR sends an immediate
   INFORM (DHCPv4) or Information-request (DHCPv6) to the MAP containing
   a client identifier for the MN without waiting for a random delay.
   The MAP responds by sending an ACK (DHCPv4) or Reply (DHCPv6) to the
   new AR with address/prefix delegation information pertaining to the
   MN and simultaneously issuing a FORCERENEW (DHCPv4) or Reconfigure
   (DHCPv6) exchange with the old AR exactly as for the MN-initiated
   exchange.  Figure 3 presents the AR-initiated message exchange:












Templin, et al.          Expires April 26, 2007                 [Page 6]


Internet-Draft              NETLMM using DHCP               October 2006


   MN                 New AR                    MAP               Old AR
    |                      |                      |                    |
    |  NS(DAD) or L2 event |   DHCP Info-request  |                    |
    |--------------------->|--------------------->|update routes to    |
    |                      |                      |MN via new AR       |
    |                      |                      |                    |
    |                      |      DHCP Reply      |  DHCP Reconfigure  |
    |                      |<---------------------|------------------->|
    |                      |create routes         |  DHCP Info-request |
    |                      |to MN                 |<-------------------|
    |                      |                      |   DHCP Reply       |
    |                      |                      |------------------->|
    |                      |                      |       delete routes|
    |                      |                      |               to MN|
    |                      |                      |                    |
    ...
    |                      |                      |
    |                      |                      | data packet
    |                      |   Tunneled Packet    | for MN
    |   Forwarded Packet   |<=====================|
    |<---------------------|                      |

              Figure 3: AR-initiated Message Exchange Diagram


5.  Functional Specification

5.1.  Mobile Node (MN) Specification

   IPv6 MNs observe the specifications found in
   [I-D.ietf-netlmm-mn-ar-if]; IPv4 and IPv6 MNs also observe the
   specifications in the normative references.  The following
   subsections highlight specifications from the normative references
   that have particular relevance to NETLMM using DHCP:

5.1.1.  Initialization

   When an MN powers on, activates a network interface or moves into a
   new LMMD, it discovers ARs via standard ICMP Router Solicitation (RS)
   and Router Advertisement (RA) messages per [RFC1256] (IPv4) or
   [RFC2461] (IPv6) and adds one or more ARs to its default router list
   based on the RAs received.

5.1.2.  Address/Prefix Configuration

   An IPv6 MN that uses SLAAC [RFC2462] to configure link-local or non-
   link-local addresses triggers an AR-initiated exchange when it sends
   NS(DAD).  An IPv4 or IPv6 MN that uses DHCP to configure IP



Templin, et al.          Expires April 26, 2007                 [Page 7]


Internet-Draft              NETLMM using DHCP               October 2006


   addresses/prefixes performs an ordinary MN-initiated DHCP exchange.

   MNs can optionally direct their broadcast/multicast solicitations to
   the unicast Layer-2 addresses of specific ARs if they wish to assert
   AR selection.

5.1.3.  MN Movement to a New AR

   If a MN using DHCP detects a mobility-related event (e.g., the MN's
   serving AR fails or appears to be failing) it sends a REQUEST
   (DHCPv4) or Confirm/Rebind (DHCPv6).  (For DHCPv4, the MN generates
   the REQUEST according to the REBINDING state instead of the RENEWING
   state.)  MNs that use only SLAAC may/may not rerun the DAD procedure
   due to a mobility-related event.

   MNs can optionally direct their broadcast/multicast messages
   triggered by mobility events to the unicast Layer-2 addresses of
   specific ARs if they wish to assert AR selection.

5.2.  Access Router (AR) Specification

   ARs send periodic and solicited RAs on their attached access networks
   per [RFC1256] (IPv4) or [RFC2461] (IPv6) and also configure both a
   DHCP/BOOTP relay agent and a DHCP client.

   For DHCPv6, the DHCP relay agent and client are tightly-coupled, with
   the client function performing all mobility-related signaling and the
   relay function performing IP forwarding table maintenance; the client
   and relay functions otherwise behave as an ordinary DHCP client and
   relay.  The two functions can be tightly-coupled via implementation
   in the same process context, inter-process communications,
   communications via a loopback interface, etc.  This document assumes
   communications via a loopback interface but does not preclude other
   methods of coupling the AR's client and relay functions.

   The following subsections specify the operation of ARs in an LMMD:

5.2.1.  NETLMM-Specific DHCP Client Behavior

   For DHCPv4, when the AR's client function receives an ACK from a MAP,
   it examines the message for CSR options and updates its IP forwarding
   table according to the information in the CSRs.  For the purpose of
   this specification, the CSR options must be ordered such that the
   first zero or more non-empty CSRs supply routes to be added, followed
   by an empty CSR, followed by zero or more non-empty CSRs that supply
   routes to be deleted.

   For DHCPv6, the AR's client function wraps each client-server message



Templin, et al.          Expires April 26, 2007                 [Page 8]


Internet-Draft              NETLMM using DHCP               October 2006


   it sends for mobility management purposes in a Relay-forward message
   with:

   o  the loopback address (::1) written in the 'peer-address' field,

   o  zero written in the 'link-address' field,

   o  an Interface-Id option included that identifies a loopback
      interface that the client listens on,

   o  and an Option Request option that lists the SRSN and CSR option
      codes

   The AR's client function then includes any other options as necessary
   and forwards the message via its backhaul network interface as though
   it were being relayed by its relay function.

   For both DHCPv4 and DHCPv6, the AR's client function monitors MN
   mobility events, e.g., by monitoring L2 mobility indications, and
   issues an appropriate INFORM/Information-request exchange as
   specified in the following sections.  When an AR's client function
   performs an INFORM/Information-request exchange with a MAP, it
   initiates the exchange immediately without waiting for the standard
   random delay.

5.2.2.  NETLMM-Specific DHCP Relay Behavior

   For DHCPv4, when an AR's relay function relays an ACK to a MN it
   examines the message for address/prefix delegations and updates the
   AR's IP forwarding table according to the delegations.

   For DHCPv6, the AR's relay function includes an Option Request option
   that lists the SRSN and CSR option codes in each Relay-forward
   message it sends.  When it relays a message to a client, it updates
   the AR's IP forwarding table according to the information in the SRSN
   and any CSR options in the Relay-reply message.

5.2.3.  Startup and MAP Registration

   When an AR powers up in an LMMD, it performs an initial solicitation
   to register itself with a MAP.

   For DHCPv4, the AR's client function creates a DISCOVER message that
   contains a Parameter Request List option that lists the CSR option
   code twice then performs an ordinary DISCOVER exchange.

   For DHCPv6, the AR's client function creates a Solicit message that
   includes a Client Identifier option identifying itself, a Reconfigure



Templin, et al.          Expires April 26, 2007                 [Page 9]


Internet-Draft              NETLMM using DHCP               October 2006


   Accept option, and any other options required for the initial
   solicitation.  It then wraps the Solicit in a Relay-forward message
   as specified in Section 5.2.1 except that it includes the CSR option
   code twice in the Option Request option.  The AR then performs an
   ordinary Solicit exchange.

   When the AR receives a reply to its solicitation from a server that
   includes an empty CSR option per Section 5.3.1 it registers the
   server as a MAP.

5.2.4.  MN Movement to a new AR

   When an AR's client function detects a new MN via a L2 mobility event
   (or, for IPv6, when an MN issues an NS(DAD)), it issues an INFORM
   (DHCPv4) or Information-request (DHCPv6).

   For DHCPv4, the AR's client function creates an INFORM message that
   includes a Parameter Request List option listing the CSR option code
   and a Client-identifier option that identifies the MN, then performs
   an ordinary INFORM exchange.

   For DHCPv6, the AR's client function creates an Information-request
   message that includes a Client Identifier option identifying itself
   and an Option Request option that lists any option codes the client
   is interested in receiving.  It then wraps the Information-request in
   a Relay-forward message as specified in Section 5.2.1 and includes a
   CSR option that includes a Client Identifier option that identifies
   the MN.  If the exchange was triggered by an NS(DAD), the client
   function also includes in the CSR option an IA Address option with
   the IPv6 address from the NS Target Address field.  (The relay
   function also includes the entire NS message in the CSR option for
   LMMD-wide proxy DAD purposes via a means outside the scope of this
   specification.)  The client function then performs an ordinary
   Information-request exchange.

5.2.5.  MN Movement from an Old AR

   For DHCPv4, when an AR's client function receives a FORCERENEW from a
   MAP with a Reconfigure Message option with 'Value' set to 11 (see:
   Section 5.4), it creates an INFORM message that includes a Parameter
   Request List option that lists the CSR option code and any other
   option codes the client is interested in receiving.  It then performs
   an ordinary INFORM exchange.

   For DHCPv6, when an AR's client function receives a Reconfigure from
   a MAP with a Reconfigure Message option with 'msg-type' set to 11, it
   creates an Information-request message that includes a Client
   Identifier option identifying itself and an Option Request option



Templin, et al.          Expires April 26, 2007                [Page 10]


Internet-Draft              NETLMM using DHCP               October 2006


   that lists any option codes the client is interested in receiving.
   It then wraps the Information-request in a Relay-forward message as
   specified in Section 5.2.1 and performs an ordinary Information-
   request exchange.

5.2.6.  AR Forwarding Model

   When an IP packet destined for a MN arrives at an AR, the AR forwards
   the packet according to its IP forwarding table which could entail
   delivery to the MN as a neighbor on an attached access link,
   tunneling to a MAP or dropping the packet and returning an
   appropriate ICMP error if the packet cannot be forwarded.

5.3.  Mobility Anchor Point (MAP) Specification

   MAPs in the backhaul network configure a DHCP server and an
   associated router that aggregates IP prefixes for the LMMD.  All MAPs
   within the same LMMD delegate IP addresses/prefixes from the LMMD's
   associated prefixes and inject the prefixes into the backhaul
   network's IGP.  When multiple MAPs are present, they synchronize
   state to maintain a consistent view of address/prefix delegations and
   IP forwarding table entries.

   For DHCPv6, MAPs maintain monotonically-increasing Server Reply
   Sequence Numbers (SRSNs) per [I-D.volz-dhc-dhcpv6-srsn-option] and
   include an SRSN option with the current value in each Relay-reply
   message they send.

   For both DHCPv4 and DHCPv6, MAPs send an immediate ACK/Reply without
   waiting for a random delay when responding to an AR's INFORM/
   Information-request.

5.3.1.  AR Registration

   For DHCPv4, when a MAP receives a DISCOVER from an AR per
   Section 5.2.1 it registers the sender as an AR, creates a tunnel to
   be used for forwarding packets to the AR, and replies with an OFFER
   or ACK (based on 4-message or 2-message exchange) that contains an
   empty CSR option.

   For DHCPv6, when a MAP receives a Solicit wrapped in a Relay-forward
   message from an AR per Section 5.2.1 it registers the sender as an
   AR, creates a tunnel to be used for forwarding packets to the AR, and
   replies with an Advertise or Reply (based on 4-message or 2-message
   exchange) wrapped in a Relay-reply message that contains an empty CSR
   option.





Templin, et al.          Expires April 26, 2007                [Page 11]


Internet-Draft              NETLMM using DHCP               October 2006


5.3.2.  MN Address/Prefix Configuration

   For IPv4 and IPv6 MNs that use DHCP, when a MAP receives a MN's
   DISCOVER (IPv4) or Solicit (IPv6) message it delegates IP addresses/
   prefixes and/or other requested configuration information.  When the
   MAP is ready to commit the address/prefix delegations, it configures
   routes in its IP forwarding table that point to the tunnel interface
   for the AR via which the MN's solicitation was relayed.  For DHCPv4,
   the MAP then returns an ACK message to the MN via the AR's relay
   function.  For DHCPv6, the MAP then returns a Reply message to the MN
   wrapped in a Relay-reply message that includes an SRSN option and CSR
   options pertaining to the MN via the AR's relay function.

   For IPv6 MNs that use SLAAC, address configuration is stateless from
   the MN's perspective but stateful from the network's perspective, and
   occurs as a side-effect of the AR-initiated exchange specified in
   Section 5.3.3.

5.3.3.  MN Movement to a New AR

   When a MN moves between ARs within the LMMD, the MAP services the
   mobility exchange as specified in the following sections:

5.3.3.1.  MN-initiated Exchange

   In a MN-initiated exchange, the MN detects a new AR (e.g., via an RA)
   and sends a REBIND-REQUEST (DHCPv4) or Confirm/Rebind (DHCPv6)
   message to the MAP.

   For DHCPv4, the MAP updates its IP forwarding table entries for the
   MN to point to the new AR, then returns an ACK message to the MN with
   address/prefix information pertaining to the MN via the new AR's
   relay function.

   For DHCPv6, the MAP updates its IP forwarding table entries for the
   MN to point to the new AR, then returns a Reply message wrapped in a
   Relay-reply message that includes an SRSN option and CSR options
   pertaining to the MN via the new AR's relay function.

5.3.3.2.  AR-initiated Exchange

   In an AR-initiated exchange, the new AR's client function detects a
   MN's presence (e.g., via an L2 trigger) and issues an INFORM (DHCPv4)
   or Information-request (DHCPv6) to the MAP.

   For DHCPv4, if the INFORM contains a Parameter Request List option
   listing the CSR option code and a Client-identifier option that
   identifies the MN, the MAP updates its IP forwarding table entries



Templin, et al.          Expires April 26, 2007                [Page 12]


Internet-Draft              NETLMM using DHCP               October 2006


   for the MN to point to the new AR.  It then returns an ACK message to
   the new AR that includes CSRs pertaining to the MN arranged as
   specified in Section 5.2.1.

   For DHCPv6, if the Information-request contains an Option Request
   option listing the CSR option code and a CSR option that includes a
   Client Identifier option that identifies the MN, the MAP updates its
   IP forwarding table entries (and/or creates new IP forwarding table
   entries) for the MN's addresses/prefixes to point to the new AR.  (If
   the CSR option also includes an IA Address option, the Information-
   request was due to a MN's NS(DAD) and the MAP performs an LMMD-wide
   proxy DAD before sending the Reply through a means outside the scope
   of this specification.)  The MAP then returns a Reply message wrapped
   in a Relay-reply message with an SRSN option and CSR options
   pertaining to the MN via the new AR's relay function.

5.3.4.  MN Movement from an Old AR

   For DHCPv4, when a MN moves to a new AR per Section 5.3.3 the MAP
   sends a FORCERENEW to the old AR's client function with a Reconfigure
   Message option with 'Value' set to 11 (see: Section 5.4).  When it
   receives an INFORM from the old AR, the MAP returns an ACK message
   that includes CSRs arranged as specified in Section 5.2.1 that
   contain routing information for the old AR.

   For DHCPv6, when a MN moves to a new AR per Section 5.3.3 the MAP
   sends a Reconfigure to the old AR's client function with a
   Reconfigure Message option with 'msg-type' set to 11.  When it
   receives an Information-request from the old AR, the MAP returns a
   Reply message wrapped in a Relay-reply message with an SRSN option
   and CSR options that contain routing information for the old AR.

5.3.5.  MN Departure from the LMMD

   For MNs that use DHCP, the MAP retains address/prefix delegations as
   long as the MN continues to refresh its lease lifetimes.  When lease
   lifetimes expire, the MAP deletes its cached address/prefix
   delegations and their corresponding route configurations and informs
   the current AR of the deletions via a FORCERENEW/Reconfigure exchange
   as specified for MN movement from an old AR in Section 5.3.4.

   For IPv6 MNs that use SLAAC, when an AR's client function detects the
   MN's departure from the LMMD it creates an Information-request
   message wrapped in a Relay-reply message as specified in
   Section 5.2.1 and includes a CSR option with all IA Address and/or IA
   Prefix options pertaining to the MN with zero lifetimes.  It then
   performs an ordinary Information-request exchange.




Templin, et al.          Expires April 26, 2007                [Page 13]


Internet-Draft              NETLMM using DHCP               October 2006


5.3.6.  MAP Forwarding Model

   When an IP packet destined for a MN arrives at a MAP, the MAP
   forwards the packet according to its IP forwarding table which could
   entail forwarding the packet via the tunnel to MN's serving AR or
   dropping the packet and returning an appropriate ICMP error if the
   packet cannot be forwarded.

5.4.  Reconfigure Message option

   ([RFC3315], Section 22.19) specifies a Reconfigure Message option for
   DHCPv6 to be included with a Reconfigure message.  This document
   specifies a corresponding Reconfigure Message option for DHCPv4 to be
   included with a FORCERENEW message.

   The format of the Reconfigure Message option for DHCPv4 is given
   below:


       Code   Len   Size
      +-----+-----+-----+
      | TBD |  1  |Value|
      +-----+-----+-----+

         Value         Operation
         -----         ---------
         0x5           Renew exchange requested
         0xb           INFORM exchange requested
         other values reserved

              Figure 4: Reconfigure Message option for DHCPv4


6.  Additional Considerations

6.1.  IPv6 Advantages

   The following features of IPv6 provide advantages over IPv4 within
   the NETLMM problem space:

   1.  IPv6 RAs can carry prefix options whereas IPv4 RAs only carry the
       addresses of routers.  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.

   2.  DHCPv6 provides a prefix delegation mechanism that MNs can use to
       acquire IP prefixes within the LMMD.




Templin, et al.          Expires April 26, 2007                [Page 14]


Internet-Draft              NETLMM using DHCP               October 2006


   3.  MNs can use unique local addresses [RFC4193] for intra-LMMD
       communications that do not require backhaul network transit.

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

   5.  DHCPv6 provides a symmetric chain of relays in the forward and
       reverse directions.  This allows for a natural mapping of the
       relay function to a router function, and allows MNs and ARs to
       leave their access network interfaces unnumbered.

   6.  DHCPv6 provides a 64-bit Server Reply Sequence Number (SRSN)
       which provides robustness against out-of-order delivery of a
       server's replies via a relay.

6.2.  Global Mobility Management

   When an MN leaves an LMMD and enters a new LMMD, its IP addresses/
   prefixes are no longer topologically correct and global mobility
   management mechanisms are needed.  Global mobility management is
   outside the scope of this document.

6.3.  Multilink Subnet Considerations

   An individual prefix is an IP prefix associated with a specific MN,
   and a shared prefix is an IP prefix that may be associated with
   multiple MNs.

   ARs must not include an individual prefix in RAs that may be received
   by a MN other than the one associated with the prefix.

   ARs must not send RAs that include a shared prefix in a Prefix
   Information Option with 'A'=1 unless there is operational assurance
   of duplicate address detection/avoidance across the LMMD.

   ARs must not send RAs that include an individual or shared prefix in
   a Prefix Information Option with 'L'=1 unless all RAs that include
   the prefix and all MNs that receive them are associated with a single
   link.

   MNs must not assume a peer is on-link unless it has received specific
   guidance from the network or it has better information that can be
   used for on-link determination.


7.  RFC Editor Notes

   (RFC Editor - this section to be deleted before publication as an



Templin, et al.          Expires April 26, 2007                [Page 15]


Internet-Draft              NETLMM using DHCP               October 2006


   RFC):

   [RFC2131] does not specify how a DHCP client should react to a link
   change event.  Section 5.1 specifies that the DHCP client sends a
   REQUEST while entering the REBINDING state upon link change
   detection.  This document updates [RFC2131].

   [RFC3442] specifies a Classless Static Route option for DHCPv4, while
   [I-D.ietf-dhc-dhcpv6-agentopt-delegate] specifies a Relay Agent
   Assignment Notification (RAAN) option for IPv6.  This document
   requests that the RAAN option be renamed as "Classless Static Route
   (CSR) Option for DHCPv6".

   [RFC3203] does not provide a means for the server to inform the
   client of whether a RENEW or INFORM exchange is requested.
   Section 5.4 of this document specifies a Reconfigure Message option
   for DHCPv4 to carry this information.  This document updates
   [RFC3203].


8.  IANA Considerations

   The IANA is instructed to allocate a new option code for the
   Reconfigure Message option for DHCPv4 in the 'bootp-dhcp-parameters'
   registry.


9.  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 between clients and
   servers is specified in [RFC3118].  The protection of messages
   between relay agents and servers is specified in [RFC4030], however
   no protection is provided for the 'giaddr' field in DHCPv4.
   ([RFC3315], Section 21) specifies mechanisms for DHCPv6 message
   authentication.

   For IPv6, if the LMMD is configured to perform authentication, an
   IPSEC security association MUST be used to protect all relayed
   messages between the AR and MAP.  For IPv4, if the LMMD is configured
   to perform authentication, either IPSEC security associations MUST be
   used to protect relayed messages, and/or the AR and MAP MUST include
   an Authentication sub-option [RFC4030] in the Relay Agent Option in
   relayed messages and responses.  Any relayed messages or responses
   that can not be successfully authenticated MUST be discarded if the



Templin, et al.          Expires April 26, 2007                [Page 16]


Internet-Draft              NETLMM using DHCP               October 2006


   LMMD is configured to perform authentication.

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


10.  Related Work

   The MITRE MobileMesh approach suggests a MAPless 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
   mechanisms for address configuration.

   The Naval Research Lab (NRL) Information Technology Division uses
   DHCP in their MANET research testbeds.


11.  Implementation Status

   Boeing and MITRE have developed independent working implementations
   of the -02 version of this specification.


12.  Acknowledgements

   The following individuals have provided valuable input: Marcelo
   Albuquerque, Ralph Droms, Wojtek Furmanski, Thomas Henderson, Long
   Ho, James Kempf, Akber Qureshi, Bernie Volz.

   Alexandru Petrescu mentioned DHCP in NETLMM mailing list discussions.
   Julien Laganier proposed a proxy DAD mechanism for use in LMMDs that
   include shared links.


13.  References

13.1.  Normative References

   [I-D.ietf-dhc-dhcpv6-agentopt-delegate]
              Droms, R., "DHCPv6 Relay Agent Assignment Notification
              (RAAN) Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-01



Templin, et al.          Expires April 26, 2007                [Page 17]


Internet-Draft              NETLMM using DHCP               October 2006


              (work in progress), August 2006.

   [I-D.volz-dhc-dhcpv6-srsn-option]
              Volz, B. and R. Droms, "DHCPv6 Server Reply Sequence
              Number Option", draft-volz-dhc-dhcpv6-srsn-option-00 (work
              in progress), August 2006.

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC3203]  T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP
              reconfigure extension", RFC 3203, December 2001.

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

   [RFC3442]  Lemon, T., Cheshire, S., and B. Volz, "The Classless
              Static Route Option for Dynamic Host Configuration
              Protocol (DHCP) version 4", RFC 3442, December 2002.




Templin, et al.          Expires April 26, 2007                [Page 18]


Internet-Draft              NETLMM using DHCP               October 2006


13.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-dhc-subnet-alloc]
              Johnson, R., "Subnet Allocation Option",
              draft-ietf-dhc-subnet-alloc-03 (work in progress),
              June 2005.

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

   [I-D.ietf-netlmm-nohost-ps]
              Kempf, J., "Problem Statement for Network-based Localized
              Mobility Management", draft-ietf-netlmm-nohost-ps-05 (work
              in progress), September 2006.

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

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

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

   [RFC4030]  Stapp, M. and T. Lemon, "The Authentication Suboption for
              the Dynamic Host Configuration Protocol (DHCP) Relay Agent



Templin, et al.          Expires April 26, 2007                [Page 19]


Internet-Draft              NETLMM using DHCP               October 2006


              Option", RFC 4030, 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.


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
   distinct IP prefix range.  Each MN would receive IP address/prefix
   delegations from their "home" AR.  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 hybrid router/DHCP server/
   relay/client.  The client function requests prefix delegations from a
   DHCP server, and the server function delegates IP addresses/prefixes
   from those IP prefixes.  The relay function relays DHCP requests and
   responses to support mobility and to mitigate the effects of errors
   such as loss of an AR or partitioning of the backhaul network.  Each
   AR also advertises reachability to its IP prefix range via the
   backhaul network IGP.

   A MN obtains address/prefix delegations as specified in Section 5.1.
   The difference is that the AR is also the MAP and allocates
   addresses/prefixes from its prefix rather than relaying messages to a
   MAP.

   If the MN roams from its home AR, it selects a "visited" AR which
   relays the MN's DHCP messages to the home AR.  The home AR updates
   its routing information and sends a route update to the current
   visited AR and previous visited AR (if any).

   In this model, failure of an AR results in packet loss and MN
   unreachability until MNs associate with a new visited AR.  Such
   failure cases can possibly be mitigated by supporting functions in
   the backhaul network (TBD).


Appendix B.  Change Log

   (RFC Editor - this section to be deleted before publication as an
   RFC):



Templin, et al.          Expires April 26, 2007                [Page 20]


Internet-Draft              NETLMM using DHCP               October 2006


   Changes from -03 to -04:

   o  support for AR-initiated updates for fast handovers

   o  support for IPv6 MNs that use SLAAC

   Changes from -02 to -03:

   o  specified explicit AR<->MAP protocol for route management using
      standard DHCP mechanisms

   o  added new sections on RFC Editor Notes and Implementation Status

   o  added new co-author

   Changes from -01 to -02:

   o  added clarification that RAs need not include prefix options; if
      none are included the MN can use DHCP prefix delegation.

   o  added point on MN sending multicast/broadcast control messages to
      the unicast Layer-2 address of an AR.

   o  updated "MAP Operations", "IPv6 advantages" and "Multilink Subnet
      Considerations" sections.

   o  shortened Introduction and Appendix B.

   o  various editorial changes

   Changes from -00 to -01:

   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 April 26, 2007                [Page 21]


Internet-Draft              NETLMM using DHCP               October 2006


Authors' Addresses

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

   Email: fred.l.templin@boeing.com


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

   Email: steven.w.russert@boeing.com


   Kevin Grace (editor)
   The MITRE Corporation
   202 Burlington Rd.
   Bedford, MA  01730
   USA

   Email: kgrace@mitre.org
























Templin, et al.          Expires April 26, 2007                [Page 22]


Internet-Draft              NETLMM using DHCP               October 2006


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

   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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Templin, et al.          Expires April 26, 2007                [Page 23]