idnits 2.17.1 draft-szeng-dhc-dhcpv6-ero-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 250. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 263. ** 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 '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 -- 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 (June 16, 2006) is 6517 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) == Unused Reference: '4' is defined on line 188, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (ref. '2') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. '4') (Obsoleted by RFC 8415) == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-agentopt-delegate-00 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC S. Zeng 3 Internet-Draft B. Volz 4 Expires: December 18, 2006 K. Kinnear 5 Cisco Systems, Inc. 6 J. Brzozowski 7 Comcast Cable 8 June 16, 2006 10 DHCPv6 Relay Agent Echo Request Option 11 draft-szeng-dhc-dhcpv6-ero-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 18, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This memo defines a Relay Agent Echo Request option for the Dynamic 45 Host Configuration Protocol for IPv6 (DHCPv6). The option allows a 46 DHCPv6 relay agent to request a list of relay agent options that the 47 server echoes back to the relay agent. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 53 3. The Relay Agent Echo Request Option . . . . . . . . . . . . . . 3 54 4. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . . . . 4 55 5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 4 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 61 9.2. Informative References . . . . . . . . . . . . . . . . . . 5 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 63 Intellectual Property and Copyright Statements . . . . . . . . . . 8 65 1. Introduction 67 DHCPv6 [2] provides a framework for configuring IPv6 clients with 68 addresses and other network parameters. It includes a relay agent 69 capability. A relay agent is an intermediary node that delivers DHCP 70 messages between clients and servers. The relay agent and the server 71 exchange information using options in relay agent messages. The 72 relay agent may add relay agent options to the client DHCP message 73 before forwarding it. 75 The information that relay agents supply can be used in the server's 76 decision making about the addresses, delegated prefixes, and 77 configuration parameters that the client is to receive. Likewise, 78 the relay may need some of the information to efficiently return 79 replies to clients. 81 In DHCPv4, the server generally echoes the relay agent option back 82 verbatim to the relay agent in server-to-client replies [3]. 83 However, DHCPv6 [2] does not require the server to do so. As matter 84 of fact, for certain relay agent options, the server is required to 85 echo back the options only if it recognizes them (e.g., [5], [6]). 86 This could be problematic, as the relay agent may need to use some 87 relay options even if the server does not recognize them. 89 This memo defines a relay agent echo request option that the relay 90 agent uses to explicitly request a list of options that the server 91 echoes back to the relay agent. 93 2. Requirements Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [1]. 99 3. The Relay Agent Echo Request Option 101 The relay agent adds options in the Relay Forward message that the 102 server uses to guide its decision making with regard to address 103 assignment, prefix delegation, and configuration parameters. The 104 relay agent also knows which of these options that it will need to 105 efficiently return replies to the client. It uses the relay agent 106 Echo Request option to inform the server the list of relay agent 107 options that the server must echo back. 109 The format of the DHCPv6 Relay Agent Echo Request option is shown 110 below: 112 0 1 2 3 113 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 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | OPTION_ERO | option-len | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | requested-option-code-1 | requested-option-code-2 | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | ... | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 option-code OPTION_ERO (TBD). 123 option-len 2 * number of requested options. 124 requested-option-code-n The option code for an option requested by 125 the relay agent. 127 4. DHCPv6 Relay Agent Behavior 129 A relay agent MAY include an Echo Request option in a Relay Forward 130 message to inform the server about options the relay agent wants the 131 server to echo back to the relay agent. If the relay agent takes 132 different actions based on whether an option is echoed back or not, 133 then the relay agent SHOULD NOT include such an option in the Echo 134 Request option. Note that the relay uses the OPTION_ORO [2] to 135 request the server to return options (e.g., [7]) other than relay 136 agent options in the Relay Forward message. 138 5. DHCPv6 Server Behavior 140 When a server creates a Relay-Reply, it SHOULD perform ERO processing 141 after processing the ORO and other options processing. For each 142 option in the ERO: 143 a. If the option is already in the Relay-Reply, the server MUST 144 ignore that option and continue to process any remaining options 145 in the ERO. 146 b. If the option was not in the received Relay-Forward, the server 147 MUST ignore that option and continue to process any remaining 148 options in the ERO. 150 c. Otherwise, the server MUST copy the option, verbatim, from the 151 received Relay-Forward to the Relay-Reply, even if the server 152 does not otherwise recognize that option. 154 6. Security Considerations 156 As the Echo Request option is only exchanged between relay agents and 157 DHCPv6 servers, [2] section 21.1, provides details on securing DHCPv6 158 messages sent between servers and relay agents. And, [2] section 23, 159 provides general DHCPv6 security considerations. 161 7. IANA Considerations 163 IANA is requested to assign a DHCPv6 option code for the OPTION_ERO 164 (Relay Agent Echo Request) Option. 166 8. Acknowledgements 168 Thanks to Ralph Droms, Josh Littlefield, Richard Johnson, and Hemant 169 Singh for their consistent input, ideas and review during the 170 production of this document. 172 9. References 174 9.1. Normative References 176 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 177 Levels", BCP 14, RFC 2119, March 1997. 179 [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 180 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 181 RFC 3315, July 2003. 183 [3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 184 January 2001. 186 9.2. Informative References 188 [4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 189 Configuration Protocol (DHCP) version 6", RFC 3633, 190 December 2003. 192 [5] Volz, B., "DHCPv6 Relay Agent Subscriber-ID Option", 193 draft-ietf-dhc-dhcpv6-subid-01 (work in progress), March 2006. 195 [6] Volz, B., "DHCPv6 Relay Agent Remote ID Option", 196 draft-ietf-dhc-dhcpv6-remoteid-01 (work in progress), 197 March 2006. 199 [7] Droms, R., "DHCP Relay Agent Assignment Notification Option", 200 draft-ietf-dhc-dhcpv6-agentopt-delegate-00 (work in progress), 201 January 2006. 203 Authors' Addresses 205 Shengyou Zeng 206 Cisco Systems, Inc. 207 1414 Massachusetts Ave. 208 Boxborough, MA 01719 209 USA 211 Phone: +1 978 936 0000 212 Email: szeng@cisco.com 214 Bernard Volz 215 Cisco Systems, Inc. 216 1414 Massachusetts Ave. 217 Boxborough, MA 01719 218 USA 220 Phone: +1 978 936 0000 221 Email: volz@cisco.com 223 Kim Kinnear 224 Cisco Systems, Inc. 225 1414 Massachusetts Ave. 226 Boxborough, MA 01719 227 USA 229 Phone: +1 978 936 0000 230 Email: kkinnear@cisco.com 232 John Jason Brzozowski 233 Comcast Cable 234 1800 Bishops Gate Boulevard 235 Mt. Laurel, NJ 08054 236 USA 238 Phone: +1 856 324 2671 239 Email: john_brzozowski@cable.comcast.com 241 Intellectual Property Statement 243 The IETF takes no position regarding the validity or scope of any 244 Intellectual Property Rights or other rights that might be claimed to 245 pertain to the implementation or use of the technology described in 246 this document or the extent to which any license under such rights 247 might or might not be available; nor does it represent that it has 248 made any independent effort to identify any such rights. Information 249 on the procedures with respect to rights in RFC documents can be 250 found in BCP 78 and BCP 79. 252 Copies of IPR disclosures made to the IETF Secretariat and any 253 assurances of licenses to be made available, or the result of an 254 attempt made to obtain a general license or permission for the use of 255 such proprietary rights by implementers or users of this 256 specification can be obtained from the IETF on-line IPR repository at 257 http://www.ietf.org/ipr. 259 The IETF invites any interested party to bring to its attention any 260 copyrights, patents or patent applications, or other proprietary 261 rights that may cover technology that may be required to implement 262 this standard. Please address the information to the IETF at 263 ietf-ipr@ietf.org. 265 Disclaimer of Validity 267 This document and the information contained herein are provided on an 268 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 269 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 270 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 271 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 272 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 273 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 275 Copyright Statement 277 Copyright (C) The Internet Society (2006). This document is subject 278 to the rights, licenses and restrictions contained in BCP 78, and 279 except as set forth therein, the authors retain all their rights. 281 Acknowledgment 283 Funding for the RFC Editor function is currently provided by the 284 Internet Society.