idnits 2.17.00 (12 Aug 2021) /tmp/idnits50143/draft-droms-nemo-dhcpv6-pd-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (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 (February 6, 2004) is 6679 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: '10' is defined on line 401, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 405, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 409, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (ref. '2') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3513 (ref. '3') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3633 (ref. '4') (Obsoleted by RFC 8415) == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 == Outdated reference: draft-ietf-nemo-basic-support has been published as RFC 3963 == Outdated reference: draft-ietf-nemo-requirements has been published as RFC 4886 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '7') == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '8') == Outdated reference: A later version (-07) exists of draft-thubert-nemo-reverse-routing-header-02 -- Possible downref: Normative reference to a draft: ref. '9' -- No information found for draft-ietf-mobileip-hmipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: draft-ietf-manet-dsr has been published as RFC 4728 ** Downref: Normative reference to an Experimental draft: draft-ietf-manet-dsr (ref. '11') == Outdated reference: draft-ietf-manet-aodv has been published as RFC 3561 ** Downref: Normative reference to an Experimental draft: draft-ietf-manet-aodv (ref. '12') ** Obsolete normative reference: RFC 3041 (ref. '13') (Obsoleted by RFC 4941) Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Group R. Droms 3 Internet-Draft P. Thubert 4 Expires: August 6, 2004 Cisco 5 February 6, 2004 7 DHCPv6 Prefix Delegation for NEMO 8 draft-droms-nemo-dhcpv6-pd-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 6, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 One aspect of network mobility support is the assignment of a prefix 39 or prefixes to a mobile router (MR) for use on the links in the 40 mobile network. DHCPv6 prefix delegation can be used for this 41 configuration task. 43 1. Introduction 45 One aspect of network mobility support is the assignment of a prefix 46 or prefixes to a mobile router for use on the links in the mobile 47 network. DHCPv6 prefix delegation [4] (DHCPv6PD) can be used for 48 this configuration task, whether from the Home Network or locally 49 from an Access Network. 51 2. Terminology 53 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 54 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 55 interpreted as described in RFC2119 [1]. 57 The following terms used in this document are defined in the IPv6 58 Addressing Architecture document [3]: 60 link-local unicast address 62 link-local scope multicast address 64 The following terms used in this document are defined in the mobile 65 IPv6 specification [5]: 67 home agent (HA) 69 home link 71 The following terms used in this document are defined in the mobile 72 network terminology document [8]: 74 mobile router (MR) 76 mobile network 78 mobile host (MH) 80 The following terms used in this document are defined in the DHCPv6 81 [2] and DHCPv6 prefix delegation [4] specifications: 83 delegating router (DR) 85 requesting router (RR) 87 DHCPv6 relay agent 89 3. Application of DHCPv6 prefix delegation to mobile networks 91 The network mobility requirements document [7] defines a solution for 92 mobile IPv6 networks based on the mobile IPv6 protocol [5]. In this 93 solution, a MR uses the mobile IPv6 protocol to establish a maintain 94 a session with its HA, and uses bidirectional tunneling between the 95 MR and HA to provide a path through which hosts attached to links in 96 the mobile network can maintain connectivity with nodes not in the 97 mobile network. 99 The requirements in basic network mobility support [7] include the 100 ability of the MR to receive delegated prefixes that can then be 101 assigned to links in the mobile network. DHCPv6PD can be used to 102 meet this requirement for prefix delegation. 104 3.1 Delegating Home prefixes 106 To use DHCPv6PD for mobile networks, the HA assumes the role of the 107 DR and the MR assumes the role of the RR. Throughout the remainder of 108 this document, the HA will be assumed to be acting as a DHCPv6PD DR 109 and the MR will be assumed to be acting as a RR. 111 The HA and MR exchange DHCPv6PD protocol messages through the tunnel 112 connecting them. The tunnel acts as the link labeled "DSL to 113 subscriber premises" in figure 1 of the DHCPv6PD specification. 115 The HA (acting as the DR) is provisioned with prefixes to be assigned 116 using any of the prefix assignment mechanisms described in the 117 DHCPv6PD specifications. Other updates to the HA data structures 118 required as a side effect of prefix delegation are specified by the 119 particular network mobility protocol. For example, in the case of 120 Basic Network Mobility Support [6], the HA would add an entry in its 121 binding cache registering the delegated prefix to the MR to which the 122 prefix was delegated. 124 3.1.1 Use of HA-MR tunnel for DHCPv6 messages 126 The DHCPv6 specification requires the use of link-local unicast and 127 link-local scope multicast addresses in DHCPv6 messages (except in 128 certain cases as defined in section 22.12 of the DHCPv6 129 specification). Section 10.4.2 of the mobile IPv6 specification 130 describes forwarding of intercepted packets, and the third paragraph 131 of that section begins: 133 However, packets addressed to the mobile node's link-local address 134 MUST NOT be tunneled to the mobile node. 136 The DHCPv6 messages exchanged between the HA and the MR originate 137 only with the HA and the MR, and therefore are not "intercepted 138 packets" and may be sent between the HA and the MR through the 139 tunnel. 141 3.1.2 Exchanging DHCPv6 messages when HA and MR are on the same link 143 When the MR is on its home link, the HA uses the home link to 144 exchange DHCPv6PD messages with the MR, even if there is a tunnel 145 across the home link between the MR and the HA. It is the 146 responsibility of the implementation to determine when the MR is on 147 its home link and to avoid use of any existing tunnel. 149 3.1.3 Location of DHCPv6PD Delegating Router function 151 The DHCPv6PD DR function MUST be implemented in the HA for the MR. 152 The use of a DHCPv6 relay agent is not defined for DHCPv6PD. 154 3.1.4 Other DHCPv6 functions 156 The DHCPv6 messages exchanged between the MR and the HA may also be 157 used for other DHCPv6 functions in addition to DHCPv6PD. For 158 example, the HA may assign global addresses to the MR and may pass 159 other configuration information such as a list of available DNS 160 recursive resolvers to the MR using the same DHCPv6 messages as used 161 for DHCPV6PD. 163 The HA may act as a DHCPv6 relay agent for MHs while it acts as a DR 164 for MRs. 166 3.2 Delegating Access Prefixes 168 A Mobile Router may also obtain a temporary delegated prefix from its 169 Access Router (acting as a DHCPv6PD DR) while the MR is roaming 170 within the AR space. 172 This is used for instance if the MR opens a network for anonymous 173 visitors to roam in. In that model, the delegated network is 174 advertised in the clear, as opposed to the MR's own Mobile Network 175 Prefixes, which can stay private, over secured media. 177 As a result, the CareOf Addresses of the visitors in a nested 178 structure are all aggregated by a larger prefix owned, subdelegated, 179 and advertised to the infrastructure by the Access Router itself. 181 It is possible to protect the privacy of both parties between a VMN 182 that implements RFC 3041 [13] and a visited MR that advertises only 183 the delegated prefixes in the clear. 185 In the case of a nested structure, it is expected that the AR and the 186 MR maintain a tunnel and that the connectivity between the two is 187 maintained somehow; this can be achieved by: 189 Performing a routing protocol such as a MANET within the nested 190 topology. 192 performing some L3 bridging technique between AR and MRs. 194 placing a Nemo Home Agent at the AR so that the MR registers the 195 mobility of the delegated prefix while it is roaming inside or 196 outside the nested structure below the AR. 198 It may be beneficial for the Mobile Router to use its address within 199 its delegated prefix as CareOf to register to its Home Agent. As a 200 result, the MR gets some advantages similar to those obtained with 201 HMIP. 203 In particular, if the Access Router is a Home Agent for the 204 aggregation of delegated prefixes, and if that Home Agent supports 205 the Reverse Routing Header (see [9]), then there are only 2 tunnels, 206 the MRAR encapsulating the MRHA tunnel whatever the nested depth of 207 the MR. 209 3.2.1 New Tree Information Option Format 211 This draft modifies the Tree Information option, as described in [9], 212 adding a new bit to indicate that the TLMR supports DHCP-PD. 214 The new bit are set by the TLMR are propagated transparently by the 215 MRs. Mobile Routers SHOULD add that option to the Router 216 Advertisement messages sent over the ingress interfaces. 218 The Tree Information option has the following format: 220 0 1 2 3 221 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Type | Length = 6 | TreePreference| TreeDepth | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 |G|H|D|Reserved | Bandwidth | DelayTime | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | MRPreference | BootTimeRandom | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | PathCRC | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | | 232 + + 233 | | 234 + Tree TLMR Identifier + 235 | | 236 + + 237 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | 240 + + 241 | | 242 + Tree Group + 243 | | 244 + + 245 | | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Type 250 8-bit unsigned integer set to 10 by the TLMR. 252 Length 254 8-bit unsigned integer set to 6 by the TLMR. The length of the 255 option (including the type and length fields) in units of 8 256 octets. 258 TreePreference 260 8-bit unsigned integer set by the TLMR to its configured 261 preference. Range from 0 = lowest to 255 = highest. 263 TreeDepth 265 8-bit unsigned integer set to 0 by the TLMR and incremented by 1 266 by each MR down the tree. 268 Grounded (G) 270 1-bit flag. Set by the TLMR to indicate that it is either attached 271 to a fixed network or at home. 273 Home Agent (H) 275 1-bit flag. Set by the TLMR to indicate that it is also 276 functioning as a Home Agent, for re-homing purposes. 278 Home (D) 280 1-bit flag. Set by the TLMR to indicate that it is also 281 functioning as a DHCPv6PD-DR. 283 Reserved 285 6-bit unsigned integer, set to 0 by the TLMR. 287 Bandwidth 289 8-bit unsigned integer set by the TLMR and decremented by MRs with 290 lower egress bandwidth. This is a power of 2 so that the available 291 egress bandwidth in bps is between 2^Bandwidth and 292 2^(Bandwidth+1). 0 means 'unspecified' and can not be modified 293 down the tree. 295 DelayTime 297 16-bit unsigned integer set by the TLMR. Tree time constant in 298 milliseconds. 300 MRPreference 302 8-bit signed integer. Set by each MR to its configured preference. 303 Range from 0 = lowest to 255 = highest. 305 BootTimeRandom 307 24-bit unsigned integer set by each MR to a random value that the 308 MR generates at boot time. 310 PathCRC 312 32-bit unsigned integer CRC, updated by each MR. This is the 313 result of a CRC-32c computation on a bit string obtained by 314 appending the received value and the MR CareOf Address. TLMRs use 315 a 'previous value' of zeroes to initially set the pathCRC. 317 Tree TLMR Identifier 319 IPv6 global address, set by the TLMR. Identifier of the tree. 321 Tree Group 323 IPv6 global address, set by the TLMR. Identifier of the tree 324 group. A MR may use the Tree Group in its tree selection 325 algorithm. 327 The AR MUST include this option in its Router Advertisements, placing 328 itself as TLMR. 330 A MR receiving this option from its Attachment Router MUST update the 331 TreeDepth, MRPreference, BootTimeRandom and PathCRC fields, and MUST 332 propagate it on its ingress interface(s), as described in [9]. 334 The alignment requirement of the Tree Information option is 8n. 336 4. Security Considerations 338 This document describes the use of DHCPv6 for prefix delegation in 339 mobile networks. It does not introduce any additional security 340 considerations beyond those described in the "Security 341 Considerations" section of the DHCPv6 base specification [2] and the 342 "Security Considerations" of the DHCPv6 Prefix Delegation 343 specification [4]. 345 Following the DHCPv6 Prefix Delegation specification, HAs and MRs 346 SHOULD use DHCPv6 authentication as described in section 347 "Authentication of DHCP messages" of the DHCPv6 specification [2], to 348 guard against attacks mounted through prefix delegation. 350 5. IANA Considerations 352 This document describes the use of DHCPv6 for prefix delegation in 353 mobile networks. It does not introduce any additional IANA 354 considerations. 356 6. Terms of Use 358 Cisco has a pending patent which relates to the subject matter of 359 this Internet Draft. If a standard relating to this subject matter is 360 adopted by IETF and any claims of any issued Cisco patents are 361 necessary for practicing this standard, any party will be able to 362 obtain a license from Cisco to use any such patent claims under 363 openly specified, reasonable, non-discriminatory terms to implement 364 and fully comply with the standard. 366 Normative References 368 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 369 Levels", BCP 14, RFC 2119, March 1997. 371 [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 372 Carney, "Dynamic Host Configuration Protocol for IPv6 373 (DHCPv6)", RFC 3315, July 2003. 375 [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 376 Addressing Architecture", RFC 3513, April 2003. 378 [4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 379 Configuration Protocol (DHCP) version 6", RFC 3633, December 380 2003. 382 [5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 383 IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 384 2003. 386 [6] Devarapalli, V., "Nemo Basic Support Protocol", 387 draft-ietf-nemo-basic-support-02 (work in progress), December 388 2003. 390 [7] Ernst, T., "Network Mobility Support Goals and Requirements", 391 draft-ietf-nemo-requirements-01 (work in progress), May 2003. 393 [8] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 394 draft-ietf-nemo-terminology-00 (work in progress), May 2003. 396 [9] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and 397 its application to Mobile Networks", 398 draft-thubert-nemo-reverse-routing-header-02 (work in 399 progress), June 2003. 401 [10] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier, 402 "Hierarchical Mobile IPv6 mobility management (HMIPv6)", 403 draft-ietf-mobileip-hmipv6-08 (work in progress), July 2003. 405 [11] Johnson, D., "The Dynamic Source Routing Protocol for Mobile Ad 406 Hoc Networks (DSR)", draft-ietf-manet-dsr-09 (work in 407 progress), April 2003. 409 [12] Perkins, C., Royer, E. and S. Das, "Ad Hoc On Demand Distance 410 Vector (AODV) Routing", draft-ietf-manet-aodv-13 (work in 411 progress), February 2003. 413 [13] Narten, T. and R. Draves, "Privacy Extensions for Stateless 414 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 416 Authors' Addresses 418 Ralph Droms 419 Cisco 420 1414 Massachusetts Avenue 421 Boxborough, MA 01719 422 USA 424 Phone: +1 978.936.1674 425 EMail: rdroms@cisco.com 427 Pascal Thubert 428 Cisco 429 Village d'Entreprises Green Side 430 400, Avenue Roumanille 431 Biot - Sophia Antipolis 06410 432 FRANCE 434 EMail: pthubert@cisco.com 436 Appendix A. Changes since version 00 438 The section on access prefix delegation was added. That section 439 provides a mechanism that is very close to HMIP but purely based on 440 standard DHCP-PD. It is limited to Nemo applications, but it provides 441 additional features, including the privacy of the mobile access 442 router. 444 Intellectual Property Statement 446 The IETF takes no position regarding the validity or scope of any 447 intellectual property or other rights that might be claimed to 448 pertain to the implementation or use of the technology described in 449 this document or the extent to which any license under such rights 450 might or might not be available; neither does it represent that it 451 has made any effort to identify any such rights. Information on the 452 IETF's procedures with respect to rights in standards-track and 453 standards-related documentation can be found in BCP-11. Copies of 454 claims of rights made available for publication and any assurances of 455 licenses to be made available, or the result of an attempt made to 456 obtain a general license or permission for the use of such 457 proprietary rights by implementors or users of this specification can 458 be obtained from the IETF Secretariat. 460 The IETF invites any interested party to bring to its attention any 461 copyrights, patents or patent applications, or other proprietary 462 rights which may cover technology that may be required to practice 463 this standard. Please address the information to the IETF Executive 464 Director. 466 Full Copyright Statement 468 Copyright (C) The Internet Society (2004). All Rights Reserved. 470 This document and translations of it may be copied and furnished to 471 others, and derivative works that comment on or otherwise explain it 472 or assist in its implementation may be prepared, copied, published 473 and distributed, in whole or in part, without restriction of any 474 kind, provided that the above copyright notice and this paragraph are 475 included on all such copies and derivative works. However, this 476 document itself may not be modified in any way, such as by removing 477 the copyright notice or references to the Internet Society or other 478 Internet organizations, except as needed for the purpose of 479 developing Internet standards in which case the procedures for 480 copyrights defined in the Internet Standards process must be 481 followed, or as required to translate it into languages other than 482 English. 484 The limited permissions granted above are perpetual and will not be 485 revoked by the Internet Society or its successors or assignees. 487 This document and the information contained herein is provided on an 488 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 489 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 490 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 491 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 492 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 494 Acknowledgment 496 Funding for the RFC Editor function is currently provided by the 497 Internet Society.