Network Working Group S Boyapati Internet-Draft Intended Status: Experimental Juniper Networks Expires: June 27, 2015 January 27 2015 Relay Chaining in DHCPv4 draft-sboyapati-dhcp-relay-chaining-dhcpv4-00.txt Status of this Memo This Internet-Draft is submitted to IETF 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. 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 January 8, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract DHCP Relay Agents eliminate the necessity of having a DHCP server on each physical network. In certain network configurations, a DHCP server may be multiple subnets away from the DHCP client and multiple Relay Agents may be configured to relay DHCP messages to and from DHCP client. Such configuration can be supported only when each Relay Agent adds certain Information to DHCP messages before relaying them. This additional information helps in relaying the DHCP reply back to the DHCP client through the same path. This mechanism is referred as Relay Chaining. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. New sub-options . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. peer-relay-agent-information Sub Option . . . . . . . . . 6 3.2. peer-address Sub Option . . . . . . . . . . . . . . . . . 6 4. Relay Chaining . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Handling DHCP messages in Relay Agent . . . . . . . . . . 7 4.1.1. Handling Broadcast DHCP messages . . . . . . . . . . . 8 4.1.2. Handling Unicast DHCP messages . . . . . . . . . . . . 9 5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 10 6. Special Scenarios . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Multiple Layer 2 Relay Agents between DHCP client and Layer 3 Relay Agent . . . . . . . . . . . . . . . . . . . 11 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 13 9.2. Informative Reference . . . . . . . . . . . . . . . . . . 13 Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction In some network configurations, DHCP server and clients are separated by multiple Relay Agents. One such case is the network configuration where Access Concentrators operate in Transparent Bridging mode as described in document [layer2-relay-agent]. In such configurations, there are situations where each of those relay agents need to add relay-agent-information to the DHCP messages received on its downstream interface. Relay chaining support in DHCPv4 will help in solving following problems: o In some deployments, Layer 3 Relay Agent uses unnumbered interfaces. When these Layer 3 Relay Agents are used along with Layer 2 Relay agents as described in [layer2-relay-agent] , they need to maintain internal states to identify the outgoing interface. Maintaining state information for each packet will not scale as number of DHCP clients increases. With Relay Chaining, Layer 3 Relay Agent can add its own Relay Agent Information option that can be used to identify the outgoing interface for DHCP reply messages. This document describes the enhancements to Relay Agent functionality when multiple Relay Agents are present between DHCP clients and servers. 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 [RFC2119]. This document uses the following terms: o "Access Concentrator" An Access Concentrator is a router or switch at the broadband access provider's edge of a public broadband access network. This document assumes that the Access Concentrator acts as a Transparent Bridge and includes the DHCP relay agent functionality. For example: In DSL environment, this is typically known as DSLAM.(Digital Subscriber Line Access Multiplexer) 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 [RFC951] and RFC1542 [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 Clients. o "Transparent 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 Clients towards the edge network. 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 of another interface while forwarding packets. 3. New sub-options The 'Relay Chaining in DHCPv4' requires the definition of following new sub-options in Relay Agent Information [Option 82] option for DHCP packet beyond those defined by RFC2131 [RFC2131] and RFC2132 [RFC2132]. See also Section 7, IANA Considerations. 3.1. peer-relay-agent-information Sub Option This sub-option is defined under Relay Agent Information option [Option 82]. A Relay Agent can use 'peer-relay-agent-information' sub-option to store the Relay Agent Information option added by the previous Relay Agent. The value field of this sub-option contains the Relay Agent Information option present in the recevied DHCP message. The new sub-option is as shown in the figure below: SubOpt Len Value +------+------+--------------------------+ | X | Len | Option 82 of Previous RA | +------+------+--------------------------+ / \ / \ +------+-----+--------------------+ | 82 | N | i1 | i2 | ... | iN | +------+-----+--------------------+ Code Len Relay Agent Information Figure 1 3.2. peer-address Sub Option 'peer-address' sub-option is used to store the previous Relay Agent's reachable IP address. It SHOULD be typically populated with the same address as mentioned in the 'giaddr' field of the received message. If there are multiple Relay Agents involved, this sub-option helps in forwarding the reply back to the DHCP client through the same path. The 'peer-address' sub-option is as follows: SubOpt Len Sub-option Value +--------+--------+--------------------------------+ | X | 4 | Previous RA's Address (giaddr) | +--------+--------+--------------------------------+ Figure 2 4. Relay Chaining Relay Chaining is defined as the mechanism where multiple Relay Agents are involved in relaying a DHCP message between DHCP clients and server. Each Relay Agent adds Relay Agent Information option to the DHCP message as described below. The option of using relay chaining mechanism MUST be configurable on Relay Agent in order to provide compatibility to the previous solutions. | +-----+ | |Host1|------+ +-----+ | | +-----+ | |Host2|------+ +--------+ +-----+ | | | +--------+ +--------+ +------| | | | | | | | Relay | | Relay | | DHCP | | | Agent |---..---| Agent |--..--| Server | | | #1 | | #2 | | | +-----+ +------| | | | +--------+ |Host3|------+ | | +--------+ +-----+ | +--------+ | +-----+ | |Host4|------+ +-----+ | | | Figure 3 A typical network configuration where Relay Chaining is required is depicted in Figure 3. In the above case, two Relay Agents are involved. Relay Agent #1 does not know the DHCP server and so is configured to reach Relay Agent #2 for all DHCP messages. Relay Agent #2 knows how to reach DHCP server and so relays a DHCP message directly to DHCP server. DHCP server generates the reply messages and sends it to Relay Agent #2 which relays the same to Relay Agent #1. 4.1. Handling DHCP messages in Relay Agent 4.1.1. Handling Broadcast DHCP messages o When a Relay Agent receives a DHCP request message which does not contain the Relay Agent Information option, it SHOULD add the Relay Agent Information option (Option 82 as described in RFC 3046 [RFC3046]) and 'giaddr' field as it deems appropriate. It should relay the DHCP message to the DHCP server or next Relay Agent. If a Relay Agent is a Layer 2 relay agent, it MUST NOT populate the 'giaddr' field in the DHCP message and should process it as per [layer2-relay-agent] o When a Relay Agent receives a DHCP request message which contains a Relay Agent Information option, it SHOULD add the Relay Agent Information Option as it deems appropriate and also populate the 'peer-relay-agent-information' sub-option as described in section 3.1. 4.1.2. Handling Unicast DHCP messages As DHCP Clients unicast RENEW, RELEASE and INFORM messages directly to the DHCP server, these messages are not intercepted by Relay Agents and so these messages does not have any Relay Agent Information options added to them. Some existing Relay Agent implementations maintain lease/location informations for each DHCP client. These implementations intercepts unicast DHCP messages to keep the lease/location information updated. So these Relay Agent adds Relay Agent Information option to unicast DHCP messages as well. Relay Agents and DHCP server process them similar to broadcast messages as described above in section 5.1.1. 5. DHCP Server Behavior DHCP server would still find only one single Relay Agent Information option [ Option 82 ] in the DHCP message which has been relayed by multiple relay agents. Some existing DHCP servers may use the Relay Agent Information option to apply the IP Address and other parameter assignment policies. These DHCP servers will have to employ recursive lookup algorithm to find the relevant Option 82 [the Option 82 which was added by the first Relay Agent]. Server MUST echo back the entire Option 82 as it is. 6. Special Scenarios 6.1. Multiple Layer 2 Relay Agents between DHCP client and Layer 3 Relay Agent There may be a network scenario when there are multiple Layer 2 Relay Agents configured between DHCP clients and Layer 3 Relay Agent. In this case, as described above, each Layer 2 Relay Agent MUST add 'Relay Agent Information' option and MUST not add 'peer-address' sub- option in it. A Layer 2 Relay Agent can use this Relay Agent Information option while relaying the DHCP Reply message back to the DHCP client. 7. Security Consideration o A Relay Agents relaying DHCP messages to another Relay Agent are essentially DHCP clients for the DHCP messages. Thus, RFC3118 [RFC3118] is an appropriate mechanism for these DHCP messages. o To restrict the number of Relay Agents in Relay Chaining, as defined in RFC 1542 [RFC1542], a Relay Agent must silently discard the DHCP message whose 'hops' field exceeds the value 16. A network manager can use configuration option to set this threshold to a smaller value. 8. IANA Considerations This document needs IANA to provide a unique number for the following new suboptions in Relay Agent Information option [Option 82]: o To carry the peer relay agent information option. Please refer to section 3.1 for more details. o To carry the peer address. Please refer to section 3.2 for more details. 9. References 9.1. Normative Reference [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. [RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [layer2-relay-agent] Joshi, B. and P. Kurapati, "Layer 2 Relay Agent", draft draft-ietf-dhc-l2ra-04.txt, February 2009. 9.2. Informative Reference [RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, September 1985. [RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993. [RFC2132] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. Authors' Address Suresh Boyapati Juniper Networks Bangalore 560 103 India Email: sureshkb@juniper.net URI: http://www.juniper.net/