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]