draft-ietf-dhc-l2ra-00.txt   draft-ietf-dhc-l2ra-01.txt 
DHC Working Group B. Joshi DHC Working Group B. Joshi
Internet-Draft P. Kurapati Internet-Draft P. Kurapati
Expires: July 31, 2008 Infosys Technologies Ltd. Expires: November 17, 2008 Infosys Technologies Ltd.
January 28, 2008 May 16, 2008
Layer 2 Relay Agent Information Layer 2 Relay Agent Information
draft-ietf-dhc-l2ra-00.txt draft-ietf-dhc-l2ra-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 34 skipping to change at page 1, line 34
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 July 31, 2008. This Internet-Draft will expire on November 17, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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
skipping to change at page 3, line 7 skipping to change at page 2, line 13
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 Relay Agent Information option in
DHCP messages. These devices are typically known as Layer 2 Relay 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 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Need of Layer 2 Relay Agent . . . . . . . . . . . . . . . . . 6 3. Need of Layer 2 Relay Agent . . . . . . . . . . . . . . . . . 5
4. Layer 2 Relay Agent in various network scenarios . . . . . . . 7 4. Layer 2 Relay Agent in various network scenarios . . . . . . . 6
4.1. DHCP server and client on same subnet . . . . . . . . . . 7 4.1. DHCP server and client on same subnet . . . . . . . . . . 6
4.1.1. Client-server interaction . . . . . . . . . . . . . . 7 4.1.1. Client-server interaction . . . . . . . . . . . . . . 6
4.1.2. Issues due to introduction of Layer 2 Relay Agent . . 9 4.1.2. Issues due to introduction of Layer 2 Relay Agent . . 8
4.2. Multiple DHCP server and Client on same subnet . . . . . . 9 4.2. Multiple DHCP server and Client on same subnet . . . . . . 8
4.2.1. Client-server interaction . . . . . . . . . . . . . . 10 4.2.1. Client-server interaction . . . . . . . . . . . . . . 9
4.2.2. Issues due to introduction of Layer 2 Relay Agent . . 10 4.2.2. Issues due to introduction of Layer 2 Relay Agent . . 9
4.3. DHCP server on another subnet with one Layer 3 Relay 4.3. DHCP server on another subnet with one Layer 3 Relay
Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Client-server interaction . . . . . . . . . . . . . . 11 4.3.1. Client-server interaction . . . . . . . . . . . . . . 10
4.3.2. Issues due to introduction of Layer 2 Relay Agent . . 12 4.3.2. Issues due to introduction of Layer 2 Relay Agent . . 12
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Consideration . . . . . . . . . . . . . . . . . . . . 15 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 17 8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 16
8.2. Informative Reference . . . . . . . . . . . . . . . . . . 17 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 18
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 as each physical network. Relay Agents populate the 'giaddr' field and
they deem appropriate and also add 'Relay Agent Information' option also append the 'Relay Agent Information' option to the DHCP
to the DHCP messages. DHCP servers use this option for IP address messages. DHCP servers use this option for IP address and other
and other parameter assignment policies. These DHCP Relay Agents are parameter assignment policies. These DHCP Relay Agents are typically
typically an IP routing aware device and are referred as Layer 3 an IP routing aware device and are referred as Layer 3 Relay Agents.
Relay Agents.
In some network configurations, there is a need for Layer 2 devices In some network configurations, there is a need for Layer 2 devices
to add Relay Agent Information option as they are closer to the end to append the Relay Agent Information option as they are closer to
hosts. These Layer 2 devices can not relay the message to the DHCP the end hosts. These Layer 2 devices are typically operating only as
servers as they are typically configured in bridging mode. These bridges for the network and may not have an IPv4 address on the
Layer 2 devices append the Relay Agent Information option and network in question. Lacking a valid IPv4 source address, they
broadcast the DHCP message. A Layer 3 Relay Agent relays it to the cannot relay packets directly to a DHCP server located on another
DHCP server. network. These Layer 2 devices append the Relay Agent Information
option and broadcast the DHCP message. A Layer 3 Relay Agent relays
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 Agent and discusses various
issues caused by introduction of Layer 2 Relay Agent. issues caused by introduction of Layer 2 Relay Agent.
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
skipping to change at page 6, line 16 skipping to change at page 5, line 16
A Layer 2 device intercepts DHCP messages for following reasons: A Layer 2 device intercepts DHCP messages for 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 DHCP server.
2. In some networks, the Layer 2 Switch which is closest to the end 2. In some network deployments, a Layer 2 device can append Relay
Agent Information in DHCP messages so that it can use this
information to forward the DHCP Replies to the specific port on
which request was received.
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 the Layer 2 and Layer 3
spoofing attempts by the subscribers. A point to note here is spoofing attempts by the subscribers. A point to note here is
that in cases where switches maintain the Lease Information, they that in cases where switches maintain the Lease Information, they
have to intercept unicast DHCP messages as well to keep this have to intercept unicast DHCP messages as well to keep this
information upto date. information upto date.
3. 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. it 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.
skipping to change at page 7, line 49 skipping to change at page 6, line 49
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 Relay Agent Information option and broadcasts it message, appends the Relay Agent Information option and
to all the ports except on which it was received. Relay Agent broadcasts it to all the ports except on which it was received.
Information option could be created as suggested in RFC 3046[3].
Layer 2 Relay Agent does not set the 'giaddr' field. Relay Agent Information option could be created as suggested in
RFC 3046[3]. Layer 2 Relay Agent does not set the 'giaddr'
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 add another Relay Agent, it intercepts this message but does not append another
Agent Information option to the message. It may discard this Relay Agent Information option to the message. It may discard
message if it is coming from an untrusted entity. Otherwise, it this message if it is coming from an untrusted entity.
will broadcast this on all the ports except on which the message Otherwise, it will broadcast this on all the ports except on
was received. which the message was received.
3. Server responds with a DHCPOFFER message after applying its local 3. Server responds with a DHCPOFFER message after applying its local
policies. DHCP server echoes back the Relay Agent Information policies. DHCP server echoes back the Relay Agent Information
option in the DHCPOFFER message. Layer 2 Relay Agent intercepts option in the DHCPOFFER message. DHCP server can either unicast
this message and removes the Relay Agent Information option. It the reply to MAC address of End Host #1 or broadcast the reply.
In both the cases, the Layer 2 Relay Agent intercepts this
message and removes the Relay Agent Information option. It
identifies the outgoing port using Relay Agent Information option identifies the outgoing port using Relay Agent Information option
and forwards to the identified interface. and forwards to the identified interface.
4. Same DHCPOFFER message will be received by the other Layer 2 4. Same DHCPOFFER message will be received by the other Layer 2
Device [#2]. If it is configured as Layer 2 Relay Agent, it Device [#2]. If it is configured as Layer 2 Relay Agent, it
broadcasts this message normally without removing the Relay Agent broadcasts this message normally without removing the Relay Agent
option since it had not added the same. A Layer 2 Relay Agent option since it had not added the same. A Layer 2 Relay Agent
uses the Relay Agent Information option to find out if it had uses the Relay Agent Information option to find out if it had
appended it to the request message. appended it to the request message.
skipping to change at page 10, line 42 skipping to change at page 9, line 42
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 DHCP Servers connected to Layer 2 Relay Agent #1 and both the 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, Layer 2 Relay Agent would receive two
messages. Processing of DHCP messages in the Layer 2 Relay Agent messages. Processing of DHCP messages in the Layer 2 Relay Agent
remains the same. 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. This is same as described in section 4.1.2. 1. Layer 2 relay agents which maintain persistent state, such as
updating filters or client registration, must be prepared to
handle potentially conflicting responses from different DHCP
Servers. Some Layer 2 relay agents may use "the most recent DHCP
packet" to update this persistent state but this may not
necessarily reflect the actual state of the client. The above is
possible when two DHCP servers ack the request of a DHCP client
with same address but has different lease times. In this case,
if the relay agent selects the server reply which has a shorter
lease time, it would expire its state possibly before the client
even has a chance to renew it. Therefore, Layer 2 relay agents
SHOULD select the longest lease time of two conflicting but
similar replies, by discarding replies that shorten the lease
time.
2. Other issues are 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 DHCP server on
another subnet and vice versa. In typical deployments, Access another subnet and vice versa. In typical deployments, 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.
+--------+ +--------+
skipping to change at page 15, line 9 skipping to change at page 14, line 9
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 Stefaan.De.Cnodder some of the existing implementations. Thanks to Stefaan.De.Cnodder
and Mukund Kamath for reviewing the draft and providing valuable and Mukund Kamath for reviewing the draft and providing valuable
suggestions 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 Relay Agent Information option
to DHCP messages coming from this and forward it. If a DHCP to DHCP messages coming from a trustable entity and forward it.
message is received from a non-trustable entity, it should discard If a DHCP message is received from a non-trustable entity, it
it and may report to the administrator. should discard it and may report to the administrator.
o Introduction of Layer 2 Relay Agent does not introduce any new o Introduction of Layer 2 Relay Agent does not introduce any new
security issue. Security issues pertaining to Relay Agents in security issue. Security issues pertaining to Relay Agents in
general applies to Layer 2 Relay Agents as well. general applies to 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.
skipping to change at page 19, line 5 skipping to change at page 18, line 5
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 Intellectual Property 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 19, line 45 skipping to change at page 18, line 29
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 (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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is currently provided by the
Administrative Support Activity (IASA). Internet Society.
 End of changes. 18 change blocks. 
69 lines changed or deleted 94 lines changed or added

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