dhc T. Lemon
Internet-Draft Nominum, Inc.
Intended status: Standards Track August 10, 2010
Expires: January 6, 2011
Relay Agent Encapsulation for DHCPv4
draft-lemon-dhcpv4-relay-encapsulation-00
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Lemon Expires January 6, 2011 [Page 1]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. RELAYFORWARD Message . . . . . . . . . . . . . . . . . . . 5
2.2. RELAYREPLY Message . . . . . . . . . . . . . . . . . . . . 5
3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Relay Segment . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Encapsulation Segment . . . . . . . . . . . . . . . . . . 6
3.2.1. Encapsulated relay message . . . . . . . . . . . . . . 6
3.2.2. Encapsulated non-relay messages . . . . . . . . . . . 6
3.3. Encapsulation Information suboption . . . . . . . . . . . 7
3.4. Encapsulating Agent Address suboption . . . . . . . . . . 7
3.5. Gateway IP Address suboption . . . . . . . . . . . . . . . 8
3.6. Message Type Suboption . . . . . . . . . . . . . . . . . . 8
3.7. Relay Agent Information Suboption . . . . . . . . . . . . 8
4. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . 9
4.1. Packet processing . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Packets traveling toward DHCP servers . . . . . . . . 10
4.1.2. Packets traveling toward DHCP clients . . . . . . . . 10
4.2. Constructing RELAYFORWARD messages . . . . . . . . . . . . 10
4.2.1. Encapsulating RELAYFORWARD messages . . . . . . . . . 10
4.2.2. Encapsulating other messages . . . . . . . . . . . . . 11
4.2.3. Constructing the relay segment . . . . . . . . . . . . 12
4.3. Decapsulating RELAYREPLY messages . . . . . . . . . . . . 12
4.3.1. Extracting and processing relay agent suboptions . . . 12
4.3.2. Constructing the decapsulated message . . . . . . . . 13
4.3.3. Transmitting the decapsulated message . . . . . . . . 13
5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 13
5.1. Receiving RELAYFORWARD messages . . . . . . . . . . . . . 14
5.1.1. Decapsulation . . . . . . . . . . . . . . . . . . . . 14
5.1.2. Processing of decapsulated suboptions . . . . . . . . 14
5.2. Sending RELAYREPLY messages . . . . . . . . . . . . . . . 15
5.2.1. Directing responses along the reply chain . . . . . . 15
5.2.2. Inner message . . . . . . . . . . . . . . . . . . . . 16
5.2.3. Iterating across the encapsulation layers . . . . . . 16
5.2.4. Per-iteration processing . . . . . . . . . . . . . . . 17
5.2.4.1. Processing for non-conforming relay agents . . . . 17
5.2.4.2. Processing for conforming relay agents . . . . . . 17
5.2.5. Transmission of RELAYREPLY messages . . . . . . . . . 18
6. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Lemon Expires January 6, 2011 [Page 2]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Lemon Expires January 6, 2011 [Page 3]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
1. Introduction
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.
The current Relay Agent Information Option specification [RFC3046]
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.
DHCP version 6 [RFC3315] provides a much cleaner technique for
providing relay agent information suboptions to the DHCP server.
Rather than appending an 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.
This document specifies a mechanism for providing the same
functionality in DHCPv4.
1.1. Requirements Language
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 RFC 2119 [RFC2119].
1.2. Terminology
The following terms and acronyms are used in this document:
DHCP - Dynamic Host Configuration Protocol Version 4 [RFC2131]
RAIO - Relay Agent Information Option [RFC3046]. Also commonly
referred to as "Option 82."
RAIO suboption - An DHCP suboption that has been defined for
encapsulation in the Relay Agent Information Option
agent encapsulation - Encapsulating DHCP packets that are being
relayed from DHCP clients or relay agents toward DHCP servers,
according to the method described in this specification.
Lemon Expires January 6, 2011 [Page 4]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
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.
relay message - A RELAYFORWARD or RELAYREPLY message.
option buffer - the portion of the DHCP packet following the magic
cookie in the 'vend' field of the DHCP Packet.
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.
2. Protocol Summary
This document specifies two new DHCP message types: the RELAYFORWARD
message, and the RELAYREPLY message. These messages are analogous to
the Relay Forward and Relay Reply messages in DHCPv6 [RFC3315].
2.1. RELAYFORWARD Message
Conforming relay agents encapsulate messages being sent toward DHCP
servers in RELAYFORWARD messages.
2.2. RELAYREPLY Message
Conforming DHCP servers encapsulate messages being sent toward DHCP
clients in RELAYREPLY messages.
Conforming Relay agents, when receiving RELAYREPLY messages,
decapsulate the message contained in the RELAYREPLY message and send
it to the next relay.
3. Encoding
Both RELAYFORWARD and RELAYREPLY messages have the same format, which
is similar to the format of other DHCP messages. The BOOTP/DHCP
header has the same format, because it must be possible for non-
conforming relay agents to parse it. The option buffer, however,
contains two segments - the relay segment, and the encapsulation
segment.
Lemon Expires January 6, 2011 [Page 5]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
3.1. Relay Segment
The relay segment consists of a DHCP Message Type suboption
specifying either a RELAYFORWARD or RELAYREPLY message, an
Encapsulation Information suboption, and any RAIO suboptions. These
options, including the first two mentioned, may appear in any order
within the relay segment.
Option codes in the Relay Segment are RAIO option codes, not DHCP
option codes. Relay segments never contain pad options. The length
of the relay segment, excluding the magic cookie, is specified in the
Encapsulation Information suboption. End and Pad options MUST NOT
appear within the relay segment.
3.2. Encapsulation Segment
The encapsulation segment contains either an encapsulated relay
message, or an encapsulated non-relay message.
3.2.1. Encapsulated relay message
An encapsulated relay message option buffer has the same format as
the option buffer of a relay message option buffer that is not
encapsulated--a relay segment, followed by an encapsulation segment.
An arbitrary number of encapsulations can be done in this way, as
long as there is room in the packet.
3.2.2. Encapsulated non-relay messages
An encapsulated non-relay message option buffer contains all the
options in the message that was encapsulated, with the following
exceptions:
o Any options following the first End option are omitted (these
options are assumed to be garbage; any signature is assumed not to
apply to them.
o 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 are omitted, and the number of Pad
options omitted is recorded in the Relay Encapsulation Information
suboption.
o If an End option is present at the end of the option buffer being
encapsulated, it is omitted, and the ep field is set to 1. If no
End option is present, the ep field is set to 0. If more than one
End option is present, only the final End option is omitted.
Lemon Expires January 6, 2011 [Page 6]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
3.3. Encapsulation Information suboption
The Encapsulation Information suboption is used by the relay to
report the total length of the data being encapsulated, the amount of
stripped padding, and whether or not an end option was stripped.
This is necessary in order to ensure that the original packet
contents can be reconstructed when decapsulating, which in turn
allows the server to check any signature [RFC3118] that may be
present.
+----+----+----+----+----+----+----+----+----+
|code| len| rslen | caplen | padlen | ep |
+----+----+----+----+----+----+----+----+----+
The Encapsulation Information Suboption consists of six parts:
code The suboption code: a single byte with a value value of TBD
len The suboption length: a single byte with a value of 7.
rslen The length of the relay segment: two byte in network byte
order.
caplen The length of the encapsulation segment: two byte in network
byte order.
padlen The length of any padding that was removed from the option
buffer prior to encapsulation: two bytes in network byte order.
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.
3.4. Encapsulating Agent Address suboption
The Encapsulating Agent Address suboption indicates to the DHCP
server or intermediate relay the IP address of the relay agent which
did the encapsulation.
+----+----+----+----+----+----+
|code| len| relay ip addr |
+----+----+----+----+----+----+
The Encapsulating Agent Address suboption consists of the following
fields:
Lemon Expires January 6, 2011 [Page 7]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
code The suboption code: a single byte with a value value of TBD
len The suboption length: a single byte with a value of 4.
relay ip addr The IP address of the relay agent.
3.5. Gateway IP Address suboption
The Gateway IP address suboption is used to specify an IP address to
store in the giaddr of a decapsulated packet.
+----+----+----+----+----+----+
|code| len| gateway ip addr |
+----+----+----+----+----+----+
The Gateway IP Address suboption consists of the following fields:
code The suboption code: a single byte with a value value of TBD
len The suboption length: a single byte with a value of 4.
relay ip addr The IP address to store in giaddr.
3.6. Message Type Suboption
Because options in the relay segment are encoded using RAIO suboption
codes [RFC3046], not DHCP option codes [RFC2132], and because the
Message Type option must appear in the relay segment, we define an
RAIO suboption that is exactly the same as the DHCP Message Type
option specified in section 9.6 of DHCP Options and BOOTP Vendor
Extensions [RFC2132]. This suboption has an option code of 53.
3.7. Relay Agent Information Suboption
As with the Message Type suboption, it is possible that a non-
conforming relay agent will append an RAIO to a RELAYFORWARD message.
In order for that to be parsed correctly, we must define an analog to
the RAIO. The Relay Agent Information suboption is treated as if it
were an RAIO when unpacking a RELAYFORWARD message. When
constructing a RELAYREPLY message that will be handled by a non-
conforming relay agent that included an RAIO, a Relay Agent
Information suboption will be used exactly as if it were an RAIO.
+----+----+----+----+----+...--+
|code| len| suboptions... |
+----+----+----+----+----+...--+
The Relay Agent Information suboption consists of the following
Lemon Expires January 6, 2011 [Page 8]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
fields:
code The suboption code: a single byte with a value value of TBD
len The suboption length: a single byte containing the length of the
suboptions field.
suboptions... Zero or more Relay Agent Information suboptions.
4. DHCP Relay Agent Behavior
DHCP Relay agents implementing this specification MUST have a
configuration parameter controlling relay encapsulation. By default,
relay encapsulation MUST be disabled.
Relay agents with encapsulation disabled MUST NOT encapsulate. Relay
agents with encapsulation disabled MUST NOT decapsulate. Relay
agents that encapsulate MUST NOT encapsulate BOOTP messages (that is,
messages that do not contain the DHCP Message Type option).
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.
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.
4.1. Packet processing
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.
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 1, the
message is traveling toward a DHCP server. If the 'op' field is set
to zero, 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. 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
Lemon Expires January 6, 2011 [Page 9]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
specified here will remain in effect.
4.1.1. Packets traveling toward DHCP servers
When a DHCP relay agent receives a RELAYREPLY message that is
traveling toward the DHCP server, the relay agent MUST silently
discard the message.
When a DHCP relay agent that is configured to encapsulate receives a
DHCP message that is traveling toward the DHCP server that is not a
RELAYREPLY message, the relay agent MUST encapsulate that packet into
a RELAYFORWARD message and sends it to the address or addresses to
which it is configured to forward messages intended for DHCP servers.
4.1.2. Packets traveling toward DHCP clients
When a DHCP relay agent receives a RELAYFORWARD message that is
traveling toward the DHCP client, the relay agent MUST discard the
message.
When a DHCP relay agent that is configured to encapsulate receives a
RELAYREPLY message that is traveling toward the DHCP client, the
relay agent MUST decapsulate that message and forward the
decapsulated message toward the client.
When a DHCP relay agent configured to encapsulate receives any other
message moving toward a DHCP client, it MUST silently discard the
message.
4.2. Constructing RELAYFORWARD messages
The relay agent constructs the RELAYFORWARD message by copying the
source message up to the end of the magic cookie in the option buffer
of the message. Following that, the relay agent constructs the relay
segment, as described below. Following that, the relay agent copies
'caplen' octets from the option buffer of the source message,
starting at the beginning of the first option that follows the magic
cookie.
The relay agent MUST NOT modify the 'giaddr' field, or any other
field, of the constructed RELAYFORWARD message.
4.2.1. Encapsulating RELAYFORWARD messages
When encapsulating RELAYFORWARD messages, the length of the
encapsulation segment is the sum of the 'rslen' and 'caplen' fields
in the encapsulation segment of the RELAYFOWARD message. This will
be the value stored in the 'caplen' field in the new encapsulation
Lemon Expires January 6, 2011 [Page 10]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
segment. The 'padlen' and 'ep' fields are always set to zero when
encapsulating RELAYFORWARD messages.
4.2.2. Encapsulating other messages
When encapsulating other messages, the length of the encapsulation
segment is determined 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 there are no more options
in the option buffer. Any data following the End option is
discarded.
While scanning, the relay agent maintains a flag which indicates
whether or not a pad option has been encountered. The flag is
initialized to false. When a Pad option is encountered, if the flag
is false, it is set to true, and the location of that Pad option is
recorded. If an option that is neither a Pad option nor an End
option is encountered, the flag is set to false. In any other case,
no action is taken with respect to either the flag or the Pad
location.
When the end of the option buffer is reached, the value of 'padlen'
is computed as the difference, in octets, between the location of the
end of the option segment--either the location of the first End
option encountered, or the first location after the buffer--and the
last location recorded for a Pad option; if the pad flag is false,
then 'padlen' is always zero.
If the pad flag is true, then 'caplen' is the difference in octets
between the last location recorded for a Pad option and the location
of the first option in the option buffer. If it is false, then
'caplen' is the difference in octets between the location of the
first End option encountered in the option buffer and the first
option in the buffer. If flag is false and no End option is present
in the option buffer, then 'caplen' is the length of the option
buffer, less four octets for the magic cookie.
The 'ep' field is set to zero if no End option was present in the
option buffer; it is set to one if an End option was present.
Note that the RAIO specification [RFC3046] requires that if an End
option is present in the DHCP message to which the RAIO is to be
appended, the RAIO will instead be inserted immediately prior to the
End option. This means that if a conforming implementation
encapsulates a packet containing an RAIO, it will simply appear as an
option in the encapsulation segment. When encapsulating, relay
agents MUST NOT include an RAIO if it follows an End option.
Lemon Expires January 6, 2011 [Page 11]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
4.2.3. Constructing the relay segment
The relay agent constructs the relay segment by including any RAIO
options it is configured to send. The relay agent MUST include a
DHCP Message Type suboption, with the message type set to
'RELAYFORWARD' (TBD).
The relay agent SHOULD include a Relay Agent ID suboption
[I-D.ietf-dhc-relay-id-suboption] to identify itself.
If the relay agent is not a layer two relay agent
[I-D.ietf-dhc-l2ra], it MUST include an Encapsulation Forwarding
Address suboption containing 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.
The relay agent MUST include an Encapsulation Information suboption.
The 'caplen' and 'padlen' fields of this suboption are set to the
values determined in the previous section. The 'rslen' field is set
to the total length of the options in the relay segment, including
the Encapsulation Information suboption.
4.3. Decapsulating RELAYREPLY messages
There are five parts to the decapsulation process:
o identifying the Encapsulation Information subption,
o using it to extract relay agent suboptions from the relay segment
of the RELAYREPLY message,
o processing those suboptionsm
o constructing the decapsulated message,
o forwarding the decapsulated message toward the DHCP client.
4.3.1. Extracting and processing relay agent suboptions
The relay agent first locates the Encapsulation Information suboption
in the option buffer of the RELAYREPLY message. Although this option
always appears in the relay segment of the RELAYREPLY message, the
relay agent has no way to differentiate the encapsulation segment and
the relay segment until it has located this option, so it simply
scans forward, option by option, in the option buffer until it finds
this option.
If the relay agent fails to locate an Encapsulation Information
Lemon Expires January 6, 2011 [Page 12]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
suboption, it MUST silently discard the RELAYREPLY message.
Once the relay agent has located the Encapsulation Information
suboption, it parses the portion of the 'options' field of the DHCP
packet starting with the first option following the magic cookie, up
to the number of bytes specified by the 'rslen' field of the
Encapsulation Information suboption.
The suboptions parsed from the relay segment are processed by the
relay agent as specified in the Relay Agent Information Option
specification [RFC3046], 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."
4.3.2. Constructing the decapsulated message
In order to decapsulate the RELAYREPLY message, the relay agent
constructs a new, decapsulated message by copying the portion of the
RELAYREPLY message up to and including the magic cookie in the
'options' field of the message. The relay agent then copies the
portion of the 'options' field of the source message beginning after
the relay segment, up to 'caplen' bytes, into the new message. If
the 'padlen' field is nonzero, the relay agent appends that many Pad
options to the new message. If the 'ep' field is nonzero, the relay
agent appends an 'End' option to the new message.
If a Gateway IP Address suboption is present in the relay segment,
the relay agent MUST store the IP address contained in that option in
the 'giaddr' field of the new message.
4.3.3. Transmitting the decapsulated message
The decapsulated message is forwarded to the IP address specified in
the Encapsulating Agent Address suboption, if that suboption is
present. If that suboption is not present, the message is forwarded
to the DHCP client as if it were on the local subnet, as specified in
the DHCP protocol specification [RFC2131]. This suboption will not
be present if the next hop is the DHCP client, or if all remaining
relay agents in the relay chain are layer two relay agents.
5. DHCP Server Behavior
A DHCP server which receives a RELAYREPLY message MUST silently
discard that message.
Lemon Expires January 6, 2011 [Page 13]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
5.1. Receiving RELAYFORWARD messages
DHCP servers that implement this specification MUST decapsulate
RELAYFORWARD messages.
5.1.1. Decapsulation
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.
In addition, this specification allows for the provisioning of a
single non-conforming relay agent anywhere in the forwarding chain,
through the use of the Gateway IP Address suboption. DHCP servers
implementing this specification MUST record the Relay Agent
Information option contents as if they were a layer of encapsulation,
in the correct order, marked for special handling when constructing
the response.
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.
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.
5.1.2. Processing of decapsulated suboptions
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.
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.
Lemon Expires January 6, 2011 [Page 14]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
Some relay agent suboptions, such as the Relay Agent Subnet Selection
suboption [RFC3527], are intended to be processed by DHCP servers.
Others, like the Circuit ID and Remote ID [RFC3046] suboptions, were
not intended to be processed by the DHCP server, but are often used
by the DHCP server for identification purposes.
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.
By default, DHCP servers MUST use the innermost suboption (the one
added by the relay agent closest to the DHCP client) for every
suboption that was sent by more than one relay agent.
5.2. Sending RELAYREPLY messages
When a DHCP server constructs a response to a DHCP client message
that arrived encapsulated in a RELAYFORWARD message, the DHCP server
MUST encapsulate the response in a RELAYREPLY message. When multiple
layers of RELAYFORWARD messages were received, the server MUST
respond with an equivalently layering of RELAYREPLY messages. When
an RAIO was found, the DHCP server MUST return an RAIO at the same
position in the encapsulation, if any.
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.
In general, RELAYREPLY messages are constructed in the same way that
RELAYFORWARD messages are constructed. However, there are two key
differences to consider in the construction of the relay segment of
RELAYREPLY messages:
o the use of the Encapsulating Agent Address suboption
o the use of the Gateway IP Address suboption
5.2.1. Directing responses along the reply chain
Relay agents indicate their IP addresses to the DHCP server using the
Encapsulating Agent Address suboption. DHCP servers indicate the IP
address of the agent to which to forward the response using the
Encapsulating Agent Address option.
This means that in a RELAYFORWARD message, the Encapsulating Agent
Address option contains the address of the relay agent that
constructed the message. In the RELAYREPLY message, it contains a
Lemon Expires January 6, 2011 [Page 15]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
different address: the address to which the message encapsulated in
the RELAYREPLY message should be sent.
This is complicated by the fact that a layer two relay agent or a
non-conforming relay agent can appear at any position in the relay
chain. In the case of a non-conforming relay agent, we use giaddr
instead of the Encapsulating Agent Address suboption to indicate the
IP address to which the relay agent should forward the response.
In the case of a layer two relay agent, some encapsulation layer
inside of the layer two agent's layer may contain the IP address of
the next hop in the chain that has an IP address. If all the relay
agents between the layer two relay agent and the client are also
layer two relay agents, there will be no IP address to which to
forward the response.
In either case, it is assumed that if there is no downstream device
with an IP address prior to the DHCP client, normal packet
transmission rules for reaching the DHCP client are used, as
specified in the DHCP protocol [RFC2131].
5.2.2. Inner message
When a DHCP server is constructing a response to a RELAYFORWARD
message, it starts with the DHCP message that is to be delivered to a
client--for example, a DHCPACK message. This message is constructed
in the usual way, except that giaddr is not set, even if it was set
in the RELAYFORWARD message. This message becomes the outgoing
message.
The DHCP server MUST NOT insert any Pad or End options into the
initial outgoing message.
5.2.3. Iterating across the encapsulation layers
As it iterates across the layers of encapsulation, The DHCP server
tracks two values: a next-hop destination address, and a next-hop
gateway address. Initially both values are 0.0.0.0. It also tracks
a flag called "appended RAIO" which starts out false.
The DHCP server iterates across the recorded information from the
encapsulations it unpacked when it received the RELAYFORWARD message,
starting with the innermost encapsulation, and proceeding toward the
outermost, in order.
Lemon Expires January 6, 2011 [Page 16]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
5.2.4. Per-iteration processing
5.2.4.1. Processing for non-conforming relay agents
If a particular layer was created by parsing an RAIO, rather than by
unpacking an encapsulation, then the server packs an RAIO onto the
end of the outgoing message. Otherwise, the server encapsulates the
outgoing message in a RELAYREPLY message.
If the server is packing an RAIO, the suboptions in the RAIO are
constructed as specified in the RAIO specification [RFC3046] and any
suboption-specific documents that apply. When the server packs an
RAIO, it MUST set the next-hop gateway IP address value to the value
of the next-hop destination IP address, and set the value of the
next-hop destination IP address to the value of giaddr from the
incoming RELAYFORWARD message.
When the server packs an RAIO, it appends it to the end of the
outgoing message, and sets the "appended RAIO" flag to true. If
there are any further layers of encapsulation, this outgoing message
is used as the input for the next layer of encapsulation.
5.2.4.2. Processing for conforming relay agents
To encapsulate a layer, the server creates a new message based on the
outgoing message by first copying the outgoing message, up to the
magic number in the option buffer, then inserting a relay segment,
and then copying the remainder of the option buffer into the
encapsulation segment. The implementation is of course not required
to copy multiple times; it is specified this way here solely for
clarity.
The server MUST NOT insert any Pad or End options either in the relay
segment or the encapsulation segment of the new message.
The server MUST copy every suboption that appeared in the incoming
relay segment into the outgoing relay segment, except for the Message
Type, Encapsulation Information and Encapsulating Agent Address
suboptions, and except for relay agent suboptions whose
specifications require or permit other behavior for the server. The
server SHOULD NOT preserve the order of options from the incoming
relay segment to the outgoing relay segment.
The server MUST insert a Message Type suboption with a message type
of RELAYREPLY (TBD).
If the "appended RAIO" flag is true, and the current next-hop gateway
address value is not 0.0.0.0, the server MUST insert a Gateway IP
Lemon Expires January 6, 2011 [Page 17]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
Address suboption into the relay segment. The 'gateway ip addr'
field MUST be set to the current next-hop gateway address value. The
DHCP server MUST then set the next-hop gateway address value to
0.0.0.0.
If there was an Encapsulating Agent IP Address suboption in the
incoming relay segment for the current layer, and the next-hop
destination IP address value is not 0.0.0.0, the DHCP server MUST
insert an Encapsulating Agent IP Address suboption into the relay
segment, and it MUST set the 'relay ip addr' field to the current
next-hop destination address. The server MUST then set the value of
the next-hop destination address to 0.0.0.0.
The DHCP server MUST insert an Encapsulation Information suboption.
The 'rslen' field MUST be set to the length of the relay segment.
The 'caplen' field MUST be set to the length of the encapsulation
segment. The 'padlen' and 'ep' fields must be zero.
Having completed an encapsulation layer, the new message becomes the
outgoing message. The server sets the "appended RAIO" flag to false.
If an additional layer of encapsulation remains to be processed, the
new outgoing message will be used as input for the next iteration.
5.2.5. Transmission of RELAYREPLY messages
This needs work. I am not sure that all the giaddr intricacies are
accounted for.
During iteration across the incoming encapsulations, the DHCP server
tracked two values: the next-hop IP address, and the next-hop gateway
address. If the next-hop gateway address value is not 0.0.0.0, and
the "appended RAIO" flag is true, the DHCP server MUST set the
'giaddr' field of the outgoing message to that value.
If the next-hop destination address is not 0.0.0.0, the DHCP server
MUST send the outgoing message to that address, with a destination
port of 67. If the next-hop destination address is 0.0.0.0, the DHCP
server MUST transmit the packet as specified in the DHCP protocol"
[RFC2131] for the case where the client is on the local subnet.
6. DHCP Client Behavior
A DHCP client that receives either a RELAYFORWARD message or a
RELAYREPLY message MUST silently discard that message.
Lemon Expires January 6, 2011 [Page 18]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
7. Security Considerations
Need to specify how encapsulations are signed.
8. IANA Considerations
We request that IANA assign three new suboption codes from the
registry of DHCP Agent Sub-Option Codes maintained in
http://www.iana.org/assignments/bootp-dhcp-parameters. One each of
these suboption codes will be assigned to the Encapsulation
Information suboption, the Encapsulating Agent Address suboption, and
the Gateway IP Address suboption.
We request that IANA assign a new suboption code from the registry of
DHCP Agent Sub-Option Codes maintained in
http://www.iana.org/assignments/bootp-dhcp-parameters. The value of
this suboption code MUST be 53, so as to be compatible with the DHCP
Message Type option. This suboption code will be assigned to the
DHCP Message Type suboption.
We request that IANA assign a new suboption code from the registry of
DHCP Agent Sub-Option Codes maintained in
http://www.iana.org/assignments/bootp-dhcp-parameters. The value of
this suboption code MUST be 82, so as to be compatible with the Relay
Agent Information option. This suboption code will be assigned to
the Relay Agent Information suboption.
We request that IANA assign two new message type codes from the
registry of DHCP Message Type 53 values maintained in
http://www.iana.org/assignments/bootp-dhcp-parameters. These two
codes will be assigned to the RELAYFORWARD and RELAYREPLY message
types.
9. References
9.1. Normative References
[I-D.ietf-dhc-relay-id-suboption]
Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption",
draft-ietf-dhc-relay-id-suboption-07 (work in progress),
July 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
Lemon Expires January 6, 2011 [Page 19]
Internet-Draft Relay Agent Encapsulation for DHCPv4 August 2010
RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
"Link Selection sub-option for the Relay Agent Information
Option for DHCPv4", RFC 3527, April 2003.
9.2. Informative References
[I-D.ietf-dhc-l2ra]
Joshi, B. and P. Kurapati, "Layer 2 Relay Agent
Information", draft-ietf-dhc-l2ra-04 (work in progress),
April 2009.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
Author's Address
Ted Lemon
Nominum, Inc.
2000 Seaport Blvd
Redwood City, CA 94063
USA
Phone: +1 650 381 6000
Email: mellon@nominum.com
Lemon Expires January 6, 2011 [Page 20]