idnits 2.17.1 draft-droms-dhc-dhcpv6-agentopt-delegate-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 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. ** 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: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-draft-droms-dhc-dhcpv6-agentopt-delegate-00', but the file name used is 'draft-droms-dhc-dhcpv6-agentopt-delegate-00' == 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 == Line 186 has weird spacing: '...-length lengt...' == 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). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 18, 2005) is 6765 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 3315 (ref. '2') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (ref. '3') (Obsoleted by RFC 8415) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc Group R. Droms 3 Internet-Draft B. Volz 4 Expires: April 21, 2006 O. Troan 5 Cisco Systems, Inc. 6 October 18, 2005 8 DHCP Relay Agent Assignment Notification Option 9 draft-draft-droms-dhc-dhcpv6-agentopt-delegate-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 21 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 April 21, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The DHCP Relay Agent Assignment Notification option is sent from a 43 DHCP server to a DHCP relay agent to inform the relay agent of IPv6 44 addresses that have been assigned or IPv6 prefixes that have been 45 delegated to DHCP clients. 47 1. Introduction 49 The DHCP Relay Agent Assignment Notification option encapsulates 50 address and prefix options to indicate that an address or prefix has 51 been assigned. The option may also carry other information required 52 by the network element for configuration related to the assigned 53 address or prefix. 55 For example, a network administrator uses the DHCP Relay Agent 56 Assignment Notification option to inform a relay agent of a prefix 57 that has been delegated through DHCP PD to a DHCP client. The relay 58 agent notifies the network element on which the it is implemented of 59 the delegation information so the network element can add routing 60 information about the delegated prefix into the appropriate routing 61 protocols. 63 2. Terminology 65 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 66 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 67 interpreted as described in RFC 2119 [1]. 69 The term "DHCP" in this document refers to DHCP for IPv6, as defined 70 in RFC 3315 [2]. The terms "DHCP prefix delegation" and "DHCP PD" 71 refer DHCP for IPv6 prefix delegation, as defined in RFC 3633 [3] 73 Additional terms used in the description of DHCP and DHCP prefix 74 delegation are defined in RFC 3315 and RFC 3633. In this document 75 "assigning" an IPv6 prefix is equivalent to "delegating" a prefix. 77 3. Option semantics 79 The DHCP Relay Agent Assignment Notification option carries 80 information about assigned IPv6 addresses and prefixes. It 81 encapsulates an IA Address option (RFC 3315) or an IA Prefix option 82 (RFC 3633), and possibly other options that carry other information 83 related to the assigned IPv6 address or prefix. 85 The DHCP server MAY include this option in a Reply message sent to a 86 client that includes assigned addresses and/or prefixes. If the DHCP 87 server does include this option in a Reply message, it MUST include 88 it in the option area of the Relay-reply message sent to the relay 89 agent intended as the recipient of the option. 91 The DHCP server is responsible for synchronizing any state created by 92 a node through the use of the Assignment Notification option. For 93 example, if a DHCP server receives a Release message for a delegated 94 prefix, it causes the node to delete any state associated with that 95 prefix by sending an Assignment Notification option containing an IA 96 Prefix option with the released prefix and a valid lifetime of zero. 98 A relay agent that receives this option SHOULD pass the information 99 to the node in which the relay agent is instantiated. The node MAY 100 make use of the information received from the relay agent. 102 If a node creates state based on the information included in this 103 option, it MUST remove that state when the lifetime as specified in 104 the option expires. 106 Examples of use: 108 o Populate an ACL with an assigned IPv6 address if the network 109 device in which the relay agent is instantiated implements a 110 security policy limiting IPv6 forwarding to devices that have 111 obtained an address through DHCP 112 o Inject routing information into a routing infrastructure about a 113 delegated prefix on behalf of a requesting router 115 4. Option format 117 The DHCP Relay Agent Assignment Notification Option has the following 118 format: 120 0 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | option-code | length | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | encapsulated-options | 126 . . 127 . . 128 . . 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 option-code OPTION_AGENT_NOTIFY (TBD) 133 length length of encapsulated options, in octets 135 encapsulated-options DHCP options to be delivered by the Relay Agent 136 Assignment Notification option 138 5. Encapsulating DHCP options in the DHCP Relay Agent Assignment 139 Notification Option 141 The contents of options encapsulated in the DHCP Relay Agent 142 Assignment Notification option are interpreted according to the use 143 of those options in the node on which the relay agent is implemented. 144 For the purposes of address and prefix assignment, the uses of the 145 DHCP IA Address and IA Prefix options are defined in this document. 147 Note that the contents of these options are not necessarily the same 148 as in the corresponding options sent to the DHCP client. For 149 example, the node that receives the information from these options 150 may be instructed to use the information for a shorter period of time 151 than the client by setting a shorter valid-lifetime in the this 152 option. 154 5.1. IA Address option 156 The fields in an IA Address option (OPTION_IAADDR, option code 5) are 157 used as follows: 159 IPv6 address The IPv6 address assigned in this DHCP message 161 preferred-lifetime Not used at the time this document was published 163 valid-lifetime The expiration lifetime of the information carried in 164 this IA Address option, expressed in units of seconds; the 165 expiration-lifetime is a relative time, giving the duration 166 relative to the current time of the information in this IA Address 167 option; if the valid-lifetime is 0, the information is no longer 168 valid. 170 IAaddr-options Not used 172 5.2. IA Prefix option 174 The fields in an IA Prefix option (OPTION_IAPREFIX, option code 28) 175 are used as follows: 177 preferred-lifetime Not used 179 valid-lifetime The expiration lifetime of the information carried in 180 this IA Prefix option, expressed in units of seconds; the 181 expiration-lifetime is a relative time, giving the duration 182 relative to the current time of the information in this IA Prefix 183 option; if the valid-lifetime is 0, the information is no longer 184 valid. 186 prefix-length length for this prefix in bits 188 IPv6-prefix The IPv6 prefix assigned in this DHCP message 190 IAprefix-options Not used at the time this document was published 192 6. Requesting assignment information from the DHCP server 194 If a relay agent requires the DHCP server to provide information 195 about assigned addresses and prefixes, it MUST include an Option 196 Request option, requesting the Assignment Notification option, as 197 described in section 22.7 of RFC 3315. 199 7. IANA considerations 201 IANA is requested to assign an option code from the "DHCPv6 and 202 DHCPv6 options registry 203 http://www.iana.org/assignments/dhcpv6-parameters to 204 OPTION_AGENT_NOTIFY. 206 8. Security considerations 208 Security issues related to DHCP are described in RFC 3315 and RFC 209 3633. 211 The DHCP Relay Agent Assignment Notification Option may be used to 212 mount a denial of service attack by causing a node to incorrectly 213 populate an ACL or incorrectly configure routing protocol information 214 for a delegated prefix. This option may also be used to insert 215 invalid prefixes into the routing infrastruture or add invalid IP 216 addresses to ACLs in nodes. Communication between a server and a 217 relay agent, and communication between relay agents, can be secured 218 through the use of IPSec, as described in section 21.1 of RFC 3315. 220 9. Normative References 222 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 223 Levels", BCP 14, RFC 2119, March 1997. 225 [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 226 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 227 RFC 3315, July 2003. 229 [3] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 230 Configuration Protocol (DHCP) version 6", RFC 3633, 231 December 2003. 233 Authors' Addresses 235 Ralph Droms 236 Cisco Systems, Inc. 237 1414 Massachusetts Avenue 238 Boxborough, MA 01719 239 USA 241 Phone: +1 978.936.1674 242 Email: rdroms@cisco.com 244 Bernie Volz 245 Cisco Systems, Inc. 246 1414 Massachusetts Avenue 247 Boxborough, MA 01719 248 USA 250 Phone: +1 978.936.0382 251 Email: volz@cisco.com 253 Ole Troan 254 Cisco Systems, Inc. 255 Shinjuku Mitsui Building, 2-1-1, Nishi-Shinjuku, Shinjuku-Ku 256 Tokyo, Kanto 163-0409 257 Japan 259 Phone: +81 3 5324.4027 260 Email: otroan@cisco.com 262 Full Copyright Statement 264 Copyright (C) The Internet Society (2005). 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 AND THE INTERNET 273 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 274 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 275 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 currently provided by the 305 Internet Society.