draft-ietf-dhc-l2ra-02.txt   draft-ietf-dhc-l2ra-03.txt 
DHC Working Group B. Joshi DHC Working Group B. Joshi
Internet-Draft P. Kurapati Internet-Draft P. Kurapati
Expires: April 4, 2009 Infosys Technologies Ltd. Expires: July 17, 2009 Infosys Technologies Ltd.
October 1, 2008 January 13, 2009
Layer 2 Relay Agent Information Layer 2 Relay Agent Information
draft-ietf-dhc-l2ra-02.txt draft-ietf-dhc-l2ra-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 April 4, 2009. This Internet-Draft will expire on July 17, 2009.
Copyright Notice
Copyright (c) 2009 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.
Abstract Abstract
In some networks, DHCP servers rely on Relay Agent Information option In some networks, DHCP servers rely on Relay Agent Information option
appended by Relay Agents for IP address and other parameter appended by Relay Agents for IP address and other parameter
assignment policies. This works fine when end hosts are directly assignment policies. This works fine when end hosts are directly
connected to Relay Agents. In some network configurations, one or connected to Relay Agents. In some network configurations, one or
more Layer 2 devices may reside between DHCP clients and Relay agent. more Layer 2 devices may reside between DHCP clients and Relay agent.
In these network scenarios, it is difficult to use the Relay Agent In these network scenarios, it is difficult to use the Relay Agent
Information option for IP address and other parameter assignment Information option for IP address and other parameter assignment
policies effectively. So there is a need for the device that is policies effectively. So there is a need for the device that is
closest to the end hosts to append Relay Agent Information option in closest to the end hosts to append a Relay Agent Information option
DHCP messages. These devices are typically known as Layer 2 Relay in DHCP messages. These devices are typically known as Layer 2 Relay
Agents. Agents.
This document aims to describe the network scenarios where Layer 2 This document aims to describe the network scenarios where a Layer 2
Relay Agent is in use and also how it handles DHCP messages. Relay Agent is in use and also how it handles DHCP messages.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Need of Layer 2 Relay Agent . . . . . . . . . . . . . . . . . 6 3. Need of Layer 2 Relay Agent . . . . . . . . . . . . . . . . . 6
4. Layer 2 Relay Agent in various network scenarios . . . . . . . 7 4. Layer 2 Relay Agent in various network scenarios . . . . . . . 7
4.1. DHCP server and client on same subnet . . . . . . . . . . 7 4.1. DHCP server and client on same subnet . . . . . . . . . . 7
4.1.1. Client-server interaction . . . . . . . . . . . . . . 7 4.1.1. Client-server interaction . . . . . . . . . . . . . . 7
skipping to change at page 3, line 28 skipping to change at page 4, line 4
Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Client-server interaction . . . . . . . . . . . . . . 11 4.3.1. Client-server interaction . . . . . . . . . . . . . . 11
4.3.2. Issues due to introduction of Layer 2 Relay Agent . . 13 4.3.2. Issues due to introduction of Layer 2 Relay Agent . . 13
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Consideration . . . . . . . . . . . . . . . . . . . . 15 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 17 8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 17
8.2. Informative Reference . . . . . . . . . . . . . . . . . . 17 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
DHCP Relay Agents eliminate the necessity of having a DHCP server on DHCP Relay Agents eliminate the necessity of having a DHCP server on
each physical network. Relay Agents populate the 'giaddr' field and each physical network. Relay Agents populate the 'giaddr' field and
also append the 'Relay Agent Information' option to the DHCP also append the 'Relay Agent Information' option to the DHCP
messages. DHCP servers use this option for IP address and other messages. DHCP servers use this option for IP address and other
parameter assignment policies. These DHCP Relay Agents are typically parameter assignment policies. These DHCP Relay Agents are typically
an IP routing aware device and are referred as Layer 3 Relay Agents. an IP routing aware device and are referred as Layer 3 Relay Agents.
skipping to change at page 4, line 26 skipping to change at page 4, line 26
the end hosts. These Layer 2 devices are typically operating only as the end hosts. These Layer 2 devices are typically operating only as
bridges for the network and may not have an IPv4 address on the bridges for the network and may not have an IPv4 address on the
network in question. Lacking a valid IPv4 source address, they network in question. Lacking a valid IPv4 source address, they
cannot relay packets directly to a DHCP server located on another cannot relay packets directly to a DHCP server located on another
network. These Layer 2 devices append the Relay Agent Information network. These Layer 2 devices append the Relay Agent Information
option and broadcast the DHCP message. A Layer 3 Relay Agent relays option and broadcast the DHCP message. A Layer 3 Relay Agent relays
it to the DHCP server. it to the DHCP server.
This document provides information about where a Layer 2 Relay Agent This document provides information about where a Layer 2 Relay Agent
fits in and how it is used. This document also looks at various fits in and how it is used. This document also looks at various
network scenarios with Layer 2 Relay Agent and discusses various network scenarios with Layer 2 Relay Agents and discusses various
issues caused by introduction of Layer 2 Relay Agent. issues caused by the introduction of Layer 2 Relay Agents.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the following terms: This document uses the following terms:
o "DHCP client" o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain configuration A DHCP client is an Internet host using DHCP to obtain configuration
parameters such as a network address. parameters such as a network address.
o "Layer 3 Relay Agent" o "Layer 3 Relay Agent"
A Layer 3 Relay Agent is a third-party agent that transfers Bootstrap A Layer 3 Relay Agent is a third-party agent that transfers Bootstrap
Protocol (BOOTP) and DHCP messages between clients and servers Protocol (BOOTP) and DHCP messages between clients and servers
residing on different subnets, per RFC951 [RFC951] and residing on different subnets, per [RFC951] and [RFC1542].
RFC1542[RFC1542].
o "BRAS"
BRAS or Broadband Remote Access Server is a network element which
acts as an aggregation device terminating end user sessions. BRAS is
usually the first IP edge device in Layer 2 Access Network
architecture.
o "DHCP server" o "DHCP server"
A DHCP server is an Internet host that returns configuration A DHCP server is an Internet host that returns configuration
parameters to DHCP clients. parameters to DHCP clients.
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 generated from this interface may use a local loopback address which
IP interface. It may use a local IP address while generating IP may be shared with other unnumbered interfaces.
packets.
3. Need of Layer 2 Relay Agent 3. Need of Layer 2 Relay Agent
A Layer 2 device intercepts DHCP messages for following reasons: A Layer 2 device intercepts DHCP messages for the following reasons:
1. In some network deployments like xDSL, the subscriber aggregation 1. In some network deployments like xDSL, the subscriber aggregation
devices (also known as Access Concentrator or a DSLAM in case of devices (also known as Access Concentrator or a DSLAM in case of
DSL) are configured to act as bridges. As these devices are DSL) are configured to act as bridges. As these devices are
closest to the subscriber, they are in the best position to closest to the subscriber, they are in the best position to
provide a unique Relay Agent Information option to enforce provide a unique Relay Agent Information option to enforce
policies in DHCP server. policies in the DHCP server.
2. In some network deployments, a Layer 2 device can append Relay 2. In some network deployments, a Layer 2 device can append Relay
Agent Information in DHCP messages so that it can use this Agent Information in DHCP messages so that it can use this
information to forward the DHCP Replies to the specific port on information to forward the DHCP Replies to the specific port on
which request was received. which the request was received.
3. In some networks, the Layer 2 Switch which is closest to the end 3. In some networks, the Layer 2 Switch which is closest to the end
users, snoops the DHCP messages. These switches extract DHCP users, snoops the DHCP messages. These switches extract DHCP
Lease Information and use this information to install packet Lease Information and use this information to install packet
filters. This helps in preventing the Layer 2 and Layer 3 filters. This helps in preventing Layer 2 and Layer 3 spoofing
spoofing attempts by the subscribers. A point to note here is attempts by the subscribers. A point to note here is that in
that in cases where switches maintain the Lease Information, they cases where switches maintain the Lease Information, they have to
have to intercept unicast DHCP messages as well to keep this intercept unicast DHCP messages as well to keep this information
information up to date. up to date.
4. NOTE: Please send an email to the authors if you are aware of any 4. NOTE: Please send an email to the authors if you are aware of any
other functionality of Layer 2 Relay Agent. It will be helpful other functionality of Layer 2 Relay Agent. It will be helpful
in updating this list. This note will be removed before moving in updating this list. This note will be removed before moving
it for IESG review. this draft for IESG review.
4. Layer 2 Relay Agent in various network scenarios 4. Layer 2 Relay Agent in various network scenarios
This section describes the various network scenarios where a Layer 2 This section describes the various network scenarios where a Layer 2
Relay Agent fits in. It also describes how it handles different DHCP Relay Agent fits in. It also describes how it handles different DHCP
messages. messages.
4.1. DHCP server and client on same subnet 4.1. DHCP server and client on same subnet
In certain network configurations, DHCP server may reside on the same In certain network configurations, a DHCP server may reside on the
subnet as the DHCP clients. A Layer 2 aggregation device resides same subnet as the DHCP clients. A Layer 2 aggregation device
between the DHCP clients and DHCP server. Following points describe resides between the DHCP clients and DHCP server. Following points
how this Layer 2 device handles various DHCP messages if it acts as a describe how this Layer 2 device handles various DHCP messages if it
Layer 2 Relay Agent. Figure #1 shows a typical network setup. acts as a Layer 2 Relay Agent. Figure 1 shows a typical network
setup.
+--------+ +--------+
| End | +--------+ | | End | +--------+ |
| Host#1 +-----------| | | +-----------+ | Host#1 +-----------| | | +-----------+
+--------+ | Layer +-----| | | +--------+ | Layer +-----| | |
| 2 | +-----| DHCP | | 2 | +-----| DHCP |
+--------+ | device | | | Server#1 | +--------+ | device | | | Server#1 |
| End +-----------| #1 | | +-----------+ | End +-----------| #1 | | +-----------+
| Host#2 | +--------+ | | Host#2 | +--------+ |
+--------+ | +--------+ |
skipping to change at page 7, line 47 skipping to change at page 7, line 48
+--------+ +--------+
Figure 1 Figure 1
4.1.1. Client-server interaction 4.1.1. Client-server interaction
The following summary of protocol message exchanges between clients The following summary of protocol message exchanges between clients
and DHCP servers describes how they are handled in Layer 2 Relay and DHCP servers describes how they are handled in Layer 2 Relay
Agent. Agent.
1. The client [End Host #1] broadcasts a DHCPDISCOVER message on its 1. The client (End Host #1) broadcasts a DHCPDISCOVER message on its
local physical subnet. Layer 2 Relay Agent [#1] intercepts this local physical subnet. Layer 2 Relay Agent #1 intercepts this
message, appends the Relay Agent Information option and message, appends the Relay Agent Information option and
broadcasts it to all the ports except on which it was received. broadcasts it to all the ports except the one on which it was
received. The Relay Agent Information option could be created as
Relay Agent Information option could be created as suggested in suggested in RFC 3046 [RFC3046]. The Layer 2 Relay Agent does
RFC 3046[RFC3046]. Layer 2 Relay Agent does not set the 'giaddr' not set the 'giaddr' field.
field.
2. Layer 2 device [#2] would also receive this DHCPDISCOVER message 2. Layer 2 device #2 would also receive this DHCPDISCOVER message
from Layer 2 device [#1]. If it is configured as Layer 2 Relay from Layer 2 device #1. If it is configured as Layer 2 Relay
Agent, it intercepts this message but does not append another Agent, it intercepts this message but does not append another
Relay Agent Information option to the message. It may discard Relay Agent Information option to the message. It may discard
this message if it is coming from an untrusted entity. this message if it is coming from an untrusted entity.
Otherwise, it will broadcast this on all the ports except on Otherwise, it will broadcast this on all the ports except the one
which the message was received. on which the message was received.
3. Server responds with a DHCPOFFER message after applying its local 3. The DHCP server responds with a DHCPOFFER message after applying
policies. DHCP server echoes back the Relay Agent Information its local policies. It echoes back the Relay Agent Information
option in the DHCPOFFER message. DHCP server can either unicast option in the DHCPOFFER message. The DHCP server can either
the reply to MAC address of End Host #1 or broadcast the reply. unicast the reply to the MAC address of End Host #1 or broadcast
If reply is broadcast, the Layer 2 Relay Agent intercepts this the reply. If the reply is broadcast, the Layer 2 Relay Agent
message and removes the Relay Agent Information option. It intercepts this message and removes the Relay Agent Information
identifies the outgoing port using Relay Agent Information option option. It identifies the outgoing port using the Relay Agent
and forwards to the identified interface. A Layer 2 Relay Agent Information option and forwards the message to the identified
may be configured to intercept unicast DHCP messages. In such a interface. A Layer 2 Relay Agent may be configured to intercept
case, Layer 2 Relay Agent intercepts unicast DHCP messages and unicast DHCP messages. In such a case, the Layer 2 Relay Agent
handle them similar to broadcast messages. intercepts unicast DHCP messages and handles them similar to
broadcast messages.
4. Same DHCPOFFER message will be received by the other Layer 2 4. The same DHCPOFFER message will be received by Layer 2 Device #2.
Device [#2]. If it is configured as Layer 2 Relay Agent, it If it is configured as Layer 2 Relay Agent, it broadcasts this
broadcasts this message normally without removing the Relay Agent message normally without removing the Relay Agent option since it
option since it had not added the same. A Layer 2 Relay Agent had not added the same. A Layer 2 Relay Agent uses the Relay
uses the Relay Agent Information option to find out if it had Agent Information option to find out if it had appended it to the
appended it to the request message. request message.
5. The client receives this DHCPOFFER message and it broadcasts a 5. The client receives this DHCPOFFER message and it broadcasts a
DHCPREQUEST message. Layer 2 Relay Agent [#1] handles this DHCPREQUEST message. Layer 2 Relay Agent #1 handles this message
message similar to how it handles a DHCPDISCOVER message. similar to how it handles a DHCPDISCOVER message.
6. The server receives the DHCPREQUEST message from the client and 6. The server receives the DHCPREQUEST message from the client and
responds with a DHCPACK/DHCPNACK message A DHCP server may responds with a DHCPACK/DHCPNACK message. A DHCP server may
unicast the DHCPACK message. Layer 2 Relay Agent processes the unicast the DHCPACK message. The Layer 2 Relay Agent processes
DHCPACK message similar to DHCPOFFER message. the DHCPACK message similar to a DHCPOFFER message.
7. Layer 2 Relay Agent process a DHCPNAK messages similar to DHCPACK 7. The Layer 2 Relay Agent process a DHCPNAK messages similar to a
message. DHCPACK message.
8. Layer 2 Relay Agent process a DHCPDECLINE message similar to 8. The Layer 2 Relay Agent process a DHCPDECLINE message similar to
DHCPDISCOVER message. a DHCPDISCOVER message.
9. DHCP client can unicast some of the DHCP messages. Layer 2 Relay 9. The DHCP client can unicast some of the DHCP messages. The Layer
Agent may or may not intercept these messages based on internal 2 Relay Agent may or may not intercept these messages based on
configuration. If Layer 2 Relay Agents intercept these messages, internal configuration. If Layer 2 Relay Agents intercept these
they append Relay Agent Information option and forward it towards messages, they append a Relay Agent Information option and
the DHCP server. They also intercept the reply messages and forward the message towards the DHCP server. They also intercept
remove Relay Agent Information option before forwarding them. the reply messages and remove the Relay Agent Information option
before forwarding them.
4.1.2. Issues due to introduction of Layer 2 Relay Agent 4.1.2. Issues due to introduction of Layer 2 Relay Agent
1. A DHCP server should be able to handle a DHCP message that 1. A DHCP server should be able to handle a DHCP message that
contains the Relay Agent Information option without 'giaddr' contains the Relay Agent Information option without 'giaddr'
field set in the message. Some existing DHCP server field set in the message. Some existing DHCP server
implementations do not echo back the Relay Agent Information implementations do not echo back the Relay Agent Information
option if giaddr is not set. This may lead to issues at Layer 2 option if giaddr is not set. This may lead to issues at Layer 2
Relay Agents as they will not be able to identify the outgoing Relay Agents as they will not be able to identify the outgoing
port correctly and would broadcast it to all ports. Some Layer 2 port correctly and would broadcast it to all ports. Some Layer 2
Relay Agents discard the reply messages if they do not find a Relay Agents discard the reply messages if they do not find a
Relay Agent Information option in a DHCP reply. Relay Agent Information option in a DHCP reply.
2. There is a case when DHCP clients may receive unicast reply 2. There is a case when the DHCP client receives a unicast reply
messages like DHCPACK with Relay Agent Information option. This message like DHCPACK with a Relay Agent Information option. This
may happen when DHCP server unicast the DHCPACK message and Layer may happen when the DHCP server unicast the DHCPACK message and
2 Relay Agent is configured not to intercept unicast messages. the Layer 2 Relay Agent is configured not to intercept unicast
In such a case, DHCP client can ignore the Relay Agent messages. In such a case, the DHCP client can ignore the Relay
Information option. Agent Information option.
3. A DHCP server should be able to handle a unicast DHCP message 3. A DHCP server should be able to handle a unicast DHCP message
containing Relay Agent Information option. Some existing DHCP containing a Relay Agent Information option. Some existing DHCP
server implementations do not echo back the Relay Agent server implementations do not echo back the Relay Agent
Information option in responses to unicast messages. Information option in responses to unicast messages.
4.2. Multiple DHCP server and Client on same subnet 4.2. Multiple DHCP server and Client on same subnet
In certain network scenarios, there could be multiple DHCP server on In certain network scenarios, there could be multiple DHCP servers on
the same subnet. Figure #2 shows a typical network setup. the same subnet. Figure 2 shows a typical network setup.
+--------+ +--------+
| End | +--------+ | | End | +--------+ |
| Host#1 +-----------| | | +-----------+ | Host#1 +-----------| | | +-----------+
+--------+ | Layer +-----| | | +--------+ | Layer +-----| | |
| 2 | +-----| DHCP | | 2 | +-----| DHCP |
+--------+ | device | | | Server#1 | +--------+ | device | | | Server#1 |
| End +-----------| #1 | | +-----------+ | End +-----------| #1 | | +-----------+
| Host#2 | +--------+ | | Host#2 | +--------+ |
+--------+ | +--------+ |
skipping to change at page 10, line 29 skipping to change at page 10, line 29
| 2 | | | 2 | |
+--------+ | device | +--------+ | device |
| End +-----------| #2 | | End +-----------| #2 |
| Host#n | +--------+ | Host#n | +--------+
+--------+ +--------+
Figure 2 Figure 2
4.2.1. Client-server interaction 4.2.1. Client-server interaction
The message exchange are same as explained in 4.1.1. However, due to The message exchanges are the same as explained in 4.1.1. However,
introduction of multiple DHCP servers the below additional message due to the introduction of multiple DHCP servers the below additional
exchanges may happen message exchange may happen
1. When Host [#1] sends DHCPDISCOVER, it will be received by both 1. When Host #1 sends DHCPDISCOVER, it will be received by both the
the DHCP Servers connected to Layer 2 Relay Agent #1 and both the DHCP Servers connected to Layer 2 Relay Agent #1 and both the
servers will respond with a DHCPOFFER. So instead of one servers will respond with a DHCPOFFER. So instead of one
DHCPOFFER message, Layer 2 Relay Agent would receive two DHCPOFFER message, the Layer 2 Relay Agent would receive two
messages. Processing of DHCP messages in the Layer 2 Relay Agent messages. The processing of DHCP messages in the Layer 2 Relay
remains the same. Agents remains the same.
4.2.2. Issues due to introduction of Layer 2 Relay Agent 4.2.2. Issues due to introduction of Layer 2 Relay Agent
1. Layer 2 relay agents which maintain persistent state, such as 1. Layer 2 relay agents which maintain persistent state, such as
updating filters or client registration, must be prepared to updating filters or client registration, must be prepared to
handle potentially conflicting responses from different DHCP handle potentially conflicting responses from different DHCP
Servers. Some Layer 2 relay agents may use "the most recent DHCP Servers. Some Layer 2 relay agents may use "the most recent DHCP
packet" to update this persistent state but this may not packet" to update this persistent state but this may not
necessarily reflect the actual state of the client. The above is necessarily reflect the actual state of the client. The above is
possible when two DHCP servers ack the request of a DHCP client possible when two DHCP servers acknowledge the request of a DHCP
with same address but has different lease times. In this case, client with the same address but has different lease times. In
if the relay agent selects the server reply which has a shorter this case, if the relay agent selects the server reply with the
lease time, it would expire its state possibly before the client shorter lease time, it would expire its state possibly before the
even has a chance to renew it. Therefore, Layer 2 relay agents client even has a chance to renew it. Therefore, Layer 2 relay
SHOULD select the longest lease time of two conflicting but agents SHOULD select the longest lease time of two conflicting
similar replies, by discarding replies that shorten the lease but similar replies, by discarding replies that shorten the lease
time. time.
2. Other issues are same as described in section 4.1.2. 2. Other issues are the same as described in section 4.1.2.
4.3. DHCP server on another subnet with one Layer 3 Relay Agent 4.3. DHCP server on another subnet with one Layer 3 Relay Agent
In certain network scenarios, there could be a Layer 3 Relay Agent In certain network scenarios, there could be a Layer 3 Relay Agent
which relays the DHCP messages from one subnet to DHCP server on which relays the DHCP messages from one subnet to the DHCP server on
another subnet and vice versa. In typical deployments, Access another subnet and vice versa. In typical deployments, the Access
Concentrator acts as Layer 2 Relay Agent and IP edge device (BRAS or Concentrator acts as Layer 2 Relay Agent and IP edge device (BRAS or
IP Services Switch) acts as Layer 3 Relay Agent. IP Services Switch) acts as Layer 3 Relay Agent.
+--------+ +--------+
| End | +--------+ | | | End | +--------+ | |
| Host#1 +--------| | | +-----------+ | | Host#1 +--------| | | +-----------+ |
+--------+ | Layer +-----| | | | +--------+ | Layer +-----| | | |
| 2 | +--| Layer 3 |----| | 2 | +--| Layer 3 |----|
+--------+ | device | | | Relay | | +--------+ | device | | | Relay | |
| End +--------| #1 | | | Agent #1 | | | End +--------| #1 | | | Agent #1 | |
skipping to change at page 11, line 44 skipping to change at page 11, line 44
+--------+ | device | | +--------+ | device | |
| End +--------| #2 + | End +--------| #2 +
| Host#n | +--------+ | Host#n | +--------+
+--------+ +--------+
Figure 3 Figure 3
4.3.1. Client-server interaction 4.3.1. Client-server interaction
As far as DHCP message processing is concerned, the presence of Layer As far as DHCP message processing is concerned, the presence of Layer
3 Relay Agent is transparent to Layer 2 Relay Agent. So all the 3 Relay Agents is transparent to Layer 2 Relay Agents. So all the
messages are handled in the same way as defined in section 4.1.1 by messages are handled in the same way as defined in section 4.1.1 for
Layer 2 Relay Agent. the Layer 2 Relay Agent.
Layer 3 Relay Agent are configured to trust/untrust an entity based The Layer 3 Relay Agents are configured to trust/untrust an entity
on a specific criteria (For example : VLAN/interface on which the based on specific criteria (For example : VLAN/interface on which the
message was received). If the DHCP messages coming from the client message was received). If the DHCP message coming from the client
has a relay agent option present, Layer 3 Relay Agent checks if it is has a relay agent option present, Layer 3 Relay Agent checks if it is
coming on a trusted interface. If it is coming from a trusted coming in on a trusted interface. If it is coming from a trusted
interface, it will set the 'giaddr' with one of the local interface interface, it will set the 'giaddr' field to one of the local
address and unicasts it to the configured servers. If the message is interface addresses and unicasts it to the configured servers. If
coming from an untrusted interface Layer 3 Relay Agent discards the the message is coming from an untrusted interface, the Layer 3 Relay
message. Agent discards the message.
Typical message processing in this scenario is given below. Typical message processing in this scenario is given below.
1. When client sends a DHCPDISCOVER message, Layer 2 Relay Agent 1. When the client sends a DHCPDISCOVER message, the Layer 2 Relay
forwards it as described in section 4.1.1. Layer 3 Relay Agent Agent forwards it as described in section 4.1.1. The Layer 3
receives this message and finds that it contains Relay Agent Relay Agent receives this message and finds that it contains
Information option. It verifies whether the message is from a Relay Agent Information option. It verifies whether the message
trusted entity or not. If it is from trusted entity it populates is from a trusted entity or not. If it is from a trusted entity
the 'giaddr' as it deems appropriate and relay it to the DHCP the Layer 2 Relay Agent populates the 'giaddr' field as it deems
server. appropriate and relays the message to the DHCP server.
2. DHCP Server process the message in the same way as described in 2. The DHCP Server processes the message in the same way as
section 4.1 and will unicast the DHCPOFFER to Layer 3 Relay Agent described in section 4.1 and will unicast the DHCPOFFER to the
on the address specified in 'giaddr' field. Layer 3 Relay Agent on the address specified in the 'giaddr'
field.
3. Layer 3 Relay Agent process the DHCPOFFER and identifies the 3. The Layer 3 Relay Agent processes the DHCPOFFER and identifies
outgoing interface. It resets the giaddr and broadcasts the the outgoing interface. It resets the 'giaddr' field and
message on the identified outgoing interface broadcasts the message on the identified outgoing interface.
4. Clients receive DHCPOFFER and generate DHCPREQUEST message. 4. The client receives the DHCPOFFER and generates a DHCPREQUEST
Layer 2 Relay Agent process it as described in section 4.1.1. message. The Layer 2 Relay Agent processes it as described in
Layer 3 Relay Agent receives the DHCPREQUEST message and process section 4.1.1. The Layer 3 Relay Agent receives the DHCPREQUEST
it similar to the DHCPDISCOVER message described in step #1. message and processes it similar to the DHCPDISCOVER message
described in step #1.
5. DHCP Server process the DHCPREQUEST and unicasts the DHCP ACK 5. The DHCP Server process the DHCPREQUEST and unicasts the DHCP ACK
message to layer 3 Relay Agent if 'broadcast' flag is set or message to the layer 3 Relay Agent if the 'broadcast' flag is
directly to the client if 'broadcast' flag is not set. If Layer set, or directly to the client if the 'broadcast' flag is not
3 Relay Agent receives this message, it will process it similar set. If the Layer 3 Relay Agent receives this message, it will
to DHCPOFFER as described in step #3. process it similar to the DHCPOFFER as described in step #3.
6. In case of unicast messages [For example: DHCPREQUEST in case of 6. In the case of unicast messages (For example: DHCPREQUEST in case
DHCPRENEW], a Layer 3 Relay Agent may or may not intercept the of DHCPRENEW), a Layer 3 Relay Agent may or may not intercept the
message. If it intercepts a unicast DHCP request message, it message. If it intercepts a unicast DHCP request message, it
populates the 'giaddr' and relay it to the DHCP server. When populates the 'giaddr' field and relays the message to the DHCP
DHCP server sends a reply for this request message, it resets the server. When the DHCP server sends a reply for this request
'giaddr' field, identifies outgoing interface and forwards the message, it resets the 'giaddr' field, identifies the outgoing
reply on the identified interface. interface, and forwards the reply on the identified interface.
4.3.2. Issues due to introduction of Layer 2 Relay Agent 4.3.2. Issues due to introduction of Layer 2 Relay Agent
Though the processing of DHCP messages remain the same in Layer 2 Though the processing of DHCP messages remains the same in Layer 2
Relay Agent, we see some more issues when a Layer 3 Relay Agent is Relay Agents, we see some more issues when a Layer 3 Relay Agent is
present to relay the DHCP messages to the DHCP server. present to relay the DHCP messages to the DHCP server.
1. When a Layer 2 Relay Agent is configured to intercept unicast 1. When a Layer 2 Relay Agent is configured to intercept unicast
messages as well, it appends Relay Agent Information option messages as well, it appends a Relay Agent Information option
before forwarding them. A Layer 3 Relay Agent may not intercept before forwarding the request message. A Layer 3 Relay Agent may
these unicast messages. Due to this, a DHCP server may not echo not intercept these unicast messages. Due to this, a DHCP server
back the Relay Agent Information option because the giaddr is not may not echo back the Relay Agent Information option because the
populated. giaddr is not populated.
2. Existing Layer 3 Relay Agents populate the 'giaddr' with the IP 2. Existing Layer 3 Relay Agents populate the 'giaddr' with the IP
address of the interface on which the request was received. This address of the interface on which the request was received. This
helps Layer 3 Relay Agent to identify the outgoing interface for helps the Layer 3 Relay Agent to identify the outgoing interface
the DHCP replies. In some cases, a Layer 3 Relay Agent may use for the DHCP replies. In some cases, a Layer 3 Relay Agent may
unnumbered interfaces. In this case, it has to use a system wide use unnumbered interfaces. In this case, it has to use a system
IP address to populate the 'giaddr' field. Due to this, it wide IP address to populate the 'giaddr' field. Due to this, it
becomes difficult to identify the correct outgoing interface for becomes difficult to identify the correct outgoing interface for
the messages received from the DHCP server. In these cases, some the messages received from the DHCP server. In these cases, some
existing Layer 3 Relay Agent implementations maintain an internal existing Layer 3 Relay Agent implementations maintain an internal
state for each DHCP messages and use this state to identify the state for each DHCP message and use this state to identify the
outgoing interface. outgoing interface.
3. DHCP server uses certain parameters to differentiate the RENEW 3. A DHCP server uses certain parameters to differentiate the RENEW
and REBIND state of a client. A DHCP client unicasts a RENEW and REBIND state of a client. A DHCP client unicasts a RENEW
request to the DHCP server, so DHCP server sees a DHCPREQUEST request to the DHCP server, so the DHCP server sees a DHCPREQUEST
without 'giaddr' and Relay Agent Information option as RENEW without 'giaddr' and Relay Agent Information option as a RENEW
request. While a REBIND request is broadcast and so DHCP server request. On the other hand, a REBIND request is broadcast and so
expect it to contain 'giaddr' and Relay Agent Information option. the DHCP server expect it to contain 'giaddr' and a Relay Agent
If Layer 2 Relay Agent is configured to intercept unicast Information option. If the Layer 2 Relay Agent is configured to
messages, it will append Relay Agent Information option to the intercept unicast messages, it will append a Relay Agent
unicast DHCP messages. Because of this, it could be difficult Information option to the unicast DHCP messages. Because of
for DHCP server to differentiate between a RENEWING and REBINDING this, it could be difficult for the DHCP server to differentiate
state. between a RENEWING and REBINDING state.
5. Acknowledgments 5. Acknowledgments
This document is the result of a discussion on DHC WG mailing list. This document is the result of a discussion on DHC WG mailing list.
Thanks to David W. Hankins and Michael Wacker for providing inputs on Thanks to David W. Hankins and Michael Wacker for providing inputs on
some of the existing implementations. Thanks to Ted Lemon, Mukund some of the existing implementations. Thanks to Ted Lemon, Mukund
Kamath and Stefaan.De.Cnodder for reviewing the draft and providing Kamath, Alfred Hoenes and Stefaan De Cnodder for reviewing the draft
valuable suggestions. and providing valuable suggestions.
6. Security Consideration 6. Security Consideration
o A Layer 2 Relay Agent should always be configured to identify a o A Layer 2 Relay Agent should always be configured to identify a
trustable entity so that it appends Relay Agent Information option trustable entity so that it appends a Relay Agent Information
to DHCP messages coming from a trustable entity and forward it. option to a DHCP messages coming from a trustable entity and
If a DHCP message is received from a non-trustable entity, it forward it. If a DHCP message is received from a non-trustable
should discard it and may report to the administrator. entity, the Layer 2 Relay Agent should discard it and may report
to the administrator.
o Introduction of Layer 2 Relay Agent does not introduce any new o The introduction of Layer 2 Relay Agent does not introduce any new
security issue. Security issues pertaining to Relay Agents in security issues. Security issues pertaining to Relay Agents in
general applies to Layer 2 Relay Agents as well. general apply to the Layer 2 Relay Agents as well.
7. IANA Considerations 7. IANA Considerations
This document does not introduce any new namespaces for the IANA to This document does not introduce any new namespaces for the IANA to
manage. manage and does not request any new code point assignments.
8. References 8. References
8.1. Normative Reference 8.1. Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
skipping to change at page 19, line 4 skipping to change at line 559
URI: http://www.infosys.com/ URI: http://www.infosys.com/
Pavan Kurapati Pavan Kurapati
Infosys Technologies Ltd. Infosys Technologies Ltd.
44 Electronics City, Hosur Road 44 Electronics City, Hosur Road
Bangalore 560 100 Bangalore 560 100
India India
Email: pavan_kurapati@infosys.com Email: pavan_kurapati@infosys.com
URI: http://www.infosys.com/ URI: http://www.infosys.com/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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.
Intellectual Property
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.
 End of changes. 57 change blocks. 
174 lines changed or deleted 193 lines changed or added

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