idnits 2.17.1 draft-droms-nemo-dhcpv6-pd-02.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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 295. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 301. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (March 28, 2005) is 6966 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: A later version (-06) exists of draft-ietf-nemo-terminology-03 ** 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-04 ** 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: 12 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Group R. Droms 2 Internet-Draft P. Thubert 3 Expires: September 29, 2005 Cisco 4 March 28, 2005 6 DHCPv6 Prefix Delegation for NEMO 7 draft-droms-nemo-dhcpv6-pd-02.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 29, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 One aspect of network mobility support is the assignment of a prefix 43 or prefixes to a mobile router (MR) for use on the links in the 44 mobile network. DHCPv6 prefix delegation can be used for this 45 configuration task. 47 1. Introduction 49 One aspect of network mobility support is the assignment of a prefix 50 or prefixes to a mobile router for use on the links in the mobile 51 network. DHCPv6 prefix delegation [1] (DHCPv6PD) can be used for 52 this configuration task, whether from the Home Network or locally 53 from an Access Network. 55 2. Terminology 57 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 58 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 59 interpreted as described in RFC2119 [2]. 61 The following terms used in this document are defined in the IPv6 62 Addressing Architecture document [3]: 63 link-local unicast address 64 link-local scope multicast address 66 The following terms used in this document are defined in the mobile 67 IPv6 specification [4]: 68 home agent (HA) 69 home link 71 The following terms used in this document are defined in the mobile 72 network terminology document [5]: 73 mobile router (MR) 74 mobile network 75 mobile host (MH) 77 The following terms used in this document are defined in the DHCPv6 78 [6] and DHCPv6 prefix delegation [1] specifications: 79 delegating router (DR) 80 requesting router (RR) 81 DHCPv6 relay agent 83 3. Application of DHCPv6 prefix delegation to mobile networks 85 The network mobility requirements document [7] defines a solution for 86 mobile IPv6 networks based on the mobile IPv6 protocol [4]. In this 87 solution, a MR uses the mobile IPv6 protocol to establish a maintain 88 a session with its HA, and uses bidirectional tunneling between the 89 MR and HA to provide a path through which hosts attached to links in 90 the mobile network can maintain connectivity with nodes not in the 91 mobile network. 93 The requirements in basic network mobility support [7] include the 94 ability of the MR to receive delegated prefixes that can then be 95 assigned to links in the mobile network. DHCPv6PD can be used to 96 meet this requirement for prefix delegation. 98 3.1 Delegating Home prefixes 100 To use DHCPv6PD for mobile networks, the HA assumes the role of the 101 DR and the MR assumes the role of the RR. Throughout the remainder 102 of this document, the HA will be assumed to be acting as a DHCPv6PD 103 DR and the MR will be assumed to be acting as a RR. 105 The HA and MR exchange DHCPv6PD protocol messages through the tunnel 106 connecting them. The tunnel acts as the link labeled "DSL to 107 subscriber premises" in figure 1 of the DHCPv6PD specification. 109 The HA (acting as the DR) is provisioned with prefixes to be assigned 110 using any of the prefix assignment mechanisms described in the 111 DHCPv6PD specifications. Other updates to the HA data structures 112 required as a side effect of prefix delegation are specified by the 113 particular network mobility protocol. For example, in the case of 114 Basic Network Mobility Support [8], the HA would add an entry in its 115 binding cache registering the delegated prefix to the MR to which the 116 prefix was delegated. 118 3.1.1 Use of HA-MR tunnel for DHCPv6 messages 120 The DHCPv6 specification requires the use of link-local unicast and 121 link-local scope multicast addresses in DHCPv6 messages (except in 122 certain cases as defined in section 22.12 of the DHCPv6 123 specification). Section 10.4.2 of the mobile IPv6 specification 124 describes forwarding of intercepted packets, and the third paragraph 125 of that section begins: 127 However, packets addressed to the mobile node's link-local address 128 MUST NOT be tunneled to the mobile node. 130 The DHCPv6 messages exchanged between the HA and the MR originate 131 only with the HA and the MR, and therefore are not "intercepted 132 packets" and may be sent between the HA and the MR through the 133 tunnel. 135 3.1.2 Exchanging DHCPv6 messages when HA and MR are on the same link 137 When the MR is on its home link, the HA uses the home link to 138 exchange DHCPv6PD messages with the MR, even if there is a tunnel 139 across the home link between the MR and the HA. It is the 140 responsibility of the implementation to determine when the MR is on 141 its home link and to avoid use of any existing tunnel. 143 3.1.3 Location of DHCPv6PD Delegating Router function 145 Support of DHCPv6PD in a mobile network is optional. If DHCPv6PD is 146 used then the DHCPv6PD DR function MUST be implemented in the HA for 147 the MR The use of a DHCPv6 relay agent is not defined for DHCPv6PD. 149 3.1.4 Other DHCPv6 functions 151 The DHCPv6 messages exchanged between the MR and the HA may also be 152 used for other DHCPv6 functions in addition to DHCPv6PD. For 153 example, the HA may assign global addresses to the MR and may pass 154 other configuration information such as a list of available DNS 155 recursive resolvers to the MR using the same DHCPv6 messages as used 156 for DHCPV6PD. 158 The HA may act as a DHCPv6 relay agent for MHs while it acts as a DR 159 for MRs. 161 3.2 Delegating Access Prefixes 163 A Mobile Router may also obtain a temporary delegated prefix from its 164 Access Router (acting as a DHCPv6PD DR) while the MR is roaming 165 within the AR space. 167 This is used for instance if the MR opens a network for anonymous 168 visitors to roam in. In that model, the delegated network is 169 advertised in the clear, as opposed to the MR's own Mobile Network 170 Prefixes, which can stay private, over secured media. 172 As a result, the CareOf Addresses of the visitors in a nested 173 structure are all aggregated by a larger prefix owned, subdelegated, 174 and advertised to the infrastructure by the Access Router itself. 176 It is possible to protect the privacy of both parties between a VMN 177 that implements RFC 3041 [9] and a visited MR that advertises only 178 the delegated prefixes in the clear. 180 In the case of a nested structure, it is expected that the AR and the 181 MR maintain a tunnel and that the connectivity between the two is 182 maintained somehow; this can be achieved by: 184 o Performing a routing protocol such as a MANET within the nested 185 topology. 186 o performing some L3 bridging technique between AR and MRs. 187 o placing a Nemo Home Agent at the AR so that the MR registers the 188 mobility of the delegated prefix while it is roaming inside or 189 outside the nested structure below the AR. 191 It may be beneficial for the Mobile Router to use its address within 192 its delegated prefix as CareOf to register to its Home Agent. As a 193 result, the MR gets some advantages similar to those obtained with 194 HMIP. 196 4. Security Considerations 198 This document describes the use of DHCPv6 for prefix delegation in 199 mobile networks. It does not introduce any additional security 200 considerations beyond those described in the "Security 201 Considerations" section of the DHCPv6 base specification [6] and the 202 "Security Considerations" of the DHCPv6 Prefix Delegation 203 specification [1]. 205 Following the DHCPv6 Prefix Delegation specification, HAs and MRs 206 SHOULD use DHCPv6 authentication as described in section 207 "Authentication of DHCP messages" of the DHCPv6 specification [6], to 208 guard against attacks mounted through prefix delegation. 210 5. IANA Considerations 212 This document describes the use of DHCPv6 for prefix delegation in 213 mobile networks. It does not introduce any additional IANA 214 considerations. 216 6. Normative References 218 [1] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 219 Configuration Protocol (DHCP) version 6", RFC 3633, December 220 2003. 222 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 223 Levels", BCP 14, RFC 2119, March 1997. 225 [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 226 Addressing Architecture", RFC 3513, April 2003. 228 [4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 229 IPv6", RFC 3775, June 2004. 231 [5] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 232 Internet-Draft draft-ietf-nemo-terminology-03, 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 Internet-Draft draft-ietf-nemo-requirements-04, February 2005. 241 [8] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert, 242 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 243 January 2005. 245 [9] Narten, T. and R. Draves, "Privacy Extensions for Stateless 246 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 248 Authors' Addresses 250 Ralph Droms 251 Cisco 252 1414 Massachusetts Avenue 253 Boxborough, MA 01719 254 USA 256 Phone: +1 978.936.1674 257 Email: rdroms@cisco.com 259 Pascal Thubert 260 Cisco 261 Village d'Entreprises Green Side 262 400, Avenue Roumanille 263 Biot - Sophia Antipolis 06410 264 FRANCE 266 Email: pthubert@cisco.com 268 Appendix A. Changes Log 270 Rev -01: The section on access prefix delegation was added. That 271 section provides a mechanism that is very close to HMIP but purely 272 based on standard DHCP-PD. It is limited to Nemo applications, but 273 it provides additional features, including the privacy of the mobile 274 access router. 276 Rev -02: The section on optimization of access prefix delegation was 277 removed. 279 Intellectual Property Statement 281 The IETF takes no position regarding the validity or scope of any 282 Intellectual Property Rights or other rights that might be claimed to 283 pertain to the implementation or use of the technology described in 284 this document or the extent to which any license under such rights 285 might or might not be available; nor does it represent that it has 286 made any independent effort to identify any such rights. Information 287 on the procedures with respect to rights in RFC documents can be 288 found in BCP 78 and BCP 79. 290 Copies of IPR disclosures made to the IETF Secretariat and any 291 assurances of licenses to be made available, or the result of an 292 attempt made to obtain a general license or permission for the use of 293 such proprietary rights by implementers or users of this 294 specification can be obtained from the IETF on-line IPR repository at 295 http://www.ietf.org/ipr. 297 The IETF invites any interested party to bring to its attention any 298 copyrights, patents or patent applications, or other proprietary 299 rights that may cover technology that may be required to implement 300 this standard. Please address the information to the IETF at 301 ietf-ipr@ietf.org. 303 The IETF has been notified of intellectual property rights claimed in 304 regard to some or all of the specification contained in this 305 document. For more information consult the online list of claimed 306 rights. 308 Disclaimer of Validity 310 This document and the information contained herein are provided on an 311 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 312 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 313 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 314 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 315 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 316 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 318 Copyright Statement 320 Copyright (C) The Internet Society (2005). This document is subject 321 to the rights, licenses and restrictions contained in BCP 78, and 322 except as set forth therein, the authors retain all their rights. 324 Acknowledgment 326 Funding for the RFC Editor function is currently provided by the 327 Internet Society.