One document matched: draft-ietf-dhc-dhcpv6-relay-supplied-options-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "reference.RFC.2119.xml">
<!ENTITY RFC3315 SYSTEM "reference.RFC.3315.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-dhc-dhcpv6-relay-supplied-options-04"
ipr="trust200902">
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Relay-Supplied DHCP Options">Relay-Supplied DHCP
Options</title>
<author fullname="Ted Lemon" initials="T." surname="Lemon">
<organization>Nominum</organization>
<address>
<postal>
<street>2000 Seaport Blvd</street>
<!-- Reorder these if your country does things differently-->
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>USA</country>
</postal>
<phone>+1 650 381 6000</phone>
<email>mellon@nominum.com</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization abbrev="Huawei">Huawei Technologies Co.,
Ltd.</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</author>
<date day="15" month="October" year="2010" />
<area>Internet</area>
<workgroup>dhc</workgroup>
<keyword>DHCPv6 Relay, DHCPv6 option</keyword>
<abstract>
<t>This document describes a mechanism whereby a DHCPv6 relay
agent can provide options to a DHCPv6 server that the DHCPv6 server can
then provide to the DHCPv6 client in certain restricted cases where
this is necessary.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The DHCPv6 specification <xref target="RFC3315"></xref> allows DHCP
relay agents to forward DHCPv6 messages between clients and servers that
are not on the same IPv6 link. In some cases the DHCP relay agent has
information not available to the DHCP server that would be useful to
provide to a DHCP client. For example, the DHCP client may need to learn
the EAP local domain name <xref
target="I.D-ietf-hokey-ldn-discovery"></xref> for use in EAP
re-authentication <xref target="RFC5296"></xref>, which is known to the
relay agent but not the server.</t>
<t>The DHCPv6 protocol specification does not provide a
mechanism whereby the relay agent can provide options to the
client. This document extends DHCP with a mechanism that allows
DHCP relay agents to propose options for the server to send to
DHCP clients.</t>
<t>This document is not intended to provide a general mechanism for
storing client configuration information in the relay agent. Rather,
it is intended to address specific use cases where only the relay
agent has information needed by the client. This extension is not
applicable to DHCP options in general, but rather provided as a
mechanism for new specifications that require this functionality.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Terminology">
<t>The following terms and acronyms are used in this document: <list
style="hanging" hangIndent="6">
<t hangText="DHCP">Dynamic Host Configuration Protocol Version 6
<xref target="RFC3315"></xref></t>
<t hangText="RSOO">Relay-Supplied Options option</t>
</list></t>
</section>
</section>
<section title="Protocol Summary">
<t>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.</t>
</section>
<section title="Encoding">
<t>In order to supply options for the DHCP server to send to the
client, 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.</t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RSOO | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options...
+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="hanging" hangIndent="16">
<t hangText="OPTION_RSOO">Relay-Supplied Options code (TBD).</t>
<t hangText="option-length">Length of Relay-Supplied Options
option.</t>
<t hangText="options">One or more DHCPv6 options.</t>
</list></t>
</section>
<section title="RSOO-enabled options">
<t>Unless specifically called out as an RSOO-enabled option, no DHCP
option should appear in an RSOO. Specifications that describe
RSOO-enabled options MUST reference this specification, and MUST state
that the option they define is RSOO-enabled. No DHCP option
specified prior to the issuance of this specification is RSOO-enabled.</t>
<t>A current list of RSOO-enabled options can be found in the
list titled "Options Permitted in the Relay-Supplied Options
option" maintained at
http://www.iana.org/assignments/dhcpv6-parameters.</t>
<t>DHCP option specifications that define RSOO-enabled options
MUST add text similar to the following to their IANA
considerations section; "random relay option" should be replaced
with the name of the option being defined in the
specification:
<list>
<t>We request that IANA add the name "random relay option" to
the registry titled "Options Permitted in the Relay-Supplied
Options Option" maintained at
http://www.iana.org/assignments/dhcpv6-parameters.</t></list></t>
</section>
<section title="DHCP Relay Agent Behavior">
<t>DHCP relay agents that implement this specification MUST be
configurable not to send the Relay-Supplied Options option.</t>
<t>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.</t>
<t>Relay agents MUST NOT send non-RSOO-enabled options in the
Relay-Supplied Options option.</t>
<t>Relay agents implementing this specification SHOULD have a
configuration parameter that determines whether or not they will
relay a Relay-Forward message toward the DHCP server if it
contains a Relay-Supplied Options option.</t>
<t>Relay agents that have this configuration parameter and that
are configured to enable this behavior MUST silently discard any
Relay-Forward packet that contains a Relay-Supplied Options
option.</t>
<t>Implementations that can be configured in this way MUST
examine all Relay-Forward encapsulations, not just the outer
encapsulation.</t>
</section>
<section title="DHCP Server Behavior">
<t>DHCP servers that implement this specification MUST examine each
option contained in an RSOO to see if it is an RSOO-enabled option. DHCP
servers MUST silently discard any option contained in an RSOO that is
not RSOO-enabled. DHCP server implementations SHOULD have a
user-configurable list of RSOO-enabled options, so that new RSOO-enabled
options do not require software to be updated.</t>
<t>DHCP servers normally construct a list of options that are candidates
to send to the DHCP client, and then construct the DHCP packet according
to section 17.2.2 of <xref target="RFC3315"> DHCPv6</xref>.</t>
<t>If the server implementing this specificaton receives an
RSOO, 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.</t>
<t>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 <xref
target="RFC3315">DHCPv6</xref>.</t>
<t>DHCP servers may receive multiply-nested Relay-Forward
messages containing conflicting values for options contained in
Relay Supplied Options options in these messages.</t>
<t>When such a conflict exists, the DHCP server MUST choose
no more than one of these options to forward to the client.
The DHCP server MUST NOT forward more than one of these options
to the client.</t>
<t>By default, the DHCP server MUST choose the innermost
value—the value supplied by the relay agent closest to the
DHCP client, to forward to the DHCP client.</t>
<t>DHCP server implementations MAY provide other heuristics for
choosing which one of a set of such conflicting options to
forward to the client, as long as the specified behavior is the
default behavior.</t>
</section>
<section title="Security Considerations">
<t>This document provides a mechanism whereby a relay agent can
inject options into the response the DHCP server sends to the
DHCP client. In general it is expected that RSOO-enabled
options will be specified because they only make sense when
originating from the relay agent. This is true of existing use
cases.</t>
<t>In the event that some new RSOO-enabled option is specified that
can originate from either the server or the relay agent, this should
be addressed in the security considerations section of the document
that specifies the use of that option.</t>
<t>In some environments, there is an interface on one side of which
is the client, and zero or more routers, and on the other side of which
is a network managed by a monolithic or effectively monolithic
administrative entity. Nodes and routers on the client side of
the interface are not controlled by this entity, and are considered
"untrusted." Nodes and routers on the other side of this interface
are considered trusted.</t>
<t>It is possible for a relay agent on the untrusted side of
this interface to supply a Relay-Supplied Options option
containing one or more RSOO-enabled options that would override
the same option or options that were provided by a relay agent
on the trusted side of the interface.</t>
<t>In environments where this is a possibility, network
administrators are advised to use relay agents that are capable
of dropping Relay-Forward messages containing the Relay-Supplied
Options option, and are advised to configure those relays to
drop such messages.</t>
<t>Note, however, that this will only be effective if the
message from the DHCP server to the DHCP client is authenticated
as specified in <xref target="RFC3315">Section 21 of
DHCP Version 6</xref>, or using some similar mechanism. Without this
authentication, the relay agent on the untrusted portion of the
network can simply modify the DHCP server's response in transit
back to the DHCP client, and there is no way for the client to
detect that this has happened.</t>
</section>
<section title="IANA Considerations">
<t>We request that IANA assign one new option code from the registry of
DHCP Option Codes maintained at
http://www.iana.org/assignments/dhcpv6-parameters. This option code will
be assigned to the Relay-Supplied Options option.</t>
<t>We request that the IANA create a new registry on the same
assignments page, titled "Options Permitted in the
Relay-Supplied Options Option". This option will contain a list
of names of options from the DHCP Option Codes list. Currently,
the list is empty.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3315;
</references>
<references title="Informative References">
<reference anchor="I.D-ietf-hokey-ldn-discovery">
<front>
<title>The Local Domain Name DHCPv6 Option</title>
<author fullname="G. Zorn" initials="G." surname="Zorn">
<organization>Network Zen</organization>
</author>
<author fullname="Q. Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
</author>
<author fullname="Y. Wang" initials="Y." surname="Wang">
<organization>Huawei</organization>
</author>
<date day="" month="September" year="2010" />
<abstract>
<t>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.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-hokey-ldn-discovery-05" />
<format target="http://datatracker.ietf.org/doc/draft-ietf-hokey-ldn-discovery/"
type="TXT" />
</reference>
<reference anchor="RFC5296">
<front>
<title>EAP Extensions for EAP Re-authentication Protocol
(ERP)</title>
<author fullname="V. Narayanan" initials="V." surname="Narayanan">
<organization></organization>
</author>
<author fullname="L. Dondeti" initials="L." surname="Dondeti">
<organization></organization>
</author>
<date month="August" year="2008" />
<abstract>
<t>The Extensible Authentication Protocol (EAP) is a generic
framework supporting multiple types of authentication methods. In
systems where EAP is used for authentication, it is desirable to
not repeat the entire EAP exchange with another authenticator.
This document specifies extensions to EAP and the EAP keying
hierarchy to support an EAP method-independent protocol for
efficient re-authentication between the peer and an EAP
re-authentication server through any authenticator. The
re-authentication server may be in the home network or in the
local network to which the peer is connecting. [STANDARDS
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5296" />
<format octets="98264"
target="http://www.rfc-editor.org/rfc/rfc5296.txt" type="TXT" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:22:40 |