idnits 2.17.1 draft-szeng-dhc-dhcpv6-ero-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 250. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 274. 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 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 (March 05, 2007) is 6254 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) == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-agentopt-delegate-02 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 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 Intended status: Standards Track K. Kinnear 5 Expires: September 6, 2007 Cisco Systems, Inc. 6 J. Brzozowski 7 Comcast Cable 8 March 05, 2007 10 DHCPv6 Relay Agent Echo Request Option 11 draft-szeng-dhc-dhcpv6-ero-02.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 September 6, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 63 Intellectual Property and Copyright Statements . . . . . . . . . . 7 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 a 84 matter of fact, for certain relay agent options, the server is 85 required to echo back the options only if it recognizes them (e.g., 86 [4], [5]). This could be problematic, as the relay agent may need to 87 use some 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., [6]) 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] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 189 Relay Agent Subscriber-ID Option", RFC 4580, June 2006. 191 [5] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 192 Relay Agent Remote-ID Option", RFC 4649, August 2006. 194 [6] Droms, R., "DHCPv6 Relay Agent Assignment Notification (RAAN) 195 Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-02 (work in 196 progress), November 2006. 198 Authors' Addresses 200 Shengyou Zeng 201 Cisco Systems, Inc. 202 1414 Massachusetts Ave. 203 Boxborough, MA 01719 204 USA 206 Phone: +1 978 936 0000 207 Email: szeng@cisco.com 209 Bernard Volz 210 Cisco Systems, Inc. 211 1414 Massachusetts Ave. 212 Boxborough, MA 01719 213 USA 215 Phone: +1 978 936 0000 216 Email: volz@cisco.com 218 Kim Kinnear 219 Cisco Systems, Inc. 220 1414 Massachusetts Ave. 221 Boxborough, MA 01719 222 USA 224 Phone: +1 978 936 0000 225 Email: kkinnear@cisco.com 227 John Jason Brzozowski 228 Comcast Cable 229 1800 Bishops Gate Boulevard 230 Mt. Laurel, NJ 08054 231 USA 233 Phone: +1 856 324 2671 234 Email: john_brzozowski@cable.comcast.com 236 Full Copyright Statement 238 Copyright (C) The IETF Trust (2007). 240 This document is subject to the rights, licenses and restrictions 241 contained in BCP 78, and except as set forth therein, the authors 242 retain all their rights. 244 This document and the information contained herein are provided on an 245 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 246 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 247 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 248 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 249 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 250 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 252 Intellectual Property 254 The IETF takes no position regarding the validity or scope of any 255 Intellectual Property Rights or other rights that might be claimed to 256 pertain to the implementation or use of the technology described in 257 this document or the extent to which any license under such rights 258 might or might not be available; nor does it represent that it has 259 made any independent effort to identify any such rights. Information 260 on the procedures with respect to rights in RFC documents can be 261 found in BCP 78 and BCP 79. 263 Copies of IPR disclosures made to the IETF Secretariat and any 264 assurances of licenses to be made available, or the result of an 265 attempt made to obtain a general license or permission for the use of 266 such proprietary rights by implementers or users of this 267 specification can be obtained from the IETF on-line IPR repository at 268 http://www.ietf.org/ipr. 270 The IETF invites any interested party to bring to its attention any 271 copyrights, patents or patent applications, or other proprietary 272 rights that may cover technology that may be required to implement 273 this standard. Please address the information to the IETF at 274 ietf-ipr@ietf.org. 276 Acknowledgment 278 Funding for the RFC Editor function is provided by the IETF 279 Administrative Support Activity (IASA).