DHC Working Group B. Joshi Internet-Draft P. Kurapati Expires: May 13, 2008 Infosys Technologies Ltd. November 10, 2007 Layer 2 Relay Agent Information draft-joshi-dhc-l2ra-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 May 13, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract In some networks, DHCP servers rely on Relay Agent Information option appended by Relay Agents for IP address and other parameter assignment policies. This works fine when End Hosts are directly connected to Relay Agents. In some network configurations, one or more Layer 2 devices may reside between DHCP clients and Relay agent. In these network scenarios, it is difficult to use the Relay Agent Information option for IP address and other parameter assignment policies effectively. So there is a need for the closest Layer 2 Joshi & Kurapati Expires May 13, 2008 [Page 1] Internet-Draft Layer 2 Relay Agent Information November 2007 device to append Relay Agent Information option in DHCP messages. These devices are typically known as Layer 2 Relay Agents. This document aims to describe the network scenarios where Layer 2 Relay Agent is in use and also how it handles DHCP messages. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Need of Layer 2 Relay Agent . . . . . . . . . . . . . . . . . 5 4. Layer 2 Relay Agent in various network scenarios . . . . . . . 6 4.1. DHCP server and client on same subnet . . . . . . . . . . 6 4.1.1. Client-server interaction . . . . . . . . . . . . . . 6 4.1.2. Issues due to introduction of Layer 2 Relay Agent . . 8 4.2. Multiple DHCP server and Client on same subnet . . . . . . 8 4.2.1. Client-server interaction . . . . . . . . . . . . . . 9 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 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3.1. Client-server interaction . . . . . . . . . . . . . . 10 4.3.2. Issues due to introduction of Layer 2 Relay Agent . . 10 5. Enhancements in Layer 2 Relay Agent . . . . . . . . . . . . . 12 5.1. Broadcasting DHCP requests on all ports . . . . . . . . . 12 5.2. A Layer 3 Relay Agent broadcasting a DHCP reply . . . . . 12 5.3. Maintaining Lease Information by Layer 2 Relay Agent . . . 12 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 16 9.2. Informative Reference . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Joshi & Kurapati Expires May 13, 2008 [Page 2] Internet-Draft Layer 2 Relay Agent Information November 2007 1. Introduction DHCP Relay Agents eliminate the necessity of having a DHCP server on each physical network. Relay Agents populate the 'giaddr' field as they deem appropriate and also add 'Relay Agent Information' option to the DHCP messages. DHCP servers use this option for IP address and other parameter assignment policies. These DHCP Relay Agents are typically a IP routing aware device and sometimes are referred as Layer 3 Relay Agent. In some networks, there is a need for Layer 2 devices to add Relay Agent Information option as they are closer to the end hosts. These Layer 2 devices can not relay the message to the DHCP servers as they are confiured in bridging mode. 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 fits in and how it is used. This document also looks at various network scenarios with Layer 2 Relay Agent and issues that are involved. Joshi & Kurapati Expires May 13, 2008 [Page 3] Internet-Draft Layer 2 Relay Agent Information November 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 "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 "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 while generating IP packets. Joshi & Kurapati Expires May 13, 2008 [Page 4] Internet-Draft Layer 2 Relay Agent Information November 2007 3. Need of Layer 2 Relay Agent A Layer 2 device intercepts DHCP messages for following reasons: 1. In some network deployments like xDSL, the subscriber aggregation devices (also known as Access Concentrator or a DSLAM in case of DSL) are configured to act as bridges. As these devices are closest to the subscriber, they are in the best postion to provide a unique Relay Agent Information option to enforce policies in DHCP server. Some existing implementation intercepts only broadcast messages while some of them intercepts unicast messages as well. If a Layer 2 Relay Agent intercepts a DHCP message, it appends Relay Agent Information option in DHCP message and forwards it. 2. In some networks, the Layer 2 Switch which is closest to the end users, snoops the DHCP messages. These switches extract DHCP Lease Information and use this information to install packet filters. This helps in preventing the Layer 2 and Layer 3 spoofing attempts by the subscribers. A point to note here is that in cases where switches maintain the Lease Information, they have to intercept unicast DHCP messages as well to keep this information upto date. 3. 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 in updating this list. Joshi & Kurapati Expires May 13, 2008 [Page 5] Internet-Draft Layer 2 Relay Agent Information November 2007 4. Layer 2 Relay Agent in various network scenarios This section describes the various network scenarios where a Layer 2 Relay Agent fits in. It also describes how it handles different DHCP messages. 4.1. DHCP server and client on same subnet In certain network configurations, DHCP server may reside on the same subnet as the DHCP clients. A Layer 2 aggregation device resides between the DHCP clients and DHCP server. Following points describe how this Layer 2 device handles various DHCP messages if it acts as a Layer 2 Relay Agent. Figure #1 shows a typical network setup. +--------+ | End | +--------+ | | Host#1 +-----------| | | +-----------+ +--------+ | Layer +-----| | | | 2 | +-----| DHCP | +--------+ | device | | | Server#1 | | End +-----------| #1 | | +-----------+ | Host#2 | +--------+ | +--------+ | | +--------+ | | End | +--------+ | | Host#3 +-----------| | | +--------+ | Layer +-----| | 2 | | +--------+ | device | | | End +-----------| #2 | | Host#n | +--------+ +--------+ Figure 1 4.1.1. Client-server interaction The following summary of protocol message exchanges between clients and DHCP servers describes how they are handlded in Layer 2 Relay Agent. 1. The client [End Host #1] broadcasts a DHCPDISCOVER message on its local physical subnet. Layer 2 Relay Agent [#1] intercepts this message, appends Relay Agent Information option and broadcasts it to all the ports except on which it was received. Relay Agent Joshi & Kurapati Expires May 13, 2008 [Page 6] Internet-Draft Layer 2 Relay Agent Information November 2007 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 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 Information option to the message. It may discard this message if it is coming from an untrusted entity. Otherwise, it will broadcast this on all the ports except on which the message was received. If the device is not configured as Layer 2 Relay Agent, it will switch/bridge the message normally. 3. Server responds with a DHCPOFFER message that includes an available network address in the 'yiaddr' field (and other configuration parameters in DHCP options). DHCP server echoes back the Relay Agent Information option in the DHCPOFFER message. Layer 2 Relay Agent intercepts this message and removes the Relay Agent Information option. It usually identify the outgoing port using Relay Agent Information option. If the broadcast bit is clear, it unicasts this message to the identified port otherwise broadcasts it to all the ports except from which this reply message was received. 4. Same DHCPOFFER message will be received by the other Layer 2 Device [#2]. If it is configured as Layer 2 Relay Agent, it broadcast this message normally. This is because it can find out that it had not forwarded the DHCPDISCOVER request. A Layer 2 Relay Agent uses the Relay Agent Information option to find out if it had appended it to the request message. 5. The client receives this DHCPOFFER message and it broadcasts a DHCPREQUEST message that contains the 'server identifier' option to indicate the server it has selected. Layer 2 Relay Agent [#1] handles this message similar to how it handles DHCPDISCOVER message. 6. The server receives the DHCPREQUEST message from the client and responds with a DHCPACK message containing the configuration parameters for the requesting client. A DHCP server may unicast the DHCPACK message if the broadcast bit in the DHCPREQUEST message is not set. DHCP server would echo back the Relay Agent Information option in the reply message. A Layer 2 Relay Agent intercepts this unicast message and remove Relay Agent Information option. It usually identify the outgoing port using Relay Agent Information option. If the broadcast bit is clear, it unicasts this message to the identified port otherwise broadcast it to all the ports except from which this reply message was received. Joshi & Kurapati Expires May 13, 2008 [Page 7] Internet-Draft Layer 2 Relay Agent Information November 2007 7. A server that is unable to satisfy the DHCPREQUEST message, responds with DHCPNACK. Layer 2 Relay Agent process this similar to DHCPACK message. 8. The client receives the DHCPACK message with configuration parameters. If client detects that the address is already in use, it sends a DHCPDECLINE message to the server. Layer 2 Relay Agent process this messages similar to DHCPDISCOVER message. 9. When client knows the address of a DHCP server, it may unicast DHCPDISCOVER, DHCPREQUEST messages to the server. DHCP clients unicast the DHCP messages like DHCPRELEASE and DHCPREQUEST when renewing the lease to the DHCP server. Layer 2 Relay Agent may or may not intercept these messages based on internal configuration. If Layer 2 Relay Agents intercept these messages, they append Relay Agent Information option and forward it towards the DHCP server. They also intercepts the reply messages and remove Relay Agent Information option before forwarding them. 4.1.2. Issues due to introduction of Layer 2 Relay Agent 1. A DHCP server should be able to handle a DHCP message that contains the Relay Agent Information option but the 'giaddr' field in the message is not set. Some existing DHCP server implementations do not echo back the Relay Agent Information option if giaddr is not set. This may lead to issues at Layer 2 Relay Agents as they will not be able to identify the outgoing port correctly and would broadcast it to all ports. Some Layer 2 Relay Agents discard the reply messages if they do not find a Relay Agent Information option in a DHCP reply. 2. A DHCP server should be able to handle a unicast DHCP message containing Relay Agent Information option. Some existing DHCP server implementations do not echo back the Relay Agent Information option in DHCP reply messages. 4.2. Multiple DHCP server and Client on same subnet In certain network scenarios, there could be multiple DHCP server on the same subnet. Figure #2 shows a typical network setup. Joshi & Kurapati Expires May 13, 2008 [Page 8] Internet-Draft Layer 2 Relay Agent Information November 2007 +--------+ | End | +--------+ | | Host#1 +-----------| | | +-----------+ +--------+ | Layer +-----| | | | 2 | +-----| DHCP | +--------+ | device | | | Server#1 | | End +-----------| #1 | | +-----------+ | Host#2 | +--------+ | +--------+ | | +-----------+ +--------+ | | DHCP | | End | +--------+ |-----| Server #2 | | Host#3 +-----------| | | | | +--------+ | Layer +-----| +-----------+ | 2 | | +--------+ | device | | End +-----------| #2 | | Host#n | +--------+ +--------+ Figure 2 4.2.1. Client-server interaction The message exchange are same as explained in 4.1.1. However, due to introduction of multiple DHCP servers the below additional message exchanges may happen 1. When Host [#1] sends DHCPDISCOVER, it will be received by both the DHCP Servers connected to L2RA #1 and both the servers will respond with a DHCPOFFER. So instead of one DHCPOFFER message, Layer 2 Relay Agent would receive two messages. Processing of DHCP messages in the Layer 2 Relay Agent remains the same. 4.2.2. Issues due to introduction of Layer 2 Relay Agent 1. This is same as described in section 4.1.2. 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 which relays the DHCP messages from/to one subnet to/from the DHCP server on another subnet. In access network scenarios, its seen that Access Concentrator works as Layer 2 Relay Agent. Joshi & Kurapati Expires May 13, 2008 [Page 9] Internet-Draft Layer 2 Relay Agent Information November 2007 +--------+ | End | +--------+ | | | Host#1 +--------| | | +-----------+ | +--------+ | Layer +-----| | | | | 2 | +--| Layer 3 |----| +--------+ | device | | | Relay | | | End +--------| #1 | | | Agent #1 | | | Host#2 | +--------+ | +-----------+ | +---------+ +--------+ | | | | | +--| DHCP | +--------+ | | | Server | | End | +--------+ | | | #1 | | Host#3 +--------| | | +---------+ +--------+ | Layer +-----| | 2 | | +--------+ | device | | | End +--------| #2 + | Host#n | +--------+ +--------+ Figure 3 4.3.1. Client-server interaction As far as DHCP message processing is concerned, the presence of Layer 3 Relay Agent is transparent to Layer 2 Relay Agent. So all the messages are handled in the same way as defined in section 4.1.1. 4.3.2. Issues due to introduction of Layer 2 Relay Agent Though the processing of DHCP messages remain the same in Layer 2 Relay Agent, we see some more issues when a Layer 3 Relay Agent is present to relay the DHCP messages to the DHCP server. 1. When a Layer 2 Relay Agent is configured to intercept unicast messages as well, it appends Relay Agent Information option before forwarding them. A Layer 3 Relay Agent may not intercept these unicast messages. Due to this, a DHCP server may not echo back the Relay Agent Information option because the giaddr is not populated. 2. Existing Layer 3 Relay Agents populate the 'giaddr' with the IP address of the interface on which the request was received. This helps Layer 3 Relay Agent to identify the outgoing interface for the DHCP replies. In some case, a Layer 3 Relay Agent may use unnumbered interfaces. In this case, it has to use a system wide Joshi & Kurapati Expires May 13, 2008 [Page 10] Internet-Draft Layer 2 Relay Agent Information November 2007 IP address to populate the 'giaddr' field. Due to this, it becomes difficult to identify the correct outgoing interface for the messages received from the DHCP server. In these cases, some existing Layer 3 Relay Agent implementations maintain an internal state for each DHCP messages and use this state to identify the outgoing interface. 3. DHCP server uses certain parameters to differentiate the RENEW and REBIND state of a client. A DHCP client unicasts a RENEW request to the DHCP server, so DHCP server sees a DHCPREQUEST without 'giaddr' and Relay Agent Information option as RENEW request. While a REBIND request is broadcast and so DHCP server expect it to contain 'giaddr' and Relay Agent Information option. If Layer 2 Relay Agent is configured to intercepts unicast messages, it will append Relay Agent Information option to the unicast DHCP messages. Because of this, it could be difficult for DHCP server to differentiate between a RENEWING and REBINDING state. Joshi & Kurapati Expires May 13, 2008 [Page 11] Internet-Draft Layer 2 Relay Agent Information November 2007 5. Enhancements in Layer 2 Relay Agent This section looks at various possible enhancements in Layer 2 Relay Agents. These enhancements is aimed in increasing the flexibility and efficiency of Layer 2 Relay Agent in general. 5.1. Broadcasting DHCP requests on all ports A normal Layer 2 Relay Agent would broadcast a DHCP request message to all its port except on which the message was received. Because of this, a DHCP request message is received by those devices which would not be interested in it. A configuration of uplink port that leads to a Layer 3 Relay Agent or DHCP server can solve this issue. Some of the existing implementation [Mostly in xDSL Access Concentrators] already supports this. 5.2. A Layer 3 Relay Agent broadcasting a DHCP reply In most of the cases, a Layer 3 Relay Agent would broadcast a DHCP reply. This will again be received by those devices which would not be interested in it. A new sub-option in Relay Agent Information option can solve this issue. 5.3. Maintaining Lease Information by Layer 2 Relay Agent A Layer 2 Relay Agent may maintain the lease information. This information is lost if the Layer 2 Relay Agent reboots. DHCPv4 Leasequery can be extended to solve this issue. Joshi & Kurapati Expires May 13, 2008 [Page 12] Internet-Draft Layer 2 Relay Agent Information November 2007 6. Acknowledgments This document is the result of a discussion on DHC WG mailing list. David W. Hankins and Michael Wacker provided inputs on some of the existing implementations. Joshi & Kurapati Expires May 13, 2008 [Page 13] Internet-Draft Layer 2 Relay Agent Information November 2007 7. Security Consideration o A Layer 2 Relay Agent should always be configured to identify a trustable entity so that it appends Relay Agent Information option to DHCP messages coming from this and forward it. If a DHCP message is received from a non-trustable entity, it should discard it and may report to the administrator. o Introduction of Layer 2 Relay Agent does not introduce any new security issue. Security issues pertaining to Relay Agents in general applies to Layer 2 Relay Agents as well. Joshi & Kurapati Expires May 13, 2008 [Page 14] Internet-Draft Layer 2 Relay Agent Information November 2007 8. IANA Considerations This document does not introduce any new namespaces for the IANA to manage. Joshi & Kurapati Expires May 13, 2008 [Page 15] Internet-Draft Layer 2 Relay Agent Information November 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] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002. 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 May 13, 2008 [Page 16] Internet-Draft Layer 2 Relay Agent Information November 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 May 13, 2008 [Page 17] Internet-Draft Layer 2 Relay Agent Information November 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 May 13, 2008 [Page 18]