idnits 2.17.1 draft-ietf-dhc-relay-agent-flags-03.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, updated by RFC 4748 on line 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 313. 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 (April 23, 2007) is 6206 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: 1 error (**), 0 flaws (~~), 1 warning (==), 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 Intended status: Standards Track M. Stapp 5 Expires: October 25, 2007 Cisco Systems, Inc. 6 April 23, 2007 8 DHCPv4 Relay Agent Flags Suboption 9 draft-ietf-dhc-relay-agent-flags-03.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 October 25, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . . . . . 6 58 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 61 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 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. For example, a server might be willing to NAK a client in 91 the REBINDING state based on a determination that the client's 92 address does not match its location in the network, but might not be 93 willing to do so if the client is in the RENEWING state. 95 The purpose of the suboption described in this document is to allow 96 the DHCP relay to specify flags for the forwarded packet. These 97 flags can be used to describe DHCP client attributes that are useful 98 to the DHCP server, but can only be detected by the local DHCP relay. 99 The DHCP server can use the information provided by the DHCP relay to 100 improve its processing algorithms. 102 One flag is defined to indicate whether the DHCP relay received the 103 packet via a unicast or broadcast packet. This allows the DHCP 104 server to know if a packet forwarded on by a DHCP Relay Agent was 105 broadcast or unicast to the DHCP Relay Agent. 107 2. Requirements Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. The Flags Suboption 115 The Flags suboption provides an extensible suboption definition for 116 several possible flags. The first flag defined is the unicast flag. 118 The format of the suboption is: 120 0 1 2 121 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Code | Length | Flags | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 Code The suboption code. (TBD, to be assigned by IANA). 128 Length The suboption length, 1 octet. 130 Flags The Relay Agent flags for this forwarded packet. 132 0 1 2 3 4 5 6 7 133 +-+-+-+-+-+-+-+-+ 134 |U| MBZ | 135 +-+-+-+-+-+-+-+-+ 137 U: UNICAST flag 139 unicast = 1 140 broadcast = 0 142 MBZ: MUST BE ZERO (reserved for future use) 144 4. DHCP Relay Agent Behavior 146 A DHCP relay agent that claims to conform to this specification MUST 147 include this suboption in every Relay Agent Information Option 148 [RFC3046] it adds to a forwarded DHCP request. In this way, the DHCP 149 server can distinguish a request forwarded from a DHCP relay agent 150 that does not support the relay-agent-flags suboption from a request 151 forwarded by a DHCP relay agent that supports the relay-agent-flags 152 suboption and which received the request that is being forwarded in a 153 broadcast packet. 155 To put this another way, A DHCP relay agent which supports the relay- 156 agent-flags suboption MUST always include it in every relay-agent- 157 information-option that it inserts into packets which it forwards on 158 to the DHCP server, whether the packet it is forwarding was received 159 as a broadcast or as a unicast. This is because the DHCP server will 160 be dealing with DHCP relay agents that support the relay-agent-flags 161 suboption as well as DHCP relay agents that do not support the relay- 162 agent-flags suboption. 164 5. DHCP Server Behavior 166 This option provides additional information to the DHCP server. The 167 DHCP server MAY use this information to make processing decisions 168 regarding the DHCP Client's packet which it is processing. For 169 instance, knowledge of the broadcast or unicast reception of a packet 170 by a DHCP relay agent could be used when making the processing 171 decisions required to implement Load Balancing [RFC3074]. A load- 172 balancing server may be willing to respond to a REBINDING client, but 173 the server cannot determine the client's state without this 174 additional indication. 176 The option length is one octet. If the DHCP server receives a relay- 177 agent-flags suboption that is longer than one octet, it MUST evaluate 178 the first octet. 180 Note to implementors: In specifying the behavior of new flags bits in 181 the future, careful attention must be paid to compatibility with 182 earlier implementations. If additional flags values are defined in 183 the future, it will not always be possible to distinguish between 184 messages from relay agents who understand the new value and set its 185 value to 'zero', and relay agents who are simply setting a series of 186 unassigned bits to 'zero'. It would be a mistake to specify 187 significant behavior changes based on 'zero' values of flags 188 specified in the future. 190 6. Security Considerations 192 Message authentication in DHCP for intradomain use where the out-of- 193 band exchange of a shared secret is feasible is defined in [RFC3118]. 194 Potential exposures to attack are discussed in section 7 of the DHCP 195 protocol specification in [RFC2131]. 197 The DHCP Relay Agent option depends on a trusted relationship between 198 the DHCP relay agent and the server, as described in section 5 of 199 [RFC3046]. While the introduction of fraudulent relay-agent options 200 can be prevented by a perimeter defense that blocks these options 201 unless the relay agent is trusted, a deeper defense using the 202 authentication option for relay agent options [RFC4030] SHOULD be 203 deployed as well. 205 7. IANA Considerations 207 IANA is requested to assign a suboption number for the Flags 208 Suboption from the DHCP Relay Agent Information Option [RFC3046] 209 suboption number space. 211 8. Acknowledgements 213 Thanks to David Hankins for realizing the problems created by the 214 server-id-override option draft and for helping us understand the 215 value of finally solving this problem in a way that has general 216 applicability. 218 9. References 220 9.1. Normative References 222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 223 Requirement Levels", BCP 14, RFC 2119, March 1997. 225 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 226 RFC 2131, March 1997. 228 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 229 Extensions", RFC 2132, March 1997. 231 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 232 RFC 3046, January 2001. 234 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 235 Messages", RFC 3118, June 2001. 237 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 238 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 239 Option", RFC 4030, March 2005. 241 9.2. Informative References 243 [RFC3074] Volz, B., Gonczi, S., Lemon, T., and R. Stevens, "DHC Load 244 Balancing Algorithm", RFC 3074, February 2001. 246 Authors' Addresses 248 Kim Kinnear 249 Cisco Systems, Inc. 250 1414 Massachusetts Ave. 251 Boxborough, MA 01719 252 US 254 Phone: +1 978 936 0000 255 Email: kkinnear@cisco.com 257 Marie Normoyle 258 Cisco Systems, Inc. 259 1414 Massachusetts Ave. 260 Boxborough, MA 01719 261 US 263 Phone: +1 978 936 0000 264 Email: mnormoyle@cisco.com 266 Mark Stapp 267 Cisco Systems, Inc. 268 1414 Massachusetts Ave. 269 Boxborough, MA 01719 270 US 272 Phone: +1 978 936 0000 273 Email: mjs@cisco.com 275 Full Copyright Statement 277 Copyright (C) The IETF Trust (2007). 279 This document is subject to the rights, licenses and restrictions 280 contained in BCP 78, and except as set forth therein, the authors 281 retain all their rights. 283 This document and the information contained herein are provided on an 284 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 285 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 286 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 287 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 288 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 289 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 291 Intellectual Property 293 The IETF takes no position regarding the validity or scope of any 294 Intellectual Property Rights or other rights that might be claimed to 295 pertain to the implementation or use of the technology described in 296 this document or the extent to which any license under such rights 297 might or might not be available; nor does it represent that it has 298 made any independent effort to identify any such rights. Information 299 on the procedures with respect to rights in RFC documents can be 300 found in BCP 78 and BCP 79. 302 Copies of IPR disclosures made to the IETF Secretariat and any 303 assurances of licenses to be made available, or the result of an 304 attempt made to obtain a general license or permission for the use of 305 such proprietary rights by implementers or users of this 306 specification can be obtained from the IETF on-line IPR repository at 307 http://www.ietf.org/ipr. 309 The IETF invites any interested party to bring to its attention any 310 copyrights, patents or patent applications, or other proprietary 311 rights that may cover technology that may be required to implement 312 this standard. Please address the information to the IETF at 313 ietf-ipr@ietf.org. 315 Acknowledgment 317 Funding for the RFC Editor function is provided by the IETF 318 Administrative Support Activity (IASA).