idnits 2.17.1 draft-krishnan-dhc-ndc-option-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 243. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 254. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 267. 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 (August 23, 2007) is 6085 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) Summary: 3 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 August 23, 2007 5 Expires: February 24, 2008 7 Neighbor Discovery Information over DHCP 8 draft-krishnan-dhc-ndc-option-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 24, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 Neighbor discovery options, in addition to being used for Neighbor 42 Discovery, are used to convey some forms of network configuration 43 information to the hosts attached to a network. Some centrally 44 managed networks, that do not wish to configure their routers to 45 advertise these pieces of information, might use a DHCP server to 46 configure there parameters. This document defines a generic DHCP 47 option for carrying these parameters. 49 Table of Contents 51 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 5. Neighbor Discovery Container(NDC) Option . . . . . . . . . . . 7 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 58 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 60 Intellectual Property and Copyright Statements . . . . . . . . . . 13 62 1. Requirements notation 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 2. Introduction 70 Router Advertisements (RAs) as defined in [RFC2461] are used to 71 deliver configuration information that is common to several nodes in 72 the same network. The router advertisements are usually multicasted 73 to all nodes in a given network in order to be scalable. The 74 configuration information is contained in Neigbor Discovery (ND) 75 options. DHCP [RFC3315] is used for delivering addressing 76 information and other related configuration information to single 77 clients when they request it. Since there are two mechanisms for 78 delivering configuration information to a given node, configuration 79 parameters need to be defined under two varying option formats. This 80 leads to duplication of work needed to standardize these options and 81 additional implementation complexity on hosts in order to process 82 these option variants. In order to prevent this duplication, this 83 document proposes a DHCP option that can be used to directly carry 84 any neighbor discovery option. 86 3. Applicability 88 It is possible to carry any neighbor discovery option using the NDC 89 option. This does not always make sense since there are neigbor 90 discovery options that are not related to configuration. The NDC 91 option SHOULD NOT be used to carry neighbor discovery options that 92 are not related to configuration. e.g. Source Link-layer Address, 93 Target Link-layer Address etc. 95 4. Operation 97 After a DHCP client receives a message that contains a NDC option it 98 needs to verify if the NDC option length is at least 8 octets. If it 99 is not, the client MUST NOT process the NDC option any further and 100 SHOULD log an error message locally. Otherwise it needs to process 101 the embedded Neighbor Discovery options one at a time as it would if 102 it had received them through a Router Advertisement. It is entirely 103 possible that the code for processing these options is shared between 104 the RA based delivery and DHCP based delivery of these options. 106 5. Neighbor Discovery Container(NDC) Option 108 The DHCP NDC option is used to carry complete neighbor discovery 109 options. There can be more than one neighbor discovery option that 110 is contained in a NDC. The number of contained options is not 111 explicitly mentioned in the NDC. The receiving node needs to process 112 all the contained options 114 0 1 2 3 115 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 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | OPTION_NDC | Option Length | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | OPT1_Type | OPT1_Length | | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 121 | | 122 | OPT1_Data | 123 . . 124 . . 125 | | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | OPTn_Type | OPTn_Length | | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 129 | | 130 | OPTn_Data | 131 . . 132 . . 133 | | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 OPTION_NDC 138 DHCP Option code allocated for the NDC option. To be 139 allocated by IANA out of the dhcpv6 parameters for option 140 codes. 142 Option Length 144 Length of the NDC option in octets not including the Option 145 Code and the Option Length fields. i.e. Combined length of 146 the included neighbor discovery options. 148 OPT1_Type 150 The neighbor discovery option type of the first included 151 option. 153 OPT1_Length 154 The length of the first included option (including the 155 OPT1_Type and OPT1_Length fields) in units of 8 octets. The 156 value 0 is invalid. 158 OPT1_Data 160 The data field of the first included neighbor discovery 161 option. The contents of this field are determined by the type 162 of the option. 164 OPTn_Type 166 The neighbor discovery option type of the nth included option. 168 OPTn_Length 170 The length of the nth included option (including the OPT1_Type 171 and OPT1_Length fields) in units of 8 octets. The value 0 is 172 invalid. 174 OPTn_Data 176 The data field of the nth included neighbor discovery option. 177 The contents of this field are determined by the type of the 178 option. 180 Figure 1: NDC layout 182 6. IANA Considerations 184 This document defines a new DHCPv6 option code for carrying neighbor 185 discovery options. IANA is requested to assign the following new 186 DHCPv6 Option Code in the registry maintained at 188 http://www.iana.org/assignments/dhcpv6-parameters: 190 OPTION_NDC 192 7. Security Considerations 194 The mechanism described in this document provides a method by which 195 one or more neighbor discovery options can be carried using DHCP 196 messages. The DHCP messages containing the NDC option may be 197 intercepted, modified or replayed in order to communicate false 198 configuration data to the client hosts. In order to prevent these 199 kinds of attacks, it is recommended that authenticated DHCP [RFC3118] 200 be used. 202 8. Normative References 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, March 1997. 207 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 208 Discovery for IP Version 6 (IPv6)", RFC 2461, 209 December 1998. 211 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 212 Messages", RFC 3118, June 2001. 214 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 215 and M. Carney, "Dynamic Host Configuration Protocol for 216 IPv6 (DHCPv6)", RFC 3315, July 2003. 218 Author's Address 220 Suresh Krishnan 221 Ericsson 222 8400 Decarie Blvd. 223 Town of Mount Royal, QC 224 Canada 226 Phone: +1 514 345 7900 x42871 227 Email: suresh.krishnan@ericsson.com 229 Full Copyright Statement 231 Copyright (C) The IETF Trust (2007). 233 This document is subject to the rights, licenses and restrictions 234 contained in BCP 78, and except as set forth therein, the authors 235 retain all their rights. 237 This document and the information contained herein are provided on an 238 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 239 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 240 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 241 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 242 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 243 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 245 Intellectual Property 247 The IETF takes no position regarding the validity or scope of any 248 Intellectual Property Rights or other rights that might be claimed to 249 pertain to the implementation or use of the technology described in 250 this document or the extent to which any license under such rights 251 might or might not be available; nor does it represent that it has 252 made any independent effort to identify any such rights. Information 253 on the procedures with respect to rights in RFC documents can be 254 found in BCP 78 and BCP 79. 256 Copies of IPR disclosures made to the IETF Secretariat and any 257 assurances of licenses to be made available, or the result of an 258 attempt made to obtain a general license or permission for the use of 259 such proprietary rights by implementers or users of this 260 specification can be obtained from the IETF on-line IPR repository at 261 http://www.ietf.org/ipr. 263 The IETF invites any interested party to bring to its attention any 264 copyrights, patents or patent applications, or other proprietary 265 rights that may cover technology that may be required to implement 266 this standard. Please address the information to the IETF at 267 ietf-ipr@ietf.org. 269 Acknowledgment 271 Funding for the RFC Editor function is provided by the IETF 272 Administrative Support Activity (IASA).