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]