--- 1/draft-ietf-dhc-l2ra-01.txt 2008-10-02 00:12:36.000000000 +0200 +++ 2/draft-ietf-dhc-l2ra-02.txt 2008-10-02 00:12:36.000000000 +0200 @@ -1,18 +1,18 @@ DHC Working Group B. Joshi Internet-Draft P. Kurapati -Expires: November 17, 2008 Infosys Technologies Ltd. - May 16, 2008 +Expires: April 4, 2009 Infosys Technologies Ltd. + October 1, 2008 Layer 2 Relay Agent Information - draft-ietf-dhc-l2ra-01.txt + draft-ietf-dhc-l2ra-02.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 @@ -23,67 +23,63 @@ 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 November 17, 2008. - -Copyright Notice - - Copyright (C) The IETF Trust (2008). + This Internet-Draft will expire on April 4, 2009. 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 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 + 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 4.3. DHCP server on another subnet with one Layer 3 Relay - Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.3.1. Client-server interaction . . . . . . . . . . . . . . 10 - 4.3.2. Issues due to introduction of Layer 2 Relay Agent . . 12 - 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 - 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 16 - 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 - Intellectual Property and Copyright Statements . . . . . . . . . . 18 + 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 Consideration . . . . . . . . . . . . . . . . . . . . 15 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 17 + 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 + Intellectual Property and Copyright Statements . . . . . . . . . . 19 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. @@ -99,34 +95,35 @@ 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 discusses various issues caused by introduction of Layer 2 Relay Agent. 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]. + document are to be interpreted as described in RFC 2119 [RFC2119]. 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]. + residing on different subnets, per RFC951 [RFC951] and + RFC1542[RFC1542]. 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 @@ -204,97 +201,95 @@ The following summary of protocol message exchanges between clients and DHCP servers describes how they are handled 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 the Relay Agent Information option and broadcasts it to all the ports except on which it was received. Relay Agent Information option could be created as suggested in - RFC 3046[3]. Layer 2 Relay Agent does not set the 'giaddr' + RFC 3046[RFC3046]. 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 append 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. 3. Server responds with a DHCPOFFER message after applying its local policies. DHCP server echoes back the Relay Agent Information option in the DHCPOFFER message. DHCP server can either unicast the reply to MAC address of End Host #1 or broadcast the reply. - In both the cases, the Layer 2 Relay Agent intercepts this + If reply is broadcast, the Layer 2 Relay Agent intercepts this message and removes the Relay Agent Information option. It identifies the outgoing port using Relay Agent Information option - and forwards to the identified interface. + and forwards to the identified interface. A Layer 2 Relay Agent + may be configured to intercept unicast DHCP messages. In such a + case, Layer 2 Relay Agent intercepts unicast DHCP messages and + handle them similar to broadcast messages. 4. Same DHCPOFFER message will be received by the other Layer 2 Device [#2]. If it is configured as Layer 2 Relay Agent, it broadcasts this 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 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. + 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 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 - may intercept this unicast message and process it similar to the - DHCPOFFER message. + responds with a DHCPACK/DHCPNACK message A DHCP server may + unicast the DHCPACK message. Layer 2 Relay Agent processes the + DHCPACK message similar to DHCPOFFER message. - 7. A server that is unable to satisfy the DHCPREQUEST message, - responds with DHCPNACK. Layer 2 Relay Agent process this similar - to DHCPACK message. + 7. Layer 2 Relay Agent process a DHCPNAK messages 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 message similar to DHCPDISCOVER message. + 8. Layer 2 Relay Agent process a DHCPDECLINE message 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 + 9. DHCP client can unicast some of the DHCP messages. 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 intercept 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 without 'giaddr' 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. A DHCP server should be able to handle a unicast DHCP message + 2. There is a case when DHCP clients may receive unicast reply + messages like DHCPACK with Relay Agent Information option. This + may happen when DHCP server unicast the DHCPACK message and Layer + 2 Relay Agent is configured not to intercept unicast messages. + In such a case, DHCP client can ignore the Relay Agent + Information option. + + 3. 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. + 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 server on the same subnet. Figure #2 shows a typical network setup. +--------+ | End | +--------+ | | Host#1 +-----------| | | +-----------+ +--------+ | Layer +-----| | | @@ -466,23 +461,23 @@ If Layer 2 Relay Agent is configured to intercept 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. 5. Acknowledgments 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 Stefaan.De.Cnodder - and Mukund Kamath for reviewing the draft and providing valuable - suggestions + some of the existing implementations. Thanks to Ted Lemon, Mukund + Kamath and Stefaan.De.Cnodder for reviewing the draft and providing + valuable suggestions. 6. 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 a trustable entity 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 @@ -491,43 +486,43 @@ 7. IANA Considerations This document does not introduce any new namespaces for the IANA to manage. 8. References 8.1. Normative Reference - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. + [RFC2119] 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. + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", + RFC 2131, March 1997. - [3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, - January 2001. + [RFC3046] 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. + [RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP + Messages", RFC 3118, June 2001. - [5] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002. + [RFC3232] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002. 8.2. Informative Reference - [6] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, - September 1985. + [RFC951] 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. + [RFC1542] Wimer, W., "Clarifications and Extensions for the + Bootstrap Protocol", RFC 1542, October 1993. - [8] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor + [RFC2132] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. Authors' Addresses Bharat Joshi Infosys Technologies Ltd. 44 Electronics City, Hosur Road Bangalore 560 100 India @@ -536,21 +531,37 @@ Pavan Kurapati Infosys Technologies Ltd. 44 Electronics City, Hosur Road Bangalore 560 100 India Email: pavan_kurapati@infosys.com URI: http://www.infosys.com/ -Intellectual Property Statement +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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. + + 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. + +Intellectual Property 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. @@ -559,31 +570,10 @@ 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 (2008). 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.