<?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 RFC768 SYSTEM "reference.RFC.0768.xml">
<!ENTITY RFC951 SYSTEM "reference.RFC.0951.xml">
<!ENTITY RFC1542 SYSTEM "reference.RFC.1542.xml">
<!ENTITY RFC2119 SYSTEM "reference.RFC.2119.xml">
<!ENTITY RFC2131 SYSTEM "reference.RFC.2131.xml">
<!ENTITY RFC2132 SYSTEM "reference.RFC.2132.xml">
<!ENTITY RFC3011 SYSTEM "reference.RFC.3011.xml">
<!ENTITY RFC3046 SYSTEM "reference.RFC.3046.xml">
<!ENTITY RFC3118 SYSTEM "reference.RFC.3118.xml">
<!ENTITY RFC3315 SYSTEM "reference.RFC.3315.xml">
<!ENTITY RFC3527 SYSTEM "reference.RFC.3527.xml">
<!ENTITY RFC4030 SYSTEM "reference.RFC.4030.xml">
<!ENTITY RFC4302 SYSTEM "reference.RFC.4302.xml">
<!ENTITY I-D.ietf-dhc-relay-id-suboption SYSTEM
  "reference.I-D.draft-ietf-dhc-relay-id-suboption-07.xml">
<!ENTITY I-D.ietf-dhc-l2ra SYSTEM
  "reference.I-D.draft-ietf-dhc-l2ra-04.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-dhcpv4-relay-encapsulation-01"
     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>
      Relay Agent Encapsulation for DHCPv4
    </title>

    <author fullname="Ted Lemon" initials="T.L." surname="Lemon">
      <organization>Nominum, Inc.</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="Hui Deng" initials="H.D." surname="Deng">
      <organization>China Mobile</organization>
      
      <address>
        <postal>
          <street>53A, Xibianmennei Ave.</street>
	  
          <!-- Reorder these if your country does things differently-->
	  
	  
          <region>Xuanwu District</region>
          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>denghui@chinamobile.com</email>
      </address>
    </author>

    <date day="30" month="September" year="2010" />

    <area>Internet</area>

    <workgroup>dhc</workgroup>

    <keyword>DHCPv4 Relay</keyword>

    <abstract>
      <t>This document describes a general mechanism whereby DHCP
      relay agents can encapsulate DHCP packets that they are
      forwarding in the direction of DHCP servers, and decapsulate
      packets that they they are forwarding toward DHCP clients, so
      that more than one relay agent can insert relay agent suboptions
      into the forwarding chain.</t>
    </abstract>
  </front>
  
  <middle>
    <section title="Introduction">
      <t>In some networking environments, it is useful to be able to
      configure relay agents in a hierarchy, so that information from
      a relay agent close to the client can be combined with information
      from one or more relay agents closer to the server, particularly
      in cases where the relay agents may be in separate administrative
      domains.</t>
      <t>The current <xref target="RFC3046">Relay Agent Information
      Option (RAIO) specification</xref> specifies that when a relay agent
      receives a packet containing an RAIO, it must not add an RAIO.
      This prevents chaining of RAIOs, and hence prohibits
      the hierarchical use case.</t>
      <t><xref target="RFC3315">DHCP version 6</xref> provides a much
      cleaner technique for providing RAIO suboptions to the DHCP
      server.  Rather than appending an information option to the
      DHCP client's message, the relay agent encapsulates the DHCP
      client message in a new DHCP message which it sends to the DHCP
      server along with any options it chooses to add to provide
      information to the DHCP server.</t>
      <t>This document specifies a mechanism for providing the same
      functionality in DHCPv4.</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="BOOTREPLY message">Any DHCP or BOOTP message in which
	  the 'op' field is set to BOOTREPLY.</t>
	  <t hangText="BOOTREQUEST message">Any DHCP or BOOTP message in which
	  the 'op' field is set to BOOTREQUEST.</t>
          <t hangText="DHCP">Dynamic Host Configuration Protocol Version 4
	  <xref target="RFC2131"></xref></t>
          <t hangText="decapsulate">the act of de-encapsulating
          DHCP packets being relayed from DHCP servers or relay agents in
	  the direction of DHCP clients, according to this specification.</t>
          <t hangText="encapsulate">the act of encapsulating DHCP
          packets that are being relayed from DHCP clients or relay agents
	  toward DHCP servers, according to the method described
          in this specification.</t>
	  <t hangText="encapsulating relay agent">a relay agent that
	  implements this specification and is configured to encapsulate.</t>
	  <t hangText="L2RA">Layer 2 Relay Agent&mdash;a relay agent that
	  doesn't have an IP address reachable by the DHCP server.</t>
	  <t hangText="L3RA">Layer 3 Relay Agent&mdash;a relay agent
	  that has an IP address reachable by the DHCP server.</t>
	  <t hangText="option buffer">the portion of the DHCP
	  packet following the magic cookie in the 'vend' field of the
	  DHCP Packet.</t>
          <t hangText="RAIO"><xref target="RFC3046">Relay Agent Information
	  Option</xref>.   Also commonly referred to as "Option 82."</t>
          <t hangText="RAIO suboption">a DHCP suboption that has been
	  defined for encapsulation in the Relay Agent Information Option</t>
          <t hangText="relay message">a RELAYFORWARD or RELAYREPLY
	  message.</t>
	  <t hangText="RELAYFORWARD message">Any DHCP or BOOTP message in which
	  the 'op' field is set to RELAYFORWARD.</t>
	  <t hangText="RELAYREPLY message">Any DHCP or BOOTP message in which
	  the 'op' field is set to RELAYREPLY.</t>
	  <t hangText="silently discard">in many places in this
	  specification, the implementation is required to silently
	  discard erroneous messages.  What is meant by 'silently
	  discard' is that the implementation MUST NOT send any ICMP
	  message indicating that the delivery was in error.  It may
	  be desirable for the implementation to keep a count of
	  messages that have been discarded, either by message type or
	  by reason for discarding, or some combination.  Nothing in
	  this specification should be construed to forbid such data
	  collection.</t></list></t>
      </section>
    </section>
    
    <section title="Protocol Summary">
      <t>This document specifies two new BOOTP message types: the RELAYFORWARD
      message, and the RELAYREPLY message.   These messages are analogous
      to the Relay Forward and Relay Reply messages in <xref target="RFC3315">
      DHCPv6</xref>.</t>
      <t>Although this specification is generally aimed at DHCP implementations,
      it is not specifically restricted to DHCP, and is applicable to BOOTP
      in cases where the BOOTP server is a DHCP server that implements this
      specification, or the less likely case that the BOOTP server only
      supports the BOOTP protocol, but still implements this specification.</t>
      <t>In general, when the term "DHCP" appears in this specification,
      the reader should not read this as intending to exclude BOOTP.</t>
      <section title="RELAYFORWARD Message">
	<t>Conforming relay agents encapsulate messages being sent toward
	DHCP servers in RELAYFORWARD messages.</t>
      </section>
      <section title="RELAYREPLY Message">
	<t>A conforming DHCP server encapsulates any message being sent toward
	a DHCP client in a RELAYREPLY message, if the message being responded
	to was encapsulated.</t>
	<t>A conforming relay agent, when it receives a RELAYREPLY message,
	decapsulates the message contained in the RELAYREPLY message and
	sends it to the next relay or to the client.</t>
      </section>	
      <section title="Layer Two Address suboption">
	<t>In cases where the closest relay agent to the client is an L2RA,
	but where there is an L3RA on the path to the client, the DHCP server
	will encode the link layer address that would normally go in the
	chaddr field of the DHCP packet into a Layer Two Address suboption.</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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | SUBOPT_L2AS |    length     |     htype     |    chaddr ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	</artwork>
      </figure>
	
      <t>
	The Layer Two Address suboption has four fields:
	<list style="hanging">
	  <t hangText="SUBOPT_L2AS">One octet: the suboption code for the Layer
	  Two Address suboption (TBD).</t>

	  <t hangText="length">One octet: the length of the Layer Two
	  Address suboption.</t>

	  <t hangText="htype">One octet: the type of the Layer Two
	  Address suboption&mdash;corresponds to the 'htype' field in
	  a non-relay DHCP or BOOTP message.</t>

	  <t hangText="chaddr">One or more octets: the layer two address
	  of the client, from the 'chaddr' field of the DHCP or BOOTP
	  message.</t>
	</list>
      </t>
      </section>
    </section>

    <section title="Encoding">
      <t>RELAYFORWARD and RELAYREPLY messages are distinguished
      through the use of the 'op' field of the DHCP packet.</t>
      <t>In non-relay DHCP packets, the 'op' field either contains
      BOOTREQUEST, for any DHCP message from the client to the server,
      or BOOTREPLY, for any DHCP message from the server to the
      client.</t>
      <t>This document defines two additional codes, RELAYFORWARD and
      RELAYREPLY.  Conforming DHCP servers and DHCP relay agents MUST
      support these two new values for the 'op' field.   DHCP clients
      should never see either value.</t>
      <texttable title="Values for the 'op' field">
	<ttcol align="left">code</ttcol>
	<ttcol align="left">meaning</ttcol>
	<c>1</c>
	<c>BOOTREQUEST</c>
	<c>2</c>
	<c>BOOTREPLY</c>
	<c>3</c>
	<c>RELAYFORWARD</c>
	<c>4</c>
	<c>RELAYREPLY</c>
      </texttable>
	  
      <t>RELAYFORWARD and RELAYREPLY messages share only the 'op'
      field in common with other DHCP and BOOTP messages.  The
      remainder of the message consists of a series of fixed-length
      fields followed by two variable-length fields: the relay
      segment, and the encapsulated message.</t>
      <figure>
	<artwork>
