idnits 2.17.1 draft-ietf-dhc-dhcpv6-agentopt-delegate-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 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 (April 1, 2017) is 2580 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) == Outdated reference: A later version (-05) exists of draft-ietf-dhc-relay-server-security-04 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Droms 3 Internet-Draft 4 Intended status: Standards Track B. Volz 5 Expires: October 3, 2017 Cisco Systems 6 O. Troan 7 Cisco Systems, Inc. 8 April 1, 2017 10 DHCPv6 Relay Agent Assignment Notification (RAAN) Option 11 draft-ietf-dhc-dhcpv6-agentopt-delegate-05.txt 13 Abstract 15 The DHCP Relay Agent Assignment Notification (RAAN) option is sent 16 from a DHCP server to a DHCP relay agent to inform the relay agent of 17 IPv6 addresses that have been assigned or IPv6 prefixes that have 18 been delegated to DHCP clients. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 3, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language and Terminology . . . . . . . . . . . . 3 56 3. Option Semantics and Usage . . . . . . . . . . . . . . . . . 3 57 4. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 4 58 5. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 4 59 6. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 4 60 7. Encapsulating DHCP Options in the RAAN Option . . . . . . . . 5 61 7.1. IA Address Option . . . . . . . . . . . . . . . . . . . . 5 62 7.2. IA Prefix Option . . . . . . . . . . . . . . . . . . . . 6 63 8. Requesting Assignment Information from the DHCP Server . . . 6 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 11. Changes Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 12.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 The DHCP Relay Agent Assignment Notification (RAAN) option 75 encapsulates address and prefix options to indicate that an address 76 or prefix has been assigned. The option may also carry other 77 information required by the network element for configuration related 78 to the assigned address or prefix. 80 For example, a relay agent uses the RAAN option to learn when a 81 prefix that has been delegated through DHCP prefix delegation (PD) to 82 a DHCP client. The relay agent notifies the network element on which 83 it is implemented of the delegation information so the network 84 element can add routing information about the delegated prefix into 85 the routing infrastructure. 87 While the practice to date for DHCPv6 has been for the relay agents 88 to "snoop" the client's message (encapsulated in the received Relay 89 Message option, and which is forwarded to the client), this will no 90 longer be possible when clients and servers use 91 [I-D.ietf-dhc-sedhcpv6] to encrypt their communication. 93 Use of the RAAN option has another benefit in that the Reply to a 94 client's Release message, which does not have any useful information 95 for the relay agent about the addresses or delegated prefixes the 96 client released, can now communicate this information in the RAAN 97 option to the relay agent. 99 2. Requirements Language and Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119] when they 104 appear in ALL CAPS. When these words are not in ALL CAPS (such as 105 "should" or "Should"), they have their usual English meanings, and 106 are not to be interpreted as [RFC2119] key words. 108 The term "DHCP" in this document refers to DHCP for IPv6, as defined 109 in [RFC3315]. The terms "DHCP prefix delegation" and "DHCP PD" refer 110 DHCP for IPv6 prefix delegation, as defined in [RFC3633]. 112 Additional terms used in the description of DHCP and DHCP prefix 113 delegation are defined in RFC 3315 and RFC 3633. In this document 114 "assigning" an IPv6 prefix is equivalent to "delegating" a prefix. 116 3. Option Semantics and Usage 118 The RAAN option carries information about assigned IPv6 addresses and 119 prefixes. It encapsulates IA Address options (RFC 3315) and/or IA 120 Prefix options (RFC 3633), and possibly other options that carry 121 other information related to the assigned IPv6 address or prefix. 123 The DHCP server is responsible for synchronizing any state created by 124 a node through the use of the RAAN option. For example, if a DHCP 125 server receives a Release message for a delegated prefix, it causes 126 the node to delete any state associated with that prefix by sending a 127 RAAN option containing an IA Prefix option with the released prefix 128 and a valid lifetime of zero. 130 When a DHCP server sends this option to a relay agent, it MUST 131 include all addresses and prefixes assigned to the client on the link 132 to which the option refers at the time the option is sent. 134 Examples of use: 136 o Populate an ACL with an assigned IPv6 address if the network 137 security policy requires limiting IPv6 forwarding to devices that 138 have obtained an address through DHCP. 140 o Inject routing information into a routing infrastructure about a 141 delegated prefix on behalf of a requesting router. 143 4. Relay Agent Behavior 145 A relay agent that wants information from the server in a RAAN option 146 includes an ORO requesting the RAAN option in its Relay-Forw message. 147 A relay agent may do this for any relayed message, regardless of the 148 message type or the message contents. 150 When a relay agent receives a Relay-Reply message containing a RAAN 151 option, the relay agent may forward that option data to the node in 152 which the relay agent is instantiated. If no RAAN option is included 153 in the Relay-Reply, the relay agent MUST NOT assume anything with 154 regard to RAAN data and MUST NOT forward any indication to the node 155 in which the relay agent is instantiated. 157 If a node creates state based on the information included in this 158 option, it MUST remove that state when the lifetime as specified in 159 the option expires. 161 One concern with the RAAN option is that messages from the DHCP 162 server may be received (or processed) out of order. But this concern 163 is no different than that for the "snooping" which has been used by 164 relay agents for many years (both in DHCPv4 and DHCPv6). 165 Implementers should be aware of this and should consider making use 166 of Leasequery ([RFC5007]) to resolve conflicts. 168 5. Server Behavior 170 When a server is responding to a request and the ORO contains an RAAN 171 option, the server SHOULD include a RAAN option with all of the 172 addresses and prefixes that have been (or are being assigned) to the 173 client. If no addresses or prefixes are assigned, the server SHOULD 174 send a RAAN option with no addresses or prefixes. 176 If the DHCP server does include this option in a Relay-Reply message, 177 it MUST include it in the option area of the Relay-Reply message sent 178 to the relay agent intended as the recipient of the option. 180 If the message received from the client contains no Client Identifier 181 option or the server is otherwise unable to identify the client or 182 the client's link (perhaps because of missing or invalid data in the 183 request), the server MUST NOT include a RAAN option in the response. 185 6. Option Format 187 The RAAN option has the following format: 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | option-code | length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 . . 195 . encapsulated-options . 196 . . 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 1: Relay Agent Assignment Notification Option Format 201 option-code OPTION_AGENT_NOTIFY (TBD). 203 option-len Length of encapsulated options, in octets. 205 encapsulated-options DHCP options to be delivered by the relay agent 206 Assignment Notification option. 208 7. Encapsulating DHCP Options in the RAAN Option 210 The contents of options encapsulated in the RAAN option are 211 interpreted according to the use of those options in the node on 212 which the relay agent is implemented. For the purposes of address 213 and prefix assignment, the uses of the DHCP IA Address and IA Prefix 214 options are defined in this document. 216 Note that the contents of these options are not necessarily the same 217 as in the corresponding options sent to the DHCP client. 219 7.1. IA Address Option 221 The fields in an IA Address option (OPTION_IAADDR, option code 5) are 222 used as follows: 224 IPv6 address The IPv6 address assigned in this DHCP message 226 preferred-lifetime Not used by the relay agent; the server SHOULD 227 set this field to the preferred-lifetime of the 228 corresponding IA Address options in the message 229 to be forwarded to the client 231 valid-lifetime The lifetime of the information carried in this 232 IA Address option, expressed in units of 233 seconds; if the valid-lifetime is 0, the 234 information is no longer valid 236 IAaddr-options Not used by the relay agent; the server SHOULD 237 set this field to the IAaddr-options of the 238 corresponding IA Address option in the message 239 to be forwarded to the client 241 7.2. IA Prefix Option 243 The fields in an IA Prefix option (OPTION_IAPREFIX, option code 28) 244 are used as follows: 246 preferred-lifetime Not used by the relay agent; the server SHOULD 247 set this field to the preferred-lifetime of the 248 corresponding IA Prefix options in the message 249 to be forwarded to the client 251 valid-lifetime The lifetime of the information carried in this 252 IA Prefix option, expressed in units of seconds; 253 if the valid-lifetime is 0, the information is 254 no longer valid 256 prefix-length Length for this prefix in bits 258 IPv6-prefix The IPv6 prefix assigned in this DHCP message 260 IAprefix-options Not used by the relay agent; the server SHOULD 261 set this field to the IAprefix-options of the 262 corresponding IA Prefix option in the message to 263 be forwarded to the client 265 8. Requesting Assignment Information from the DHCP Server 267 If a relay agent requires the DHCP server to provide information 268 about assigned addresses and prefixes, it MUST include an Option 269 Request option, requesting the Assignment Notification option, as 270 described in section 22.7 of RFC 3315. 272 9. IANA Considerations 274 IANA is requested to assign an option code from the "DHCPv6 and 275 DHCPv6 options" registry http://www.iana.org/assignments/ 276 dhcpv6-parameters to OPTION_AGENT_NOTIFY. 278 10. Security Considerations 280 Security issues related to DHCP are described in RFC 3315 and RFC 281 3633. 283 The RAAN option may be used to mount a denial of service attack by 284 causing a node to incorrectly populate an ACL or incorrectly 285 configure routing information for a delegated prefix. This option 286 may also be used to insert invalid prefixes into the routing 287 infrastructure or add invalid IP addresses to ACLs in nodes. 288 Communication between a server and a relay agent, and communication 289 between relay agents, can be secured through the use of IPSec, as 290 described in [I-D.ietf-dhc-relay-server-security]. 292 11. Changes Log 294 If this section is included in the document when it is submitted for 295 publication, the RFC Editor is requested to remove it. 297 Changes in rev -01: 299 o Added section describing use of "Server Reply Sequence Number" 300 option to allow resequencing of out-of-order messages. 302 Changes in rev -02: 304 o Made editorial change in section 1: s/the appropriate routing 305 protocols/the routing infrastructure/ 307 o Updated first paragraph in Section 3 to allow multiple IA 308 Address options and/or IA Prefix options 310 o Renamed section 3 to "Options Semantics and Usage" 312 o Added paragraph to section "Option Semantics and Usage" 313 requiring that the DHCP server must include all addresses/ 314 prefixes for the client (on that link) in the RAAN option 316 o Added list of use cases to section "Option Semantics and Usage" 318 o Added section "Relay Agent Behavior" 320 o Added section "Server Behavior"; moved second paragraph of 321 section "Option Semantics and Usage" to "Server Behavior" 323 o Updated reference to draft-ietf-dhc-dhcpv6-srsn-option-00 325 o Clarified descriptions of various option fields in section 326 "Encapsulating DHCP options in the RAAN Option" 328 Changes in rev -03: refreshed after expiration. 330 Changes in rev -04: all references to the "Server Reply Sequence 331 Number" option were removed from the draft. 333 Changes in rev -05: 335 o Converted the -04 text version to xml. 337 o Updated introduction to add motivation for option because of 338 [I-D.ietf-dhc-sedhcpv6], and also Reply to Release "snooping" 339 issues. 341 o Updated security considerations to reference IPsec document 342 ([I-D.ietf-dhc-relay-server-security]). 344 12. References 346 12.1. Normative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, 350 DOI 10.17487/RFC2119, March 1997, 351 . 353 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 354 C., and M. Carney, "Dynamic Host Configuration Protocol 355 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 356 2003, . 358 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 359 Host Configuration Protocol (DHCP) version 6", RFC 3633, 360 DOI 10.17487/RFC3633, December 2003, 361 . 363 12.2. Informative References 365 [I-D.ietf-dhc-relay-server-security] 366 Volz, B. and Y. Pal, "Security of Messages Exchanged 367 Between Servers and Relay Agents", draft-ietf-dhc-relay- 368 server-security-04 (work in progress), March 2017. 370 [I-D.ietf-dhc-sedhcpv6] 371 Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. 372 Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work 373 in progress), February 2017. 375 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 376 "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, 377 September 2007, . 379 Authors' Addresses 381 Ralph Droms 383 Email: rdroms.ietf@gmail.com 385 Bernie Volz 386 Cisco Systems, Inc. 387 1414 Massachusetts Ave 388 Boxborough, MA 01719 389 USA 391 Email: volz@cisco.com 393 Ole Troan 394 Cisco Systems, Inc. 395 Oslo 396 Norway 398 Email: otroan@cisco.com