idnits 2.17.1 draft-ietf-dhc-relay-agent-flags-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 267. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 280. ** 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 8, 2006) is 6529 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) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC K. Kinnear 3 Internet-Draft M. Normoyle 4 Expires: December 10, 2006 M. Stapp 5 Cisco Systems, Inc. 6 June 8, 2006 8 DHCPv4 Relay Agent Flags Suboption 9 draft-ietf-dhc-relay-agent-flags-01.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 December 10, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This memo defines a new suboption of the DHCP relay agent information 43 option that allows the DHCP relay to specify flags for the forwarded 44 packet. One flag is defined to indicate whether the DHCP relay 45 received the packet via a unicast or broadcast packet. This 46 information may be used by the DHCP server to better serve clients 47 based on whether their request was originally broadcast or unicast. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 53 3. The Flags Suboption . . . . . . . . . . . . . . . . . . . . . . 4 54 4. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . . 4 55 5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 5 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 61 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 63 Intellectual Property and Copyright Statements . . . . . . . . . . 8 65 1. Introduction 67 Any time a client's DHCP packet is broadcast, a local DHCP relay will 68 process its request and forward it on to the DHCP server. When the 69 DHCP relay performs this function, it can be configured to use the 70 DHCP relay agent information option to forward additional information 71 to the DHCP server, which the server may then use to alter its 72 processing algorithms. Once the lease has been granted, however, 73 future DHCP DHCPREQUEST/RENEWAL messages are unicast directly to the 74 DHCP Server. [RFC2131] [RFC2132] [RFC3046] 76 In general, DHCP servers may also make subtle (and sometimes not so 77 subtle) changes in their processing algorithms depending on whether 78 or not the DHCP server received the message as a unicast packet from 79 the DHCP client directly, a broadcast packet from the DHCP client on 80 a locally connected network, or a unicast packet from a DHCP Relay 81 Agent which has forwarded on a packet broadcast from a DHCP client 82 connected to a network local to the DHCP Relay Agent. 84 In some situations, DHCP Clients may unicast their DHCPREQUEST/RENEW 85 packets to the DHCP Relay Agent, which will forward the packet on to 86 the DHCP server. In these cases, the DHCP server cannot tell whether 87 the packet was broadcast or unicast by the DHCP client, and so it may 88 be unable to process the DHCP client packets in the manner that it 89 would if it knew whether the original DHCP packet was broadcast or 90 unicast. 92 The purpose of the suboption described in this document is to allow 93 the DHCP relay to specify flags for the forwarded packet. These 94 flags can be used to describe DHCP client attributes that are useful 95 to the DHCP server, but can only be detected by the local DHCP relay. 96 The DHCP server can use the information provided by the DHCP relay to 97 improve its processing algorithms. 99 One flag is defined to indicate whether the DHCP relay received the 100 packet via a unicast or broadcast packet. This allows the DHCP 101 server to know if a packet forwarded on by a DHCP Relay Agent was 102 broadcast or unicast to the DHCP Relay Agent. 104 2. Requirements Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. The Flags Suboption 112 The Flags suboption provides an extensible suboption definition for 113 several possible flags. The first flag defined is the unicast flag. 115 The format of the suboption is: 117 0 1 2 118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Code | Length | Flags | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 Code The suboption code. (TBD, to be assigned by IANA). 125 Length The suboption length, 1 octet. 127 Flags The Relay Agent flags for this forwarded packet. 129 0 1 2 3 4 5 6 7 130 +-+-+-+-+-+-+-+-+ 131 |U| MBZ | 132 +-+-+-+-+-+-+-+-+ 134 U: UNICAST flag 136 unicast = 1 137 broadcast = 0 139 MBZ: MUST BE ZERO (reserved for future use) 141 4. DHCP Relay Agent Behavior 143 A DHCP relay agent MUST include this suboption in every Relay Agent 144 Information Option [RFC3046] it adds to a forwarded DHCP request. In 145 this way, the DHCP server can distinguish a request forwarded from a 146 DHCP relay agent which does not support the relay-agent-flags 147 suboption from a request forwarded by a DHCP relay agent which 148 supports the relay-agent-flags suboption and which received the 149 request that is being forwarded in a broadcast packet. 151 To put this another way, A DHCP relay agent which supports the relay- 152 agent-flags suboption MUST always include it in every relay-agent- 153 information-option that it inserts into packets which it forwards on 154 to the DHCP server, whether the packet it is forwarding was received 155 as a broadcast or as a unicast. This is because the DHCP server will 156 be dealing with DHCP relay agents that support the relay-agent-flags 157 suboption as well as DHCP relay agents that do not support the relay- 158 agent-flags suboption. 160 5. DHCP Server Behavior 162 This option provides additional information to the DHCP server. The 163 DHCP server MAY use this information to make processing decisions 164 regarding the DHCP Client's packet which it is processing. For 165 instance, knowledge of the broadcast or unicast reception of a packet 166 by a DHCP relay agent is important when making the processing 167 decisions required to implement Load Balancing [RFC3074]. 169 The option length is one octet. If the DHCP server receives a relay- 170 agent-flags suboption that is longer than one octet, it MUST evaluate 171 the first octet. 173 6. Security Considerations 175 Message authentication in DHCP for intradomain use where the out-of- 176 band exchange of a shared secret is feasible is defined in [RFC3118]. 177 Potential exposures to attack are discussed in section 7 of the DHCP 178 protocol specification in [RFC2131]. 180 The DHCP Relay Agent option depends on a trusted relationship between 181 the DHCP relay agent and the server, as described in section 5 of 182 [RFC3046]. While the introduction of fraudulent relay-agent options 183 can be prevented by a perimeter defense that blocks these options 184 unless the relay agent is trusted, a deeper defense using the 185 authentication option for relay agent options [RFC4030] SHOULD be 186 deployed as well. 188 7. IANA Considerations 190 IANA is requested to assign a suboption number for the Flags 191 Suboption from the DHCP Relay Agent Information Option [RFC3046] 192 suboption number space. 194 8. Acknowledgements 196 Thanks to David Hankins for realizing the problems created by the 197 server-id-override option draft and for helping us understand the 198 value of finally solving this problem in a way that has general 199 applicability. 201 9. References 203 9.1. Normative References 205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels", BCP 14, RFC 2119, March 1997. 208 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 209 RFC 2131, March 1997. 211 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 212 Extensions", RFC 2132, March 1997. 214 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 215 RFC 3046, January 2001. 217 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 218 Messages", RFC 3118, June 2001. 220 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 221 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 222 Option", RFC 4030, March 2005. 224 9.2. Informative References 226 [RFC3074] Volz, B., Gonczi, S., Lemon, T., and R. Stevens, "DHC Load 227 Balancing Algorithm", RFC 3074, February 2001. 229 Authors' Addresses 231 Kim Kinnear 232 Cisco Systems, Inc. 233 1414 Massachusetts Ave. 234 Boxborough, MA 01719 235 US 237 Phone: +1 978 936 0000 238 Email: kkinnear@cisco.com 240 Marie Normoyle 241 Cisco Systems, Inc. 242 1414 Massachusetts Ave. 243 Boxborough, MA 01719 244 US 246 Phone: +1 978 936 0000 247 Email: mnormoyle@cisco.com 249 Mark Stapp 250 Cisco Systems, Inc. 251 1414 Massachusetts Ave. 252 Boxborough, MA 01719 253 US 255 Phone: +1 978 936 0000 256 Email: mjs@cisco.com 258 Intellectual Property Statement 260 The IETF takes no position regarding the validity or scope of any 261 Intellectual Property Rights or other rights that might be claimed to 262 pertain to the implementation or use of the technology described in 263 this document or the extent to which any license under such rights 264 might or might not be available; nor does it represent that it has 265 made any independent effort to identify any such rights. Information 266 on the procedures with respect to rights in RFC documents can be 267 found in BCP 78 and BCP 79. 269 Copies of IPR disclosures made to the IETF Secretariat and any 270 assurances of licenses to be made available, or the result of an 271 attempt made to obtain a general license or permission for the use of 272 such proprietary rights by implementers or users of this 273 specification can be obtained from the IETF on-line IPR repository at 274 http://www.ietf.org/ipr. 276 The IETF invites any interested party to bring to its attention any 277 copyrights, patents or patent applications, or other proprietary 278 rights that may cover technology that may be required to implement 279 this standard. Please address the information to the IETF at 280 ietf-ipr@ietf.org. 282 Disclaimer of Validity 284 This document and the information contained herein are provided on an 285 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 286 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 287 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 288 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 289 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 290 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 292 Copyright Statement 294 Copyright (C) The Internet Society (2006). This document is subject 295 to the rights, licenses and restrictions contained in BCP 78, and 296 except as set forth therein, the authors retain all their rights. 298 Acknowledgment 300 Funding for the RFC Editor function is currently provided by the 301 Internet Society.