+-----+-----+-----+-----+
|  op |  ep |   padlen  |
+-----+-----+-----+-----+
|   rslen   |   caplen  |
+-----+-----+-----+-----+
|        aiaddr         |
+-----+-----+-----+-----+
.                       .
.     relay segment     .
.                       .
+-----------------------+
.                       .
.  encapsulated message .
.                       .
+-----------------------+
	</artwork>
      </figure>
      <section title="The fixed-length header">
	<t>The fixed-length header of the relay message contains a
	series of fields that perform two purposes: to provide enough
	information that the DHCP server can reconstruct the original
	packet sent by the DHCP client, and to establish the lengths
	of the two variable-length segments.</t>

	<t>To satisfy the first of these requirements, two fields in
	the fixed-length header report the amount of padding stripped
	from the client message, if any, and whether or not an end
	option was stripped from the client message.  Except for a
	relay message that immediately encapsulates a message from a
	DHCP client, these fields are always zero.  Using these two
	fields, the DHCP server can reconstruct the client packet
	exactly, and this allows the DHCP server to validate any <xref
	target="RFC3118">signature</xref> that may be present.</t>

	<t>
	  The fixed-length header consists of five fields:

	  <list style="hanging">
	    <t hangText="op">The BOOTP 'op' field, which, for a relay message,
	    MUST contain the RELAYFORWARD or RELAYREPLY code.</t>
	    <t hangText="ep">If an End option was present in the option
	    buffer prior to encapsulation, this field is set to 1;
	    otherwise, it is set to 0.  This field is a single byte.</t>
	    <t hangText="padlen">The length of any padding that was
	    removed from the option buffer prior to encapsulation: two
	    bytes in network byte order.</t>
	    <t hangText="rslen">The length of the relay
	    segment: two byte in network byte order.</t>
	    <t hangText="caplen">The length of the encapsulation
	    segment: two byte in network byte order.</t>
	    <t hangText="aiaddr">Relay agent IP address.</t>
	  </list>
	</t>
      </section>
      <section title="Relay Segment">
	<t>The relay segment contains any RAIO suboptions that the
	encapsulating agent (the relay agent or the DHCP server)
	wishes to send.  End and Pad options MUST NOT appear
	within the relay segment.</t>
      </section>
      <section title="Encapsulation Segment">
	<t>
	  The encapsulation segment contains the entire DHCP message
	  being encapsulated, with four exceptions:
	  <list style="symbols">
	    <t>The encapsulating agent MUST omit the IP and UDP
	    headers, as well as any layer two header, from the
	    encapsulated message.</t>
	    <t>The encapsulating agent MUST omit any options following
	    the first End option in the option buffer.  These options
	    are assumed to be garbage, and <xref target="RFC3118">are
	    not covered by any signature</xref>.</t>
	    <t>The encapsulating MUST omit any Pad options present
	    either at the end of the option buffer, or prior to the
	    first End packet, that are followed only by other Pad
	    options or a single End option.  The encapsulating agent
	    MUST record number of Pad options that were omitted in
	    the 'padlen' field of the message header.</t>
	    <t>The encapsulating agent MUST omit the End option, if
	    present.  The encapsulating agent MUST set the 'ep' field
	    in the message header to 1 if an End option was present in
	    the option buffer, and to zero if no End option was
	    present.</t>
	  </list>
	</t>
	<t>These exceptions apply only to the option buffer.  The
	encapsulating agent MUST NOT modify the contents of the 'file'
	and 'sname' fields.  The encapsulating agent MUST NOT count
	End or Pad options that appear in these fields.</t>
      </section>
    </section>

    <section title="DHCP Relay Agent Behavior">
      <t>DHCP Relay agents implementing this specification MUST have a
      configuration parameter controlling relay encapsulation.  By
      default, relay encapsulation MUST be disabled.</t>

      <t>Relay agents with encapsulation disabled MUST NOT
      encapsulate.  Relay agents with encapsulation disabled MUST NOT
      decapsulate.</t>

      <t>In any case where a relay agent implementing this specification
      does not encapsulate or decapsulate, it MUST behave exactly as
      a relay agent would that did not implement this specification at
      all.</t>

      <t>DHCP relay agents that are configured with encapsulation
      enabled, but which have no agent-specific options to send to the
      DHCP server, MUST encapsulate.  Relay agents that are configured
      with encapsulation enabled MUST decapsulate.</t>

      <t>Layer two relay agents MUST silently discard any messages
      that contains an <xref target="RFC4302">IPsec authentication
      header</xref>.  This is because they cannot modify such packets,
      but also cannot detect that a message from the DHCP server is in
      response such a message, since it might not contain an IPsec
      authentication header.</t>

      <section title="Packet processing">
	<t>Relay agents implementing this specification may receive
	packets directed toward DHCP servers with a source port of 67
	(BOOTPS).  Therefore, the source port cannot be used to
	determine whether the packet is traveling toward a DHCP server
	or toward a DHCP client.</t>

	<t>In order to determine whether a message is traveling toward
	a DHCP client or toward a DHCP server, the relay agent must
	check the 'op' field of the DHCP message.  If the 'op' field
	is set to BOOTREQUEST or RELAYFORWARD, the message is
	traveling toward a DHCP server.  If the 'op' field is set to
	BOOTREPLY or RELAYREPLY, the message is traveling toward a
	DHCP client.  At the time of the writing of this
	specification, no other value is meaningful in the 'op'
	field.</t>

	<t>Relay agents implementing this specification MUST NOT
	encapsulate or decapsulate messages with other values in the
	'op' field.  It is assumed that if meanings are defined for
	additional values, the document that specifies the meaning of
	those values will update this document; in the absence of such
	an update, the behavior specified here will remain in effect.</t>

	<t>Relay agents implementing this specification MAY
	differentiate between DHCP and BOOTP messages.  Under normal
	circumstances, BOOTP and DHCP messages are forwarded to the
	same server, which should be able to successfully decapsulate
	both DHCP and BOOTP messages.  However, some relay agents may
	send BOOTP and DHCP packets to different servers; this
	document should not be construed to require that such a relay
	agent should encapsulate all messages regardless of
	protocol.</t>

	<section title="Packets traveling toward DHCP servers">
	  <t>Any DHCP or BOOTP packet with an 'op' value of
	  BOOTREQUEST or RELAYFORWARD is traveling toward a DHCP server.
	  When a DHCP relay agent that is configured to encapsulate
	  receives such a packet, the relay agent MUST encapsulate that
	  packet into a RELAYFORWARD message and send it to the
	  address or addresses with which it is configured to forward
	  messages intended for DHCP servers.</t>
	</section>
	<section title="Packets traveling toward DHCP clients">
	  <t>Any DHCP or BOOTP packet with an 'op' value of BOOTREPLY
	  or RELAYREPLY is traveling toward a DHCP client.  When a
	  DHCP relay agent that is configured to encapsulate recieves
	  a RELAYREPLY message that is traveling toward a DHCP or
	  BOOTP client, the relay agent MUST decapsulate that message
	  and forward the decapsulated message toward the client.</t>
	</section>
	<section title="Anti-spoofing">
	  <t>Because this specification allows for chaining of relay
	  agent-supplied information, it is now possible for a relay
	  agent outside of the trusted portion of a network to
	  communicate relay agent information to the DHCP server
	  without preventing the legitimate relay from communicating
	  return path information to the DHCP server, as is the case
	  with RFC3046.</t>
	  <t>In order to prevent this sort of spoofing, relay agents
	  implementing this specification MUST be configurable to
	  discard all RELAYFORWARD messages that they receive.
	  Administrators relying on a trusted network architecture to
	  control the flow of information to the DHCP server SHOULD
	  configure relay agents on the edge of their networks to
	  discard RELAYFORWARD messages.</t>
	</section>
      </section>
      <section title="Constructing RELAYFORWARD messages">
	<section title="Initializing the fixed-length header">
	  <t>The relay agent constructs the RELAYFORWARD message by
	  constructing the fixed-length header as specified in the
	  earlier section titled 'Encoding'.  The relay agent
	  MUST set the 'op' field to a value of RELAYFORWARD.</t>

	  <t>If the relay agent is not a <xref
	  target="I-D.ietf-dhc-l2ra">layer two relay agent</xref>, it
	  MUST store one of its own IP addresses in the 'aiaddr' field.
	  This address MUST be a valid IP address that is reachable by
	  the next hop relay(s) or DHCP server(s) to which the relay
	  agent is configured to forward.</t>

	  <t>DHCP servers normally use the relay agent IP address to
	  determine on what link the DHCP client's IP address should
	  be allocated.  In some cases, the value stored in the
	  'aiaddr' field will not be a valid IP address on the link on
	  which the source message was received.  In this case, the
	  relay agent MUST include a <xref target="RFC3527">link
	  selection suboption</xref> that identifies that link in the
	  relay segment.</t>

	  <t>If the relay agent is a layer two relay agent, it MAY
	  include a link selection suboption in the relay segment.</t>

	  <t>If the message being encapsulated is a BOOTREQUEST, L2RAs
	  MUST store a value of zero in the 'aiaddr' field.  Otherwise,
	  the L2RA MUST copy the value of the 'aiaddr' field in the
	  RELAYFORWARD message being encapsulated into the 'aiaddr' field
	  of the RELAYFORWARD message that it generates.</t>

	  <t>The 'rslen' field depends on the length of the relay
	  segment.  The 'caplen', 'padlen' and 'ep' values in the
	  fixed header are initialized differently depending on
	  whether the message being encapsulated is a BOOTREQUEST or a
	  RELAYFORWARD message.</t>
	</section>
	<section title="Initializing the relay segment">
	  <t>Following the fixed header, the relay agent MUST append any
	  RAIO suboptions it wishes to send to the DHCP server; this is
	  the 'relay segment'.  It MUST store the length of the relay
	  segment in the 'rslen' field of the fixed header.</t>

	  <t>The relay agent SHOULD include a <xref
	  target="I-D.ietf-dhc-relay-id-suboption">Relay Agent ID
	  suboption</xref> in the relay segment to identify itself to
	  the DHCP server.</t>
	</section>

	<section title="Fixed header settings for RELAYFORWARD messages">
	  <t>If the message being encapsulated is a RELAYFORWARD
	  message, the relay agent MUST initialize the 'caplen' field
	  of the fixed header to the length of the source message,
	  excluding any layer 2, IP and UDP headers.  It MUST append
	  the contents of the message, again excluding any layer 2, IP
	  or UDP headers, to the new message.  It MUST initialize the
	  'ep' and 'padlen' fields in the fixed header of the new
	  message to zero.</t>
	</section>

	<section title="Fixed header settings for BOOTREQUEST messages">
	  <t>If the message being encapsulated is a BOOTREQUEST
	  message, the relay agent determines the length of the
	  encapsulation segment by scanning forward across the option
	  buffer of the source message, beginning with the first
	  option in the option buffer, until an End option is reached,
	  or the end of the buffer is reached.  The difference between
	  the offset of this location in the message and the offset of
	  the first location following the UDP header of the message
	  is the length of the message to be relayed.</t>

	  <t>If an End option terminated the scan, the relay agent
	  MUST set the value of the 'ep' field in the fixed header to
	  one.  Otherwise, the relay agent MUST set the value of the
	  'ep' field to zero.</t>

	  <t>The relay agent MUST count all of the Pad options that
	  follow the last option in the option buffer that is neither
	  a Pad nor an End option.   The relay agent MUST store this
	  count in the 'padlen' field of the fixed header.</t>

	  <t>The relay agent MUST store the difference between the
	  value stored in 'padlen' and the length of the message to
	  be relayed in the 'caplen' field of the fixed header.</t>
	</section>

	<section title="Initializing the encapsulation segment">
	  <t>The relay agent MUST copy the portion of the message
	  being encapsulated that immediately follows the UDP header
	  into the RELAYFORWARD message being generated.   The
	  length of the data being copied is the value that was stored
	  in 'caplen'.</t>
	</section>
      </section>

      <section title="Decapsulating RELAYREPLY messages">
	<t>To decapsulate a RELAYREPLY message, the relay agent
	creates a decapsulated message, processes any RAIO suboptions
	it recognizes in the relay segment, and forwards the
	decapsulated message to its destination.</t>

	<section title="Processing relay agent suboptions">
	  <t>The suboptions parsed from the relay segment are
	  processed by the relay agent as specified in <xref
	  target="RFC3046">the Relay Agent Information Option
	  specification</xref>, as well as in any documents that
	  define suboptions to the Relay Agent Information Option.  A
	  current list of DHCP Relay Agent suboptions and the
	  documents that define them can be located in the IANA
	  protocol registry for Bootp and DHCP parameters, in the
	  section titled "DHCP Relay Agent Sub-Option Codes."</t>
	</section>

	<section title="Constructing the decapsulated message">
	  <t>To construct a decapsulated message, the relay agent copies
	  the portion of the RELAYREPLY message following the relay
	  segment, with a length specified in the 'caplen' field of the
	  fixed-length header, into the new message.</t>
	</section>
      </section>

      <section title="Retransmitting modified messages">
	<t>If the relay agent did not modify the message either by
	encapsulating or decapsulating it, it retransmits the message
	according to existing practice.</t>

	<t>Otherwise, how the modified message is transmitted to its
	next destination depends on two factors.  First, is the relay
	agent that modified the message a <xref
	target="I-D.ietf-dhc-l2ra">layer two</xref> relay agent or a
	<xref target="RFC1542">layer three</xref> relay agent?
	Second, is the modified message a BOOTREPLY message, a
	RELAYREPLY message, or some other message?</t>

	<section title="Layer two relay agents">
	  <t>There are two special aspects to the handling of relayed
	  packets in Layer Two Relay Agents (L2RAs).   The first is
	  the construction of the layer two, IP and UDP headers
	  on the packet.   The second is how the L2RA makes the
	  forwarding decision.</t>
	  <section title="Constructing the headers">
	    <t>The L2RA constructs the headers on the relayed packet
	    by copying and, as necessary, modifying the headers from
	    the original packet.</t>
	    <t>If there is a layer two header, the L2RA MUST copy this
	    header in accordance with the needs of the particular
	    layer two implementation it is using.  If the header
	    contains a packet length field, the L2RA MUST adjust the
	    value in the packet length field.  If the header contains
	    a non-secure integrity check such as a CRC or checksum
	    that covers the entire packet, the L2RA MUST recompute this
	    value.</t>
	    <t>L2RA encapsulation in cases where the layer two
	    contains a secure integrity check must either construct
	    a new integrity signature, or else remove the integrity
	    signature.  If neither of these is possible, the L2RA
	    MUST silently discard the packet.</t>
	    <t>The L2RA MUST copy the IP header without modification.
	    If the IP header contains any sort of secure integrity
	    check on the packet, the L2RA MUST silently discard the
	    packet.</t>
	    <t>The L2RA MUST copy the UDP header and adjust the
	    <xref target="RFC0768">'Length' field</xref>.  If the 
	    contents of the 'Checksum' field are not zero, the
	    L2RA MUST compute a new checksum according to the
	    algorithm specified in <xref target="RFC0768">User
	    Datagram Protocol.</xref></t>
	  </section>
	  <section title="Forwarding the modified packet">
	    <t>Ordinarily when a layer two device forwards a packet,
	    it simply copies that packet from the interface on which
	    it was received and transmits it, unchanged, on one or
	    more interfaces other than that interface.  The mechanism
	    used to choose which interfaces it forwards the packet to
	    is beyond the scope of this document.</t>
	    
	    <t>Once a DHCP packet has been modified by the L2RA either
	    as an encapsulation or a decapsulation, the L2RA must
	    forward it either toward the DHCP server or the DHCP client.
	    The implementation has two options: transmit the packet
	    as it would transmit any other packet, or use its
	    configuration and/or information in the relay header
	    to direct the packet out a particular interface.</t>
	    
	    <t>The details of ordinary packet forwarding in devices
	    that implement L2RA is beyond the scope of this
	    document.</t>
	    
	    <t>When processing a RELAYREPLY message, the L2RA MAY
	    use information in the relay segment of the RELAYREPLY
	    to determine on which network interface the RELAYREPLY
	    should be forwarded.</t>
	    
	    <t>When processing any other message, the L2RA MAY use
	    configuration information to direct the packet out a
	    specific port or ports that have been marked as reaching
	    DHCP servers.   The L2RA MUST NOT forward any packet
	    on the interface on which it was received, even if that
	    interface is so marked.</t>
	  </section>
	</section>
      </section>

      <section title="Layer Three Relay Agents">
	<section title="Transmitting a decapsulated RELAYREPLY message">
	  <t>When the decapsulated message is itself a RELAYREPLY
	  message, the relay agent MUST forward the decapsulated
	  message to the IP address specified in the 'aiaddr' field of
	  the fixed-length header.</t>
	  <t>If the relay segment of the packet that was decapsulated
	  contains a Link Layer Address suboption, the relay agent
	  MUST transmit the packet to that link layer address without
	  attempting to use Address Resolution Protocol (ARP) to
	  translate the address contained in 'aiaddr' to a layer two
	  address.</t>
	</section>
	<section title="Transmitting a decapsulated BOOTREPLY message">
	  <t>When transmitting a decapsulated BOOTREPLY message, the
	  relay agent transmits the message as specified in <xref
	  target="RFC0951">Bootstrap Protocol, Section 4</xref>.</t>
	</section>
	<section title="Transmitting other messages">
	  <t>When transmitting RELAYFORWARD and BOOTREQUEST messages,
	  the relay agent simply sends the message to the IP address
	  or addresses configured as DHCP servers for that relay agent.</t>
	</section>
      </section>
    </section>

    <section title="DHCP Server Behavior">
      <t>A DHCP server which receives a RELAYREPLY message MUST
      silently discard that message.</t>
      <section title="Receiving RELAYFORWARD messages">
	<t>DHCP servers that implement this specification MUST decapsulate
	RELAYFORWARD messages.</t>
	<section title="Decapsulation">
	  <t>By design, this specification supports multiple layers of
	  encapsulation.  The DHCP server implementation therefore
	  MUST decapsulate each layer and retain the information in
	  that layer, organized so that the ordering of the
	  encapsulation is available both during packet processing,
	  and when constructing the reply.</t>
	  <t>Aside from the necessity of handling an RAIO differently
	  than an encapsulation when constructing a RELAYREPLY
	  message, DHCP servers MUST NOT, by default, treat relay
	  suboptions received in an RAIO any differently than relay
	  suboptions received in an encapsulation.</t>
	  <t>It is not the goal of this specification to define a
	  particular implementation strategy or data structure for
	  representing the encapsulation, so long as the ability to
	  process the options and suboptions as required below is
	  preserved.  Implementations MAY provide means for addressing
	  the contents of relay segments and of the inner
	  encapsulation segment in any convenient form, as long as it
	  conforms generally to the requirements of this document.</t>
	</section>
	<section title="Processing of decapsulated suboptions">
	  <t>This section specifies requirements for the processing of
	  decapsulated relay suboptions in the default case, where no
	  custom processing has been specified.  This should not be
	  construed to forbid implementations for providing mechanisms
	  for customizing the processing of these suboptions.</t>
	  <t>This document does not specify special handling for DHCP
	  options.  Only the inner encapsulation&mdash;the
	  encapsulation of the original message sent from the client,
	  which is done by the first encapsulating relay&mdash;can
	  ever contain DHCP Options; hence, whatever normal mechanisms
	  a DHCP server provides for processing these options should
	  suffice.</t>
	  <t>Some relay agent suboptions, such as the <xref
	  target="RFC3527">Relay Agent Subnet Selection
	  suboption</xref>, are intended to be processed by DHCP
	  servers.  Others, like the <xref target="RFC3046">Circuit ID
	  and Remote ID</xref> suboptions, were not intended to be
	  processed by the DHCP server, but are often used by the DHCP
	  server for identification purposes.</t>
	  <t>In cases where more than one relay agent sends the same
	  suboption, the DHCP server must either factor all such
	  suboptions into its processing, or choose one such suboption
	  and use that exclusively for processing.</t>
	  <t>By default, DHCP servers MUST use the outermost suboption
	  (the one added by the relay agent closest to the DHCP
	  server) for every suboption that was sent by more than one
	  relay agent.</t>
	</section>
	<section title="Address allocation">
	  <t>During normal processing, DHCP servers use a variety of
	  data to determine where the DHCP client is in the network
	  topology.  These data are provided by relay agents.  In the
	  absence of any relay-agent-provided topology data, the DHCP
	  server assumes that the client is connected to the link
	  on which the message was received.</t>

	  <t>One datum used by DHCP servers in locating the client is
	  the value of the 'giaddr' field of the BOOTP header.   This
	  specification eliminates the use of giaddr; hence, it cannot
	  be used in the address allocation decision.</t>

	  <t>The functionality provided by giaddr is replaced in
	  this specification by the 'aiaddr' field in the fixed-length
	  relay header.</t>

	  <section title="Default link selection algorithm">
	    <t>DHCP servers MUST implement a default algorithm for
	    determining the link to which the client is attached.
	    This algorithm is to first search the client message for a
	    <xref target="RFC3011">subnet selection option</xref>.</t>

	    <t>The server next searches for link-identifying data in
	    each RELAYFORWARD encapsulation, starting from the inner
	    most and ending at the outermost, until a RELAYFORWARD is
	    found that identifies the client's location.</t>

	    <t>A RELAYFORWARD encapsulation contains link-identifying
	    data if the value of the 'aiaddr' field of the
	    fixed-length header is not zero, or if the relay segment
	    contains a <xref target="RFC3527">Link Selection
	    suboption</xref>.</t>

	    <t>If a Link Selection suboption is present in the innermost
	    RELAYFORWARD message containing link-identifying
	    data, the DHCP server MUST use the contents of that
	    option to identify the link to which the client is
	    connected.</t>
	    
	    <t>Otherwise, if a Subnet Selection option was found in the
	    client message, the DHCP server MUST use the contents of that
	    option to identify the link to which the client is connected.</t>
	    
	    <t>Otherwise, the DHCP server MUST use the contents of the
	    'aiaddr' field in the RELAYFORWARD encapsulation that was
	    identified as being the innermost RELAYFORWARD containing
	    link-identifying data.</t>
	  </section>
	  <section title="Other link selection algorithms">
	    <t>DHCP servers implementing this specification MAY implement
	    link selection algorithms other than the one described in
	    the preceding section.   DHCP servers MUST NOT use any
	    link selection algorithm other than the one described in
	    the preceding section unless specially configured to do so.</t>
	  </section>
	</section>
      </section>
      <section title="Responding to RELAYFORWARD messages">
	<t>Once the DHCP server has processed the encapsulated message
	from the DHCP client and constructed a response to the DHCP
	client, it constructs a RELAYREPLY message and sends it to the
	next hop on the way to the client.</t>
	<section title="Constructing a RELAYREPLY encapsulation">
	  <t>The server MUST encapsulate any response to a client message
	  contained in one or more RELAYFORWARD encapsulations in a
	  set of corresponding RELAYREPLY encapsulations.   Each RELAYREPLY
	  is nested in the same way that the corresponding RELAYFORWARD was
	  nested, so that the innermost RELAYREPLY corresponds to the
	  innermost RELAYFORWARD, and the outermost RELAYREPLY corresponds
	  to the outermost RELAYFORWARD.</t>
	  <section title="Constructing the relay segments">
	    <t>The server MUST copy every suboption that appeared in
	    the relay segment of the RELAYFORWARD encapsulation into
	    corresponding outgoing RELAYREPLY encapsulation's relay
	    segment.  The server SHOULD NOT preserve the order of
	    options from the incoming relay segment to the outgoing
	    relay segment.</t>
	    <t>If the message encapsulated by a particular RELAYREPLY
	    encapsulation is not a RELAYREPLY, or if the message
	    encapsulated by that RELAYREPLY is a RELAYREPLY, but the
	    'aiaddr' field of the fixed-length header of the inner
	    RELAYREPLY has a value of zero, the DHCP server MUST
	    include a Layer Two Address suboption in the relay
	    segment.  The DHCP server MUST set the 'htype' field of
	    the Layer Two Address suboption to the value of 'htype' in
	    the client message.  The DHCP server MUST set the 'chaddr'
	    field in the Layer Two Address suboption to the value of
	    the 'chaddr' field in the client message.</t>
	  </section>
	  <section title="Constructing the fixed-length header">
	    <t>The server MUST set the values of 'ep' and 'padlen' in
	    the fixed-length header to zero.  The server MUST set the
	    value of 'caplen' to the length of the message
	    encapsulated in the RELAYREPLY encapsulation being
	    constructed.  The server MUST set the value of 'rslen' to
	    the length of the relay segment of the RELAYREPLY
	    encapsulation being constructed.</t>
	    <t>If the message encapsulated in the RELAYREPLY being
	    constructed is a RELAYREPLY, and the 'aiaddr' field of
	    the RELAYFORWARD encapsulation corresponding to the inner
	    RELAYREPLY is not zero, the DHCP server MUST copy the
	    value from that 'aiaddr' field to the 'aiaddr' field
	    of the RELAYREPLY being constructed.</t>
	    <t>Otherwise, if the BROADCAST bit in the 'flags' field of
	    the inner message is set to 1, or 'ciaddr' is zero and
	    'yiaddr' is also zero, the DHCP server MUST set the value
	    of 'aiaddr' to 255.255.255.255.  If 'ciaddr' is not zero,
	    the DHCP server must copy that value to 'aiaddr'.  If
	    'ciaddr' is zero and 'yiaddr' is not, the DHCP server MUST
	    copy the value of 'yiaddr' to 'aiaddr'.</t>
	  </section>
	</section>
	<section title="Transmission of RELAYREPLY messages">
	  <t>If the value of 'aiaddr' in the outermost RELAYFORWARD
	  encapsulation to which the RELAYREPLY is a response is nonzero,
	  the DHCP server MUST transmit the RELAYREPLY to that IP address.</t>

	  <t>Otherwise, if 'ciaddr' and 'yiaddr' are both zero, or the
	  BROADCAST bit in the 'flags' field is set to 1, or the DHCP
	  server implementation is not able to perform the ARP-cache
	  preloading trick described in <xref
	  target="RFC0951">Bootstrap Protocol, Section 4</xref>, the
	  DHCP server MUST broadcast the RELAYREPLY message to the
	  255.255.255.255 broadcast address.</t>

	  <t>Otherwise, the DHCP server MUST use the value of
	  'ciaddr', if nonzero, or 'yiaddr', otherwise, as the
	  destination address for the message, and MUST preload its
	  ARP cache (or otherwise arrange to transmit the message
	  without using ARP) to the layer two address provided by the
	  client in 'htype' and 'chaddr' and 'hlen'.</t>
	</section>
      </section>
      <section title="Responding to messages other than RELAYFORWARD">
	<t>When a DHCP server constructs a response to a DHCP client
	message that did not arrive encapsulated in a RELAYFORWARD
	message, the DHCP server MUST NOT encapsulate the response in
	a RELAYREPLY message.  DHCP server implementors should be
	careful that their servers do not respond to an incoming RAIO
	from a non-conforming relay agent with a RELAYREPLY
	message.</t>
      </section>
    </section>

    <section title="DHCP Client Behavior">
      <t>A DHCP client that receives either a RELAYFORWARD message or
      a RELAYREPLY message MUST silently discard that message.</t>
    </section>

    <section title="Security Considerations">
      <t><xref target="RFC3046">DHCP Relay Information Option</xref>
      limits relay agent information to a single relay agent, and
      provides some minimal anti-spoofing.  By supporting relay agent
      chaining, it is now possible for a relay agent downstream of the
      trusted portion of a provider network to communicate relay agent
      information options to a DHCP server.</t>
      <t>This specification defines a much more robust spoofing
      rejection mechanism, by allowing the administrator to configure
      the relay to discard RELAYFORWARD messages originating from
      outside of the trusted portion of the network.  Administrators
      of networks that rely on this trusted/untrusted configuration are
      encouraged to configure edge relays to discard RELAYFORWARD
      messages.</t>
      <t>In networks where trusted relay agents may be separated from
      the DHCP server by transit networks that are not trusted, it is
      possible to modify the message in transit.  This possibility
      exists with normal DHCP relays as well.  Administrators of such
      networks should consider using <xref target="RFC4030">relay
      agent authentication</xref> to prevent modification of relay
      agent communications in transit.</t>
    </section>

    <section title="IANA Considerations">
      <t>We request that IANA assign one new suboption code from
      the registry of DHCP Agent Sub-Option Codes maintained in
      http://www.iana.org/assignments/bootp-dhcp-parameters.  This
      suboption code will be assigned to the Layer Two Address Suboption.
      </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC768;
      &RFC951;
      &RFC1542;
      &RFC2119;
      &RFC2131;
      &RFC3011;
      &RFC3046;
      &RFC3118;
      &RFC3527;
      &RFC4030;
      &RFC4302;
      &I-D.ietf-dhc-relay-id-suboption;
    </references>

    <references title="Informative References">
      &RFC3315;
      &I-D.ietf-dhc-l2ra;
    </references>
  </back>
</rfc>
