Network Working Group F. Templin
Internet-Draft S. Russert
Expires: November 4, 2006 I. Chakeres
Boeing Phantom Works
May 3, 2006
Autoconfiguration and Network Localized Mobility Management using DHCP
draft-templin-autoconf-netlmm-dhcp-00.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 November 4, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Mobile nodes that require global Internet access must have a way to
automatically configure globally routable and unique IP addresses
that remain stable across localized mobility events. This document
specifies mechanisms for address autoconfiguration (AUTOCONF) and
network localized mobility management (NETLMM) based on the Dynamic
Host Configuration Protocol (DHCP). Solutions for both IPv4 and IPv6
are given.
Templin, et al. Expires November 4, 2006 [Page 1]
Internet-Draft Autoconf, Mobility Management and DHCP May 2006
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. Non-Standard Behavior . . . . . . . . . . . . . . . . . . 8
5. Additional Considerations . . . . . . . . . . . . . . . . . . 9
5.1. IP Version Differences . . . . . . . . . . . . . . . . . . 9
5.2. ARP/Neighbor Cache Management . . . . . . . . . . . . . . 10
5.3. Global Mobility Management . . . . . . . . . . . . . . . . 10
5.4. Duplicate Address Detection (DAD) . . . . . . . . . . . . 10
5.5. Multi-link Subnet Considerations . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Templin, et al. Expires November 4, 2006 [Page 2]
Internet-Draft Autoconf, Mobility Management and DHCP May 2006
1. Introduction
Access networks (e.g., campus LANs, cellular wireless, WiFi, MANETs,
etc.) that connect nodes to the Internet may be prone to disturbances
such as congestion, signal intermittence, node movements, partitions/
merges, equipment failure, etc. From a node's point of view, these
disturbances appear as mobility events that may cause its default
access router connection to fail or degrade, i.e., the node appears
to be mobile with respect to the access network. Such mobile nodes
therefore require a means to quickly select another access router as
network conditions change. Moreover, a mobile node requires a means
to procure unique and globally routable IP addresses that remain
stable even if its default access router changes. This can be
accomplished when access routers connect mobile nodes to the Internet
via stable backhaul networks with mobility anchor points that
delegate IP addresses and maintain mobile node to access router
mappings.
Mobile nodes, access routers and mobility anchor points can use the
Bootstrap Protocol (BOOTP) [RFC0951] and Dynamic Host Configuration
Protocol (DHCPv4) [RFC2131] for IPv4 (or DHCPv6 [RFC3315] for IPv6)
as well as the associated mechanisms specified in this document to
provision globally routable and unique IP addresses that remain
stable within a localized mobility management domain.
Using these mechanisms, the mobile node selects a specific primary
access router among possibly many candidates on the link thereby
minimizing control message overhead and eliminating ambiguity. In
particular, the mobile node is uniquely qualified to select the best
access router among possibly many candidates and is also uniquely
qualified to determine when it should change to a new access router.
Additionally, the mobile node receives positive/negative confirmation
that the correct IP address delegations and route/tunnel state have
been registered with the mobility anchor point such that black holes
will not occur.
The model of operation described in this document corresponds to that
proposed for the IETF Network Localized Mobility Management (NETLMM)
working group [I-D.ietf-netlmm-nohost-ps] [I-D.ietf-netlmm-nohost-
req]. Solutions for both IPv4 [RFC0791] and IPv6 [RFC2460] are
given.
2. Terminology
The terminology in the normative references apply; the following
terms are defined within the scope of this document:
Templin, et al. Expires November 4, 2006 [Page 3]
Internet-Draft Autoconf, Mobility Management and DHCP May 2006
link
the same as defined in ([RFC2461], Section 2.1).
access network
a link that connects Mobile Nodes and Access Routers and may be
subject to congestion, signal intermittence, node movements,
network partitions/merges, equipment failure, etc.
backhaul network
a network that connects Access Routers and Mobility Anchor
Point(s) and also connects the Localized Mobility Management
Domain to the global Internet.
Mobile Node (MN)
a node on an access network that also acts as a DHCP client.
Access Router (AR)
a router that connects access networks to a backhaul network and
also acts as a DHCP/BOOTP relay agent.
Mobility Anchor Point (MAP)
a backhaul network router (and its associated DHCP server) that
aggregates IP prefixes in a Localized Mobility Management Domain.
Localized Mobility Management Domain (LMMD)
a set of MAPs (and their associated ARs and MNs) that provision
addresses from the same IP subnet prefix(es).
3. Model of Operation
The Dynamic Host Configuration Protocol (DHCP) has seen significant
operational experience in fielded deployments. Using the DHCP-based
mechanisms specified in Section 4, MNs on access networks can send
DHCP requests via ARs to MAPs in the backhaul network to configure
global IP addresses and establish MN->AR routes/tunnels in MAP IP
forwarding tables. Moreover, these mechanisms allow MNs to retain
their global IP addresses even if they change ARs within the LMMD.
The following figure provides a reference diagram for the DHCP-based
network localized mobility management solution space:
Templin, et al. Expires November 4, 2006 [Page 4]
Internet-Draft Autoconf, Mobility Management and DHCP May 2006
/-------------------------\
/ Internet \
\ /
\-------+---------+-------/
| |
/-------+---------+-------\
/ Backhaul \
/ Network \
- - | - - - - - - - - - - - - - - | - - -
| +-----+ |
| | MAP |-+ |
| +-----+ |-+ |
| +-----+ | |
| +-----+ |
\ /
\ +-----+ +-----+ /
\--| AR1 |--...--| ARn |--/
+-----+ +-----+
/ \ / \
/ \ / \
/ \ / \ Access
- - - - /- - - -\- - -/ - - - \ - - - - -
/ \ / \ Network
+----+
| MN | ------->
+----+ AR change
Figure 1: Reference Network Diagram
Using the mechanisms specified in Section 4, a MN discovers ARs via
standard IP router discovery and selects a primary AR. The MN then
send a unicast DHCP request to the primary AR which relays the
request to a MAP. The MAP delegates an IP address for the MN and
also creates a route/tunnel to the MN via the primary AR. The MAP
then sends a DHCP reply to the MN via the primary AR, and the AR
relays the reply to the MN. The MN now knows that it has received a
unique IP address delegation and knows that the MAP has established
the correct route and address delegation cache state. Moreover, the
MN can change to a new primary AR as network conditions require and
can immediately inform the MAP of the change. The following figure
presents a message exchange diagram that outlines this model of
operation:
Templin, et al. Expires November 4, 2006 [Page 5]
Internet-Draft Autoconf, Mobility Management and DHCP May 2006
MN AR MAP
| | |
| Router Advertisement | |
|<-----------------------| |
| DHCP Request | |
|----------------------->| Relayed DHCP Request |
| |---------------------->| create route
| | DHCP Reply | to MN via AR
| Relayed DHCP Reply |<----------------------|
|<-----------------------| |
| | |
...
| | |
| | | data packet
| | Tunneled Packet | for MN
| Forwarded Packet |<======================|
|<-----------------------| |
Figure 2: Message Exchange Diagram
4. Functional Specification
The following subsections specify operation of MNs, ARs and MAPs in
support of address configuration and localized mobility management.
Items marked with (*) denote non-standard behavior that is specified
only in this document (see: Section 4.4):
4.1. Mobile Node (MN) Operation
MNs discover ARs via standard ICMP Router Solicitation (RS) and
Router Advertisement (RA) messages per [RFC1256] (IPv4) or [RFC2461]
(IPv6). Mechanisms for detection of network attachment for IPv4
[RFC4436] or IPv6 [I-D.ietf-dna-protocol] can also be used to more
quickly detect and respond to AR changes.
When a MN first powers on, activates a network interface or when it
receives an indication of link change or movement to a new LMMD, it
uses standard mechanisms to receive RAs from nearby ARs and (if none
are heard) send a small number of RSs to elicit immediate RAs. After
the MN receives RAs from one or more AR, it selects one or more ARs
as default routers and selects one AR as its primary default router.
After the MN discovers ARs, it requests IP address delegations and/or
IP prefix delegations (IPv6-only [RFC3633]) by sending DHCPDISCOVER
(IPv4) or Solicit (IPv6) messages to the IP unicast address of the
primary AR (*). To reduce control message overhead, the MN can use
the Rapid Commit option for DHCPv4 [RFC4039] or DHCPv6 [RFC3315] to
Templin, et al. Expires November 4, 2006 [Page 6]
Internet-Draft Autoconf, Mobility Management and DHCP May 2006
enable address assignment with the exchange of just two messages
instead of four.
When the MN receives IP address/prefix delegations, it should
configure the addresses/prefixes on a loopback interface so that
changes between different access technologies can be easily
accommodated.
After address/prefix configuration, the MN issues DHCPREQUEST (IPv4),
Confirm or Renew (IPv6) messages to the unicast address of the
primary AR (*) to refresh its address lease lifetimes as long as it
requires continued global IP addressing services.
If the MN's primary AR fails (or appears to be failing), the MN
selects a new primary AR and sends an immediate DHCPREQUEST (IPv4),
Confirm or Renew (IPv6) message to the unicast address of the new
primary AR (*) so that the MAP(s) can quickly update their IP
forwarding tables (see: Section 4.3).
MNs can send IP packets to off-link destinations using any of the ARs
in their default router list as the next hop. Packets sent to
destinations with the same IP prefix as the source should be sent to
the primary AR as a next hop. This allows packets exchanged by a
pair of MNs that are both located behind the same AR to remain on the
local access network without having to pass through the backhaul
network and/or a MAP.
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.) In the IPv6 case, the RAs sent by ARs should also include
prefix options with the 'L' bit set to 0 for advertisement of IPv6
prefixes owned by the MAP(s).
ARs configure a BOOTP (IPv4) or DHCPv6 (IPv6) relay agent. When an
AR receives a MN's DHCPDISCOVER, DHCPREQUEST (IPv4), Solicit, Confirm
or Renew (IPv6) message, it relays the request to one or more MAPs in
the backhaul network. (When the MAP and AR are co-located, the
request is handled by the local DHCP server.) When the AR relays the
request, it writes the IP address of its access network interface in
the BOOTP 'giaddr' field (IPv4) or DHCPv6 'peer-address' field
(IPv6). This means that an AR's access network interfaces must be
provisioned with IP addresses that are injected as host routes into
the backhaul network's intra-domain routing protocol. ARs must also
Templin, et al. Expires November 4, 2006 [Page 7]
Internet-Draft Autoconf, Mobility Management and DHCP May 2006
be provisioned with the IP address(es) of the MAP(s).
ARs can optionally be configured to participate as a middle party in
MN-to-MAP DHCP exchanges, e.g., so that appropriate policy decisions
can be implemented.
4.3. Mobility Anchor Point (MAP) Operation
The MAP(s) in the backhaul network act as DHCP servers and IP routers
for MNs in access networks. All MAPs within the same LMMD delegate
addresses from a common set of IP subnet prefixes and inject the
prefixes into the backhaul network's intra-domain routing protocol.
When multiple MAPs are present within the same LMMD, they synchronize
state over the backhaul network to maintain a consistent view of
address delegations and IP routes.
When a MAP receives a DHCPDISCOVER (IPv4) or Solicit (IPv6) message
that was relayed by an AR, it delegates an IP address for the MN.
(Optionally in IPv6, the MAP can delegate IP prefixes for the MN to
be further sub-delegated to its associated hosts.) After the MAP
delegates an IP address/prefix, it notes the unicast address of the
AR from either the BOOTP 'giaddr' field (IPv4) or the DHCPv6 'peer-
address' field (IPv6) then configures a route in its IP forwarding
table and (if necessary) a tunnel interface used for directing
packets destined for the MN to the correct AR (*). After the route
is configured, the MAP returns a DHCPOFFER (IPv4) or Advertise (IPv6)
to the unicast address of the AR. If Rapid Commit is in use, the MAP
instead returns an immediate DHCPACK (IPv4) or Reply (IPv6).
Following DHCP address delegation and IP route/tunnel configuration,
when a packet destined for a MN arrives at a MAP, the MAP either: a)
encapsulates the packet with the MN's primary AR as the destination
address in the outer header (i.e., tunnels the packet to the AR), or
b) inserts an IPv4 source routing header (likewise IPv6 routing
header) (*) to ensure that the packet will be forwarded through the
MN's primary AR.
The MAP retains address/prefix delegations and route/tunnel
configurations as long as the MN continues to use the same primary AR
and continues to refresh the lease lifetimes. When the MN 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. Non-Standard Behavior
MNs must tightly couple their DHCP operations with the IP router
Templin, et al. Expires November 4, 2006 [Page 8]
Internet-Draft Autoconf, Mobility Management and DHCP May 2006
discovery process. In particular, MNs must send their DHCP requests
to the unicast address(es) of ARs discovered in RAs. Also, in order
to support mobility, MNs must send immediate DHCP requests whenever
they change to a new primary AR in order to update route/tunnel
entries on the MAP.
MAPs must tightly couple the delegation of IP addresses/prefixes with
the establishment of routes/tunnels in their IP forwarding tables.
Following address/prefix delegation, MAPs must also closely monitor a
MN's DHCP requests to detect changes in ARs and make corresponding
changes to existing IP forwarding table and tunnel entries if
necessary. MAPs may optionally arrange for the insertion of routing
headers in the packets they forward instead of tunneling (e.g., to
reduce tunneling header overhead) but should note that this may
result in excessive TTL/Hop Limit decrementation. Finally MAPs must
delete existing IP forwarding table and tunnel entries when their
corresponding IP address delegations expire.
5. Additional Considerations
5.1. IP Version Differences
IPv6 RAs can carry prefix options for IPv6 stateless address
autoconfiguration [RFC2462] whereas IPv4 RAs only carry the
address(es) of routers. In the IPv6 case, all ARs in the LMMD can
advertise the same IPv6 prefixes on their attached access networks
with the 'L' bit set to 0 so that MNs can use the prefixes for
address auto-configuration but not on-link determination.
IPv6 MNs can auto-configure addresses from advertised prefixes and
propose them to the MAP's DHCPv6 server instead of allowing the
DHCPv6 server to select addresses. (The DHCPv6 server will return
failure codes for proposed addresses that are duplicates). This
allows IPv6 MNs a degree of control (not available in IPv4) to
configure their own addresses with interface identifiers created
using mechanisms such as CGAs [RFC3972] or privacy addresses
[I-D.ietf-ipngwg-temp-addresses-v2].
MNs must quickly detect movement between different LMMDs. In IPv6,
the MN will see a different set of IP prefixes in RAs when it moves
from one LMMD to another. In IPv4, the MN can only detect movement
to a different LMMD based on DHCPREQUEST failures when it attempts to
update its address lifetimes (since DHCPv4 servers in different LMMDs
will manage different sets of IP addresses).
DHCPv6 provides a prefix delegation mechanism [RFC3633] that can be
used for assigning IP prefixes for subnets within access networks;
Templin, et al. Expires November 4, 2006 [Page 9]
Internet-Draft Autoconf, Mobility Management and DHCP May 2006
DHCPv4 does not provide a similar mechanism.
MNs can use local addressing for intra-access network communications
that do not require backhaul network transit. IPv6 provides a unique
local addressing (ULA) mechanism [RFC4193] which assures a high
probability of uniqueness when access networks partition and merge.
The local addressing mechanisms provided by IPv4 [RFC1918] [RFC3927]
cannot assure high probability of uniqueness.
5.2. ARP/Neighbor Cache Management
In highly dynamic environments, communication failures can result due
to stale IPv4 ARP [RFC0826] (similarly IPv6 Neighbor Discovery
[RFC2461]) cache entries. MNs and ARs must therefore carefully
manage their IPv4 ARP (similarly IPv6 neighbor) caches to quickly
flush stale entries. Note that this is also true for the NETLMM
approach.
5.3. Global Mobility Management
When a MN leaves a LMMD and enters a new LMMD, its global IP
addresses are no longer topologically correct and global mobility
management mechanisms are needed. Currently available global
mobility mechanisms for IPv6 include MIPv6, HIP and MobIKE, while
MIPv4 is available for IPv4. A problem statement for global IP
mobility management is given in [I-D.njedjou-netlmm-globalmm-ps].
5.4. Duplicate Address Detection (DAD)
DAD procedures in LMMDs are the same as for any link using the
mechanisms of ARP (IPv4) or IPv6 stateless address autoconfiguration
[RFC2462] (IPv6).
Additionally, a MAP's DHCP server will only delegate IP addresses/
prefixes that are unique within the LMMD and will return error codes
for address collisions.
5.5. Multi-link Subnet Considerations
The model of operation proposed by this document (and by NETLMM)
constitutes a multi-link subnet in the MAP->MN direction but not in
the MN->Internet direction. In particular, packets destined for a MN
via the MAP have their IPv4 TTL (likewise IPv6 Hop Limit) decremented
at least once for the path between the MAP and AR and an additional
time for the link between the AR and the MN. Future versions of this
document will investigate a neighbor discovery proxy approach
[RFC4389] to avoid multi-link subnet issues (see: [I-D.thaler-
intarea-multilink-subnet-issues]).
Templin, et al. Expires November 4, 2006 [Page 10]
Internet-Draft Autoconf, Mobility Management and DHCP May 2006
6. IANA Considerations
ARs are defined as comprising both an IP router and BOOTP/DHCPv6
relay agent function, but backward compatibility for legacy routers
on access networks may be desired (TBD).
If backward compatibility for legacy IPv4 routers is needed, the
"icmp-parameters" registry could define a new code for the ICMPv4 RA
type (type 9) called "BOOTP Relay Agent Present" to be included in
the ICMPv4 RAs sent by ARs but not those sent by legacy routers.
If backward compatibility for legacy IPv6 routers is needed, a new
bit (the 'D' bit) could be defined from the ICMPv6 RA "Reserved"
field. This bit would be set to 1 in ICMPv6 RAs sent by ARs with
DHCPv6 relay agents but not those sent by legacy routers.
7. Security Considerations
Threats relating to NETLMM [I-D.ietf-netlmm-threats] and the security
considerations for DHCP [RFC2131] [RFC3315] apply to this document.
The base DHCPv4 specification [RFC2131] does not specify securing
mechanisms, but DHCPv4 message authentication is specified in
[RFC3118]. The base DHCPv6 specification [RFC3315] includes
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. 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
Templin, et al. Expires November 4, 2006 [Page 11]
Internet-Draft Autoconf, Mobility Management and DHCP May 2006
DHCP in their MANET research testbeds. Alexandru Petrescu mentioned
DHCP in NETLMM mailing list discussions.
The following individuals (in chronological order) have provided
valuable input: Marcelo Albuquerque, Thomas Henderson, Seung Yi.
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
[I-D.ietf-dna-protocol]
Kempf, J., "Detecting Network Attachment in IPv6 Networks
(DNAv6)", draft-ietf-dna-protocol-00 (work in progress),
February 2006.
Templin, et al. Expires November 4, 2006 [Page 12]
Internet-Draft Autoconf, Mobility Management and DHCP May 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-nohost-ps]
Kempf, J., "Problem Statement for IP Local Mobility",
draft-ietf-netlmm-nohost-ps-01 (work in progress),
April 2006.
[I-D.ietf-netlmm-nohost-req]
Kempf, J., "Goals for Network-based Localized Mobility
Management (NETLMM)", draft-ietf-netlmm-nohost-req-01
(work in progress), April 2006.
[I-D.ietf-netlmm-threats]
Kempf, J. and C. Vogt, "Security Threats to Network-based
Localized Mobility Management",
draft-ietf-netlmm-threats-00 (work in progress),
April 2006.
[I-D.njedjou-netlmm-globalmm-ps]
Njedjou, E. and J. Riera, "Problem Statement for Global IP
Mobility Management", draft-njedjou-netlmm-globalmm-ps-01
(work in progress), May 2006.
[I-D.thaler-intarea-multilink-subnet-issues]
Thaler, D., "Issues With Protocols Proposing Multilink
Subnets", draft-thaler-intarea-multilink-subnet-issues-00
(work in progress), March 2006.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Templin, et al. Expires November 4, 2006 [Page 13]
Internet-Draft Autoconf, Mobility Management and DHCP May 2006
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.
Templin, et al. Expires November 4, 2006 [Page 14]
Internet-Draft Autoconf, Mobility Management and DHCP May 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
Templin, et al. Expires November 4, 2006 [Page 15]
Internet-Draft Autoconf, Mobility Management and DHCP May 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 November 4, 2006 [Page 16]