Network Working Group S. De Cnodder Internet-Draft P. Mensch Expires: June 4, 2006 Alcatel December 1, 2005 Unicast Address Sub-Option draft-decnodder-dhc-rai-unicast-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 June 4, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In some network topologies, it is preferred to have a trusted network element between the DHCP client and the DHCP relay agent that adds the DHCP relay-agent-information option but does not set the giaddr field. This document defines a new sub-option for the relay-agent- information option. With this sub-option, the DHCP relay agent will always unicast the messages towards the trusted layer 2 DHCP relay agent with a MAC address that is known in the network. The new sub- option is called the "unicast-address" sub-option. De Cnodder & Mensch Expires June 4, 2006 [Page 1] Internet-Draft Unicast Address Sub-Option December 2005 Table of Contents 1. Requirements notation and Terminology . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Unicast-Address Sub-Option . . . . . . . . . . . . . . . . . . 6 3.1. Unicast-Address Sub-Option Definition . . . . . . . . . . 6 3.2. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . 6 3.3. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . 7 3.4. Example Scenarios . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 De Cnodder & Mensch Expires June 4, 2006 [Page 2] Internet-Draft Unicast Address Sub-Option December 2005 1. Requirements notation and 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 [RFC2119]. This document uses the following terms: "trusted layer 2 DHCP relay agent" A network element that is residing between the DHCP client and the DHCP relay agent. This network element inserts the relay-agent- information option as a DHCP relay agent would do. The DHCP relay agent trusts this option, and does not replace or remove it while transfering the DHCP message towards the server or towards the client. "downstream" Downstream is the direction from the DHCP relay agent towards the DHCP client, possibly passing a trusted layer 2 DHCP relay agent. "upstream" Upstream is the direction from the DHCP client towards the DHCP relay agent, possibly passing a trusted layer 2 DHCP relay agent. De Cnodder & Mensch Expires June 4, 2006 [Page 3] Internet-Draft Unicast Address Sub-Option December 2005 2. Introduction In some network topologies, it is preferred to have a trusted network element between the DHCP client and the DHCP relay agent that adds the DHCP relay-agent-information option [RFC3046] but does not set the giaddr field. An example of such an environment is described in [WT101] where an access node such as a DSLAM adds the relay-agent- information option containing information on the port (e.g., DSL line) of the user who is requesting an IP address. Multiple access nodes can be connected via an Ethernet based aggregation network to an IP edge router that is acting as the relay agent. Such network elements adding the DHCP relay-agent-information option are called "layer 2 DHCP relay agents" in [WT101]. 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 |-----...... DHCP +-----+ | | Relay |Host4|-------| | +-----+ | | +------+ Figure 1: Example network with a trusted layer 2 DHCP relay agent [RFC2131] 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 DHCPACK messages to all access nodes. De Cnodder & Mensch Expires June 4, 2006 [Page 4] Internet-Draft Unicast Address Sub-Option December 2005 Whether or not broadcast is used between the 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 DHCP relay agent to the trusted layer 2 DHCP relay agent, while between the trusted layer 2 DHCP relay agent and the host, the 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 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 DHCP relay agent. Hence, all unicast messages sent by the DHCP relay agent using this MAC address will be flooded to all access nodes. To overcome these 2 previously mentioned problems, this document defines a new sub-option for the relay-agent-information option. With this sub-option, the DHCP relay agent will always unicast the messages towards the trusted layer 2 DHCP relay agent with a MAC address that is known in the network. The new sub-option is called the "unicast-address" sub-option. De Cnodder & Mensch Expires June 4, 2006 [Page 5] Internet-Draft Unicast Address Sub-Option December 2005 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 DHCP relay agent unicasts the messages from the DHCP server with a MAC address known in the network. The MAC address in the unicast- address sub-option MUST be a MAC address that can be used to send unicast packets to the client. The format of the option is as follows: SubOpt Len Hardware address +------+------+------+------+------+--- | TBD | 16 | a1 | a2 | a3 | ... +------+------+------+------+------+--- Note that the encoding of the hardware address field is the same as the chaddr field in a DHCP message (e.g. the length will be fixed to 16 octets). 3.2. DHCP Relay Agent Behavior When the trusted layer 2 DHCP relay agent adds this sub-option to the relay-agent-information option, the DHCP relay agent SHOULD unicast all DHCP messages from the DHCP server towards the layer 2 DHCP relay agent. The destination MAC address SHOULD be the address that is put into the hardware address field of the unicast-address sub-option. The trusted layer 2 DHCP relay agent may add the unicast-address sub- option only in the case that when the DHCP relay agent unicasts the messages to this unicast address, the messages will arrive at the same trusted layer 2 DHCP relay agent. The layer 2 DHCP relay agent SHOULD still be able to receive broadcast messages from the DHCP relay agent in order to remain compatible with relay agents that do not support the unicast-address sub-option. Such DHCP relay agent will still look to the broadcast flag in the flags fields of the DHCP message and forward the DHCPOFFER and DHCPACK messages accordingly. A DHCP relay agent that does support this sub-option, will ignore the broadcast flag and so the trusted layer 2 DHCP relay agent MUST 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 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. De Cnodder & Mensch Expires June 4, 2006 [Page 6] Internet-Draft Unicast Address Sub-Option December 2005 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. 3.3. DHCP Server Behavior Altough rarther unlikely, it is also possible that no 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 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. 3.4. 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 sub-option. The 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. If the trusted layer 2 DHCP relay agent performs a MAC concentration function, then the unicast-address sub-option should contain the MAC address that the layer 2 DHCP relay agent is using for upstream frames. De Cnodder & Mensch Expires June 4, 2006 [Page 7] Internet-Draft Unicast Address Sub-Option December 2005 4. Security Considerations 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 & Mensch Expires June 4, 2006 [Page 8] Internet-Draft Unicast Address Sub-Option December 2005 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 & Mensch Expires June 4, 2006 [Page 9] Internet-Draft Unicast Address Sub-Option December 2005 6. Acknowledgements The authors would like the acknowledge Ludwig Pauwels and Paul Reynders for their comments on this document. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [WT101] Cohen, A. and E. Shrum, "Migration to Ethernet Based DSL Aggregation", Working Text WT-101, DSL Forum, May 2005. De Cnodder & Mensch Expires June 4, 2006 [Page 10] Internet-Draft Unicast Address Sub-Option December 2005 Authors' Addresses Stefaan De Cnodder Alcatel Francis Wellesplein 1 B-2018 Antwerp Belgium Phone: +32 3 240 85 15 Email: stefaan.de_cnodder@alcatel.be Patrick Mensch Alcatel Francis Wellesplein 1 B-2018 Antwerp Belgium Phone: +32 3 240 75 24 Email: patrick.mensch@alcatel.be De Cnodder & Mensch Expires June 4, 2006 [Page 11] Internet-Draft Unicast Address Sub-Option December 2005 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 (2005). 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 & Mensch Expires June 4, 2006 [Page 12]