Network Working Group F. Templin, Ed. Internet-Draft S. Russert, Ed. Intended status: Standards Track Boeing Phantom Works Expires: March 26, 2007 K. Grace, Ed. MITRE September 22, 2006 Network Localized Mobility Management using DHCP draft-templin-autoconf-netlmm-dhcp-03.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 March 26, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Mobile nodes require a means to automatically configure globally routable IP addresses/prefixes that remain stable across localized mobility events. This document specifies mechanisms for network localized mobility management (NETLMM) using the Dynamic Host Configuration Protocol (DHCP). Solutions for both IPv4 and IPv6 are given. Templin, et al. Expires March 26, 2007 [Page 1] Internet-Draft Localized Mobility Management using DHCP September 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Model of Operation . . . . . . . . . . . . . . . . . . . . . . 4 5. Functional Specification . . . . . . . . . . . . . . . . . . . 7 5.1. Mobile Node (MN) Specification . . . . . . . . . . . . . . 7 5.2. Access Router (AR) Specification . . . . . . . . . . . . . 7 5.3. Mobility Anchor Point (MAP) Specification . . . . . . . . 8 5.4. Classless Static Route option . . . . . . . . . . . . . . 9 5.5. Reconfigure Message option . . . . . . . . . . . . . . . . 11 5.6. Use of RAAN Options for DHCPv6 . . . . . . . . . . . . . . 11 6. Additional Considerations . . . . . . . . . . . . . . . . . . 12 6.1. IPv6 Advantages . . . . . . . . . . . . . . . . . . . . . 12 6.2. Global Mobility Management . . . . . . . . . . . . . . . . 12 6.3. Multilink Subnet Considerations . . . . . . . . . . . . . 12 6.4. Support for MNs that use SLAAC . . . . . . . . . . . . . . 13 7. RFC Editor Notes . . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 13.2. Informative References . . . . . . . . . . . . . . . . . . 16 Appendix A. Nested LMMD Model . . . . . . . . . . . . . . . . . . 17 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Templin, et al. Expires March 26, 2007 [Page 2] Internet-Draft Localized Mobility Management using DHCP September 2006 1. Introduction Access networks (e.g., campus LANs, cellular wireless, WiFi, MANETs, etc.) may be prone to congestion, signal intermittence, node movements, partitions/merges, equipment failure, etc. From a node's viewpoint, these disturbances appear as mobility events that cause communications to fail or degrade, i.e., the node appears to be mobile with respect to the access network. Such mobile nodes require a means to procure globally routable IP addresses/prefixes that remain stable across mobility events. This can be accommodated when access routers connect mobile nodes via stable backhaul networks with mobility anchor points that delegate IP addresses/prefixes 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][RFC3633] for IPv6, as well as the mechanisms specified in this document to provision globally routable and unique IP addresses/prefixes that remain stable within a localized mobility management domain. The model of operation described in this document corresponds to [I-D.ietf-netlmm-nohost-ps] [I-D.ietf-netlmm-nohost-req]. Solutions for both IPv4 [RFC0791] and IPv6 [RFC2460] are given. 2. Additional Authors Ian Chakeres (ian.chakeres@gmail.com) and Seung Yi (seung.yi@boeing.com) made significant contributions to this effort. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs" [RFC2119]. 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). Templin, et al. Expires March 26, 2007 [Page 3] Internet-Draft Localized Mobility Management using DHCP September 2006 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 and client. 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/prefixes from a set of aggregated prefix(es). 4. Model of Operation The Dynamic Host Configuration Protocol (DHCP) has seen significant operational experience in fielded deployments. The DHCP-based mechanisms specified in Section 5 support IP address/prefix configuration and dynamic route management in an LMMD. The following figure provides a reference diagram for the localized mobility management solution space: Templin, et al. Expires March 26, 2007 [Page 4] Internet-Draft Localized Mobility Management using DHCP September 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 5, an MN discovers ARs via standard IP router discovery and sends DHCP requests that are relayed to the MAP by one or more ARs. (The MN can direct multicast/ broadcast requests to the unicast Layer-2 address of specific ARs 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 signals the AR to create a route to the delegated address/prefix. The MN now has a global IP address/prefix delegation and the MAP and AR have established the correct route and address delegation cache state. The MN can change to a new primary AR as network conditions require and can immediately inform the MAP of the change. The MAP uses a DHCP-based protocol to update the routing tables of the MN's new and old ARs. The protocol is a 3-way exchange that begins with the MAP sending a FORCERENEW (DHCPv4) or Reconfigure (DHCPv6) to the AR. The AR responds by initiating a DHCP INFORM Templin, et al. Expires March 26, 2007 [Page 5] Internet-Draft Localized Mobility Management using DHCP September 2006 (DHCPv4) or Information-request (DHCPv6) exchange with the MAP to request routes that should be added or removed by the AR. The MAP responds to this request by sending the AR an ACK (DHCPv4) or Reply (DHCPv6) message with Classless Static Route (CSR) option(s). Upon receiving this response, the AR installs and/or deletes the routes as indicated in the CSR option(s). The 3-way exchange for the route updates provides reliability for lost messages as the MAP will timeout and retransmit the FORCERENEW/Reconfigure until receiving an INFORM/Inform-request, and the AR will timeout and retransmit the INFORM/Information-request until receiving an ACK/Reply. The following figure presents a message exchange diagram: MN New AR MAP Old AR | | | | | Router Advertisement | | | |<---------------------| | | | DHCP Request | | | |--------------------->| Relayed DHCP Request | | | |--------------------->| create route | | | | to MN via AR | | | | | | | DHCP Reply | | | Relayed DHCP Reply |<---------------------| | |<---------------------| | | | | | | | | | | | | | | | | DHCP Reconfigure | DHCP Reconfigure | | |<---------------------|------------------->| | | DHCP Inform | DHCP Inform | | |--------------------->|<-------------------| | | DHCP Reply | DHCP Reply | | |<---------------------|------------------->| | | create route | delete route | | | to MN | to MN | | | | | ... | | | | | | data packet | | Tunneled Packet | for MN | Forwarded Packet |<=====================| |<---------------------| | Figure 2: Message Exchange Diagram Templin, et al. Expires March 26, 2007 [Page 6] Internet-Draft Localized Mobility Management using DHCP September 2006 5. Functional Specification 5.1. Mobile Node (MN) Specification When an MN powers on, activates a network interface or moves into a new LMMD, it discovers ARs via standard ICMP Router Solicitation (RS) and Router Advertisement (RA) messages per [RFC1256] (IPv4) or [RFC2461] (IPv6) and adds one or more ARs to its default router list. The MN then requests IP address/prefix delegations via a DISCOVER (IPv4) or Solicit (IPv6) exchange. After address/prefix configuration, the MN periodic renews its address/prefix lease lifetimes. If the MN's primary AR fails or appears to be failing (e.g., due to a link change event) the MN sends an immediate REQUEST (IPv4), Confirm or Rebind (IPv6) message via a new AR so that the MAP(s) and ARs can quickly update their IP forwarding tables. For DHCPv4, the MN generates the REQUEST according to the REBINDING state instead of the RENEWING state. 5.2. Access Router (AR) Specification ARs send periodic and solicited RAs on their attached access networks per [RFC1256] (IPv4) or [RFC2461] (IPv6). ARs configure a BOOTP (IPv4) or DHCPv6 (IPv6) relay agent and a DHCP client. At startup, an AR's DHCP client function announces its presence to any MAP(s) by sending a DISCOVER (DHCPv4) or Solicit (DHCPv6) containing a Parameter Request List option (DHCPv4) or Option Request option (DHCPv6) with the Classless Static Route (CSR) option code (see: Section 5.4) listed twice. The presence of two or more CSR codes in the option indicates that the client is configured as an AR. Upon receiving a response, the AR examines the OFFER (DHCPv4) or Advertise (DHCPv6) to see if it contains an empty CSR option. If it does, the AR concludes the responding DHCP server is configured as a MAP. When an AR receives a FORCERENEW (DHCPv4) [RFC3203] or Reconfigure (DHCPv6) from a MAP, it inspects the message for a Reconfigure Message option (see: Section 5.5) to determine whether it should initiate an INFORM (DHCPv4) / Information-request (DHCPv6) or RENEW (DHCPv4) / Renew (DHCPv6) exchange with the server (according to standard backoff and retransmission rules). Upon receiving an ACK (DHCPv4) or Reply (DHCPv6), the AR examines the message for CSR Option(s). For DHCPv4, CSR options are ordered such that the first zero or more non-empty CSRs supply routes to be added, followed by an empty CSR, Templin, et al. Expires March 26, 2007 [Page 7] Internet-Draft Localized Mobility Management using DHCP September 2006 followed by zero or more non-empty CSRs that supply routes to be deleted. For DHCPv6, the lifetime field for each route indicates whether the route should be added (lifetime > 0) or deleted (lifetime = 0). The AR processes the CSR options and adds/deletes routes as indicated. 5.3. Mobility Anchor Point (MAP) Specification The MAP(s) in the backhaul network act as DHCP servers and routers that aggregate IP prefixes associated with the LMMD. All MAPs within the same LMMD delegate IP addresses/prefixes from the LMMD's associated prefixes and inject the prefixes into the backhaul network's IGP. When multiple MAPs are present within the same LMMD, they synchronize state to maintain a consistent view of address/ prefix delegations and IP routes. When a MAP receives a DISCOVER (DHCPv4) or Solicit (DHCPv6) from an AR's client function (see: Section 5.2) it registers the client as an AR and replies with an OFFER (DHCPv4) or Advertise (DHCPv6) containing an empty CSR option. When a MAP receives a DISCOVER (IPv4) or Solicit (IPv6) message from a MN, it delegates IP address(es)/prefix(es) and/or other requested configuration information. When the MAP is ready to commit the address/prefix delegations, it configures a route in its IP forwarding table and a tunnel interface used for directing packets destined for the MN to the AR via which the MN's DHCP request was relayed. The MAP then returns the ACK (IPv4) or Reply (IPv6) message to the MN via the AR as a DHCP relay. When CSRs are used, the MAP simultaneously initiates a procedure to update the routing tables of the MN's new and old ARs. The MAP begins by sending a FORCERENEW (DHCPv4) or Reconfigure (DHCPv6) with a Reconfigure Message option (using standard backoff and retransmission rules) to trigger the AR to perform an INFORM/ACK (DHCPv4) or Information-request/Information-reply (DHCPv6) exchange. Upon receiving an INFORM/Information-request, the MAP inspects the message for the presence of CSR option request codes. If only one CSR option code is present, the MAP will interpret the request to be for a full dump of routes. If two or more CSR option requests are present, the MAP will interpret the request to be for an incremental update that includes only routes to be added/deleted since the last request. The MAP populates an ACK (DHCPv4) or Reply (DHCPv6) with CSR options that contain the desired routes, and sends the message to the requesting AR. For DHCPv4, CSR options are ordered following the convention specified in Section 5.2. Templin, et al. Expires March 26, 2007 [Page 8] Internet-Draft Localized Mobility Management using DHCP September 2006 Following DHCP address/prefix delegation and IP route/tunnel configuration, when an IP packet destined for an MN arrives at a MAP, the MAP 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). The MAP retains address/prefix delegations as long as the MN continues to refresh its 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. The MAP then initiates the update procedure described above to the new and old ARs. When lease lifetimes expire, the MAP deletes its cached address/prefix delegations and their corresponding route/tunnel configurations and performs the update procedure with the AR to delete the MNs associated routes. 5.4. Classless Static Route option [RFC3442] specifies a Classless Static Route option for IPv4. This document specifies a corresponding CSR option for DHCPv6. The format of the Classless Static Route option for IPv6 is given below: Templin, et al. Expires March 26, 2007 [Page 9] Internet-Draft Localized Mobility Management using DHCP September 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_CSR | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix-len | intf-id-len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | prefix | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | nexthop | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . interface-id . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_CSR (TBD). option-len 38 + length of interface ID field. prefix-len Prefix length for the IPv6 prefix. intf-id-len Length of the interface-id field. prefix an IPv6 address/prefix. nexthop an IPv6 address that identifies the nexthop for the static route interface-id an opaque value that was conveyed from a relay to the server. Only used for clients configured on the same machine as the relay. lifetime The remaining lifetime for the CSR in the option, expressed in units of seconds. Figure 3: Classless Static Route (CSR) option for DHCPv6 Templin, et al. Expires March 26, 2007 [Page 10] Internet-Draft Localized Mobility Management using DHCP September 2006 5.5. Reconfigure Message option ([RFC3315], Section 22.19) specifies a Reconfigure Message option for DHCPv6 to be included with a Reconfigure message. This document specifies a corresponding Reconfigure Message option for DHCPv4 to be included with a FORCERENEW message. The format of the Reconfigure Message option for DHCPv4 is given below: Code Len Size +-----+-----+-----+ | TBD | 1 |Value| +-----+-----+-----+ Value Operation ----- --------- 0x5 Renew exchange requested 0xb INFORM exchange requested other values reserved Figure 4: Reconfigure Message option for DHCPv4 5.6. Use of RAAN Options for DHCPv6 [I-D.ietf-dhc-dhcpv6-agentopt-delegate] specifies a Relay Agent Assignment Notification (RAAN) option used by DHCPv6 servers to manage static routes in the networking equipment associated with relays on the path. ARs with relays that are prepared to accept RAAN options include the RAAN option code in the Option Request option of the initial Solicit exchange between their client function and the DHCPv6 server on the MAP. MAPs include RAAN options (instead of CSR options) in DHCPv6 replies that traverse the AR's relay function for ARs that accept RAAN options. This means that the MAP can include RAAN options in-band on the MAP's DHCP reply to a MN instead of out-of-band via a Reconfigure/Information-request/Information-reply exchange with the AR's client function. When a MAP initiates a DHCPv6 Reconfigure/Information-request/ Information-reply to delete routes on an AR from which a MN has recently departed, it encapsulates the Reconfigure in a Relay-forward message with RAAN options that forces the Reconfigure to pass through the ARs relay function before reaching the AR's client function. Templin, et al. Expires March 26, 2007 [Page 11] Internet-Draft Localized Mobility Management using DHCP September 2006 6. Additional Considerations 6.1. IPv6 Advantages The following features of IPv6 provide advantages over IPv4 within the NETLMM problem space: 1. IPv6 RAs can carry prefix options whereas IPv4 RAs only carry the address(es) of routers. 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. 2. DHCPv6 provides a prefix delegation mechanism that MNs can use to acquire IP prefixes within the LMMD. 3. MNs can use unique local addresses [RFC4193] for intra-LMMD communications that do not require backhaul network transit. 4. The ARP mechanism used by IPv4 is insecure, while IPv6 Neighbor Discovery can use the securing mechanisms of SEND [RFC3971]. 5. DHCPv6 provides a symmetric chain of relays in the forward and reserve directions. This allows for a natural mapping of the relay function to a router function, and allows MNs and ARs to leave their access network interfaces unnumbered. 6.2. 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]. 6.3. Multilink Subnet Considerations An individual prefix is an IP prefix associated with a specific MN, and a shared prefix is an IP prefix that may be associated with multiple MNs. ARs must not include an individual prefix in RAs that may be received by a MN other than the one associated with the prefix. ARs must not send RAs that include a shared prefix in a Prefix Information Option with 'A'=1 unless there is operational assurance of duplicate address detection/avoidance across the LMMD. ARs must not send RAs that include an individual or shared prefix in a Prefix Information Option with 'L'=1 unless all RAs that include Templin, et al. Expires March 26, 2007 [Page 12] Internet-Draft Localized Mobility Management using DHCP September 2006 the prefix and all MNs that receive them are associated with a single link. MNs and ARs must not assign prefixes other than /128 (IPv6) or /32 (IPv6) to an access interface unless it can be assured that all nodes that configure addresses from the prefix are connected to the same link. 6.4. Support for MNs that use SLAAC This specification can be extended to support MNs that use StateLess Address Auto Configuration (SLAAC) [RFC2462] instead of DHCPv6. All AR<->MAP signaling would be the same as specified in Section 5 with the exception that the AR would act as a proxy DHCP client on behalf of the MN as triggered by the MN's Neighbor Solicitation (NS) messages. 7. RFC Editor Notes (RFC Editor - this section to be deleted before publication as an RFC): [RFC2131] does not specify how a DHCP client should react to a link change event. Section 5.1 specifies that the DHCP client sends an immediate REQUEST while entering the REBINDING state upon link change detection. This document updates [RFC2131]. [RFC3442] specifies a Classless Static Route option for DHCPv4, but does not specify a corresponding option for IPv6. Section 5.4 of this document specifies a Classless Static Route option for DHCPv6. This document updates [RFC3442]. [RFC3203] does not provide a means for the server to inform the client of whether a RENEW or INFORM exchange is requested. Section 5.5 of this document specifies a Reconfigure Message option for DHCPv4 to carry this information. This document updates [RFC3203]. 8. IANA Considerations The IANA is instructed to allocate a new option code for the Classless Static Route option for DHCPv6 in the 'dhcpv6-parameters' registry. The IANA is instructed to allocate a new option code for the Reconfigure Message option for DHCPv4 in the 'bootp-dhcp-parameters' Templin, et al. Expires March 26, 2007 [Page 13] Internet-Draft Localized Mobility Management using DHCP September 2006 registry. 9. 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 between clients and servers is specified in [RFC3118]. The protection of messages between relay agents and servers is specified in [RFC4030], however no protection is provided for the 'giaddr' field in DHCPv4. ([RFC3315], Section 21) specifies mechanisms for DHCPv6 message authentication. For IPv6, if the LMMD is configured to perform authentication, an IPSEC security association MUST be used to protect all relayed messages between the AR and MAP. For IPv4, if the LMMD is configured to perform authentication, either IPSEC security associations MUST be used to protect relayed messages, and/or the AR and MAP MUST include an Authentication sub-option [RFC4030] in the Relay Agent Option in relayed messages and responses. Any relayed messages or responses that can not be successfully authenticated MUST be discarded if the LMMD is configured to perform authentication. The ARP mechanism used by IPv4 is insecure, while IPv6 Neighbor Discovery can use the securing mechanisms of SEND [RFC3971]. 10. 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. The Naval Research Lab (NRL) Information Technology Division uses DHCP in their MANET research testbeds. Templin, et al. Expires March 26, 2007 [Page 14] Internet-Draft Localized Mobility Management using DHCP September 2006 11. Implementation Status Boeing and MITRE have developed independent working implementations of the -02 version of this specification. 12. Acknowledgements The following individuals have provided valuable input: Marcelo Albuquerque, Ralph Droms, Wojtek Furmanski, Thomas Henderson, Long Ho, James Kempf, Bernie Volz. Alexandru Petrescu mentioned DHCP in NETLMM mailing list discussions. 13. References 13.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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, December 2001. Templin, et al. Expires March 26, 2007 [Page 15] Internet-Draft Localized Mobility Management using DHCP September 2006 [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. [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4", RFC 3442, December 2002. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. 13.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-dhc-dhcpv6-agentopt-delegate] Droms, R., "DHCPv6 Relay Agent Assignment Notification (RAAN) Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-01 (work in progress), August 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-04 (work in progress), August 2006. [I-D.ietf-netlmm-threats] Kempf, J. and C. Vogt, "Security Threats to Network-Based Localized Mobility Management", draft-ietf-netlmm-threats-04 (work in progress), September 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. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. Templin, et al. Expires March 26, 2007 [Page 16] Internet-Draft Localized Mobility Management using DHCP September 2006 [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. [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4030, 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. 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 distinct IP prefix range. Each MN would receive IP address/prefix delegations from their "home" AR. 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 hybrid router/DHCP server/ relay/client. The client function requests prefix delegations from a DHCP server, and the server function delegates IP addresses/prefixes from those IP prefixes. The relay function relays DHCP requests and responses to support mobility and to mitigate the effects of errors such as loss of an AR or partitioning of the backhaul network. Each AR also advertises reachability to its IP prefix range via the backhaul network IGP. A MN obtains address/prefix delegations as specified in Section 5.1. The difference is that the AR is also the MAP and allocates addresses/prefixes from its prefix rather than relaying messages to a MAP. If the MN roams from its home AR, it selects a "visited" AR which relays the MN's DHCP messages to the home AR. The home AR updates its routing information and sends a route update to the current visited AR and previous visited AR (if any). In this model, failure of an AR results in packet loss and MN Templin, et al. Expires March 26, 2007 [Page 17] Internet-Draft Localized Mobility Management using DHCP September 2006 unreachability until MNs associate with a new visited AR. Such failure cases can possibly be mitigated by supporting functions in the backhaul network (TBD). Appendix B. Change Log (RFC Editor - this section to be deleted before publication as an RFC): Changes from -02 to -03: o specified explicit AR<->MAP protocol for route management using standard DHCP mechanisms o added new sections on RFC Editor Notes and Implementation Status o added new co-author 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. Templin, et al. Expires March 26, 2007 [Page 18] Internet-Draft Localized Mobility Management using DHCP September 2006 o changed "IP Version Differences" section title to "IPv6 Advantages". o changed document title. Authors' Addresses Fred L. Templin (editor) Boeing Phantom Works P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA Email: fred.l.templin@boeing.com Steven W. Russet (editor) Boeing Phantom Works P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA Email: steven.w.russert@boeing.com Kevin Grace (editor) MITRE USA Email: kgrace@mitre.org Templin, et al. Expires March 26, 2007 [Page 19] Internet-Draft Localized Mobility Management using DHCP September 2006 Full 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Templin, et al. Expires March 26, 2007 [Page 20]