idnits 2.17.1 draft-templin-autoconf-netlmm-dhcp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1014. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1025. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1032. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1038. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 843 has weird spacing: '...le Node and A...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2006) is 6366 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC0826' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'E2E' is defined on line 833, but no explicit reference was found in the text == Unused Reference: 'RFC3927' is defined on line 870, but no explicit reference was found in the text == Unused Reference: 'RFC4039' is defined on line 881, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-agentopt-delegate-01 ** Downref: Normative reference to an Informational draft: draft-volz-dhc-dhcpv6-srsn-option (ref. 'I-D.volz-dhc-dhcpv6-srsn-option') ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-13) exists of draft-ietf-dhc-subnet-alloc-03 == Outdated reference: A later version (-03) exists of draft-ietf-netlmm-mn-ar-if-01 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft S. Russert, Ed. 4 Intended status: Standards Track Boeing Phantom Works 5 Expires: April 26, 2007 K. Grace, Ed. 6 The MITRE Corporation 7 October 23, 2006 9 Network Localized Mobility Management using DHCP 10 draft-templin-autoconf-netlmm-dhcp-04.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 26, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 Mobile nodes require a means to automatically configure globally 44 routable IP addresses/prefixes that remain stable across localized 45 mobility events. This document specifies mechanisms for network 46 localized mobility management (NETLMM) using the Dynamic Host 47 Configuration Protocol (DHCP). Solutions for both IPv4 and IPv6 are 48 given. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Model of Operation . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Functional Specification . . . . . . . . . . . . . . . . . . . 7 57 5.1. Mobile Node (MN) Specification . . . . . . . . . . . . . . 7 58 5.1.1. Initialization . . . . . . . . . . . . . . . . . . . . 7 59 5.1.2. Address/Prefix Configuration . . . . . . . . . . . . . 7 60 5.1.3. MN Movement to a New AR . . . . . . . . . . . . . . . 8 61 5.2. Access Router (AR) Specification . . . . . . . . . . . . . 8 62 5.2.1. NETLMM-Specific DHCP Client Behavior . . . . . . . . . 8 63 5.2.2. NETLMM-Specific DHCP Relay Behavior . . . . . . . . . 9 64 5.2.3. Startup and MAP Registration . . . . . . . . . . . . . 9 65 5.2.4. MN Movement to a new AR . . . . . . . . . . . . . . . 10 66 5.2.5. MN Movement from an Old AR . . . . . . . . . . . . . . 10 67 5.2.6. AR Forwarding Model . . . . . . . . . . . . . . . . . 11 68 5.3. Mobility Anchor Point (MAP) Specification . . . . . . . . 11 69 5.3.1. AR Registration . . . . . . . . . . . . . . . . . . . 11 70 5.3.2. MN Address/Prefix Configuration . . . . . . . . . . . 12 71 5.3.3. MN Movement to a New AR . . . . . . . . . . . . . . . 12 72 5.3.4. MN Movement from an Old AR . . . . . . . . . . . . . . 13 73 5.3.5. MN Departure from the LMMD . . . . . . . . . . . . . . 13 74 5.3.6. MAP Forwarding Model . . . . . . . . . . . . . . . . . 14 75 5.4. Reconfigure Message option . . . . . . . . . . . . . . . . 14 76 6. Additional Considerations . . . . . . . . . . . . . . . . . . 14 77 6.1. IPv6 Advantages . . . . . . . . . . . . . . . . . . . . . 14 78 6.2. Global Mobility Management . . . . . . . . . . . . . . . . 15 79 6.3. Multilink Subnet Considerations . . . . . . . . . . . . . 15 80 7. RFC Editor Notes . . . . . . . . . . . . . . . . . . . . . . . 15 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 83 10. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 85 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 88 13.2. Informative References . . . . . . . . . . . . . . . . . . 19 89 Appendix A. Nested LMMD Model . . . . . . . . . . . . . . . . . . 20 90 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 92 Intellectual Property and Copyright Statements . . . . . . . . . . 23 94 1. Introduction 96 Access networks (e.g., campus LANs, cellular wireless, WiFi, MANETs, 97 etc.) may be prone to congestion, signal intermittence, node 98 movements, partitions/merges, equipment failure, etc. From a node's 99 viewpoint, these disturbances appear as mobility events that cause 100 communications to fail or degrade, i.e., the node appears to be 101 mobile with respect to the access network. Such mobile nodes require 102 a means to procure globally routable IP addresses/prefixes that 103 remain stable across mobility events. This can be accommodated when 104 access routers connect mobile nodes via backhaul networks with 105 mobility anchor points that delegate IP addresses/prefixes and 106 maintain mobile node to access router mappings. 108 Access routers and mobility anchor points can use the Bootstrap 109 Protocol (BOOTP) [RFC0951] and Dynamic Host Configuration Protocol 110 (DHCPv4) [RFC2131] [I-D.ietf-dhc-subnet-alloc] for IPv4, or DHCPv6 111 [RFC3315][RFC3633] for IPv6, as well as the mechanisms specified in 112 this document to provision mobile nodes with globally routable and 113 unique IP addresses/prefixes that remain stable within a localized 114 mobility management domain. 116 The model of operation described in this document corresponds to 117 [I-D.ietf-netlmm-nohost-ps] [I-D.ietf-netlmm-nohost-req]. Solutions 118 for both IPv4 [RFC0791] and IPv6 [RFC2460] are given. 120 2. Additional Authors 122 Ian Chakeres (ian.chakeres@gmail.com) and Seung Yi 123 (seung.yi@boeing.com) made significant contributions to this effort. 125 3. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in "Key words for use in 130 RFCs" [RFC2119]. 132 The terminology in the normative references apply; the following 133 terms are defined within the scope of this document: 135 link 136 the same as defined in ([RFC2461], Section 2.1). 138 access network 139 a link that connects Mobile Nodes and Access Routers and may be 140 subject to congestion, signal intermittence, node movements, 141 network partitions/merges, equipment failure, etc. 143 backhaul network 144 a network that connects Access Routers and Mobility Anchor 145 Point(s) and also connects the Localized Mobility Management 146 Domain to the global Internet. 148 Mobile Node (MN) 149 a node on an access network that also acts as a DHCP client. 151 Access Router (AR) 152 a router that connects access networks to a backhaul network and 153 also acts as a DHCP/BOOTP relay agent and client. 155 Mobility Anchor Point (MAP) 156 a backhaul network router (and its associated DHCP server) that 157 aggregates IP prefixes in a Localized Mobility Management Domain. 159 Localized Mobility Management Domain (LMMD) 160 a set of MAPs (and their associated ARs and MNs) that provision 161 addresses/prefixes from a set of aggregated prefixes. 163 Classless Static Route (CSR) option 164 a DHCP option with (address/prefix, nexthop) information 165 pertaining to a MN. For DHCPv4, the CSR option is specified in 166 [RFC3442]. For DHCPv6, [I-D.ietf-dhc-dhcpv6-agentopt-delegate] 167 specifies a "Relay Agent Assignment Notification (RAAN)" option 168 that this document refers to as the "CSR option for DHCPv6". 170 Server Reply Sequence Number (SRSN) option 171 a DHCPv6 option specified in [I-D.volz-dhc-dhcpv6-srsn-option] 172 that carries a sequence number pertaining to CSRs. 174 4. Model of Operation 176 The Dynamic Host Configuration Protocol (DHCP) has seen significant 177 operational experience in fielded deployments. The DHCP-based 178 mechanisms for NETLMM specified in Section 5 support IP address/ 179 prefix configuration and stability as well as dynamic route 180 management in an LMMD. The following figure provides a reference 181 diagram for the localized mobility management solution space: 183 /-------------------------\ 184 / Internet \ 185 \ / 186 \-------+---------+-------/ 187 | | 188 /-------+---------+-------\ ---- 189 / \ ^ 190 / +-----+ \ | 191 | | MAP |-+ | | 192 | +-----+ |-+ | | 193 | +-----+ | | | 194 | +-----+ | | 195 | Backhaul Network | 196 | +-----+ +-----+ | L 197 |- - | AR1 | ..... | ARn | - -| M 198 | +-----+ +-----+ | M 199 | / \ Access / \ | D 200 | / \ Network / \ | 201 | / \ / \ | | 202 | +----+ | | 203 | | MN | -------> | | 204 \ +----+ AR change / | 205 \ / v 206 \-------------------------/ ---- 208 Figure 1: Reference Network Diagram 210 In this model, the MAP uses DHCP-based mechanisms to delegate IP 211 addresses/prefixes for a MN. The MAP then creates routes in its IP 212 forwarding table that point to a specific AR and signals the AR to 213 create routes in its IP forwarding table that associate the MN with 214 the correct access link. When the MN moves from an old AR to a new 215 AR, the MAP and ARs update their IP forwarding tables using either an 216 MN-initiated exchange or an AR-initiated exchange. 218 An MN-initiated exchange begins when an MN sends a DHCP request to 219 the MAP either on the first network join or when changing to a new 220 AR. The MAP includes routing information in its reply to the MN via 221 the new AR and simultaneously initiates a FORCERENEW (DHCPv4) 222 [RFC3203] or Reconfigure (DHCPv6) exchange that deletes routing 223 information in the old AR. Figure 2 presents the MN-initiated 224 exchange: 226 MN New AR MAP Old AR 227 | | | | 228 | Router Advertisement | | | 229 | (or L2 event) | | | 230 |<---------------------| | | 231 | DHCP Request | | | 232 |--------------------->| Relayed DHCP Request | | 233 | |--------------------->| create route to | 234 | | | MN via new AR | 235 | | | | 236 | | DHCP Reply | DHCP Reconfigure | 237 | Relayed DHCP Reply |<---------------------|------------------->| 238 |<---------------------|create routes | DHCP Info-request | 239 | |to MN |<-------------------| 240 | | | DHCP Reply | 241 | | |------------------->| 242 | | | delete routes| 243 | | | to MN| 244 | | | | 245 ... 246 | | | 247 | | | data packet 248 | | Tunneled Packet | for MN 249 | Forwarded Packet |<=====================| 250 |<---------------------| | 252 Figure 2: MN-initiated Message Exchange Diagram 254 An AR-initiated exchange begins when an AR detects an L2 mobility 255 event or (for IPv6) when an MN sends a Neighbor Solicitation (NS) for 256 the purpose of Duplicate Address Detection (DAD) during StateLess 257 Address Auto-Configuration (SLAAC). This new AR sends an immediate 258 INFORM (DHCPv4) or Information-request (DHCPv6) to the MAP containing 259 a client identifier for the MN without waiting for a random delay. 260 The MAP responds by sending an ACK (DHCPv4) or Reply (DHCPv6) to the 261 new AR with address/prefix delegation information pertaining to the 262 MN and simultaneously issuing a FORCERENEW (DHCPv4) or Reconfigure 263 (DHCPv6) exchange with the old AR exactly as for the MN-initiated 264 exchange. Figure 3 presents the AR-initiated message exchange: 266 MN New AR MAP Old AR 267 | | | | 268 | NS(DAD) or L2 event | DHCP Info-request | | 269 |--------------------->|--------------------->|update routes to | 270 | | |MN via new AR | 271 | | | | 272 | | DHCP Reply | DHCP Reconfigure | 273 | |<---------------------|------------------->| 274 | |create routes | DHCP Info-request | 275 | |to MN |<-------------------| 276 | | | DHCP Reply | 277 | | |------------------->| 278 | | | delete routes| 279 | | | to MN| 280 | | | | 281 ... 282 | | | 283 | | | data packet 284 | | Tunneled Packet | for MN 285 | Forwarded Packet |<=====================| 286 |<---------------------| | 288 Figure 3: AR-initiated Message Exchange Diagram 290 5. Functional Specification 292 5.1. Mobile Node (MN) Specification 294 IPv6 MNs observe the specifications found in 295 [I-D.ietf-netlmm-mn-ar-if]; IPv4 and IPv6 MNs also observe the 296 specifications in the normative references. The following 297 subsections highlight specifications from the normative references 298 that have particular relevance to NETLMM using DHCP: 300 5.1.1. Initialization 302 When an MN powers on, activates a network interface or moves into a 303 new LMMD, it discovers ARs via standard ICMP Router Solicitation (RS) 304 and Router Advertisement (RA) messages per [RFC1256] (IPv4) or 305 [RFC2461] (IPv6) and adds one or more ARs to its default router list 306 based on the RAs received. 308 5.1.2. Address/Prefix Configuration 310 An IPv6 MN that uses SLAAC [RFC2462] to configure link-local or non- 311 link-local addresses triggers an AR-initiated exchange when it sends 312 NS(DAD). An IPv4 or IPv6 MN that uses DHCP to configure IP 313 addresses/prefixes performs an ordinary MN-initiated DHCP exchange. 315 MNs can optionally direct their broadcast/multicast solicitations to 316 the unicast Layer-2 addresses of specific ARs if they wish to assert 317 AR selection. 319 5.1.3. MN Movement to a New AR 321 If a MN using DHCP detects a mobility-related event (e.g., the MN's 322 serving AR fails or appears to be failing) it sends a REQUEST 323 (DHCPv4) or Confirm/Rebind (DHCPv6). (For DHCPv4, the MN generates 324 the REQUEST according to the REBINDING state instead of the RENEWING 325 state.) MNs that use only SLAAC may/may not rerun the DAD procedure 326 due to a mobility-related event. 328 MNs can optionally direct their broadcast/multicast messages 329 triggered by mobility events to the unicast Layer-2 addresses of 330 specific ARs if they wish to assert AR selection. 332 5.2. Access Router (AR) Specification 334 ARs send periodic and solicited RAs on their attached access networks 335 per [RFC1256] (IPv4) or [RFC2461] (IPv6) and also configure both a 336 DHCP/BOOTP relay agent and a DHCP client. 338 For DHCPv6, the DHCP relay agent and client are tightly-coupled, with 339 the client function performing all mobility-related signaling and the 340 relay function performing IP forwarding table maintenance; the client 341 and relay functions otherwise behave as an ordinary DHCP client and 342 relay. The two functions can be tightly-coupled via implementation 343 in the same process context, inter-process communications, 344 communications via a loopback interface, etc. This document assumes 345 communications via a loopback interface but does not preclude other 346 methods of coupling the AR's client and relay functions. 348 The following subsections specify the operation of ARs in an LMMD: 350 5.2.1. NETLMM-Specific DHCP Client Behavior 352 For DHCPv4, when the AR's client function receives an ACK from a MAP, 353 it examines the message for CSR options and updates its IP forwarding 354 table according to the information in the CSRs. For the purpose of 355 this specification, the CSR options must be ordered such that the 356 first zero or more non-empty CSRs supply routes to be added, followed 357 by an empty CSR, followed by zero or more non-empty CSRs that supply 358 routes to be deleted. 360 For DHCPv6, the AR's client function wraps each client-server message 361 it sends for mobility management purposes in a Relay-forward message 362 with: 364 o the loopback address (::1) written in the 'peer-address' field, 366 o zero written in the 'link-address' field, 368 o an Interface-Id option included that identifies a loopback 369 interface that the client listens on, 371 o and an Option Request option that lists the SRSN and CSR option 372 codes 374 The AR's client function then includes any other options as necessary 375 and forwards the message via its backhaul network interface as though 376 it were being relayed by its relay function. 378 For both DHCPv4 and DHCPv6, the AR's client function monitors MN 379 mobility events, e.g., by monitoring L2 mobility indications, and 380 issues an appropriate INFORM/Information-request exchange as 381 specified in the following sections. When an AR's client function 382 performs an INFORM/Information-request exchange with a MAP, it 383 initiates the exchange immediately without waiting for the standard 384 random delay. 386 5.2.2. NETLMM-Specific DHCP Relay Behavior 388 For DHCPv4, when an AR's relay function relays an ACK to a MN it 389 examines the message for address/prefix delegations and updates the 390 AR's IP forwarding table according to the delegations. 392 For DHCPv6, the AR's relay function includes an Option Request option 393 that lists the SRSN and CSR option codes in each Relay-forward 394 message it sends. When it relays a message to a client, it updates 395 the AR's IP forwarding table according to the information in the SRSN 396 and any CSR options in the Relay-reply message. 398 5.2.3. Startup and MAP Registration 400 When an AR powers up in an LMMD, it performs an initial solicitation 401 to register itself with a MAP. 403 For DHCPv4, the AR's client function creates a DISCOVER message that 404 contains a Parameter Request List option that lists the CSR option 405 code twice then performs an ordinary DISCOVER exchange. 407 For DHCPv6, the AR's client function creates a Solicit message that 408 includes a Client Identifier option identifying itself, a Reconfigure 409 Accept option, and any other options required for the initial 410 solicitation. It then wraps the Solicit in a Relay-forward message 411 as specified in Section 5.2.1 except that it includes the CSR option 412 code twice in the Option Request option. The AR then performs an 413 ordinary Solicit exchange. 415 When the AR receives a reply to its solicitation from a server that 416 includes an empty CSR option per Section 5.3.1 it registers the 417 server as a MAP. 419 5.2.4. MN Movement to a new AR 421 When an AR's client function detects a new MN via a L2 mobility event 422 (or, for IPv6, when an MN issues an NS(DAD)), it issues an INFORM 423 (DHCPv4) or Information-request (DHCPv6). 425 For DHCPv4, the AR's client function creates an INFORM message that 426 includes a Parameter Request List option listing the CSR option code 427 and a Client-identifier option that identifies the MN, then performs 428 an ordinary INFORM exchange. 430 For DHCPv6, the AR's client function creates an Information-request 431 message that includes a Client Identifier option identifying itself 432 and an Option Request option that lists any option codes the client 433 is interested in receiving. It then wraps the Information-request in 434 a Relay-forward message as specified in Section 5.2.1 and includes a 435 CSR option that includes a Client Identifier option that identifies 436 the MN. If the exchange was triggered by an NS(DAD), the client 437 function also includes in the CSR option an IA Address option with 438 the IPv6 address from the NS Target Address field. (The relay 439 function also includes the entire NS message in the CSR option for 440 LMMD-wide proxy DAD purposes via a means outside the scope of this 441 specification.) The client function then performs an ordinary 442 Information-request exchange. 444 5.2.5. MN Movement from an Old AR 446 For DHCPv4, when an AR's client function receives a FORCERENEW from a 447 MAP with a Reconfigure Message option with 'Value' set to 11 (see: 448 Section 5.4), it creates an INFORM message that includes a Parameter 449 Request List option that lists the CSR option code and any other 450 option codes the client is interested in receiving. It then performs 451 an ordinary INFORM exchange. 453 For DHCPv6, when an AR's client function receives a Reconfigure from 454 a MAP with a Reconfigure Message option with 'msg-type' set to 11, it 455 creates an Information-request message that includes a Client 456 Identifier option identifying itself and an Option Request option 457 that lists any option codes the client is interested in receiving. 458 It then wraps the Information-request in a Relay-forward message as 459 specified in Section 5.2.1 and performs an ordinary Information- 460 request exchange. 462 5.2.6. AR Forwarding Model 464 When an IP packet destined for a MN arrives at an AR, the AR forwards 465 the packet according to its IP forwarding table which could entail 466 delivery to the MN as a neighbor on an attached access link, 467 tunneling to a MAP or dropping the packet and returning an 468 appropriate ICMP error if the packet cannot be forwarded. 470 5.3. Mobility Anchor Point (MAP) Specification 472 MAPs in the backhaul network configure a DHCP server and an 473 associated router that aggregates IP prefixes for the LMMD. All MAPs 474 within the same LMMD delegate IP addresses/prefixes from the LMMD's 475 associated prefixes and inject the prefixes into the backhaul 476 network's IGP. When multiple MAPs are present, they synchronize 477 state to maintain a consistent view of address/prefix delegations and 478 IP forwarding table entries. 480 For DHCPv6, MAPs maintain monotonically-increasing Server Reply 481 Sequence Numbers (SRSNs) per [I-D.volz-dhc-dhcpv6-srsn-option] and 482 include an SRSN option with the current value in each Relay-reply 483 message they send. 485 For both DHCPv4 and DHCPv6, MAPs send an immediate ACK/Reply without 486 waiting for a random delay when responding to an AR's INFORM/ 487 Information-request. 489 5.3.1. AR Registration 491 For DHCPv4, when a MAP receives a DISCOVER from an AR per 492 Section 5.2.1 it registers the sender as an AR, creates a tunnel to 493 be used for forwarding packets to the AR, and replies with an OFFER 494 or ACK (based on 4-message or 2-message exchange) that contains an 495 empty CSR option. 497 For DHCPv6, when a MAP receives a Solicit wrapped in a Relay-forward 498 message from an AR per Section 5.2.1 it registers the sender as an 499 AR, creates a tunnel to be used for forwarding packets to the AR, and 500 replies with an Advertise or Reply (based on 4-message or 2-message 501 exchange) wrapped in a Relay-reply message that contains an empty CSR 502 option. 504 5.3.2. MN Address/Prefix Configuration 506 For IPv4 and IPv6 MNs that use DHCP, when a MAP receives a MN's 507 DISCOVER (IPv4) or Solicit (IPv6) message it delegates IP addresses/ 508 prefixes and/or other requested configuration information. When the 509 MAP is ready to commit the address/prefix delegations, it configures 510 routes in its IP forwarding table that point to the tunnel interface 511 for the AR via which the MN's solicitation was relayed. For DHCPv4, 512 the MAP then returns an ACK message to the MN via the AR's relay 513 function. For DHCPv6, the MAP then returns a Reply message to the MN 514 wrapped in a Relay-reply message that includes an SRSN option and CSR 515 options pertaining to the MN via the AR's relay function. 517 For IPv6 MNs that use SLAAC, address configuration is stateless from 518 the MN's perspective but stateful from the network's perspective, and 519 occurs as a side-effect of the AR-initiated exchange specified in 520 Section 5.3.3. 522 5.3.3. MN Movement to a New AR 524 When a MN moves between ARs within the LMMD, the MAP services the 525 mobility exchange as specified in the following sections: 527 5.3.3.1. MN-initiated Exchange 529 In a MN-initiated exchange, the MN detects a new AR (e.g., via an RA) 530 and sends a REBIND-REQUEST (DHCPv4) or Confirm/Rebind (DHCPv6) 531 message to the MAP. 533 For DHCPv4, the MAP updates its IP forwarding table entries for the 534 MN to point to the new AR, then returns an ACK message to the MN with 535 address/prefix information pertaining to the MN via the new AR's 536 relay function. 538 For DHCPv6, the MAP updates its IP forwarding table entries for the 539 MN to point to the new AR, then returns a Reply message wrapped in a 540 Relay-reply message that includes an SRSN option and CSR options 541 pertaining to the MN via the new AR's relay function. 543 5.3.3.2. AR-initiated Exchange 545 In an AR-initiated exchange, the new AR's client function detects a 546 MN's presence (e.g., via an L2 trigger) and issues an INFORM (DHCPv4) 547 or Information-request (DHCPv6) to the MAP. 549 For DHCPv4, if the INFORM contains a Parameter Request List option 550 listing the CSR option code and a Client-identifier option that 551 identifies the MN, the MAP updates its IP forwarding table entries 552 for the MN to point to the new AR. It then returns an ACK message to 553 the new AR that includes CSRs pertaining to the MN arranged as 554 specified in Section 5.2.1. 556 For DHCPv6, if the Information-request contains an Option Request 557 option listing the CSR option code and a CSR option that includes a 558 Client Identifier option that identifies the MN, the MAP updates its 559 IP forwarding table entries (and/or creates new IP forwarding table 560 entries) for the MN's addresses/prefixes to point to the new AR. (If 561 the CSR option also includes an IA Address option, the Information- 562 request was due to a MN's NS(DAD) and the MAP performs an LMMD-wide 563 proxy DAD before sending the Reply through a means outside the scope 564 of this specification.) The MAP then returns a Reply message wrapped 565 in a Relay-reply message with an SRSN option and CSR options 566 pertaining to the MN via the new AR's relay function. 568 5.3.4. MN Movement from an Old AR 570 For DHCPv4, when a MN moves to a new AR per Section 5.3.3 the MAP 571 sends a FORCERENEW to the old AR's client function with a Reconfigure 572 Message option with 'Value' set to 11 (see: Section 5.4). When it 573 receives an INFORM from the old AR, the MAP returns an ACK message 574 that includes CSRs arranged as specified in Section 5.2.1 that 575 contain routing information for the old AR. 577 For DHCPv6, when a MN moves to a new AR per Section 5.3.3 the MAP 578 sends a Reconfigure to the old AR's client function with a 579 Reconfigure Message option with 'msg-type' set to 11. When it 580 receives an Information-request from the old AR, the MAP returns a 581 Reply message wrapped in a Relay-reply message with an SRSN option 582 and CSR options that contain routing information for the old AR. 584 5.3.5. MN Departure from the LMMD 586 For MNs that use DHCP, the MAP retains address/prefix delegations as 587 long as the MN continues to refresh its lease lifetimes. When lease 588 lifetimes expire, the MAP deletes its cached address/prefix 589 delegations and their corresponding route configurations and informs 590 the current AR of the deletions via a FORCERENEW/Reconfigure exchange 591 as specified for MN movement from an old AR in Section 5.3.4. 593 For IPv6 MNs that use SLAAC, when an AR's client function detects the 594 MN's departure from the LMMD it creates an Information-request 595 message wrapped in a Relay-reply message as specified in 596 Section 5.2.1 and includes a CSR option with all IA Address and/or IA 597 Prefix options pertaining to the MN with zero lifetimes. It then 598 performs an ordinary Information-request exchange. 600 5.3.6. MAP Forwarding Model 602 When an IP packet destined for a MN arrives at a MAP, the MAP 603 forwards the packet according to its IP forwarding table which could 604 entail forwarding the packet via the tunnel to MN's serving AR or 605 dropping the packet and returning an appropriate ICMP error if the 606 packet cannot be forwarded. 608 5.4. Reconfigure Message option 610 ([RFC3315], Section 22.19) specifies a Reconfigure Message option for 611 DHCPv6 to be included with a Reconfigure message. This document 612 specifies a corresponding Reconfigure Message option for DHCPv4 to be 613 included with a FORCERENEW message. 615 The format of the Reconfigure Message option for DHCPv4 is given 616 below: 618 Code Len Size 619 +-----+-----+-----+ 620 | TBD | 1 |Value| 621 +-----+-----+-----+ 623 Value Operation 624 ----- --------- 625 0x5 Renew exchange requested 626 0xb INFORM exchange requested 627 other values reserved 629 Figure 4: Reconfigure Message option for DHCPv4 631 6. Additional Considerations 633 6.1. IPv6 Advantages 635 The following features of IPv6 provide advantages over IPv4 within 636 the NETLMM problem space: 638 1. IPv6 RAs can carry prefix options whereas IPv4 RAs only carry the 639 addresses of routers. IPv6 MNs can auto-configure addresses from 640 advertised prefixes and propose them to the MAP's DHCPv6 server 641 instead of allowing the DHCPv6 server to select addresses. 643 2. DHCPv6 provides a prefix delegation mechanism that MNs can use to 644 acquire IP prefixes within the LMMD. 646 3. MNs can use unique local addresses [RFC4193] for intra-LMMD 647 communications that do not require backhaul network transit. 649 4. The ARP mechanism used by IPv4 is insecure, while IPv6 Neighbor 650 Discovery can use the securing mechanisms of SEND [RFC3971]. 652 5. DHCPv6 provides a symmetric chain of relays in the forward and 653 reverse directions. This allows for a natural mapping of the 654 relay function to a router function, and allows MNs and ARs to 655 leave their access network interfaces unnumbered. 657 6. DHCPv6 provides a 64-bit Server Reply Sequence Number (SRSN) 658 which provides robustness against out-of-order delivery of a 659 server's replies via a relay. 661 6.2. Global Mobility Management 663 When an MN leaves an LMMD and enters a new LMMD, its IP addresses/ 664 prefixes are no longer topologically correct and global mobility 665 management mechanisms are needed. Global mobility management is 666 outside the scope of this document. 668 6.3. Multilink Subnet Considerations 670 An individual prefix is an IP prefix associated with a specific MN, 671 and a shared prefix is an IP prefix that may be associated with 672 multiple MNs. 674 ARs must not include an individual prefix in RAs that may be received 675 by a MN other than the one associated with the prefix. 677 ARs must not send RAs that include a shared prefix in a Prefix 678 Information Option with 'A'=1 unless there is operational assurance 679 of duplicate address detection/avoidance across the LMMD. 681 ARs must not send RAs that include an individual or shared prefix in 682 a Prefix Information Option with 'L'=1 unless all RAs that include 683 the prefix and all MNs that receive them are associated with a single 684 link. 686 MNs must not assume a peer is on-link unless it has received specific 687 guidance from the network or it has better information that can be 688 used for on-link determination. 690 7. RFC Editor Notes 692 (RFC Editor - this section to be deleted before publication as an 693 RFC): 695 [RFC2131] does not specify how a DHCP client should react to a link 696 change event. Section 5.1 specifies that the DHCP client sends a 697 REQUEST while entering the REBINDING state upon link change 698 detection. This document updates [RFC2131]. 700 [RFC3442] specifies a Classless Static Route option for DHCPv4, while 701 [I-D.ietf-dhc-dhcpv6-agentopt-delegate] specifies a Relay Agent 702 Assignment Notification (RAAN) option for IPv6. This document 703 requests that the RAAN option be renamed as "Classless Static Route 704 (CSR) Option for DHCPv6". 706 [RFC3203] does not provide a means for the server to inform the 707 client of whether a RENEW or INFORM exchange is requested. 708 Section 5.4 of this document specifies a Reconfigure Message option 709 for DHCPv4 to carry this information. This document updates 710 [RFC3203]. 712 8. IANA Considerations 714 The IANA is instructed to allocate a new option code for the 715 Reconfigure Message option for DHCPv4 in the 'bootp-dhcp-parameters' 716 registry. 718 9. Security Considerations 720 Threats relating to NETLMM [I-D.ietf-netlmm-threats] and the security 721 considerations for DHCP [RFC2131] [RFC3315] apply to this document. 723 The base DHCPv4 specification [RFC2131] does not specify securing 724 mechanisms, but DHCPv4 message authentication between clients and 725 servers is specified in [RFC3118]. The protection of messages 726 between relay agents and servers is specified in [RFC4030], however 727 no protection is provided for the 'giaddr' field in DHCPv4. 728 ([RFC3315], Section 21) specifies mechanisms for DHCPv6 message 729 authentication. 731 For IPv6, if the LMMD is configured to perform authentication, an 732 IPSEC security association MUST be used to protect all relayed 733 messages between the AR and MAP. For IPv4, if the LMMD is configured 734 to perform authentication, either IPSEC security associations MUST be 735 used to protect relayed messages, and/or the AR and MAP MUST include 736 an Authentication sub-option [RFC4030] in the Relay Agent Option in 737 relayed messages and responses. Any relayed messages or responses 738 that can not be successfully authenticated MUST be discarded if the 739 LMMD is configured to perform authentication. 741 The ARP mechanism used by IPv4 is insecure, while IPv6 Neighbor 742 Discovery can use the securing mechanisms of SEND [RFC3971]. 744 10. Related Work 746 The MITRE MobileMesh approach suggests a MAPless backhaul network 747 with a fully-connected mesh of tunnels between ARs. Telcordia has 748 proposed DHCP-related solutions for the CECOM MOSAIC program. The 749 Cisco LAM mechanism operates by injecting host routes for MNs into 750 the backhaul network's intra-domain routing protocol. Hierarchical 751 Mobile IPv6 (HMIPv6) has each AR advertise a different IP subnet 752 prefix on the access network. The IETF NETLMM approach advocates 753 intelligent ARs for handling mobility and simple MNs that do not get 754 involved with mobility-related signaling. Various proposals targeted 755 for the IETF AUTOCONF working group have suggested stateless 756 mechanisms for address configuration. 758 The Naval Research Lab (NRL) Information Technology Division uses 759 DHCP in their MANET research testbeds. 761 11. Implementation Status 763 Boeing and MITRE have developed independent working implementations 764 of the -02 version of this specification. 766 12. Acknowledgements 768 The following individuals have provided valuable input: Marcelo 769 Albuquerque, Ralph Droms, Wojtek Furmanski, Thomas Henderson, Long 770 Ho, James Kempf, Akber Qureshi, Bernie Volz. 772 Alexandru Petrescu mentioned DHCP in NETLMM mailing list discussions. 773 Julien Laganier proposed a proxy DAD mechanism for use in LMMDs that 774 include shared links. 776 13. References 778 13.1. Normative References 780 [I-D.ietf-dhc-dhcpv6-agentopt-delegate] 781 Droms, R., "DHCPv6 Relay Agent Assignment Notification 782 (RAAN) Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-01 783 (work in progress), August 2006. 785 [I-D.volz-dhc-dhcpv6-srsn-option] 786 Volz, B. and R. Droms, "DHCPv6 Server Reply Sequence 787 Number Option", draft-volz-dhc-dhcpv6-srsn-option-00 (work 788 in progress), August 2006. 790 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 791 September 1981. 793 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 794 converting network protocol addresses to 48.bit Ethernet 795 address for transmission on Ethernet hardware", STD 37, 796 RFC 826, November 1982. 798 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 799 September 1985. 801 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 802 September 1991. 804 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 805 Requirement Levels", BCP 14, RFC 2119, March 1997. 807 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 808 RFC 2131, March 1997. 810 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 811 (IPv6) Specification", RFC 2460, December 1998. 813 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 814 Discovery for IP Version 6 (IPv6)", RFC 2461, 815 December 1998. 817 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 818 Autoconfiguration", RFC 2462, December 1998. 820 [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP 821 reconfigure extension", RFC 3203, December 2001. 823 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 824 and M. Carney, "Dynamic Host Configuration Protocol for 825 IPv6 (DHCPv6)", RFC 3315, July 2003. 827 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 828 Static Route Option for Dynamic Host Configuration 829 Protocol (DHCP) version 4", RFC 3442, December 2002. 831 13.2. Informative References 833 [E2E] Salzer, J., Reed, D., and D. Clark, "End-to-end Arguments 834 in System Design", ACM ToCS , November 1984. 836 [I-D.ietf-dhc-subnet-alloc] 837 Johnson, R., "Subnet Allocation Option", 838 draft-ietf-dhc-subnet-alloc-03 (work in progress), 839 June 2005. 841 [I-D.ietf-netlmm-mn-ar-if] 842 Laganier, J., "Network-based Localized Mobility Management 843 Interface between Mobile Node and Access Router", 844 draft-ietf-netlmm-mn-ar-if-01 (work in progress), 845 June 2006. 847 [I-D.ietf-netlmm-nohost-ps] 848 Kempf, J., "Problem Statement for Network-based Localized 849 Mobility Management", draft-ietf-netlmm-nohost-ps-05 (work 850 in progress), September 2006. 852 [I-D.ietf-netlmm-nohost-req] 853 Kempf, J., "Goals for Network-based Localized Mobility 854 Management (NETLMM)", draft-ietf-netlmm-nohost-req-05 855 (work in progress), October 2006. 857 [I-D.ietf-netlmm-threats] 858 Kempf, J. and C. Vogt, "Security Threats to Network-Based 859 Localized Mobility Management", 860 draft-ietf-netlmm-threats-04 (work in progress), 861 September 2006. 863 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 864 Messages", RFC 3118, June 2001. 866 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 867 Host Configuration Protocol (DHCP) version 6", RFC 3633, 868 December 2003. 870 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 871 Configuration of IPv4 Link-Local Addresses", RFC 3927, 872 May 2005. 874 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 875 Neighbor Discovery (SEND)", RFC 3971, March 2005. 877 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 878 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 879 Option", RFC 4030, March 2005. 881 [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for 882 the Dynamic Host Configuration Protocol version 4 883 (DHCPv4)", RFC 4039, March 2005. 885 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 886 Addresses", RFC 4193, October 2005. 888 Appendix A. Nested LMMD Model 890 The MAP function can be distributed among the ARs if each AR 891 configures a DHCP server that delegates addresses from its own 892 distinct IP prefix range. Each MN would receive IP address/prefix 893 delegations from their "home" AR. In other words, each AR (and its 894 associated MNs) appears as a nested LMMD within a larger encompassing 895 LMMD. 897 In this scenario, each AR configures a hybrid router/DHCP server/ 898 relay/client. The client function requests prefix delegations from a 899 DHCP server, and the server function delegates IP addresses/prefixes 900 from those IP prefixes. The relay function relays DHCP requests and 901 responses to support mobility and to mitigate the effects of errors 902 such as loss of an AR or partitioning of the backhaul network. Each 903 AR also advertises reachability to its IP prefix range via the 904 backhaul network IGP. 906 A MN obtains address/prefix delegations as specified in Section 5.1. 907 The difference is that the AR is also the MAP and allocates 908 addresses/prefixes from its prefix rather than relaying messages to a 909 MAP. 911 If the MN roams from its home AR, it selects a "visited" AR which 912 relays the MN's DHCP messages to the home AR. The home AR updates 913 its routing information and sends a route update to the current 914 visited AR and previous visited AR (if any). 916 In this model, failure of an AR results in packet loss and MN 917 unreachability until MNs associate with a new visited AR. Such 918 failure cases can possibly be mitigated by supporting functions in 919 the backhaul network (TBD). 921 Appendix B. Change Log 923 (RFC Editor - this section to be deleted before publication as an 924 RFC): 926 Changes from -03 to -04: 928 o support for AR-initiated updates for fast handovers 930 o support for IPv6 MNs that use SLAAC 932 Changes from -02 to -03: 934 o specified explicit AR<->MAP protocol for route management using 935 standard DHCP mechanisms 937 o added new sections on RFC Editor Notes and Implementation Status 939 o added new co-author 941 Changes from -01 to -02: 943 o added clarification that RAs need not include prefix options; if 944 none are included the MN can use DHCP prefix delegation. 946 o added point on MN sending multicast/broadcast control messages to 947 the unicast Layer-2 address of an AR. 949 o updated "MAP Operations", "IPv6 advantages" and "Multilink Subnet 950 Considerations" sections. 952 o shortened Introduction and Appendix B. 954 o various editorial changes 956 Changes from -00 to -01: 958 o updated figure 1. 960 o added new appendices on nested LMMD model and failure cases for 961 the network-based signaling. 963 o added text under "AR operation" and "Non-Standard Behavior" for 964 route management. 966 o removed "over the backhaul network" from "MAP operation" in the 967 passage on MAP synchronization. 969 o changed "IP Version Differences" section title to "IPv6 970 Advantages". 972 o changed document title. 974 Authors' Addresses 976 Fred L. Templin (editor) 977 Boeing Phantom Works 978 P.O. Box 3707 MC 7L-49 979 Seattle, WA 98124 980 USA 982 Email: fred.l.templin@boeing.com 984 Steven W. Russet (editor) 985 Boeing Phantom Works 986 P.O. Box 3707 MC 7L-49 987 Seattle, WA 98124 988 USA 990 Email: steven.w.russert@boeing.com 992 Kevin Grace (editor) 993 The MITRE Corporation 994 202 Burlington Rd. 995 Bedford, MA 01730 996 USA 998 Email: kgrace@mitre.org 1000 Full Copyright Statement 1002 Copyright (C) The Internet Society (2006). 1004 This document is subject to the rights, licenses and restrictions 1005 contained in BCP 78, and except as set forth therein, the authors 1006 retain all their rights. 1008 This document and the information contained herein are provided on an 1009 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1010 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1011 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1012 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1013 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1014 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1016 Intellectual Property 1018 The IETF takes no position regarding the validity or scope of any 1019 Intellectual Property Rights or other rights that might be claimed to 1020 pertain to the implementation or use of the technology described in 1021 this document or the extent to which any license under such rights 1022 might or might not be available; nor does it represent that it has 1023 made any independent effort to identify any such rights. Information 1024 on the procedures with respect to rights in RFC documents can be 1025 found in BCP 78 and BCP 79. 1027 Copies of IPR disclosures made to the IETF Secretariat and any 1028 assurances of licenses to be made available, or the result of an 1029 attempt made to obtain a general license or permission for the use of 1030 such proprietary rights by implementers or users of this 1031 specification can be obtained from the IETF on-line IPR repository at 1032 http://www.ietf.org/ipr. 1034 The IETF invites any interested party to bring to its attention any 1035 copyrights, patents or patent applications, or other proprietary 1036 rights that may cover technology that may be required to implement 1037 this standard. Please address the information to the IETF at 1038 ietf-ipr@ietf.org. 1040 Acknowledgment 1042 Funding for the RFC Editor function is provided by the IETF 1043 Administrative Support Activity (IASA).