Internet DRAFT - draft-decnodder-dhc-rai-unicast
draft-decnodder-dhc-rai-unicast
DHC Working Group S. De Cnodder
Internet-Draft Alcatel
Expires: February 18, 2007 P. Kurapati
Infosys Technologies Ltd.
August 17, 2006
Unicast Address Sub-Option
draft-decnodder-dhc-rai-unicast-01.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 February 18, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
In some network topologies, it is preferred to have a trusted network
element between the DHCP client and the L3 relay agent that adds the
DHCP relay-agent-information option but does not set the giaddr
field. They operate in Layer 2 mode and hence act as trusted Layer 2
relay agents. The replies from the server are broadcasted by the L3
relay agents to these L2 relay agents which must be avoided. This
document defines a new sub-option for the relay-agent-information
De Cnodder & Kurapati Expires February 18, 2007 [Page 1]
Internet-Draft Unicast Address Sub-Option August 2006
option. With this sub-option, the L3 relay agent will always unicast
the messages towards the trusted layer 2 DHCP relay agent with a
hardware address that is known in the network. The new sub-option is
called the "unicast-address" sub-option.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Unicast-Address Sub-Option . . . . . . . . . . . . . . . . . . 7
3.1. Unicast-Address Sub-Option Definition . . . . . . . . . . 7
3.2. L3 Relay Agent Behavior . . . . . . . . . . . . . . . . . 7
3.3. L2 Relay Agent Behavior . . . . . . . . . . . . . . . . . 7
3.4. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . 8
3.5. Example Scenarios . . . . . . . . . . . . . . . . . . . . 8
4. Security Consideration . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 13
7.2. Informative Reference . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
De Cnodder & Kurapati Expires February 18, 2007 [Page 2]
Internet-Draft Unicast Address Sub-Option August 2006
1. 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 "trusted layer 2 DHCP relay agent"
A network element that is residing between the DHCP client and the L3
DHCP relay agent. This network element inserts the relay-agent-
information option as a L3 DHCP relay agent would do. The L3 DHCP
relay agent trusts this option, and does not replace or remove it
while transferring the DHCP message towards the server or towards the
client.
o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain configuration
parameters such as a network address.
o "L3 DHCP 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] and [RFC1542].
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
client.
o "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 client towards the edge
De Cnodder & Kurapati Expires February 18, 2007 [Page 3]
Internet-Draft Unicast Address Sub-Option August 2006
network.
De Cnodder & Kurapati Expires February 18, 2007 [Page 4]
Internet-Draft Unicast Address Sub-Option August 2006
2. Introduction
In some network topologies, it is preferred to have a trusted network
element between the DHCP client and the L3 DHCP relay agent that adds
the DHCP relay-agent-information option (RFC 3046) [2] but does not
set the giaddr field. An example of such an environment is described
in TR101 [3] where an access node such as a DSLAM adds the relay-
agent-information option which can uniquely identify the DSL line.
Multiple access nodes can be connected via an Ethernet based
aggregation network to an IP edge router that is acting as the L3
relay agent. Such network elements adding the DHCP relay-agent-
information option are called "layer 2 DHCP relay agents" in
TR101[3].
Figure 1 shows an example where each access node adds the relay agent
information option containing the port information of the host
sending the DHCP messages and the IP edge router relays the DHCP
messages.
+-------+
+-----+ | |
|Host1|-------| |
+-----+ |Access |
|Node1 |-----......
+-----+ | | .
|Host2|-------| | . +------+
+-----+ | | . | |
+-------+ ----| | +--------+
Trusted layer 2 | | | DHCP |
DHCP relay agents |IPedge|--.....---| Server |
+-------+ | | +--------+
+-----+ | | .----| |
|Host3|-------| | . | |
+-----+ |Access | . +------+
|Node2 |-----...... L3
+-----+ | | Relay Agent
|Host4|-------| |
+-----+ | |
+-------+
Figure 1
RFC 2131[4] defines the meaning of the broadcast flag in the flags
field: it indicates whether the client wishes to receive the
DHCPOFFER and DHCPACK message as a broadcast or a unicast from the
DHCP server or the DHCP relay agent. In the scenario of Figure 1,
this means that the IP edge router will broadcast the DHCPOFFER and
De Cnodder & Kurapati Expires February 18, 2007 [Page 5]
Internet-Draft Unicast Address Sub-Option August 2006
DHCPACK messages to all access nodes if the broadcast flag is set.
Whether or not broadcast is used between the L3 relay agent and the
trusted layer 2 DHCP relay agents depends on the behavior of the DHCP
clients. However broadcasts in the aggregation network are to be
avoided. So it is preferred to always use unicast from the L3 DHCP
relay agent to the trusted layer 2 DHCP relay agent. Between the
trusted layer 2 DHCP relay agent and the host, broadcast flag has to
be honored.
Even though the DHCP clients are not setting the broadcast flag, it
is still possible that the DHCPOFFER and DHCPACK messages from the
DHCP server are sent to all access nodes. This is when the access
node implements a MAC concentration or MAC translation function.
When such a MAC operation is performed, the access node replaces the
source MAC address of all upstream frames by another MAC address, for
instance with its own MAC address. In this case, the MAC addresses
of the hosts will remain unknown in the network between the trusted
layer 2 DHCP relay agent and the L3 DHCP relay agent. Hence, all
unicast messages sent by the L3 DHCP relay agent using this MAC
address will be flooded to all access nodes.
To overcome these two previously mentioned problems, this document
defines a new sub-option 'unicast-address' for the relay-agent-
information option. With this sub-option, the L3 DHCP relay agent
will always unicast the messages towards the trusted layer 2 DHCP
relay agent with a hardware address that is known in the network.
De Cnodder & Kurapati Expires February 18, 2007 [Page 6]
Internet-Draft Unicast Address Sub-Option August 2006
3. Unicast-Address Sub-Option
3.1. Unicast-Address Sub-Option Definition
The unicast-address sub-option of the relay-agent-information option
MAY be used by any trusted layer 2 DHCP relay agent such that the L3
relay agent unicasts the messages from the DHCP server with a
hardware address known in the network. The hardware address in the
unicast-address sub-option MUST be an address that can be used to
send unicast packets towards the client.
The format of the option is as follows .
SubOpt Len [Hardware address details]
+------+------+----------+-------------+
| X | Len | htype(1) | hwaddr |
+------+------+----------+-------------+
Figure 2
o 'X' is the sub-option code which needs to be allocated by IANA.
o 'Len' represents the lenth of the 'value' which includes both htype
and hwaddr fields
o "htype" represents Hardware type. See the 'ARP parameters'
maintained in the database referenced by Assigned numbers RFC
3232[5].
o"hwaddr" is the unicast hardware address.
3.2. L3 Relay Agent Behavior
When L3 DHCP Relay Agent receives a DHCP packet with unicast-address
sub-option added, it SHOULD unicast that message towards the layer 2
DHCP relay agent with destination address set to the value contained
in the hwaddr field of the sub-option. A L3 relay agent that
supports this option SHOULD ignore the broadcast flag if this sub-
option is present in the DHCP message. In the absence of this sub-
option a L3 relay agent SHOULD behave as earlier and forward the
message as per the broadcast bit set in the message.
3.3. L2 Relay Agent Behavior
The layer 2 DHCP relay agent may add this sub-option only in the case
when the intermediate network elements does MAC learning ensuring
that when the L3 relay agent unicasts the messages to this hardware
address, the messages will arrive at the same layer 2 DHCP relay
De Cnodder & Kurapati Expires February 18, 2007 [Page 7]
Internet-Draft Unicast Address Sub-Option August 2006
agent. The layer 2 DHCP relay agent SHOULD still be able to receive
broadcast messages from the L3 DHCP relay agent in order to remain
compatible with relay agents that do not support the unicast-address
sub-option.
Layer 2 DHCP relay agent MUST always process the broadcast flag as
described in [RFC2131]. This means that it is possible that the
layer 2 DHCP relay agents receive a unicast message from the L3 DHCP
relay agent, and that it has to forward it as a broadcast. It is
also possible that the unicast message stays unicast and that only
the destination MAC address has to be changed to the content of the
chaddr field.
If the layer 2 DHCP relay agent performs a MAC address concentration
function, it SHOULD add the unicast-address sub-option to all
upstream DHCP messages in order to avoid flooding of unknown
destination MAC addresses. On the other hand, if the layer 2 DHCP
relay agent acts as a bridge, it MAY add the unicast-address sub-
option only to the DHCPDISCOVER and DHCPREQUEST messages as these are
the only messages which may result in a downstream broadcast.
Any host connected to a L2 relay agent can add an option 82 with this
new sub-option and send to L2 Relay Agent. To prevent this all
downstream ports on the L2 DHCP relay agent SHOULD be treated as non
trusted entities and any packet arriving on this interface with
Option 82 added SHOULD be silently discarded. In case L2 relay agent
is further downstream of Access node, it SHOULD be ensured that
access node does not act as L2 relay agent for that line.
3.4. DHCP Server Behavior
Although rather unlikely, it is also possible that no L3 DHCP relay
agent is configured in the network and that the DHCP server has layer
2 connectivity with the trusted layer 2 DHCP relay agent. In this
case the DHCP server, supporting the unicast address option, SHOULD
act as a L3 DHCP relay agent would do.
So if the DHCP server receives DHCP messages with giaddr set to zero
and a valid unicast-address sub-option, the DHCP server SHOULD ignore
the broadcast flag and unicast the DHCP messages to the hardware
address in the unicast-address sub-option. Server SHOULD also
include this sub-option in the option 82 of its reply.
3.5. Example Scenarios
In a first example, the trusted layer 2 DHCP relay agent acts as a
bridge. In such a case, the layer 2 DHCP relay agent puts the MAC
address in the chaddr field of DHCP messages in the unicast-address
De Cnodder & Kurapati Expires February 18, 2007 [Page 8]
Internet-Draft Unicast Address Sub-Option August 2006
sub-option. The L3 DHCP relay agent will then send the DHCPOFFER and
DHCPACK messages from the DHCP server as unicast to the layer 2 DHCP
relay agent, which converts the message to broadcast if the broadcast
flag is set.
In the second case L2 DHCP relay agent does MAC translation/
concentration function.In this case layer 2 DHCP relay agent adds
unicast-address sub-option which contains the MAC address that the
layer 2 DHCP relay agent is using for upstream frames.
De Cnodder & Kurapati Expires February 18, 2007 [Page 9]
Internet-Draft Unicast Address Sub-Option August 2006
4. Security Consideration
o The unicast-address sub-option only applies to a network where
there is a trusted layer 2 DHCP relay agent. No new security
issues with respect to such a network architecture are introduced
by the unicast-address sub-option.
De Cnodder & Kurapati Expires February 18, 2007 [Page 10]
Internet-Draft Unicast Address Sub-Option August 2006
5. IANA Considerations
IANA is requested to assign a value from the DHCP Relay Agent Sub-
options space defined in [RFC3046] for the unicast-address sub-option
defined in Section 3.
De Cnodder & Kurapati Expires February 18, 2007 [Page 11]
Internet-Draft Unicast Address Sub-Option August 2006
6. Acknowledgments
The authors would like the acknowledge Ludwig Pauwels and Paul
Reynders for their comments on this document. Thanks to Patrick
Mensch who contributed for the initial version of this draft. Thanks
to Ted Lemon, Andre Kostur and Bharat Joshi for suggesting
improvements for this new option.
De Cnodder & Kurapati Expires February 18, 2007 [Page 12]
Internet-Draft Unicast Address Sub-Option August 2006
7. References
7.1. Normative Reference
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
January 2001.
[3] Cohen, A. and E. Shrum, "Migration to Ethernet Based DSL
Aggregation", Tecnical Report 101, DSL Forum, April 2006.
[4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[5] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002.
7.2. Informative Reference
[6] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
De Cnodder & Kurapati Expires February 18, 2007 [Page 13]
Internet-Draft Unicast Address Sub-Option August 2006
Authors' Addresses
Stefaan De Cnodder
Alcatel
Francis Wellesplein 1,
B-2018 Antwerp
Belgium
Email: stefaan.de_cnodder@alcatel.be
URI: http://www.alcatel.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/
De Cnodder & Kurapati Expires February 18, 2007 [Page 14]
Internet-Draft Unicast Address Sub-Option August 2006
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 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 Internet Society (2006). 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.
De Cnodder & Kurapati Expires February 18, 2007 [Page 15]
