draft-ietf-dhc-dhcpv6-ldra-03.txt		rfc6221.txt
	DHC Working Group D. Miles, Ed.		Internet Engineering Task Force (IETF) D. Miles, Ed.
	Internet-Draft S. Ooghe		Request for Comments: 6221 S. Ooghe
	Updates: 3315 (if approved) Alcatel-Lucent		Updates: 3315 Alcatel-Lucent
	Intended status: Standards Track W. Dec		Category: Standards Track W. Dec
	Expires: April 22, 2011 Cisco Systems		ISSN: 2070-1721 Cisco Systems
	S. Krishnan		S. Krishnan
	A. Kavanagh		A. Kavanagh
	Ericsson		Ericsson
	October 19, 2010		May 2011
	Lightweight DHCPv6 Relay Agent		Lightweight DHCPv6 Relay Agent
	draft-ietf-dhc-dhcpv6-ldra-03
	Abstract		Abstract
	This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that		This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that
	is used to insert relay agent options in DHCPv6 message exchanges		is used to insert relay agent options in DHCPv6 message exchanges
	identifying client-facing interfaces. The LDRA can be implemented in		identifying client-facing interfaces. The LDRA can be implemented in
	existing access nodes (such as DSLAMs and Ethernet switches) that do		existing access nodes (such as Digital Subscriber Link Access
	not support IPv6 control or routing functions.		Multiplexers (DSLAMs) and Ethernet switches) that do not support IPv6
			control or routing functions.
	Status of this Memo
	This Internet-Draft is submitted in full conformance with the		Status of This Memo
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This is an Internet Standards Track document.
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	This Internet-Draft will expire on April 22, 2011.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc6221.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction ....................................................3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language ......................................3
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Background ......................................................3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Terminology .....................................................3
	4. Server Considerations . . . . . . . . . . . . . . . . . . . . 4		4. Server Considerations ...........................................5
	5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5		5. Message Format ..................................................5
	5.1. Relay-Forward Message . . . . . . . . . . . . . . . . . . 5		5.1. Relay-Forward Message ......................................5
	5.2. Relay-Reply Message . . . . . . . . . . . . . . . . . . . 5		5.2. Relay-Reply Message ........................................6
	5.3. Mandatory DHCP Options . . . . . . . . . . . . . . . . . . 6		5.3. Mandatory DHCP Options .....................................6
	5.3.1. Relay-Message Option . . . . . . . . . . . . . . . . . 6		5.3.1. Relay-Message Option ................................6
	5.3.2. Interface-ID Option . . . . . . . . . . . . . . . . . 6		5.3.2. Interface-ID Option .................................6
	6. Agent Behaviour . . . . . . . . . . . . . . . . . . . . . . . 7		6. Agent Behaviour .................................................7
	6.1. Relaying a Client Message . . . . . . . . . . . . . . . . 7		6.1. Relaying a Client Message ..................................7
	6.1.1. Client Message Validation . . . . . . . . . . . . . . 7		6.1.1. Client Message Validation ...........................8
	6.1.2. Trusted and Untrusted Interfaces . . . . . . . . . . . 8		6.1.2. Trusted and Untrusted Interfaces ....................8
	6.2. Relaying a Relay-Reply message from the network . . . . . 8		6.2. Relaying a Relay-Reply Message from the Network ............8
	7. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 9		7. Network Topology ................................................9
	7.1. Client and Server on Same Link . . . . . . . . . . . . . . 9		7.1. Client and Server on Same Link .............................9
	7.2. Client and Server behind Relay Agent . . . . . . . . . . . 10		7.2. Client and Server behind Relay Agent ......................11
	7.3. Relay Agent in Front of LDRA . . . . . . . . . . . . . . . 11		7.3. Relay Agent in Front of LDRA ..............................12
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. Contributors ...................................................15
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		9. Security Considerations ........................................15
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 12		10. References ....................................................15
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13		10.1. Normative References .....................................15
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		10.2. Informative References ...................................16
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	12.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	DHCPv6 Relay-Agents [RFC3315] are deployed to forward DHCPv6 messages		DHCPv6 Relay Agents [RFC3315] are deployed to forward DHCPv6 messages
	between clients and servers when they are not on the same IPv6 link		between clients and servers when they are not on the same IPv6 link
	and are often implemented alongside a routing function in a common		and are often implemented alongside a routing function in a common
	node. A Lightweight DHCPv6 Relay Agent (LDRA) allows Relay Agent		node. A Lightweight DHCPv6 Relay Agent (LDRA) allows Relay Agent
	Information to be inserted by an access node that performs a link-		Information to be inserted by an access node that performs a link-
	layer bridging (i.e. non-routing) function. A LDRA resides on the		layer bridging (i.e., non-routing) function. An LDRA resides on the
	same IPv6 link as the client and a DHCPv6 Relay Agent or Server and		same IPv6 link as the client and a DHCPv6 Relay Agent or server, and
	is functionally the equivalent of the Layer 2 DHCP Relay draft[L2RA]		is functionally the equivalent of the Layer 2 Relay Agent proposed
	proposed for DHCPv4 operation.		for DHCPv4 operation in [L2RA].
	Unlike a DHCPv6 Relay-Agent specified in [RFC3315], a LDRA does not		Unlike a DHCPv6 Relay Agent specified in [RFC3315], an LDRA does not
	implement any IPv6 control functions (e.g. ICMPv6) or have any		implement any IPv6 control functions (e.g., ICMPv6) or have any
	routing capability in the node.		routing capability in the node.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Background		2. Background
	A variety of different link-layer network topologies exist for the		A variety of different link-layer network topologies exist for the
	aggregation of IPv6 nodes into one or more routers. In Layer 2		aggregation of IPv6 nodes into one or more routers. In Layer 2
	aggregation networks (IEEE 802.1D bridging or similar) that have many		aggregation networks (IEEE 802.1D bridging or similar) that have many
	nodes on a single link, a DHCPv6 server or DHCP relay agent would		nodes on a single link, a DHCPv6 server or DHCP Relay Agent would
	normally be unaware of how a DHCP client is attached to the network.		normally be unaware of how a DHCP client is attached to the network.
	The LDRA allows Relay Agent Information, including the Interface-ID		The LDRA allows Relay Agent Information, including the Interface-ID
	option [RFC3315], to be inserted by the access node so that it may be		option [RFC3315], to be inserted by the access node so that it may be
	used by the DHCPv6 server for client identification. A typical		used by the DHCPv6 server for client identification. A typical
	application in a broadband service provider may be as an equivalent		application in a broadband service provider could be equivalent to a
	to the Broadband Forum TR-101 Layer 2 DHCP Relay Agent [TR-101]		Layer 2 DHCP Relay Agent as described in the Broadband Forum TR-101
	described in [L2RA].		report [TR-101] and in [L2RA].
	3. Terminology		3. Terminology
	Access Node A device that combines many interfaces onto		Access Node A device that combines many interfaces onto
	one link. An access node is not IP-aware		one link. An access node is not IP-aware
	in the data path.		in the data path.
	Address An IP layer identifier for an interface or		Address An IP layer identifier for an interface or
	set of interfaces.		set of interfaces.
	skipping to change at page 4, line 24		skipping to change at page 4, line 21
	Lightweight Relay Agent A function on the access node that		Lightweight Relay Agent A function on the access node that
	intercepts DHCP messages between clients		intercepts DHCP messages between clients
	and servers. The function exists as a bump		and servers. The function exists as a bump
	in the wire on the IP link.		in the wire on the IP link.
	Link A communication facility or medium over		Link A communication facility or medium over
	which nodes can communicate at the link		which nodes can communicate at the link
	layer.		layer.
	Link-local address An IP address having only local-scope,		Link-local address An IP address having only local scope,
	indicated by having the address prefix		indicated by having the address prefix
	FE80::/10, that can be used to reach		fe80::/10, that can be used to reach
	neighbouring nodes attached to the same		neighbouring nodes attached to the same
	link. Every interface has a link-local		link. Every interface has a link-local
	address.		address.
	Network-facing An interface on the access node that		Network-facing An interface on the access node that
	carries traffic towards the DHCPv6		carries traffic towards the DHCPv6
	server(s).		server(s).
	Node A device that implements IPv6.		Node A device that implements IPv6.
	skipping to change at page 4, line 50		skipping to change at page 5, line 7
	Relay Agent A node that acts as an intermediary to		Relay Agent A node that acts as an intermediary to
	deliver DHCP messages between clients and		deliver DHCP messages between clients and
	servers and being on the same link as the		servers and being on the same link as the
	client.		client.
	Unspecified address An IPv6 address that is comprised entirely		Unspecified address An IPv6 address that is comprised entirely
	of zeros.		of zeros.
	4. Server Considerations		4. Server Considerations
	This document updates the behavior specified in section 11 of DHCP		This document updates the behaviour specified in Section 11 of DHCP
	for IPv6 [RFC3315]. RFC3315 states, in part:		for IPv6 [RFC3315]. RFC 3315 states, in part:
	o If the server receives the message from a forwarding relay agent,		If the server receives the message from a forwarding relay agent,
	then the client is on the same link as the one to which the		then the client is on the same link as the one to which the
	interface, identified by the link-address field in the message		interface, identified by the link-address field in the message
	from the relay agent, is attached.		from the relay agent, is attached.
	DHCP server implementations conforming to this specification must,		DHCP server implementations conforming to this specification MUST,
	for the purposes of address selection, ignore any link-address field		for the purposes of address selection, ignore any link-address field
	whose value is zero. In the text from RFC3315 above, "link-address"		whose value is zero. In the above text from RFC 3315, "link-address"
	refers both to the link-address field of the Relay-forward message,		refers to both the link-address field of the Relay-Forward message,
	and also the link-address fields in any Relay-forward messages that		and the link-address fields in any Relay-Forward messages that may be
	may be nested within the Relay-forward message.		nested within the Relay-Forward message.
	5. Message Format		5. Message Format
	The Lightweight DHCPv6 Relay Agent (LDRA) exchanges DHCP messages		The Lightweight DHCPv6 Relay Agent (LDRA) exchanges DHCP messages
	between clients and servers using the message formats established in		between clients and servers using the message formats established in
	[RFC3315].		[RFC3315].
	To maintain interoperability with existing DHCP relays and servers		To maintain interoperability with existing DHCP relays and servers,
	the message format is unchanged from [RFC3315]. The LDRA implements		the message format is unchanged from [RFC3315]. The LDRA implements
	the same message types as a normal DHCPv6 Relay Agent. They are:		the same message types as a normal DHCPv6 Relay Agent. They are:
	o Relay-Forward Messages		o Relay-Forward Messages
	o Relay-Reply Messages		o Relay-Reply Messages
	5.1. Relay-Forward Message		5.1. Relay-Forward Message
	The Relay-Forward message is created by any DHCPv6 Relay Agent,		The Relay-Forward message is created by any DHCPv6 Relay Agent,
	including an LDRA, to forward messages between clients and servers or		including an LDRA, to forward messages between clients and servers or
	other relay agents. These messages are built as specified in		other relay agents. These messages are built as specified in
	[RFC3315].		[RFC3315].
	The Relay-Forward message contains relay agent parameters that		The Relay-Forward message contains relay agent parameters that
	identify the client-facing interface on which any reply messages		identify the client-facing interface on which any reply messages
	should be forwarded. These parameters are link-address, peer-address		should be forwarded. These parameters are link-address, peer-
	and Interface-ID. The link-address parameter MUST be set to the		address, and Interface-ID. The link-address parameter MUST be set to
	unspecified address. The Interface-ID Relay Agent Option MUST be		the unspecified address. The peer-address parameter MUST be set as
	included in the Relay-Forward message. The LDRA MAY insert		specified in Section 6.1. The Interface-ID Relay Agent option MUST
			be included in the Relay-Forward message. The LDRA MAY insert
	additional relay agent options.		additional relay agent options.
	5.2. Relay-Reply Message		5.2. Relay-Reply Message
	The Relay-Reply message is constructed by a DHCPv6 server to send		The Relay-Reply message is constructed by a DHCPv6 server to send
	parameters to a DHCP client when a relay agent is present between the		parameters to a DHCP client when a relay agent is present between the
	server and the client. The Relay-Reply message may be sent after an		server and the client. The Relay-Reply message may be sent after an
	initial Relay-Forward message as the parameters link-address, peer-		initial Relay-Forward message as the parameters link-address, peer-
	address, Interface-ID and the relay agent's IP address are learnt		address, and Interface-ID, as well as the relay agent's IP address,
	from the Relay-Forward message.		are learnt from the Relay-Forward message.
	The server MUST include the Interface-ID option in the Relay-Reply		The server MUST include the Interface-ID option in the Relay-Reply
	Message to indicate to the LDRA the interface on which the de-		Message to indicate to the LDRA the interface on which the
	capsulated message should be forwarded.		decapsulated message should be forwarded.
	5.3. Mandatory DHCP Options		5.3. Mandatory DHCP Options
	Parameters are exchanged between DHCP client, relay-agent and server		Parameters are exchanged between the DHCP client, Relay Agent, and
	through the use of DHCP options. There is a set of mandatory DHCP		server through the use of DHCP options. There is a set of mandatory
	options that MUST be included by the LDRA in all Relay-Forward		DHCP options that MUST be included by the LDRA in all Relay-Forward
	messages. These are the:		messages. These are the:
	o Relay-Message Option		o Relay-Message Option
	o Interface-ID Option		o Interface-ID Option
	5.3.1. Relay-Message Option		5.3.1. Relay-Message Option
	A DHCPv6 Relay Agent relays messages between clients and servers or		A DHCPv6 Relay Agent relays messages between clients and servers or
	other relay agents through Relay-Forward and Relay-Reply message		other relay agents through Relay-Forward and Relay-Reply message
	types. The original client DHCP message (i.e. the packet payload,		types. The original client DHCP message (i.e., the packet payload,
	excluding UDP and IP headers) is encapsulated in a Relay Message		excluding UDP and IP headers) is encapsulated in a Relay Message
	option [RFC3315].		option [RFC3315].
	If a Relay-Message would exceed the MTU of the outgoing interface it		If a Relay-Message would exceed the MTU of the outgoing interface, it
	MUST be discarded and an error condition SHOULD be logged.		MUST be discarded, and an error condition SHOULD be logged.
	5.3.2. Interface-ID Option		5.3.2. Interface-ID Option
	The LDRA MUST include the Interface-ID option [RFC3315] in all Relay-		The LDRA MUST include the Interface-ID option [RFC3315] in all Relay-
	Forward messages. When a LDRA receives a Relay-reply message with an		Forward messages. When an LDRA receives a Relay-Reply message with
	Interface-ID option present and link-address unspecified, the LDRA		an Interface-ID option present and link-address unspecified, the LDRA
	MUST relay the decapsulated message to the client on the interface		MUST relay the decapsulated message to the client on the interface
	identified in the Interface-ID option.		identified in the Interface-ID option.
	Servers MAY use the Interface-ID for parameter assignment policies.		Servers MAY use the Interface-ID for parameter assignment policies.
	The format of the Interface-ID is outside the scope of this		The format of the Interface-ID is outside the scope of this
	contribution. The Interface-ID SHOULD be considered an opaque value,		contribution. The Interface-ID SHOULD be considered an opaque value;
	i.e. the server SHOULD NOT try to parse the contents of the		i.e., the server SHOULD NOT try to parse the contents of the
	Interface-ID option. The LDRA SHOULD use the same Interface-ID value		Interface-ID option. The LDRA SHOULD use the same Interface-ID value
	for a given interface, and this value SHOULD be retained across		for a given interface, and this value SHOULD be retained across
	restarts. This is because, if the Interface-ID changes, a server		restarts. This is because if the Interface-ID changes, a server will
	will not be able to use it reliably in parameter assignment policies.		not be able to use it reliably in parameter assignment policies.
	6. Agent Behaviour		6. Agent Behaviour
	The LDRA MUST have each of its interfaces configured as either		The LDRA MUST have each of its interfaces configured as either
	client-facing or network-facing. The LDRA uses the notion of client-		client-facing or network-facing. The LDRA uses the notion of client-
	facing and network-facing interfaces to process DHCPv6 messages.		facing and network-facing interfaces to process DHCPv6 messages.
	6.1. Relaying a Client Message		6.1. Relaying a Client Message
	When a DHCPv6 message (defined in [RFC3315]) is received on any		The LDRA MUST intercept and process all IP traffic received on any
	client-facing interface, the LDRA MUST intercept and process the		client-facing interface that has:
	message. The LDRA MUST also prevent the original message from being
	forwarded on the network facing interface.		o destination IP address set to All_DHCP_Relay_Agents_and_Servers
			(ff02::1:2);
			o protocol type UDP; and
			o destination port 547.
			The LDRA MUST also prevent the original message from being forwarded
			on the network-facing interface.
	The lightweight relay agent adds any other options it is configured		The lightweight relay agent adds any other options it is configured
	or required to include in the Relay-Forward message. The LDRA MUST		or required to include in the Relay-Forward message. The LDRA MUST
	set the link-address field of the Relay-forward message to the		set the link-address field of the Relay-Forward message to the
	Unspecified Address (::) and MUST include the Interface-ID option in		Unspecified Address (::) and MUST include the Interface-ID option in
	all DHCP Relay-Forward messages.		all DHCP Relay-Forward messages.
	If the message received on the client-facing interface is a Relay-		If the message received on the client-facing interface is a Relay-
	Forward message, the LDRA MUST set the Hop-Count field in the newly		Forward message, the LDRA MUST set the hop-count field in the newly
	created Relay-Forward message to the value of the hop-count field in		created Relay-Forward message to the value of the hop-count field in
	the received message incremented by 1 as specified in [RFC3315].		the received message, incremented by 1 as specified in [RFC3315].
	The LDRA MUST copy the IP destination and link-layer destination		The LDRA MUST copy the IP destination and link-layer destination
	addresses from the client-originated message into the IP destination		addresses from the client-originated message into the IP destination
	address and link-layer destination address of the Relay-forward		address and link-layer destination address of the Relay-Forward
	message.		message.
	The LDRA MUST copy the IP source address from the client-originated		The LDRA MUST copy the IP source address from the client-originated
	message into the peer-address field of the Relay-forward message.		message into the peer-address field of the Relay-Forward message.
	The LDRA MUST copy the link-layer source address from the client-		The LDRA MUST copy the link-layer source address from the client-
	originated message into the link-layer source address of the Relay-		originated message into the link-layer source address of the Relay-
	forward message.		Forward message.
	6.1.1. Client Message Validation		6.1.1. Client Message Validation
	On receipt of a DHCP message on a client-facing interface, the LDRA		On receipt of a DHCP message on a client-facing interface, the LDRA
	MUST discard a message if it is of one of following message types:		MUST discard a message if it is of one of the following message
			types:
	o ADVERTISE (2)		o ADVERTISE (2)
	o REPLY (7)		o REPLY (7)
	o RECONFIGURE (10)		o RECONFIGURE (10)
	o RELAY-REPLY (13)		o RELAY-REPL (13)
	Options contained in the DHCPv6 message MUST NOT be validated by the		Options contained in the DHCPv6 message MUST NOT be validated by the
	LDRA, making it the responsibility of the DHCP server to check		LDRA, making it the responsibility of the DHCP server to check
	message option validity and allow new options to be introduced		message option validity and allow new options to be introduced
	without changes on the LDRA.		without changes on the LDRA.
	6.1.2. Trusted and Untrusted Interfaces		6.1.2. Trusted and Untrusted Interfaces
	In [RFC3046] DHCPv4 relay-agents had their client-facing interfaces		In [RFC3046], DHCPv4 Relay Agents had their client-facing interfaces
	set to trusted and untrusted. An LDRA MUST implement a configuration		set to "trusted" and "untrusted". An LDRA MUST implement a
	setting for all client-facing interfaces, marking them either as		configuration setting for all client-facing interfaces, marking them
	trusted or as untrusted. This setting SHOULD be configurable per		either as trusted or as untrusted. This setting SHOULD be
	interface. When a client-facing interface is deemed untrusted the		configurable per interface. When a client-facing interface is deemed
	LDRA MUST discard any message received from the client-facing		untrusted, the LDRA MUST discard any message of type RELAY-FORW (12)
	interface of type RELAY-FORWARD (12).		received from the client-facing interface.
	6.2. Relaying a Relay-Reply message from the network		6.2. Relaying a Relay-Reply Message from the Network
	The LDRA MUST intercept and process all IP traffic received on the		The LDRA MUST intercept and process all IP traffic received on the
	network-facing interface that has:		network-facing interface that has:
	o a link-local scoped source address;		o a link-local scoped source address;
	o a link-local scoped destination address;		o a link-local scoped destination address;
	o protocol type UDP; and		o protocol type UDP; and
	o destination port 547		o destination port 547
	An LDRA MUST inspect the DHCP message type and only forward Relay-		An LDRA MUST inspect the DHCP message type and only forward Relay-
	Reply messages. Other DHCP message types MUST be silently discarded.		Reply messages. Other DHCP message types MUST be silently discarded.
	The Relay-Reply message is considered valid by the LDRA if it passes		The Relay-Reply message is considered valid by the LDRA if it passes
	the validity checks to be performed by a relay agent per [RFC3315]		the validity checks to be performed by a relay agent per [RFC3315]
	and:		and
	- The Interface-ID Option is present and the value corresponds to a		- the Interface-ID option is present, and the value corresponds to a
	valid interface in the access node,		valid interface in the access node;
	- the Relay-Reply peer-address and the destination IP address is		- the Relay-Reply peer-address and the destination IP address are
	identical and it is a link-local scoped address when no IP address is		identical, and it is a link-local scoped address when no IP
	configured on the LDRA, and		address is configured on the LDRA; and
	- the link-address is the Unspecified Address when no IP address is		- the link-address is the Unspecified Address when no IP address is
	configured on the LDRA		configured on the LDRA.
	If the Relay-Reply message is valid, the LDRA copies the peer-address		If the Relay-Reply message is valid, the LDRA copies the peer-address
	into to the destination IP address field. The LDRA SHOULD forward		into the destination IP address field. The LDRA SHOULD forward the
	the packet to the correct client- facing interface using the		packet to the correct client-facing interface using the destination
	destination link-layer (MAC) address or the Interface-Id in the		link-layer (Media Access Control (MAC)) address or the Interface-ID
	Relay-Reply. The LDRA SHOULD NOT retransmit the packet on any other		in the Relay-Reply. The LDRA SHOULD NOT retransmit the packet on any
	interface. The contents of the Relay Message Option is put into an		other interface. The contents of the Relay Message option are put
	IP/UDP packet and then forwarded to the client.		into an IP/UDP packet and then forwarded to the client.
	The LDRA MUST copy the link-layer and IP source address from the		The LDRA MUST copy the link-layer and IP source address from the
	Relay-Reply message into the IP/UDP packet that is forwarded to the		Relay-Reply message into the IP/UDP packet that is forwarded to the
	client.		client.
	7. Network Topology		7. Network Topology
	The LDRA intercepts any DHCPv6 message received on client-facing		The LDRA intercepts any DHCPv6 message received on client-facing
	interfaces with a destination IP address of		interfaces with the traffic pattern specified in Section 6.1. The
	All_DHCP_Relay_Agents_and_Servers (FF02::1:2). The LDRA MUST NOT		LDRA MUST NOT forward the original client message to a network-facing
	forward the original client message to a network-facing interface, it		interface; it MUST process the message and add the appropriate Relay-
	MUST process the message and add the appropriate Relay-Forward		Forward options as described in previous sections.
	options as described in previous sections.
	7.1. Client and Server on Same Link		7.1. Client and Server on Same Link
	The access node acts as a bridge; it has no information about any IP		The access node acts as a bridge; it has no information about any IP
	prefixes that are valid on the link, thus a server should consider		prefixes that are valid on the link. Thus, a server should consider
	address and parameter assignment as if the client DHCP message was		address and parameter assignment as if the client DHCP message were
	not relayed.		not relayed.
	+--------+		+--------+
	Client -------| |		Client -------| |
	| Access |		| Access |
	Client -------| Node |-----+		Client -------| Node |-----+
	| (LDRA) | |		| (LDRA) | |
	Client -------| | |		Client -------| | |
	+--------+ |		+--------+ |
	| +--------+		| +--------+
	|------| Server |		|------| Server |
	| +--------+		| +--------+
	skipping to change at page 9, line 48		skipping to change at page 10, line 25
	+--------+ |		+--------+ |
	Client -------| | |		Client -------| | |
	| Access | |		| Access | |
	Client -------| Node |-----+		Client -------| Node |-----+
	| (LDRA) |		| (LDRA) |
	Client -------| |		Client -------| |
	+--------+		+--------+
	<--------- IPv6 Link -------->		<--------- IPv6 Link -------->
	For example, if a client sent a DHCP solicit message that was relayed		For example, if a client sent a DHCP Solicit message that was relayed
	by the LDRA to the server, the server would receive the following		by the LDRA to the server, the server would receive the following
	Relay-Forward message from the LDRA:		Relay-Forward message from the LDRA:
	src-ip: client link-local address		src-ip: client link-local address
	dst-ip: All_DHCP_Relay_Agents_and_Servers		dst-ip: All_DHCP_Relay_Agents_and_Servers
	msg-type: RELAY-FORWARD
			msg-type: RELAY-FORW
	hop-count: 0		hop-count: 0
	link-address: Unspecified_Address		link-address: Unspecified_Address
	peer-address: client link-local address		peer-address: client link-local address
	Interface-ID Option:		Interface-ID Option:
	interface-id: LDRA-inserted interface-id		interface-id: LDRA-inserted interface-id
	Relay-Message Option, which contains:		Relay-Message Option, which contains:
	msg-type: SOLICIT		msg-type: SOLICIT
	Solicit Message Options: <from client>		Solicit Message Options: <from client>
	7.2. Client and Server behind Relay Agent		7.2. Client and Server behind Relay Agent
	The client and server are on different IPv6 links, separated by one		The client and server are on different IPv6 links, separated by one
	or more relay agents that will typically act as a router. The LDRA		or more relay agents that will typically act as a router. The LDRA
	will send Relay-Forward messages upstream towards the second relay		will send Relay-Forward messages upstream towards the second relay
	agent which in turn will process the messages.		agent, which in turn will process the messages.
	+--------+		+--------+
	Client -------| |		Client -------| |
	| Access |		| Access |
	Client -------| Node |-----+		Client -------| Node |-----+
	| (LDRA) | |		| (LDRA) | |
	Client -------| | |		Client -------| | |
	+--------+ |		+--------+ |
	| +--------+ +--------+		| +--------+ +--------+
	|------| RelayB |-------| Server |		|------| RelayB |-------| Server |
	| +--------+ +--------+		| +--------+ +--------+
	+--------+ |		+--------+ |
	Client -------| | |		Client -------| | |
	| Access | |		| Access | |
	Client -------| Node |-----+		Client -------| Node |-----+
	| (LDRA) |		| (LDRA) |
	Client -------| |		Client -------| |
	+--------+		+--------+
	<------- IPv6 Link A -------> <--IPv6 Link B-->		<------- IPv6 Link A -------> <--IPv6 Link B-->
	For example, if a client sent a DHCP solicit message that was relayed		For example, if a client sent a DHCP Solicit message that was relayed
	by the LDRA to another relay agent and then to the server, the server		by the LDRA to another relay agent and then to the server, the server
	would receive the following Relay-Forward message from the LDRA:		would receive the following Relay-Forward message from the LDRA:
	src-ip: relayB		src-ip: relayB
	dst-ip: server		dst-ip: server
	msg-type: RELAY-FORWARD
			msg-type: RELAY-FORW
	hop-count: 1		hop-count: 1
	link-address: relayB address from link A		link-address: relayB address from link A
	peer-address: client link-local address		peer-address: client link-local address
	Relay-Message Option, which contains:		Relay-Message Option, which contains:
	msg-type: RELAY-FORWARD
			msg-type: RELAY-FORW
	hop-count: 0		hop-count: 0
	link-address: Unspecified_Address		link-address: Unspecified_Address
	peer-address: client link-local address		peer-address: client link-local address
	Interface-ID Option:		Interface-ID Option:
	interface-id: LDRA-inserted interface-id		interface-id: LDRA-inserted interface-id
	Relay-Message Option, which contains:		Relay-Message Option, which contains:
	msg-type: SOLICIT		msg-type: SOLICIT
	Solicit Message Options: <from client>		Solicit Message Options: <from client>
	7.3. Relay Agent in Front of LDRA		7.3. Relay Agent in Front of LDRA
	The client and server are on different IPv6 links, separated by one		The client and server are on different IPv6 links, separated by one
	or more relay agents that will typically act as a router and there is		or more relay agents that will typically act as a router, and there
	an [RFC3315] Relay Agent on the client-facing Interface of the LDRA.		is an [RFC3315] Relay Agent on the client-facing interface of the
	The LDRA will send Relay-Forward messages upstream towards the second		LDRA. The LDRA will send Relay-Forward messages upstream towards the
	relay agent which in turn will process the messages.		second relay agent, which in turn will process the messages.
	+--------+		+--------+
	RelayC -------| |		RelayC -------| |
	| Access |		| Access |
	RelayC -------| Node |-----+		RelayC -------| Node |-----+
	| (LDRA) | |		| (LDRA) | |
	RelayC -------| | |		RelayC -------| | |
	+--------+ |		+--------+ |
	| +--------+ +--------+		| +--------+ +--------+
	|------| RelayB |-------| Server |		|------| RelayB |-------| Server |
	| +--------+ +--------+		| +--------+ +--------+
	+--------+ |		+--------+ |
	RelayC -------| | |		RelayC -------| | |
	| Access | |		| Access | |
	RelayC -------| Node |-----+		RelayC -------| Node |-----+
	| (LDRA) |		| (LDRA) |
	RelayC -------| |		RelayC -------| |
	+--------+		+--------+
	<------- IPv6 Link A -------> <--IPv6 Link B-->		<------- IPv6 Link A -------> <--IPv6 Link B-->
	For example, if a client sent a DHCP solicit message that was relayed		For example, if a client sent a DHCP Solicit message that was relayed
	by RelayC and the LDRA to another relay agent, RelayB, and then to		by RelayC and the LDRA to another relay agent, RelayB, and then to
	the server, the server would receive the following Relay-Forward		the server, the server would receive the following Relay-Forward
	message:		message:
	src-ip: relayB		src-ip: relayB
	dst-ip: server		dst-ip: server
	msg-type: RELAY-FORWARD
			msg-type: RELAY-FORW
	hop-count: 2		hop-count: 2
	link-address: relayB address from link A		link-address: relayB address from link A
	peer-address: relayC		peer-address: relayC
	Relay-Message Option, which contains:		Relay-Message Option, which contains:
	msg-type: RELAY-FORWARD
			msg-type: RELAY-FORW
	hop-count: 1		hop-count: 1
	link-address: Unspecified_Address		link-address: Unspecified_Address
	peer-address: relayC		peer-address: relayC
	Interface-ID Option:		Interface-ID Option:
	interface-id: LDRA-inserted interface-id		interface-id: LDRA-inserted interface-id
	Relay-Message Option, which contains:		Relay-Message Option, which contains:
	msg-type: RELAY-FORWARD
			msg-type: RELAY-FORW
	hop-count: 0		hop-count: 0
	link-address: global or unspecified address
			link-address: global or Unspecified_Address
	peer-address: end client address		peer-address: end client address
	Interface-ID Option: (if required)		Interface-ID Option: (if required)
	interface-id: relayC inserted Interface-ID
			interface-id: relayC-inserted Interface-ID
	Relay-Message Option, which contains:		Relay-Message Option, which contains:
	msg-type: SOLICIT		msg-type: SOLICIT
	Solicit Message Options: <from end client>		Solicit Message Options: <from end client>
	8. Contributors		8. Contributors
	The authors would like to thank the following for their support,		The authors would like to thank the following for their support:
	Lieven Levrau, Alastair Johnson, Robert Haylock, Mickey Vucic, Ludwig		Lieven Levrau, Alastair Johnson, Robert Haylock, Mickey Vucic, Ludwig
	Pauwels, Fernando Cuervo, John Kaippallimalil, Fredrik Garneij,		Pauwels, Fernando Cuervo, John Kaippallimalil, Fredrik Garneij,
	Alfred Hoenes and Ted Lemon.		Alfred Hoenes, Ted Lemon, Tatuya Jinmei, David Hankins, and Ralph
			Droms.
	Comments are solicited and should be addressed to the DHC WG mailing		Comments are solicited and should be addressed to the DHC WG mailing
	list (dhcwg@ietf.org) and/or the author.		list (dhcwg@ietf.org) and/or the authors.
	9. IANA Considerations
	This document does not introduce any new namespaces for the IANA to
	manage.
	10. Security Considerations		9. Security Considerations
	Although the LDRA only listens to client-originated IPv6 traffic sent		The security issues pertaining to DHCPv6 Relay Agents as specified in
	to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547,		Section 23 of [RFC3315] are also applicable to LDRAs. The LDRA
	the LDRA SHOULD implement some form of rate-limiting on received		SHOULD implement some form of rate-limiting on client-originated
	messages to prevent excessive process utilisation. As DHCP is		traffic in order to prevent excessive process utilisation. The
	session-oriented, messages in excess of the rate-limit may be		traffic to be rate-limited can be easily identified since the LDRA
	silently discarded.		listens only to client-originated IPv6 traffic sent to the
			All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547 and does
			not process any other client-originated traffic. As DHCP is session-
			oriented, messages in excess of the rate-limit may be silently
			discarded.
	The hop count based determination of the trustworthiness of the LDRA		The hop-count-based determination of the trustworthiness of the LDRA
	can be easily defeated by a rogue relay agent on the network-facing		can be easily defeated by a rogue relay agent on the network-facing
	interface of the LDRA.		interface of the LDRA.
	11. Acknowledgements		10. References
	The authors would like to thank Tatuya Jinmei, David Hankins, Ted
	Lemon and Ralph Droms for reviewing this document and suggesting
	changes.
	12. References
	12.1. Normative References		10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3315] Droms, R., "Dynamic Host Configuration Protocol for IPv6		[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
	(DHCPv6)", RFC 3315, July 2003.		C., and M. Carney, "Dynamic Host Configuration Protocol
			for IPv6 (DHCPv6)", RFC 3315, July 2003.
	12.2. Informative References		10.2. Informative References
	[L2RA] Joshi, B., "Layer 2 Relay Agent Information", IETF		[L2RA] Joshi, B. and P. Kurapati, "Layer 2 Relay Agent
	Draft draft-ietf-dhc-l2ra-04, April 2009.		Information", Work in Progress, April 2011.
	[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",		[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
	RFC 3046, January 2001.		RFC 3046, January 2001.
	[TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL		[TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL
	Aggregation", Technical Report TR-101, April 2006.		Aggregation", Technical Report TR-101, April 2006.
	Authors' Addresses		Authors' Addresses
	David Miles (editor)		David Miles (editor)
	Alcatel-Lucent		Alcatel-Lucent
	L3 / 215 Spring St		L3 / 215 Spring St.
	Melbourne, Victoria 3000		Melbourne, Victoria 3000
	Australia		Australia
	Phone: +61 3 9664 3308		Phone: +61 3 9664 3308
	Email: david.miles@alcatel-lucent.com		EMail: david.miles@alcatel-lucent.com
	Sven Ooghe		Sven Ooghe
	Alcatel-Lucent		Alcatel-Lucent
	Copernicuslaan 50		Copernicuslaan 50
	2018 Antwerp,		2018 Antwerp,
	Belgium		Belgium
	Phone:		EMail: sven.ooghe@alcatel-lucent.com
	Email: sven.ooghe@alcatel-lucent.com
	Wojciech Dec		Wojciech Dec
	Cisco Systems		Cisco Systems
	Haarlerberdweg 13-19		Haarlerberdweg 13-19
	1101 CH Amsterdam,		1101 CH Amsterdam,
	The Netherlands		The Netherlands
	Phone:		EMail: wdec@cisco.com
	Email: wdec@cisco.com
	Suresh Krishnan		Suresh Krishnan
	Ericsson		Ericsson
	8400 Blvd Decarie		8400 Blvd. Decarie
	Town of Mount Royal, Quebec		Town of Mount Royal, Quebec
	Canada		Canada
	Email: suresh.krishnan@ericsson.com		EMail: suresh.krishnan@ericsson.com
	Alan Kavanagh		Alan Kavanagh
	Ericsson		Ericsson
	8400 Blvd Decarie		8400 Blvd. Decarie
	Town of Mount Royal, Quebec		Town of Mount Royal, Quebec
	Canada		Canada
	Email: alan.kavanagh@ericsson.com		EMail: alan.kavanagh@ericsson.com
End of changes. 115 change blocks.
	190 lines changed or deleted		238 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/