Network Working Group F. Templin
Internet-Draft S. Russert
Expires: December 23, 2006 I. Chakeres
S. Yi
Boeing Phantom Works
June 21, 2006
Network Localized Mobility Management using DHCP
draft-templin-autoconf-netlmm-dhcp-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 23, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Mobile nodes that require global Internet access must have a way to
automatically configure globally routable and unique IP addresses
that remain stable across localized mobility events. This document
specifies mechanisms for address autoconfiguration (AUTOCONF) and
network localized mobility management (NETLMM) based on the Dynamic
Host Configuration Protocol (DHCP). Solutions for both IPv4 and IPv6
Templin, et al. Expires December 23, 2006 [Page 1]
Internet-Draft Localized Mobility Management using DHCP June 2006
are given.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Model of Operation . . . . . . . . . . . . . . . . . . . . . . 4
4. Functional Specification . . . . . . . . . . . . . . . . . . . 6
4.1. Mobile Node (MN) Operation . . . . . . . . . . . . . . . . 6
4.2. Access Router (AR) Operation . . . . . . . . . . . . . . . 7
4.3. Mobility Anchor Point (MAP) Operation . . . . . . . . . . 8
4.4. Functions Specified Only in this Document . . . . . . . . 8
5. Additional Considerations . . . . . . . . . . . . . . . . . . 9
5.1. IPv6 Advantages . . . . . . . . . . . . . . . . . . . . . 9
5.2. ARP/Neighbor Cache Management . . . . . . . . . . . . . . 10
5.3. Global Mobility Management . . . . . . . . . . . . . . . . 10
5.4. Duplicate Address Detection (DAD) . . . . . . . . . . . . 10
5.5. Multilink Subnet Considerations . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Nested LMMD Model . . . . . . . . . . . . . . . . . . 14
Appendix B. Control Message Loss Implications for NETLMM . . . . 15
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Templin, et al. Expires December 23, 2006 [Page 2]
Internet-Draft Localized Mobility Management using DHCP June 2006
1. Introduction
Access networks (e.g., campus LANs, cellular wireless, WiFi, MANETs,
etc.) that connect nodes to the Internet may be prone to disturbances
such as congestion, signal intermittence, node movements, partitions/
merges, equipment failure, etc. From a node's point of view, these
disturbances appear as mobility events that may cause its default
access router connections to fail or degrade, i.e., the node appears
to be mobile with respect to the access network. Such mobile nodes
therefore require a means to quickly associate with new access
routers as network conditions change. Moreover, a mobile node
requires a means to procure unique and globally routable IP addresses
that remain stable even if it changes access routers. This can be
accomplished when access routers connect mobile nodes to the Internet
via stable backhaul networks with mobility anchor points that
delegate IP addresses and maintain mobile node to access router
mappings.
Mobile nodes, access routers and mobility anchor points can use the
Bootstrap Protocol (BOOTP) [RFC0951] and Dynamic Host Configuration
Protocol (DHCPv4) [RFC2131] for IPv4, or DHCPv6 [RFC3315] for IPv6,
as well as the associated mechanisms specified in this document to
provision globally routable and unique IP addresses that remain
stable within a localized mobility management domain.
The model of operation described in this document corresponds to that
proposed for the IETF Network Localized Mobility Management (NETLMM)
working group [I-D.ietf-netlmm-nohost-ps] [I-D.ietf-netlmm-nohost-
req]. Solutions for both IPv4 [RFC0791] and IPv6 [RFC2460] are
given.
2. Terminology
The terminology in the normative references apply; the following
terms are defined within the scope of this document:
link
the same as defined in ([RFC2461], Section 2.1).
access network
a link that connects Mobile Nodes and Access Routers and may be
subject to congestion, signal intermittence, node movements,
network partitions/merges, equipment failure, etc.
Templin, et al. Expires December 23, 2006 [Page 3]
Internet-Draft Localized Mobility Management using DHCP June 2006
backhaul network
a network that connects Access Routers and Mobility Anchor
Point(s) and also connects the Localized Mobility Management
Domain to the global Internet.
Mobile Node (MN)
a node on an access network that also acts as a DHCP client.
Access Router (AR)
a router that connects access networks to a backhaul network and
also acts as a DHCP/BOOTP relay agent.
Mobility Anchor Point (MAP)
a backhaul network router (and its associated DHCP server) that
aggregates IP prefixes in a Localized Mobility Management Domain.
Localized Mobility Management Domain (LMMD)
a set of MAPs (and their associated ARs and MNs) that provision
addresses from the same IP subnet prefix(es).
3. Model of Operation
The Dynamic Host Configuration Protocol (DHCP) has seen significant
operational experience in fielded deployments. Using the DHCP-based
mechanisms specified in Section 4, MNs on access networks can send
DHCP requests via ARs to MAPs in a backhaul network to configure
global IP addresses and establish routes in AR/MAP IP forwarding
tables. Moreover, these mechanisms allow MNs to retain their global
IP addresses even if they change ARs within the LMMD. The following
figure provides a reference diagram for the localized mobility
management solution space:
Templin, et al. Expires December 23, 2006 [Page 4]
Internet-Draft Localized Mobility Management using DHCP June 2006
/-------------------------\
/ Internet \
\ /
\-------+---------+-------/
| |
/-------+---------+-------\ ----
/ \ ^
/ +-----+ \ |
| | MAP |-+ | |
| +-----+ |-+ | |
| +-----+ | | |
| +-----+ | |
| Backhaul Network |
| +-----+ +-----+ | L
|- - | AR1 | ..... | ARn | - -| M
| +-----+ +-----+ | M
| / \ Access / \ | D
| / \ Network / \ |
| / \ / \ | |
| +----+ | |
| | MN | -------> | |
\ +----+ AR change / |
\ / v
\-------------------------/ ----
Figure 1: Reference Network Diagram
Using the mechanisms specified in Section 4, an MN discovers ARs via
standard IP router discovery. The MN then sends a multicast/
broadcast DHCP request that is relayed to the MAP by one or more ARs.
(The MN can direct the request to an AR's unicast Layer-2 address 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 the AR creates a route to the delegated address/
prefix then relays the reply to the MN. The MN now knows that it has
received a unique IP address delegation and knows that the MAP and AR
have established the correct route and address delegation cache
state. Moreover, the MN can change to a new primary AR as network
conditions require and can immediately inform the MAP of the change.
The following figure presents a message exchange diagram that
outlines this model of operation:
Templin, et al. Expires December 23, 2006 [Page 5]
Internet-Draft Localized Mobility Management using DHCP June 2006
MN AR MAP
| | |
| Router Advertisement | |
|<-----------------------| |
| DHCP Request | |
|----------------------->| Relayed DHCP Request |
| |---------------------->| create route
| | DHCP Reply | to MN via AR
| Relayed DHCP Reply |<----------------------|
|<-----------------------| create route |
| | to MN |
...
| | |
| | | data packet
| | Tunneled Packet | for MN
| Forwarded Packet |<======================|
|<-----------------------| |
Figure 2: Message Exchange Diagram
4. Functional Specification
The following subsections specify operation of MNs, ARs and MAPs in
support of address/prefix configuration and localized mobility
management. Items marked with (*) denote functions that are
specified only in this document (see: Section 4.4):
4.1. Mobile Node (MN) Operation
When an MN first powers on, activates a network interface or when it
receives an indication of link change and/or movement to a new LMMD,
it discovers ARs via standard ICMP Router Solicitation (RS) and
Router Advertisement (RA) messages per [RFC1256] (IPv4) or [RFC2461]
(IPv6). Mechanisms for detection of network attachment (DNA) for
IPv4 [RFC4436] or IPv6 [I-D.ietf-dna-protocol] can also be used to
more quickly detect and respond to AR changes. After the MN receives
RAs from one or more AR, it selects one or more ARs as default
routers.
After the MN discovers ARs, it requests IP address delegations and/or
IP prefix delegations (IPv6-only [RFC3633]) by sending DHCPDISCOVER
(IPv4) or SOLICIT (IPv6) messages. The MN sends the DHCP messages to
the appropriate IP multicast/broadcast address, but it can select
specific ARs by directing the messages to an AR's unicast Layer-2
address (*). To reduce control message overhead, the MN can use the
Rapid Commit option for DHCPv4 [RFC4039] or DHCPv6 [RFC3315] to
enable address assignment with the exchange of just two messages
Templin, et al. Expires December 23, 2006 [Page 6]
Internet-Draft Localized Mobility Management using DHCP June 2006
instead of four.
After address/prefix configuration, the MN issues DHCPREQUEST (IPv4)
or RENEW (IPv6) messages through its primary AR to refresh its
address lease lifetimes as long as it requires continued global IP
addressing services. (For IPv4, the DHCPREQUEST message must be sent
through its primary AR instead of unicast to the DHCP server).
If a primary AR fails (or appears to be failing), the MN can send an
immediate DHCPREQUEST (IPv4), CONFIRM or RENEW (IPv6) message through
a new AR so that the MAP(s) can quickly update IP forwarding tables
(see: Section 4.3).
MNs can send IP packets to off-link destinations using any of the ARs
in their default router list as the next hop.
4.2. Access Router (AR) Operation
ARs send periodic and solicited RAs on their attached access networks
per [RFC1256] (IPv4) or [RFC2461] (IPv6). ARs should send periodic
RAs at small intervals to provide beacons for MNs to quickly discover
nearby ARs and detect AR failures. (The beacon interval should be
determined based on link characteristics of the particular access
network, and possibly also the mechanisms for detection of network
attachment (DNA).) In the IPv6 case, RAs should include either
prefix options with the 'L' bit set to 0 or no prefix options at all.
(If no prefix options are included, MNs can obtain prefixes via DHCP
prefix delegation [RFC3633].)
ARs configure a BOOTP (IPv4) or DHCPv6 (IPv6) relay agent. When an
AR receives an MN's DHCPDISCOVER, DHCPREQUEST (IPv4), SOLICIT,
CONFIRM or RENEW (IPv6) message, it relays the message to one or more
MAPs in the backhaul network. (When the MAP and AR are co-located,
the request is handled by the local DHCP server.) When the AR relays
the request, it writes the IP address of its access network interface
in the BOOTP 'giaddr' field (IPv4) or DHCPv6 'peer-address' field
(IPv6). This means that an AR's access network interfaces must be
provisioned with IP addresses that are injected as host routes into
the backhaul network's intra-domain routing protocol.
When an AR relays a MAP's DHCPACK (IPv4) or REPLY (IPv6) to an MN, it
examines the message for delegated IP addresses/prefixes. If
delegated IP addresses/prefixes are included, the MN creates routes
in its IP forwarding table that associate the delegated IP addresses/
prefixes with the MN's address in the BOOTP 'chaddr' field for DHCPv4
or the 'peer-address' for DHCPv6 (*).
ARs can optionally be configured to participate as a middle party in
Templin, et al. Expires December 23, 2006 [Page 7]
Internet-Draft Localized Mobility Management using DHCP June 2006
MN-to-MAP DHCP exchanges, e.g., so that appropriate policy decisions
can be implemented.
4.3. Mobility Anchor Point (MAP) Operation
The MAP(s) in the backhaul network act as DHCP servers and IP routers
for MNs in access networks. All MAPs within the same LMMD delegate
addresses from a common set of IP subnet prefixes and inject the
prefixes into the backhaul network's intra-domain routing protocol.
When multiple MAPs are present within the same LMMD, they synchronize
state to maintain a consistent view of address delegations and IP
routes.
When a MAP receives a DHCPDISCOVER (IPv4) or SOLICIT (IPv6) message,
it delegates IP address(es)/prefix(es) for the MN. If DHCP four-
message exchange is used, the MAP then returns a DHCPOFFER (IPv4) or
ADVERTISE (IPv6) to the unicast address of the AR found in the BOOTP
'giaddr' field (IPv4) or DHCPv6 'peer-address' field (IPv6) and waits
for the corresponding request from the MN. When the MAP is ready to
commit the address/prefix delegations, it configures a route in its
IP forwarding table and (if necessary) a tunnel interface used for
directing packets destined for the MN to the correct AR (*). The MAP
then returns the DHCPACK (IPv4) or REPLY (IPv6) message to the
unicast address of the AR.
Following DHCP address/prefix delegation and IP route/tunnel
configuration, when a packet destined for an MN arrives at a MAP, the
MAP either: a) encapsulates the packet with the MN's primary AR as
the destination address in the outer header (i.e., tunnels the packet
to the AR), or b) inserts an IPv4 source routing header (likewise
IPv6 routing header) (*) to ensure that the packet will be forwarded
through the MN's primary AR.
The MAP retains address/prefix delegations as long as the MN
continues to refresh the 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 (*). When lease lifetimes
expire, the MAP deletes the cached address/prefix delegations and
their corresponding route/tunnel configurations (*).
4.4. Functions Specified Only in this Document
MNs should tightly couple their DHCP operations with the IP router
discovery process. In particular, MNs that wish to select specific
primary ARs can direct their DHCP messages to an AR's unicast Layer-2
address.
ARs must examine DHCPACK (IPv4) or REPLY (IPv6) messages and create
Templin, et al. Expires December 23, 2006 [Page 8]
Internet-Draft Localized Mobility Management using DHCP June 2006
routes in their IP forwarding tables that associate delegated IP
addresses/prefixes with the MN's address.
MAPs must tightly couple the delegation of IP addresses/prefixes with
the establishment of routes/tunnels in their IP forwarding tables.
Following address/prefix delegation, MAPs must also closely monitor
an MN's DHCP requests to detect changes in ARs and make corresponding
changes to existing IP forwarding table and tunnel entries if
necessary. MAPs may optionally arrange for the insertion of routing
headers in the packets they forward instead of tunneling (e.g., to
reduce tunneling header overhead) but this may result in excessive
TTL/Hop Limit decrementation. Finally MAPs must delete existing IP
forwarding table and tunnel entries when their corresponding IP
address delegations expire.
5. Additional Considerations
5.1. IPv6 Advantages
The one clear and undeniable advantage for IPv6 is its larger address
space. The following additional features of IPv6 may provide
advantages over IPv4 within the NETLMM problem space:
1. IPv6 RAs can carry prefix options for IPv6 stateless address
autoconfiguration [RFC2462] whereas IPv4 RAs only carry the
address(es) of routers. In particular, ARs can advertise IPv6
prefixes with the 'L' bit set to 0 so that MNs can use the
prefixes for address auto-configuration but not on-link
determination.
2. IPv6 MNs can auto-configure addresses from advertised prefixes
and propose them to the MAP's DHCPv6 server instead of allowing
the DHCPv6 server to select addresses. (The DHCPv6 server will
return failure codes for proposed addresses that are duplicates).
This allows IPv6 MNs a degree of control (not available in IPv4)
to configure their own addresses with interface identifiers
created using mechanisms such as CGAs [RFC3972] or privacy
addresses [I-D.ietf-ipngwg-temp-addresses-v2].
3. DHCPv6 provides a prefix delegation mechanism [RFC3633] that can
be used by MNs for acquiring IP prefixes within the LMMD; DHCPv4
does not provide a similar mechanism.
4. MNs can use local addressing for intra-LMMD communications that
do not require backhaul network transit. IPv6 provides a unique
local addressing (ULA) mechanism [RFC4193] which assures a high
probability of uniqueness even when access networks partition and
Templin, et al. Expires December 23, 2006 [Page 9]
Internet-Draft Localized Mobility Management using DHCP June 2006
merge. The local addressing mechanisms provided by IPv4
[RFC1918] [RFC3927] cannot assure high probability of uniqueness.
5. The ARP mechanism used by IPv4 is insecure, while IPv6 Neighbor
Discovery can use the securing mechanisms of SEND [RFC3971].
5.2. ARP/Neighbor Cache Management
In highly dynamic environments, communication failures can result due
to stale IPv4 ARP [RFC0826] (similarly IPv6 Neighbor Discovery
[RFC2461]) cache entries. MNs and ARs must therefore carefully
manage their IPv4 ARP (similarly IPv6 neighbor) caches to quickly
flush stale entries.
5.3. 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].
5.4. Duplicate Address Detection (DAD)
DAD procedures in LMMDs are the same as for any link using the
mechanisms of ARP (IPv4) or IPv6 stateless address autoconfiguration
[RFC2462] (IPv6).
Additionally, a MAP's DHCP server will only delegate IP addresses/
prefixes that are unique within the LMMD and will return error codes
for address collisions.
5.5. Multilink Subnet Considerations
Multilink subnet issues are analyzed in [I-D.thaler-intarea-
multilink-subnet-issues].
When each MN assigns addresses from separate IP prefixes, (e.g., per
[I-D.thaler-autoconf-multisubnet-manets]) there are no multilink
subnet issues.
When multiple MNs assign addresses from a shared IP prefix, multilink
subnet issues can be avoided if ARs and MAPs support a neighbor
discovery proxy capability per [RFC4389].
6. IANA Considerations
ARs are defined as comprising both an IP router and BOOTP/DHCPv6
Templin, et al. Expires December 23, 2006 [Page 10]
Internet-Draft Localized Mobility Management using DHCP June 2006
relay agent function, but backward compatibility for legacy routers
on access networks may be desired (TBD).
If backward compatibility for legacy IPv4 routers is desired, the
"icmp-parameters" registry could define a new code for the ICMPv4 RA
type (type 9) called "BOOTP Relay Agent Present" to be included in
the ICMPv4 RAs sent by ARs but not those sent by legacy routers.
If backward compatibility for legacy IPv6 routers is desired, a new
bit (the 'D' bit) could be defined from the ICMPv6 RA "Reserved"
field. This bit would be set to 1 in ICMPv6 RAs sent by ARs with
DHCPv6 relay agents but not those sent by legacy routers.
7. Security Considerations
Threats relating to NETLMM [I-D.ietf-netlmm-threats] and the security
considerations for DHCP [RFC2131] [RFC3315] apply to this document.
The base DHCPv4 specification [RFC2131] does not specify securing
mechanisms, but DHCPv4 message authentication is specified in
[RFC3118]. ([RFC3315], Section 21) specifies mechanisms for DHCPv6
message authentication.
The ARP mechanism used by IPv4 is insecure, while IPv6 Neighbor
Discovery can use the securing mechanisms of SEND [RFC3971].
8. Related Work
The Mitre MobileMesh approach suggests a serverless backhaul network
with a fully-connected mesh of tunnels between ARs. Telcordia has
proposed DHCP-related solutions for the CECOM MOSAIC program. The
Cisco LAM mechanism operates by injecting host routes for MNs into
the backhaul network's intra-domain routing protocol. Hierarchical
Mobile IPv6 (HMIPv6) has each AR advertise a different IP subnet
prefix on the access network. The IETF NETLMM approach advocates
intelligent ARs for handling mobility and simple MNs that do not get
involved with mobility-related signaling. Various proposals targeted
for the IETF AUTOCONF working group have suggested stateless
mechanisms for address configuration.
9. Acknowledgements
The Naval Research Lab (NRL) Information Technology Division uses
DHCP in their MANET research testbeds. Alexandru Petrescu mentioned
DHCP in NETLMM mailing list discussions.
Templin, et al. Expires December 23, 2006 [Page 11]
Internet-Draft Localized Mobility Management using DHCP June 2006
The following individuals (in chronological order) have provided
valuable input: Marcelo Albuquerque, Thomas Henderson, Wojtek
Furmanski, Long Ho, James Kempf.
10. References
10.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985.
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
10.2. Informative References
[E2E] Salzer, J., Reed, D., and D. Clark, "End-to-end Arguments
in System Design", ACM ToCS , November 1984.
[I-D.ietf-dna-protocol]
Kempf, J., "Detecting Network Attachment in IPv6 Networks
(DNAv6)", draft-ietf-dna-protocol-00 (work in progress),
Templin, et al. Expires December 23, 2006 [Page 12]
Internet-Draft Localized Mobility Management using DHCP June 2006
February 2006.
[I-D.ietf-ipngwg-temp-addresses-v2]
Narten, T., "Privacy Extensions for Stateless Address
Autoconfiguration in IPv6",
draft-ietf-ipngwg-temp-addresses-v2-00 (work in progress),
September 2002.
[I-D.ietf-netlmm-mn-ar-if]
Laganier, J. and S. Narayanan, "Network-based Localized
Mobility Management Interface between Mobile Node and
Access Router", draft-ietf-netlmm-mn-ar-if-00 (work in
progress), April 2006.
[I-D.ietf-netlmm-nohost-ps]
Kempf, J., "Problem Statement for 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-01
(work in progress), April 2006.
[I-D.ietf-netlmm-threats]
Kempf, J. and C. Vogt, "Security Threats to Network-based
Localized Mobility Management",
draft-ietf-netlmm-threats-00 (work in progress),
April 2006.
[I-D.njedjou-netlmm-globalmm-ps]
Njedjou, E. and J. Riera, "Problem Statement for Global IP
Mobility Management", draft-njedjou-netlmm-globalmm-ps-01
(work in progress), May 2006.
[I-D.thaler-autoconf-multisubnet-manets]
Thaler, D., "Multi-Subnet MANETs",
draft-thaler-autoconf-multisubnet-manets-00 (work in
progress), February 2006.
[I-D.thaler-intarea-multilink-subnet-issues]
Thaler, D., "Issues With Protocols Proposing Multilink
Subnets", draft-thaler-intarea-multilink-subnet-issues-00
(work in progress), March 2006.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
Templin, et al. Expires December 23, 2006 [Page 13]
Internet-Draft Localized Mobility Management using DHCP June 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.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for
the Dynamic Host Configuration Protocol version 4
(DHCPv4)", RFC 4039, March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
Appendix A. Nested LMMD Model
The MAP function can be distributed among the ARs if each AR
configures a DHCP server that delegates addresses from its own IP
prefix range that is distinct from the IP prefix ranges delegated by
other ARs. In that case, each MN would receive IP address/prefix
delegations that are relative to their "home" AR and distinct from
the IP addresses/prefixes delegated by other ARs. In other words,
each AR (and its associated MNs) appears as a nested LMMD within a
larger encompassing LMMD.
In this scenario, each AR configures a DHCP server that delegates IP
addresses/prefixes from an IP prefix range that is distinct from
other ARs. Each AR also advertises reachability to its IP prefix
range via the intra-domain routing protocol on the backhaul network,
and configures an IP address for itself from the prefix range, e.g.,
'2001:DB8::1'.
Templin, et al. Expires December 23, 2006 [Page 14]
Internet-Draft Localized Mobility Management using DHCP June 2006
When an MN first enters a LMMD, it discovers a home AR (based on IP
router advertisements) and sends DHCPDISCOVER (IPv4) or SOLICIT
(IPv6) messages to the IP unicast address of the AR to request an IP
address/prefix delegation. After the MN receives IP address/prefix
delegations, it sends periodic DHCPREQUEST (IPv4) or RENEW (IPv6)
messages to the unicast address of the primary AR to refresh its
address/prefix lease lifetimes as long as it requires continued
global IP addressing services.
If the MN loses its connection with its home AR, it selects a
"visited" AR and sends an immediate DHCPREQUEST (IPv4), CONFIRM or
RENEW (IPv6) message through the visited AR. The DHCP entity on the
visited AR will note that the MNs address is delegated from a
different IP prefix range within the LMMD and will relay the request
to the IP address of the MNs home AR, e.g., '2001:DB8::1". This
implies that the DHCP entity on the visited AR must act as a hybrid
relay/server.
When the home AR (acting as a MAP) receives the relayed request, it
notes the address of the relaying AR from the BOOTP 'giaddr' field or
the DHCPv6 'peer-address' field then configures a route in its IP
forwarding table and (if necessary) a tunnel interface used for
directing packets destined for the MN to the visited AR. After the
route is configured, the MAP returns a DHCPOFFER (IPv4) or ADVERTISE
(IPv6) (or, when rapid commit is used, a DHCPACK (IPv4) or REPLY
(IPv6)) to the visited AR. (In other words, the home AR performs the
same function that a centralized MAP would ordinarily perform on
behalf of MNs that are away from home.)
In this model, failure of an AR would result in IP readdressing and
dropped calls for MNs that associated with the failed AR. Such
failure cases can possibly be mitigated by supporting functions in
the backhaul network (TBD).
Also in this model, all ARs within the LMMD must delegate IP
addresses/prefixes from prefix ranges that are covered by the IP
prefix served by the aggregated LMMD. For example, the aggregated
LMMD could serve the prefix '2001:DB8::/48', and ARs within the LMMD
could serve subordinate prefixes such as '2001:DB8::/56', '2001:DB8:
0:100::/56', etc. In other words, the ARs represent nested LMMDs
within the aggregated LMMD.
Appendix B. Control Message Loss Implications for NETLMM
When the MN uses multicast IPv6 Neighbor Solicitation (NS) messages
for duplicate address detection (DAD) to implicitly trigger address
registration signaling between the AR and the MAP, message loss can
Templin, et al. Expires December 23, 2006 [Page 15]
Internet-Draft Localized Mobility Management using DHCP June 2006
cause the MN to incorrectly conclude that its tentative address was
both unique and successfully registered with the MAP. When the MN
uses multicast (IPv6) or broadcast (IPv4) DHCP messages to explicitly
trigger address registration, message loss can cause the MN to retry
until a DHCP reply is received. To avoid issues related to
multicast/broadcast control message loss, the MN can direct its
NS(DAD) and/or DHCP messages to the unicast Layer-2 address of a
specific AR.
Appendix C. Change Log
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 December 23, 2006 [Page 16]
Internet-Draft Localized Mobility Management using DHCP June 2006
Authors' Addresses
Fred L. Templin
Boeing Phantom Works
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: fred.l.templin@boeing.com
Steven W. Russet
Boeing Phantom Works
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: steven.w.russert@boeing.com
Ian D. Chakeres
Boeing Phantom Works
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: ian.chakeres@gmail.com
Seung Yi
Boeing Phantom Works
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: seung.yi@boeing.com
Templin, et al. Expires December 23, 2006 [Page 17]
Internet-Draft Localized Mobility Management using DHCP June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Templin, et al. Expires December 23, 2006 [Page 18]