Network Working Group F. Templin, Ed. Internet-Draft S. Russert, Ed. Intended status: Standards Track Boeing Phantom Works Expires: April 26, 2007 K. Grace, Ed. The MITRE Corporation October 23, 2006 Network Localized Mobility Management using DHCP draft-templin-autoconf-netlmm-dhcp-04.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 April 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 April 26, 2007 [Page 1] Internet-Draft NETLMM using DHCP October 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.1.1. Initialization . . . . . . . . . . . . . . . . . . . . 7 5.1.2. Address/Prefix Configuration . . . . . . . . . . . . . 7 5.1.3. MN Movement to a New AR . . . . . . . . . . . . . . . 8 5.2. Access Router (AR) Specification . . . . . . . . . . . . . 8 5.2.1. NETLMM-Specific DHCP Client Behavior . . . . . . . . . 8 5.2.2. NETLMM-Specific DHCP Relay Behavior . . . . . . . . . 9 5.2.3. Startup and MAP Registration . . . . . . . . . . . . . 9 5.2.4. MN Movement to a new AR . . . . . . . . . . . . . . . 10 5.2.5. MN Movement from an Old AR . . . . . . . . . . . . . . 10 5.2.6. AR Forwarding Model . . . . . . . . . . . . . . . . . 11 5.3. Mobility Anchor Point (MAP) Specification . . . . . . . . 11 5.3.1. AR Registration . . . . . . . . . . . . . . . . . . . 11 5.3.2. MN Address/Prefix Configuration . . . . . . . . . . . 12 5.3.3. MN Movement to a New AR . . . . . . . . . . . . . . . 12 5.3.4. MN Movement from an Old AR . . . . . . . . . . . . . . 13 5.3.5. MN Departure from the LMMD . . . . . . . . . . . . . . 13 5.3.6. MAP Forwarding Model . . . . . . . . . . . . . . . . . 14 5.4. Reconfigure Message option . . . . . . . . . . . . . . . . 14 6. Additional Considerations . . . . . . . . . . . . . . . . . . 14 6.1. IPv6 Advantages . . . . . . . . . . . . . . . . . . . . . 14 6.2. Global Mobility Management . . . . . . . . . . . . . . . . 15 6.3. Multilink Subnet Considerations . . . . . . . . . . . . . 15 7. RFC Editor Notes . . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 13.2. Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Nested LMMD Model . . . . . . . . . . . . . . . . . . 20 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Templin, et al. Expires April 26, 2007 [Page 2] Internet-Draft NETLMM using DHCP October 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 backhaul networks with mobility anchor points that delegate IP addresses/prefixes and maintain mobile node to access router mappings. Access routers and mobility anchor points can use the Bootstrap Protocol (BOOTP) [RFC0951] and Dynamic Host Configuration Protocol (DHCPv4) [RFC2131] [I-D.ietf-dhc-subnet-alloc] for IPv4, or DHCPv6 [RFC3315][RFC3633] for IPv6, as well as the mechanisms specified in this document to provision mobile nodes with 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 April 26, 2007 [Page 3] Internet-Draft NETLMM using DHCP October 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 prefixes. Classless Static Route (CSR) option a DHCP option with (address/prefix, nexthop) information pertaining to a MN. For DHCPv4, the CSR option is specified in [RFC3442]. For DHCPv6, [I-D.ietf-dhc-dhcpv6-agentopt-delegate] specifies a "Relay Agent Assignment Notification (RAAN)" option that this document refers to as the "CSR option for DHCPv6". Server Reply Sequence Number (SRSN) option a DHCPv6 option specified in [I-D.volz-dhc-dhcpv6-srsn-option] that carries a sequence number pertaining to CSRs. 4. Model of Operation The Dynamic Host Configuration Protocol (DHCP) has seen significant operational experience in fielded deployments. The DHCP-based mechanisms for NETLMM specified in Section 5 support IP address/ prefix configuration and stability as well as dynamic route management in an LMMD. The following figure provides a reference diagram for the localized mobility management solution space: Templin, et al. Expires April 26, 2007 [Page 4] Internet-Draft NETLMM using DHCP October 2006 /-------------------------\ / Internet \ \ / \-------+---------+-------/ | | /-------+---------+-------\ ---- / \ ^ / +-----+ \ | | | MAP |-+ | | | +-----+ |-+ | | | +-----+ | | | | +-----+ | | | Backhaul Network | | +-----+ +-----+ | L |- - | AR1 | ..... | ARn | - -| M | +-----+ +-----+ | M | / \ Access / \ | D | / \ Network / \ | | / \ / \ | | | +----+ | | | | MN | -------> | | \ +----+ AR change / | \ / v \-------------------------/ ---- Figure 1: Reference Network Diagram In this model, the MAP uses DHCP-based mechanisms to delegate IP addresses/prefixes for a MN. The MAP then creates routes in its IP forwarding table that point to a specific AR and signals the AR to create routes in its IP forwarding table that associate the MN with the correct access link. When the MN moves from an old AR to a new AR, the MAP and ARs update their IP forwarding tables using either an MN-initiated exchange or an AR-initiated exchange. An MN-initiated exchange begins when an MN sends a DHCP request to the MAP either on the first network join or when changing to a new AR. The MAP includes routing information in its reply to the MN via the new AR and simultaneously initiates a FORCERENEW (DHCPv4) [RFC3203] or Reconfigure (DHCPv6) exchange that deletes routing information in the old AR. Figure 2 presents the MN-initiated exchange: Templin, et al. Expires April 26, 2007 [Page 5] Internet-Draft NETLMM using DHCP October 2006 MN New AR MAP Old AR | | | | | Router Advertisement | | | | (or L2 event) | | | |<---------------------| | | | DHCP Request | | | |--------------------->| Relayed DHCP Request | | | |--------------------->| create route to | | | | MN via new AR | | | | | | | DHCP Reply | DHCP Reconfigure | | Relayed DHCP Reply |<---------------------|------------------->| |<---------------------|create routes | DHCP Info-request | | |to MN |<-------------------| | | | DHCP Reply | | | |------------------->| | | | delete routes| | | | to MN| | | | | ... | | | | | | data packet | | Tunneled Packet | for MN | Forwarded Packet |<=====================| |<---------------------| | Figure 2: MN-initiated Message Exchange Diagram An AR-initiated exchange begins when an AR detects an L2 mobility event or (for IPv6) when an MN sends a Neighbor Solicitation (NS) for the purpose of Duplicate Address Detection (DAD) during StateLess Address Auto-Configuration (SLAAC). This new AR sends an immediate INFORM (DHCPv4) or Information-request (DHCPv6) to the MAP containing a client identifier for the MN without waiting for a random delay. The MAP responds by sending an ACK (DHCPv4) or Reply (DHCPv6) to the new AR with address/prefix delegation information pertaining to the MN and simultaneously issuing a FORCERENEW (DHCPv4) or Reconfigure (DHCPv6) exchange with the old AR exactly as for the MN-initiated exchange. Figure 3 presents the AR-initiated message exchange: Templin, et al. Expires April 26, 2007 [Page 6] Internet-Draft NETLMM using DHCP October 2006 MN New AR MAP Old AR | | | | | NS(DAD) or L2 event | DHCP Info-request | | |--------------------->|--------------------->|update routes to | | | |MN via new AR | | | | | | | DHCP Reply | DHCP Reconfigure | | |<---------------------|------------------->| | |create routes | DHCP Info-request | | |to MN |<-------------------| | | | DHCP Reply | | | |------------------->| | | | delete routes| | | | to MN| | | | | ... | | | | | | data packet | | Tunneled Packet | for MN | Forwarded Packet |<=====================| |<---------------------| | Figure 3: AR-initiated Message Exchange Diagram 5. Functional Specification 5.1. Mobile Node (MN) Specification IPv6 MNs observe the specifications found in [I-D.ietf-netlmm-mn-ar-if]; IPv4 and IPv6 MNs also observe the specifications in the normative references. The following subsections highlight specifications from the normative references that have particular relevance to NETLMM using DHCP: 5.1.1. Initialization 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 based on the RAs received. 5.1.2. Address/Prefix Configuration An IPv6 MN that uses SLAAC [RFC2462] to configure link-local or non- link-local addresses triggers an AR-initiated exchange when it sends NS(DAD). An IPv4 or IPv6 MN that uses DHCP to configure IP Templin, et al. Expires April 26, 2007 [Page 7] Internet-Draft NETLMM using DHCP October 2006 addresses/prefixes performs an ordinary MN-initiated DHCP exchange. MNs can optionally direct their broadcast/multicast solicitations to the unicast Layer-2 addresses of specific ARs if they wish to assert AR selection. 5.1.3. MN Movement to a New AR If a MN using DHCP detects a mobility-related event (e.g., the MN's serving AR fails or appears to be failing) it sends a REQUEST (DHCPv4) or Confirm/Rebind (DHCPv6). (For DHCPv4, the MN generates the REQUEST according to the REBINDING state instead of the RENEWING state.) MNs that use only SLAAC may/may not rerun the DAD procedure due to a mobility-related event. MNs can optionally direct their broadcast/multicast messages triggered by mobility events to the unicast Layer-2 addresses of specific ARs if they wish to assert AR selection. 5.2. Access Router (AR) Specification ARs send periodic and solicited RAs on their attached access networks per [RFC1256] (IPv4) or [RFC2461] (IPv6) and also configure both a DHCP/BOOTP relay agent and a DHCP client. For DHCPv6, the DHCP relay agent and client are tightly-coupled, with the client function performing all mobility-related signaling and the relay function performing IP forwarding table maintenance; the client and relay functions otherwise behave as an ordinary DHCP client and relay. The two functions can be tightly-coupled via implementation in the same process context, inter-process communications, communications via a loopback interface, etc. This document assumes communications via a loopback interface but does not preclude other methods of coupling the AR's client and relay functions. The following subsections specify the operation of ARs in an LMMD: 5.2.1. NETLMM-Specific DHCP Client Behavior For DHCPv4, when the AR's client function receives an ACK from a MAP, it examines the message for CSR options and updates its IP forwarding table according to the information in the CSRs. For the purpose of this specification, the CSR options must be ordered such that the first zero or more non-empty CSRs supply routes to be added, followed by an empty CSR, followed by zero or more non-empty CSRs that supply routes to be deleted. For DHCPv6, the AR's client function wraps each client-server message Templin, et al. Expires April 26, 2007 [Page 8] Internet-Draft NETLMM using DHCP October 2006 it sends for mobility management purposes in a Relay-forward message with: o the loopback address (::1) written in the 'peer-address' field, o zero written in the 'link-address' field, o an Interface-Id option included that identifies a loopback interface that the client listens on, o and an Option Request option that lists the SRSN and CSR option codes The AR's client function then includes any other options as necessary and forwards the message via its backhaul network interface as though it were being relayed by its relay function. For both DHCPv4 and DHCPv6, the AR's client function monitors MN mobility events, e.g., by monitoring L2 mobility indications, and issues an appropriate INFORM/Information-request exchange as specified in the following sections. When an AR's client function performs an INFORM/Information-request exchange with a MAP, it initiates the exchange immediately without waiting for the standard random delay. 5.2.2. NETLMM-Specific DHCP Relay Behavior For DHCPv4, when an AR's relay function relays an ACK to a MN it examines the message for address/prefix delegations and updates the AR's IP forwarding table according to the delegations. For DHCPv6, the AR's relay function includes an Option Request option that lists the SRSN and CSR option codes in each Relay-forward message it sends. When it relays a message to a client, it updates the AR's IP forwarding table according to the information in the SRSN and any CSR options in the Relay-reply message. 5.2.3. Startup and MAP Registration When an AR powers up in an LMMD, it performs an initial solicitation to register itself with a MAP. For DHCPv4, the AR's client function creates a DISCOVER message that contains a Parameter Request List option that lists the CSR option code twice then performs an ordinary DISCOVER exchange. For DHCPv6, the AR's client function creates a Solicit message that includes a Client Identifier option identifying itself, a Reconfigure Templin, et al. Expires April 26, 2007 [Page 9] Internet-Draft NETLMM using DHCP October 2006 Accept option, and any other options required for the initial solicitation. It then wraps the Solicit in a Relay-forward message as specified in Section 5.2.1 except that it includes the CSR option code twice in the Option Request option. The AR then performs an ordinary Solicit exchange. When the AR receives a reply to its solicitation from a server that includes an empty CSR option per Section 5.3.1 it registers the server as a MAP. 5.2.4. MN Movement to a new AR When an AR's client function detects a new MN via a L2 mobility event (or, for IPv6, when an MN issues an NS(DAD)), it issues an INFORM (DHCPv4) or Information-request (DHCPv6). For DHCPv4, the AR's client function creates an INFORM message that includes a Parameter Request List option listing the CSR option code and a Client-identifier option that identifies the MN, then performs an ordinary INFORM exchange. For DHCPv6, the AR's client function creates an Information-request message that includes a Client Identifier option identifying itself and an Option Request option that lists any option codes the client is interested in receiving. It then wraps the Information-request in a Relay-forward message as specified in Section 5.2.1 and includes a CSR option that includes a Client Identifier option that identifies the MN. If the exchange was triggered by an NS(DAD), the client function also includes in the CSR option an IA Address option with the IPv6 address from the NS Target Address field. (The relay function also includes the entire NS message in the CSR option for LMMD-wide proxy DAD purposes via a means outside the scope of this specification.) The client function then performs an ordinary Information-request exchange. 5.2.5. MN Movement from an Old AR For DHCPv4, when an AR's client function receives a FORCERENEW from a MAP with a Reconfigure Message option with 'Value' set to 11 (see: Section 5.4), it creates an INFORM message that includes a Parameter Request List option that lists the CSR option code and any other option codes the client is interested in receiving. It then performs an ordinary INFORM exchange. For DHCPv6, when an AR's client function receives a Reconfigure from a MAP with a Reconfigure Message option with 'msg-type' set to 11, it creates an Information-request message that includes a Client Identifier option identifying itself and an Option Request option Templin, et al. Expires April 26, 2007 [Page 10] Internet-Draft NETLMM using DHCP October 2006 that lists any option codes the client is interested in receiving. It then wraps the Information-request in a Relay-forward message as specified in Section 5.2.1 and performs an ordinary Information- request exchange. 5.2.6. AR Forwarding Model When an IP packet destined for a MN arrives at an AR, the AR forwards the packet according to its IP forwarding table which could entail delivery to the MN as a neighbor on an attached access link, tunneling to a MAP or dropping the packet and returning an appropriate ICMP error if the packet cannot be forwarded. 5.3. Mobility Anchor Point (MAP) Specification MAPs in the backhaul network configure a DHCP server and an associated router that aggregates IP prefixes for 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, they synchronize state to maintain a consistent view of address/prefix delegations and IP forwarding table entries. For DHCPv6, MAPs maintain monotonically-increasing Server Reply Sequence Numbers (SRSNs) per [I-D.volz-dhc-dhcpv6-srsn-option] and include an SRSN option with the current value in each Relay-reply message they send. For both DHCPv4 and DHCPv6, MAPs send an immediate ACK/Reply without waiting for a random delay when responding to an AR's INFORM/ Information-request. 5.3.1. AR Registration For DHCPv4, when a MAP receives a DISCOVER from an AR per Section 5.2.1 it registers the sender as an AR, creates a tunnel to be used for forwarding packets to the AR, and replies with an OFFER or ACK (based on 4-message or 2-message exchange) that contains an empty CSR option. For DHCPv6, when a MAP receives a Solicit wrapped in a Relay-forward message from an AR per Section 5.2.1 it registers the sender as an AR, creates a tunnel to be used for forwarding packets to the AR, and replies with an Advertise or Reply (based on 4-message or 2-message exchange) wrapped in a Relay-reply message that contains an empty CSR option. Templin, et al. Expires April 26, 2007 [Page 11] Internet-Draft NETLMM using DHCP October 2006 5.3.2. MN Address/Prefix Configuration For IPv4 and IPv6 MNs that use DHCP, when a MAP receives a MN's DISCOVER (IPv4) or Solicit (IPv6) message it delegates IP addresses/ prefixes and/or other requested configuration information. When the MAP is ready to commit the address/prefix delegations, it configures routes in its IP forwarding table that point to the tunnel interface for the AR via which the MN's solicitation was relayed. For DHCPv4, the MAP then returns an ACK message to the MN via the AR's relay function. For DHCPv6, the MAP then returns a Reply message to the MN wrapped in a Relay-reply message that includes an SRSN option and CSR options pertaining to the MN via the AR's relay function. For IPv6 MNs that use SLAAC, address configuration is stateless from the MN's perspective but stateful from the network's perspective, and occurs as a side-effect of the AR-initiated exchange specified in Section 5.3.3. 5.3.3. MN Movement to a New AR When a MN moves between ARs within the LMMD, the MAP services the mobility exchange as specified in the following sections: 5.3.3.1. MN-initiated Exchange In a MN-initiated exchange, the MN detects a new AR (e.g., via an RA) and sends a REBIND-REQUEST (DHCPv4) or Confirm/Rebind (DHCPv6) message to the MAP. For DHCPv4, the MAP updates its IP forwarding table entries for the MN to point to the new AR, then returns an ACK message to the MN with address/prefix information pertaining to the MN via the new AR's relay function. For DHCPv6, the MAP updates its IP forwarding table entries for the MN to point to the new AR, then returns a Reply message wrapped in a Relay-reply message that includes an SRSN option and CSR options pertaining to the MN via the new AR's relay function. 5.3.3.2. AR-initiated Exchange In an AR-initiated exchange, the new AR's client function detects a MN's presence (e.g., via an L2 trigger) and issues an INFORM (DHCPv4) or Information-request (DHCPv6) to the MAP. For DHCPv4, if the INFORM contains a Parameter Request List option listing the CSR option code and a Client-identifier option that identifies the MN, the MAP updates its IP forwarding table entries Templin, et al. Expires April 26, 2007 [Page 12] Internet-Draft NETLMM using DHCP October 2006 for the MN to point to the new AR. It then returns an ACK message to the new AR that includes CSRs pertaining to the MN arranged as specified in Section 5.2.1. For DHCPv6, if the Information-request contains an Option Request option listing the CSR option code and a CSR option that includes a Client Identifier option that identifies the MN, the MAP updates its IP forwarding table entries (and/or creates new IP forwarding table entries) for the MN's addresses/prefixes to point to the new AR. (If the CSR option also includes an IA Address option, the Information- request was due to a MN's NS(DAD) and the MAP performs an LMMD-wide proxy DAD before sending the Reply through a means outside the scope of this specification.) The MAP then returns a Reply message wrapped in a Relay-reply message with an SRSN option and CSR options pertaining to the MN via the new AR's relay function. 5.3.4. MN Movement from an Old AR For DHCPv4, when a MN moves to a new AR per Section 5.3.3 the MAP sends a FORCERENEW to the old AR's client function with a Reconfigure Message option with 'Value' set to 11 (see: Section 5.4). When it receives an INFORM from the old AR, the MAP returns an ACK message that includes CSRs arranged as specified in Section 5.2.1 that contain routing information for the old AR. For DHCPv6, when a MN moves to a new AR per Section 5.3.3 the MAP sends a Reconfigure to the old AR's client function with a Reconfigure Message option with 'msg-type' set to 11. When it receives an Information-request from the old AR, the MAP returns a Reply message wrapped in a Relay-reply message with an SRSN option and CSR options that contain routing information for the old AR. 5.3.5. MN Departure from the LMMD For MNs that use DHCP, the MAP retains address/prefix delegations as long as the MN continues to refresh its lease lifetimes. When lease lifetimes expire, the MAP deletes its cached address/prefix delegations and their corresponding route configurations and informs the current AR of the deletions via a FORCERENEW/Reconfigure exchange as specified for MN movement from an old AR in Section 5.3.4. For IPv6 MNs that use SLAAC, when an AR's client function detects the MN's departure from the LMMD it creates an Information-request message wrapped in a Relay-reply message as specified in Section 5.2.1 and includes a CSR option with all IA Address and/or IA Prefix options pertaining to the MN with zero lifetimes. It then performs an ordinary Information-request exchange. Templin, et al. Expires April 26, 2007 [Page 13] Internet-Draft NETLMM using DHCP October 2006 5.3.6. MAP Forwarding Model When an IP packet destined for a MN arrives at a MAP, the MAP forwards the packet according to its IP forwarding table which could entail forwarding the packet via the tunnel to MN's serving AR or dropping the packet and returning an appropriate ICMP error if the packet cannot be forwarded. 5.4. 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 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 addresses 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. Templin, et al. Expires April 26, 2007 [Page 14] Internet-Draft NETLMM using DHCP October 2006 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 reverse 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. DHCPv6 provides a 64-bit Server Reply Sequence Number (SRSN) which provides robustness against out-of-order delivery of a server's replies via a relay. 6.2. Global Mobility Management When an MN leaves an LMMD and enters a new LMMD, its IP addresses/ prefixes are no longer topologically correct and global mobility management mechanisms are needed. Global mobility management is outside the scope of this document. 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 the prefix and all MNs that receive them are associated with a single link. MNs must not assume a peer is on-link unless it has received specific guidance from the network or it has better information that can be used for on-link determination. 7. RFC Editor Notes (RFC Editor - this section to be deleted before publication as an Templin, et al. Expires April 26, 2007 [Page 15] Internet-Draft NETLMM using DHCP October 2006 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 a REQUEST while entering the REBINDING state upon link change detection. This document updates [RFC2131]. [RFC3442] specifies a Classless Static Route option for DHCPv4, while [I-D.ietf-dhc-dhcpv6-agentopt-delegate] specifies a Relay Agent Assignment Notification (RAAN) option for IPv6. This document requests that the RAAN option be renamed as "Classless Static Route (CSR) Option for DHCPv6". [RFC3203] does not provide a means for the server to inform the client of whether a RENEW or INFORM exchange is requested. Section 5.4 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 Reconfigure Message option for DHCPv4 in the 'bootp-dhcp-parameters' 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 Templin, et al. Expires April 26, 2007 [Page 16] Internet-Draft NETLMM using DHCP October 2006 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 MAPless 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. 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, Akber Qureshi, Bernie Volz. Alexandru Petrescu mentioned DHCP in NETLMM mailing list discussions. Julien Laganier proposed a proxy DAD mechanism for use in LMMDs that include shared links. 13. References 13.1. Normative References [I-D.ietf-dhc-dhcpv6-agentopt-delegate] Droms, R., "DHCPv6 Relay Agent Assignment Notification (RAAN) Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-01 Templin, et al. Expires April 26, 2007 [Page 17] Internet-Draft NETLMM using DHCP October 2006 (work in progress), August 2006. [I-D.volz-dhc-dhcpv6-srsn-option] Volz, B. and R. Droms, "DHCPv6 Server Reply Sequence Number Option", draft-volz-dhc-dhcpv6-srsn-option-00 (work in progress), August 2006. [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. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, December 2001. [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. Templin, et al. Expires April 26, 2007 [Page 18] Internet-Draft NETLMM using DHCP October 2006 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-subnet-alloc] Johnson, R., "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-03 (work in progress), June 2005. [I-D.ietf-netlmm-mn-ar-if] Laganier, J., "Network-based Localized Mobility Management Interface between Mobile Node and Access Router", draft-ietf-netlmm-mn-ar-if-01 (work in progress), June 2006. [I-D.ietf-netlmm-nohost-ps] Kempf, J., "Problem Statement for Network-based Localized Mobility Management", draft-ietf-netlmm-nohost-ps-05 (work in progress), September 2006. [I-D.ietf-netlmm-nohost-req] Kempf, J., "Goals for Network-based Localized Mobility Management (NETLMM)", draft-ietf-netlmm-nohost-req-05 (work in progress), October 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. [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. [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Templin, et al. Expires April 26, 2007 [Page 19] Internet-Draft NETLMM using DHCP October 2006 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 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): Templin, et al. Expires April 26, 2007 [Page 20] Internet-Draft NETLMM using DHCP October 2006 Changes from -03 to -04: o support for AR-initiated updates for fast handovers o support for IPv6 MNs that use SLAAC 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. o changed "IP Version Differences" section title to "IPv6 Advantages". o changed document title. Templin, et al. Expires April 26, 2007 [Page 21] Internet-Draft NETLMM using DHCP October 2006 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) The MITRE Corporation 202 Burlington Rd. Bedford, MA 01730 USA Email: kgrace@mitre.org Templin, et al. Expires April 26, 2007 [Page 22] Internet-Draft NETLMM using DHCP October 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 April 26, 2007 [Page 23]