idnits 2.17.1 draft-ietf-dhc-dhcpv6-agentopt-delegate-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2009) is 5401 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 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: Standards Track O. Troan 5 Expires: January 14, 2010 Cisco Systems, Inc. 6 July 13, 2009 8 DHCPv6 Relay Agent Assignment Notification (RAAN) Option 9 draft-ietf-dhc-dhcpv6-agentopt-delegate-04.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 14, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 The DHCP Relay Agent Assignment Notification (RAAN) option is sent 58 from a DHCP server to a DHCP relay agent to inform the relay agent of 59 IPv6 addresses that have been assigned or IPv6 prefixes that have 60 been delegated to DHCP clients. 62 1. Introduction 64 The DHCP Relay Agent Assignment Notification (RAAN) option 65 encapsulates address and prefix options to indicate that an address 66 or prefix has been assigned. The option may also carry other 67 information required by the network element for configuration related 68 to the assigned address or prefix. 70 For example, a network administrator uses the RAAN option to inform a 71 relay agent of a prefix that has been delegated through DHCP PD to a 72 DHCP client. The relay agent notifies the network element on which 73 it is implemented of the delegation information so the network 74 element can add routing information about the delegated prefix into 75 the routing infrastructure. 77 2. Terminology 79 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 80 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 81 interpreted as described in RFC 2119 [RFC2119]. 83 The term "DHCP" in this document refers to DHCP for IPv6, as defined 84 in RFC 3315 [RFC3315]. The terms "DHCP prefix delegation" and "DHCP 85 PD" refer DHCP for IPv6 prefix delegation, as defined in RFC 3633 86 [RFC3633] 88 Additional terms used in the description of DHCP and DHCP prefix 89 delegation are defined in RFC 3315 and RFC 3633. In this document 90 "assigning" an IPv6 prefix is equivalent to "delegating" a prefix. 92 3. Option Semantics and Usage 94 The RAAN option carries information about assigned IPv6 addresses and 95 prefixes. It encapsulates IA Address options (RFC 3315) and/or IA 96 Prefix options (RFC 3633), and possibly other options that carry 97 other information related to the assigned IPv6 address or prefix. 99 The DHCP server is responsible for synchronizing any state created by 100 a node through the use of the RAAN option. For example, if a DHCP 101 server receives a Release message for a delegated prefix, it causes 102 the node to delete any state associated with that prefix by sending a 103 RAAN option containing an IA Prefix option with the released prefix 104 and a valid lifetime of zero. 106 When a DHCP server sends this option to a relay agent, it MUST 107 include all addresses and prefixes assigned to the client on the link 108 to which the option refers at the time the option is sent. 110 Examples of use: 112 o Populate an ACL with an assigned IPv6 address if the network 113 security policy requires limiting IPv6 forwarding to devices that 114 have obtained an address through DHCP 115 o Inject routing information into a routing infrastructure about a 116 delegated prefix on behalf of a requesting router 118 4. Relay Agent Behavior 120 A relay agent that wants information from the server in a RAAN option 121 includes an ORO requesting the RAAN option in its Relay-Forw message. 122 A relay agent may do this for any relayed message, regardless of the 123 message type or the message contents. 125 When a relay agent receives a Relay-Reply message containing a RAAN 126 option, the relay agent may forward that option data to the node in 127 which the relay agent is instantiated. If no RAAN option is included 128 in the Relay-Reply, the relay agent MUST NOT assume anything with 129 regard to RAAN data and MUST NOT forward any indication to the node 130 in which the relay agent is instantiated. 132 If a node creates state based on the information included in this 133 option, it MUST remove that state when the lifetime as specified in 134 the option expires. 136 5. Server Behavior 138 When a server is responding to a request and the ORO contains an RAAN 139 option, the server SHOULD include a RAAN option with all of the 140 addresses and prefixes that have been (or are being assigned) to the 141 client. If no addresses or prefixes are assigned, the server SHOULD 142 send a RAAN option with no addresses or prefixes. 144 If the DHCP server does include this option in a Relay-Reply message, 145 it MUST include it in the option area of the Relay-Reply message sent 146 to the relay agent intended as the recipient of the option. 148 If the message received from the client contains no Client Identifier 149 option or the server is otherwise unable to identify the client or 150 the client's link (perhaps because of missing or invalid data in the 151 request), the server MUST NOT include a RAAN option in the response. 153 6. Option format 155 The RAAN option has the following format: 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | option-code | length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | encapsulated-options | 163 . . 164 . . 165 . . 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 option-code OPTION_AGENT_NOTIFY (TBD) 170 length length of encapsulated options, in octets 172 encapsulated-options DHCP options to be delivered by the relay agent 173 Assignment Notification option 175 7. Encapsulating DHCP options in the RAAN Option 177 The contents of options encapsulated in the RAAN option are 178 interpreted according to the use of those options in the node on 179 which the relay agent is implemented. For the purposes of address 180 and prefix assignment, the uses of the DHCP IA Address and IA Prefix 181 options are defined in this document. 183 Note that the contents of these options are not necessarily the same 184 as in the corresponding options sent to the DHCP client. 186 7.1. IA Address option 188 The fields in an IA Address option (OPTION_IAADDR, option code 5) are 189 used as follows: 191 IPv6 address The IPv6 address assigned in this DHCP message 193 preferred-lifetime Not used by the relay agent; the server SHOULD 194 set this field to the preferred-lifetime of the 195 corresponding IA Address options in the message 196 to be forwarded to the client 198 valid-lifetime The lifetime of the information carried in this 199 IA Address option, expressed in units of seconds; 200 if the valid-lifetime is 0, the information is no 201 longer valid 203 IAaddr-options Not used by the relay agent; the server SHOULD 204 set this field to the IAaddr-options of the 205 corresponding IA Address option in the message to 206 be forwarded to the client 208 7.2. IA Prefix option 210 The fields in an IA Prefix option (OPTION_IAPREFIX, option code 28) 211 are used as follows: 213 preferred-lifetime Not used by the relay agent; the server SHOULD 214 set this field to the preferred-lifetime of the 215 corresponding IA Prefix options in the message to 216 be forwarded to the client 218 valid-lifetime The lifetime of the information carried in this 219 IA Prefix option, expressed in units of seconds; 220 if the valid-lifetime is 0, the information is no 221 longer valid 223 prefix-length length for this prefix in bits 225 IPv6-prefix The IPv6 prefix assigned in this DHCP message 226 IAprefix-options Not used by the relay agent; the server SHOULD 227 set this field to the IAprefix-options of the 228 corresponding IA Prefix option in the message to 229 be forwarded to the client 231 8. Requesting assignment information from the DHCP server 233 If a relay agent requires the DHCP server to provide information 234 about assigned addresses and prefixes, it MUST include an Option 235 Request option, requesting the Assignment Notification option, as 236 described in section 22.7 of RFC 3315. 238 9. IANA considerations 240 IANA is requested to assign an option code from the "DHCPv6 and 241 DHCPv6 options" registry 242 http://www.iana.org/assignments/dhcpv6-parameters to 243 OPTION_AGENT_NOTIFY. 245 10. Security considerations 247 Security issues related to DHCP are described in RFC 3315 and RFC 248 3633. 250 The RAAN option may be used to mount a denial of service attack by 251 causing a node to incorrectly populate an ACL or incorrectly 252 configure routing information for a delegated prefix. This option 253 may also be used to insert invalid prefixes into the routing 254 infrastructure or add invalid IP addresses to ACLs in nodes. 255 Communication between a server and a relay agent, and communication 256 between relay agents, can be secured through the use of IPSec, as 257 described in section 21.1 of RFC 3315. 259 11. Changes log 261 If this section is included in the document when it is submitted for 262 publication, the RFC Editor is requested to remove it. 264 Changes in rev -01: 265 o Added section describing use of "Server Reply Sequence Number" 266 option to allow resequencing of out-of-order messages 268 Changes in rev -02: 270 o Made editorial change in section 1: s/the appropriate routing 271 protocols/the routing infrastructure/ 272 o Updated first paragraph in Section 3 to allow multiple IA Address 273 options and/or IA Prefix options 274 o Renamed section 3 to "Options Semantics and Usage" 275 o Added paragraph to section "Option Semantics and Usage" requiring 276 that the DHCP server must include all addresses/prefixes for the 277 client (on that link) in the RAAN option 278 o Added list of use cases to section "Option Semantics and Usage" 279 o Added section "Relay Agent Behavior" 280 o Added section "Server Behavior"; moved second paragraph of section 281 "Option Semantics and Usage" to "Server Behavior" 282 o Updated reference to draft-ietf-dhc-dhcpv6-srsn-option-00 283 o Clarified descriptions of various option fields in section 284 "Encapsulating DHCP options in the RAAN Option" 286 Changes in rev -03: refreshed after expiration. 288 Changes in rev -04: all references to the "Server Reply Sequence 289 Number" option were removed from the draft. 291 12. Normative References 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, March 1997. 296 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 297 and M. Carney, "Dynamic Host Configuration Protocol for 298 IPv6 (DHCPv6)", RFC 3315, July 2003. 300 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 301 Host Configuration Protocol (DHCP) version 6", RFC 3633, 302 December 2003. 304 Authors' Addresses 306 Ralph Droms 307 Cisco Systems, Inc. 308 1414 Massachusetts Avenue 309 Boxborough, MA 01719 310 USA 312 Phone: +1 978.936.1674 313 Email: rdroms@cisco.com 314 Bernie Volz 315 Cisco Systems, Inc. 316 1414 Massachusetts Avenue 317 Boxborough, MA 01719 318 USA 320 Phone: +1 978.936.0382 321 Email: volz@cisco.com 323 Ole Troan 324 Cisco Systems, Inc. 326 Phone: +47 23 27 3664 327 Email: otroan@cisco.com