idnits 2.17.1 draft-ietf-dhc-dhcpv6-relay-supplied-options-01.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 18, 2010) is 4969 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) -- Obsolete informational reference (is this intentional?): RFC 5296 (Obsoleted by RFC 6696) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 22, 2011 Huawei 6 September 18, 2010 8 Relay-Supplied DHCP Options 9 draft-ietf-dhc-dhcpv6-relay-supplied-options-01 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 22, 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 62 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 The DHCPv6 specification [RFC3315] allows DHCP relay agents to 68 forward DHCPv6 messages between clients and servers that are not on 69 the same IPv6 link. In some cases the DHCP relay agent has 70 information the DHCP server does not have that would be useful to 71 provide to a DHCP client. For example, the DHCP client may need to 72 learn the EAP local domain name [I.D-ietf-hokey-ldn-discovery] for 73 use in EAP re-authentication [RFC5296], which is known to the relay 74 agent but not the server. The DHCPv6 protocol specification does not 75 provide a mechanism whereby the relay agent can provide options to 76 the client. This document extends DHCP with a mechanism that allows 77 DHCP relay agents to propose options for the server to send to DHCP 78 clients. 80 1.1. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 1.2. Terminology 88 The following terms and acronyms are used in this document: 90 DHCP - Dynamic Host Configuration Protocol Version 6 [RFC3315] 92 RSOO - Relay-Supplied Options option 94 2. Protocol Summary 96 DHCP clients do not support a mechanism for receiving options from 97 relay agents--the function of the relay agent is simply to deliver 98 the payload from the server. Consequently, in order for the DHCP 99 relay agent to provide options to the client, it sends those options 100 to the DHCP server, encapsulated in a Relay-Supplied Options option. 101 The DHCP server can then choose to place those options in the 102 response it sends to the client. 104 3. Encoding 106 In order to supply options for the DHCP server, the relay agent sends 107 a Relay-Supplied Options option in the Relay-Forward message. This 108 option encapsulates whatever options the relay agent wishes to 109 provide to the DHCPv6 server. 111 +----+----+----+----+--------------+ 112 + TBD | length | suboptions...| 113 +----+----+----+----+--------------+ 115 TBD Relay-Supplied Options code 117 length Length of Relay-Supplied Options option 119 suboptions One or more DHCPv6 options 121 4. DHCP Relay Agent Behavior 123 Relay agents MAY include a Relay-Supplied Options option in the 124 option payload of a Relay-Forward message. Relay agents MUST NOT 125 modify the contents of any message before forwarding it to the DHCP 126 client. 128 5. DHCP Server Behavior 130 A DHCP server that implements this spec must have a user-configurable 131 setting which determines whether or not it accepts a Relay-Supplied 132 Options option. If the DHCP server is configured not to accept the 133 RSOO, it MUST discard any such options that it receives. 135 DHCP servers normally construct a list of options that are candidates 136 to send to the DHCP client, and then constructs the DHCP packet 137 according to section 17.2.2 of DHCPv6 [RFC3315]. 139 If the server receives an RSOO and is configured to accept it, it 140 SHOULD add any options that appear in the RSOO for which it has no 141 internal candidate to the list of options that are candidates to send 142 to the DHCP client. The server SHOULD discard any options that 143 appear in the RSOO for which it already has one or more candidates. 145 Aside from the addition of options from the RSOO, the DHCP server 146 should then construct a DHCP packet as it normally would, and 147 transmit it to the DHCP client as described in DHCPv6 [RFC3315]. 149 DHCP Server implementations MAY discard options deemed inappropriate 150 to forward. For example, it would never be appropriate for the DHCP 151 server to forward an IA option. The list of options that will be 152 discarded SHOULD be configurable by the administrator. 154 6. Security Considerations 156 This document provides a mechanism whereby a relay agent can inject 157 options into the response the DHCP server sends to the DHCP client. 158 Because the DHCP server prefers its own configured options to those 159 supplied by the relay agent, this can't be used as a means for 160 overriding server-supplied options. However, it is still possible in 161 some configurations for a rogue DHCP relay agent to supply additional 162 options to the DHCP client. 164 Because the relay agent is supplying options which the DHCP server 165 might then sign, this provides a mechanism whereby an attacker could 166 get the DHCP server to authenticate a message that the attacker could 167 not itself forge to the client. 169 For this reason, DHCP servers in environments where a rogue relay 170 could interpose itself into the packet flow SHOULD authenticate the 171 relay agent as described in section 21.1 of DHCPv6 [RFC3315]. 173 Note, however, that this attack is only useful if the DHCP server is 174 using the DHCPv6 authentication mechanism; in the absence of DHCPv6 175 authentication, the relay agent could more easily forge a message to 176 the client, rather than using this mechanism to cause the server to 177 produce a message containing forged information. 179 7. IANA Considerations 181 We request that IANA assign one new option code from the registry of 182 DHCP Option Codes maintained at 183 http://www.iana.org/assignments/dhcpv6-parameters. This option code 184 will be assigned to the Relay-Supplied Options option. 186 8. References 188 8.1. Normative References 190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 191 Requirement Levels", BCP 14, RFC 2119, March 1997. 193 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 194 and M. Carney, "Dynamic Host Configuration Protocol for 195 IPv6 (DHCPv6)", RFC 3315, July 2003. 197 8.2. Informative References 199 [I.D-ietf-hokey-ldn-discovery] 200 Zorn, G., Wu, Q., and Y. Wang, "The Local Domain Name 201 DHCPv6 Option", draft-ietf-hokey-ldn-discovery-05 (work in 202 progress), September 2010. 204 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 205 authentication Protocol (ERP)", RFC 5296, August 2008. 207 Authors' Addresses 209 Ted Lemon 210 Nominum 211 2000 Seaport Blvd 212 Redwood City, CA 94063 213 USA 215 Phone: +1 650 381 6000 216 Email: mellon@nominum.com 218 Qin Wu 219 Huawei Technologies Co., Ltd. 220 101 Software Avenue, Yuhua District 221 Nanjing, Jiangsu 210012 222 China 224 Email: sunseawq@huawei.com