Network Working Group F. Templin, Ed.
Internet-Draft S. Russert, Ed.
Intended status: Standards Track Boeing Phantom Works
Expires: March 26, 2007 K. Grace, Ed.
MITRE
September 22, 2006
Network Localized Mobility Management using DHCP
draft-templin-autoconf-netlmm-dhcp-03.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 March 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 March 26, 2007 [Page 1]
Internet-Draft Localized Mobility Management using DHCP September 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.2. Access Router (AR) Specification . . . . . . . . . . . . . 7
5.3. Mobility Anchor Point (MAP) Specification . . . . . . . . 8
5.4. Classless Static Route option . . . . . . . . . . . . . . 9
5.5. Reconfigure Message option . . . . . . . . . . . . . . . . 11
5.6. Use of RAAN Options for DHCPv6 . . . . . . . . . . . . . . 11
6. Additional Considerations . . . . . . . . . . . . . . . . . . 12
6.1. IPv6 Advantages . . . . . . . . . . . . . . . . . . . . . 12
6.2. Global Mobility Management . . . . . . . . . . . . . . . . 12
6.3. Multilink Subnet Considerations . . . . . . . . . . . . . 12
6.4. Support for MNs that use SLAAC . . . . . . . . . . . . . . 13
7. RFC Editor Notes . . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Nested LMMD Model . . . . . . . . . . . . . . . . . . 17
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Templin, et al. Expires March 26, 2007 [Page 2]
Internet-Draft Localized Mobility Management using DHCP September 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 stable backhaul networks with
mobility anchor points that delegate IP addresses/prefixes 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][RFC3633]
for IPv6, as well as the mechanisms specified in this document to
provision 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 March 26, 2007 [Page 3]
Internet-Draft Localized Mobility Management using DHCP September 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 prefix(es).
4. Model of Operation
The Dynamic Host Configuration Protocol (DHCP) has seen significant
operational experience in fielded deployments. The DHCP-based
mechanisms specified in Section 5 support IP address/prefix
configuration and dynamic route management in an LMMD. The following
figure provides a reference diagram for the localized mobility
management solution space:
Templin, et al. Expires March 26, 2007 [Page 4]
Internet-Draft Localized Mobility Management using DHCP September 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 5, an MN discovers ARs via
standard IP router discovery and sends DHCP requests that are relayed
to the MAP by one or more ARs. (The MN can direct multicast/
broadcast requests to the unicast Layer-2 address of specific ARs if
it wishes to assert AR selection.)
The MAP delegates an IP address/prefix for the MN and also creates a
route/tunnel to the delegated address/prefix via either an AR
selected by the MN or an AR of the MAP's own choosing. The MAP then
sends a DHCP reply to the MN via this primary AR and signals the AR
to create a route to the delegated address/prefix.
The MN now has a global IP address/prefix delegation and the MAP and
AR have established the correct route and address delegation cache
state. The MN can change to a new primary AR as network conditions
require and can immediately inform the MAP of the change.
The MAP uses a DHCP-based protocol to update the routing tables of
the MN's new and old ARs. The protocol is a 3-way exchange that
begins with the MAP sending a FORCERENEW (DHCPv4) or Reconfigure
(DHCPv6) to the AR. The AR responds by initiating a DHCP INFORM
Templin, et al. Expires March 26, 2007 [Page 5]
Internet-Draft Localized Mobility Management using DHCP September 2006
(DHCPv4) or Information-request (DHCPv6) exchange with the MAP to
request routes that should be added or removed by the AR. The MAP
responds to this request by sending the AR an ACK (DHCPv4) or Reply
(DHCPv6) message with Classless Static Route (CSR) option(s). Upon
receiving this response, the AR installs and/or deletes the routes as
indicated in the CSR option(s). The 3-way exchange for the route
updates provides reliability for lost messages as the MAP will
timeout and retransmit the FORCERENEW/Reconfigure until receiving an
INFORM/Inform-request, and the AR will timeout and retransmit the
INFORM/Information-request until receiving an ACK/Reply.
The following figure presents a message exchange diagram:
MN New AR MAP Old AR
| | | |
| Router Advertisement | | |
|<---------------------| | |
| DHCP Request | | |
|--------------------->| Relayed DHCP Request | |
| |--------------------->| create route |
| | | to MN via AR |
| | | |
| | DHCP Reply | |
| Relayed DHCP Reply |<---------------------| |
|<---------------------| | |
| | | |
| | | |
| | | |
| | DHCP Reconfigure | DHCP Reconfigure |
| |<---------------------|------------------->|
| | DHCP Inform | DHCP Inform |
| |--------------------->|<-------------------|
| | DHCP Reply | DHCP Reply |
| |<---------------------|------------------->|
| | create route | delete route |
| | to MN | to MN |
| | | |
...
| | |
| | | data packet
| | Tunneled Packet | for MN
| Forwarded Packet |<=====================|
|<---------------------| |
Figure 2: Message Exchange Diagram
Templin, et al. Expires March 26, 2007 [Page 6]
Internet-Draft Localized Mobility Management using DHCP September 2006
5. Functional Specification
5.1. Mobile Node (MN) Specification
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.
The MN then requests IP address/prefix delegations via a DISCOVER
(IPv4) or Solicit (IPv6) exchange. After address/prefix
configuration, the MN periodic renews its address/prefix lease
lifetimes.
If the MN's primary AR fails or appears to be failing (e.g., due to a
link change event) the MN sends an immediate REQUEST (IPv4), Confirm
or Rebind (IPv6) message via a new AR so that the MAP(s) and ARs can
quickly update their IP forwarding tables. For DHCPv4, the MN
generates the REQUEST according to the REBINDING state instead of the
RENEWING state.
5.2. Access Router (AR) Specification
ARs send periodic and solicited RAs on their attached access networks
per [RFC1256] (IPv4) or [RFC2461] (IPv6).
ARs configure a BOOTP (IPv4) or DHCPv6 (IPv6) relay agent and a DHCP
client. At startup, an AR's DHCP client function announces its
presence to any MAP(s) by sending a DISCOVER (DHCPv4) or Solicit
(DHCPv6) containing a Parameter Request List option (DHCPv4) or
Option Request option (DHCPv6) with the Classless Static Route (CSR)
option code (see: Section 5.4) listed twice. The presence of two or
more CSR codes in the option indicates that the client is configured
as an AR. Upon receiving a response, the AR examines the OFFER
(DHCPv4) or Advertise (DHCPv6) to see if it contains an empty CSR
option. If it does, the AR concludes the responding DHCP server is
configured as a MAP.
When an AR receives a FORCERENEW (DHCPv4) [RFC3203] or Reconfigure
(DHCPv6) from a MAP, it inspects the message for a Reconfigure
Message option (see: Section 5.5) to determine whether it should
initiate an INFORM (DHCPv4) / Information-request (DHCPv6) or RENEW
(DHCPv4) / Renew (DHCPv6) exchange with the server (according to
standard backoff and retransmission rules). Upon receiving an ACK
(DHCPv4) or Reply (DHCPv6), the AR examines the message for CSR
Option(s).
For DHCPv4, CSR options are ordered such that the first zero or more
non-empty CSRs supply routes to be added, followed by an empty CSR,
Templin, et al. Expires March 26, 2007 [Page 7]
Internet-Draft Localized Mobility Management using DHCP September 2006
followed by zero or more non-empty CSRs that supply routes to be
deleted.
For DHCPv6, the lifetime field for each route indicates whether the
route should be added (lifetime > 0) or deleted (lifetime = 0). The
AR processes the CSR options and adds/deletes routes as indicated.
5.3. Mobility Anchor Point (MAP) Specification
The MAP(s) in the backhaul network act as DHCP servers and routers
that aggregate IP prefixes associated with 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 within the same LMMD,
they synchronize state to maintain a consistent view of address/
prefix delegations and IP routes.
When a MAP receives a DISCOVER (DHCPv4) or Solicit (DHCPv6) from an
AR's client function (see: Section 5.2) it registers the client as an
AR and replies with an OFFER (DHCPv4) or Advertise (DHCPv6)
containing an empty CSR option.
When a MAP receives a DISCOVER (IPv4) or Solicit (IPv6) message from
a MN, it delegates IP address(es)/prefix(es) and/or other requested
configuration information. When the MAP is ready to commit the
address/prefix delegations, it configures a route in its IP
forwarding table and a tunnel interface used for directing packets
destined for the MN to the AR via which the MN's DHCP request was
relayed. The MAP then returns the ACK (IPv4) or Reply (IPv6) message
to the MN via the AR as a DHCP relay.
When CSRs are used, the MAP simultaneously initiates a procedure to
update the routing tables of the MN's new and old ARs. The MAP
begins by sending a FORCERENEW (DHCPv4) or Reconfigure (DHCPv6) with
a Reconfigure Message option (using standard backoff and
retransmission rules) to trigger the AR to perform an INFORM/ACK
(DHCPv4) or Information-request/Information-reply (DHCPv6) exchange.
Upon receiving an INFORM/Information-request, the MAP inspects the
message for the presence of CSR option request codes. If only one
CSR option code is present, the MAP will interpret the request to be
for a full dump of routes. If two or more CSR option requests are
present, the MAP will interpret the request to be for an incremental
update that includes only routes to be added/deleted since the last
request. The MAP populates an ACK (DHCPv4) or Reply (DHCPv6) with
CSR options that contain the desired routes, and sends the message to
the requesting AR. For DHCPv4, CSR options are ordered following the
convention specified in Section 5.2.
Templin, et al. Expires March 26, 2007 [Page 8]
Internet-Draft Localized Mobility Management using DHCP September 2006
Following DHCP address/prefix delegation and IP route/tunnel
configuration, when an IP packet destined for an MN arrives at a MAP,
the MAP 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).
The MAP retains address/prefix delegations as long as the MN
continues to refresh its lease lifetimes. When the MN changes to a
new primary AR, the MAP updates its cached route/tunnel
configurations to point to the new AR. The MAP then initiates the
update procedure described above to the new and old ARs. When lease
lifetimes expire, the MAP deletes its cached address/prefix
delegations and their corresponding route/tunnel configurations and
performs the update procedure with the AR to delete the MNs
associated routes.
5.4. Classless Static Route option
[RFC3442] specifies a Classless Static Route option for IPv4. This
document specifies a corresponding CSR option for DHCPv6.
The format of the Classless Static Route option for IPv6 is given
below:
Templin, et al. Expires March 26, 2007 [Page 9]
Internet-Draft Localized Mobility Management using DHCP September 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CSR | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix-len | intf-id-len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| prefix |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| nexthop |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. interface-id .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CSR (TBD).
option-len 38 + length of interface ID field.
prefix-len Prefix length for the IPv6 prefix.
intf-id-len Length of the interface-id field.
prefix an IPv6 address/prefix.
nexthop an IPv6 address that identifies the nexthop for the
static route
interface-id an opaque value that was conveyed from a relay to
the server. Only used for clients configured on
the same machine as the relay.
lifetime The remaining lifetime for the CSR in the
option, expressed in units of seconds.
Figure 3: Classless Static Route (CSR) option for DHCPv6
Templin, et al. Expires March 26, 2007 [Page 10]
Internet-Draft Localized Mobility Management using DHCP September 2006
5.5. 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
5.6. Use of RAAN Options for DHCPv6
[I-D.ietf-dhc-dhcpv6-agentopt-delegate] specifies a Relay Agent
Assignment Notification (RAAN) option used by DHCPv6 servers to
manage static routes in the networking equipment associated with
relays on the path.
ARs with relays that are prepared to accept RAAN options include the
RAAN option code in the Option Request option of the initial Solicit
exchange between their client function and the DHCPv6 server on the
MAP.
MAPs include RAAN options (instead of CSR options) in DHCPv6 replies
that traverse the AR's relay function for ARs that accept RAAN
options. This means that the MAP can include RAAN options in-band on
the MAP's DHCP reply to a MN instead of out-of-band via a
Reconfigure/Information-request/Information-reply exchange with the
AR's client function.
When a MAP initiates a DHCPv6 Reconfigure/Information-request/
Information-reply to delete routes on an AR from which a MN has
recently departed, it encapsulates the Reconfigure in a Relay-forward
message with RAAN options that forces the Reconfigure to pass through
the ARs relay function before reaching the AR's client function.
Templin, et al. Expires March 26, 2007 [Page 11]
Internet-Draft Localized Mobility Management using DHCP September 2006
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
address(es) 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.
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
reserve 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.2. Global Mobility Management
When an 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. A problem statement for global IP
mobility management is given in [I-D.njedjou-netlmm-globalmm-ps].
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
Templin, et al. Expires March 26, 2007 [Page 12]
Internet-Draft Localized Mobility Management using DHCP September 2006
the prefix and all MNs that receive them are associated with a single
link.
MNs and ARs must not assign prefixes other than /128 (IPv6) or /32
(IPv6) to an access interface unless it can be assured that all nodes
that configure addresses from the prefix are connected to the same
link.
6.4. Support for MNs that use SLAAC
This specification can be extended to support MNs that use StateLess
Address Auto Configuration (SLAAC) [RFC2462] instead of DHCPv6. All
AR<->MAP signaling would be the same as specified in Section 5 with
the exception that the AR would act as a proxy DHCP client on behalf
of the MN as triggered by the MN's Neighbor Solicitation (NS)
messages.
7. RFC Editor Notes
(RFC Editor - this section to be deleted before publication as an
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 an
immediate REQUEST while entering the REBINDING state upon link change
detection. This document updates [RFC2131].
[RFC3442] specifies a Classless Static Route option for DHCPv4, but
does not specify a corresponding option for IPv6. Section 5.4 of
this document specifies a Classless Static Route option for DHCPv6.
This document updates [RFC3442].
[RFC3203] does not provide a means for the server to inform the
client of whether a RENEW or INFORM exchange is requested.
Section 5.5 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
Classless Static Route option for DHCPv6 in the 'dhcpv6-parameters'
registry.
The IANA is instructed to allocate a new option code for the
Reconfigure Message option for DHCPv4 in the 'bootp-dhcp-parameters'
Templin, et al. Expires March 26, 2007 [Page 13]
Internet-Draft Localized Mobility Management using DHCP September 2006
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
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 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
mechanisms for address configuration.
The Naval Research Lab (NRL) Information Technology Division uses
DHCP in their MANET research testbeds.
Templin, et al. Expires March 26, 2007 [Page 14]
Internet-Draft Localized Mobility Management using DHCP September 2006
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, Bernie Volz.
Alexandru Petrescu mentioned DHCP in NETLMM mailing list discussions.
13. References
13.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.
[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.
[RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP
reconfigure extension", RFC 3203, December 2001.
Templin, et al. Expires March 26, 2007 [Page 15]
Internet-Draft Localized Mobility Management using DHCP September 2006
[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.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
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-dhcpv6-agentopt-delegate]
Droms, R., "DHCPv6 Relay Agent Assignment Notification
(RAAN) Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-01
(work in progress), August 2006.
[I-D.ietf-netlmm-nohost-ps]
Kempf, J., "Problem Statement for Network-based Localized
Mobility Management", draft-ietf-netlmm-nohost-ps-04 (work
in progress), June 2006.
[I-D.ietf-netlmm-nohost-req]
Kempf, J., "Goals for Network-based Localized Mobility
Management (NETLMM)", draft-ietf-netlmm-nohost-req-04
(work in progress), August 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.
[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.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
Templin, et al. Expires March 26, 2007 [Page 16]
Internet-Draft Localized Mobility Management using DHCP September 2006
[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
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
Templin, et al. Expires March 26, 2007 [Page 17]
Internet-Draft Localized Mobility Management using DHCP September 2006
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):
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.
Templin, et al. Expires March 26, 2007 [Page 18]
Internet-Draft Localized Mobility Management using DHCP September 2006
o changed "IP Version Differences" section title to "IPv6
Advantages".
o changed document title.
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)
MITRE
USA
Email: kgrace@mitre.org
Templin, et al. Expires March 26, 2007 [Page 19]
Internet-Draft Localized Mobility Management using DHCP September 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 March 26, 2007 [Page 20]