idnits 2.17.1 draft-ietf-dhc-dhcpv6-agentopt-delegate-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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 359. ** 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 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 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 (November 27, 2006) is 6358 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (ref. '2') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (ref. '3') (Obsoleted by RFC 8415) == Outdated reference: A later version (-02) exists of draft-ietf-dhc-dhcpv6-srsn-option-00 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 Intended status: Informational O. Troan 5 Expires: May 31, 2007 Cisco Systems, Inc. 6 November 27, 2006 8 DHCPv6 Relay Agent Assignment Notification (RAAN) Option 9 draft-ietf-dhc-dhcpv6-agentopt-delegate-02.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 May 31, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 The DHCP Relay Agent Assignment Notification (RAAN) option is sent 43 from a DHCP server to a DHCP relay agent to inform the relay agent of 44 IPv6 addresses that have been assigned or IPv6 prefixes that have 45 been delegated to DHCP clients. 47 1. Introduction 49 The DHCP Relay Agent Assignment Notification (RAAN) option 50 encapsulates address and prefix options to indicate that an address 51 or prefix has been assigned. The option may also carry other 52 information required by the network element for configuration related 53 to the assigned address or prefix. 55 For example, a network administrator uses the RAAN option to inform a 56 relay agent of a prefix that has been delegated through DHCP PD to a 57 DHCP client. The relay agent notifies the network element on which 58 it is implemented of the delegation information so the network 59 element can add routing information about the delegated prefix into 60 the routing infrastructure. 62 2. Terminology 64 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 65 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 66 interpreted as described in RFC 2119 [1]. 68 The term "DHCP" in this document refers to DHCP for IPv6, as defined 69 in RFC 3315 [2]. The terms "DHCP prefix delegation" and "DHCP PD" 70 refer DHCP for IPv6 prefix delegation, as defined in RFC 3633 [3] 72 Additional terms used in the description of DHCP and DHCP prefix 73 delegation are defined in RFC 3315 and RFC 3633. In this document 74 "assigning" an IPv6 prefix is equivalent to "delegating" a prefix. 76 3. Option Semantics and Usage 78 The RAAN option carries information about assigned IPv6 addresses and 79 prefixes. It encapsulates IA Address options (RFC 3315) and/or IA 80 Prefix options (RFC 3633), and possibly other options that carry 81 other information related to the assigned IPv6 address or prefix. 83 The DHCP server is responsible for synchronizing any state created by 84 a node through the use of the RAAN option. For example, if a DHCP 85 server receives a Release message for a delegated prefix, it causes 86 the node to delete any state associated with that prefix by sending a 87 RAAN option containing an IA Prefix option with the released prefix 88 and a valid lifetime of zero. 90 When a DHCP server sends this option to a relay agent, it MUST 91 include all addresses and prefixes assigned to the client on the link 92 to which the option refers at the time the option is sent. 94 Examples of use: 96 o Populate an ACL with an assigned IPv6 address if the network 97 security policy requires limiting IPv6 forwarding to devices that 98 have obtained an address through DHCP 99 o Inject routing information into a routing infrastructure about a 100 delegated prefix on behalf of a requesting router 102 4. Relay Agent Behavior 104 A relay agent that wants information from the server in a RAAN option 105 includes an ORO requesting the RAAN option in its Relay-Forw message. 106 A relay agent may do this for any relayed message, regardless of the 107 message type or the message contents. 109 When a relay agent receives a Relay-Reply message containing a RAAN 110 option, the relay agent may forward that option data to the node in 111 which the relay agent is instantiated. If no RAAN option is included 112 in the Relay-Reply, the relay agent MUST NOT assume anything with 113 regard to RAAN data and MUST NOT forward any indication to the node 114 in which the relay agent is instantiated. 116 If a node creates state based on the information included in this 117 option, it MUST remove that state when the lifetime as specified in 118 the option expires. 120 5. Server Behavior 122 When a server is responding to a request and the ORO contains an RAAN 123 option, the server SHOULD include a RAAN option with all of the 124 addresses and prefixes that have been (or are being assigned) to the 125 client. If no addresses or prefixes are assigned, the server SHOULD 126 send a RAAN option with no addresses or prefixes. 128 If the DHCP server does include this option in a Relay-Reply message, 129 it MUST include it in the option area of the Relay-Reply message sent 130 to the relay agent intended as the recipient of the option. 132 If the message received from the client contains no Client Identifier 133 option or the server is otherwise unable to identify the client or 134 the client's link (perhaps because of missing or invalid data in the 135 request), the server MUST NOT include a RAAN option in the response. 137 6. Option format 139 The RAAN option has the following format: 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | option-code | length | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | encapsulated-options | 147 . . 148 . . 149 . . 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 option-code OPTION_AGENT_NOTIFY (TBD) 154 length length of encapsulated options, in octets 156 encapsulated-options DHCP options to be delivered by the relay agent 157 Assignment Notification option 159 7. Encapsulating DHCP options in the RAAN Option 161 The contents of options encapsulated in the RAAN option are 162 interpreted according to the use of those options in the node on 163 which the relay agent is implemented. For the purposes of address 164 and prefix assignment, the uses of the DHCP IA Address and IA Prefix 165 options are defined in this document. 167 Note that the contents of these options are not necessarily the same 168 as in the corresponding options sent to the DHCP client. 170 7.1. IA Address option 172 The fields in an IA Address option (OPTION_IAADDR, option code 5) are 173 used as follows: 175 IPv6 address The IPv6 address assigned in this DHCP message 177 preferred-lifetime Not used by the relay agent; the server SHOULD 178 set this field to the preferred-lifetime of the 179 corresponding IA Address options in the message 180 to be forwarded to the client 182 valid-lifetime The lifetime of the information carried in this 183 IA Address option, expressed in units of seconds; 184 if the valid-lifetime is 0, the information is no 185 longer valid 187 IAaddr-options Not used by the relay agent; the server SHOULD 188 set this field to the IAaddr-options of the 189 corresponding IA Address option in the message to 190 be forwarded to the client 192 7.2. IA Prefix option 194 The fields in an IA Prefix option (OPTION_IAPREFIX, option code 28) 195 are used as follows: 197 preferred-lifetime Not used by the relay agent; the server SHOULD 198 set this field to the preferred-lifetime of the 199 corresponding IA Prefix options in the message to 200 be forwarded to the client 202 valid-lifetime The lifetime of the information carried in this 203 IA Prefix option, expressed in units of seconds; 204 if the valid-lifetime is 0, the information is no 205 longer valid 207 prefix-length length for this prefix in bits 209 IPv6-prefix The IPv6 prefix assigned in this DHCP message 211 IAprefix-options Not used by the relay agent; the server SHOULD 212 set this field to the IAprefix-options of the 213 corresponding IA Prefix option in the message to 214 be forwarded to the client 216 8. Requesting assignment information from the DHCP server 218 If a relay agent requires the DHCP server to provide information 219 about assigned addresses and prefixes, it MUST include an Option 220 Request option, requesting the Assignment Notification option, as 221 described in section 22.7 of RFC 3315. 223 9. Reordering received DHCP messages 225 The relay agent MUST use the Server Reply Sequence Number (SRSN) 226 option [4] to detect and discard RAAN options contained in DHCP 227 messages that are received out of order. 229 10. IANA considerations 231 IANA is requested to assign an option code from the "DHCPv6 and 232 DHCPv6 options" registry 233 http://www.iana.org/assignments/dhcpv6-parameters to 234 OPTION_AGENT_NOTIFY. 236 11. Security considerations 238 Security issues related to DHCP are described in RFC 3315 and RFC 239 3633. 241 The RAAN option may be used to mount a denial of service attack by 242 causing a node to incorrectly populate an ACL or incorrectly 243 configure routing information for a delegated prefix. This option 244 may also be used to insert invalid prefixes into the routing 245 infrastructure or add invalid IP addresses to ACLs in nodes. 246 Communication between a server and a relay agent, and communication 247 between relay agents, can be secured through the use of IPSec, as 248 described in section 21.1 of RFC 3315. 250 12. Changes log 252 If this section is included in the document when it is submitted for 253 publication, the RFC Editor is requested to remove it. 255 Changes in rev -01: 256 o Added section describing use of "Server Reply Sequence Number" 257 option to allow resequencing of out-of-order messages 259 Changes in rev -02: 260 o Made editorial change in section 1: s/the appropriate routing 261 protocols/the routing infrastructure/ 262 o Updated first paragraph in Section 3 to allow multiple IA Address 263 options and/or IA Prefix options 264 o Renamed section "Options Semantics and Usage" 265 o Added paragraph to section "Option Semantics and Usage" requiring 266 that the DHCP server must include all addresses/prefixes for the 267 client (on that link) in the RAAN option 268 o Added list of use cases to section "Option Semantics and Usage" 269 o Added section "Relay Agent Behavior" 270 o Added section "Server Behavior"; moved second paragraph of section 271 "Option Semantics and Usage" to "Server Behavior" 272 o Updated reference to draft-ietf-dhc-dhcpv6-srsn-option-00 273 o Clarified descriptions of various option fields in section 274 "Encapsulating DHCP options in the RAAN Option" 276 13. Normative References 278 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 279 Levels", BCP 14, RFC 2119, March 1997. 281 [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 282 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 283 RFC 3315, July 2003. 285 [3] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 286 Configuration Protocol (DHCP) version 6", RFC 3633, 287 December 2003. 289 [4] Volz, B. and R. Droms, "DHCPv6 Server Reply Sequence Number 290 Option", draft-ietf-dhc-dhcpv6-srsn-option-00 (work in 291 progress), November 2006. 293 Authors' Addresses 295 Ralph Droms 296 Cisco Systems, Inc. 297 1414 Massachusetts Avenue 298 Boxborough, MA 01719 299 USA 301 Phone: +1 978.936.1674 302 Email: rdroms@cisco.com 304 Bernie Volz 305 Cisco Systems, Inc. 306 1414 Massachusetts Avenue 307 Boxborough, MA 01719 308 USA 310 Phone: +1 978.936.0382 311 Email: volz@cisco.com 312 Ole Troan 313 Cisco Systems, Inc. 314 Shinjuku Mitsui Building, 2-1-1, Nishi-Shinjuku, Shinjuku-Ku 315 Tokyo, Kanto 163-0409 316 Japan 318 Phone: +81 3 5324.4027 319 Email: otroan@cisco.com 321 Full Copyright Statement 323 Copyright (C) The Internet Society (2006). 325 This document is subject to the rights, licenses and restrictions 326 contained in BCP 78, and except as set forth therein, the authors 327 retain all their rights. 329 This document and the information contained herein are provided on an 330 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 331 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 332 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 333 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 334 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 335 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 337 Intellectual Property 339 The IETF takes no position regarding the validity or scope of any 340 Intellectual Property Rights or other rights that might be claimed to 341 pertain to the implementation or use of the technology described in 342 this document or the extent to which any license under such rights 343 might or might not be available; nor does it represent that it has 344 made any independent effort to identify any such rights. Information 345 on the procedures with respect to rights in RFC documents can be 346 found in BCP 78 and BCP 79. 348 Copies of IPR disclosures made to the IETF Secretariat and any 349 assurances of licenses to be made available, or the result of an 350 attempt made to obtain a general license or permission for the use of 351 such proprietary rights by implementers or users of this 352 specification can be obtained from the IETF on-line IPR repository at 353 http://www.ietf.org/ipr. 355 The IETF invites any interested party to bring to its attention any 356 copyrights, patents or patent applications, or other proprietary 357 rights that may cover technology that may be required to implement 358 this standard. Please address the information to the IETF at 359 ietf-ipr@ietf.org. 361 Acknowledgment 363 Funding for the RFC Editor function is provided by the IETF 364 Administrative Support Activity (IASA).