DHC Working Group B. Joshi
Internet-Draft P. Kurapati
Expires: August 13, 2007 Infosys Technologies Ltd.
February 9, 2007
Relay Chaining in DHCPv4
draft-kurapati-dhc-relay-chaining-dhcpv4-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
DHCP Relay Agents eliminate the necessity of having a DHCP server on
each physical network. DHCPv4 assumes that there is always only one
Relay Agent between DHCP clients and DHCP server. In certain network
configurations, a DHCP server may be multiple subnets away from the
DHCP client and multiple Relay Agents may be configured to relay DHCP
messages to and from DHCP client. Such configuration can be
supported only when each Relay Agent adds certain Information to DHCP
messages before relaying them. This additional information helps in
Joshi & Kurapati Expires August 13, 2007 [Page 1]
Internet-Draft Relay Chaining in DHCPv4 February 2007
relaying the DHCP reply back to the DHCP client through the same
path. This mechanism is often referred as Relay Chaining.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. New sub-options . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. peer-relay-agent-information Sub Option . . . . . . . . . 6
3.2. peer-address Sub Option . . . . . . . . . . . . . . . . . 6
4. Relay Chaining . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Handling DHCP messages in Relay Agent . . . . . . . . . . 7
4.1.1. Handling Broadcast DHCP messages . . . . . . . . . . . 7
4.1.2. Handling Unicast DHCP messages . . . . . . . . . . . . 8
5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 10
6. Special Scenarios . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Multiple Layer 2 Relay Agents between DHCP client and
Layer 3 Relay Agent . . . . . . . . . . . . . . . . . . . 11
6.2. One or multiple Layer 2 Relay Agents between two Layer
3 Relay Agents . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Consideration . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 14
9.2. Informative Reference . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Joshi & Kurapati Expires August 13, 2007 [Page 2]
Internet-Draft Relay Chaining in DHCPv4 February 2007
1. Introduction
In some network configurations, DHCP server and clients are separated
by multiple Relay Agents. One such case is the network configuration
where Access Concentrators operate in Transparent Bridging mode as
described in document [5]. In such configurations there are
situations where each of those relay agents need to add relay-agent-
information to the DHCP messages received on its downstream
interface. Relay chaining support in DHCPv4 will help in solving
following problems:
o In some deployments Layer 3 Relay Agent uses unnumbered
interfaces. When these Layer 3 Relay Agents are used along with
Layer 2 Relay agents as described in document [5] , they need to
maintain internal states to identify the outgoing interface.
Maintaining state information for each packet will not scale as
number of DHCP clients increases. With Relay Chaining, Layer 3
Relay Agent can add its own Relay Agent Information option that
can be used to identify the outgoing interface for DHCP reply
messages.
o When a network configuration supports multiple Layer 3 Relay
Agents between DHCP Clients and DHCP server, a DHCP message need
to be relayed through these Relay Agents to reach DHCP server or
DHCP Clients. This can not be supported with present mechanism.
This document describes the enhancements to Relay Agent functionality
when multiple Relay Agents are present between DHCP clients and
servers.
Joshi & Kurapati Expires August 13, 2007 [Page 3]
Internet-Draft Relay Chaining in DHCPv4 February 2007
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
This document uses the following terms:
o "Access Concentrator"
An Access Concentrator is a router or switch at the broadband access
provider's edge of a public broadband access network. This document
assumes that the Access Concentrator acts as a Transparent Bridge and
includes the DHCP relay agent functionality. For example: In DSL
environment, this is typically known as DSLAM.(Digital Subscriber
Line Access Multiplexer)
o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain configuration
parameters such as a network address.
o "Layer 3 Relay Agent"
A Layer 3 Relay Agent is a third-party agent that transfers Bootstrap
Protocol (BOOTP) and DHCP messages between clients and servers
residing on different subnets, per RFC951 [6] and RFC1542 [7].
o "DHCP server"
A DHCP server is an Internet host that returns configuration
parameters to DHCP clients.
o "downstream"
Downstream is the direction from the edge network towards the DHCP
Clients.
o "Transparent Bridge"
A device which does bridging based on MAC learning principles.
Bridge learns the Source MAC of the incoming frames and updates a
table with MAC/Interface information. While forwarding data packets,
bridge looks at this table to find the outgoing interface.
o "upstream"
Upstream is the direction from the DHCP Clients towards the edge
Joshi & Kurapati Expires August 13, 2007 [Page 4]
Internet-Draft Relay Chaining in DHCPv4 February 2007
network.
o "Unnumbered Interfaces"
An interface with no IP address associated with it. IP packets
received on this interface will be processed like any other numbered
IP interface. It may use a local IP address of another interface
while forwarding packets.
Joshi & Kurapati Expires August 13, 2007 [Page 5]
Internet-Draft Relay Chaining in DHCPv4 February 2007
3. New sub-options
The 'Relay Chaining in DHCPv4' requires the definition of following
new sub-options in Relay Agent Information [Option 82] option for
DHCP packet beyond those defined by RFC2131 [2] and RFC2132 [8]. See
also Section 7, IANA Considerations.
3.1. peer-relay-agent-information Sub Option
This sub-option is defined under Relay Agent Information option
[Option 82]. A Relay Agent can use 'peer-relay-agent-information'
sub-option to store the Relay Agent Information option added by the
previous Relay Agent. The value field of this sub-option contains
the Relay Agent Information option present in the recevied DHCP
message. The new sub-option is as shown in the figure below:
SubOpt Len Value
+------+------+--------------------------+
| X | Len | Option 82 of Previous RA |
+------+------+--------------------------+
/ \
/ \
+------+-----+--------------------+
| 82 | N | i1 | i2 | ... | iN |
+------+-----+--------------------+
Code Len Relay Agent Information
Figure 1
3.2. peer-address Sub Option
'peer-address' sub-option is used to store the previous Relay Agent's
reachable IP address. It SHOULD be typically populated with the same
address as mentioned in the 'giaddr' field of the received message.
If there are multiple Relay Agents involved, this sub-option helps in
forwarding the reply back to the DHCP client through the same path.
The 'peer-address' sub-option is as follows:
SubOpt Len Sub-option Value
+--------+--------+--------------------------------+
| X | 4 | Previous RA's Address (giaddr) |
+--------+--------+--------------------------------+
Figure 2
Joshi & Kurapati Expires August 13, 2007 [Page 6]
Internet-Draft Relay Chaining in DHCPv4 February 2007
4. Relay Chaining
Relay Chaining is defined as the mechanism where multiple Relay
Agents are involved in relaying a DHCP message between DHCP clients
and server. Each Relay Agent adds Relay Agent Information option to
the DHCP message as described below. The option of using relay
chaining mechanism MUST be configurable on Relay Agent in order to
provide compatibility to the previous solutions.
|
+-----+ |
|Host1|------+
+-----+ |
|
+-----+ |
|Host2|------+ +--------+
+-----+ | | | +--------+ +--------+
+------| | | | | |
| | Relay | | Relay | | DHCP |
| | Agent |---..---| Agent |--..--| Server |
| | #1 | | #2 | | |
+-----+ +------| | | | +--------+
|Host3|------+ | | +--------+
+-----+ | +--------+
|
+-----+ |
|Host4|------+
+-----+ |
|
|
Figure 3
A typical network configuration where Relay Chaining is required is
depicted in Figure 3. In the above case, two Relay Agents are
involved. Relay Agent #1 does not know the DHCP server and so is
configured to reach Relay Agent #2 for all DHCP messages. Relay
Agent #2 knows how to reach DHCP server and so relays a DHCP message
directly to DHCP server. DHCP server generates the reply messages
and sends it to Relay Agent #2 which relays the same to Relay Agent
#1.
4.1. Handling DHCP messages in Relay Agent
4.1.1. Handling Broadcast DHCP messages
Joshi & Kurapati Expires August 13, 2007 [Page 7]
Internet-Draft Relay Chaining in DHCPv4 February 2007
o When a Relay Agent receives a DHCP request message which does not
contain the Relay Agent Information option, it SHOULD add the
Relay Agent Information option (Option 82 as described in RFC 3046
[3]) and 'giaddr' field as it deems appropriate. It SHOULD relay
the DHCP message to the DHCP server or next Relay Agent.
o When a Relay Agent receives a DHCP request message which contains
a Relay Agent Information option, it SHOULD add the Relay Agent
Information Option as it deems appropriate and also populate the
'peer-relay-agent-information' sub-option as described in section
3.1.
o If a Relay Agent is a Layer 2 relay agent, as per [5] it MUST NOT
populate the 'giaddr' field in the DHCP message.
o If a DHCP message received by a Relay Agent has a non-zero
'giaddr' field, it MUST add 'peer-address' sub-option in the Relay
Agent Information option with the same IP address as described in
section 3.2.
o When a Relay Agent receives the reply message from the server, it
MAY verify the Relay Agent Information option and SHALL silently
discard the packet if it had not added the Relay Agent Information
option. A Relay Agent MUST remove the Relay Agent Information
option it had added and process the reply message as follows:
* A Relay Agent MUST look for 'peer-relay-agent-information' sub-
option in the Relay Agent Information option it had added and
if it finds this sub-option, it MUST extract the contents which
is the Option 82 of the previous Relay Agent. Before relaying
this message, it MUST append the Relay Agent Information option
of the previous Relay Agent as it is to the DHCP message.
Relay Agent MAY use the Relay Agent Information it had added,
to identify the outgoing interface.
* A Relay Agent MUST also look for 'peer-address' sub-option and
if it finds this sub-option, it must extract the IP address
from the sub-option. It MUST set this IP address as 'giaddr'
and relay the DHCP reply to this IP address. If this sub-
option is not available, it SHOULD broadcast the reply to the
outgoing interface.
4.1.2. Handling Unicast DHCP messages
As DHCP Clients unicast RENEW, RELEASE and INFORM messages directly
to the DHCP server, these messages are not intercepted by Relay
Agents and so these messages does not have any Relay Agent
Information options added to them.
Joshi & Kurapati Expires August 13, 2007 [Page 8]
Internet-Draft Relay Chaining in DHCPv4 February 2007
Some existing Relay Agent implementations maintain lease/location
informations for each DHCP client. These implementations intercepts
unicast DHCP messages to keep the lease/location information updated.
So these Relay Agent adds Relay Agent Information option to unicast
DHCP messages as well. Relay Agents and DHCP server process them
similar to broadcast messages as described above in section 5.1.1.
Joshi & Kurapati Expires August 13, 2007 [Page 9]
Internet-Draft Relay Chaining in DHCPv4 February 2007
5. DHCP Server Behavior
DHCP server would still find only one single Relay Agent Information
option [ Option 82 ] in the DHCP message which has been relayed by
multiple relay agents.
Some existing DHCP servers may use the Relay Agent Information option
to apply the IP Address and other parameter assignment policies.
These DHCP servers will have to employ recursive lookup algorithm to
find the relevant Option 82 [the Option 82 which was added by the
first Relay Agent]. Server MUST echo back the entire Option 82 as it
is.
Joshi & Kurapati Expires August 13, 2007 [Page 10]
Internet-Draft Relay Chaining in DHCPv4 February 2007
6. Special Scenarios
6.1. Multiple Layer 2 Relay Agents between DHCP client and Layer 3
Relay Agent
There may be a network scenario when there are multiple Layer 2 Relay
Agents configured between DHCP clients and Layer 3 Relay Agent. In
this case, as described above, each Layer 2 Relay Agent MUST add
'Relay Agent Information' option and MUST not add 'peer-address' sub-
option in it. A Layer 2 Relay Agent can use this Relay Agent
Information option while relaying the DHCP Reply message back to the
DHCP client.
6.2. One or multiple Layer 2 Relay Agents between two Layer 3 Relay
Agents
There is a very rare possibility of one or multiple Layer 2 Relay
Agents being present between two Layer 3 Relay Agents. In this case,
all the DHCP messages exchanged between these two Layer 3 Relay
Agents would be unicast messages. Typically a Layer 2 Relay Agent
should snoop these DHCP messages only if it maintains Lease/Location
information as described in [5]. In such cases, Layer 2 Relay Agents
SHOULD add Relay Agent Information option as described in section
4.1.1.
Joshi & Kurapati Expires August 13, 2007 [Page 11]
Internet-Draft Relay Chaining in DHCPv4 February 2007
7. Security Consideration
o A Relay Agents relaying DHCP messages to another Relay Agent are
essentially DHCP clients for the DHCP messages. Thus, RFC3118 [4]
is an appropriate mechanism for these DHCP messages.
o To restrict the number of Relay Agents in Relay Chaining, as
defined in RFC 1542 [7], a Relay Agent must silently discard the
DHCP message whose 'hops' field exceeds the value 16. A network
manager can use configuration option to set this threshold to a
smaller value.
Joshi & Kurapati Expires August 13, 2007 [Page 12]
Internet-Draft Relay Chaining in DHCPv4 February 2007
8. IANA Considerations
This document needs IANA to provide a unique number for the following
new suboptions in Relay Agent Information option [Option 82]:
o To carry the peer relay agent information option. Please refer to
section 3.1 for more details.
o To carry the peer address. Please refer to section 3.2 for more
details.
Joshi & Kurapati Expires August 13, 2007 [Page 13]
Internet-Draft Relay Chaining in DHCPv4 February 2007
9. References
9.1. Normative Reference
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
January 2001.
[4] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
[5] Joshi, B., Kurapati, P., Kamath, M., and S. De Cnodder, "Layer 2
Relay Agent", draft draft-joshi-dhc-layer2-relay-agent-00.txt,
February 2007.
9.2. Informative Reference
[6] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
September 1985.
[7] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, October 1993.
[8] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
Joshi & Kurapati Expires August 13, 2007 [Page 14]
Internet-Draft Relay Chaining in DHCPv4 February 2007
Authors' Addresses
Bharat Joshi
Infosys Technologies Ltd.
44 Electronics City, Hosur Road
Bangalore 560 100
India
Email: bharat_joshi@infosys.com
URI: http://www.infosys.com/
Pavan Kurapati
Infosys Technologies Ltd.
44 Electronics City, Hosur Road
Bangalore 560 100
India
Email: pavan_kurapati@infosys.com
URI: http://www.infosys.com/
Joshi & Kurapati Expires August 13, 2007 [Page 15]
Internet-Draft Relay Chaining in DHCPv4 February 2007
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Joshi & Kurapati Expires August 13, 2007 [Page 16]