draft-ietf-dhc-dhcpv6-ldra-01.txt		draft-ietf-dhc-dhcpv6-ldra-02.txt
	DHC Working Group D. Miles, Ed.		DHC Working Group D. Miles, Ed.
	Internet-Draft S. Ooghe		Internet-Draft S. Ooghe
	Intended status: Standards Track Alcatel-Lucent		Intended status: Standards Track Alcatel-Lucent
	Expires: April 16, 2010 W. Dec		Expires: December 10, 2010 W. Dec
	Cisco Systems		Cisco Systems
	S. Krishnan		S. Krishnan
	A. Kavanagh		A. Kavanagh
	Ericsson		Ericsson
	October 13, 2009		June 8, 2010
	Lightweight DHCPv6 Relay Agent		Lightweight DHCPv6 Relay Agent
	draft-ietf-dhc-dhcpv6-ldra-01		draft-ietf-dhc-dhcpv6-ldra-02
			Abstract
			This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that
			is used to insert relay agent options in DHCPv6 message exchanges
			identifying client-facing interfaces. The LDRA can be implemented in
			existing access nodes (such as DSLAMs and Ethernet switches) that do
			not support IPv6 control or routing functions.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		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), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		Drafts is at http://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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on December 10, 2010.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 16, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that		described in the Simplified BSD License.
	is used to insert relay agent options in DHCPv6 message exchanges
	identifying client-facing interfaces. The LDRA can be implemented in
	existing access nodes (such as DSLAMs and Ethernet switches) that do
	not support IPv6 control or routing functions.
	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 . . . . . . . . . . . . . . . . . . . . 4
	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 . . . . . . . . . . . . . . . . . . . 5
	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 . . . . . . . . . . . . . . 7
	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 . . . . . . . . . . . . . . 10		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 . . . . . . . . . . . 10
	7.3. Relay Agent in Front of LDRA . . . . . . . . . . . . . . . 11		7.3. Relay Agent in Front of LDRA . . . . . . . . . . . . . . . 11
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 13		10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 13		11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	11.2. Informative References . . . . . . . . . . . . . . . . . . 13		11.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	skipping to change at page 3, line 38		skipping to change at page 3, line 38
	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 may be as an equivalent
	to the Broadband Forum TR-101 Layer 2 DHCP Relay Agent[TR-101]		to the Broadband Forum TR-101 Layer 2 DHCP Relay Agent [TR-101]
	described in [L2RA]		described 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.
	Client-facing An interface on the access node that		Client-facing An interface on the access node that
	carries traffic towards the DHCPv6 client		carries traffic towards the DHCPv6 client.
	Host A non-routing IPv6 node that is		Host A non-routing IPv6 node that is
	participating in DHCPv6 message exchange		participating in a DHCPv6 message exchange.
	IP Internet Protocol Version 6 (IPv6)		IP Internet Protocol Version 6 (IPv6).
	LDRA Lightweight DHCPv6 Relay Agent		LDRA Lightweight DHCPv6 Relay Agent.
	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.
	Router A node that forwards packets not directly		Router A node that forwards packets not directly
	addressed to itself		addressed to itself.
	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 IP address that is comprised entirely of		Unspecified address An IPv6 address that is comprised entirely
	zeros		of zeros.
	4. Server Considerations		4. Server Considerations
	This document updates the behavior specified in section 11 of DHCP		This document updates the behavior specified in section 11 of DHCP
	for IPv6 [RFC3315]. RFC3315 states, in part:		for IPv6 [RFC3315]. RFC3315 states, in part:
	o If the server receives the message from a forwarding relay agent,		o 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.
	skipping to change at page 5, line 35		skipping to change at page 5, line 35
	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-address
	and Interface-ID. The link-address parameter MUST be set to the		and Interface-ID. The link-address parameter MUST be set to the
	unspecified address. The Interface-ID Relay Agent Option MUST be		unspecified address. The Interface-ID Relay Agent Option MUST be
	included in the Relay-Forward message. The LDRA MAY insert		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
	skipping to change at page 6, line 14		skipping to change at page 6, line 14
	address, Interface-ID and the relay agent's IP address are learnt		address, Interface-ID and the relay agent's IP address are learnt
	from the Relay-Forward message.		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 de-
	capsulated message should be forwarded.		capsulated 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 DHCP client, relay-agent and server
	through the use of DHCP options. There are a set of mandatory DHCP		through the use of DHCP options. There is a set of mandatory DHCP
	options that MUST be included by the LDRA in all Relay-Forward and		options that MUST be included by the LDRA in all Relay-Forward
	Relay-Reply 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,
	skipping to change at page 7, line 8		skipping to change at page 7, line 8
	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 not be able to use it reliably in parameter assignment policies.		will 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 (DHCPv6 server) facing. The LDRA uses the		client-facing or network-facing. The LDRA uses the notion of client-
	notion of client-facing and network-facing interfaces to process the		facing and network-facing interfaces to process DHCPv6 messages.
	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		When a DHCPv6 message (defined in [RFC3315]) is received on any
	client-facing interface, the LDRA MUST intercept and process the		client-facing interface, the LDRA MUST intercept and process the
	message. The LDRA MUST also prevent the original message from being		message. The LDRA MUST also prevent the original message from being
	forwarded on the network facing interface.		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
	skipping to change at page 7, line 43		skipping to change at page 7, line 42
	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 the 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 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-REPLY (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 configuration
	setting for all client-facing interfaces, marking them either as		setting for all client-facing interfaces, marking them either as
	skipping to change at page 8, line 35		skipping to change at page 8, line 33
	untrusted interfaces (relay-agent interfaces that would ensure there		untrusted interfaces (relay-agent interfaces that would ensure there
	are no relay-agent options on incoming messages) were defined. In		are no relay-agent options on incoming messages) were defined. In
	DHCPv6, relay agents encapsulate the received message into the Relay-		DHCPv6, relay agents encapsulate the received message into the Relay-
	Message Option in addition to adding any relay-agent options. This		Message Option in addition to adding any relay-agent options. This
	nested message behaviour allows a server to identify the options each		nested message behaviour allows a server to identify the options each
	relay-agent has inserted along the path, whenever the data path		relay-agent has inserted along the path, whenever the data path
	between LDRA and server falls within a protected or operator		between LDRA and server falls within a protected or operator
	controlled environment.		controlled environment.
	When an LDRA is deployed, DHCPv6 servers MAY be configured with the		When an LDRA is deployed, DHCPv6 servers MAY be configured with the
	Relay-Forward hop-count of the LDRA to instruct at which level of		Relay-Forward hop-count of the LDRA to instruct them at which level
	nesting the relay-agent options should be parsed. This removes the		of nesting the relay-agent options should be parsed. This removes
	need for an interface to be configured as trusted or untrusted by		the need for an interface to be configured as trusted or untrusted by
	providing the DHCPv6 server with an awareness of the LDRA logical		providing the DHCPv6 server with an awareness of the LDRA logical
	location in the DHCP relay path. This behaviour is dependent on the		location in the DHCP relay path. This behaviour is dependent on the
	interception of all DHCP messages by the LDRA and the incrementing of		interception of all DHCP messages by the LDRA and the incrementing of
	the Relay-Forward hop-count if a Relay-Forward message is received		the Relay-Forward hop-count if a Relay-Forward message is received
	from the client-facing LDRA interface.		from the client-facing LDRA 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 MUST silently discard		An LDRA MUST inspect the DHCP message type and MUST silently discard
	any DHCP message that is not type Relay-Reply or is otherwise an		any DHCP message that is not type Relay-Reply or is otherwise an
	invalid DHCPv6 packet. The LDRA SHOULD ignore any message that does		invalid DHCPv6 packet. The LDRA SHOULD ignore any message that does
	not meet this criteria and subject it to normal packet forwarding.		not meet this criteria and subject it to normal packet forwarding.
	In addition to the validity checks performed by a relay agent in		The Relay-Reply message is considered valid by the LDRA if it passes
	[RFC3315] , the Relay-Reply message is considered valid by the LDRA		the validity checks to be performed by a relay agent per [RFC3315]
	if:		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 MUST be		- the Relay-Reply peer-address and the destination IP address is
	identical and MUST be a link-local scoped address when no IP address		identical and it is a link-local scoped address when no IP address is
	is configured on the LDRA, and		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
	The LDRA copies the peer-address into to the destination IP address		The LDRA copies the peer-address into to the destination IP address
	field. The LDRA SHOULD forward the packet to the correct client-		field. The LDRA SHOULD forward the packet to the correct client-
	facing interface using the destination link-layer (MAC) address or		facing interface using the destination link-layer (MAC) address or
	the Interface-Id in the Relay-Reply. The LDRA SHOULD NOT retransmit		the Interface-Id in the Relay-Reply. The LDRA SHOULD NOT retransmit
	the packet on any other interface. The contents of the Relay Message		the packet on any other interface. The contents of the Relay Message
	Option is put into an IP/UDP packet and then forwarded to the client.		Option is put into an IP/UDP packet and then forwarded to the client.
	skipping to change at page 10, line 29		skipping to change at page 10, line 24
	|------| Server |		|------| Server |
	| +--------+		| +--------+
	+--------+ |		+--------+ |
	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 and then to the server, the server would receive the		by the LDRA to the server, the server would receive the following
	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-FORWARD
	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:
	skipping to change at page 11, line 12		skipping to change at page 11, line 12
	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-FORWARD
	hop-count: 1		hop-count: 1
	link-address: relayB address from link A		link-address: relayB address from link A
	skipping to change at page 12, line 12		skipping to change at page 12, line 12
	The LDRA will send Relay-Forward messages upstream towards the second		The LDRA will send Relay-Forward messages upstream towards the second
	relay agent which in turn will process the messages.		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 the LDRA to another relay agent and then to the server, the server		by RelayC and the LDRA to another relay agent, RelayB, and then to
	would receive the following Relay-Forward message from the LDRA:		the server, the server would receive the following Relay-Forward
			message:
	src-ip: relayB		src-ip: relayB
	dst-ip: server		dst-ip: server
	msg-type: RELAY-FORWARD		msg-type: RELAY-FORWARD
	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-FORWARD
	hop-count: 1		hop-count: 1
	skipping to change at page 13, line 46		skipping to change at page 13, line 46
	[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", RFC 2119, March 1997.
	[RFC3315] Droms, R., "Dynamic Host Configuration Protocol for IPv6		[RFC3315] Droms, R., "Dynamic Host Configuration Protocol for IPv6
	(DHCPv6)", RFC 3315, July 2003.		(DHCPv6)", RFC 3315, July 2003.
	11.2. Informative References		11.2. Informative References
	[L2RA] Joshi, B., "Layer 2 Relay Agent Information", IETF		[L2RA] Joshi, B., "Layer 2 Relay Agent Information", IETF
	Draft draft-ietf-dhc-l2ra-02, May 2008.		Draft draft-ietf-dhc-l2ra-04, April 2009.
	[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)
End of changes. 41 change blocks.
	77 lines changed or deleted		75 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/