idnits 2.17.1 draft-krishnan-intarea-ra-dhcp-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, updated by RFC 4748 on line 276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 300. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (November 11, 2007) is 6004 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 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5006 (Obsoleted by RFC 6106) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Standards Track November 11, 2007 5 Expires: May 14, 2008 7 Carrying DHCP options over Neighbor Discovery Messages 8 draft-krishnan-intarea-ra-dhcp-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 May 14, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 DHCP options are used to convey network and host configuration 42 information to the hosts attached to a network. Some networks may 43 wish to configure their routers to advertise these same pieces of 44 information, and might use IPv6 Router Advertisements do distribute 45 these parameters. This document defines a generic neighbor discovery 46 option for carrying DHCP options. This option is carried over IPv6 47 Router Advertisements. 49 Table of Contents 51 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Justification . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 55 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 6. DHCP Container(DHCPC) Option . . . . . . . . . . . . . . . . . 8 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 59 9. Acknowledgmentes . . . . . . . . . . . . . . . . . . . . . . . 12 60 10. Normative References . . . . . . . . . . . . . . . . . . . . . 13 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 Intellectual Property and Copyright Statements . . . . . . . . . . 15 64 1. Requirements notation 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [RFC2119]. 70 2. Introduction 72 Router Advertisements (RAs) as defined in [RFC2461] are used to 73 deliver configuration information that is common to several nodes in 74 the same network. The router advertisements are usually multicasted 75 to all nodes in a given network in order to be scalable. The 76 configuration information is contained in Neigbor Discovery (ND) 77 options. DHCP [RFC3315] is used for delivering addressing 78 information and other related configuration information to single 79 clients when they request it. Since there are two mechanisms for 80 delivering common configuration information to a given node, 81 configuration parameters need to be defined under two varying option 82 formats. This leads to duplication of work needed to standardize 83 these options and additional implementation complexity on hosts in 84 order to process these option variants. In order to prevent this 85 duplication, this document proposes a neighbor discovery option that 86 can be used to directly carry any relevant DHCP option. 88 3. Justification 90 Recently there has been interest in doing more of DHCP work using 91 Neighbor Discovery (Router Advertisement) messages. This is mainly 92 to accomodate environments where DHCP is not available and the only 93 way of convey configuration information is through RAs. Since DHCP 94 options cannot be carried in RAs this leads to duplicate 95 standardization efforts to develop ND options for options already 96 developed for DHCP. For example consider [RFC5006] that redefines a 97 DNS server address option for RAs that has been defined long ago for 98 DHCP. Not only does this waste valuable time in redundant 99 standardization effort, it also complicates client implementations 100 that need to be able to parse and understand tho incompatible option 101 formats. It also takes away valuable code points away from the 102 neighbor discovery message types (8 bit value). Thus it make sense 103 to define a DHCP carrier option for neighbor discovery messages so 104 that we can reuse DHCP options as necessary without coming up with 105 new neighbor discovery options. 107 4. Applicability 109 It is possible to carry any DHCP option using the DHCPC option. 110 However, this does not always make sense since there are DHCP options 111 that are client specific and hence are not uniform across all the 112 hosts in the network. The DHCPC option SHOULD NOT be used to carry 113 DHCP options that are client specific. This option can be carried in 114 any neighbor discovery messages. 116 5. Operation 118 After a node receives a neighbor discovery that contains a DHCPC 119 option it needs to verify if the DHCPC option length is at least 1 (8 120 octets). If it is not, the node MUST NOT process the DHCPC option 121 any further and SHOULD log an error message locally. Otherwise it 122 needs to process the embedded DHCP options one at a time as it would 123 if it had received them through a DHCP message. It is entirely 124 possible that the code for processing these options is shared between 125 the neighbor discovery based delivery and DHCP based delivery of 126 these options. 128 6. DHCP Container(DHCPC) Option 130 The DHCPC option in Neighbor Discovery messages is used to carry 131 complete DHCP options. There can be more than DHCP option contained 132 in a DHCPC option. The number of contained DHCP options is not 133 explicitly mentioned in the DHCPC. The receiving node MUST process 134 all the contained options 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Type | Length | Reserved | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | OPT1_code | OPT1_len | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | OPT1_data | 144 | (OPT1_len octets) | 145 . . 146 . . 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | OPTn_code | OPTn_len | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | OPTn_data | 151 | (OPTn_len octets) | 152 . . 153 . . 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 Type 158 8-bit identifier of the type of option. The option identifier 159 for the DHCPC option will be allocated by the IANA. 161 Option Length 163 8-bit unsigned integer. The length of the option (including 164 the type and length fields) in units of 8 octets. The value 165 0 is considered invalid. 167 OPT1_code 169 16-bit unsigned integer. The DHCPv6 option code of the first 170 DHCP option that is carried in the DHCPC option. 172 OPT1_len 174 16-bit unsigned integer. The length of the option data of the 175 first included DHCP option (excluding the OPT1_code and the 176 OPT1_len fields) 178 OPT1_Data 180 The data field of the first included neighbor discovery 181 option. The contents of this field are determined by the type 182 of the option. 184 OPT1_code 186 16-bit unsigned integer. The DHCPv6 option code of the first 187 DHCP option that is carried in the DHCPC option. 189 OPT1_len 191 16-bit unsigned integer. The length of the option data of the 192 first included DHCP option (excluding the OPT1_code and the 193 OPT1_len fields) 195 OPT1_Data 197 The data field of the first included neighbor discovery 198 option. The contents of this field are determined by the type 199 of the option. 201 Figure 1: DHCPC layout 203 7. IANA Considerations 205 This document defines a new IPv6 neighbor discovery option for 206 carrying DHCP options. IANA is requested to assign the a new 207 neighbor discovery option type in the registry maintained at 209 http://www.iana.org/assignments/icmpv6-parameters 211 DHCP Carrier Option [RFC-krishnan-intarea-ra-dhcp-00.txt] 213 The option type 26 is recommended as it is the first unused option 214 type at the time of writing this draft. 216 8. Security Considerations 218 The mechanism described in this document provides a method by which 219 one or more DHCP options can be carried using IPv6 Router 220 Advertisement messages. The neighbor discovery messages containing 221 the DHCPC option may be intercepted, modified or replayed in order to 222 communicate false configuration data to the client hosts. In order 223 to prevent these kinds of attacks, it is recommended that SEND 224 [RFC3971] be used. 226 9. Acknowledgmentes 228 The author would like to thank Jari Arkko for his detailed review and 229 comments on the earlier versions of this document. 231 10. Normative References 233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 234 Requirement Levels", BCP 14, RFC 2119, March 1997. 236 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 237 Discovery for IP Version 6 (IPv6)", RFC 2461, 238 December 1998. 240 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 241 and M. Carney, "Dynamic Host Configuration Protocol for 242 IPv6 (DHCPv6)", RFC 3315, July 2003. 244 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 245 Neighbor Discovery (SEND)", RFC 3971, March 2005. 247 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 248 "IPv6 Router Advertisement Option for DNS Configuration", 249 RFC 5006, September 2007. 251 Author's Address 253 Suresh Krishnan 254 Ericsson 255 8400 Decarie Blvd. 256 Town of Mount Royal, QC 257 Canada 259 Phone: +1 514 345 7900 x42871 260 Email: suresh.krishnan@ericsson.com 262 Full Copyright Statement 264 Copyright (C) The IETF Trust (2007). 266 This document is subject to the rights, licenses and restrictions 267 contained in BCP 78, and except as set forth therein, the authors 268 retain all their rights. 270 This document and the information contained herein are provided on an 271 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 272 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 273 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 274 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 275 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 276 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 278 Intellectual Property 280 The IETF takes no position regarding the validity or scope of any 281 Intellectual Property Rights or other rights that might be claimed to 282 pertain to the implementation or use of the technology described in 283 this document or the extent to which any license under such rights 284 might or might not be available; nor does it represent that it has 285 made any independent effort to identify any such rights. Information 286 on the procedures with respect to rights in RFC documents can be 287 found in BCP 78 and BCP 79. 289 Copies of IPR disclosures made to the IETF Secretariat and any 290 assurances of licenses to be made available, or the result of an 291 attempt made to obtain a general license or permission for the use of 292 such proprietary rights by implementers or users of this 293 specification can be obtained from the IETF on-line IPR repository at 294 http://www.ietf.org/ipr. 296 The IETF invites any interested party to bring to its attention any 297 copyrights, patents or patent applications, or other proprietary 298 rights that may cover technology that may be required to implement 299 this standard. Please address the information to the IETF at 300 ietf-ipr@ietf.org. 302 Acknowledgment 304 Funding for the RFC Editor function is provided by the IETF 305 Administrative Support Activity (IASA).