<?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-lemon-dhcpv6-relay-supplied-options-00"
     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.L." 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>

    <date day="24" month="March" year="2010" />

    <area>Internet</area>

    <workgroup>dhc</workgroup>

    <keyword>DHCPv6 Relay, DHCPv6 option</keyword>

    <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>

  <middle>
    <section title="Introduction">
      <t>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.  <xref target="RFC3315">
      The DHCPv6 specification</xref> 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.</t>

      <t>The motivation for this draft comes from a proposal from
      the Mobile IPv6 working group, <xref target="hiopt">
      DHCP Options for Home Information Discovery in MIPv6</xref>.
      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.</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">
          <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, 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>
+------+--------+----------+-----+----------+
+ code | length | option 1 | ... | option n |
+------+--------+----------+-----+----------+
	</artwork>
      </figure>
    </section>

    <section title="DHCP Relay Agent Behavior">
      <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>
    </section>

    <section title="DHCP Server Behavior">
      <t>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.</t>
      <t>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 <xref target="RFC3315">
      DHCPv6</xref>.</t>
      <t>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.</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>
    </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.   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.</t>
      <t>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 <xref target="RFC3315">
      DHCPv6</xref>.</t>
      <t>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.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;
      &RFC3315;
    </references>

    <references title="Informative References">
      <!--      &hiopt; -->
      <!-- Pull in the reference from the I-D set once Alper issues
           a new version. -->
      
      <reference anchor="hiopt">
        <front>
            <title>DHCP Options for Home Information Discovery in MIPv6</title>
            <author initials="H" surname="Jang" fullname="Heejin Jang">
                <organization>
		  Samsung Advanced Institute of Technology
		</organization>
            </author>
            <author initials="A" surname="Yegin" fullname="Alper Yegin">
                <organization>Samsung Electronics</organization>
            </author>
            <author initials="K"
		    surname="Chowdhury" fullname="Kuntal Chowdhury">
                <organization>Stardent Networks</organization>
            </author>
            <author initials="J"
		    surname="Choi" fullname="JinHyeock Choi">
                <organization>
		  Samsung Advanced Institute of Technology
		</organization>
            </author>
            <date month="May" year="2008" />
        </front>
      </reference>
    </references>
  </back>
</rfc>
