< draft-joshi-dhc-layer2-relay-agent-00.txt   draft-joshi-dhc-layer2-relay-agent-01.txt >
DHC Working Group B. Joshi DHC Working Group B. Joshi
Internet-Draft P. Kurapati Internet-Draft P. Kurapati
Expires: August 13, 2007 M. Kamath Expires: December 16, 2007 M. Kamath
Infosys Technologies Ltd. Infosys Technologies Ltd.
S. De Cnodder S. De Cnodder
Alcatel-Lucent Alcatel-Lucent
February 9, 2007 June 14, 2007
Layer 2 Relay Agent Layer 2 Relay Agent
draft-joshi-dhc-layer2-relay-agent-00.txt draft-joshi-dhc-layer2-relay-agent-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2007. This Internet-Draft will expire on December 16, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
In Layer 2 Access Networks, Access Concentrators are present between In Layer 2 Access Networks, Access Concentrators are present between
DHCP Clients and Relay Agent. In this case, the Relay Agent can not 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 uniquely identify the end host and hence can not add unique 'Relay
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Information option in the DHCP message. Access concentrators do not Information option in the DHCP message. Access concentrators do not
set the 'giaddr' field. Access Concentrators in this mode are set the 'giaddr' field. Access Concentrators in this mode are
typically known as Layer 2 Relay agents. typically known as Layer 2 Relay agents.
This document provides insight to the behavior of the Access This document provides insight to the behavior of the Access
Concentrators which act as DHCP Layer 2 Relay Agents in Access Concentrators which act as DHCP Layer 2 Relay Agents in Access
Networks. Networks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Layer 2 Relay Agent . . . . . . . . . . . . . . . . . . . . . 7 3. Layer 2 Relay Agent . . . . . . . . . . . . . . . . . . . . . 6
4. Handling DHCP messages in Layer 2 Relay Agent . . . . . . . . 8 4. Handling DHCP messages in Layer 2 Relay Agent . . . . . . . . 7
4.1. Handling Broadcast DHCP messages . . . . . . . . . . . . . 8 4.1. Handling Broadcast DHCP messages . . . . . . . . . . . . . 7
4.2. Handling Unicast DHCP messages . . . . . . . . . . . . . . 8 4.2. Handling Unicast DHCP messages . . . . . . . . . . . . . . 7
5. Handling DHCP messages in Layer 3 Relay Agent . . . . . . . . 9 5. Handling DHCP messages in Layer 3 Relay Agent . . . . . . . . 8
6. Handling DHCP messages in DHCP server . . . . . . . . . . . . 10 6. Handling DHCP messages in DHCP server . . . . . . . . . . . . 9
7. Extension of DHCPLEASEQUERY for Layer 2 Relay Agent . . . . . 11 7. Extension of DHCPLEASEQUERY for Layer 2 Relay Agent . . . . . 10
7.1. Protocol Extension Overview . . . . . . . . . . . . . . . 11 7.1. Protocol Extension Overview . . . . . . . . . . . . . . . 10
7.1.1. Lease/Location information in layer 2 Networks . . . . 11 7.2. Protocol Extension Details . . . . . . . . . . . . . . . . 10
7.1.2. Extension of DHCPLEASEQUERY in layer 2 Networks . . . 11 7.2.1. Generating DHCPLEASEQUERY Message . . . . . . . . . . 10
7.2. Protocol Extension Details . . . . . . . . . . . . . . . . 11
7.2.1. Generating DHCPLEASEQUERY Message . . . . . . . . . . 11
7.2.2. Handling DHCPLEASEQUERY Message in Layer 3 Relay 7.2.2. Handling DHCPLEASEQUERY Message in Layer 3 Relay
Agent . . . . . . . . . . . . . . . . . . . . . . . . 12 Agent . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2.3. Handling DHCPLEASEQUERY Message in DHCP Server . . . . 13 7.2.3. Handling DHCPLEASEQUERY Message in DHCP Server . . . . 11
7.2.4. Handling DHCP Reply Message in Layer 3 Relay Agent . . 13 7.2.4. Handling DHCP Reply Message in Layer 3 Relay Agent . . 12
7.2.5. Handling DHCP Reply Message in Layer 2 Relay Agent . . 13 7.2.5. Handling DHCP Reply Message in Layer 2 Relay Agent . . 12
7.3. DHCPLEASEQUERY using Management IP address of Layer 2 7.3. DHCPLEASEQUERY using Management IP address of Layer 2
Relay Agent . . . . . . . . . . . . . . . . . . . . . . . 14 Relay Agent . . . . . . . . . . . . . . . . . . . . . . . 13
8. Prevention of flooding of DHCP replies from Layer 3 Relay 8. Prevention of flooding of DHCP replies from Layer 3 Relay
Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Flooding of DHCP reply messages from Layer 3 Relay 8.1. Flooding of DHCP reply messages from Layer 3 Relay
Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1.1. Unicast-Address Sub-Option . . . . . . . . . . . . . . 15 8.1.1. Unicast-Address Sub-Option . . . . . . . . . . . . . . 14
8.2. Flooding of DHCPLEASEQUERY reply messages from Layer 3 8.2. Flooding of DHCPLEASEQUERY reply messages from Layer 3
Relay Agent . . . . . . . . . . . . . . . . . . . . . . . 17 Relay Agent . . . . . . . . . . . . . . . . . . . . . . . 16
8.2.1. Relay Agent Hardware Address option . . . . . . . . . 18 8.2.1. Relay Agent Hardware Address option . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. Security Consideration . . . . . . . . . . . . . . . . . . . . 21 10. Security Consideration . . . . . . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative Reference . . . . . . . . . . . . . . . . . . . 23 12.1. Normative Reference . . . . . . . . . . . . . . . . . . . 22
12.2. Informative Reference . . . . . . . . . . . . . . . . . . 23 12.2. Informative Reference . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 24
1. Introduction 1. Introduction
In Access Networks, Service Providers have been deploying DHCP to DHCP Relay Agents eliminate the necessity of having a DHCP server on
dynamically configure the end hosts. DHCP Relay Agents eliminate the each physical network. RFC 3046 defines a new option 'Relay Agent
necessity of having a DHCP server on each physical network. RFC 3046 Information' which is added to DHCP messages by Relay Agents. DHCP
defines a new option 'Relay Agent Information' which is added to DHCP servers may use this option for IP address and other parameter
messages by Relay Agents. DHCP servers may use this option for IP assignment policies.
address and other parameter assignment policies.
In case of Layer 2 Access Networks, Access Concentrators typically In case of Layer 2 Access Networks, Access Concentrators typically
act as a transparent bridge. They act as DHCP relay agents by adding act as a transparent bridge. They act as DHCP relay agents by adding
'Relay Agent Information' option since they are closer to the 'Relay Agent Information' option since they are closer to the
subscribers. The first Layer 3 device connected to Access subscribers. The first Layer 3 device connected to Access
Concentrator acts as Layer 3 Relay agent which relays the DHCP Concentrator acts as Layer 3 Relay agent which relays the DHCP
messages between DHCP clients and DHCP servers. messages between DHCP clients and DHCP servers.
This document describes a typical Layer 2 Access Network and how a This document describes a typical Layer 2 Access Network and how a
Layer 2 Relay Agent works. It later describes the need for Layer 2 Relay Agent works. It later describes the need for
skipping to change at page 6, line 22 skipping to change at page 5, line 22
there is a need to identify a "Uplink Port", through which the DHCP 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 messages are relayed to the DHCP server, through a Layer 3 DHCP relay
agent. The uplink port SHOULD be a configurable parameter on the agent. The uplink port SHOULD be a configurable parameter on the
Layer 2 DHCP relay agent. This will prevent an unnecessary flooding 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. of DHCP messages to all the ports which are a part of the same VLAN.
o "Unnumbered Interfaces" o "Unnumbered Interfaces"
An interface with no IP address associated with it. IP packets An interface with no IP address associated with it. IP packets
received on this interface will be processed like any other numbered received on this interface will be processed like any other numbered
IP interface. It may use a local IP address of another interface IP interface. It may use a local IP address while generating IP
while forwarding packets. packets.
3. Layer 2 Relay Agent 3. Layer 2 Relay Agent
In Access Networks, an Access Concentrator acting as Transparent In Access Networks, an Access Concentrator acting as Transparent
Bridge can also act as a Layer 2 DHCP Relay Agent. In figure 1, 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 Layer 3 Relay Agent can not uniquely identify the end hosts so the
Access Concentrator needs to append Relay Agent Information [option Access Concentrator needs to append Relay Agent Information [option
82] to each DHCP packet before forwarding it to Layer 3 Relay Agent. 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 When a DHCP reply is received, Layer 2 Relay Agent may use the Relay
Agent option [option 82] to identify the outgoing interface and Agent option [option 82] to identify the outgoing interface. It
removes the Relay Agent Information option before forwarding DHCP removes the Relay Agent Information option before forwarding DHCP
reply to end hosts. reply to end hosts.
+-------+ +-------+
+-----+ | | +-----+ | |
|Host1|-------| | |Host1|-------| |
+-----+ |Access | +-----+ |Access |
|Concen-|-----...... |Concen-|-----......
+-----+ |trator | . +-----+ |trator | .
|Host2|-------| #1 | . +------+ |Host2|-------| #1 | . +------+
skipping to change at page 8, line 19 skipping to change at page 7, line 19
When a DHCP message is received from the DHCP client, the Layer 2 When a DHCP message is received from the DHCP client, the Layer 2
Relay Agent SHOULD add the Relay Agent Information (option 82 as Relay Agent SHOULD add the Relay Agent Information (option 82 as
described in RFC 3046 [3]) and forward it towards the DHCP server. 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 The Layer 2 Relay Agent MUST NOT populate the 'giaddr' field in the
DHCP message. 'Relay Agent Information' option SHALL be added as 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 last option, just before the END option (FF) as described in RFC 3046
[3]. [3].
If a Layer 2 Relay Agent receives a DHCP message that already If a Layer 2 Relay Agent receives a DHCP message that already
contains a Relay Agent Information option, the Layer 2 Relay Agent contains a Relay Agent Information option, the Layer 2 Relay Agent
may discard this packet if the interface on which is was received is may discard this packet if the interface on which it was received is
untrusted. Otherwise, if the interface is trusted, then the DHCP untrusted. Otherwise, if the interface is trusted, then the DHCP
packet should be forwarded as it is towards the DHCP server. packet should be forwarded as it is towards the DHCP server.
When the reply message is received from a server, the Relay Agent When the reply message is received from a server, the Relay Agent
Information option MAY be verified. A Layer 2 Relay Agent MAY Information option may be verified. A Layer 2 Relay Agent MAY
silently discard the packet if it had not added the Relay Agent silently discard the packet if it had not added the Relay Agent
Information option. Relay Agent Information MAY be used to identify Information option. Relay Agent Information may be used to identify
the outgoing interface. The relay agent information MUST be removed the outgoing interface. The relay agent information MUST be removed
before the reply message is forwarded to the DHCP client. before the reply message is forwarded to the DHCP client.
4.2. Handling Unicast DHCP messages 4.2. Handling Unicast DHCP messages
DHCP Clients unicast RENEW, RELEASE and INFORM messages directly to DHCP Clients unicast RENEW, RELEASE and INFORM messages directly to
the DHCP server. Similar to a Layer 3 Relay Agent, a Layer 2 Relay 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 Agent does not intercept the unicast DHCP messages and so does not
add any Relay Agent Information option to unicast messages. add any Relay Agent Information option to unicast messages.
Some existing implementations maintain lease/location informations Some existing implementations maintain lease/location informations
for each DHCP client. These implementations snoop unicast DHCP for each DHCP client. These implementations snoop unicast DHCP
messages to keep the lease/location information updated. So a Layer messages to keep the lease/location information updated. So a Layer
2 Relay Agent adds Relay Agent Information option to unicast DHCP 2 Relay Agent adds Relay Agent Information option to unicast DHCP
messages as well. Layer 3 Relay Agent and DHCP server process them messages as well. Layer 3 Relay Agent and DHCP server process them
similar to the broadcast messages as described above in section 4.1. similar to the way they handle other unicast DHCP messages.
5. Handling DHCP messages in Layer 3 Relay Agent 5. Handling DHCP messages in Layer 3 Relay Agent
When Layer 3 Relay Agent receives a DHCP message from Layer 2 Relay When Layer 3 Relay Agent receives a DHCP message from Layer 2 Relay
Agent, it does following: Agent, it does following:
o If the DHCP message contains option 82 and 'giaddr' field is set 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 to zero, and has been received from a trusted circuit, Layer 3
Relay Agent forwards the packet per normal DHCP relay agent Relay Agent forwards the packet per normal DHCP relay agent
operations, setting the giaddr field as it deems appropriate. But operations, setting the giaddr field as it deems appropriate. But
if such a DHCP message is received from an untrusted interface, if such a DHCP message is received from an untrusted interface, it
Relay Agent SHALL discard the packet. SHALL discard the packet.
o If the DHCP message does not contain any option 82, the processing 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. of packet MUST be done as per RFC 2131 [2] and RFC 3046 [3].
Layer 3 Relay Agent needs to forward replies of such DHCP messages A Layer 3 Relay Agent needs to forward replies of such DHCP messages
towards only that Layer 2 Relay Agent which had relayed the DHCP 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 message to the Layer 3 Relay Agent. This means that the Layer 3
Agent needs a mechanism using which it can identify the outgoing Relay Agent needs a mechanism using which it can identify the
interface for the DHCP replies. A Layer 3 Relay Agent can achieve it outgoing interface for the DHCP replies. A Layer 3 Relay Agent can
in following ways: achieve it in the following ways:
o A layer 3 relay agent can populate the 'giaddr' field in such a 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 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 destination IP address of the DHCP reply message to identify
the outgoing interface. For example, it can use the primary IP the outgoing interface. For example, it can use the primary IP
Address of the interface as 'giaddr' on which it had received the Address of the interface as 'giaddr' on which it had received the
DHCP message. DHCP message.
o The above method will not work if a Layer 3 Relay Agent uses 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 "unnumbered interface". In this case, a Layer 3 Relay Agent can
skipping to change at page 10, line 7 skipping to change at page 9, line 7
* The above solution will not scale up if there are multiple * The above solution will not scale up if there are multiple
unnumbered interfaces. It will also not work if there are unnumbered interfaces. It will also not work if there are
multiple Relay Agents between DHCP Clients and server. This multiple Relay Agents between DHCP Clients and server. This
issue can be resolved if intermediate Relay Agents support issue can be resolved if intermediate Relay Agents support
Relay Chaining [7]. With Relay Chaining, each Relay Agent can Relay Chaining [7]. With Relay Chaining, each Relay Agent can
add Relay Agent Information option which can be used to add Relay Agent Information option which can be used to
identify outgoing interface to forward the reply message. identify outgoing interface to forward the reply message.
6. Handling DHCP messages in DHCP server 6. Handling DHCP messages in DHCP server
There are no changes suggested in DHCP server functionality to This document does not suggest any changes to the functioning of the
support Layer 2 Relay Agent. DHCP server to support the layer 2 relay agent.
7. Extension of DHCPLEASEQUERY for Layer 2 Relay Agent 7. Extension of DHCPLEASEQUERY for Layer 2 Relay Agent
7.1. Protocol Extension Overview 7.1. Protocol Extension Overview
7.1.1. Lease/Location information in layer 2 Networks A Layer 2 Relay Agent may want to maintain the information of
outgoing interface, MAC Address, IP address and Lease information for
Layer 2 Relay Agents snoop all DHCP messages and maintain the each DHCP Client. This information [MAC-IP-Interface Binding] could
information of outgoing interface, MAC Address, IP address and Lease be used to prevent MAC/IP Spoofing attacks. It could also be used
information for each DHCP Client. This information [MAC-IP-Interface for bridging frames. In this case, it needs to snoop all DHCP
Binding] may be used to prevent MAC/IP Spoofing attacks and may also messages to keep this information updated. Maintaing this
be used for bridging frames. information makes a Layer 2 Relay Agent vulnerable to the same issue
[location/lease information lost when Layer 2 Relay Agent gets
7.1.2. Extension of DHCPLEASEQUERY in layer 2 Networks rebooted] which has been addressed in RFC 4388 [5] for Layer 3
networks. This document extends mechanism proposed in [5] to address
Layer 2 Relay Agents acting as Transparent Bridge typically maintain this issue for layer 2 networks.
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 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. location/lease information to verify the IP address or MAC address.
If the location/lease information is not available, it can query DHCP If the location/lease information is not available, it can query DHCP
server to obtain the lease/location information using DHCPLEASEQUERY server to obtain the lease/location information using DHCPLEASEQUERY
message. message.
Layer 2 Relay Agent can generate a DHCPLEASEQUERY [Query by IP A Layer 2 Relay Agent can generate a DHCPLEASEQUERY [Query by IP
address, MAC address or client identifier [10]] with all the fields address, MAC address or client identifier [10]] with all the fields
properly populated as defined in RFC 4388 [5]. properly populated as defined in RFC 4388 [5].
7.2. Protocol Extension Details 7.2. Protocol Extension Details
7.2.1. Generating DHCPLEASEQUERY Message 7.2.1. Generating DHCPLEASEQUERY Message
When a data packet is received from a host, Layer 2 Relay Agent may 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 verify if it has location/lease information for the source IP address
or source MAC address of data packet received. Similarly when Layer or source MAC address of data packet received. Similarly when Layer
2 Relay Agent receives a data packet from upstream interface, it may 2 Relay Agent receives a data packet from the uplink port, it may
verify location/lease information for the destination IP address or verify location/lease information for the destination IP address or
destination MAC address of the data packet. A Layer 2 Relay Agent destination MAC address of the data packet. A Layer 2 Relay Agent
would typically generate DHCPLEASEQUERY message if the location/lease would typically generate DHCPLEASEQUERY message if the location/lease
information is not available for the corresponding IP address or MAC information is not available for the corresponding IP address or MAC
address assuming that it has lost the location/lease information address assuming that it has lost the location/lease information
during last reboot. The DHCPLEASEQUERY message uses the DHCP message during last reboot. The DHCPLEASEQUERY message uses the DHCP message
format as described in RFC 2131 [2], and uses message number 10 in format as described in RFC 2131 [2], and uses message number 10 in
the DHCP Message Type option (option 53). The DHCPLEASEQUERY message the DHCP Message Type option (option 53). The DHCPLEASEQUERY message
has the following pertinent message contents: has the following pertinent message contents:
skipping to change at page 13, line 32 skipping to change at page 12, line 24
message or it had relayed it for a Layer 2 Relay Agent. 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 When the DHCP Reply message is received, a Layer 3 Relay Agent MAY
use 'giaddr', 'state information' or Relay Agent Information option use 'giaddr', 'state information' or Relay Agent Information option
to identify the outgoing interface. to identify the outgoing interface.
7.2.5. Handling DHCP Reply Message in Layer 2 Relay Agent 7.2.5. Handling DHCP Reply Message in Layer 2 Relay Agent
7.2.5.1. Handling DHCPLEASEUNASSIGNED Reply Message 7.2.5.1. Handling DHCPLEASEUNASSIGNED Reply Message
When a DHCPLEASEUNASSIGNED message is received by Layer 2 Relay When a DHCPLEASEUNASSIGNED message is received by a Layer 2 Relay
Agent, it means that there is no active lease for the IP address 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 present in the DHCP server, but that a server does in fact manage
that IP address. Layer 2 Relay Agent SHOULD cache this information that IP address. Layer 2 Relay Agent SHOULD cache this information
for later use. for later use.
7.2.5.2. Handling DHCPLEASEUNKNOWN Reply Message 7.2.5.2. Handling DHCPLEASEUNKNOWN Reply Message
When a DHCPLEASEUNKNOWN message is received by Layer 2 Relay Agent, When a DHCPLEASEUNKNOWN message is received by Layer 2 Relay Agent,
it SHOULD cache this information but only for a short lifetime, it SHOULD cache this information but only for a short lifetime,
approximately for 5 minutes as suggested in RFC 4388 [5]. approximately for 5 minutes as suggested in RFC 4388 [5].
skipping to change at page 14, line 25 skipping to change at page 13, line 18
good for this document as well. good for this document as well.
7.2.5.6. Handling DHCPLEASEQUERY messages not belonging to Layer 2 7.2.5.6. Handling DHCPLEASEQUERY messages not belonging to Layer 2
Relay Agent Relay Agent
o Since Layer 3 Relay Agent can broadcast the reply of o Since Layer 3 Relay Agent can broadcast the reply of
DHCPLEASEQUERY message, it will be processed by all the Layer 2 DHCPLEASEQUERY message, it will be processed by all the Layer 2
Relay Agents connected to the same LAN. Using either Transaction Relay Agents connected to the same LAN. Using either Transaction
Id or Relay Agent Information Option, a Layer 2 Relay Agent should Id or Relay Agent Information Option, a Layer 2 Relay Agent should
be able to correctly identify if the DHCPLEASEQUERY response is be able to correctly identify if the DHCPLEASEQUERY response is
meant for itself. Responses which does not belong to an Access meant for itself. Responses which do not belong to an Access
Concentrator MUST be silently discarded. Concentrator MUST be silently discarded.
o In a typical bridged network, multiple Layer 2 Relay Agents may o In a typical bridged network, multiple Layer 2 Relay Agents may
share the same LAN. As DHCPLEASEQUERY message generated by a share the same LAN. As a DHCPLEASEQUERY message generated by a
Layer 2 Relay Agent is broadcast, it will be received by other Layer 2 Relay Agent is broadcast, it will be received by other
Layer 2 Relay Agent also. Layer 2 Relay Agents MUST silently Layer 2 Relay Agents also. Layer 2 Relay Agents MUST silently
discard any DHCPLEASEQUERY message received on its upstream discard any DHCPLEASEQUERY message received from the uplink port.
interface.
7.3. DHCPLEASEQUERY using Management IP address of Layer 2 Relay Agent 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 Though rare, but if a Layer 2 Relay Agent allows the use of
Management IP address for communication with DHCP server, it can Management IP address for communication with DHCP server, it can
generate DHCPLEASEQUERY message as described in RFC 4388 instead of generate DHCPLEASEQUERY message as described in RFC 4388 instead of
using the extension of DHCPLEASEQUERY message described in this using the extension of DHCPLEASEQUERY message described in this
document. document.
8. Prevention of flooding of DHCP replies from Layer 3 Relay Agent 8. Prevention of flooding of DHCP replies from Layer 3 Relay Agent
skipping to change at page 17, line 35 skipping to change at page 16, line 35
SHOULD act as a Layer 3 DHCP relay agent would do. SHOULD act as a Layer 3 DHCP relay agent would do.
So if the DHCP server receives DHCP messages with giaddr set to zero 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 and a valid unicast-address sub-option, the DHCP server SHOULD ignore
the broadcast flag and unicast the DHCP messages to the hardware the broadcast flag and unicast the DHCP messages to the hardware
address in the unicast-address sub-option. The DHCP Server SHOULD address in the unicast-address sub-option. The DHCP Server SHOULD
also include this sub-option in the option 82 of its reply. also include this sub-option in the option 82 of its reply.
8.1.1.5. Example Scenarios 8.1.1.5. Example Scenarios
In first example, the trusted layer 2 DHCP relay agent acts as a o The trusted layer 2 DHCP relay agent acts as a bridge. In such a
bridge. In such a case, the layer 2 DHCP relay agent puts the MAC case, the layer 2 DHCP relay agent puts the MAC address in the
address in the chaddr field of DHCP messages in the unicast-address chaddr field of DHCP messages in the unicast-address sub-option.
sub-option. The Layer 3 DHCP relay agent will then send the The Layer 3 DHCP relay agent will then send the DHCPOFFER and
DHCPOFFER and DHCPACK messages from the DHCP server as unicast to the DHCPACK messages from the DHCP server as unicast to the layer 2
layer 2 DHCP relay agent, which converts the message to broadcast if DHCP relay agent, which converts the message to broadcast if the
the broadcast flag is set. broadcast flag is set.
In the second case Layer 2 Relay Agent does MAC translation/ o The Layer 2 Relay Agent does MAC translation/concentration
concentration function.In this case layer 2 DHCP relay agent adds function. In this case layer 2 DHCP relay agent adds unicast-
unicast-address sub-option which contains the MAC address that the address sub-option which contains the MAC address that the Layer 2
Layer 2 DHCP Relay Agent is using for upstream frames. DHCP Relay Agent is using for upstream frames.
8.2. Flooding of DHCPLEASEQUERY reply messages from Layer 3 Relay Agent 8.2. Flooding of DHCPLEASEQUERY reply messages from Layer 3 Relay Agent
The above suboption would not work for reply message for a LEASEQUERY The above suboption would not work for reply message for a LEASEQUERY
request because the reply message type other than LEASEACTIVE for a request because the reply message type other than LEASEACTIVE for a
LEASEQUERY message will not have Relay Agent Information option. LEASEQUERY message will not have Relay Agent Information option.
This can be resolved by creating a new option which is echoed back by 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. the DHCP server in DHCP reply messages for a LEASEQUERY message.
This document need the definition of following new option for DHCP This document need the definition of following new option for DHCP
packet beyond those defined by [RFC2131] and [RFC2132]. See also packet beyond those defined by [RFC2131] and [RFC2132]. See also
Section 12, IANA Considerations. Section 11, IANA Considerations.
8.2.1. Relay Agent Hardware Address option 8.2.1. Relay Agent Hardware Address option
"relay-agent-hwaddr" option allows a Layer 3 Relay agent to unicast a "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 DHCP reply for a DHCPLEASEQUERY message to the Layer 2 Relay Agent
which had generated the DHCPLEASEQUERY message. The code for this which had generated the DHCPLEASEQUERY message. The code for this
option need to be allocated by IANA. option need to be allocated by IANA.
code [Hardware address details] code [Hardware address details]
+------+------+------------+------------+ +------+------+------------+------------+
skipping to change at page 18, line 39 skipping to change at page 17, line 39
details" and can be used to deduce length of "hwaddr" field. details" and can be used to deduce length of "hwaddr" field.
o "htype" represents Hardware type. See the 'ARP parameters' o "htype" represents Hardware type. See the 'ARP parameters'
maintained in the database referenced by Assigned numbers RFC maintained in the database referenced by Assigned numbers RFC
3232[4]. 3232[4].
o "hwaddr" is Relay Agent hardware address. o "hwaddr" is Relay Agent hardware address.
8.2.1.1. Layer 2 Relay Agent Behavior 8.2.1.1. Layer 2 Relay Agent Behavior
Layer 2 Relay agents which can receive a unicast reply for Layer 2 Relay agents which has the capability to receive a unicast
DHCPLEASEQUERY message SHOULD add option "relay-agent-hwaddr" in reply for DHCPLEASEQUERY message SHOULD add option "relay-agent-
DHCPLEASEQUERY message. Option "relay-agent-hwaddr" SHOULD be hwaddr" in DHCPLEASEQUERY message. Option "relay-agent-hwaddr"
populated based on the interface on which this request is sent out. SHOULD be populated based on the interface on which this request is
sent out.
8.2.1.2. Layer 3 Relay Agent Behavior 8.2.1.2. Layer 3 Relay Agent Behavior
While forwarding a reply for Lease Query request, a Layer 3 Relay While forwarding a reply for Lease Query request, a Layer 3 Relay
Agent MUST look for "relay-agent-hwaddr" option [code 'X'] in the Agent MUST look for "relay-agent-hwaddr" option [code 'X'] in the
DHCP reply and if it finds this option, it SHOULD extract 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 hardware address and use it to unicast the reply to the Layer 2 Relay
Agent. Agent.
DHCP reply message with message type 'DHCPLEASEACTIVE' can have Relay DHCP reply message with message type 'DHCPLEASEACTIVE' can have Relay
skipping to change at page 23, line 27 skipping to change at page 22, line 27
[4] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages", [4] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001. RFC 3118, June 2001.
[5] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol [5] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol
(DHCP) Leasequery", RFC 4388, February 2006. (DHCP) Leasequery", RFC 4388, February 2006.
[6] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002. [6] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002.
[7] Joshi, B. and P. Kurapati, "Relay Chaining in DHCPv4", [7] Joshi, B. and P. Kurapati, "Relay Chaining in DHCPv4",
draft draft-kurapati-dhc-relay-chaining-dhcpv4-00.txt, draft draft-kurapati-dhc-relay-chaining-dhcpv4-01.txt,
February 2007. February 2007.
12.2. Informative Reference 12.2. Informative Reference
[8] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", [8] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)",
RFC 951, September 1985. RFC 951, September 1985.
[9] Wimer, W., "Clarifications and Extensions for the Bootstrap [9] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, October 1993. Protocol", RFC 1542, October 1993.
 End of changes. 34 change blocks. 
101 lines changed or deleted 93 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/