Diff: draft-ietf-dhc-dhcpv4-relay-encapsulation-01.txt - draft-porfiri-dhc-dhcpv4-raio-nesting.txt

	draft-ietf-dhc-dhcpv4-relay-encapsulation-01.txt	draft-porfiri-dhc-dhcpv4-raio-nesting.txt


	dhc T. Lemon	DHC C. Porfiri
	Internet-Draft Nominum, Inc.	Internet-Draft J. Arkko
	Intended status: Standards Track H. Deng	Intended status: Standards Track M. Kühlewind
	Expires: January 12, 2012 L. Huang	Expires: 24 April 2024 Ericsson
	China Mobile	22 October 2023
	July 11, 2011


	Relay Agent Encapsulation for DHCPv4	DHCPv4 Relay Agent Information Option Passing Extensions
	draft-ietf-dhc-dhcpv4-relay-encapsulation-01	draft-porfiri-dhc-dhcpv4-raio-nesting-latest

	Abstract	Abstract

	This document describes a general mechanism whereby DHCP relay agents	This document describes a general mechanism whereby DHCP relay agents
	can encapsulate DHCP packets that they are forwarding in the	can encapsulate DHCP packets that they are forwarding in the

	direction of DHCP servers, and decapsulate packets that they are	direction of DHCP servers, and decapsulate packets that they they are
	forwarding toward DHCP clients, so that more than one relay agent can	forwarding toward DHCP clients, so that more than one relay agent can
	insert relay agent suboptions into the forwarding chain.	insert relay agent suboptions into the forwarding chain.


	Status of this Memo	Status of This Memo

	This Internet-Draft is submitted in full conformance with the	This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.	provisions of BCP 78 and BCP 79.

	Internet-Drafts are working documents of the Internet Engineering	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-	working documents as Internet-Drafts. The list of current Internet-

	Drafts is at http://datatracker.ietf.org/drafts/current/.	Drafts is at https://datatracker.ietf.org/drafts/current/.

	Internet-Drafts are draft documents valid for a maximum of six months	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."	material or to cite them other than as "work in progress."


	This Internet-Draft will expire on January 12, 2012.	This Internet-Draft will expire on 24 April 2024.

	Copyright Notice	Copyright Notice


	Copyright (c) 2011 IETF Trust and the persons identified as the	Copyright (c) 2023 IETF Trust and the persons identified as the
	document authors. All rights reserved.	document authors. All rights reserved.

	This document is subject to BCP 78 and the IETF Trust's Legal	This document is subject to BCP 78 and the IETF Trust's Legal

	Provisions Relating to IETF Documents	Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(http://trustee.ietf.org/license-info) in effect on the date of	license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents	Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect	and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must	extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of	described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as	provided without warranty as described in the Revised BSD License.
	described in the Simplified BSD License.

	Table of Contents	Table of Contents


	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4	2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . 5
	2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 6	2.1. RELAYFORWARD Message . . . . . . . . . . . . . . . . . . 6
	2.1. RELAYFORWARD Message . . . . . . . . . . . . . . . . . . . 6	2.2. RELAYREPLY Message . . . . . . . . . . . . . . . . . . . 6
	2.2. RELAYREPLY Message . . . . . . . . . . . . . . . . . . . . 6	2.3. Layer Two Address suboption . . . . . . . . . . . . . . . 6
	2.3. Layer Two Address suboption . . . . . . . . . . . . . . . 6	3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 7	3.1. The fixed-length header . . . . . . . . . . . . . . . . . 8
	3.1. The fixed-length header . . . . . . . . . . . . . . . . . 8	3.2. Relay Segment . . . . . . . . . . . . . . . . . . . . . . 9
	3.2. Relay Segment . . . . . . . . . . . . . . . . . . . . . . 9	3.3. Encapsulation Segment . . . . . . . . . . . . . . . . . . 9
	3.3. Encapsulation Segment . . . . . . . . . . . . . . . . . . 9	4. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . 10
	4. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . 9	4.1. Packet processing . . . . . . . . . . . . . . . . . . . . 10
	4.1. Packet processing . . . . . . . . . . . . . . . . . . . . 10	4.1.1. Packets traveling toward DHCP servers . . . . . . . . 11
	4.1.1. Packets traveling toward DHCP servers . . . . . . . . 11	4.1.2. Packets traveling toward DHCP clients . . . . . . . . 11
	4.1.2. Packets traveling toward DHCP clients . . . . . . . . 11	4.1.3. Anti-spoofing . . . . . . . . . . . . . . . . . . . . 11
	4.1.3. Anti-spoofing . . . . . . . . . . . . . . . . . . . . 11	4.2. Constructing RELAYFORWARD messages . . . . . . . . . . . 12
	4.2. Constructing RELAYFORWARD messages . . . . . . . . . . . . 11	4.2.1. Initializing the fixed-length header . . . . . . . . 12
	4.2.1. Initializing the fixed-length header . . . . . . . . . 11	4.2.2. Initializing the relay segment . . . . . . . . . . . 12
	4.2.2. Initializing the relay segment . . . . . . . . . . . . 12	4.2.3. Fixed header settings for RELAYFORWARD messages . . . 13
	4.2.3. Fixed header settings for RELAYFORWARD messages . . . 12	4.2.4. Fixed header settings for BOOTREQUEST messages . . . 13
	4.2.4. Fixed header settings for BOOTREQUEST messages . . . . 13	4.2.5. Initializing the encapsulation segment . . . . . . . 13
	4.2.5. Initializing the encapsulation segment . . . . . . . . 13	4.3. Decapsulating RELAYREPLY messages . . . . . . . . . . . . 14
	4.3. Decapsulating RELAYREPLY messages . . . . . . . . . . . . 13	4.3.1. Processing relay agent suboptions . . . . . . . . . . 14
	4.3.1. Processing relay agent suboptions . . . . . . . . . . 13	4.3.2. Constructing the decapsulated message . . . . . . . . 14
	4.3.2. Constructing the decapsulated message . . . . . . . . 14	4.4. Retransmitting modified messages . . . . . . . . . . . . 14
	4.4. Retransmitting modified messages . . . . . . . . . . . . . 14	4.5. Layer two relay agents . . . . . . . . . . . . . . . . . 14
	4.4.1. Layer two relay agents . . . . . . . . . . . . . . . . 14	4.5.1. Constructing the headers . . . . . . . . . . . . . . 15
	4.4.1.1. Constructing the headers . . . . . . . . . . . . . 14	4.5.2. Forwarding the modified packet . . . . . . . . . . . 15
	4.4.1.2. Forwarding the modified packet . . . . . . . . . . 15	4.6. Layer Three Relay Agents . . . . . . . . . . . . . . . . 16
	4.4.2. Layer three relay agents . . . . . . . . . . . . . . . 15	4.6.1. Transmitting a decapsulated RELAYREPLY message . . . 16
	4.4.2.1. Transmitting a decapsulated RELAYREPLY message . . 15	4.6.2. Transmitting a decapsulated BOOTREPLY message . . . . 16
	4.4.2.2. Transmitting a decapsulated BOOTREPLY message . . 16	4.6.3. Transmitting other messages . . . . . . . . . . . . . 16
	4.4.2.3. Transmitting other messages . . . . . . . . . . . 16	5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 16
	5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 16	5.1. Receiving RELAYFORWARD messages . . . . . . . . . . . . . 16
	5.1. Receiving RELAYFORWARD messages . . . . . . . . . . . . . 16	5.1.1. Decapsulation . . . . . . . . . . . . . . . . . . . . 17
	5.1.1. Decapsulation . . . . . . . . . . . . . . . . . . . . 16	5.1.2. Processing of decapsulated suboptions . . . . . . . . 17
	5.1.2. Processing of decapsulated suboptions . . . . . . . . 16	5.1.3. Address allocation . . . . . . . . . . . . . . . . . 18
	5.1.3. Address allocation . . . . . . . . . . . . . . . . . . 17	5.1.4. Default link selection algorithm . . . . . . . . . . 18
	5.1.3.1. Default link selection algorithm . . . . . . . . . 17	5.1.5. Other link selection algorithms . . . . . . . . . . . 19
	5.1.3.2. Other link selection algorithms . . . . . . . . . 18	5.2. Responding to RELAYFORWARD messages . . . . . . . . . . . 19
	5.2. Responding to RELAYFORWARD messages . . . . . . . . . . . 18	5.2.1. Constructing a RELAYREPLY encapsulation . . . . . . . 19
	5.2.1. Constructing a RELAYREPLY encapsulation . . . . . . . 18	5.2.2. Transmission of RELAYREPLY messages . . . . . . . . . 20
	5.2.1.1. Constructing the relay segments . . . . . . . . . 19	5.3. Responding to messages other than RELAYFORWARD . . . . . 21
	5.2.1.2. Constructing the fixed-length header . . . . . . . 19	6. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . 21
	5.2.2. Transmission of RELAYREPLY messages . . . . . . . . . 19	7. Layer 2 Relay Agent Information . . . . . . . . . . . . . . . 21
	5.3. Responding to messages other than RELAYFORWARD . . . . . . 20	7.1. Need of Layer 2 Relay Agent . . . . . . . . . . . . . . . 21
	6. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 20	7.2. Layer 2 Relay Agent in various network scenarios . . . . 22
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 20	7.2.1. DHCP server and client on same subnet . . . . . . . . 22
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21	7.2.2. Multiple DHCP server and Client on same subnet . . . 25
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21	7.2.3. DHCP server on another subnet with one Layer 3 Relay
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 21	Agent . . . . . . . . . . . . . . . . . . . . . . . . 27
	9.2. Informative References . . . . . . . . . . . . . . . . . . 22	7.2.4. DHCP server on another subnet with multiple Layer 3
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22	Relay Agents . . . . . . . . . . . . . . . . . . . . 29
		8. Conventions and Definitions . . . . . . . . . . . . . . . . . 30
		9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
		11.1. Normative References . . . . . . . . . . . . . . . . . . 31
		11.2. Informative References . . . . . . . . . . . . . . . . . 32
		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33
		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33

	1. Introduction	1. Introduction

	In some networking environments, it is useful to be able to configure	In some networking environments, it is useful to be able to configure
	relay agents in a hierarchy, so that information from a relay agent	relay agents in a hierarchy, so that information from a relay agent
	close to the client can be combined with information from one or more	close to the client can be combined with information from one or more
	relay agents closer to the server, particularly in cases where the	relay agents closer to the server, particularly in cases where the
	relay agents may be in separate administrative domains.	relay agents may be in separate administrative domains.

	The current Relay Agent Information Option (RAIO) specification	The current Relay Agent Information Option (RAIO) specification

		(Patrick, M., "DHCP Relay Agent Information Option," January 2001.)
	[RFC3046] specifies that when a relay agent receives a packet	[RFC3046] specifies that when a relay agent receives a packet
	containing an RAIO, it must not add an RAIO. This prevents chaining	containing an RAIO, it must not add an RAIO. This prevents chaining
	of RAIOs, and hence prohibits the hierarchical use case.	of RAIOs, and hence prohibits the hierarchical use case.


	DHCP version 6 [RFC3315] provides a much cleaner technique for	DHCP version 6 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
	providing RAIO suboptions to the DHCP server. Rather than appending	C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6
	an information option to the DHCP client's message, the relay agent	(DHCPv6)," July 2003.) [RFC3315] provides a much cleaner technique
	encapsulates the DHCP client message in a new DHCP message which it	for providing RAIO suboptions to the DHCP server. Rather than
	sends to the DHCP server along with any options it chooses to add to	appending an information option to the DHCP client's message, the
	provide information to the DHCP server.	relay agent encapsulates the DHCP client message in a new DHCP
		message which it sends to the DHCP server along with any options it
		chooses to add to provide information to the DHCP server.

	This document specifies a mechanism for providing the same	This document specifies a mechanism for providing the same

	functionality in DHCPv4.	functionality in DHCPv4. it is a republication and fine-tuning of
		ideas discussed earlier in the IETF which did not lead to a standard
		specification, see [I-D.ietf-dhc-dhcpv4-relay-encapsulation]
		[I-D.ietf-dhc-l2ra]. The topic is brought up now due to new
		situations where this kind of functionality is needed (see
		{Need_of_L2RA}).


	1.1. Requirements Language	1.1. Terminology


	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The following terms and acronyms are used in this document:
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].


	1.2. Terminology	* BOOTREPLY message


	The following terms and acronyms are used in this document:	Any DHCP or BOOTP message in which the 'op' field is set to
		BOOTREPLY.


	BOOTREPLY message Any DHCP or BOOTP message in which the 'op'	* BOOTREQUEST message
	field is set to BOOTREPLY.


	BOOTREQUEST message Any DHCP or BOOTP message in which the 'op'	Any DHCP or BOOTP message in which the 'op' field is set to
	field is set to BOOTREQUEST.	BOOTREQUEST.


	DHCP Dynamic Host Configuration Protocol Version 4	* DHCP
	[RFC2131]


	decapsulate the act of de-encapsulating DHCP packets being	Dynamic Host Configuration Protocol Version 4 [RFC2131] (Droms,
	relayed from DHCP servers or relay agents in	R., "Dynamic Host Configuration Protocol," March 1997.)
	the direction of DHCP clients, according to
	this specification.


	encapsulate the act of encapsulating DHCP packets that are	* decapsulate
	being relayed from DHCP clients or relay agents
	toward DHCP servers, according to the method
	described in this specification.


	encapsulating relay agent a relay agent that implements this	The act of de-encapsulating DHCP packets being relayed from DHCP
	specification and is configured to encapsulate.	servers or relay agents in the direction of DHCP clients,
		according to this specification.


	L2RA Layer 2 Relay Agent--a relay agent that doesn't	* encapsulate
	have an IP address reachable by the DHCP
	server.


	L3RA Layer 3 Relay Agent--a relay agent that has an	The act of encapsulating DHCP packets that are being relayed from
	IP address reachable by the DHCP server.	DHCP clients or relay agents toward DHCP servers, according to the
		method described in this specification.


	option buffer the portion of the DHCP packet following the	* encapsulating relay agent
	magic cookie in the 'vend' field of the DHCP
	Packet.


	RAIO Relay Agent Information Option [RFC3046]. Also	A relay agent that implements this specification and is configured
	commonly referred to as "Option 82."	to encapsulate.


	RAIO suboption a DHCP suboption that has been defined for	* L2RA
	encapsulation in the Relay Agent Information
	Option


	relay message a RELAYFORWARD or RELAYREPLY message.	Layer 2 Relay Agent -- a relay agent that doesn't have an IP
		address reachable by the DHCP server.


	RELAYFORWARD message Any DHCP or BOOTP message in which the 'op'	* L3RA
	field is set to RELAYFORWARD.


	RELAYREPLY message Any DHCP or BOOTP message in which the 'op'	Layer 3 Relay Agent -- a relay agent that has an IP address
	field is set to RELAYREPLY.	reachable by the DHCP server.


	silently discard in many places in this specification, the	* option buffer
	implementation is required to silently discard	The portion of the DHCP packet following the magic cookie in the
	erroneous messages. What is meant by 'silently	'vend' field of the DHCP Packet.
	discard' is that the implementation MUST NOT
	send any ICMP message indicating that the	* RAIO
	delivery was in error. It may be desirable for
	the implementation to keep a count of messages	Relay Agent Information Option (Patrick, M., "DHCP Relay Agent
	that have been discarded, either by message	Information Option," January 2001.) [RFC3046]. Also commonly
	type or by reason for discarding, or some	referred to as "Option 82."
	combination. Nothing in this specification
	should be construed to forbid such data	* RAIO suboption
	collection.
		A DHCP suboption that has been defined for encapsulation in the
		Relay Agent Information Option

		* relay message

		A RELAYFORWARD or RELAYREPLY message.

		* RELAYFORWARD message:

		Any DHCP or BOOTP message in which the 'op' field is set to
		RELAYFORWARD.

		* RELAYREPLY message:

		Any DHCP or BOOTP message in which the 'op' field is set to
		RELAYREPLY.

		* silently discard: In many places in this specification, the
		implementation is required to silently discard erroneous messages.
		What is meant by 'silently discard' is that the implementation
		MUST NOT send any ICMP message indicating that the delivery was in
		error. It may be desirable for the implementation to keep a count
		of messages that have been discarded, either by message type or by
		reason for discarding, or some combination. Nothing in this
		specification should be construed to forbid such data collection.

	2. Protocol Summary	2. Protocol Summary

	This document specifies two new BOOTP message types: the RELAYFORWARD	This document specifies two new BOOTP message types: the RELAYFORWARD
	message, and the RELAYREPLY message. These messages are analogous to	message, and the RELAYREPLY message. These messages are analogous to

	the Relay Forward and Relay Reply messages in DHCPv6 [RFC3315].	the Relay Forward and Relay Reply messages in DHCPv6 (Droms, R.,
		Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic
		Host Configuration Protocol for IPv6 (DHCPv6)," July 2003.)
		[RFC3315].

	Although this specification is generally aimed at DHCP	Although this specification is generally aimed at DHCP
	implementations, it is not specifically restricted to DHCP, and is	implementations, it is not specifically restricted to DHCP, and is
	applicable to BOOTP in cases where the BOOTP server is a DHCP server	applicable to BOOTP in cases where the BOOTP server is a DHCP server
	that implements this specification, or the less likely case that the	that implements this specification, or the less likely case that the
	BOOTP server only supports the BOOTP protocol, but still implements	BOOTP server only supports the BOOTP protocol, but still implements
	this specification.	this specification.

	In general, when the term "DHCP" appears in this specification, the	In general, when the term "DHCP" appears in this specification, the
	reader should not read this as intending to exclude BOOTP.	reader should not read this as intending to exclude BOOTP.

	skipping to change at page 6, line 49	skipping to change at page 6, line 43
	where there is an L3RA on the path to the client, the DHCP server	where there is an L3RA on the path to the client, the DHCP server
	will encode the link layer address that would normally go in the	will encode the link layer address that would normally go in the
	chaddr field of the DHCP packet into a Layer Two Address suboption.	chaddr field of the DHCP packet into a Layer Two Address suboption.

	0 1 2 3	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| SUBOPT_L2AS \| length \| htype \| chaddr ...	\| SUBOPT_L2AS \| length \| htype \| chaddr ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


		Figure 1: Layer 2 Address Suboption

	The Layer Two Address suboption has four fields:	The Layer Two Address suboption has four fields:


	SUBOPT_L2AS One octet: the suboption code for the Layer Two Address	* SUBOPT_L2AS
	suboption (TBD).


	length One octet: the length of the Layer Two Address suboption.	One octet - suboption code for the Layer Two Address suboption
		(TBD).


	htype One octet: the type of the Layer Two Address suboption--	* length
	corresponds to the 'htype' field in a non-relay DHCP or BOOTP	One octet - length of the Layer Two Address suboption.
	message.


	chaddr One or more octets: the layer two address of the client, from	* htype
	the 'chaddr' field of the DHCP or BOOTP message.
		One octet - type of the Layer Two Address suboption -- corresponds
		to the 'htype' field in a non-relay DHCP or BOOTP message.

		* chaddr

		One or more octets - layer two address of the client, from the
		'chaddr' field of the DHCP or BOOTP message.

	3. Encoding	3. Encoding

	RELAYFORWARD and RELAYREPLY messages are distinguished through the	RELAYFORWARD and RELAYREPLY messages are distinguished through the
	use of the 'op' field of the DHCP packet.	use of the 'op' field of the DHCP packet.

	In non-relay DHCP packets, the 'op' field either contains	In non-relay DHCP packets, the 'op' field either contains
	BOOTREQUEST, for any DHCP message from the client to the server, or	BOOTREQUEST, for any DHCP message from the client to the server, or
	BOOTREPLY, for any DHCP message from the server to the client.	BOOTREPLY, for any DHCP message from the server to the client.

	This document defines two additional codes, RELAYFORWARD and	This document defines two additional codes, RELAYFORWARD and
	RELAYREPLY. Conforming DHCP servers and DHCP relay agents MUST	RELAYREPLY. Conforming DHCP servers and DHCP relay agents MUST
	support these two new values for the 'op' field. DHCP clients should	support these two new values for the 'op' field. DHCP clients should
	never see either value.	never see either value.


	+------+--------------+	\|-----:\|:--------------\|
	\| code \| meaning \|	\| code \| meaning \|
	+------+--------------+	\|-----:\|:--------------\|
	\| 1 \| BOOTREQUEST \|	\| 1 \| BOOTREQUEST \|
	\| 2 \| BOOTREPLY \|	\| 2 \| BOOTREPLY \|
	\| 3 \| RELAYFORWARD \|	\| 3 \| RELAYFORWARD \|
	\| 4 \| RELAYREPLY \|	\| 4 \| RELAYREPLY \|
	+------+--------------+	\|-----:\|:--------------\|


	Values for the 'op' field	Figure 2

	RELAYFORWARD and RELAYREPLY messages share only the 'op' field in	RELAYFORWARD and RELAYREPLY messages share only the 'op' field in
	common with other DHCP and BOOTP messages. The remainder of the	common with other DHCP and BOOTP messages. The remainder of the
	message consists of a series of fixed-length fields followed by two	message consists of a series of fixed-length fields followed by two
	variable-length fields: the relay segment, and the encapsulated	variable-length fields: the relay segment, and the encapsulated
	message.	message.


	+-----+-----+-----+-----+	+-----+-----+-----+-----+
	\| op \| ep \| padlen \|	\| op \| ep \| padlen \|
	+-----+-----+-----+-----+	+-----+-----+-----+-----+
	\| rslen \| caplen \|	\| rslen \| caplen \|
	+-----+-----+-----+-----+	+-----+-----+-----+-----+
	\| aiaddr \|	\| aiaddr \|
	+-----+-----+-----+-----+	+-----+-----+-----+-----+
	. .	. .
	. relay segment .	. relay segment .
	. .	. .
	+-----------------------+	+-----------------------+
	. .	. .
	. encapsulated message .	. encapsulated message .
	. .	. .
	+-----------------------+	+-----------------------+

		Figure 3: Structure of RELAYFORWARD and RELAYREPLY messages

	3.1. The fixed-length header	3.1. The fixed-length header

	The fixed-length header of the relay message contains a series of	The fixed-length header of the relay message contains a series of
	fields that perform two purposes: to provide enough information that	fields that perform two purposes: to provide enough information that
	the DHCP server can reconstruct the original packet sent by the DHCP	the DHCP server can reconstruct the original packet sent by the DHCP
	client, and to establish the lengths of the two variable-length	client, and to establish the lengths of the two variable-length
	segments.	segments.

	To satisfy the first of these requirements, two fields in the fixed-	To satisfy the first of these requirements, two fields in the fixed-
	length header report the amount of padding stripped from the client	length header report the amount of padding stripped from the client
	message, if any, and whether or not an end option was stripped from	message, if any, and whether or not an end option was stripped from
	the client message. Except for a relay message that immediately	the client message. Except for a relay message that immediately
	encapsulates a message from a DHCP client, these fields are always	encapsulates a message from a DHCP client, these fields are always
	zero. Using these two fields, the DHCP server can reconstruct the	zero. Using these two fields, the DHCP server can reconstruct the
	client packet exactly, and this allows the DHCP server to validate	client packet exactly, and this allows the DHCP server to validate

	any signature [RFC3118] that may be present.	any signature (Droms, R. and W. Arbaugh, "Authentication for DHCP
		Messages," June 2001.) [RFC3118] that may be present.

	The fixed-length header consists of five fields:	The fixed-length header consists of five fields:


	op The BOOTP 'op' field, which, for a relay message, MUST contain the	* op

		The BOOTP 'op' field, which, for a relay message, MUST contain the
	RELAYFORWARD or RELAYREPLY code.	RELAYFORWARD or RELAYREPLY code.


	ep If an End option was present in the option buffer prior to	* ep

		If an End option was present in the option buffer prior to
	encapsulation, this field is set to 1; otherwise, it is set to 0.	encapsulation, this field is set to 1; otherwise, it is set to 0.
	This field is a single byte.	This field is a single byte.


	padlen The length of any padding that was removed from the option	* padlen
	buffer prior to encapsulation: two bytes in network byte order.


	rslen The length of the relay segment: two byte in network byte	The length of any padding that was removed from the option buffer
		prior to encapsulation: two bytes in network byte order.

		* rslen

		The length of the relay segment: two byte in network byte order.

		* caplen

		The length of the encapsulation segment: two byte in network byte
	order.	order.


	caplen The length of the encapsulation segment: two byte in network	* aiaddr
	byte order.


	aiaddr Relay agent IP address.	Relay agent IP address.

	3.2. Relay Segment	3.2. Relay Segment

	The relay segment contains any RAIO suboptions that the encapsulating	The relay segment contains any RAIO suboptions that the encapsulating
	agent (the relay agent or the DHCP server) wishes to send. End and	agent (the relay agent or the DHCP server) wishes to send. End and

	Pad options MUST NOT appear in the relay segment.	Pad options MUST NOT appear within the relay segment.

	3.3. Encapsulation Segment	3.3. Encapsulation Segment

	The encapsulation segment contains the entire DHCP message being	The encapsulation segment contains the entire DHCP message being
	encapsulated, with four exceptions:	encapsulated, with four exceptions:


	o The encapsulating agent MUST omit the IP and UDP headers, as well	* The encapsulating agent MUST omit the IP and UDP headers, as well
	as any layer two header, from the encapsulated message.	as any layer two header, from the encapsulated message.


	o The encapsulating agent MUST omit any options following the first	* The encapsulating agent MUST omit any options following the first
	End option in the option buffer. These options are assumed to be	End option in the option buffer. These options are assumed to be

	garbage, and are not covered by any signature [RFC3118].	garbage, and are not covered by any signature (Droms, R. and W.
		Arbaugh, "Authentication for DHCP Messages," June 2001.)
		[RFC3118].


	o The encapsulating MUST omit any Pad options present either at the	* The encapsulating MUST omit any Pad options present either at the
	end of the option buffer, or prior to the first End option, that	end of the option buffer, or prior to the first End packet, that
	are followed only by other Pad options or a single End option.	are followed only by other Pad options or a single End option.
	The encapsulating agent MUST record number of Pad options that	The encapsulating agent MUST record number of Pad options that
	were omitted in the 'padlen' field of the message header.	were omitted in the 'padlen' field of the message header.


	o The encapsulating agent MUST omit the End option, if present. The	* The encapsulating agent MUST omit the End option, if present. The
	encapsulating agent MUST set the 'ep' field in the message header	encapsulating agent MUST set the 'ep' field in the message header
	to 1 if an End option was present in the option buffer, and to	to 1 if an End option was present in the option buffer, and to
	zero if no End option was present.	zero if no End option was present.

	These exceptions apply only to the option buffer. The encapsulating	These exceptions apply only to the option buffer. The encapsulating
	agent MUST NOT modify the contents of the 'file' and 'sname' fields.	agent MUST NOT modify the contents of the 'file' and 'sname' fields.
	The encapsulating agent MUST NOT count End or Pad options that appear	The encapsulating agent MUST NOT count End or Pad options that appear
	in these fields.	in these fields.

	4. DHCP Relay Agent Behavior	4. DHCP Relay Agent Behavior

	DHCP Relay agents implementing this specification MUST have a	DHCP Relay agents implementing this specification MUST have a
	configuration parameter controlling relay encapsulation. By default,	configuration parameter controlling relay encapsulation. By default,
	relay encapsulation MUST be disabled.	relay encapsulation MUST be disabled.

	Relay agents with encapsulation disabled MUST NOT encapsulate. Relay	Relay agents with encapsulation disabled MUST NOT encapsulate. Relay
	agents with encapsulation disabled MUST NOT decapsulate.	agents with encapsulation disabled MUST NOT decapsulate.

	In any case where a relay agent implementing this specification does	In any case where a relay agent implementing this specification does
	not encapsulate or decapsulate, it MUST behave exactly as a relay	not encapsulate or decapsulate, it MUST behave exactly as a relay

	agent that does not implement this specification at all.	agent would that did not implement this specification at all.

	DHCP relay agents that are configured with encapsulation enabled, but	DHCP relay agents that are configured with encapsulation enabled, but
	which have no agent-specific options to send to the DHCP server, MUST	which have no agent-specific options to send to the DHCP server, MUST
	encapsulate. Relay agents that are configured with encapsulation	encapsulate. Relay agents that are configured with encapsulation
	enabled MUST decapsulate.	enabled MUST decapsulate.

	Layer two relay agents MUST silently discard any messages that	Layer two relay agents MUST silently discard any messages that

	contains an IPsec authentication header [RFC4302]. This is because	contains an IPsec authentication header (Kent, S., "IP Authentication
	they cannot modify such messages, but also cannot detect that a	Header," December 2005.) [RFC4302]. This is because they cannot
	message from the DHCP server is in response such messages, since the	modify such packets, but also cannot detect that a message from the
	response message might not contain an IPsec authentication header.	DHCP server is in response such a message, since it might not contain
		an IPsec authentication header.
	If a relay message would exceed the MTU of the outgoing interface, it
	MUST be discarded, and an error condition SHOULD be logged.

	4.1. Packet processing	4.1. Packet processing

	Relay agents implementing this specification may receive packets	Relay agents implementing this specification may receive packets
	directed toward DHCP servers with a source port of 67 (BOOTPS).	directed toward DHCP servers with a source port of 67 (BOOTPS).
	Therefore, the source port cannot be used to determine whether the	Therefore, the source port cannot be used to determine whether the
	packet is traveling toward a DHCP server or toward a DHCP client.	packet is traveling toward a DHCP server or toward a DHCP client.

	In order to determine whether a message is traveling toward a DHCP	In order to determine whether a message is traveling toward a DHCP
	client or toward a DHCP server, the relay agent must check the 'op'	client or toward a DHCP server, the relay agent must check the 'op'

	skipping to change at page 11, line 51	skipping to change at page 12, line 14

	4.2. Constructing RELAYFORWARD messages	4.2. Constructing RELAYFORWARD messages

	4.2.1. Initializing the fixed-length header	4.2.1. Initializing the fixed-length header

	The relay agent constructs the RELAYFORWARD message by constructing	The relay agent constructs the RELAYFORWARD message by constructing
	the fixed-length header as specified in the earlier section titled	the fixed-length header as specified in the earlier section titled
	'Encoding'. The relay agent MUST set the 'op' field to a value of	'Encoding'. The relay agent MUST set the 'op' field to a value of
	RELAYFORWARD.	RELAYFORWARD.


	If the relay agent is not a layer two relay agent	If the relay agent is not a layer two relay agent [I-D.ietf-dhc-l2ra]
		(see Section 7), it MUST store one of its own IP addresses in the
	[I-D.ietf-dhc-l2ra], it MUST store one of its own IP addresses in the
	'aiaddr' field. This address MUST be a valid IP address that is	'aiaddr' field. This address MUST be a valid IP address that is
	reachable by the next hop relay(s) or DHCP server(s) to which the	reachable by the next hop relay(s) or DHCP server(s) to which the
	relay agent is configured to forward.	relay agent is configured to forward.

	DHCP servers normally use the relay agent IP address to determine on	DHCP servers normally use the relay agent IP address to determine on
	what link the DHCP client's IP address should be allocated. In some	what link the DHCP client's IP address should be allocated. In some
	cases, the value stored in the 'aiaddr' field will not be a valid IP	cases, the value stored in the 'aiaddr' field will not be a valid IP
	address on the link on which the source message was received. In	address on the link on which the source message was received. In
	this case, the relay agent MUST include a link selection suboption	this case, the relay agent MUST include a link selection suboption

	[RFC3527] that identifies that link in the relay segment.	(Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, "Link
		Selection sub-option for the Relay Agent Information Option for
		DHCPv4," April 2003.) [RFC3527] that identifies that link in the
		relay segment.

	If the relay agent is a layer two relay agent, it MAY include a link	If the relay agent is a layer two relay agent, it MAY include a link
	selection suboption in the relay segment.	selection suboption in the relay segment.

	If the message being encapsulated is a BOOTREQUEST, L2RAs MUST store	If the message being encapsulated is a BOOTREQUEST, L2RAs MUST store
	a value of zero in the 'aiaddr' field. Otherwise, the L2RA MUST copy	a value of zero in the 'aiaddr' field. Otherwise, the L2RA MUST copy
	the value of the 'aiaddr' field in the RELAYFORWARD message being	the value of the 'aiaddr' field in the RELAYFORWARD message being
	encapsulated into the 'aiaddr' field of the RELAYFORWARD message that	encapsulated into the 'aiaddr' field of the RELAYFORWARD message that
	it generates.	it generates.


	skipping to change at page 12, line 38	skipping to change at page 13, line 5
	initialized differently depending on whether the message being	initialized differently depending on whether the message being
	encapsulated is a BOOTREQUEST or a RELAYFORWARD message.	encapsulated is a BOOTREQUEST or a RELAYFORWARD message.

	4.2.2. Initializing the relay segment	4.2.2. Initializing the relay segment

	Following the fixed header, the relay agent MUST append any RAIO	Following the fixed header, the relay agent MUST append any RAIO
	suboptions it wishes to send to the DHCP server; this is the 'relay	suboptions it wishes to send to the DHCP server; this is the 'relay
	segment'. It MUST store the length of the relay segment in the	segment'. It MUST store the length of the relay segment in the
	'rslen' field of the fixed header.	'rslen' field of the fixed header.


	The relay agent SHOULD include a Relay Agent ID suboption	The relay agent SHOULD include a Relay Agent ID suboption (Stapp, M.,
	[I-D.ietf-dhc-relay-id-suboption] in the relay segment to identify	"The DHCPv4 Relay Agent Identifier Suboption," July 2009.) [RFC6925]
	itself to the DHCP server.	in the relay segment to identify itself to the DHCP server.

	4.2.3. Fixed header settings for RELAYFORWARD messages	4.2.3. Fixed header settings for RELAYFORWARD messages

	If the message being encapsulated is a RELAYFORWARD message, the	If the message being encapsulated is a RELAYFORWARD message, the
	relay agent MUST initialize the 'caplen' field of the fixed header to	relay agent MUST initialize the 'caplen' field of the fixed header to
	the length of the source message, excluding any layer 2, IP and UDP	the length of the source message, excluding any layer 2, IP and UDP
	headers. It MUST append the contents of the message, again excluding	headers. It MUST append the contents of the message, again excluding
	any layer 2, IP or UDP headers, to the new message. It MUST	any layer 2, IP or UDP headers, to the new message. It MUST
	initialize the 'ep' and 'padlen' fields in the fixed header of the	initialize the 'ep' and 'padlen' fields in the fixed header of the
	new message to zero.	new message to zero.

	skipping to change at page 13, line 47	skipping to change at page 14, line 16

	To decapsulate a RELAYREPLY message, the relay agent creates a	To decapsulate a RELAYREPLY message, the relay agent creates a
	decapsulated message, processes any RAIO suboptions it recognizes in	decapsulated message, processes any RAIO suboptions it recognizes in
	the relay segment, and forwards the decapsulated message to its	the relay segment, and forwards the decapsulated message to its
	destination.	destination.

	4.3.1. Processing relay agent suboptions	4.3.1. Processing relay agent suboptions

	The suboptions parsed from the relay segment are processed by the	The suboptions parsed from the relay segment are processed by the
	relay agent as specified in the Relay Agent Information Option	relay agent as specified in the Relay Agent Information Option

	specification [RFC3046], as well as in any documents that define	specification (Patrick, M., "DHCP Relay Agent Information Option,"
		January 2001.) [RFC3046], as well as in any documents that define
	suboptions to the Relay Agent Information Option. A current list of	suboptions to the Relay Agent Information Option. A current list of
	DHCP Relay Agent suboptions and the documents that define them can be	DHCP Relay Agent suboptions and the documents that define them can be
	located in the IANA protocol registry for Bootp and DHCP parameters,	located in the IANA protocol registry for Bootp and DHCP parameters,
	in the section titled "DHCP Relay Agent Sub-Option Codes."	in the section titled "DHCP Relay Agent Sub-Option Codes."

	4.3.2. Constructing the decapsulated message	4.3.2. Constructing the decapsulated message

	To construct a decapsulated message, the relay agent copies the	To construct a decapsulated message, the relay agent copies the
	portion of the RELAYREPLY message following the relay segment, with a	portion of the RELAYREPLY message following the relay segment, with a
	length specified in the 'caplen' field of the fixed-length header,	length specified in the 'caplen' field of the fixed-length header,
	into the new message.	into the new message.

	4.4. Retransmitting modified messages	4.4. Retransmitting modified messages

	If the relay agent did not modify the message either by encapsulating	If the relay agent did not modify the message either by encapsulating
	or decapsulating it, it retransmits the message according to existing	or decapsulating it, it retransmits the message according to existing
	practice.	practice.

	Otherwise, how the modified message is transmitted to its next	Otherwise, how the modified message is transmitted to its next
	destination depends on two factors. First, is the relay agent that	destination depends on two factors. First, is the relay agent that

	modified the message a layer two [I-D.ietf-dhc-l2ra] relay agent or a	modified the message a layer two (Joshi, B. and P. Kurapati, "Layer
	layer three [RFC1542] relay agent? Second, is the modified message a	2 Relay Agent Information," April 2009.) [I-D.ietf-dhc-l2ra] relay
		agent (see Section 4.5) or a layer three (Wimer, W., "Clarifications
		and Extensions for the Bootstrap Protocol," October 1993.) [RFC1542]
		relay agent (see Section 4.6)? Second, is the modified message a
	BOOTREPLY message, a RELAYREPLY message, or some other message?	BOOTREPLY message, a RELAYREPLY message, or some other message?


	4.4.1. Layer two relay agents	4.5. Layer two relay agents

	There are two special aspects to the handling of relayed packets in	There are two special aspects to the handling of relayed packets in
	Layer Two Relay Agents (L2RAs). The first is the construction of the	Layer Two Relay Agents (L2RAs). The first is the construction of the
	layer two, IP and UDP headers on the packet. The second is how the	layer two, IP and UDP headers on the packet. The second is how the
	L2RA makes the forwarding decision.	L2RA makes the forwarding decision.


	4.4.1.1. Constructing the headers	4.5.1. Constructing the headers

	The L2RA constructs the headers on the relayed packet by copying and,	The L2RA constructs the headers on the relayed packet by copying and,
	as necessary, modifying the headers from the original packet.	as necessary, modifying the headers from the original packet.

	If there is a layer two header, the L2RA MUST copy this header in	If there is a layer two header, the L2RA MUST copy this header in
	accordance with the needs of the particular layer two implementation	accordance with the needs of the particular layer two implementation
	it is using. If the header contains a packet length field, the L2RA	it is using. If the header contains a packet length field, the L2RA
	MUST adjust the value in the packet length field. If the header	MUST adjust the value in the packet length field. If the header
	contains a non-secure integrity check such as a CRC or checksum that	contains a non-secure integrity check such as a CRC or checksum that
	covers the entire packet, the L2RA MUST recompute this value.	covers the entire packet, the L2RA MUST recompute this value.

	L2RA encapsulation in cases where the layer two contains a secure	L2RA encapsulation in cases where the layer two contains a secure
	integrity check must either construct a new integrity signature, or	integrity check must either construct a new integrity signature, or
	else remove the integrity signature. If neither of these is	else remove the integrity signature. If neither of these is
	possible, the L2RA MUST silently discard the packet.	possible, the L2RA MUST silently discard the packet.


	The L2RA MUST copy the IP header without modification except length	If the IP header contains any sort of secure integrity check on the
	and checksum field which should be recomputed. If the IP header	packet, the L2RA MUST silently discard the packet. The L2RA MUST
	contains any sort of secure integrity check on the packet, the L2RA	adjust Total Length field in the IP header. In other respects, L2RA
	MUST silently discard the packet.	MUST copy the IP header without modification.

	The L2RA MUST copy the UDP header and adjust the 'Length' field	The L2RA MUST copy the UDP header and adjust the 'Length' field

	[RFC0768]. If the contents of the 'Checksum' field are not zero, the	carried within it (Postel, J., "User Datagram Protocol," August
	L2RA MUST compute a new checksum according to the algorithm specified	1980.) [RFC0768]. If the contents of the 'Checksum' field are not
	in User Datagram Protocol. [RFC0768]	zero, the L2RA MUST compute a new checksum according to the algorithm
		specified in User Datagram Protocol. (Postel, J., "User Datagram
		Protocol," August 1980.) [RFC0768]


	4.4.1.2. Forwarding the modified packet	4.5.2. Forwarding the modified packet

	Ordinarily when a layer two device forwards a packet, it simply	Ordinarily when a layer two device forwards a packet, it simply
	copies that packet from the interface on which it was received and	copies that packet from the interface on which it was received and
	transmits it, unchanged, on one or more interfaces other than that	transmits it, unchanged, on one or more interfaces other than that
	interface. The mechanism used to choose which interfaces it forwards	interface. The mechanism used to choose which interfaces it forwards
	the packet to is beyond the scope of this document.	the packet to is beyond the scope of this document.

	Once a DHCP packet has been modified by the L2RA either as an	Once a DHCP packet has been modified by the L2RA either as an
	encapsulation or a decapsulation, the L2RA must forward it either	encapsulation or a decapsulation, the L2RA must forward it either
	toward the DHCP server or the DHCP client. The implementation has	toward the DHCP server or the DHCP client. The implementation has

	skipping to change at page 15, line 38	skipping to change at page 16, line 15
	When processing a RELAYREPLY message, the L2RA MAY use information in	When processing a RELAYREPLY message, the L2RA MAY use information in
	the relay segment of the RELAYREPLY to determine on which network	the relay segment of the RELAYREPLY to determine on which network
	interface the RELAYREPLY should be forwarded.	interface the RELAYREPLY should be forwarded.

	When processing any other message, the L2RA MAY use configuration	When processing any other message, the L2RA MAY use configuration
	information to direct the packet out a specific port or ports that	information to direct the packet out a specific port or ports that
	have been marked as reaching DHCP servers. The L2RA MUST NOT forward	have been marked as reaching DHCP servers. The L2RA MUST NOT forward
	any packet on the interface on which it was received, even if that	any packet on the interface on which it was received, even if that
	interface is so marked.	interface is so marked.


	4.4.2. Layer three relay agents	4.6. Layer Three Relay Agents


	4.4.2.1. Transmitting a decapsulated RELAYREPLY message	4.6.1. Transmitting a decapsulated RELAYREPLY message

	When the decapsulated message is itself a RELAYREPLY message, the	When the decapsulated message is itself a RELAYREPLY message, the
	relay agent MUST forward the decapsulated message to the IP address	relay agent MUST forward the decapsulated message to the IP address
	specified in the 'aiaddr' field of the fixed-length header.	specified in the 'aiaddr' field of the fixed-length header.

	If the relay segment of the packet that was decapsulated contains a	If the relay segment of the packet that was decapsulated contains a
	Link Layer Address suboption, the relay agent MUST transmit the	Link Layer Address suboption, the relay agent MUST transmit the
	packet to that link layer address without attempting to use Address	packet to that link layer address without attempting to use Address
	Resolution Protocol (ARP) to translate the address contained in	Resolution Protocol (ARP) to translate the address contained in
	'aiaddr' to a layer two address.	'aiaddr' to a layer two address.


	4.4.2.2. Transmitting a decapsulated BOOTREPLY message	4.6.2. Transmitting a decapsulated BOOTREPLY message

	When transmitting a decapsulated BOOTREPLY message, the relay agent	When transmitting a decapsulated BOOTREPLY message, the relay agent
	transmits the message as specified in Bootstrap Protocol, Section 4	transmits the message as specified in Bootstrap Protocol, Section 4

		(Croft, B. and J. Gilmore, "Bootstrap Protocol," September 1985.)
	[RFC0951].	[RFC0951].


	4.4.2.3. Transmitting other messages	4.6.3. Transmitting other messages

	When transmitting RELAYFORWARD and BOOTREQUEST messages, the relay	When transmitting RELAYFORWARD and BOOTREQUEST messages, the relay
	agent simply sends the message to the IP address or addresses	agent simply sends the message to the IP address or addresses
	configured as DHCP servers for that relay agent.	configured as DHCP servers for that relay agent.

	5. DHCP Server Behavior	5. DHCP Server Behavior

	A DHCP server which receives a RELAYREPLY message MUST silently	A DHCP server which receives a RELAYREPLY message MUST silently
	discard that message.	discard that message.


	skipping to change at page 17, line 9	skipping to change at page 17, line 35

	5.1.2. Processing of decapsulated suboptions	5.1.2. Processing of decapsulated suboptions

	This section specifies requirements for the processing of	This section specifies requirements for the processing of
	decapsulated relay suboptions in the default case, where no custom	decapsulated relay suboptions in the default case, where no custom
	processing has been specified. This should not be construed to	processing has been specified. This should not be construed to
	forbid implementations for providing mechanisms for customizing the	forbid implementations for providing mechanisms for customizing the
	processing of these suboptions.	processing of these suboptions.

	This document does not specify special handling for DHCP options.	This document does not specify special handling for DHCP options.

	Only the inner encapsulation--the encapsulation of the original	Only the inner encapsulation - the encapsulation of the original
	message sent from the client, which is done by the first	message sent from the client, which is done by the first

	encapsulating relay--can ever contain DHCP Options; hence, whatever	encapsulating relay - can ever contain DHCP Options; hence, whatever
	normal mechanisms a DHCP server provides for processing these options	normal mechanisms a DHCP server provides for processing these options
	should suffice.	should suffice.

	Some relay agent suboptions, such as the Relay Agent Subnet Selection	Some relay agent suboptions, such as the Relay Agent Subnet Selection

	suboption [RFC3527], are intended to be processed by DHCP servers.	suboption (Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
	Others, like the Circuit ID and Remote ID [RFC3046] suboptions, were	"Link Selection sub-option for the Relay Agent Information Option for
	not intended to be processed by the DHCP server, but are often used	DHCPv4," April 2003.) [RFC3527], are intended to be processed by
	by the DHCP server for identification purposes.	DHCP servers. Others, like the Circuit ID and Remote ID (Patrick,
		M., "DHCP Relay Agent Information Option," January 2001.) [RFC3046]
		suboptions, were not intended to be processed by the DHCP server, but
		are often used by the DHCP server for identification purposes.

	In cases where more than one relay agent sends the same suboption,	In cases where more than one relay agent sends the same suboption,
	the DHCP server must either factor all such suboptions into its	the DHCP server must either factor all such suboptions into its
	processing, or choose one such suboption and use that exclusively for	processing, or choose one such suboption and use that exclusively for
	processing.	processing.

	By default, DHCP servers MUST use the outermost suboption (the one	By default, DHCP servers MUST use the outermost suboption (the one
	added by the relay agent closest to the DHCP server) for every	added by the relay agent closest to the DHCP server) for every
	suboption that was sent by more than one relay agent.	suboption that was sent by more than one relay agent.


	skipping to change at page 17, line 46	skipping to change at page 18, line 30
	is connected to the link on which the message was received.	is connected to the link on which the message was received.

	One datum used by DHCP servers in locating the client is the value of	One datum used by DHCP servers in locating the client is the value of
	the 'giaddr' field of the BOOTP header. This specification	the 'giaddr' field of the BOOTP header. This specification
	eliminates the use of giaddr; hence, it cannot be used in the address	eliminates the use of giaddr; hence, it cannot be used in the address
	allocation decision.	allocation decision.

	The functionality provided by giaddr is replaced in this	The functionality provided by giaddr is replaced in this
	specification by the 'aiaddr' field in the fixed-length relay header.	specification by the 'aiaddr' field in the fixed-length relay header.


	5.1.3.1. Default link selection algorithm	5.1.4. Default link selection algorithm

	DHCP servers MUST implement a default algorithm for determining the	DHCP servers MUST implement a default algorithm for determining the
	link to which the client is attached. This algorithm is to first	link to which the client is attached. This algorithm is to first

	search the client message for a subnet selection option [RFC3011].	search the client message for a subnet selection option (Waters, G.,
		"The IPv4 Subnet Selection Option for DHCP," November 2000.)
		[RFC3011].

	The server next searches for link-identifying data in each	The server next searches for link-identifying data in each
	RELAYFORWARD encapsulation, starting from the inner most and ending	RELAYFORWARD encapsulation, starting from the inner most and ending
	at the outermost, until a RELAYFORWARD is found that identifies the	at the outermost, until a RELAYFORWARD is found that identifies the
	client's location.	client's location.

	A RELAYFORWARD encapsulation contains link-identifying data if the	A RELAYFORWARD encapsulation contains link-identifying data if the
	value of the 'aiaddr' field of the fixed-length header is not zero,	value of the 'aiaddr' field of the fixed-length header is not zero,

	or if the relay segment contains a Link Selection suboption	or if the relay segment contains a Link Selection suboption (Kinnear,
	[RFC3527].	K., Stapp, M., Johnson, R., and J. Kumarasamy, "Link Selection sub-
		option for the Relay Agent Information Option for DHCPv4," April
		2003.) [RFC3527].

	If a Link Selection suboption is present in the innermost	If a Link Selection suboption is present in the innermost
	RELAYFORWARD message containing link-identifying data, the DHCP	RELAYFORWARD message containing link-identifying data, the DHCP
	server MUST use the contents of that option to identify the link to	server MUST use the contents of that option to identify the link to
	which the client is connected.	which the client is connected.

	Otherwise, if a Subnet Selection option was found in the client	Otherwise, if a Subnet Selection option was found in the client
	message, the DHCP server MUST use the contents of that option to	message, the DHCP server MUST use the contents of that option to
	identify the link to which the client is connected.	identify the link to which the client is connected.

	Otherwise, the DHCP server MUST use the contents of the 'aiaddr'	Otherwise, the DHCP server MUST use the contents of the 'aiaddr'
	field in the RELAYFORWARD encapsulation that was identified as being	field in the RELAYFORWARD encapsulation that was identified as being
	the innermost RELAYFORWARD containing link-identifying data.	the innermost RELAYFORWARD containing link-identifying data.


	5.1.3.2. Other link selection algorithms	5.1.5. Other link selection algorithms

	DHCP servers implementing this specification MAY implement link	DHCP servers implementing this specification MAY implement link
	selection algorithms other than the one described in the preceding	selection algorithms other than the one described in the preceding
	section. DHCP servers MUST NOT use any link selection algorithm	section. DHCP servers MUST NOT use any link selection algorithm
	other than the one described in the preceding section unless	other than the one described in the preceding section unless
	specially configured to do so.	specially configured to do so.

	5.2. Responding to RELAYFORWARD messages	5.2. Responding to RELAYFORWARD messages

	Once the DHCP server has processed the encapsulated message from the	Once the DHCP server has processed the encapsulated message from the
	DHCP client and constructed a response to the DHCP client, it	DHCP client and constructed a response to the DHCP client, it

	constructs a RELAYREPLY message and sends it toward the client.	constructs a RELAYREPLY message and sends it to the next hop on the
		way to the client.

	5.2.1. Constructing a RELAYREPLY encapsulation	5.2.1. Constructing a RELAYREPLY encapsulation

	The server MUST encapsulate any response to a client message	The server MUST encapsulate any response to a client message
	contained in one or more RELAYFORWARD encapsulations in a set of	contained in one or more RELAYFORWARD encapsulations in a set of
	corresponding RELAYREPLY encapsulations. Each RELAYREPLY is nested	corresponding RELAYREPLY encapsulations. Each RELAYREPLY is nested
	in the same way that the corresponding RELAYFORWARD was nested, so	in the same way that the corresponding RELAYFORWARD was nested, so
	that the innermost RELAYREPLY corresponds to the innermost	that the innermost RELAYREPLY corresponds to the innermost
	RELAYFORWARD, and the outermost RELAYREPLY corresponds to the	RELAYFORWARD, and the outermost RELAYREPLY corresponds to the
	outermost RELAYFORWARD.	outermost RELAYFORWARD.

	skipping to change at page 20, line 5	skipping to change at page 20, line 46

	5.2.2. Transmission of RELAYREPLY messages	5.2.2. Transmission of RELAYREPLY messages

	If the value of 'aiaddr' in the outermost RELAYFORWARD encapsulation	If the value of 'aiaddr' in the outermost RELAYFORWARD encapsulation
	to which the RELAYREPLY is a response is nonzero, the DHCP server	to which the RELAYREPLY is a response is nonzero, the DHCP server
	MUST transmit the RELAYREPLY to that IP address.	MUST transmit the RELAYREPLY to that IP address.

	Otherwise, if 'ciaddr' and 'yiaddr' are both zero, or the BROADCAST	Otherwise, if 'ciaddr' and 'yiaddr' are both zero, or the BROADCAST
	bit in the 'flags' field is set to 1, or the DHCP server	bit in the 'flags' field is set to 1, or the DHCP server
	implementation is not able to perform the ARP-cache preloading trick	implementation is not able to perform the ARP-cache preloading trick

	described in Bootstrap Protocol, Section 4 [RFC0951], the DHCP server	described in Bootstrap Protocol, Section 4 (Croft, B. and J.
	MUST broadcast the RELAYREPLY message to the 255.255.255.255	Gilmore, "Bootstrap Protocol," September 1985.) [RFC0951], the DHCP
		server MUST broadcast the RELAYREPLY message to the 255.255.255.255
	broadcast address.	broadcast address.

	Otherwise, the DHCP server MUST use the value of 'ciaddr', if	Otherwise, the DHCP server MUST use the value of 'ciaddr', if
	nonzero, or 'yiaddr', otherwise, as the destination address for the	nonzero, or 'yiaddr', otherwise, as the destination address for the
	message, and MUST preload its ARP cache (or otherwise arrange to	message, and MUST preload its ARP cache (or otherwise arrange to
	transmit the message without using ARP) to the layer two address	transmit the message without using ARP) to the layer two address
	provided by the client in 'htype' and 'chaddr' and 'hlen'.	provided by the client in 'htype' and 'chaddr' and 'hlen'.

	5.3. Responding to messages other than RELAYFORWARD	5.3. Responding to messages other than RELAYFORWARD

	When a DHCP server constructs a response to a DHCP client message	When a DHCP server constructs a response to a DHCP client message
	that did not arrive encapsulated in a RELAYFORWARD message, the DHCP	that did not arrive encapsulated in a RELAYFORWARD message, the DHCP
	server MUST NOT encapsulate the response in a RELAYREPLY message.	server MUST NOT encapsulate the response in a RELAYREPLY message.
	DHCP server implementors should be careful that their servers do not	DHCP server implementors should be careful that their servers do not

	respond to an incoming packet with RAIO from a non-conforming relay	respond to an incoming RAIO from a non-conforming relay agent with a
	agent with a RELAYREPLY message.	RELAYREPLY message.

	6. DHCP Client Behavior	6. DHCP Client Behavior

	A DHCP client that receives either a RELAYFORWARD message or a	A DHCP client that receives either a RELAYFORWARD message or a
	RELAYREPLY message MUST silently discard that message.	RELAYREPLY message MUST silently discard that message.


	7. Security Considerations	7. Layer 2 Relay Agent Information


	DHCP Relay Information Option [RFC3046] limits relay agent	In some network configurations, there is a need for Layer 2 devices
		to append the Relay Agent Information option as they are closer to
		the end hosts. These Layer 2 devices are typically operating only as
		bridges for the network and may not have an IPv4 address on the
		network in question. Lacking a valid IPv4 source address, they
		cannot relay packets directly to a DHCP server located on another
		network. 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 section provides information about where a Layer 2 Relay Agent
		fits in and how it is used. This section also looks at various
		network scenarios with Layer 2 Relay Agents and discusses various
		issues caused by the introduction of Layer 2 Relay Agents.

		7.1. Need of Layer 2 Relay Agent

		A Layer 2 device intercepts DHCP messages for the 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 position to
		provide a unique Relay Agent Information option to enforce
		policies in the DHCP server.

		2. In some network deployments, a Layer 2 device can append Relay
		Agent Information in DHCP messages so that it can use this
		information to forward the DHCP Replies to the specific port on
		which the request was received.

		3. 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 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
		up to date.

		4. In some network deployments like Fronthaul in mobile networks,
		the aggregation of Radio Unit devices (also known as Switched
		Fronthaul) hides the relationship between the Radio Unit
		themselves and the physical ports where they are connected (see
		Section 7.2.4). In order to properly setup the Switched
		Fronthaul network aggregation, the DHCP server must know the
		network topology. This is accomplished by implementing in each
		and all the Layer 2 switches a L2RA functionality.

		7.2. 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.

		7.2.1. DHCP server and client on same subnet

		In certain network configurations, a 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. The following
		points describe how this Layer 2 device handles various DHCP messages
		if it acts as a Layer 2 Relay Agent. Figure 4 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 4: DHCP server and client on same subnet

		7.2.1.1. Client-server interaction

		The following summary of protocol message exchanges between clients
		and DHCP servers describes how they are handled in a 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 the one on which it was
		received. The Relay Agent Information option could be created as
		suggested in [RFC3046]. The 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 the one
		on which the message was received.

		3. The DHCP server responds with a DHCPOFFER message after applying
		its local policies. It echoes back the Relay Agent Information
		option in the DHCPOFFER message. The DHCP server can either
		unicast the reply to the MAC address of End Host #1 or broadcast
		the reply. If the reply is broadcast, the Layer 2 Relay Agent
		intercepts this message and removes the Relay Agent Information
		option. It identifies the outgoing port using the Relay Agent
		Information option and forwards the message to the identified
		interface. A Layer 2 Relay Agent may be configured to intercept
		unicast DHCP messages. In such a case, the Layer 2 Relay Agent
		intercepts unicast DHCP messages and handles them similar to
		broadcast messages.

		4. The same DHCPOFFER message will be received by 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. 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/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
		messages, they append a Relay Agent Information option and
		forward the message towards the DHCP server. They also intercept
		the reply messages and remove the Relay Agent Information option
		before forwarding them.

		7.2.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. There is a case when the DHCP client receives a unicast reply
		message like DHCPACK with a Relay Agent Information option. This
		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.

		7.2.2. Multiple DHCP server and Client on same subnet

		In certain network scenarios, there could be multiple DHCP servers on
		the same subnet. Figure 5 shows a typical network setup.

		+--------+
		\| 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 5: Multiple DHCP server and client on same subnet

		7.2.2.1. Client-server interaction

		The message exchanges are the same as explained in Section 7.2.1.1
		However, due to the introduction of multiple DHCP servers the below
		additional message exchange may happen.

		1. When Host #1 sends DHCPDISCOVER, it will be received by both DHCP
		Servers connected to Layer 2 Relay Agent #1 and both servers will
		respond with a DHCPOFFER. So instead of one DHCPOFFER message,
		the Layer 2 Relay Agent would receive two messages. The
		processing of DHCP messages in the Layer 2 Relay Agents remains
		the same.

		7.2.2.2. Issues due to introduction of Layer 2 Relay Agent

		1. Layer 2 relay agents which maintain persistent state, such as
		updating filters or client registration, must be prepared to
		handle potentially conflicting responses from different DHCP
		Servers. Some Layer 2 relay agents may use "the most recent DHCP
		packet" to update this persistent state but this may not
		necessarily reflect the actual state of the client. The above is
		possible when two DHCP servers acknowledge the request of a DHCP
		client with the same address but different lease times. In this
		case, if the relay agent selects the server reply with the
		shorter lease time, it would expire its state possibly before the
		client even has a chance to renew it. Therefore, Layer 2 relay
		agents SHOULD select the longest lease time of two conflicting
		but similar replies, by discarding replies that shorten the lease
		time.

		2. Other issues are the same as described in section Section 7.2.1.2

		7.2.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 one subnet to a DHCP server on
		another subnet and vice versa. In typical deployments, the Access
		Concentrator acts as Layer 2 Relay Agent and the IP edge device (BRAS
		or IP Services Switch) acts as Layer 3 Relay Agent.

		+--------+
		\| 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 6: DHCP server on a different subnet with a Layer 3 Relay
		Agent

		7.2.3.1. Client-server interaction

		As far as DHCP message processing is concerned, the presence of Layer
		3 Relay Agents is transparent to Layer 2 Relay Agents. So all the
		messages are handled in the same way as defined in section
		Section 7.2.1.1 for the Layer 2 Relay Agent.

		The Layer 3 Relay Agents are configured to trust/untrust an entity
		based on specific criteria (For example : VLAN/interface on which the
		message was received). If the DHCP message coming from the client
		has a relay agent option present, the Layer 3 Relay Agent checks if
		it is coming in on a trusted interface. If it is coming from a
		trusted interface, it will set the 'giaddr' field to one of the local
		interface addresses and unicasts it to the configured server(s). If
		the message is coming from an untrusted interface, the Layer 3 Relay
		Agent discards the message.

		Typical message processing in this scenario is given below.

		1. When the client sends a DHCPDISCOVER message, the Layer 2 Relay
		Agent forwards it as described in section Section 7.2.1.1. The
		Layer 3 Relay Agent receives this message and finds that it
		contains a Relay Agent Information option. It verifies whether
		the message is from a trusted entity or not. If it is from a
		trusted entity, the Layer 2 Relay Agent populates the 'giaddr'
		field as it deems appropriate and relays the message to the DHCP
		server.

		2. The DHCP Server processes the message in the same way as
		described in section Section 7.2.1 and unicasts the DHCPOFFER to
		the Layer 3 Relay Agent on the address specified in the 'giaddr'
		field.

		3. The Layer 3 Relay Agent processes the DHCPOFFER and identifies
		the outgoing interface. It resets the 'giaddr' field and
		broadcasts the message on the identified outgoing interface.

		4. The client receives the DHCPOFFER and generates a DHCPREQUEST
		message. The Layer 2 Relay Agent processes it as described in
		section Section 7.2.1.1. The Layer 3 Relay Agent receives the
		DHCPREQUEST message and processes it similar to the DHCPDISCOVER
		message described in step #1.

		5. The DHCP Server processes the DHCPREQUEST and unicasts the DHCP
		ACK message to the layer 3 Relay Agent if the 'broadcast' flag is
		set, or directly to the client if the 'broadcast' flag is not
		set. If the Layer 3 Relay Agent receives this message, it
		processes it similar to the DHCPOFFER as described in step #3.

		6. In the case of unicast messages (For example: DHCPREQUEST in case
		of DHCPRENEW), a Layer 3 Relay Agent may or may not intercept the
		message. If it intercepts a unicast DHCP request message, it
		populates the 'giaddr' field and relays the message to the DHCP
		server. When the DHCP server sends a reply for this request
		message, it resets the 'giaddr' field, identifies the outgoing
		interface, and forwards the reply on the identified interface.

		7.2.3.2. Issues due to introduction of Layer 2 Relay Agent

		Though the processing of DHCP messages remains the same in Layer 2
		Relay Agents, 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 a Relay Agent Information option
		before forwarding the request message. 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' field is not populated.

		2. Existing Layer 3 Relay Agents populate the 'giaddr' field with
		the IP address of the interface on which the request was
		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. 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.

		7.2.4. DHCP server on another subnet with multiple Layer 3 Relay Agents

		In certain network scenarios, there could be more Layer 3 Relay
		Agents which relays the DHCP messages from one subnet to a DHCP
		server on another subnet and vice versa. In typical deployments, the
		Fronthaul Switch acts as Layer 2 Relay Agent and the Baseband Unit or
		a Router acts as Layer 3 Relay Agent.

		+--------+
		\| End \| +--------+ \| \|
		\| Host#1 +--------\| \| \| +-----------+ \|
		+--------+ \| Layer +-----\| \| \| \|
		\| 2 \| +--\| Layer 3 \|----\|
		+--------+ \| device \| \| \| Relay \| \|
		\| End +--------\| #1 \| \| \| Agent #1 \| \|
		\| Host#2 \| +--------+ \| +-----------+ \| +---------+
		+--------+ \| \| \| \|
		\| +--\| DHCP \|
		+--------+ \| \| \| Server \|
		\| End \| +--------+ \| \| \| #1 \|
		\| Host#3 +--------\| \| \| +-----------+ \| +---------+
		+--------+ \| Layer +-----\| \| \| \|
		\| 2 \| +--\| Layer 3 \|----\|
		+--------+ \| device \| \| \| Relay \| \|
		\| End +--------\| #2 + \| \| Agent #2 \| \|
		\| Host#n \| +--------+ \| +-----------+
		+--------+ \|

		Figure 7: DHCP server on a different subnet with more Layer 3
		Relay Agent

		7.2.4.1. Client-server interaction

		Same as described in Section 7.2.3.1

		7.2.4.2. Issues due to introduction of Layer 2 Relay Agent

		Same as described in Section 7.2.3.2

		In a scenario where multiple Layer 3 relay agents exist the DHCP
		Server must consider the possibility that mutple requests for the
		same End Host will arrive via different Layer 3 Agents and take a
		decision to which one is to be used. It is expected that the DHCP
		Server can cope with that situation.

		8. Conventions and Definitions

		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
		"OPTIONAL" in this document are to be interpreted as described in
		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
		capitals, as shown here.

		9. Security Considerations

		DHCP Relay Information Option (Patrick, M., "DHCP Relay Agent
		Information Option," January 2001.) [RFC3046] limits relay agent
	information to a single relay agent, and provides some minimal anti-	information to a single relay agent, and provides some minimal anti-
	spoofing. By supporting relay agent chaining, it is now possible for	spoofing. By supporting relay agent chaining, it is now possible for
	a relay agent downstream of the trusted portion of a provider network	a relay agent downstream of the trusted portion of a provider network
	to communicate relay agent information options to a DHCP server.	to communicate relay agent information options to a DHCP server.

	This specification defines a much more robust spoofing rejection	This specification defines a much more robust spoofing rejection
	mechanism, by allowing the administrator to configure the relay to	mechanism, by allowing the administrator to configure the relay to
	discard RELAYFORWARD messages originating from outside of the trusted	discard RELAYFORWARD messages originating from outside of the trusted
	portion of the network. Administrators of networks that rely on this	portion of the network. Administrators of networks that rely on this
	trusted/untrusted configuration are encouraged to configure edge	trusted/untrusted configuration are encouraged to configure edge
	relays to discard RELAYFORWARD messages.	relays to discard RELAYFORWARD messages.

	In networks where trusted relay agents may be separated from the DHCP	In networks where trusted relay agents may be separated from the DHCP
	server by transit networks that are not trusted, it is possible to	server by transit networks that are not trusted, it is possible to
	modify the message in transit. This possibility exists with normal	modify the message in transit. This possibility exists with normal
	DHCP relays as well. Administrators of such networks should consider	DHCP relays as well. Administrators of such networks should consider

	using relay agent authentication [RFC4030] to prevent modification of	using relay agent authentication (Stapp, M. and T. Lemon, "The
	relay agent communications in transit.	Authentication Suboption for the Dynamic Host Configuration Protocol
		(DHCP) Relay Agent Option," March 2005.) [RFC4030] to prevent
		modification of relay agent communications in transit.


	8. IANA Considerations	10. IANA Considerations

	We request that IANA assign one new suboption code from the registry	We request that IANA assign one new suboption code from the registry
	of DHCP Agent Sub-Option Codes maintained in	of DHCP Agent Sub-Option Codes maintained in
	http://www.iana.org/assignments/bootp-dhcp-parameters. This	http://www.iana.org/assignments/bootp-dhcp-parameters. This
	suboption code will be assigned to the Layer Two Address Suboption.	suboption code will be assigned to the Layer Two Address Suboption.


	9. References	11. References

	9.1. Normative References


	[I-D.ietf-dhc-relay-id-suboption]	11.1. Normative References
	Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption",
	draft-ietf-dhc-relay-id-suboption-07 (work in progress),
	July 2009.

	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,

	August 1980.	DOI 10.17487/RFC0768, August 1980,
		<https://www.rfc-editor.org/rfc/rfc768>.


	[RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951,	[RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
	September 1985.	DOI 10.17487/RFC0951, September 1985,
		<https://www.rfc-editor.org/rfc/rfc951>.

	[RFC1542] Wimer, W., "Clarifications and Extensions for the	[RFC1542] Wimer, W., "Clarifications and Extensions for the

	Bootstrap Protocol", RFC 1542, October 1993.	Bootstrap Protocol", RFC 1542, DOI 10.17487/RFC1542,
		October 1993, <https://www.rfc-editor.org/rfc/rfc1542>.

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

	Requirement Levels", BCP 14, RFC 2119, March 1997.	Requirement Levels", BCP 14, RFC 2119,
		DOI 10.17487/RFC2119, March 1997,
		<https://www.rfc-editor.org/rfc/rfc2119>.

	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",

	RFC 2131, March 1997.	RFC 2131, DOI 10.17487/RFC2131, March 1997,
		<https://www.rfc-editor.org/rfc/rfc2131>.

	[RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP",	[RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP",

	RFC 3011, November 2000.	RFC 3011, DOI 10.17487/RFC3011, November 2000,
		<https://www.rfc-editor.org/rfc/rfc3011>.

	[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",	[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",

	RFC 3046, January 2001.	RFC 3046, DOI 10.17487/RFC3046, January 2001,
		<https://www.rfc-editor.org/rfc/rfc3046>.


	[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP	[RFC3118] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for
	Messages", RFC 3118, June 2001.	DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001,
		<https://www.rfc-editor.org/rfc/rfc3118>.

	[RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,	[RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
	"Link Selection sub-option for the Relay Agent Information	"Link Selection sub-option for the Relay Agent Information

	Option for DHCPv4", RFC 3527, April 2003.	Option for DHCPv4", RFC 3527, DOI 10.17487/RFC3527, April
		2003, <https://www.rfc-editor.org/rfc/rfc3527>.

	[RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for	[RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for
	the Dynamic Host Configuration Protocol (DHCP) Relay Agent	the Dynamic Host Configuration Protocol (DHCP) Relay Agent

	Option", RFC 4030, March 2005.	Option", RFC 4030, DOI 10.17487/RFC4030, March 2005,
		<https://www.rfc-editor.org/rfc/rfc4030>.

	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,

	December 2005.	DOI 10.17487/RFC4302, December 2005,
		<https://www.rfc-editor.org/rfc/rfc4302>.


	9.2. Informative References	[RFC6925] Joshi, B., Desetti, R., and M. Stapp, "The DHCPv4 Relay
		Agent Identifier Sub-Option", RFC 6925,
		DOI 10.17487/RFC6925, April 2013,
		<https://www.rfc-editor.org/rfc/rfc6925>.

		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
		May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

		11.2. Informative References

		[I-D.ietf-dhc-dhcpv4-relay-encapsulation]
		Lemon, T., Deng, H., and L. Huang, "Relay Agent
		Encapsulation for DHCPv4", Work in Progress, Internet-
		Draft, draft-ietf-dhc-dhcpv4-relay-encapsulation-01, 11
		July 2011, <https://datatracker.ietf.org/doc/html/draft-
		ietf-dhc-dhcpv4-relay-encapsulation-01>.

	[I-D.ietf-dhc-l2ra]	[I-D.ietf-dhc-l2ra]
	Joshi, B. and P. Kurapati, "Layer 2 Relay Agent	Joshi, B. and P. Kurapati, "Layer 2 Relay Agent

	Information", draft-ietf-dhc-l2ra-04 (work in progress),	Information", Work in Progress, Internet-Draft, draft-
	April 2009.	ietf-dhc-l2ra-06, 25 January 2012,
		<https://datatracker.ietf.org/doc/html/draft-ietf-dhc-
		l2ra-06>.


	[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,	[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
	and M. Carney, "Dynamic Host Configuration Protocol for	C., and M. Carney, "Dynamic Host Configuration Protocol
	IPv6 (DHCPv6)", RFC 3315, July 2003.	for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
		2003, <https://www.rfc-editor.org/rfc/rfc3315>.


	Authors' Addresses	Acknowledgments


	Ted Lemon	The authors would like to acknowledge that much of the material in
	Nominum, Inc.	this document comes directly from
	2000 Seaport Blvd	[I-D.ietf-dhc-dhcpv4-relay-encapsulation] by Ted Lemon, Hui Deng, and
	Redwood City, CA 94063	Lu Huang, and [I-D.ietf-dhc-l2ra] by Bharat Joshi and Pavan Kurapati.
	USA	These documents were the original ideas, which the current authors
		have only adopted and fine-tuned.


	Phone: +1 650 381 6000	The authors would also like to acknowledge interesting discussions in
	Email: mellon@nominum.com	this problem space with Sarah Gannon, Ines Ramadza, Siddharth Sharma,
		and Bernie Volz.


	Hui Deng	Authors' Addresses
	China Mobile
	53A, Xibianmennei Ave.
	Beijing, Xuanwu District 100053
	China


	Email: denghui@chinamobile.com	Claudio Porfiri
		Ericsson
		Email: claudio.porfiri@ericsson.com


	Lu Huang	Jari Arkko
	China Mobile	Ericsson
	53A, Xibianmennei Ave.	Email: jari.arkko@ericsson.com
	Xunwu District, Beijing 100053
	China


	Email: huanglu@chinamobile.com	Mirja Kühlewind
		Ericsson
		Email: mirja.kuhlewind@ericsson.com

End of changes. 107 change blocks.
	280 lines changed or deleted	797 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/