idnits 2.17.1 draft-templin-autoconf-netlmm-dhcp-01.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 866. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 843. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 850. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 856. ** 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 762: '... client MUST leave the transaction I...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 562 has weird spacing: '...le Node and...' -- 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 (June 2, 2006) is 6531 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: 'E2E' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netlmm-nohost-req' is defined on line 571, but no explicit reference was found in the text ** 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 (-09) exists of draft-ietf-dna-protocol-00 == Outdated reference: A later version (-03) exists of draft-ietf-netlmm-mn-ar-if-00 == Outdated reference: A later version (-05) exists of draft-ietf-netlmm-nohost-ps-01 == Outdated reference: A later version (-05) exists of draft-ietf-netlmm-nohost-req-01 == Outdated reference: A later version (-04) exists of draft-ietf-netlmm-threats-00 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin 3 Internet-Draft S. Russert 4 Expires: December 4, 2006 I. Chakeres 5 S. Yi 6 Boeing Phantom Works 7 June 2, 2006 9 Network Localized Mobility Management using DHCP 10 draft-templin-autoconf-netlmm-dhcp-01.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 December 4, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 Mobile nodes that require global Internet access must have a way to 44 automatically configure globally routable and unique IP addresses 45 that remain stable across localized mobility events. This document 46 specifies mechanisms for address autoconfiguration (AUTOCONF) and 47 network localized mobility management (NETLMM) based on the Dynamic 48 Host Configuration Protocol (DHCP). Solutions for both IPv4 and IPv6 49 are given. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Model of Operation . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Functional Specification . . . . . . . . . . . . . . . . . . . 6 57 4.1. Mobile Node (MN) Operation . . . . . . . . . . . . . . . . 6 58 4.2. Access Router (AR) Operation . . . . . . . . . . . . . . . 7 59 4.3. Mobility Anchor Point (MAP) Operation . . . . . . . . . . 8 60 4.4. Functions Specified Only in this Document . . . . . . . . 8 61 5. Additional Considerations . . . . . . . . . . . . . . . . . . 9 62 5.1. IPv6 Advantages . . . . . . . . . . . . . . . . . . . . . 9 63 5.2. ARP/Neighbor Cache Management . . . . . . . . . . . . . . 10 64 5.3. Global Mobility Management . . . . . . . . . . . . . . . . 10 65 5.4. Duplicate Address Detection (DAD) . . . . . . . . . . . . 10 66 5.5. Multi-link Subnet Considerations . . . . . . . . . . . . . 10 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 74 Appendix A. Nested LMMD Model . . . . . . . . . . . . . . . . . . 14 75 Appendix B. Control Message Loss Implications for NETLMM . . . . 16 76 B.1. Implications for Network-Based Signaling . . . . . . . . . 16 77 B.2. Implications for Host-based Signaling . . . . . . . . . . 17 78 B.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 Appendix C. Changes since -00 . . . . . . . . . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 81 Intellectual Property and Copyright Statements . . . . . . . . . . 20 83 1. Introduction 85 Access networks (e.g., campus LANs, cellular wireless, WiFi, MANETs, 86 etc.) that connect nodes to the Internet may be prone to disturbances 87 such as congestion, signal intermittence, node movements, partitions/ 88 merges, equipment failure, etc. From a node's point of view, these 89 disturbances appear as mobility events that may cause its default 90 access router connection to fail or degrade, i.e., the node appears 91 to be mobile with respect to the access network. Such mobile nodes 92 therefore require a means to quickly select another access router as 93 network conditions change. Moreover, a mobile node requires a means 94 to procure unique and globally routable IP addresses that remain 95 stable even if its default access router changes. This can be 96 accomplished when access routers connect mobile nodes to the Internet 97 via stable backhaul networks with mobility anchor points that 98 delegate IP addresses and maintain mobile node to access router 99 mappings. 101 Mobile nodes, access routers and mobility anchor points can use the 102 Bootstrap Protocol (BOOTP) [RFC0951] and Dynamic Host Configuration 103 Protocol (DHCPv4) [RFC2131] for IPv4, or DHCPv6 [RFC3315] for IPv6, 104 as well as the associated mechanisms specified in this document to 105 provision globally routable and unique IP addresses that remain 106 stable within a localized mobility management domain. 108 Using these mechanisms, the mobile node selects a specific primary 109 access router among possibly many candidates thereby minimizing 110 control message overhead and eliminating ambiguity. In particular, 111 the mobile node is uniquely qualified to select the best primary 112 access router among possibly many candidates and is also uniquely 113 qualified to determine when it should change to a new primary access 114 router. Additionally, the mobile node receives positive/negative 115 confirmation that the correct IP address delegations and route/tunnel 116 state have been registered within the localized mobility management 117 domain such that communication failures due to black holes, address 118 duplications, etc., will not occur. 120 The model of operation described in this document corresponds to that 121 proposed for the IETF Network Localized Mobility Management (NETLMM) 122 working group [I-D.ietf-netlmm-nohost-ps] [I-D.ietf-netlmm-nohost- 123 req]. Solutions for both IPv4 [RFC0791] and IPv6 [RFC2460] are 124 given. 126 2. Terminology 128 The terminology in the normative references apply; the following 129 terms are defined within the scope of this document: 131 link 132 the same as defined in ([RFC2461], Section 2.1). 134 access network 135 a link that connects Mobile Nodes and Access Routers and may be 136 subject to congestion, signal intermittence, node movements, 137 network partitions/merges, equipment failure, etc. 139 backhaul network 140 a network that connects Access Routers and Mobility Anchor 141 Point(s) and also connects the Localized Mobility Management 142 Domain to the global Internet. 144 Mobile Node (MN) 145 a node on an access network that also acts as a DHCP client. 147 Access Router (AR) 148 a router that connects access networks to a backhaul network and 149 also acts as a DHCP/BOOTP relay agent. 151 Mobility Anchor Point (MAP) 152 a backhaul network router (and its associated DHCP server) that 153 aggregates IP prefixes in a Localized Mobility Management Domain. 155 Localized Mobility Management Domain (LMMD) 156 a set of MAPs (and their associated ARs and MNs) that provision 157 addresses from the same IP subnet prefix(es). 159 3. Model of Operation 161 The Dynamic Host Configuration Protocol (DHCP) has seen significant 162 operational experience in fielded deployments. Using the DHCP-based 163 mechanisms specified in Section 4, MNs on access networks can send 164 DHCP requests via ARs to MAPs in the backhaul network to configure 165 global IP addresses and establish MN->AR routes/tunnels in MAP IP 166 forwarding tables. Moreover, these mechanisms allow MNs to retain 167 their global IP addresses even if they change ARs within the LMMD. 168 The following figure provides a reference diagram for the DHCP-based 169 network localized mobility management solution space: 171 /-------------------------\ 172 / Internet \ 173 \ / 174 \-------+---------+-------/ 175 | | 176 /-------+---------+-------\ ---- 177 / \ ^ 178 / +-----+ \ | 179 | | MAP |-+ | | 180 | +-----+ |-+ | | 181 | +-----+ | | | 182 | +-----+ | | 183 | Backhaul Network | 184 | +-----+ +-----+ | L 185 |- - | AR1 | ..... | ARn | - -| M 186 | +-----+ +-----+ | M 187 | / \ Access / \ | D 188 | / \ Network / \ | 189 | / \ / \ | | 190 | +----+ | | 191 | | MN | -------> | | 192 \ +----+ AR change / | 193 \ / v 194 \-------------------------/ ---- 196 Figure 1: Reference Network Diagram 198 Using the mechanisms specified in Section 4, a MN discovers ARs via 199 standard IP router discovery and selects a primary AR. The MN then 200 send a unicast DHCP request to the primary AR which relays the 201 request to a MAP. The MAP delegates an IP address for the MN and 202 also creates a route/tunnel to the MN via the primary AR. The MAP 203 then sends a DHCP reply to the MN via the primary AR, and the AR 204 relays the reply to the MN. The MN now knows that it has received a 205 unique IP address delegation and knows that the MAP has established 206 the correct route and address delegation cache state. Moreover, the 207 MN can change to a new primary AR as network conditions require and 208 can immediately inform the MAP of the change. The following figure 209 presents a message exchange diagram that outlines this model of 210 operation: 212 MN AR MAP 213 | | | 214 | Router Advertisement | | 215 |<-----------------------| | 216 | DHCP Request | | 217 |----------------------->| Relayed DHCP Request | 218 | |---------------------->| create route 219 | | DHCP Reply | to MN via AR 220 | Relayed DHCP Reply |<----------------------| 221 |<-----------------------| | 222 | | | 223 ... 224 | | | 225 | | | data packet 226 | | Tunneled Packet | for MN 227 | Forwarded Packet |<======================| 228 |<-----------------------| | 230 Figure 2: Message Exchange Diagram 232 4. Functional Specification 234 The following subsections specify operation of MNs, ARs and MAPs in 235 support of address configuration and localized mobility management. 236 Items marked with (*) denote functions that are specified only in 237 this document (see: Section 4.4): 239 4.1. Mobile Node (MN) Operation 241 MNs discover ARs via standard ICMP Router Solicitation (RS) and 242 Router Advertisement (RA) messages per [RFC1256] (IPv4) or [RFC2461] 243 (IPv6). Mechanisms for detection of network attachment (DNA) for 244 IPv4 [RFC4436] or IPv6 [I-D.ietf-dna-protocol] can also be used to 245 more quickly detect and respond to AR changes. 247 When a MN first powers on, activates a network interface or when it 248 receives an indication of link change or movement to a new LMMD, it 249 uses standard mechanisms to receive RAs from neighboring ARs and (if 250 none are heard) send a small number of RSs to elicit immediate RAs. 251 After the MN receives RAs from one or more AR, it selects one or more 252 ARs as default routers and selects one AR as its primary default 253 router. 255 After the MN discovers ARs, it requests IP address delegations and/or 256 IP prefix delegations (IPv6-only [RFC3633]) by sending DHCPDISCOVER 257 (IPv4) or Solicit (IPv6) messages to the IP unicast address of the 258 primary AR (*). To reduce control message overhead, the MN can use 259 the Rapid Commit option for DHCPv4 [RFC4039] or DHCPv6 [RFC3315] to 260 enable address assignment with the exchange of just two messages 261 instead of four. 263 After address/prefix configuration, the MN issues DHCPREQUEST (IPv4), 264 Confirm or Renew (IPv6) messages to the unicast address of the 265 primary AR (*) to refresh its address lease lifetimes as long as it 266 requires continued global IP addressing services. 268 If the MN's primary AR fails (or appears to be failing), the MN 269 selects a new primary AR and sends an immediate DHCPREQUEST (IPv4), 270 Confirm or Renew (IPv6) message to the unicast address of the new 271 primary AR (*) so that the MAP(s) can quickly update their IP 272 forwarding tables (see: Section 4.3). 274 MNs can send IP packets to off-link destinations using any of the ARs 275 in their default router list as the next hop. 277 4.2. Access Router (AR) Operation 279 ARs send periodic and solicited RAs on their attached access networks 280 per [RFC1256] (IPv4) or [RFC2461] (IPv6). ARs should send periodic 281 RAs at small intervals to provide beacons for MNs to quickly discover 282 nearby ARs and detect AR failures. (The beacon interval should be 283 determined based on link characteristics of the particular access 284 network, and possibly also the mechanisms for detection of network 285 attachment (DNA).) In the IPv6 case, the RAs sent by ARs should also 286 include prefix options with the 'L' bit set to 0 for advertisement of 287 IPv6 prefixes owned by the MAP(s). 289 ARs configure a BOOTP (IPv4) or DHCPv6 (IPv6) relay agent. When an 290 AR receives a MN's DHCPDISCOVER, DHCPREQUEST (IPv4), Solicit, Confirm 291 or Renew (IPv6) message, it relays the request to one or more MAPs in 292 the backhaul network. (When the MAP and AR are co-located, the 293 request is handled by the local DHCP server.) When the AR relays the 294 request, it writes the IP address of its access network interface in 295 the BOOTP 'giaddr' field (IPv4) or DHCPv6 'peer-address' field 296 (IPv6). This means that an AR's access network interfaces must be 297 provisioned with IP addresses that are injected as host routes into 298 the backhaul network's intra-domain routing protocol. ARs must also 299 be provisioned with the IP address(es) of the MAP(s). 301 When an AR relays a MAP's DHCPACK (IPv4) or Reply (IPv6) to a MN, it 302 examines the message for delegated IP addresses/prefixes. If 303 delegated IP addresses/prefixes are included, the MN creates routes 304 in its IP forwarding table that associate the delegated IP addresses/ 305 prefixes with the MN's address in the BOOTP 'chaddr' field (for 306 DHCPv4) or the 'peer-address' (for DHCPv6) (*). 308 ARs can optionally be configured to participate as a middle party in 309 MN-to-MAP DHCP exchanges, e.g., so that appropriate policy decisions 310 can be implemented. 312 4.3. Mobility Anchor Point (MAP) Operation 314 The MAP(s) in the backhaul network act as DHCP servers and IP routers 315 for MNs in access networks. All MAPs within the same LMMD delegate 316 addresses from a common set of IP subnet prefixes and inject the 317 prefixes into the backhaul network's intra-domain routing protocol. 318 When multiple MAPs are present within the same LMMD, they synchronize 319 state to maintain a consistent view of address delegations and IP 320 routes. 322 When a MAP receives a DHCPDISCOVER (IPv4) or Solicit (IPv6) message, 323 it delegates an IP address for the MN. (Optionally in IPv6, the MAP 324 can delegate IP prefixes for the MN to be further sub-delegated to 325 its associated hosts.) After the MAP delegates an IP address/prefix, 326 it notes the unicast address of the AR from either the BOOTP 'giaddr' 327 field (IPv4) or the DHCPv6 'peer-address' field (IPv6) then 328 configures a route in its IP forwarding table and (if necessary) a 329 tunnel interface used for directing packets destined for the MN to 330 the correct AR (*). After the route is configured, the MAP returns a 331 DHCPOFFER (IPv4) or Advertise (IPv6) to the unicast address of the 332 AR. If Rapid Commit is in use, the MAP instead returns an immediate 333 DHCPACK (IPv4) or Reply (IPv6). 335 Following DHCP address delegation and IP route/tunnel configuration, 336 when a packet destined for a MN arrives at a MAP, the MAP either: a) 337 encapsulates the packet with the MN's primary AR as the destination 338 address in the outer header (i.e., tunnels the packet to the AR), or 339 b) inserts an IPv4 source routing header (likewise IPv6 routing 340 header) (*) to ensure that the packet will be forwarded through the 341 MN's primary AR. 343 The MAP retains address/prefix delegations and route/tunnel 344 configurations as long as the MN continues to use the same primary AR 345 and continues to refresh the lease lifetimes. When the MN signals a 346 change to a new primary AR, the MAP updates its cached route/tunnel 347 configurations to point to the new AR (*). When lease lifetimes 348 expire, the MAP deletes the cached address/prefix delegations and 349 their corresponding route/tunnel configurations (*). 351 4.4. Functions Specified Only in this Document 353 MNs must tightly couple their DHCP operations with the IP router 354 discovery process. In particular, MNs must send their DHCP requests 355 to the unicast address(es) of ARs discovered in RAs. Also, in order 356 to support mobility, MNs must send immediate DHCP requests whenever 357 they change to a new primary AR as a signal for MAPs to update their 358 route/tunnel entries. 360 ARs must examine DHCPACK (IPv4) or Reply (IPv6) messages and create 361 routes in their IP forwarding tables that associate delegated IP 362 addresses/prefixes with the MN's address. 364 MAPs must tightly couple the delegation of IP addresses/prefixes with 365 the establishment of routes/tunnels in their IP forwarding tables. 366 Following address/prefix delegation, MAPs must also closely monitor a 367 MN's DHCP requests to detect changes in ARs and make corresponding 368 changes to existing IP forwarding table and tunnel entries if 369 necessary. MAPs may optionally arrange for the insertion of routing 370 headers in the packets they forward instead of tunneling (e.g., to 371 reduce tunneling header overhead) but should note that this may 372 result in excessive TTL/Hop Limit decrementation. Finally MAPs must 373 delete existing IP forwarding table and tunnel entries when their 374 corresponding IP address delegations expire. 376 5. Additional Considerations 378 5.1. IPv6 Advantages 380 IPv6 RAs can carry prefix options for IPv6 stateless address 381 autoconfiguration [RFC2462] whereas IPv4 RAs only carry the 382 address(es) of routers. In the IPv6 case, all ARs in the LMMD can 383 advertise the same IPv6 prefixes on their attached access networks 384 with the 'L' bit set to 0 so that MNs can use the prefixes for 385 address auto-configuration but not on-link determination. 387 IPv6 MNs can auto-configure addresses from advertised prefixes and 388 propose them to the MAP's DHCPv6 server instead of allowing the 389 DHCPv6 server to select addresses. (The DHCPv6 server will return 390 failure codes for proposed addresses that are duplicates). This 391 allows IPv6 MNs a degree of control (not available in IPv4) to 392 configure their own addresses with interface identifiers created 393 using mechanisms such as CGAs [RFC3972] or privacy addresses 394 [I-D.ietf-ipngwg-temp-addresses-v2]. 396 MNs must quickly detect movement between different LMMDs. In IPv6, 397 the MN will see a different set of IP prefixes in RAs when it moves 398 from one LMMD to another. In IPv4, the MN can only detect movement 399 to a different LMMD based on DHCPREQUEST failures when it tries to 400 connect to a new AR (since DHCPv4 servers in different LMMDs will 401 manage different sets of IP addresses). 403 DHCPv6 provides a prefix delegation mechanism [RFC3633] that can be 404 used for assigning IP prefixes for subnets within access networks; 405 DHCPv4 does not provide a similar mechanism. 407 MNs can use local addressing for intra-access network communications 408 that do not require backhaul network transit. IPv6 provides a unique 409 local addressing (ULA) mechanism [RFC4193] which assures a high 410 probability of uniqueness even when access networks partition and 411 merge. The local addressing mechanisms provided by IPv4 [RFC1918] 412 [RFC3927] cannot assure high probability of uniqueness. 414 5.2. ARP/Neighbor Cache Management 416 In highly dynamic environments, communication failures can result due 417 to stale IPv4 ARP [RFC0826] (similarly IPv6 Neighbor Discovery 418 [RFC2461]) cache entries. MNs and ARs must therefore carefully 419 manage their IPv4 ARP (similarly IPv6 neighbor) caches to quickly 420 flush stale entries. Note that this is also true for the NETLMM 421 approach. 423 5.3. Global Mobility Management 425 When a MN leaves a LMMD and enters a new LMMD, its global IP 426 addresses are no longer topologically correct and global mobility 427 management mechanisms are needed. Currently available global 428 mobility mechanisms for IPv6 include MIPv6, HIP and MobIKE, while 429 MIPv4 is available for IPv4. A problem statement for global IP 430 mobility management is given in [I-D.njedjou-netlmm-globalmm-ps]. 432 5.4. Duplicate Address Detection (DAD) 434 DAD procedures in LMMDs are the same as for any link using the 435 mechanisms of ARP (IPv4) or IPv6 stateless address autoconfiguration 436 [RFC2462] (IPv6). 438 Additionally, a MAP's DHCP server will only delegate IP addresses/ 439 prefixes that are unique within the LMMD and will return error codes 440 for address collisions. 442 5.5. Multi-link Subnet Considerations 444 The model of operation proposed by this document (and by NETLMM) 445 constitutes a multi-link subnet in the MAP->MN direction but not in 446 the MN->Internet direction. In particular, packets destined for a MN 447 via the MAP have their IPv4 TTL (likewise IPv6 Hop Limit) decremented 448 once as they are forwarded by the MAP, possibly additional times as 449 they are forwarded along the MAP->AR path, and once as they are 450 forwarded by the AR. 452 Future versions of this document will investigate a neighbor 453 discovery proxy approach [RFC4389] to avoid multi-link subnet issues 454 (see: [I-D.thaler-intarea-multilink-subnet-issues]). 456 6. IANA Considerations 458 ARs are defined as comprising both an IP router and BOOTP/DHCPv6 459 relay agent function, but backward compatibility for legacy routers 460 on access networks may be desired (TBD). 462 If backward compatibility for legacy IPv4 routers is needed, the 463 "icmp-parameters" registry could define a new code for the ICMPv4 RA 464 type (type 9) called "BOOTP Relay Agent Present" to be included in 465 the ICMPv4 RAs sent by ARs but not those sent by legacy routers. 467 If backward compatibility for legacy IPv6 routers is needed, a new 468 bit (the 'D' bit) could be defined from the ICMPv6 RA "Reserved" 469 field. This bit would be set to 1 in ICMPv6 RAs sent by ARs with 470 DHCPv6 relay agents but not those sent by legacy routers. 472 7. Security Considerations 474 Threats relating to NETLMM [I-D.ietf-netlmm-threats] and the security 475 considerations for DHCP [RFC2131] [RFC3315] apply to this document. 477 The base DHCPv4 specification [RFC2131] does not specify securing 478 mechanisms, but DHCPv4 message authentication is specified in 479 [RFC3118]. ([RFC3315], Section 21) specifies mechanisms for DHCPv6 480 message authentication. 482 The ARP mechanism used by IPv4 is insecure, while IPv6 Neighbor 483 Discovery can use the securing mechanisms of SEND [RFC3971]. 485 8. Related Work 487 The Mitre MobileMesh approach suggests a serverless backhaul network 488 with a fully-connected mesh of tunnels between ARs. Telcordia has 489 proposed DHCP-related solutions for the CECOM MOSAIC program. The 490 Cisco LAM mechanism operates by injecting host routes for MNs into 491 the backhaul network's intra-domain routing protocol. Hierarchical 492 Mobile IPv6 (HMIPv6) has each AR advertise a different IP subnet 493 prefix on the access network. The IETF NETLMM approach advocates 494 intelligent ARs for handling mobility and simple MNs that do not get 495 involved with mobility-related signaling. Various proposals targeted 496 for the IETF AUTOCONF working group have suggested stateless 497 mechanisms for address configuration. 499 9. Acknowledgements 501 The Naval Research Lab (NRL) Information Technology Division uses 502 DHCP in their MANET research testbeds. Alexandru Petrescu mentioned 503 DHCP in NETLMM mailing list discussions. 505 The following individuals (in chronological order) have provided 506 valuable input: Marcelo Albuquerque, Thomas Henderson, Wojtek 507 Furmanski, Long Ho. 509 10. References 511 10.1. Normative References 513 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 514 September 1981. 516 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 517 converting network protocol addresses to 48.bit Ethernet 518 address for transmission on Ethernet hardware", STD 37, 519 RFC 826, November 1982. 521 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 522 September 1985. 524 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 525 September 1991. 527 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 528 RFC 2131, March 1997. 530 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 531 (IPv6) Specification", RFC 2460, December 1998. 533 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 534 Discovery for IP Version 6 (IPv6)", RFC 2461, 535 December 1998. 537 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 538 Autoconfiguration", RFC 2462, December 1998. 540 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 541 and M. Carney, "Dynamic Host Configuration Protocol for 542 IPv6 (DHCPv6)", RFC 3315, July 2003. 544 10.2. Informative References 546 [E2E] Salzer, J., Reed, D., and D. Clark, "End-to-end Arguments 547 in System Design", ACM ToCS , November 1984. 549 [I-D.ietf-dna-protocol] 550 Kempf, J., "Detecting Network Attachment in IPv6 Networks 551 (DNAv6)", draft-ietf-dna-protocol-00 (work in progress), 552 February 2006. 554 [I-D.ietf-ipngwg-temp-addresses-v2] 555 Narten, T., "Privacy Extensions for Stateless Address 556 Autoconfiguration in IPv6", 557 draft-ietf-ipngwg-temp-addresses-v2-00 (work in progress), 558 September 2002. 560 [I-D.ietf-netlmm-mn-ar-if] 561 Laganier, J. and S. Narayanan, "Network-based Localized 562 Mobility Management Interface between Mobile Node and 563 Access Router", draft-ietf-netlmm-mn-ar-if-00 (work in 564 progress), April 2006. 566 [I-D.ietf-netlmm-nohost-ps] 567 Kempf, J., "Problem Statement for IP Local Mobility", 568 draft-ietf-netlmm-nohost-ps-01 (work in progress), 569 April 2006. 571 [I-D.ietf-netlmm-nohost-req] 572 Kempf, J., "Goals for Network-based Localized Mobility 573 Management (NETLMM)", draft-ietf-netlmm-nohost-req-01 574 (work in progress), April 2006. 576 [I-D.ietf-netlmm-threats] 577 Kempf, J. and C. Vogt, "Security Threats to Network-based 578 Localized Mobility Management", 579 draft-ietf-netlmm-threats-00 (work in progress), 580 April 2006. 582 [I-D.njedjou-netlmm-globalmm-ps] 583 Njedjou, E. and J. Riera, "Problem Statement for Global IP 584 Mobility Management", draft-njedjou-netlmm-globalmm-ps-01 585 (work in progress), May 2006. 587 [I-D.thaler-intarea-multilink-subnet-issues] 588 Thaler, D., "Issues With Protocols Proposing Multilink 589 Subnets", draft-thaler-intarea-multilink-subnet-issues-00 590 (work in progress), March 2006. 592 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 593 E. Lear, "Address Allocation for Private Internets", 594 BCP 5, RFC 1918, February 1996. 596 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 597 Messages", RFC 3118, June 2001. 599 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 600 Host Configuration Protocol (DHCP) version 6", RFC 3633, 601 December 2003. 603 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 604 Configuration of IPv4 Link-Local Addresses", RFC 3927, 605 May 2005. 607 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 608 Neighbor Discovery (SEND)", RFC 3971, March 2005. 610 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 611 RFC 3972, March 2005. 613 [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for 614 the Dynamic Host Configuration Protocol version 4 615 (DHCPv4)", RFC 4039, March 2005. 617 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 618 Addresses", RFC 4193, October 2005. 620 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 621 Proxies (ND Proxy)", RFC 4389, April 2006. 623 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 624 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 626 Appendix A. Nested LMMD Model 628 The MAP function can be distributed among the ARs if each AR 629 configures a DHCP server that delegates addresses from its own IP 630 prefix range that is distinct from the IP prefix ranges delegated by 631 other ARs. In that case, each MN would receive IP address/prefix 632 delegations that are relative to their "home" AR and distinct from 633 the IP addresses/prefixes delegated by other ARs. In other words, 634 each AR (and its associated MNs) appears as a nested LMMD within a 635 larger encompassing LMMD. 637 In this scenario, each AR configures a DHCP server that delegates IP 638 addresses/prefixes from an IP prefix range that is distinct from 639 other ARs. Each AR also advertises reachability to its IP prefix 640 range via the intra-domain routing protocol on the backhaul network, 641 and configures an IP address for itself from the prefix range, e.g., 642 '2001:DB8::1'. 644 When a MN first enters a LMMD, it discovers a home AR (based on IP 645 router advertisements) and sends DHCPDISCOVER (IPv4) or Solicit 646 (IPv6) messages to the IP unicast address of the AR to request an IP 647 address/prefix delegation. After the MN receives IP address/prefix 648 delegations, it sends periodic DHCPREQUEST (IPv4), Confirm or Renew 649 (IPv6) messages to the unicast address of the primary AR to refresh 650 its address lease lifetimes as long as it requires continued global 651 IP addressing services. 653 If the MN loses its connection with its home AR, it selects a 654 "visited" AR and sends an immediate DHCPREQUEST (IPv4), Confirm or 655 Renew (IPv6) message to the unicast address of the visited AR. The 656 DHCP entity on the visited AR will note that the MNs address is 657 delegated from a different IP prefix range within the LMMD and will 658 relay the request to the IP address of the MNs home AR, e.g., '2001: 659 DB8::1". This implies that the DHCP entity on the visited AR must 660 act as a hybrid relay/server. 662 When the home AR (acting as a MAP) receives the relayed request, it 663 notes the address of the relaying AR from the BOOTP 'giaddr' field or 664 the DHCPv6 'peer-address' field then configures a route in its IP 665 forwarding table and (if necessary) a tunnel interface used for 666 directing packets destined for the MN to the visited AR. After the 667 route is configured, the MAP returns a DHCPOFFER (IPv4) or Advertise 668 (IPv6) to the unicast address of the visited AR. (In other words, 669 the home AR performs the same function that a centralized MAP would 670 ordinarily perform on behalf of MNs that are away from home.) 672 In this model, failure of an AR would result in IP readdressing and 673 dropped calls for MNs that associated with the failed AR. Such 674 failure cases can possibly be mitigated by supporting functions in 675 the backhaul network (TBD). 677 Also in this model, all ARs within the LMMD must delegate IP 678 addresses/prefixes from prefix ranges that are covered by the IP 679 prefix served by the aggregated LMMD. For example, the aggregated 680 LMMD could serve the prefix '2001:DB8::/48', and ARs within the LMMD 681 could serve subordinate prefixes such as '2001:DB8::/56', '2001:DB8: 682 0:100::/56', etc. In other words, the ARs represent nested LMMDs 683 within the aggregated LMMD. 685 Appendix B. Control Message Loss Implications for NETLMM 687 [I-D.ietf-netlmm-mn-ar-if] specifies a network-based mechanism that 688 uses a MN's duplicate address detection procedure to implicitly 689 trigger address registration signaling between the AR and the MAP, 690 while this document specifies a host-based mechanism that uses a MNs 691 DHCP requests to explicitly trigger address registration signaling 692 between the MN and the MAP. Control message loss implications for 693 both scenarios are analyzed in the following sections: 695 B.1. Implications for Network-Based Signaling 697 In the network-based signaling method specified in [I-D.ietf-netlmm- 698 mn-ar-if], if the MN configures a tentative address and sends a 699 Neighbor Solicitation (NS) message to the solicited-node multicast 700 address (see: [RFC2462], Section 5.4.2), but a control message is 701 lost somewhere on the MN<->AR<->MAP paths, the MN could incorrectly 702 conclude that its tentative address was both unique and successfully 703 registered with the MAP. The following scenarios can occur: 705 1. If the MN's multicast NS message is lost on the MN->AR path, the 706 AR will not perform address registration and the MN will receive 707 no indication that address registration failed. The MN will then 708 incorrectly assign the tentative address to an interface after 709 RetransTimer msecs (see: [RFC2462], Section 5.4). 711 2. If the AR attempts to register a MN's tentative address with the 712 MAP and the MAP returns an indication that the address was a 713 duplicate, the AR will defend the MN's tentative address by 714 sending a Neighbor Advertisement (NA) message to the all-nodes 715 multicast address on the AR->MN path as specified in ([RFC2461], 716 Section 7.2.4). But, if the NA message is lost, the MN will 717 incorrectly assign the tentative address to an interface after 718 RetransTimer msecs. 720 3. If a control message is lost on the AR<->MAP paths, the AR can 721 assume loss after a timeout period and retry the registration 722 until an acknowledgement is received. If the retries are not 723 completed within RetransTimer msecs and the address registration 724 fails (due to address duplication and/or excessive retries), the 725 MN will incorrectly assign the tentative address to an interface. 727 One possible mitigation is for the MN to set DupAddrDetectTransmits 728 (see: [RFC2462], Section 5.4) to some value greater than 1 at the 729 expense of extra control message overhead and extra delay, but this 730 mitigation can fail when more than DupAddrDetectTransmits control 731 messages are lost. A complementary mitigation is for the AR to set 732 its retry timer to some value smaller than RetransTimer/N (where N is 733 the desired number of retries) and/or for the MN to set RetransTimer 734 to some value larger than the default of 1000 msecs. But, since the 735 MN<->AR<->MAP paths may be carried over links with arbitrarily-long 736 delays, selecting appropriate timer values may be problematic in some 737 use cases. Also, this mitigation can fail when a NS/NA message is 738 lost on the MN<->AR paths. Finally, the network could attempt a 739 "just-in-time" registration for a MN that sends packets without 740 previously registering its address but such mitigations could be 741 susceptible to security and robustness-related issues. 743 B.2. Implications for Host-based Signaling 745 In the DHCP-based MN-driven case specified in this document, if a 746 control message is lost on the MN<->AR<->MAP paths, the MN will retry 747 the DHCP request until a DHCP reply is received. If excessive 748 failures occur and the MN abandons its efforts, the DHCP server may 749 have created useless address delegation state that will expire after 750 the lease lifetime expires but the MN will not incorrectly assign an 751 address to an interface. The MN is also free to try again using 752 different ARs which should lead to successful address registration 753 and acknowledgement. 755 DHCPv4 requests encode a Transaction ID ('xid') used by the client to 756 match incoming messages with pending requests, and ([RFC2131], 757 Section 4.1) states that: "Selecting a new 'xid' for each 758 retransmission is an implementation decision. A client may choose to 759 reuse the same 'xid' or select a new 'xid' for each retransmitted 760 message.". DHCPv6 requests likewise encode a Transaction ID 761 ('transaction-id'), but ([RFC3315], Section 15.1) states that: "A 762 client MUST leave the transaction ID unchanged in retransmissions of 763 a message.". 765 So, for MNs that implement a DHCPv4 client that selects a new 'xid' 766 for each retransmission, address registration may fail even after 767 successive retries if the delay across the MN<->AR<->MAP paths is 768 longer than the retransmission time. For MNs that implement a 769 DHCPv4/DHCPv6 client that uses the same Transaction ID for successive 770 retries, address registration should succeed since any DHCP reply 771 will complete the (retransmitted) DHCP request. 773 B.3. Summary 775 The network-based signaling mechanisms specified in [I-D.ietf-netlmm- 776 mn-ar-if] leave opportunity for the MN to incorrectly assign an 777 address to an interface, while the host-based signaling mechanisms 778 specified in this document do not. Therefore, applicability of the 779 network-based model must be carefully analyzed for specific use cases 780 and compared against MN complexity in the host-based method. 782 Appendix C. Changes since -00 784 o updated figure 1. 786 o added new appendices on nested LMMD model and failure cases for 787 the network-based signaling. 789 o added text under "AR operation" and "Non-Standard Behavior" for 790 route management. 792 o removed "over the backhaul network" from "MAP operation" in the 793 passage on MAP synchronization. 795 o changed "IP Version Differences" section title to "IPv6 796 Advantages". 798 o changed document title. 800 Authors' Addresses 802 Fred L. Templin 803 Boeing Phantom Works 804 P.O. Box 3707 MC 7L-49 805 Seattle, WA 98124 806 USA 808 Email: fred.l.templin@boeing.com 810 Steven W. Russet 811 Boeing Phantom Works 812 P.O. Box 3707 MC 7L-49 813 Seattle, WA 98124 814 USA 816 Email: steven.w.russert@boeing.com 818 Ian D. Chakeres 819 Boeing Phantom Works 820 P.O. Box 3707 MC 7L-49 821 Seattle, WA 98124 822 USA 824 Email: ian.chakeres@gmail.com 826 Seung Yi 827 Boeing Phantom Works 828 P.O. Box 3707 MC 7L-49 829 Seattle, WA 98124 830 USA 832 Email: seung.yi@boeing.com 834 Intellectual Property Statement 836 The IETF takes no position regarding the validity or scope of any 837 Intellectual Property Rights or other rights that might be claimed to 838 pertain to the implementation or use of the technology described in 839 this document or the extent to which any license under such rights 840 might or might not be available; nor does it represent that it has 841 made any independent effort to identify any such rights. Information 842 on the procedures with respect to rights in RFC documents can be 843 found in BCP 78 and BCP 79. 845 Copies of IPR disclosures made to the IETF Secretariat and any 846 assurances of licenses to be made available, or the result of an 847 attempt made to obtain a general license or permission for the use of 848 such proprietary rights by implementers or users of this 849 specification can be obtained from the IETF on-line IPR repository at 850 http://www.ietf.org/ipr. 852 The IETF invites any interested party to bring to its attention any 853 copyrights, patents or patent applications, or other proprietary 854 rights that may cover technology that may be required to implement 855 this standard. Please address the information to the IETF at 856 ietf-ipr@ietf.org. 858 Disclaimer of Validity 860 This document and the information contained herein are provided on an 861 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 862 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 863 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 864 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 865 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 866 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 868 Copyright Statement 870 Copyright (C) The Internet Society (2006). This document is subject 871 to the rights, licenses and restrictions contained in BCP 78, and 872 except as set forth therein, the authors retain all their rights. 874 Acknowledgment 876 Funding for the RFC Editor function is currently provided by the 877 Internet Society.