Network Working Group F. Templin Internet-Draft S. Russert Expires: December 4, 2006 I. Chakeres S. Yi Boeing Phantom Works June 2, 2006 Network Localized Mobility Management using DHCP draft-templin-autoconf-netlmm-dhcp-01.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 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 Templin, et al. Expires December 4, 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. Multi-link Subnet Considerations . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. Nested LMMD Model . . . . . . . . . . . . . . . . . . 14 Appendix B. Control Message Loss Implications for NETLMM . . . . 16 B.1. Implications for Network-Based Signaling . . . . . . . . . 16 B.2. Implications for Host-based Signaling . . . . . . . . . . 17 B.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix C. Changes since -00 . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Templin, et al. Expires December 4, 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 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 thereby minimizing control message overhead and eliminating ambiguity. In particular, the mobile node is uniquely qualified to select the best primary access router among possibly many candidates and is also uniquely qualified to determine when it should change to a new primary access router. Additionally, the mobile node receives positive/negative confirmation that the correct IP address delegations and route/tunnel state have been registered within the localized mobility management domain such that communication failures due to black holes, address duplications, etc., 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 December 4, 2006 [Page 3] Internet-Draft Localized Mobility Management using DHCP June 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 December 4, 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, 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 December 4, 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 |<----------------------| |<-----------------------| | | | | ... | | | | | | 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 functions that are 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 (DNA) 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 neighboring 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 Templin, et al. Expires December 4, 2006 [Page 6] Internet-Draft Localized Mobility Management using DHCP June 2006 the Rapid Commit option for DHCPv4 [RFC4039] or DHCPv6 [RFC3315] to enable address assignment with the exchange of just two messages instead of four. 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. 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, 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 be provisioned with the IP address(es) of the MAP(s). When an AR relays a MAP's DHCPACK (IPv4) or Reply (IPv6) to a 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) (*). Templin, et al. Expires December 4, 2006 [Page 7] Internet-Draft Localized Mobility Management using DHCP June 2006 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 to maintain a consistent view of address delegations and IP routes. When a MAP receives a DHCPDISCOVER (IPv4) or Solicit (IPv6) message, 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 signals a change 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 must tightly couple their DHCP operations with the IP router discovery process. In particular, MNs must send their DHCP requests to the unicast address(es) of ARs discovered in RAs. Also, in order Templin, et al. Expires December 4, 2006 [Page 8] Internet-Draft Localized Mobility Management using DHCP June 2006 to support mobility, MNs must send immediate DHCP requests whenever they change to a new primary AR as a signal for MAPs to update their route/tunnel entries. ARs must examine DHCPACK (IPv4) or Reply (IPv6) messages and create 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 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. IPv6 Advantages 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 tries to connect to a new AR (since DHCPv4 servers in different LMMDs will manage different sets of IP addresses). Templin, et al. Expires December 4, 2006 [Page 9] Internet-Draft Localized Mobility Management using DHCP June 2006 DHCPv6 provides a prefix delegation mechanism [RFC3633] that can be used for assigning IP prefixes for subnets within access networks; 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 even 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 once as they are forwarded by the MAP, possibly additional times as they are forwarded along the MAP->AR path, and once as they are forwarded by the AR. Templin, et al. Expires December 4, 2006 [Page 10] Internet-Draft Localized Mobility Management using DHCP June 2006 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]). 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]. ([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 Templin, et al. Expires December 4, 2006 [Page 11] Internet-Draft Localized Mobility Management using DHCP June 2006 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. The following individuals (in chronological order) have provided valuable input: Marcelo Albuquerque, Thomas Henderson, Wojtek Furmanski, Long Ho. 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. Templin, et al. Expires December 4, 2006 [Page 12] Internet-Draft Localized Mobility Management using DHCP June 2006 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), 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 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. Templin, et al. Expires December 4, 2006 [Page 13] Internet-Draft Localized Mobility Management using DHCP June 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 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 Templin, et al. Expires December 4, 2006 [Page 14] Internet-Draft Localized Mobility Management using DHCP June 2006 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'. When a 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), 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 loses its connection with its home AR, it selects a "visited" AR and sends an immediate DHCPREQUEST (IPv4), Confirm or Renew (IPv6) message to the unicast address of 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) to the unicast address of 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. Templin, et al. Expires December 4, 2006 [Page 15] Internet-Draft Localized Mobility Management using DHCP June 2006 Appendix B. Control Message Loss Implications for NETLMM [I-D.ietf-netlmm-mn-ar-if] specifies a network-based mechanism that uses a MN's duplicate address detection procedure to implicitly trigger address registration signaling between the AR and the MAP, while this document specifies a host-based mechanism that uses a MNs DHCP requests to explicitly trigger address registration signaling between the MN and the MAP. Control message loss implications for both scenarios are analyzed in the following sections: B.1. Implications for Network-Based Signaling In the network-based signaling method specified in [I-D.ietf-netlmm- mn-ar-if], if the MN configures a tentative address and sends a Neighbor Solicitation (NS) message to the solicited-node multicast address (see: [RFC2462], Section 5.4.2), but a control message is lost somewhere on the MN<->AR<->MAP paths, the MN could incorrectly conclude that its tentative address was both unique and successfully registered with the MAP. The following scenarios can occur: 1. If the MN's multicast NS message is lost on the MN->AR path, the AR will not perform address registration and the MN will receive no indication that address registration failed. The MN will then incorrectly assign the tentative address to an interface after RetransTimer msecs (see: [RFC2462], Section 5.4). 2. If the AR attempts to register a MN's tentative address with the MAP and the MAP returns an indication that the address was a duplicate, the AR will defend the MN's tentative address by sending a Neighbor Advertisement (NA) message to the all-nodes multicast address on the AR->MN path as specified in ([RFC2461], Section 7.2.4). But, if the NA message is lost, the MN will incorrectly assign the tentative address to an interface after RetransTimer msecs. 3. If a control message is lost on the AR<->MAP paths, the AR can assume loss after a timeout period and retry the registration until an acknowledgement is received. If the retries are not completed within RetransTimer msecs and the address registration fails (due to address duplication and/or excessive retries), the MN will incorrectly assign the tentative address to an interface. One possible mitigation is for the MN to set DupAddrDetectTransmits (see: [RFC2462], Section 5.4) to some value greater than 1 at the expense of extra control message overhead and extra delay, but this mitigation can fail when more than DupAddrDetectTransmits control messages are lost. A complementary mitigation is for the AR to set its retry timer to some value smaller than RetransTimer/N (where N is Templin, et al. Expires December 4, 2006 [Page 16] Internet-Draft Localized Mobility Management using DHCP June 2006 the desired number of retries) and/or for the MN to set RetransTimer to some value larger than the default of 1000 msecs. But, since the MN<->AR<->MAP paths may be carried over links with arbitrarily-long delays, selecting appropriate timer values may be problematic in some use cases. Also, this mitigation can fail when a NS/NA message is lost on the MN<->AR paths. Finally, the network could attempt a "just-in-time" registration for a MN that sends packets without previously registering its address but such mitigations could be susceptible to security and robustness-related issues. B.2. Implications for Host-based Signaling In the DHCP-based MN-driven case specified in this document, if a control message is lost on the MN<->AR<->MAP paths, the MN will retry the DHCP request until a DHCP reply is received. If excessive failures occur and the MN abandons its efforts, the DHCP server may have created useless address delegation state that will expire after the lease lifetime expires but the MN will not incorrectly assign an address to an interface. The MN is also free to try again using different ARs which should lead to successful address registration and acknowledgement. DHCPv4 requests encode a Transaction ID ('xid') used by the client to match incoming messages with pending requests, and ([RFC2131], Section 4.1) states that: "Selecting a new 'xid' for each retransmission is an implementation decision. A client may choose to reuse the same 'xid' or select a new 'xid' for each retransmitted message.". DHCPv6 requests likewise encode a Transaction ID ('transaction-id'), but ([RFC3315], Section 15.1) states that: "A client MUST leave the transaction ID unchanged in retransmissions of a message.". So, for MNs that implement a DHCPv4 client that selects a new 'xid' for each retransmission, address registration may fail even after successive retries if the delay across the MN<->AR<->MAP paths is longer than the retransmission time. For MNs that implement a DHCPv4/DHCPv6 client that uses the same Transaction ID for successive retries, address registration should succeed since any DHCP reply will complete the (retransmitted) DHCP request. B.3. Summary The network-based signaling mechanisms specified in [I-D.ietf-netlmm- mn-ar-if] leave opportunity for the MN to incorrectly assign an address to an interface, while the host-based signaling mechanisms specified in this document do not. Therefore, applicability of the network-based model must be carefully analyzed for specific use cases and compared against MN complexity in the host-based method. Templin, et al. Expires December 4, 2006 [Page 17] Internet-Draft Localized Mobility Management using DHCP June 2006 Appendix C. Changes since -00 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 4, 2006 [Page 18] 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 4, 2006 [Page 19] 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 4, 2006 [Page 20]