TOC |
|
This document describes a general mechanism whereby a DHCPv6 relay agent can provide options to a DHCPv6 server that the DHCPv6 server can then provide to the DHCPv6 client.
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 26, 2010.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
1.
Introduction
1.1.
Requirements Language
1.2.
Terminology
2.
Protocol Summary
3.
Encoding
4.
DHCP Relay Agent Behavior
5.
DHCP Server Behavior
6.
Security Considerations
7.
References
7.1.
Normative References
7.2.
Informative References
§
Author's Address
TOC |
There are some cases where a DHCP relay agent has information that would be useful to provide to a DHCP client, and the DHCP server does not have that information. The DHCPv6 specification (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [RFC3315] does not provide a mechanism whereby the DHCP relay can provide options to the DHCP client. This document defines an extension to DHCP that allows DHCP relay agents to propose options to be sent to DHCP clients.
The motivation for this draft comes from a proposal from the Mobile IPv6 working group, DHCP Options for Home Information Discovery in MIPv6 (Jang, H., Yegin, A., Chowdhury, K., and J. Choi, “DHCP Options for Home Information Discovery in MIPv6,” May 2008.) [hiopt]. This draft initially proposed a one-off mechanism whereby the relay agent can provide a home agent option to be sent back to the DHCP client. It is our belief that there may be other uses cases for this functionality, so rather than requiring special code in the server for each such use case, we propose to provide a general mechanism that will satisfy any such use case.
TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
TOC |
The following terms and acronyms are used in this document:
- DHCP
- - Dynamic Host Configuration Protocol Version 6 [RFC3315] (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.)
- RSOO
- - Relay-Supplied Options option
TOC |
DHCP clients do not support a mechanism for receiving options from relay agents--the function of the relay agent is simply to deliver the payload from the server. Consequently, in order for the DHCP relay agent to provide options to the client, it sends those options to the DHCP server, encapsulated in a Relay-Supplied Options option. The DHCP server can then choose to place those options in the response it sends to the client.
TOC |
In order to supply options for the DHCP server, the relay agent sends a Relay-Supplied Options option in the Relay-Forward message. This option encapsulates whatever options the relay agent wishes to provide to the DHCPv6 server.
+------+--------+----------+-----+----------+ + code | length | option 1 | ... | option n | +------+--------+----------+-----+----------+
TOC |
Relay agents MAY include a Relay-Supplied Options option in the option payload of a Relay-Forward message. Relay agents MUST NOT modify the contents of any message before forwarding it to the DHCP client.
TOC |
A DHCP server that implements this spec must have a user-configurable setting which determines whether or not it accepts a Relay-Supplied Options option. If the DHCP server is configured not to accept the RSOO, it MUST discard any such options that it receives.
DHCP servers normally construct a list of options that are candidates to send to the DHCP client, and then constructs the DHCP packet according to section 17.2.2 of DHCPv6 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [RFC3315].
If the server receives an RSOO and is configured to accept it, it SHOULD add any options that appear in the RSOO for which it has no internal candidate to the list of options that are candidates to send to the DHCP client. The server SHOULD discard any options that appear in the RSOO for which it already has one or more candidates.
Aside from the addition of options from the RSOO, the DHCP server should then construct a DHCP packet as it normally would, and transmit it to the DHCP client as described in DHCPv6 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [RFC3315].
TOC |
This document provides a mechanism whereby a relay agent can inject options into the response the DHCP server sends to the DHCP client. Because the DHCP server prefers its own configured options to those supplied by the relay agent, this can't be used as a means for overriding server-supplied options. However, it is still possible in some configurations for a rogue DHCP server to supply additional options to the DHCP client.
For this reason, DHCP servers in environments where a rogue relay could interject itself into the packet flow SHOULD authenticate the relay agent as described in section 21.1 of DHCPv6 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [RFC3315].
Note, however, that in any environment where this is possible, it would also possible for the attacker to simply supply a bogus DHCPv6 packet, so unless the packet from the server is authenticated, the same risk exists even in environments where the RSOO is not supported by or enabled on the DHCP server.
TOC |
TOC |
[RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
[RFC3315] | Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” RFC 3315, July 2003 (TXT). |
TOC |
[hiopt] | Jang, H., Yegin, A., Chowdhury, K., and J. Choi, “DHCP Options for Home Information Discovery in MIPv6,” May 2008. |
TOC |
Ted Lemon | |
Nominum | |
2000 Seaport Blvd | |
Redwood City, CA 94063 | |
USA | |
Phone: | +1 650 381 6000 |
Email: | mellon@nominum.com |