idnits 2.17.00 (12 Aug 2021) /tmp/idnits15772/draft-ietf-nemo-dhcpv6-pd-00.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 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 304. ** 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 : ---------------------------------------------------------------------------- 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 (August 4, 2005) is 6134 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) ** 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: draft-ietf-nemo-terminology has been published as RFC 4885 ** 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: draft-ietf-nemo-requirements has been published as RFC 4886 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '7') ** Obsolete normative reference: RFC 3041 (ref. '9') (Obsoleted by RFC 4941) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 7 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: February 5, 2006 Cisco 5 August 4, 2005 7 DHCPv6 Prefix Delegation for NEMO 8 draft-ietf-nemo-dhcpv6-pd-00 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 February 5, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 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 48 One aspect of network mobility support is the assignment of a prefix 49 or prefixes to a mobile router for use on the links in the mobile 50 network. DHCPv6 prefix delegation [1] (DHCPv6PD) can be used for 51 this configuration task, whether from the Home Network or locally 52 from an Access Network. 54 2. Terminology 56 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 57 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 58 interpreted as described in RFC2119 [2]. 60 The following terms used in this document are defined in the IPv6 61 Addressing Architecture document [3]: 62 link-local unicast address 63 link-local scope multicast address 65 The following terms used in this document are defined in the mobile 66 IPv6 specification [4]: 67 home agent (HA) 68 home link 70 The following terms used in this document are defined in the mobile 71 network terminology document [5]: 72 mobile router (MR) 73 mobile network 74 mobile host (MH) 76 The following terms used in this document are defined in the DHCPv6 77 [6] and DHCPv6 prefix delegation [1] specifications: 78 delegating router (DR) 79 requesting router (RR) 80 DHCPv6 relay agent 82 3. Application of DHCPv6 prefix delegation to mobile networks 84 The network mobility requirements document [7] defines a solution for 85 mobile IPv6 networks based on the mobile IPv6 protocol [4]. In this 86 solution, a MR uses the mobile IPv6 protocol to establish a maintain 87 a session with its HA, and uses bidirectional tunneling between the 88 MR and HA to provide a path through which hosts attached to links in 89 the mobile network can maintain connectivity with nodes not in the 90 mobile network. 92 The requirements in basic network mobility support [7] include the 93 ability of the MR to receive delegated prefixes that can then be 94 assigned to links in the mobile network. DHCPv6PD can be used to 95 meet this requirement for prefix delegation. 97 3.1 Delegating Home prefixes 99 To use DHCPv6PD for mobile networks, the HA assumes the role of the 100 DR and the MR assumes the role of the RR. Throughout the remainder 101 of this document, the HA will be assumed to be acting as a DHCPv6PD 102 DR and the MR will be assumed to be acting as a RR. 104 The HA and MR exchange DHCPv6PD protocol messages through the tunnel 105 connecting them. The tunnel acts as the link labeled "DSL to 106 subscriber premises" in figure 1 of the DHCPv6PD specification. 108 The HA (acting as the DR) is provisioned with prefixes to be assigned 109 using any of the prefix assignment mechanisms described in the 110 DHCPv6PD specifications. Other updates to the HA data structures 111 required as a side effect of prefix delegation are specified by the 112 particular network mobility protocol. For example, in the case of 113 Basic Network Mobility Support [8], the HA would add an entry in its 114 binding cache registering the delegated prefix to the MR to which the 115 prefix was delegated. 117 3.1.1 Use of HA-MR tunnel for DHCPv6 messages 119 The DHCPv6 specification requires the use of link-local unicast and 120 link-local scope multicast addresses in DHCPv6 messages (except in 121 certain cases as defined in section 22.12 of the DHCPv6 122 specification). Section 10.4.2 of the mobile IPv6 specification 123 describes forwarding of intercepted packets, and the third paragraph 124 of that section begins: 126 However, packets addressed to the mobile node's link-local address 127 MUST NOT be tunneled to the mobile node. 129 The DHCPv6 messages exchanged between the HA and the MR originate 130 only with the HA and the MR, and therefore are not "intercepted 131 packets" and may be sent between the HA and the MR through the 132 tunnel. 134 3.1.2 Exchanging DHCPv6 messages when HA and MR are on the same link 136 When the MR is on its home link, the HA uses the home link to 137 exchange DHCPv6PD messages with the MR, even if there is a tunnel 138 across the home link between the MR and the HA. It is the 139 responsibility of the implementation to determine when the MR is on 140 its home link and to avoid use of any existing tunnel. 142 3.1.3 Location of DHCPv6PD Delegating Router function 144 Support of DHCPv6PD in a mobile network is optional. If DHCPv6PD is 145 used then the DHCPv6PD DR function MUST be implemented in the HA for 146 the MR. The use of a DHCPv6 relay agent is not defined for DHCPv6PD. 148 3.1.4 Other DHCPv6 functions 150 The DHCPv6 messages exchanged between the MR and the HA may also be 151 used for other DHCPv6 functions in addition to DHCPv6PD. For 152 example, the HA may assign global addresses to the MR and may pass 153 other configuration information such as a list of available DNS 154 recursive resolvers to the MR using the same DHCPv6 messages as used 155 for DHCPV6PD. 157 The HA may act as a DHCPv6 relay agent for MHs while it acts as a DR 158 for MRs. 160 3.2 Delegating Access Prefixes 162 A Mobile Router may also obtain a temporary delegated prefix from its 163 Access Router (acting as a DHCPv6PD DR) while the MR is roaming 164 within the AR space. 166 This is used for instance if the MR opens a network for anonymous 167 visitors to roam in. In that model, the delegated network is 168 advertised in the clear, as opposed to the MR's own Mobile Network 169 Prefixes, which can stay private, over secured media. 171 As a result, the CareOf Addresses of the visitors in a nested 172 structure are all aggregated by a larger prefix owned, subdelegated, 173 and advertised to the infrastructure by the Access Router itself. 175 It is possible to protect the privacy of both parties between a VMN 176 that implements RFC 3041 [9] and a visited MR that advertises only 177 the delegated prefixes in the clear. 179 In the case of a nested structure, it is expected that the AR and the 180 MR maintain a tunnel and that the connectivity between the two is 181 maintained somehow; this can be achieved by: 183 o Performing a routing protocol such as a MANET within the nested 184 topology. 185 o performing some L3 bridging technique between AR and MRs. 186 o placing a Nemo Home Agent at the AR so that the MR registers the 187 mobility of the delegated prefix while it is roaming inside or 188 outside the nested structure below the AR. 190 It may be beneficial for the Mobile Router to use its address within 191 its delegated prefix as CareOf to register to its Home Agent. As a 192 result, the MR gets some advantages similar to those obtained with 193 HMIP. 195 4. Security Considerations 197 This document describes the use of DHCPv6 for prefix delegation in 198 mobile networks. It does not introduce any additional security 199 considerations beyond those described in the "Security 200 Considerations" section of the DHCPv6 base specification [6] and the 201 "Security Considerations" of the DHCPv6 Prefix Delegation 202 specification [1]. 204 Following the DHCPv6 Prefix Delegation specification, HAs and MRs 205 SHOULD use DHCPv6 authentication as described in section 206 "Authentication of DHCP messages" of the DHCPv6 specification [6], to 207 guard against attacks mounted through prefix delegation. 209 5. IANA Considerations 211 This document describes the use of DHCPv6 for prefix delegation in 212 mobile networks. It does not introduce any additional IANA 213 considerations. 215 6. Normative References 217 [1] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 218 Configuration Protocol (DHCP) version 6", RFC 3633, 219 December 2003. 221 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 222 Levels", BCP 14, RFC 2119, March 1997. 224 [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 225 Addressing Architecture", RFC 3513, April 2003. 227 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 228 IPv6", RFC 3775, June 2004. 230 [5] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 231 draft-ietf-nemo-terminology-03 (work in progress), 232 February 2005. 234 [6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 235 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 236 RFC 3315, July 2003. 238 [7] Ernst, T., "Network Mobility Support Goals and Requirements", 239 draft-ietf-nemo-requirements-04 (work in progress), 240 February 2005. 242 [8] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 243 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 244 January 2005. 246 [9] Narten, T. and R. Draves, "Privacy Extensions for Stateless 247 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 249 Authors' Addresses 251 Ralph Droms 252 Cisco 253 1414 Massachusetts Avenue 254 Boxborough, MA 01719 255 USA 257 Phone: +1 978.936.1674 258 Email: rdroms@cisco.com 260 Pascal Thubert 261 Cisco 262 Village d'Entreprises Green Side 263 400, Avenue Roumanille 264 Biot - Sophia Antipolis 06410 265 FRANCE 267 Email: pthubert@cisco.com 269 Appendix A. Changes Log 271 Rev -01: The section on access prefix delegation was added. That 272 section provides a mechanism that is very close to HMIP but purely 273 based on standard DHCP-PD. It is limited to Nemo applications, but 274 it provides additional features, including the privacy of the mobile 275 access router. 277 Rev -02: The section on optimization of access prefix delegation was 278 removed. 280 WG work item: Published as draft-ietf-nemo-dhcpv6-pd-02.txt 282 Intellectual Property Statement 284 The IETF takes no position regarding the validity or scope of any 285 Intellectual Property Rights or other rights that might be claimed to 286 pertain to the implementation or use of the technology described in 287 this document or the extent to which any license under such rights 288 might or might not be available; nor does it represent that it has 289 made any independent effort to identify any such rights. Information 290 on the procedures with respect to rights in RFC documents can be 291 found in BCP 78 and BCP 79. 293 Copies of IPR disclosures made to the IETF Secretariat and any 294 assurances of licenses to be made available, or the result of an 295 attempt made to obtain a general license or permission for the use of 296 such proprietary rights by implementers or users of this 297 specification can be obtained from the IETF on-line IPR repository at 298 http://www.ietf.org/ipr. 300 The IETF invites any interested party to bring to its attention any 301 copyrights, patents or patent applications, or other proprietary 302 rights that may cover technology that may be required to implement 303 this standard. Please address the information to the IETF at 304 ietf-ipr@ietf.org. 306 The IETF has been notified of intellectual property rights claimed in 307 regard to some or all of the specification contained in this 308 document. For more information consult the online list of claimed 309 rights. 311 Disclaimer of Validity 313 This document and the information contained herein are provided on an 314 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 315 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 316 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 317 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 318 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 319 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 321 Copyright Statement 323 Copyright (C) The Internet Society (2005). This document is subject 324 to the rights, licenses and restrictions contained in BCP 78, and 325 except as set forth therein, the authors retain all their rights. 327 Acknowledgment 329 Funding for the RFC Editor function is currently provided by the 330 Internet Society.