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]