idnits 2.17.1 draft-ietf-nemo-dhcpv6-pd-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 445. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 458. ** 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 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 27, 2006) is 6605 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) -- Looks like a reference, but probably isn't: 'RFC 3775' on line 172 -- Looks like a reference, but probably isn't: 'RFC 3963' on line 280 -- Looks like a reference, but probably isn't: 'RFC3775' on line 279 ** Obsolete normative reference: RFC 3633 (ref. '1') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3513 (ref. '3') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3775 (ref. '4') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-04 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '5') ** Obsolete normative reference: RFC 3315 (ref. '6') (Obsoleted by RFC 8415) == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '7') == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-agentopt-delegate-00 Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 10 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 31, 2006 Cisco 5 February 27, 2006 7 DHCPv6 Prefix Delegation for NEMO 8 draft-ietf-nemo-dhcpv6-pd-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 31, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 One aspect of network mobility support is the assignment of a prefix 42 or prefixes to a Mobile Router (MR) for use on the links in the 43 Mobile Network. DHCPv6 prefix delegation can be used for this 44 configuration task. 46 1. Introduction 47 One aspect of network mobility support is the assignment of a prefix 48 or prefixes to a Mobile Router for use on the links in the Mobile 49 Network. DHCPv6 prefix delegation [1] (DHCPv6PD) can be used for 50 this configuration task. 52 2. Terminology 54 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 55 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 56 interpreted as described in RFC2119 [2]. 58 The following terms used in this document are defined in the IPv6 59 Addressing Architecture document [3]: 60 link-local unicast address 61 link-local scope multicast address 63 The following terms used in this document are defined in the mobile 64 IPv6 specification [4]: 65 home agent (HA) 66 home link 68 The following terms used in this document are defined in the Mobile 69 Network terminology document [5]: 70 Mobile Router (MR) 71 Mobile Network 72 mobile host (MH) 74 The following terms used in this document are defined in the DHCPv6 75 [6] and DHCPv6 prefix delegation [1] specifications: 76 delegating router (DR) 77 requesting router (RR) 78 DHCPv6 relay agent 80 3. Application of DHCPv6 prefix delegation to mobile networks for 81 delegation of home prefixes 83 The NEMO Basic protocol [8] extends the mobile IPv6 protocol [4] to 84 enable network mobility. In this extension, a MR uses the mobile 85 IPv6 protocol to establish a maintain a session with its HA, and uses 86 bidirectional tunneling between the MR and HA to provide a path 87 through which hosts attached to links in the Mobile Network can 88 maintain connectivity with nodes not in the Mobile Network. 90 The requirements for NEMO [7] include the ability of the MR to 91 receive delegated prefixes that can then be assigned to links in the 92 Mobile Network. DHCPv6PD can be used to meet this requirement for 93 prefix delegation. 95 To use DHCPv6PD for Mobile Networks, the HA assumes the role of 96 either the DR or a DHCPv6 relay agent and the MR assumes the role of 97 the RR. Throughout the remainder of this document, the HA will be 98 assumed to be acting as a DHCPv6PD DR or relay agent and the MR will 99 be assumed to be acting as a RR. 101 If the HA is acts as relay agent, some other device acts as the DR. 102 For example, the server providing DHCPv6 service in the home network 103 might also provide NEMO DHCPv6PD service. Or, a home network with 104 several HAs might configure one of those HAs as a DHCPv6PD server 105 while the other HAs act as relay agents. 107 The HA and MR exchange DHCPv6PD protocol messages through the tunnel 108 connecting them. The tunnel acts as the link labeled "DSL to 109 subscriber premises" in figure 1 of the DHCPv6PD specification. 111 The DHCPv6PD server is provisioned with prefixes to be assigned using 112 any of the prefix assignment mechanisms described in the DHCPv6PD 113 specifications. Other updates to the HA data structures required as 114 a side effect of prefix delegation are specified by the particular 115 network mobility protocol. For example, in the case of Basic Network 116 Mobility Support [8], the HA would add an entry in its binding cache 117 registering the delegated prefix to the MR to which the prefix was 118 delegated. 120 3.1. When the MR uses DHCPv6 122 The MR initiates a DHCPv6 message exchange for prefix delegation 123 whenever it establishes an MRHA tunnel to its HA. If the MR does not 124 have any active delegated prefixes (with unexpired leases), the MR 125 initiates a DHCPv6 message exchange with a DHCPv6 Solicit message as 126 described in section 17 of RFC 3315 and section 12 of RFC 3633. If 127 the MR has one or more active delegated prefixes, the MR initiates a 128 DHCPv6 message exchange with a DHCPv6 Confirm message as described in 129 section 18.1.2 of RFC 3315 and section 12 of RFC 3633. 131 3.2. Use of MRHA tunnel for DHCPv6 messages 133 The DHCPv6 specification requires the use of link-local unicast and 134 link-local scope multicast addresses in DHCPv6 messages (except in 135 certain cases as defined in section 22.12 of the DHCPv6 136 specification). Section 10.4.2 of the mobile IPv6 specification 137 describes forwarding of intercepted packets, and the third paragraph 138 of that section begins: 140 However, packets addressed to the mobile node's link-local address 141 MUST NOT be tunneled to the mobile node. 143 The DHCPv6 messages exchanged between the HA and the MR originate 144 only with the HA and the MR, and therefore are not "intercepted 145 packets" and may be sent between the HA and the MR through the 146 tunnel. 148 Even though the MRHA tunnel is a point to point connection, the MR 149 SHOULD use multicast DHCPv6 messages as described in RFC 3315 over 150 that tunnel. 152 3.3. Exchanging DHCPv6 messages when MR is at home 154 When the MR is on its home link, the HA uses the home link to 155 exchange DHCPv6PD messages with the MR. It is the responsibility of 156 the implementation to determine when the MR is on its home link and 157 to avoid use of any existing tunnel. 159 3.4. Minimizing DHCPv6PD messages 161 DHCPv6PD in a Mobile Network can be combined with the Rapid Commit 162 option [6] to provide DHCPv6 prefix delegation with a two message 163 exchange between the mobile node and the DHCPv6 PD server. 165 3.5. DHCPv6PD and DHAAD 167 The MR acting as RR needs a direct link to the DR (or relay) 168 function. When the MR is away from Home, that link is the MRHA 169 tunnel. If a MR needs to obtain a prefix by means of DHCPv6PD, it 170 has to locate a HA that is capable of serving either as a DHCPv6PD 171 relay agent or server. Since the use of DHCPv6PD is optional and 172 comes as an addition to existing protocols [RFC 3775] and [RFC 3963], 173 it can not be expected that all HAs are DHCPv6PD capable. 175 This specification extends Dynamic Home Agent Address Discovery and 176 the Home Agent Information Option in order to enable the detection by 177 a MR of all HAs that are DHCPv6PD capable. A new 'D' bit is 178 introduced to let Home Agents advertise that they are willing to 179 participate to DHCP. Note that there is no need for the MR acting as 180 RR to know whether a HA is actually a DR or simply acting as a relay. 182 3.5.1. Modified Dynamic Home Agent Address Discovery Request 184 A new flag (D) (Support for DHCPv6PD) is introduced in the DHAAD 185 Request message, defined in [RFC3775] and [RFC 3963]. The Mobile 186 Router sets this flag to indicate that it wants to discover Home 187 Agents participating to DHCPv6 Prefix Delegation. 189 A the MR which sets the 'D' flag MUST also set the 'R' flag, to 190 declare that it is a Mobile Router and asks for a HA that supports 191 Mobile Routers, as defined in [RFC 3963]. 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Type | Code | Checksum | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Identifier |R|D| Reserved | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 DHCPv6PD Support Flag (D) 203 A one-bit flag that when set indicates that the Mobile Router 204 wants to discover Home Agents participating to DHCPv6 Prefix 205 Delegation. 207 For a description of the other fields in the message, see [RFC3775] 208 and [RFC 3963]. 210 3.5.2. Modified Dynamic Home Agent Address Discovery Reply 212 A new flag (D) (Support for DHCPv6PD) is introduced in the DHAAD 213 Reply message, defined in [RFC3775] and [RFC 3963]. If a Home Agent 214 receives a Dynamic Home Agent Discovery request message with the 215 DHCPv6PD Support Flag set, it MUST reply with a list of Home Agents 216 participating to DHCPv6PD. 218 The DHCPv6PD Support Flag MUST be set if there is at least one Home 219 Agent participating to DHCPv6PD. In that case, the reply will list 220 only those HAs that participate to DHCPv6PD, whether they act as 221 servers (DRs) or relays. 223 A HA that supports DHCPv6PD MUST support Mobile Routers as well, so 224 if the 'D' bit is set, then the 'R' bit should be set as well. So 225 there is no need in an implementation to support the case where some 226 HAs would support Mobile Routers while others would be participating 227 to DHCPv6 Prefix Delegation but none could do both. 229 If none of the Home Agents support DHCPv6PD, the Home Agent MAY reply 230 with a list of Home Agents that only support NEMO basic Mobile 231 Routers or Mobile IPv6 Mobile Nodes. In this case, the DHCPv6PD 232 Support Flag MUST be set to 0. 234 The modified message format is as follows. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Type | Code | Checksum | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Identifier |R|D| Reserved | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | | 244 + + 245 + + 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 DHCPv6PD Support Flag (D) 251 A one-bit flag that when set indicates that the Home Agents 252 listed in this message participate to DHCPv6 Prefix Delegation. 254 For a description of the other fields in the message, see [RFC3775] 255 and [RFC 3963]. 257 3.5.3. Modified Home Agent Information Option 259 A new flag (D) (Support for DHCPv6PD) is introduced in the Home Agent 260 Information Option defined in [RFC3775] and [RFC 3963]. 262 If a Home Agent participates to DHCPv6PD, it SHOULD set the flag. If 263 the HA sets the 'D' flag, then it MUST also set the 'R' flag, 264 Indicating that it supports Mobile Routers, as defined in [RFC 3963]. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type | Length |R|D| Reserved | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Home Agent Preference | Home Agent Lifetime | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 DHCPv6PD Support Flag (D) 276 A one-bit flag that when set indicates that the Home Agents 277 participates to DHCPv6 Prefix Delegation. 279 For a description of the other fields in the message, see [RFC3775] 280 and [RFC 3963]. 282 3.6. Location of DHCPv6PD Delegating Router function 284 Support of DHCPv6PD for a Mobile Network is optional. 286 The use of a DHCPv6 relay agent is not defined for DHCPv6PD in the 287 DHCPv6PD specification [1]. If the DHCPv6PD DR function is 288 implemented in the HA for the MR, no relay agent function is 289 required. 291 It may be desirable to use a single DR to manage RRs in a network 292 with multiple HAs. In this scenario, the HAs will act as DHCP relay 293 agents, forwarding messages between the RRs and the DR. 295 Use of the DHCPv6 relay agent function with DHCPv6PD requires that 296 there be some mechanism through which routing information for the 297 delegated prefixes can be added to the appropriate routing 298 infrastructure. If the HA is acting as a DHCPv6 relay agent, the HA 299 SHOULD add a route to the delegated prefix and advertise that route 300 after receiving a binding update for the prefix from the RR [8]. 302 In particular, if the MR uses NEMO explicit mode, then it must add 303 the delegated prefix to prefix list in the Binding Update messages. 304 If the binding cache is cleared before the prefix valid lifetime, the 305 MR might bind that prefix again using explicit mode, till the 306 lifetime expires. 308 In implicit mode, the HA must save the delegated prefix with the 309 binding cache entry of the Mobile Router. When the BCE is cleared, 310 the HA loses the information about the delegated prefix. Because the 311 MR will use DHCPv6 when it reestablishes its tunnel to the HA (see 312 Section 3.1), the HA will be able to add the delegated prefix back to 313 the BCE. 315 At the time this draft was written, one way in which a DR can 316 explicitly notify a relay agent about delegated prefixes, is to use 317 the "DHCP Relay Agent Assignment Notification Option" [9]. 319 Another alternative, if the RR is part of the same administrative 320 domain as the home network to which it is attached through the HA, 321 and the RR can be trusted, the RR can use a routing protocol like 322 OSPF to advertise any delegated prefixes. 324 NEMO explicit mode is recommended to take advantage of the function 325 already defined for NEMO. 327 3.7. Other DHCPv6 functions 329 The DHCPv6 messages exchanged between the MR and the HA may also be 330 used for other DHCPv6 functions in addition to DHCPv6PD. For 331 example, the HA may assign global addresses to the MR and may pass 332 other configuration information such as a list of available DNS 333 recursive resolvers to the MR using the same DHCPv6 messages as used 334 for DHCPV6PD. 336 The HA may act as a DHCPv6 relay agent for MHs while it acts as a DR 337 for MRs. 339 4. Changes in this draft 341 4.1. Revision -01 343 Removed section 3.2, "Delegating Access Prefixes". 345 Modified sections 3 and 3.6 (was section 3.1.3), "Location of 346 DHCPv6PD Delegating Router function," to allow for DHCPv6PD through a 347 relay agent and to allow for a single DR on a home network to perform 348 PD for RRs through more than one HA. 350 Added section 3.1 describing when the MR should use DHCPv6 PD. 352 Added section 3.4 describing use of Rapid Commit to minimize DHCPv6PD 353 messages and 355 Added section 3.5 recommending that DHCPv6PD and DHAAD be kept 356 independent and describing flags indicating availability of PD 357 service from HA. 359 Added section 3.7 describing the use of DHCPv6 for other 360 configuration in parallel with PD. 362 5. Security Considerations 364 This document describes the use of DHCPv6 for prefix delegation in 365 Mobile Networks. It does not introduce any additional security 366 considerations beyond those described in the "Security 367 Considerations" section of the DHCPv6 base specification [6] and the 368 "Security Considerations" of the DHCPv6 Prefix Delegation 369 specification [1]. 371 Following the DHCPv6 Prefix Delegation specification, HAs and MRs 372 SHOULD use DHCPv6 authentication as described in section 373 "Authentication of DHCP messages" of the DHCPv6 specification [6], to 374 guard against attacks mounted through prefix delegation. 376 6. IANA Considerations 378 This document describes the use of DHCPv6 for prefix delegation in 379 Mobile Networks. It does not introduce any additional IANA 380 considerations. 382 7. Normative References 384 [1] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 385 Configuration Protocol (DHCP) version 6", RFC 3633, 386 December 2003. 388 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 389 Levels", BCP 14, RFC 2119, March 1997. 391 [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 392 Addressing Architecture", RFC 3513, April 2003. 394 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 395 IPv6", RFC 3775, June 2004. 397 [5] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 398 draft-ietf-nemo-terminology-04 (work in progress), October 2005. 400 [6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 401 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 402 RFC 3315, July 2003. 404 [7] Ernst, T., "Network Mobility Support Goals and Requirements", 405 draft-ietf-nemo-requirements-05 (work in progress), 406 October 2005. 408 [8] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 409 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 410 January 2005. 412 [9] Droms, R., "DHCP Relay Agent Assignment Notification Option", 413 draft-ietf-dhc-dhcpv6-agentopt-delegate-00 (work in progress), 414 January 2006. 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 Intellectual Property Statement 438 The IETF takes no position regarding the validity or scope of any 439 Intellectual Property Rights or other rights that might be claimed to 440 pertain to the implementation or use of the technology described in 441 this document or the extent to which any license under such rights 442 might or might not be available; nor does it represent that it has 443 made any independent effort to identify any such rights. Information 444 on the procedures with respect to rights in RFC documents can be 445 found in BCP 78 and BCP 79. 447 Copies of IPR disclosures made to the IETF Secretariat and any 448 assurances of licenses to be made available, or the result of an 449 attempt made to obtain a general license or permission for the use of 450 such proprietary rights by implementers or users of this 451 specification can be obtained from the IETF on-line IPR repository at 452 http://www.ietf.org/ipr. 454 The IETF invites any interested party to bring to its attention any 455 copyrights, patents or patent applications, or other proprietary 456 rights that may cover technology that may be required to implement 457 this standard. Please address the information to the IETF at 458 ietf-ipr@ietf.org. 460 Disclaimer of Validity 462 This document and the information contained herein are provided on an 463 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 464 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 465 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 466 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 467 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 468 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 470 Copyright Statement 472 Copyright (C) The Internet Society (2006). This document is subject 473 to the rights, licenses and restrictions contained in BCP 78, and 474 except as set forth therein, the authors retain all their rights. 476 Acknowledgment 478 Funding for the RFC Editor function is currently provided by the 479 Internet Society.