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 February 9, 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.

Table of Contents

1.  Introduction
    1.1.  Requirements Language
    1.2.  Terminology
2.  Protocol Summary
    2.1.  RELAYFORWARD Message
    2.2.  RELAYREPLY Message
3.  Encoding
    3.1.  Relay Segment
    3.2.  Encapsulation Segment
        3.2.1.  Encapsulated relay message
        3.2.2.  Encapsulated non-relay messages
    3.3.  Encapsulation Information suboption
    3.4.  Encapsulating Agent Address suboption
    3.5.  Gateway IP Address suboption
    3.6.  Message Type Suboption
    3.7.  Relay Agent Information Suboption
4.  DHCP Relay Agent Behavior
    4.1.  Packet processing
        4.1.1.  Packets traveling toward DHCP servers
        4.1.2.  Packets traveling toward DHCP clients
    4.2.  Constructing RELAYFORWARD messages
        4.2.1.  Encapsulating RELAYFORWARD messages
        4.2.2.  Encapsulating other messages
        4.2.3.  Constructing the relay segment
    4.3.  Decapsulating RELAYREPLY messages
        4.3.1.  Extracting and processing relay agent suboptions
        4.3.2.  Constructing the decapsulated message
        4.3.3.  Transmitting the decapsulated message
5.  DHCP Server Behavior
    5.1.  Receiving RELAYFORWARD messages
        5.1.1.  Decapsulation
        5.1.2.  Processing of decapsulated suboptions
    5.2.  Sending RELAYREPLY messages
        5.2.1.  Directing responses along the reply chain
        5.2.2.  Inner message
        5.2.3.  Iterating across the encapsulation layers
        5.2.4.  Per-iteration processing
            5.2.4.1.  Processing for non-conforming relay agents
            5.2.4.2.  Processing for conforming relay agents
        5.2.5.  Transmission of RELAYREPLY messages
6.  DHCP Client Behavior
7.  Security Considerations
8.  IANA Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Author's Address

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 (Patrick, M., “DHCP Relay Agent Information Option,” January 2001.) [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 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

1.2.  Terminology

The following terms and acronyms are used in this document:

DHCP

- Dynamic Host Configuration Protocol Version 4 [RFC2131] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.)

RAIO

- Relay Agent Information Option (Patrick, M., “DHCP Relay Agent Information Option,” January 2001.) [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.

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 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [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.

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:

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

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 (Droms, R. and W. Arbaugh, “Authentication for DHCP Messages,” June 2001.) [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:

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 (Patrick, M., “DHCP Relay Agent Information Option,” January 2001.) [RFC3046], not DHCP option codes (Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions,” March 1997.) [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 (Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions,” March 1997.) [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 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 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 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 (Patrick, M., “DHCP Relay Agent Information Option,” January 2001.) [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.

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 (Stapp, M., “The DHCPv4 Relay Agent Identifier Suboption,” July 2009.) [I‑D.ietf‑dhc‑relay‑id‑suboption] to identify itself.

If the relay agent is not a layer two relay agent (Joshi, B. and P. Kurapati, “Layer 2 Relay Agent Information,” April 2009.) [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:

• identifying the Encapsulation Information subption,
• using it to extract relay agent suboptions from the relay segment of the RELAYREPLY message,
• processing those suboptionsm
• constructing the decapsulated message,
• 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 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 (Patrick, M., “DHCP Relay Agent Information Option,” January 2001.) [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 (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) [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.

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.

Some relay agent suboptions, such as the Relay Agent Subnet Selection suboption (Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, “Link Selection sub-option for the Relay Agent Information Option for DHCPv4,” April 2003.) [RFC3527], are intended to be processed by DHCP servers. Others, like the Circuit ID and Remote ID (Patrick, M., “DHCP Relay Agent Information Option,” January 2001.) [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:

• the use of the Encapsulating Agent Address suboption
• 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 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 (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) [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.

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 (Patrick, M., “DHCP Relay Agent Information Option,” January 2001.) [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 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" (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) [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.

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

9.2. Informative References

Author's Address