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]