One document matched: draft-ietf-dhc-dhcpv4-relay-encapsulation-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 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-ietf-dhc-dhcpv4-relay-encapsulation-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>
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="16" month="October" 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" hangIndent="22">
<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—a relay agent that
doesn't have an IP address reachable by the DHCP server.</t>
<t hangText="L3RA">Layer 3 Relay Agent—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—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—the
encapsulation of the original message sent from the client,
which is done by the first encapsulating relay—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>
| PAFTECH AB 2003-2026 | 2026-04-24 07:47:20 |