--- 1/draft-ietf-dhc-l2ra-04.txt 2011-04-07 10:16:21.000000000 +0200 +++ 2/draft-ietf-dhc-l2ra-05.txt 2011-04-07 10:16:21.000000000 +0200 @@ -1,94 +1,92 @@ DHC Working Group B. Joshi -Internet-Draft P. Kurapati -Expires: October 23, 2009 Infosys Technologies Ltd. - April 21, 2009 +Internet-Draft Infosys Technologies Ltd. +Intended status: Informational P. Kurapati +Expires: October 9, 2011 Juniper Networks + April 7, 2011 Layer 2 Relay Agent Information - draft-ietf-dhc-l2ra-04.txt + draft-ietf-dhc-l2ra-05.txt + +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 device that is + closest to the end hosts to append a 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 a Layer 2 + Relay Agent is in use and also how it handles DHCP messages. Status of this Memo - This Internet-Draft is submitted to IETF in full conformance with the + This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and 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. + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. 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 October 23, 2009. + This Internet-Draft will expire on October 9, 2011. Copyright Notice - Copyright (c) 2009 IETF Trust and the persons identified as the + Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect - to this document. - -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 device that is - closest to the end hosts to append a 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 a Layer 2 - Relay Agent is in use and also how it handles DHCP messages. + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Need of Layer 2 Relay Agent . . . . . . . . . . . . . . . . . 6 - 4. Layer 2 Relay Agent in various network scenarios . . . . . . . 7 - 4.1. DHCP server and client on same subnet . . . . . . . . . . 7 - 4.1.1. Client-server interaction . . . . . . . . . . . . . . 7 - 4.1.2. Issues due to introduction of Layer 2 Relay Agent . . 9 - 4.2. Multiple DHCP server and Client on same subnet . . . . . . 9 - 4.2.1. Client-server interaction . . . . . . . . . . . . . . 10 - 4.2.2. Issues due to introduction of Layer 2 Relay Agent . . 10 + 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.3.1. Client-server interaction . . . . . . . . . . . . . . 11 - 4.3.2. Issues due to introduction of Layer 2 Relay Agent . . 13 - 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 17 - 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 + Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.3.1. Client-server interaction . . . . . . . . . . . . . . 10 + 4.3.2. Issues due to introduction of Layer 2 Relay Agent . . 12 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 16 + 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction DHCP Relay Agents eliminate the necessity of having a DHCP server on each physical network. Relay Agents populate the 'giaddr' field and also append the '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 an IP routing aware device and are referred as Layer 3 Relay Agents. @@ -251,23 +249,26 @@ message normally without removing the Relay Agent option since it had not added the same. 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. Layer 2 Relay Agent #1 handles this message similar to how it handles a DHCPDISCOVER message. 6. The server receives the DHCPREQUEST message from the client and - responds with a DHCPACK/DHCPNACK message. A DHCP server may - unicast the DHCPACK message. The Layer 2 Relay Agent processes - the DHCPACK message similar to a DHCPOFFER message. + responds with a DHCPACK/DHCPNAK message. If DHCP server + broadcasts the DHCPACK message, Layer 2 Relay Agent processes it + similar to a DHCPOFFER message. If DHCP server unicasts the + DHCPACK message to the client, Layer 2 Relay agent intercepts the + same and processes the message similar to the broadcasted DHCPACK + message. 7. The Layer 2 Relay Agent processes a DHCPNAK messages similar to a DHCPACK message. 8. The Layer 2 Relay Agent processes a DHCPDECLINE message similar to a DHCPDISCOVER message. 9. The DHCP client can unicast some of the DHCP messages. The Layer 2 Relay Agent may or may not intercept these messages based on internal configuration. If Layer 2 Relay Agents intercept these @@ -283,24 +284,26 @@ field set in the message. 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. There is a case when the DHCP client receives a unicast reply message like DHCPACK with a Relay Agent Information option. This - may happen when the DHCP server unicasts the DHCPACK message and - the Layer 2 Relay Agent is configured not to intercept unicast - messages. In such a case, the DHCP client can ignore the Relay - Agent Information option. + can happen only when the DHCP server unicasts the DHCPACK message + and the Layer 2 Relay Agent is not configured to intercept + unicast messages. Most of the Layer 2 Relay Agents, that are + deployed today, are configured to intercept the unicast DHCP + messages and hence this behaviour may not be seen in the real + world deployments. 3. A DHCP server should be able to handle a unicast DHCP message containing a Relay Agent Information option. Some existing DHCP server implementations do not echo back the Relay Agent Information option in responses to unicast messages. 4.2. Multiple DHCP server and Client on same subnet In certain network scenarios, there could be multiple DHCP servers on the same subnet. Figure 2 shows a typical network setup. @@ -462,39 +465,40 @@ received. This helps the Layer 3 Relay Agent to identify the outgoing interface for the DHCP replies. In some cases, a Layer 3 Relay Agent may use unnumbered interfaces. In this case, it has to use a system wide 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 message and use this state to identify the outgoing interface. - 3. A 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 the DHCP server sees a DHCPREQUEST - without 'giaddr' and Relay Agent Information option as a RENEW - request. On the other hand, a REBIND request is broadcast and so - the DHCP server expects it to contain 'giaddr' field and a Relay - Agent Information option. If the Layer 2 Relay Agent is - configured to intercept unicast messages, it will append a Relay - Agent Information option to the unicast DHCP message. Because of - this, it could be difficult for the DHCP server to differentiate - between a RENEWING and REBINDING state. + 3. The DHCP server uses certain parameters to differentiate the + RENEW and REBIND state of a client. A DHCPREQUEST without + 'giaddr' and the Relay Agent Information option is treated as + RENEW request while DHCPREQUEST with 'giaddr' and Relay Agent + Information option is treated as REBIND request. In a network + configuration where both Layer 2 Relay Agent and Layer 3 Relay + Agent are configured to intercept the unicast DHCP messages, the + DHCP server will receive RENEW request with Relay Agent + Information option and 'giaddr' field set. Since REBIND request + will also have Relay Agent Information option and 'giaddr' field + set, it becomes difficult for the DHCP server to differentiate + between RENEW and REBIND requests. -5. Acknowledgments +5. Acknowledgements This document is the result of a discussion on DHC WG mailing list. Thanks to David W. Hankins and Michael Wacker for providing inputs on some of the existing implementations. Thanks to Ted Lemon, Mukund - Kamath, Alfred Hoenes and Stefaan De Cnodder for reviewing the draft - and providing valuable suggestions. + Kamath, Alfred Hoenes, Ramesh and Stefaan De Cnodder for reviewing + the draft and providing valuable suggestions. 6. Security Considerations o A Layer 2 Relay Agent should always be configured to identify a trustable entity so that it appends a Relay Agent Information option to a DHCP message coming from a trustable entity and forwards it. If a DHCP message is received from a non-trustable entity, the Layer 2 Relay Agent should discard it and may report to the administrator. @@ -541,17 +545,17 @@ 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 + Juniper Networks + Embassy Prime Buildings, C.V. Raman Nagar + Bangalore 560 093 India - Email: pavan_kurapati@infosys.com - URI: http://www.infosys.com/ + Email: kurapati@juniper.net + URI: http://www.juniper.net/