idnits 2.17.1 draft-ietf-dhc-dhcpv6-relay-supplied-options-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (September 14, 2010) is 4967 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: 1 error (**), 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 Q. Wu 5 Expires: March 18, 2011 Huawei 6 September 14, 2010 8 Relay-Supplied DHCP Options 9 draft-ietf-dhc-dhcpv6-relay-supplied-options-00 11 Abstract 13 This document describes a general mechanism whereby a DHCPv6 relay 14 agent can provide options to a DHCPv6 server that the DHCPv6 server 15 can then provide to the DHCPv6 client. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 18, 2011. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . . 4 57 5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 4 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 60 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 There are some cases where a DHCP relay agent has information that 66 would be useful to provide to a DHCP client, and the DHCP server does 67 not have that information. The DHCPv6 specification [RFC3315] does 68 not provide a mechanism whereby the DHCP relay can provide options to 69 the DHCP client. This document defines an extension to DHCP that 70 allows DHCP relay agents to propose options to be sent to DHCP 71 clients. 73 The initial motivation for this draft came from a proposal from the 74 Mobile IPv6 working group that proposed a single-use mechanism 75 whereby a particular relay option would be forwarded to the client. 76 Subsequent independent effort in another working group has confirmed 77 the need for a general mechanism to do this. 79 1.1. Requirements Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 1.2. Terminology 87 The following terms and acronyms are used in this document: 89 DHCP - Dynamic Host Configuration Protocol Version 6 [RFC3315] 91 RSOO - Relay-Supplied Options option 93 2. Protocol Summary 95 DHCP clients do not support a mechanism for receiving options from 96 relay agents--the function of the relay agent is simply to deliver 97 the payload from the server. Consequently, in order for the DHCP 98 relay agent to provide options to the client, it sends those options 99 to the DHCP server, encapsulated in a Relay-Supplied Options option. 100 The DHCP server can then choose to place those options in the 101 response it sends to the client. 103 3. Encoding 105 In order to supply options for the DHCP server, the relay agent sends 106 a Relay-Supplied Options option in the Relay-Forward message. This 107 option encapsulates whatever options the relay agent wishes to 108 provide to the DHCPv6 server. 110 +----+----+----+----+--------------+ 111 + TBD | length | suboptions...| 112 +----+----+----+----+--------------+ 114 TBD Relay-Supplied Options code 116 length Length of Relay-Supplied Options option 118 suboptions One or more DHCPv6 options 120 4. DHCP Relay Agent Behavior 122 Relay agents MAY include a Relay-Supplied Options option in the 123 option payload of a Relay-Forward message. Relay agents MUST NOT 124 modify the contents of any message before forwarding it to the DHCP 125 client. 127 5. DHCP Server Behavior 129 A DHCP server that implements this spec must have a user-configurable 130 setting which determines whether or not it accepts a Relay-Supplied 131 Options option. If the DHCP server is configured not to accept the 132 RSOO, it MUST discard any such options that it receives. 134 DHCP servers normally construct a list of options that are candidates 135 to send to the DHCP client, and then constructs the DHCP packet 136 according to section 17.2.2 of DHCPv6 [RFC3315]. 138 If the server receives an RSOO and is configured to accept it, it 139 SHOULD add any options that appear in the RSOO for which it has no 140 internal candidate to the list of options that are candidates to send 141 to the DHCP client. The server SHOULD discard any options that 142 appear in the RSOO for which it already has one or more candidates. 144 Aside from the addition of options from the RSOO, the DHCP server 145 should then construct a DHCP packet as it normally would, and 146 transmit it to the DHCP client as described in DHCPv6 [RFC3315]. 148 DHCP Server implementations MAY discard options deemed inappropriate 149 to forward. For example, it would never be appropriate for the DHCP 150 server to forward an IA option. The list of options that will be 151 discarded SHOULD be configurable by the administrator. 153 6. Security Considerations 155 This document provides a mechanism whereby a relay agent can inject 156 options into the response the DHCP server sends to the DHCP client. 157 Because the DHCP server prefers its own configured options to those 158 supplied by the relay agent, this can't be used as a means for 159 overriding server-supplied options. However, it is still possible in 160 some configurations for a rogue DHCP relay agent to supply additional 161 options to the DHCP client. 163 Because the relay agent is supplying options which the DHCP server 164 might then sign, this provides a mechanism whereby an attacker could 165 get the DHCP server to authenticate a message that the attacker could 166 not itself forge to the client. 168 For this reason, DHCP servers in environments where a rogue relay 169 could interpose itself into the packet flow SHOULD authenticate the 170 relay agent as described in section 21.1 of DHCPv6 [RFC3315]. 172 Note, however, that this attack is only useful if the DHCP server is 173 using the DHCPv6 authentication mechanism; in the absence of DHCPv6 174 authentication, the relay agent could more easily forge a message to 175 the client, rather than using this mechanism to cause the server to 176 produce a message containing forged information. 178 7. IANA Considerations 180 We request that IANA assign one new option code from the registry of 181 DHCP Option Codes maintained at 182 http://www.iana.org/assignments/dhcpv6-parameters. This option code 183 will be assigned to the Relay-Supplied Options option. 185 8. Normative References 187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 188 Requirement Levels", BCP 14, RFC 2119, March 1997. 190 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 191 and M. Carney, "Dynamic Host Configuration Protocol for 192 IPv6 (DHCPv6)", RFC 3315, July 2003. 194 Authors' Addresses 196 Ted Lemon 197 Nominum 198 2000 Seaport Blvd 199 Redwood City, CA 94063 200 USA 202 Phone: +1 650 381 6000 203 Email: mellon@nominum.com 205 Qin Wu 206 Huawei Technologies Co., Ltd. 207 101 Software Avenue, Yuhua District 208 Nanjing, Jiangsu 210012 209 China 211 Email: sunseawq@huawei.com