idnits 2.17.00 (12 Aug 2021) /tmp/idnits48771/draft-lemon-dhcpv6-relay-supplied-options-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 24, 2010) is 4434 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) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc T. Lemon 3 Internet-Draft Nominum 4 Intended status: Standards Track March 24, 2010 5 Expires: September 25, 2010 7 Relay-Supplied DHCP Options 8 draft-lemon-dhcpv6-relay-supplied-options-00 10 Abstract 12 This document describes a general mechanism whereby a DHCPv6 relay 13 agent can provide options to a DHCPv6 server that the DHCPv6 server 14 can then provide to the DHCPv6 client. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 25, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . . 4 62 5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 4 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 There are some cases where a DHCP relay agent has information that 72 would be useful to provide to a DHCP client, and the DHCP server does 73 not have that information. The DHCPv6 specification [RFC3315] does 74 not provide a mechanism whereby the DHCP relay can provide options to 75 the DHCP client. This document defines an extension to DHCP that 76 allows DHCP relay agents to propose options to be sent to DHCP 77 clients. 79 The motivation for this draft comes from a proposal from the Mobile 80 IPv6 working group, DHCP Options for Home Information Discovery in 81 MIPv6 [hiopt]. This draft initially proposed a one-off mechanism 82 whereby the relay agent can provide a home agent option to be sent 83 back to the DHCP client. It is our belief that there may be other 84 uses cases for this functionality, so rather than requiring special 85 code in the server for each such use case, we propose to provide a 86 general mechanism that will satisfy any such use case. 88 1.1. Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 1.2. Terminology 96 The following terms and acronyms are used in this document: 98 DHCP - Dynamic Host Configuration Protocol Version 6 [RFC3315] 100 RSOO - Relay-Supplied Options option 102 2. Protocol Summary 104 DHCP clients do not support a mechanism for receiving options from 105 relay agents--the function of the relay agent is simply to deliver 106 the payload from the server. Consequently, in order for the DHCP 107 relay agent to provide options to the client, it sends those options 108 to the DHCP server, encapsulated in a Relay-Supplied Options option. 109 The DHCP server can then choose to place those options in the 110 response it sends to the client. 112 3. Encoding 114 In order to supply options for the DHCP server, the relay agent sends 115 a Relay-Supplied Options option in the Relay-Forward message. This 116 option encapsulates whatever options the relay agent wishes to 117 provide to the DHCPv6 server. 119 +------+--------+----------+-----+----------+ 120 + code | length | option 1 | ... | option n | 121 +------+--------+----------+-----+----------+ 123 4. DHCP Relay Agent Behavior 125 Relay agents MAY include a Relay-Supplied Options option in the 126 option payload of a Relay-Forward message. Relay agents MUST NOT 127 modify the contents of any message before forwarding it to the DHCP 128 client. 130 5. DHCP Server Behavior 132 A DHCP server that implements this spec must have a user-configurable 133 setting which determines whether or not it accepts a Relay-Supplied 134 Options option. If the DHCP server is configured not to accept the 135 RSOO, it MUST discard any such options that it receives. 137 DHCP servers normally construct a list of options that are candidates 138 to send to the DHCP client, and then constructs the DHCP packet 139 according to section 17.2.2 of DHCPv6 [RFC3315]. 141 If the server receives an RSOO and is configured to accept it, it 142 SHOULD add any options that appear in the RSOO for which it has no 143 internal candidate to the list of options that are candidates to send 144 to the DHCP client. The server SHOULD discard any options that 145 appear in the RSOO for which it already has one or more candidates. 147 Aside from the addition of options from the RSOO, the DHCP server 148 should then construct a DHCP packet as it normally would, and 149 transmit it to the DHCP client as described in DHCPv6 [RFC3315]. 151 6. Security Considerations 153 This document provides a mechanism whereby a relay agent can inject 154 options into the response the DHCP server sends to the DHCP client. 155 Because the DHCP server prefers its own configured options to those 156 supplied by the relay agent, this can't be used as a means for 157 overriding server-supplied options. However, it is still possible in 158 some configurations for a rogue DHCP server to supply additional 159 options to the DHCP client. 161 For this reason, DHCP servers in environments where a rogue relay 162 could interject itself into the packet flow SHOULD authenticate the 163 relay agent as described in section 21.1 of DHCPv6 [RFC3315]. 165 Note, however, that in any environment where this is possible, it 166 would also possible for the attacker to simply supply a bogus DHCPv6 167 packet, so unless the packet from the server is authenticated, the 168 same risk exists even in environments where the RSOO is not supported 169 by or enabled on the DHCP server. 171 7. References 173 7.1. Normative References 175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 176 Requirement Levels", BCP 14, RFC 2119, March 1997. 178 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 179 and M. Carney, "Dynamic Host Configuration Protocol for 180 IPv6 (DHCPv6)", RFC 3315, July 2003. 182 7.2. Informative References 184 [hiopt] Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP 185 Options for Home Information Discovery in MIPv6", 186 May 2008. 188 Author's Address 190 Ted Lemon 191 Nominum 192 2000 Seaport Blvd 193 Redwood City, CA 94063 194 USA 196 Phone: +1 650 381 6000 197 Email: mellon@nominum.com