One document matched: draft-ietf-dhc-dhcpv6-relay-supplied-options-00.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-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." 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="14" month="September" 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 initial motivation for this draft came from a proposal
      from the Mobile IPv6 working group that proposed a single-use
      mechanism whereby a particular relay option would be forwarded
      to the client.  Subsequent independent effort in another working
      group has confirmed the need for a general mechanism to do
      this.</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>
+----+----+----+----+--------------+
+   TBD   |  length | suboptions...|
+----+----+----+----+--------------+
	</artwork>
      </figure>
      <t>
	<list style="hanging">
	  <t hangText="TBD">Relay-Supplied Options code</t>
	  <t hangText="length">Length of Relay-Supplied Options option</t>
	  <t hangText="suboptions">One or more DHCPv6 options</t>
	</list>
      </t>
    </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>
      <t>DHCP Server implementations MAY discard options deemed
      inappropriate to forward.  For example, it would never be
      appropriate for the DHCP server to forward an IA option.  The
      list of options that will be discarded SHOULD be configurable by
      the administrator.</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 relay
      agent to supply additional options to the DHCP client.</t>
      <t>Because the relay agent is supplying options which the DHCP server
      might then sign, this provides a mechanism whereby an attacker could
      get the DHCP server to authenticate a message that the attacker could
      not itself forge to the client.</t>
      <t>For this reason, DHCP servers in environments where a rogue
      relay could interpose 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 this attack is only useful if the DHCP
      server is using the DHCPv6 authentication mechanism; in the absence
      of DHCPv6 authentication, the relay agent could more easily forge a
      message to the client, rather than using this mechanism to cause the
      server to produce a message containing forged information.</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>
    </section>
  </middle>

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