DHC Working Group B. Joshi
Internet-Draft P. Kurapati
Expires: August 13, 2007 M. Kamath
Infosys Technologies Ltd.
S. De Cnodder
Alcatel-Lucent
February 9, 2007
Layer 2 Relay Agent
draft-joshi-dhc-layer2-relay-agent-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
In Layer 2 Access Networks, Access Concentrators are present between
DHCP Clients and Relay Agent. In this case, the Relay Agent can not
uniquely identify the end host and hence can not add unique 'Relay
Agent Information' option corresponding to the end hosts in DHCP
messages. As the Access concentrators are closer to the end hosts,
Joshi, et al. Expires August 13, 2007 [Page 1]
Internet-Draft Layer 2 Relay Agent February 2007
they can uniquely identify the end hosts and add the Relay Agent
Information option in the DHCP message. Access concentrators do not
set the 'giaddr' field. Access Concentrators in this mode are
typically known as Layer 2 Relay agents.
This document provides insight to the behavior of the Access
Concentrators which act as DHCP Layer 2 Relay Agents in Access
Networks.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Layer 2 Relay Agent . . . . . . . . . . . . . . . . . . . . . 7
4. Handling DHCP messages in Layer 2 Relay Agent . . . . . . . . 8
4.1. Handling Broadcast DHCP messages . . . . . . . . . . . . . 8
4.2. Handling Unicast DHCP messages . . . . . . . . . . . . . . 8
5. Handling DHCP messages in Layer 3 Relay Agent . . . . . . . . 9
6. Handling DHCP messages in DHCP server . . . . . . . . . . . . 10
7. Extension of DHCPLEASEQUERY for Layer 2 Relay Agent . . . . . 11
7.1. Protocol Extension Overview . . . . . . . . . . . . . . . 11
7.1.1. Lease/Location information in layer 2 Networks . . . . 11
7.1.2. Extension of DHCPLEASEQUERY in layer 2 Networks . . . 11
7.2. Protocol Extension Details . . . . . . . . . . . . . . . . 11
7.2.1. Generating DHCPLEASEQUERY Message . . . . . . . . . . 11
7.2.2. Handling DHCPLEASEQUERY Message in Layer 3 Relay
Agent . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2.3. Handling DHCPLEASEQUERY Message in DHCP Server . . . . 13
7.2.4. Handling DHCP Reply Message in Layer 3 Relay Agent . . 13
7.2.5. Handling DHCP Reply Message in Layer 2 Relay Agent . . 13
7.3. DHCPLEASEQUERY using Management IP address of Layer 2
Relay Agent . . . . . . . . . . . . . . . . . . . . . . . 14
8. Prevention of flooding of DHCP replies from Layer 3 Relay
Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Flooding of DHCP reply messages from Layer 3 Relay
Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1.1. Unicast-Address Sub-Option . . . . . . . . . . . . . . 15
8.2. Flooding of DHCPLEASEQUERY reply messages from Layer 3
Relay Agent . . . . . . . . . . . . . . . . . . . . . . . 17
8.2.1. Relay Agent Hardware Address option . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. Security Consideration . . . . . . . . . . . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative Reference . . . . . . . . . . . . . . . . . . . 23
12.2. Informative Reference . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Joshi, et al. Expires August 13, 2007 [Page 2]
Internet-Draft Layer 2 Relay Agent February 2007
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Joshi, et al. Expires August 13, 2007 [Page 3]
Internet-Draft Layer 2 Relay Agent February 2007
1. Introduction
In Access Networks, Service Providers have been deploying DHCP to
dynamically configure the end hosts. DHCP Relay Agents eliminate the
necessity of having a DHCP server on each physical network. RFC 3046
defines a new option 'Relay Agent Information' which is added to DHCP
messages by Relay Agents. DHCP servers may use this option for IP
address and other parameter assignment policies.
In case of Layer 2 Access Networks, Access Concentrators typically
act as a transparent bridge. They act as DHCP relay agents by adding
'Relay Agent Information' option since they are closer to the
subscribers. The first Layer 3 device connected to Access
Concentrator acts as Layer 3 Relay agent which relays the DHCP
messages between DHCP clients and DHCP servers.
This document describes a typical Layer 2 Access Network and how a
Layer 2 Relay Agent works. It later describes the need for
leasequery in Layer 2 Relay Agents and extends RFC 4388 to Layer 2
Relay Agents. This document also describes mechanisms to prevent
flooding between Layer 2 Relay Agents and Layer 3 Relay Agent.
Joshi, et al. Expires August 13, 2007 [Page 4]
Internet-Draft Layer 2 Relay Agent February 2007
2. Terminology
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 [1].
This document uses the following terms:
o "Access Concentrator"
An Access Concentrator is a router or switch at the broadband access
provider's edge of a public broadband access network. This document
assumes that the Access Concentrator acts as a Transparent Bridge and
includes the DHCP relay agent functionality. For example: In DSL
environment, this is typically known as DSLAM.(Digital Subscriber
Line Access Multiplexer)
o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain configuration
parameters such as a network address.
o "Layer 3 Relay Agent"
A Layer 3 Relay Agent is a third-party agent that transfers Bootstrap
Protocol (BOOTP) and DHCP messages between clients and servers
residing on different subnets, per RFC951 [8] and RFC1542[9].
o "DHCP server"
A DHCP server is an Internet host that returns configuration
parameters to DHCP clients.
o "downstream"
Downstream is the direction from the edge network towards the DHCP
Clients.
o "Transparent Bridge"
A device which does bridging based on MAC learning principles.
Bridge learns the Source MAC of the incoming frames and updates a
table with MAC/Interface information. While forwarding data packets,
bridge looks at this table to find the outgoing interface.
o "upstream"
Upstream is the direction from the DHCP Clients towards the edge
Joshi, et al. Expires August 13, 2007 [Page 5]
Internet-Draft Layer 2 Relay Agent February 2007
network.
o "Uplink port"
A port on the Layer 2 relay agent that is connected to the upstream
router.
The layer 2 DHCP relay Agent does not have any IP interfaces. Hence
there is a need to identify a "Uplink Port", through which the DHCP
messages are relayed to the DHCP server, through a Layer 3 DHCP relay
agent. The uplink port SHOULD be a configurable parameter on the
Layer 2 DHCP relay agent. This will prevent an unnecessary flooding
of DHCP messages to all the ports which are a part of the same VLAN.
o "Unnumbered Interfaces"
An interface with no IP address associated with it. IP packets
received on this interface will be processed like any other numbered
IP interface. It may use a local IP address of another interface
while forwarding packets.
Joshi, et al. Expires August 13, 2007 [Page 6]
Internet-Draft Layer 2 Relay Agent February 2007
3. Layer 2 Relay Agent
In Access Networks, an Access Concentrator acting as Transparent
Bridge can also act as a Layer 2 DHCP Relay Agent. In figure 1,
Layer 3 Relay Agent can not uniquely identify the end hosts so the
Access Concentrator needs to append Relay Agent Information [option
82] to each DHCP packet before forwarding it to Layer 3 Relay Agent.
When a DHCP reply is received, Layer 2 Relay Agent uses the Relay
Agent option [option 82] to identify the outgoing interface and
removes the Relay Agent Information option before forwarding DHCP
reply to end hosts.
+-------+
+-----+ | |
|Host1|-------| |
+-----+ |Access |
|Concen-|-----......
+-----+ |trator | .
|Host2|-------| #1 | . +------+
+-----+ | | . | |
+-------+ ----| | +--------+
Trusted Layer 2 | | | DHCP |
DHCP Relay Agents |IPEdge|--.....---| Server |
+-------+ | | +--------+
+-----+ | | .----| |
|Host3|-------| | . | |
+-----+ |Access | . +------+
|Concen-|-----...... Layer 3
+-----+ |trator | Relay Agent
|Host4|-------| #2 |
+-----+ | |
+-------+
Figure 1
Joshi, et al. Expires August 13, 2007 [Page 7]
Internet-Draft Layer 2 Relay Agent February 2007
4. Handling DHCP messages in Layer 2 Relay Agent
4.1. Handling Broadcast DHCP messages
When a DHCP message is received from the DHCP client, the Layer 2
Relay Agent SHOULD add the Relay Agent Information (option 82 as
described in RFC 3046 [3]) and forward it towards the DHCP server.
The Layer 2 Relay Agent MUST NOT populate the 'giaddr' field in the
DHCP message. 'Relay Agent Information' option SHALL be added as the
last option, just before the END option (FF) as described in RFC 3046
[3].
If a Layer 2 Relay Agent receives a DHCP message that already
contains a Relay Agent Information option, the Layer 2 Relay Agent
may discard this packet if the interface on which is was received is
untrusted. Otherwise, if the interface is trusted, then the DHCP
packet should be forwarded as it is towards the DHCP server.
When the reply message is received from a server, the Relay Agent
Information option MAY be verified. A Layer 2 Relay Agent MAY
silently discard the packet if it had not added the Relay Agent
Information option. Relay Agent Information MAY be used to identify
the outgoing interface. The relay agent information MUST be removed
before the reply message is forwarded to the DHCP client.
4.2. Handling Unicast DHCP messages
DHCP Clients unicast RENEW, RELEASE and INFORM messages directly to
the DHCP server. Similar to a Layer 3 Relay Agent, a Layer 2 Relay
Agent does not intercept the unicast DHCP messages and so does not
add any Relay Agent Information option to unicast messages.
Some existing implementations maintain lease/location informations
for each DHCP client. These implementations snoop unicast DHCP
messages to keep the lease/location information updated. So a Layer
2 Relay Agent adds Relay Agent Information option to unicast DHCP
messages as well. Layer 3 Relay Agent and DHCP server process them
similar to the broadcast messages as described above in section 4.1.
Joshi, et al. Expires August 13, 2007 [Page 8]
Internet-Draft Layer 2 Relay Agent February 2007
5. Handling DHCP messages in Layer 3 Relay Agent
When Layer 3 Relay Agent receives a DHCP message from Layer 2 Relay
Agent, it does following:
o If the DHCP message contains option 82 and 'giaddr' field is set
to zero, and has been received from a trusted circuit, Layer 3
Relay Agent forwards the packet per normal DHCP relay agent
operations, setting the giaddr field as it deems appropriate. But
if such a DHCP message is received from an untrusted interface,
Relay Agent SHALL discard the packet.
o If the DHCP message does not contain any option 82, the processing
of packet MUST be done as per RFC 2131 and RFC 3046.
Layer 3 Relay Agent needs to forward replies of such DHCP messages
towards only that Layer 2 Relay Agent which had relayed the DHCP
message to the Layer 3 Relay Agent. This means that Layer 3 Relay
Agent needs a mechanism using which it can identify the outgoing
interface for the DHCP replies. A Layer 3 Relay Agent can achieve it
in following ways:
o A layer 3 relay agent can populate the 'giaddr' field in such a
way that when it receives the reply from DHCP server, it can use
the destination IP address of the DHCP reply message to identify
the outgoing interface. For example, it can use the primary IP
Address of the interface as 'giaddr' on which it had received the
DHCP message.
o The above method will not work if a Layer 3 Relay Agent uses
"unnumbered interface". In this case, a Layer 3 Relay Agent can
overcome this problem in following ways:
* If a Layer 3 Relay Agent uses the local IP Address as 'giaddr',
it can maintain some state information for each DHCP message
forwarded to the DHCP server. Layer 3 Relay Agent refers to
this state information to forward the reply messages.
* The above solution will not scale up if there are multiple
unnumbered interfaces. It will also not work if there are
multiple Relay Agents between DHCP Clients and server. This
issue can be resolved if intermediate Relay Agents support
Relay Chaining [7]. With Relay Chaining, each Relay Agent can
add Relay Agent Information option which can be used to
identify outgoing interface to forward the reply message.
Joshi, et al. Expires August 13, 2007 [Page 9]
Internet-Draft Layer 2 Relay Agent February 2007
6. Handling DHCP messages in DHCP server
There are no changes suggested in DHCP server functionality to
support Layer 2 Relay Agent.
Joshi, et al. Expires August 13, 2007 [Page 10]
Internet-Draft Layer 2 Relay Agent February 2007
7. Extension of DHCPLEASEQUERY for Layer 2 Relay Agent
7.1. Protocol Extension Overview
7.1.1. Lease/Location information in layer 2 Networks
Layer 2 Relay Agents snoop all DHCP messages and maintain the
information of outgoing interface, MAC Address, IP address and Lease
information for each DHCP Client. This information [MAC-IP-Interface
Binding] may be used to prevent MAC/IP Spoofing attacks and may also
be used for bridging frames.
7.1.2. Extension of DHCPLEASEQUERY in layer 2 Networks
Layer 2 Relay Agents acting as Transparent Bridge typically maintain
lease/location information for all DHCP clients. This makes it
vulnerable to the same issue [location/lease information lost when
Layer 2 Relay Agent gets rebooted] which has been addressed in RFC
4388 [5] for Layer 3 networks. This document extends mechanism
proposed in [5] to address this issue for layer 2 networks.
When Layer 2 Relay Agent needs to bridge a frame, it MAY refer to
location/lease information to verify the IP address or MAC address.
If the location/lease information is not available, it can query DHCP
server to obtain the lease/location information using DHCPLEASEQUERY
message.
Layer 2 Relay Agent can generate a DHCPLEASEQUERY [Query by IP
address, MAC address or client identifier [10]] with all the fields
properly populated as defined in RFC 4388 [5].
7.2. Protocol Extension Details
7.2.1. Generating DHCPLEASEQUERY Message
When a data packet is received from a host, Layer 2 Relay Agent may
verify if it has location/lease information for the source IP address
or source MAC address of data packet received. Similarly when Layer
2 Relay Agent receives a data packet from upstream interface, it may
verify location/lease information for the destination IP address or
destination MAC address of the data packet. A Layer 2 Relay Agent
would typically generate DHCPLEASEQUERY message if the location/lease
information is not available for the corresponding IP address or MAC
address assuming that it has lost the location/lease information
during last reboot. The DHCPLEASEQUERY message uses the DHCP message
format as described in RFC 2131 [2], and uses message number 10 in
the DHCP Message Type option (option 53). The DHCPLEASEQUERY message
has the following pertinent message contents:
Joshi, et al. Expires August 13, 2007 [Page 11]
Internet-Draft Layer 2 Relay Agent February 2007
o "giaddr" field MUST NOT be set. Though RFC 4388 [5] mandates that
an Access Concentrator [in Layer 3 mode] MUST set the "giaddr"
field, this document suggest that a Layer 2 Relay Agent acting as
Transparent Bridge must not set the "giaddr" field.
o The Parameter Request List option (option 55) MUST include the
Relay Agent Information option (option 82).
o All the other options in Parameter Request List option (option 55)
SHOULD be set as per the interest of the requester. The
interesting options are likely to include the IP Address Lease
Time option (option 51) and possibly the Vendor class identifier
option (option 60).
o Source IP address of the DHCPLEASEQUERY message MUST be set to
0.0.0.0.
o Destination IP address of the DHCPLEASEQUERY message MUST be set
to broadcast address 255.255.255.255.
o Destination MAC address of the DHCPLEASEQUERY message MUST be set
to FF:FF:FF:FF:FF:FF.
o Source MAC address of the DHCPLEASEQUERY message MUST be set to
the hardware address of the interface on which this request is
sent out.
All other fields in MAC header, IP header and DHCP header SHOULD be
set as per RFC 2131 [2]. Additional details concerning different
query types are same as defined in RFC 4388 [5].
7.2.2. Handling DHCPLEASEQUERY Message in Layer 3 Relay Agent
A Layer 3 Relay Agent conforming to this document, MUST process the
DHCP LEASEQUERY message received on its downstream interface similar
to the other DHCP messages.
When a Layer 3 Relay Agent uses unnumbered interfaces and does not
maintain internal states, it can not identify the outgoing interface
when DHCP server returns DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN. So
a Layer 3 Relay Agent MUST add Relay Agent Information option to the
DHCPLEASEQUERY messages as described in RFC 3046 [3]. DHCP server
MUST echo back this option for message type DHCPLEASEUNASSIGNED or
DHCPLEASEUNKNOWN and Layer 3 Relay Agent SHALL use this to identify
the outgoing interface.
Joshi, et al. Expires August 13, 2007 [Page 12]
Internet-Draft Layer 2 Relay Agent February 2007
7.2.3. Handling DHCPLEASEQUERY Message in DHCP Server
While generating a DHCP reply for a DHCPLEASEQUERY message, if the
message type is DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN, it MUST echo
back the Relay Agent Information received in the DHCPLEASEQUERY
message. If the message type is DHCPLEASEACTIVE, DHCP server
prepares the message as described in RFC 4388 and ignores the Relay
Agent Information option received in the DHCPLEASEQUERY message.
This document does not propose any other changes to RFC 4388 [5] for
handling DHCPLEASEQUERY message in DHCP server.
7.2.4. Handling DHCP Reply Message in Layer 3 Relay Agent
When Layer 3 Relay Agent receives a DHCP Reply message with message
type as DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN, it
must have a way to identify if it had generated the leasequery
message or it had relayed it for a Layer 2 Relay Agent.
When the DHCP Reply message is received, a Layer 3 Relay Agent MAY
use 'giaddr', 'state information' or Relay Agent Information option
to identify the outgoing interface.
7.2.5. Handling DHCP Reply Message in Layer 2 Relay Agent
7.2.5.1. Handling DHCPLEASEUNASSIGNED Reply Message
When a DHCPLEASEUNASSIGNED message is received by Layer 2 Relay
Agent, it means that there is no active lease for the IP address
present in the DHCP server, but that a server does in fact manage
that IP address. Layer 2 Relay Agent SHOULD cache this information
for later use.
7.2.5.2. Handling DHCPLEASEUNKNOWN Reply Message
When a DHCPLEASEUNKNOWN message is received by Layer 2 Relay Agent,
it SHOULD cache this information but only for a short lifetime,
approximately for 5 minutes as suggested in RFC 4388 [5].
7.2.5.3. Handling DHCPLEASEACTIVE Reply Message
When Layer 2 Relay Agent receives a DHCPLEASEACTIVE message, it MUST
update its location/lease information.
7.2.5.4. Handling multiple responses for DHCPLEASEQUERY Message
A Layer 3 Relay Agent can forward a DHCPLEASEQUERY request to more
than one DHCP server and so a Layer 2 Relay Agent may receive more
Joshi, et al. Expires August 13, 2007 [Page 13]
Internet-Draft Layer 2 Relay Agent February 2007
than one reply for a DHCPLEASEQUERY message.
A Layer 2 Relay Agent MUST be able to process multiple responses for
a DHCPLEASEQUERY message. For example:
o It should be able to ignore all other responses once it receives
DHCPLEASEACTIVE response from one of the DHCP server.
7.2.5.5. Handling No Response to the DHCPLEASEQUERY Message
This has been discussed in detail in RFC 4388 [5] and the same holds
good for this document as well.
7.2.5.6. Handling DHCPLEASEQUERY messages not belonging to Layer 2
Relay Agent
o Since Layer 3 Relay Agent can broadcast the reply of
DHCPLEASEQUERY message, it will be processed by all the Layer 2
Relay Agents connected to the same LAN. Using either Transaction
Id or Relay Agent Information Option, a Layer 2 Relay Agent should
be able to correctly identify if the DHCPLEASEQUERY response is
meant for itself. Responses which does not belong to an Access
Concentrator MUST be silently discarded.
o In a typical bridged network, multiple Layer 2 Relay Agents may
share the same LAN. As DHCPLEASEQUERY message generated by a
Layer 2 Relay Agent is broadcast, it will be received by other
Layer 2 Relay Agent also. Layer 2 Relay Agents MUST silently
discard any DHCPLEASEQUERY message received on its upstream
interface.
7.3. DHCPLEASEQUERY using Management IP address of Layer 2 Relay Agent
Though rare, but if a Layer 2 Relay Agent allows the use of
Management IP address for communication with DHCP server, it can
generate DHCPLEASEQUERY message as described in RFC 4388 instead of
using the extension of DHCPLEASEQUERY message described in this
document.
Joshi, et al. Expires August 13, 2007 [Page 14]
Internet-Draft Layer 2 Relay Agent February 2007
8. Prevention of flooding of DHCP replies from Layer 3 Relay Agent
Figure 1 shows an example where each access concentrator adds the
relay agent information option containing the port information of the
host sending the DHCP messages and the IP edge router relays the DHCP
messages.
RFC 2131[2] defines the meaning of the broadcast flag in the flags
field: it indicates whether the client wishes to receive the
DHCPOFFER and DHCPACK message as a broadcast or a unicast from the
DHCP server or the DHCP relay agent. In the scenario of Figure 1,
this means that the IP edge router will broadcast the DHCPOFFER and
DHCPACK messages to all access concentrators if the broadcast flag is
set. Whether or not broadcast is used between the Layer 3 Relay
Agent and the trusted Layer 2 Relay Agents depends on the behavior of
the DHCP clients. However broadcasts in the aggregation network are
to be avoided. So it is preferred to always use unicast from the
Layer 3 DHCP relay agent to the trusted layer 2 DHCP relay agent.
Between the trusted layer 2 DHCP relay agent and the host, broadcast
flag has to be honored.
Even though the DHCP clients are not setting the broadcast flag, it
is still possible that the DHCPOFFER and DHCPACK messages from the
DHCP server are sent to all access concentrators. This is when the
access concentrator implements a MAC concentration or MAC translation
function. When such a MAC operation is performed, the access
concentrator replaces the source MAC address of all upstream frames
by another MAC address, for instance with its own MAC address. In
this case, the MAC addresses of the hosts will remain unknown in the
network between the trusted layer 2 DHCP relay agent and the Layer 3
DHCP relay agent. Hence all unicast messages sent by the Layer 3
DHCP relay agent using this MAC address will be flooded to all access
concentrators.
8.1. Flooding of DHCP reply messages from Layer 3 Relay Agent
To overcome these two previously mentioned problems, a new sub-option
'unicast-address' is defined for the Relay Agent Information option.
With this sub-option, the Layer 3 Relay Agent will always unicast the
messages towards the trusted Layer 2 Relay Agent with a hardware
address that is known in the network.
8.1.1. Unicast-Address Sub-Option
8.1.1.1. Unicast-Address Sub-Option Definition
The unicast-address sub-option of the relay-agent-information option
MAY be used by any trusted layer 2 DHCP relay agent such that the
Joshi, et al. Expires August 13, 2007 [Page 15]
Internet-Draft Layer 2 Relay Agent February 2007
Layer 3 relay agent unicasts the messages from the DHCP server with a
hardware address known in the network. The hardware address in the
unicast-address sub-option MUST be an address that can be used to
send unicast packets towards the client.
The format of the option is as follows:
SubOpt Len [Hardware address details]
+------+------+----------+-------------+
| X | Len | htype(1) | hwaddr |
+------+------+----------+-------------+
Figure 2
o 'X' is the sub-option code which needs to be allocated by IANA.
o 'Len' represents the length of the 'value' which includes both
htype and hwaddr fields
o "htype" represents Hardware type. See the 'ARP parameters'
maintained in the database referenced by Assigned numbers RFC 3232
[6].
o "hwaddr" is the unicast hardware address.
8.1.1.2. Layer 3 Relay Agent Behavior
When Layer 3 DHCP Relay Agent receives a DHCP packet with unicast-
address sub-option added, it SHOULD unicast that message towards the
layer 2 DHCP relay agent with destination address set to the value
contained in the hwaddr field of the sub-option. A Layer 3 relay
agent that supports this option SHOULD ignore the broadcast flag if
this sub-option is present in the DHCP message. In the absence of
this sub-option a Layer 3 relay agent SHOULD behave as earlier and
forward the message as per the broadcast bit set in the message.
8.1.1.3. Layer 2 Relay Agent Behavior
The Layer 2 Relay Agent may add this sub-option only in the case when
the intermediate network elements do MAC learning ensuring that when
the Layer 3 relay agent unicasts the messages to this hardware
address, the messages will arrive at the same layer 2 DHCP relay
agent. The Layer 2 DHCP relay agent SHOULD still be able to receive
broadcast messages from the Layer 3 DHCP relay agent in order to
remain compatible with relay agents that do not support the unicast-
address sub-option.
Layer 2 DHCP relay agent MUST always process the broadcast flag as
Joshi, et al. Expires August 13, 2007 [Page 16]
Internet-Draft Layer 2 Relay Agent February 2007
described in [RFC2131]. This means that it is possible that the
layer 2 DHCP relay agents receive a unicast message from the Layer 3
DHCP relay agent, and that it has to forward it as a broadcast. It
is also possible that the unicast message stays unicast and that only
the destination MAC address has to be changed to the content of the
chaddr field.
If the layer 2 DHCP relay agent performs a MAC address concentration
function, it SHOULD add the unicast-address sub-option to all
upstream DHCP messages in order to avoid flooding of unknown
destination MAC addresses. On the other hand, if the layer 2 DHCP
relay agent acts as a bridge, it MAY add the unicast-address sub-
option only to the DHCPDISCOVER and DHCPREQUEST messages as these are
the only messages which may result in a downstream broadcast.
8.1.1.4. DHCP Server Behavior
Although rather unlikely, it is also possible that no Layer 3 DHCP
relay agent is configured in the network and that the DHCP server has
layer 2 connectivity with the trusted layer 2 DHCP relay agent. In
this case the DHCP server, supporting the unicast address option,
SHOULD act as a Layer 3 DHCP relay agent would do.
So if the DHCP server receives DHCP messages with giaddr set to zero
and a valid unicast-address sub-option, the DHCP server SHOULD ignore
the broadcast flag and unicast the DHCP messages to the hardware
address in the unicast-address sub-option. The DHCP Server SHOULD
also include this sub-option in the option 82 of its reply.
8.1.1.5. Example Scenarios
In first example, the trusted layer 2 DHCP relay agent acts as a
bridge. In such a case, the layer 2 DHCP relay agent puts the MAC
address in the chaddr field of DHCP messages in the unicast-address
sub-option. The Layer 3 DHCP relay agent will then send the
DHCPOFFER and DHCPACK messages from the DHCP server as unicast to the
layer 2 DHCP relay agent, which converts the message to broadcast if
the broadcast flag is set.
In the second case Layer 2 Relay Agent does MAC translation/
concentration function.In this case layer 2 DHCP relay agent adds
unicast-address sub-option which contains the MAC address that the
Layer 2 DHCP Relay Agent is using for upstream frames.
8.2. Flooding of DHCPLEASEQUERY reply messages from Layer 3 Relay Agent
The above suboption would not work for reply message for a LEASEQUERY
request because the reply message type other than LEASEACTIVE for a
Joshi, et al. Expires August 13, 2007 [Page 17]
Internet-Draft Layer 2 Relay Agent February 2007
LEASEQUERY message will not have Relay Agent Information option.
This can be resolved by creating a new option which is echoed back by
the DHCP server in DHCP reply messages for a LEASEQUERY message.
This document need the definition of following new option for DHCP
packet beyond those defined by [RFC2131] and [RFC2132]. See also
Section 12, IANA Considerations.
8.2.1. Relay Agent Hardware Address option
"relay-agent-hwaddr" option allows a Layer 3 Relay agent to unicast a
DHCP reply for a DHCPLEASEQUERY message to the Layer 2 Relay Agent
which had generated the DHCPLEASEQUERY message. The code for this
option need to be allocated by IANA.
code [Hardware address details]
+------+------+------------+------------+
| X | len | htype (1) | hwaddr |
+------+------+------------+------------+
In the above option:
o 'X' need to be allocated by IANA.
o "len" field contains the length of the "Hardware address
details" and can be used to deduce length of "hwaddr" field.
o "htype" represents Hardware type. See the 'ARP parameters'
maintained in the database referenced by Assigned numbers RFC
3232[4].
o "hwaddr" is Relay Agent hardware address.
8.2.1.1. Layer 2 Relay Agent Behavior
Layer 2 Relay agents which can receive a unicast reply for
DHCPLEASEQUERY message SHOULD add option "relay-agent-hwaddr" in
DHCPLEASEQUERY message. Option "relay-agent-hwaddr" SHOULD be
populated based on the interface on which this request is sent out.
8.2.1.2. Layer 3 Relay Agent Behavior
While forwarding a reply for Lease Query request, a Layer 3 Relay
Agent MUST look for "relay-agent-hwaddr" option [code 'X'] in the
DHCP reply and if it finds this option, it SHOULD extract the
hardware address and use it to unicast the reply to the Layer 2 Relay
Agent.
Joshi, et al. Expires August 13, 2007 [Page 18]
Internet-Draft Layer 2 Relay Agent February 2007
DHCP reply message with message type 'DHCPLEASEACTIVE' can have Relay
Agent Information option which may have 'unicast-address' sub-option.
In such a case, both 'relay-agent-hwaddr' option and 'unicast-
address' sub-option MAY be present. A Layer 3 Relay Agent conforming
to this document MUST always prefer hardware address extracted from
'unicast-address' sub-option of Relay Agent Information option over
'relay-agent-hwaddr' option.
8.2.1.3. DHCP server Behavior
DHCP servers conforming to this document MUST echo the entire
contents of the "relay-agent-hwaddr" option [code 'X'] in the reply
for a DHCPLEASEQUERY request. DHCP servers SHALL NOT place the
echoed "relay-agent-hwaddr" option in the overloaded sname or file
fields. If a server is unable to copy a full "relay-agent-hwaddr"
option into a response, it SHALL send the response without the
"relay-agent-hwaddr" option, and SHOULD increment an error counter
for the situation.
DHCP Server MUST NOT add or echo back this option in any other DHCP
reply messages it generates.
Joshi, et al. Expires August 13, 2007 [Page 19]
Internet-Draft Layer 2 Relay Agent February 2007
9. Acknowledgments
Stig Venaas, Wojciech Dec, Richard Pruss and Andre Kostur provided
good feedback on this memo. A detailed discussion with Ted Lemon,
Andre Kostur on how a Layer 3 Relay Agent can unicast the various
DHCP replies to a Layer 2 Relay Agent was very helpful.
The authors would like to acknowledge Ludwig Pauwels and Paul
Reynders for their feedback on 'unicast-address' sub-option. Thanks
to Patrick Mensch who contributed for the initial version of the
document which had defined 'unicast-address' sub-option.
Description of authentication for DHCPLEASEQUERY messages in security
section are taken from RFC 4388.
Joshi, et al. Expires August 13, 2007 [Page 20]
Internet-Draft Layer 2 Relay Agent February 2007
10. Security Consideration
o Layer 3 Relay Agent that relays the DHCP message are essentially
DHCP clients for the purposes of the DHCP messages relayed by
Layer 2 Relay Agent. Layer 3 Relay Agent MUST relay a DHCP
message only when it comes from a trusted circuit. Thus,
RFC3118[4] is an appropriate mechanism for DHCP messages relayed
by Layer 2 Relay Agent.
o This document suggest new option which MAY be added by Layer 2
Relay Agents in DHCP message. If a server finds this new option
included in a received message, the server MUST compute any hash
function as if the option were NOT included in the message without
changing the order of options. Whenever the server sends back
this option to a relay agent, the server MUST not include this
option in the computation of any hash function over the message.
Joshi, et al. Expires August 13, 2007 [Page 21]
Internet-Draft Layer 2 Relay Agent February 2007
11. IANA Considerations
This document needs IANA to provide a unique number for the new
option to carry Hardware address of a Relay Agent. Please refer to
section 8.1 for more details.
This document also needs IANA to provide a unique number for the
following new suboptions in Relay Agent Information option [Option
82]:
o To carry the hardware address of a Relay Agent. Please refer to
section 8.2 for more details.
Joshi, et al. Expires August 13, 2007 [Page 22]
Internet-Draft Layer 2 Relay Agent February 2007
12. References
12.1. Normative Reference
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
January 2001.
[4] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
[5] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol
(DHCP) Leasequery", RFC 4388, February 2006.
[6] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002.
[7] Joshi, B. and P. Kurapati, "Relay Chaining in DHCPv4",
draft draft-kurapati-dhc-relay-chaining-dhcpv4-00.txt,
February 2007.
12.2. Informative Reference
[8] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)",
RFC 951, September 1985.
[9] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, October 1993.
[10] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
Joshi, et al. Expires August 13, 2007 [Page 23]
Internet-Draft Layer 2 Relay Agent February 2007
Authors' Addresses
Bharat Joshi
Infosys Technologies Ltd.
44 Electronics City, Hosur Road
Bangalore 560 100
India
Email: bharat_joshi@infosys.com
URI: http://www.infosys.com/
Pavan Kurapati
Infosys Technologies Ltd.
44 Electronics City, Hosur Road
Bangalore 560 100
India
Email: pavan_kurapati@infosys.com
URI: http://www.infosys.com/
Mukund Kamath
Infosys Technologies Ltd.
44 Electronics City, Hosur Road
Bangalore 560 100
India
Email: mukund_kamath@infosys.com
URI: http://www.infosys.com/
Stefaan De Cnodder
Alcatel-Lucent
Francis Wellesplein 1,
B-2018 Antwerp
Belgium
Email: stefaan.de_cnodder@alcatel-lucent.be
URI: http://www.alcatel-lucent.com
Joshi, et al. Expires August 13, 2007 [Page 24]
Internet-Draft Layer 2 Relay Agent February 2007
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Joshi, et al. Expires August 13, 2007 [Page 25]