draft-ietf-6man-dad-proxy-07.txt		rfc6957.txt
	6man Working Group F. Costa		Internet Engineering Task Force (IETF) F. Costa
	Internet-Draft J-M. Combes, Ed.		Request for Comments: 6957 J-M. Combes, Ed.
	Intended status: Standards Track X. Pougnard		Category: Standards Track X. Pougnard
	Expires: October 11, 2013 France Telecom Orange		ISSN: 2070-1721 France Telecom Orange
	H. Li		H. Li
	Huawei Technologies		Huawei Technologies
	April 9, 2013		June 2013
	Duplicate Address Detection Proxy		Duplicate Address Detection Proxy
	draft-ietf-6man-dad-proxy-07
	Abstract		Abstract
	The document describes a proxy based mechanism allowing the use of		The document describes a proxy-based mechanism allowing the use of
	Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-		Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-
	multipoint architecture with "split-horizon" forwarding scheme,		multipoint architecture with a "split-horizon" forwarding scheme,
	primarily deployed for Digital Subscriber Line (DSL) and Fiber access		primarily deployed for Digital Subscriber Line (DSL) and Fiber access
	architectures. Based on the DAD signalling, the first hop router		architectures. Based on the DAD signaling, the first-hop router
	stores in a Binding Table all known IPv6 addresses used on a point-		stores in a Binding Table all known IPv6 addresses used on a point-
	to-multipoint domain (e.g. VLAN). When a node performs DAD for an		to-multipoint domain (e.g., VLAN). When a node performs DAD for an
	address already used by another node, the first hop router replies		address already used by another node, the first-hop router defends
	instead of this last one.		the address rather than the device using the address.
	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 October 11, 2013.		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/rfc6957.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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. Why existing IETF solutions are not sufficient? . . . . . . . 4		3. Why Existing IETF Solutions Are Not Sufficient . . . . . . . 4
	3.1. Duplicate Address Detection . . . . . . . . . . . . . . . 5		3.1. Duplicate Address Detection . . . . . . . . . . . . . . . 4
	3.2. Neighbor Discovery Proxy . . . . . . . . . . . . . . . . . 5		3.2. Neighbor Discovery Proxy . . . . . . . . . . . . . . . . 5
	3.3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . 5		3.3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . 5
	3.4. IPv6 Mobility Manager . . . . . . . . . . . . . . . . . . 6		3.4. IPv6 Mobility Manager . . . . . . . . . . . . . . . . . . 6
	4. Duplicate Address Detection Proxy (DAD-Proxy)		4. Duplicate Address Detection Proxy (DAD-Proxy) Specifications 6
	specifications . . . . . . . . . . . . . . . . . . . . . . . . 6		4.1. DAD-Proxy Data Structure . . . . . . . . . . . . . . . . 6
	4.1. DAD-Proxy Data structure . . . . . . . . . . . . . . . . . 6		4.2. DAD-Proxy Mechanism . . . . . . . . . . . . . . . . . . . 7
	4.2. DAD-Proxy mechanism . . . . . . . . . . . . . . . . . . . 7		4.2.1. No Entry Exists for the Tentative Address . . . . . . 7
	4.2.1. No entry exists for the tentative address . . . . . . 7		4.2.2. An Entry Already Exists for the Tentative Address . . 7
	4.2.2. An entry already exists for the tentative address . . 7		4.2.3. Confirmation of Reachability to Check the Validity of
	4.2.3. Confirmation of reachability to check the validity		the Conflict . . . . . . . . . . . . . . . . . . . . 9
	of the conflict . . . . . . . . . . . . . . . . . . . 9		5. Manageability Considerations . . . . . . . . . . . . . . . . 11
	5. Manageability Considerations . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6.1. Interoperability with SEND . . . . . . . . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6.2. Protection against IP Source Address Spoofing . . . . . . 11
	7.1. Interoperability with SEND . . . . . . . . . . . . . . . . 11		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	7.2. IP source address spoofing protection . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 12		Appendix A. DAD-Proxy State Machine . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Appendix A. DAD Proxy state machine . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	This document specifies a function called Duplicate Address Detection		This document specifies a function called Duplicate Address Detection
	(DAD) proxy allowing the use of DAD by the nodes on the same point-		(DAD) proxy allowing the use of DAD by the nodes on the same point-
	to-multipoint domain with "split-horizon" forwarding scheme,		to-multipoint domain with a "split-horizon" forwarding scheme,
	primarily deployed for Digital Subscriber Line (DSL) and Fiber access		primarily deployed for Digital Subscriber Line (DSL) and Fiber access
	architectures. It only impacts the first hop router and it doesn't		architectures [TR-101]. It only impacts the first-hop router and it
	need modifications on the other IPv6 nodes. This mechanism is fully		doesn't need modifications on the other IPv6 nodes. This mechanism
	effective if all the nodes of a point-to-multipoint domain (except		is fully effective if all the nodes of a point-to-multipoint domain
	the DAD proxy itself) perform DAD.		(except the DAD proxy itself) perform DAD.
	This document explains also why DAD mechanism [RFC4862] without a		This document explains also why the DAD mechanism [RFC4862] without a
	proxy cannot be used in a point-to-multipoint architecture with		proxy cannot be used in a point-to-multipoint architecture with a
	"split-horizon" forwarding scheme (IPv6 over PPP [RFC5072] is not		"split-horizon" forwarding scheme (IPv6 over PPP [RFC5072] is not
	affected). One of the main reasons is that, because of this		affected). One of the main reasons is that, because of this
	forwarding scheme, IPv6 nodes on the same point-to-multipoint domain		forwarding scheme, IPv6 nodes on the same point-to-multipoint domain
	cannot have direct communication: any communication between them must		cannot have direct communication: any communication between them must
	go through the first hop router of the same domain.		go through the first-hop router of the same domain.
	It is assumed in this document that Link-layer addresses on a point-		It is assumed in this document that link-layer addresses on a point-
	to-multipoint domain are unique from the first hop router's point of		to-multipoint domain are unique from the first-hop router's point of
	view (e.g. in an untrusted Ethernet architecture this assumption can		view (e.g., in an untrusted Ethernet architecture, this assumption
	be guaranteed thanks to mechanisms such as "MAC Address Translation"		can be guaranteed thanks to mechanisms such as Media Access Control
	performed by an aggregation device between IPv6 nodes and the first		(MAC) address translation performed by an aggregation device between
	hop router).		IPv6 nodes and the first-hop router).
	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
	Terminology in this document follows that in Neighbor Discovery for		Terminology in this document follows that in "Neighbor Discovery for
	IP version 6 (IPv6) [RFC4861] and IPv6 Stateless Address		IP version 6 (IPv6)" [RFC4861] and "IPv6 Stateless Address
	Autoconfiguration [RFC4862]. In addition, this section defines		Autoconfiguration" [RFC4862]. In addition, this section defines
	additional terms related to Digital Subscriber Line (DSL) and Fiber		additional terms related to DSL and Fiber access architectures, which
	access architectures, which are an important case where the solution		are an important case where the solution described in this document
	described in this document can be used:		can be used:
	Customer Premises Equipment (CPE)		Customer Premises Equipment (CPE)
	The first IPv6 node in a customer's network.		The first IPv6 node in a customer's network.
	Access Node (AN)		Access Node (AN)
	The first aggregation point in the public access network. It		The first aggregation point in the public access network. It
	is considered as a L2 bridge in this document.		is considered as an L2 bridge in this document.
	Broadband Network Gateway (BNG)		Broadband Network Gateway (BNG)
	The first hop router from the CPE's point of view.		The first-hop router from the CPE's point of view.
	VLAN N:1 architecture		VLAN N:1 architecture
	A point-to-multipoint architecture where many CPEs are		A point-to-multipoint architecture where many CPEs are
	connected to the same VLAN. The CPEs may be connected on the		connected to the same VLAN. The CPEs may be connected on the
	same or different Access Nodes.		same or different Access Nodes.
	split-horizon model		split-horizon model
	A forwarding scheme where CPEs cannot have direct layer 2		A forwarding scheme where CPEs cannot have direct layer 2
	communications between them (i.e. IP flows must be forwarded		communications between them (i.e., IP flows must be forwarded
	through the BNG via routing).		through the BNG via routing).
	The following figure shows where are the different entities defined		The following figure shows where the different entities are, as
	above.		defined above.
	+------+ +----+		+------+ +----+
	| CPE3 |---------| AN |		| CPE3 |---------| AN |
	+------+ +----+		+------+ +----+
	|		|
	|		|
	+------+ +----+		+------+ +----+
	| CPE2 |---------| AN |---+		| CPE2 |---------| AN |---+
	+------+ +----+ |		+------+ +----+ |
	+------+ | |		+------+ | |
	| CPE1 |------------+ |		| CPE1 |------------+ |
	+------+ +-----+		+------+ +-----+
	| BNG |--- Internet		| BNG |--- Internet
	+-----+		+-----+
	Figure 1: DSL and Fiber access Architecture		Figure 1: DSL and Fiber Access Architecture
	3. Why existing IETF solutions are not sufficient?		3. Why Existing IETF Solutions Are Not Sufficient
	In a DSL or Fiber access architecture depicted in Figure 1, CPE1,2,3		In a DSL or Fiber access architecture depicted in Figure 1, CPE1,
	and the BNG are IPv6 nodes, while AN is a L2 bridge providing		CPE2, CPE3, and the BNG are IPv6 nodes, while AN is an L2 bridge
	connectivity between the BNG and each CPE. The AN enforces a split-		providing connectivity between the BNG and each CPE. The AN enforces
	horizon model so that CPEs can only send and receive frames (e.g.		a split-horizon model so that CPEs can only send and receive frames
	Ethernet frames) to and from the BNG but not to each other. That		(e.g., Ethernet frames) to and from the BNG but not to each other.
	said, the BNG is on a same link with all CPE, but one CPE is not on a		That said, the BNG is on the same link with all CPEs, but a given CPE
	same link with any other CPE.		is not on the same link with any other CPE.
	3.1. Duplicate Address Detection		3.1. Duplicate Address Detection
	Duplicate Address Detection (DAD) [RFC4862] is performed when an IPv6		Duplicate Address Detection (DAD) [RFC4862] is performed when an IPv6
	node verifies the uniqueness of a tentative IPv6 address. This node		node verifies the uniqueness of a tentative IPv6 address. This node
	sends a Neighbor Solicitation (NS) message with the IP destination		sends a Neighbor Solicitation (NS) message with the IP destination
	set to the solicited-node multicast address of the tentative address.		set to the solicited-node multicast address of the tentative address.
	This NS message is multicasted to other nodes on the same link. When		This NS message is multicasted to other nodes on the same link. When
	the tentative address is already used on the link by another node,		the tentative address is already used on the link by another node,
	this last one replies with a Neighbor Advertisement (NA) message to		this last one replies with a Neighbor Advertisement (NA) message to
	inform the first node. So when performing DAD, a node expects the NS		inform the first node. So, when performing DAD, a node expects the
	messages to be received by any node currently using the tentative		NS messages to be received by any node currently using the tentative
	address.		address.
	However, in a point-to-multipoint network with split-horizon		However, in a point-to-multipoint network with a split-horizon
	forwarding scheme implemented in the AN, the CPEs are prevented from		forwarding scheme implemented in the AN, the CPEs are prevented from
	talking to each other directly. All packets sent out from a CPE are		talking to each other directly. All packets sent out from a CPE are
	forwarded by the AN only to the BNG but not to any other CPE. NS		forwarded by the AN only to the BNG but not to any other CPE. NS
	messages sent by a certain CPE will be received only by the BNG and		messages sent by a certain CPE will be received only by the BNG and
	will not reach other CPEs. So, other CPEs have no idea that a		will not reach other CPEs. So, other CPEs have no idea that a
	certain IPv6 address is used by another CPE. That means, in a		certain IPv6 address is used by another CPE. That means, in a
	network with split-horizon, DAD, as defined in [RFC4862], can't work		network with split-horizon, DAD, as defined in [RFC4862], can't work
	properly without an additional help.		properly without additional help.
	3.2. Neighbor Discovery Proxy		3.2. Neighbor Discovery Proxy
	Neighbor Discovery (ND) Proxy [RFC4389] is designed for forwarding ND		Neighbor Discovery (ND) Proxy [RFC4389] is designed for forwarding ND
	messages between different IP links where the subnet prefix is the		messages between different IP links where the subnet prefix is the
	same. A ND Proxy function on a bridge ensures that packets between		same. An ND Proxy function on a bridge ensures that packets between
	nodes on different segments can be received by this function and have		nodes on different segments can be received by this function and have
	the correct link-layer address type on each segment. When the ND		the correct link-layer address type on each segment. When the ND
	proxy receives a multicast ND message, it forwards it to all other		Proxy receives a multicast ND message, it forwards it to all other
	interfaces on a same link.		interfaces on a same link.
	In DSL or Fiber networks, when the AN, acting as a ND Proxy, receives		In DSL or Fiber networks, when the AN, acting as an ND Proxy,
	a ND message from a CPE, it will forward it to the BNG but none of		receives an ND message from a CPE, it will forward it to the BNG but
	other CPEs, as only the BNG is on the same link with the CPE. Hence,		none of the other CPEs, as only the BNG is on the same link with the
	implementing ND Proxy on the AN would not help a CPE acknowledge		CPE. Hence, implementing ND Proxy on the AN would not help a CPE
	link-local addresses used by other CPEs.		acknowledge link-local addresses used by other CPEs.
	As the BNG must not forward link-local scoped messages sent from a		As the BNG must not forward link-local scoped messages sent from a
	CPE to other CPEs, ND Proxy cannot be implemented in the BNG.		CPE to other CPEs, ND Proxy cannot be implemented in the BNG.
	3.3. 6LoWPAN Neighbor Discovery		3.3. 6LoWPAN Neighbor Discovery
	[RFC6775] defines an optional modification of DAD for a 6LowPAN.		[RFC6775] defines an optional modification of DAD for IPv6 over Low-
	When a 6LoWPAN node wants to configure an IPv6 address, it registers		Power Wireless Personal Area Networks (6LoWPAN). When a 6LoWPAN node
	that address with one or more of its default routers using the		wants to configure an IPv6 address, it registers that address with
	Address Registration option (ARO). If this address is already owned		one or more of its default routers using the Address Registration
	by another node, the router informs the 6LoWPAN node this address		Option (ARO). If this address is already owned by another node, the
	cannot be configured.		router informs the 6LoWPAN node that this address cannot be
			configured.
	This mechanism requires modifications in all hosts in order to		This mechanism requires modifications in all hosts in order to
	support the Address Registration option.		support the ARO.
	3.4. IPv6 Mobility Manager		3.4. IPv6 Mobility Manager
	According to [RFC6275], a home agent acts as a proxy for mobile nodes		According to [RFC6275], a home agent acts as a proxy for mobile nodes
	when they are away from the home network: the home agent defends an		when they are away from the home network: the home agent defends a
	mobile node's home address by replying to NS messages with NA		mobile node's home address by replying to NS messages with NA
	messages.		messages.
	There is a problem for this mechanism if it is applied in a DSL or		There is a problem for this mechanism if it is applied in a DSL or
	Fiber public access network. Operators of such networks require a NA		Fiber public access network. Operators of such networks require that
	message is only received by the sender of the corresponding NS		an NA message is only received by the sender of the corresponding NS
	message, for security and scalability reasons. However, the home		message, for security and scalability reasons. However, the home
	agent per [RFC6275] multicasts NA messages on the home link and all		agent per [RFC6275] multicasts NA messages on the home link and all
	nodes on this link will receive these NA messages. This shortcoming		nodes on this link will receive these NA messages. This shortcoming
	prevents this mechanism being deployed in DSL or Fiber access		prevents this mechanism from being deployed in DSL or Fiber access
	networks directly.		networks directly.
	4. Duplicate Address Detection Proxy (DAD-Proxy) specifications		4. Duplicate Address Detection Proxy (DAD-Proxy) Specifications
	At first, it is important to note that as this mechanism is strongly		First, it is important to note that, as this mechanism is strongly
	based on DAD [RFC4862], it is not completely reliable and the goal of		based on DAD [RFC4862], it is not completely reliable, and the goal
	this document is not to fix DAD.		of this document is not to fix DAD.
	4.1. DAD-Proxy Data structure		4.1. DAD-Proxy Data Structure
	A BNG needs to store in a Binding Table information related to the		A BNG needs to store in a Binding Table information related to the
	IPv6 addresses generated by any CPE. This Binding Table can be		IPv6 addresses generated by any CPE. This Binding Table can be
	distinct from the Neighbor Cache. This must be done per point to		distinct from the Neighbor Cache. This must be done per point-to-
	multipoint domain (e.g. per Ethernet VLAN). Each entry in this		multipoint domain (e.g., per Ethernet VLAN). Each entry in this
	Binding Table MUST contain the following fields:		Binding Table MUST contain the following fields:
	o IPv6 Address		o IPv6 Address
	o Link-layer Address		o Link-layer Address
	For security or performances reasons, it must be possible to limit		For security or performances reasons, it must be possible to limit
	the number of IPv6 Addresses per Link-layer Address (possibly, but		the number of IPv6 addresses per link-layer address (possibly, but
	not necessarily, to 1).		not necessarily, to 1).
	On the reception of an unsolicited NA (e.g., when a CPE wishes to		On the reception of an unsolicited NA (e.g., when a CPE wishes to
	inform its neighbors of a new link-layer address) for an IPv6 address		inform its neighbors of a new link-layer address) for an IPv6 address
	already recorded in the Binding Table, each entry associated to this		already recorded in the Binding Table, each entry associated to this
	IPv6 address MUST be updated consequently: the current Link-layer		IPv6 address MUST be updated consequently: the current link-layer
	Address is replaced by the one included in the unsolicited NA		address is replaced by the one included in the unsolicited NA
	message.		message.
	For security or performances reasons, the Binding Table MUST be large		For security or performances reasons, the Binding Table MUST be large
	enough for the deployment in which it is used: if the Binding Table		enough for the deployment in which it is used: if the Binding Table
	is distinct from the Neighbor Cache, it MUST have at least the same		is distinct from the Neighbor Cache, it MUST be at least the same
	size as this last one. Implementations MUST either state the fixed		size as this last one. Implementations MUST either state the fixed
	size of Binding Table that they support or make the size		size of the Binding Table that they support or make the size
	configurable. In the latter case, implementations MUST state the		configurable. In the latter case, implementations MUST state the
	largest Binding Table size that they support. Additionally,		largest Binding Table size that they support. Additionally,
	implementations SHOULD allow an operator to enquire the current		implementations SHOULD allow an operator to inquire about the current
	occupancy level of the Binding Table to determine if it is about to		occupancy level of the Binding Table to determine if it is about to
	become full. Implementations encountering a full Binding Table will		become full. Implementations encountering a full Binding Table will
	likely handle it in a way similar to NS message loss.		likely handle it in a way similar to NS message loss.
	It is recommended to apply technical solutions to minimize the risk		It is recommended to apply technical solutions to minimize the risk
	that the Binding Table becomes full. These solutions are out of the		that the Binding Table becomes full. These solutions are out of the
	scope of this document.		scope of this document.
	4.2. DAD-Proxy mechanism		4.2. DAD-Proxy Mechanism
	When a CPE performs DAD, as specified in [RFC4862], it sends a		When a CPE performs DAD, as specified in [RFC4862], it sends a
	Neighbor Solicitation (NS) message, with the unspecified address as		Neighbor Solicitation (NS) message, with the unspecified address as
	the source address, in order to check if a tentative address is		the source address, in order to check if a tentative address is
	already in use on the link. The BNG receives this message and MUST		already in use on the link. The BNG receives this message and MUST
	perform actions specified in the following sections based on the		perform actions specified in the following sections based on the
	information in the Binding Table.		information in the Binding Table.
	4.2.1. No entry exists for the tentative address		4.2.1. No Entry Exists for the Tentative Address
	When there is no entry for the tentative address, the BNG MUST create		When there is no entry for the tentative address, the BNG MUST create
	one with the following information:		one with the following information:
	o IPv6 Address Field set to the tentative address in the NS message.		o IPv6 Address field set to the tentative address in the NS message.
	o Link-layer Address Field set to the Link-layer source address in		o Link-layer Address field set to the link-layer source address in
	the Link-layer Header of the NS message.		the link-layer header of the NS message.
	The BNG MUST NOT reply to the CPE or forward the NS message.		The BNG MUST NOT reply to the CPE or forward the NS message.
	4.2.2. An entry already exists for the tentative address		4.2.2. An Entry Already Exists for the Tentative Address
	When there is an entry for the tentative address, the BNG MUST check		When there is an entry for the tentative address, the BNG MUST check
	the following conditions:		the following conditions:
	o The address in the Target Address Field in the NS message is equal		o The address in the Target Address field in the NS message is equal
	to the address in the IPv6 Address Field in the entry.		to the address in the IPv6 Address field in the entry.
	o The source address of the IPv6 Header in the NS message is equal		o The source address of the IPv6 Header in the NS message is equal
	to the unspecified address.		to the unspecified address.
	When these conditions are met and the source address of the Link-		When these conditions are met and the source address of the link-
	Layer Header in the NS message is equal to the address in the Link-		layer header in the NS message is equal to the address in the Link-
	Layer Address Field in the entry, that means the CPE is still		layer Address field in the entry, that means the CPE is still
	performing DAD for this address. The BNG MUST NOT reply to the CPE		performing DAD for this address. The BNG MUST NOT reply to the CPE
	or forward the NS message.		or forward the NS message.
	When these conditions are met and the source address of the Link-		When these conditions are met and the source address of the link-
	Layer Header in the NS message is not equal to the address in the		layer header in the NS message is not equal to the address in the
	Link-Layer Address Field in the entry, that means possibly another		Link-layer Address field in the entry, that means possibly another
	CPE performs DAD for an already owned address. The BNG then has to		CPE is performing DAD for an already owned address. The BNG then has
	verify whether there is a real conflict by checking if the CPE whose		to verify whether there is a real conflict by checking if the CPE
	IPv6 address is in the entry is still connected. In the following,		whose IPv6 address is in the entry is still connected. In the
	we will call IPv6-CPE1 the IPv6 address of the existing entry in the		following text, we will call IPv6-CPE1 the IPv6 address of the
	Binding Table, Link-layer-CPE1 the Link-layer address of that entry		existing entry in the Binding Table, Link-layer-CPE1 the link-layer
	and Link-layer-CPE2 the Link-layer address of the CPE which is		address of that entry, and Link-layer-CPE2 the link-layer address of
	performing DAD, which is different from Link-layer-CPE1.		the CPE that is performing DAD, which is different from Link-layer-
			CPE1.
	The BNG MUST check if the potential address conflict is real. In		The BNG MUST check if the potential address conflict is real. In
	particular:		particular:
	o If IPv6-CPE1 is in the Neighbor Cache and it is associated with		o If IPv6-CPE1 is in the Neighbor Cache and it is associated with
	Link-layer-CPE1, the reachability of IPv6-CPE1 MUST be confirmed		Link-layer-CPE1, the reachability of IPv6-CPE1 MUST be confirmed
	as explained in Section 4.2.3.		as explained in Section 4.2.3.
	o If IPv6-CPE1 is in the Neighbor Cache, but in this cache it is		o If IPv6-CPE1 is in the Neighbor Cache, but in this cache it is
	associated with another Link-layer address than Link-layer-CPE1,		associated with a link-layer address other than Link-layer-CPE1,
	that means that there is possibly a conflict with another CPE, but		that means that there is possibly a conflict with another CPE, but
	that CPE did not perform DAD. This situation is out of the scope		that CPE did not perform DAD. This situation is out of the scope
	of this document, since one assumption made above is that all the		of this document, since one assumption made above is that all the
	nodes of a point-to-multipoint domain (except the DAD proxy		nodes of a point-to-multipoint domain (except the DAD proxy
	itself) perform DAD.		itself) perform DAD.
	o If IPv6-CPE1 is not in the Neighbor Cache, then the BNG MUST		o If IPv6-CPE1 is not in the Neighbor Cache, then the BNG MUST
	create a new entry based on the information of the entry in the		create a new entry based on the information of the entry in the
	Binding Table. This step is necessary in order to trigger the		Binding Table. This step is necessary in order to trigger the
	reachibility check as explained in Section 4.2.3. The entry in		reachability check as explained in Section 4.2.3. The entry in
	the Neighbor Cache MUST be created based on the algorithm defined		the Neighbor Cache MUST be created based on the algorithm defined
	in section 7.3.3 of [RFC4861], in particular by considering the		in Section 7.3.3 of [RFC4861], in particular by treating this case
	case as if a packet other than a solicited Neighbor Advertisement		as though a packet other than a solicited Neighbor Advertisement
	was received from IPv6-CPE1. That means that the new entry of the		were received from IPv6-CPE1. Thus, the new entry of the Neighbor
	Neighbor Cache MUST contain the following information:		Cache MUST contain the following information:
	* IPv6 address: IPv6-CPE1		* IPv6 address: IPv6-CPE1
	* Link-layer address: Link-layer-CPE1		* Link-layer address: Link-layer-CPE1
	* State: STALE		* State: STALE
	Then the reachability of IPv6-CPE1 MUST be confirmed as soon as		The reachability of IPv6-CPE1 MUST be confirmed as soon as
	possible following the procedure explained in section 4.2.3.		possible following the procedure explained in Section 4.2.3.
	4.2.3. Confirmation of reachability to check the validity of the		4.2.3. Confirmation of Reachability to Check the Validity of the
	conflict		Conflict
	Given that the IPv6-CPE1 is in an entry of the Neighbor Cache, the		Given that the IPv6-CPE1 is in an entry of the Neighbor Cache, the
	reachability of IPv6-CPE1 is checked by using the NUD (Neighbor		reachability of IPv6-CPE1 is checked by using the Neighbor
	Unreachibility Detection) mechanism described in section 7.3.1 of		Unreachability Detection (NUD) mechanism described in Section 7.3.1
	[RFC4861]. This mechanism MUST be triggered as if a packet has to be		of [RFC4861]. This mechanism MUST be triggered as though a packet
	sent to IPv6-CPE1. Note that in some cases this mechanism does not		had to be sent to IPv6-CPE1. Note that in some cases this mechanism
	do anything, for instance if the state of the entry is REACHABLE and		does not do anything. For instance, if the state of the entry is
	a positive confirmation was received recently that the forward path		REACHABLE and a positive confirmation was received recently that the
	to the IPv6-CPE1 was functioning properly (see RFC 4861 for more		forward path to the IPv6-CPE1 was functioning properly (see RFC 4861
	details).		for more details), this mechanism does not do anything.
	Next, the behavior of the BNG depends on the result of the NUD		Next, the behavior of the BNG depends on the result of the NUD
	process, as explained in the following sections.		process, as explained in the following sections.
	4.2.3.1. The result of the NUD process is negative		4.2.3.1. The Result of the NUD Process is Negative
	If the result of the NUD process is negative (i.e. if this process		If the result of the NUD process is negative (i.e., if this process
	removes IPv6-CPE1 from the Neighbor Cache), that means that the		removes IPv6-CPE1 from the Neighbor Cache), that means that the
	potential conflict is not real.		potential conflict is not real.
	The conflicting entry in the Binding Table (Link-layer-CPE1) is		The conflicting entry in the Binding Table (Link-layer-CPE1) is
	deleted and it is replaced by a new entry with the same IPv6 address,		deleted and it is replaced by a new entry with the same IPv6 address,
	but the Link-layer address of the CPE which is performing DAD (Link-		but the link-layer address of the CPE is performing DAD (Link-layer-
	layer-CPE2), as explained in Section 4.2.1.		CPE2), as explained in Section 4.2.1.
	4.2.3.2. The result of the NUD process is positive		4.2.3.2. The Result of the NUD Process is Positive
	If the result of the NUD process is positive (i.e. if after this		If the result of the NUD process is positive (i.e., if after this
	process the state of IPv6-CPE1 is REACHABLE), that means that the		process the state of IPv6-CPE1 is REACHABLE), that means that the
	potential conflict is real.		potential conflict is real.
	As shown in Figure 2, the BNG MUST reply to CPE that is performing		As shown in Figure 2, the BNG MUST reply to the CPE that is
	DAD (CPE2 in Figure 1) with a NA message which has the following		performing DAD (CPE2 in Figure 1) with an NA message that has the
	format:		following format:
	Layer 2 Header Fields:		Layer 2 Header Fields:
	Source Address		Source Address
	The Link-layer address of the interface on which the BNG		The link-layer address of the interface on which the BNG
	received the NS message.		received the NS message.
	Destination Address		Destination Address
	The source address in the Layer 2 Header of the NS		The source address in the Layer 2 Header of the NS
	message received by the BNG (i.e. Link-layer-CPE2)		message received by the BNG (i.e., Link-layer-CPE2).
	IPv6 Header Fields:		IPv6 Header Fields:
	Source Address		Source Address
	An address assigned to the interface from which the		An address assigned to the interface from which the
	advertisement is sent.		advertisement is sent.
	Destination Address		Destination Address
	The all-nodes multicast address.		The all-nodes multicast address.
	ICMPv6 Fields:		ICMPv6 Fields:
	Target Address		Target Address
	The tentative address already used (i.e. IPv6-CPE1).		The tentative address already used (i.e., IPv6-CPE1).
	Target Link-layer address		Target Link-layer Address
	The Link-layer address of the interface on which the BNG		The link-layer address of the interface on which the BNG
	received the NS message.		received the NS message.
	CPE1 CPE2 BNG		CPE1 CPE2 BNG
	| | |		| | |
	(a)| | |		(a)| | |
	| | |		| | |
	(b)|===================>|		(b)|===================>|
	| | |(c)		| | |(c)
	| | |		| | |
	| (d)| |		| (d)| |
	| | |		| | |
	| (e)|=========>|		| (e)|=========>|
	| | |		| | |
	| |<=========|(f)		| |<=========|(f)
	| | |		| | |
	(a) CPE1 generated a tentative address		(a) CPE1 generates a tentative address
	(b) CPE1 performs DAD for this one		(b) CPE1 performs DAD for this one
	(c) BNG updates its Binding Table		(c) BNG updates its Binding Table
	(d) CPE2 generates a same tentative address		(d) CPE2 generates a same tentative address
	(e) CPE2 performs DAD for this one		(e) CPE2 performs DAD for this one
	(f) BNG informs CPE2 that DAD fails		(f) BNG informs CPE2 that DAD fails
	Figure 2
	The BNG and the CPE MUST support the Unicast Transmission on Link-		Figure 2: DAD Failure
	layer of IPv6 Multicast Messages [RFC6085], to be able, respectively,
			The BNG and the CPE MUST support the unicast transmission on the link
			layer of IPv6 multicast messages [RFC6085], to be able, respectively,
	to generate and to process such a packet format.		to generate and to process such a packet format.
	5. Manageability Considerations		5. Manageability Considerations
	The BNG SHOULD support a mechanism to log and emit alarms whenever a		The BNG SHOULD support a mechanism to log and emit alarms whenever a
	duplication of IPv6 addresses is detected by the DAD-Proxy function.		duplication of IPv6 addresses is detected by the DAD-Proxy function.
	Moreover, the BNG SHOULD implement a function to allow an operator to		Moreover, the BNG SHOULD implement a function to allow an operator to
	access logs and to see the current entries in the Binding Table. The		access logs and to see the current entries in the Binding Table. The
	management of access rights to get this information is out of the		management of access rights to get this information is out of the
	scope of this document.		scope of this document.
	6. IANA Considerations		6. Security Considerations
	No new options or messages are defined in this document.
	7. Security Considerations
	7.1. Interoperability with SEND		6.1. Interoperability with SEND
	The mechanism described in this document will not interoperate with		The mechanism described in this document will not interoperate with
	SEcure Neighbor Discovery (SEND) [RFC3971]. This is due to the BNG		SEcure Neighbor Discovery (SEND) [RFC3971]. This is due to the BNG
	not owning the private key associated with the Cryptographically		not owning the private key associated with the Cryptographically
	Generated Address (CGA) [RFC3972] needed to correctly sign the		Generated Address (CGA) [RFC3972] needed to correctly sign the
	proxied ND messages [RFC5909].		proxied ND messages [RFC5909].
	Secure Proxy ND Support for SEND [RFC6496] has been specified to		Secure Proxy ND Support for SEND [RFC6496] has been specified to
	address this limitation, and SHOULD be implemented and used on the		address this limitation, and it SHOULD be implemented and used on the
	BNG and the CPEs.		BNG and the CPEs.
	7.2. IP source address spoofing protection		6.2. Protection against IP Source Address Spoofing
	To ensure protection against IP source address spoofing in data		To ensure protection against IP source address spoofing in data
	packets, this proposal can be used in combinaison with Source Address		packets, this proposal can be used in combination with Source Address
	Validation Improvement (SAVI) mechanisms [RFC6620]		Validation Improvement (SAVI) mechanisms [RFC6620] [SAVI-SEND]
	[I-D.ietf-savi-send] [I-D.ietf-savi-mix].		[SAVI-MIX].
	If so, the SAVI device is the BNG and the Binding Anchor for a CPE is		If SAVI mechanisms are used, the SAVI device is the BNG, and the
	its MAC address, which is assumed to be unique in this document (cf.		Binding Anchor for a CPE is its MAC address, which is assumed to be
	Section 1).		unique in this document (cf. Section 1).
	8. Acknowledgments		7. Acknowledgments
	The authors would like to thank Alan Kavanagh, Wojciech Dec, Suresh		The authors would like to thank Alan Kavanagh, Wojciech Dec, Suresh
	Krishnan and Tassos Chatzithomaoglou for their comments. The authors		Krishnan, and Tassos Chatzithomaoglou for their comments. The
	would like also to thank the IETF 6man WG members and the BBF		authors would like also to thank the IETF 6man WG members and the BBF
	community for their support.		community for their support.
	9. References		8. References
	9.1. Normative References		8.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", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
	[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless		[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
	Address Autoconfiguration", RFC 4862, September 2007.		Address Autoconfiguration", RFC 4862, September 2007.
	[RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec,		[RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec,
	"Address Mapping of IPv6 Multicast Packets on Ethernet",		"Address Mapping of IPv6 Multicast Packets on Ethernet",
	RFC 6085, January 2011.		RFC 6085, January 2011.
	9.2. Informative References		8.2. Informative References
	[I-D.ietf-savi-mix]		[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
	Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, "SAVI		Neighbor Discovery (SEND)", RFC 3971, March 2005.
	for Mixed Address Assignment Methods Scenario",
	draft-ietf-savi-mix-03 (work in progress), November 2012.
	[I-D.ietf-savi-send]		[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
	Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source-		RFC 3972, March 2005.
	Address Validation Implementation",
	draft-ietf-savi-send-09 (work in progress), April 2013.
	[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure		[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
	Neighbor Discovery (SEND)", RFC 3971, March 2005.		Proxies (ND Proxy)", RFC 4389, April 2006.
	[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",		[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6
	RFC 3972, March 2005.		over PPP", RFC 5072, September 2007.
	[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery		[RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing
	Proxies (ND Proxy)", RFC 4389, April 2006.		Neighbor Discovery Proxy: Problem Statement", RFC 5909,
			July 2010.
	[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over		[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
	PPP", RFC 5072, September 2007.		in IPv6", RFC 6275, July 2011.
	[RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing		[RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-
	Neighbor Discovery Proxy: Problem Statement", RFC 5909,		Martinez, "Secure Proxy ND Support for SEcure Neighbor
	July 2010.		Discovery (SEND)", RFC 6496, February 2012.
	[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support		[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
	in IPv6", RFC 6275, July 2011.		SAVI: First-Come, First-Served Source Address Validation
			Improvement for Locally Assigned IPv6 Addresses", RFC
			6620, May 2012.
	[RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-		[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C.
	Martinez, "Secure Proxy ND Support for SEcure Neighbor		Bormann, "Neighbor Discovery Optimization for IPv6 over
	Discovery (SEND)", RFC 6496, February 2012.		Low-Power Wireless Personal Area Networks (6LoWPANs)",
			RFC 6775, November 2012.
	[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS		[SAVI-MIX] Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, Ed.,
	SAVI: First-Come, First-Served Source Address Validation		"SAVI for Mixed Address Assignment Methods Scenario",
	Improvement for Locally Assigned IPv6 Addresses",		Work in Progress, May 2013.
	RFC 6620, May 2012.
	[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,		[SAVI-SEND] Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source-
	"Neighbor Discovery Optimization for IPv6 over Low-Power		Address Validation Implementation", Work in Progress,
	Wireless Personal Area Networks (6LoWPANs)", RFC 6775,		April 2013.
	November 2012.
	Appendix A. DAD Proxy state machine		[TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL
			Aggregation", Issue 2, Technical Report TR-101, July
			2011, <http://www.broadband-forum.org/technical/download/
			TR-101_Issue-2.pdf>.
	This appendix, informative, contains a summary (cf. Table 1) of the		Appendix A. DAD-Proxy State Machine
	actions done by the BNG when it receives a DAD based NS (DAD-NS)
	message. The tentative address in this message is IPv6-CPE1 and the
	associated Link-layer address is Link-layer-CPE2. The actions are
	precisely specified in Section 4.2.
	+------------+---------------------+-------------------+------------+		This appendix, which is informative, contains a summary (cf. Table 1)
	| Event | Check | Action | New event |		of the actions done by the BNG when it receives a DAD-based NS
	+------------+---------------------+-------------------+------------+		(DAD-NS) message. The tentative address in this message is IPv6-CPE1
	| DAD-NS | o No entry for | Create an entry | - |		and the associated link-layer address is Link-layer-CPE2. The
	| message | IPv6-CPE1 in the | for IPv6-CPE1 | |		actions are precisely specified in Section 4.2.
	| reception. | Binding Table. | bound to | |
	| | | Link-layer-CPE2 | |		+------------+--------------------+--------------------+------------+
	| | | in the Binding | |		| Event | Check | Action | New event |
	| | | Table. | |		+------------+--------------------+--------------------+------------+
	| | o Entry for | - | Existing |		| DAD-NS | * No entry for | Create an entry | - |
	| | IPv6-CPE1 in the | | entry |		| message | IPv6-CPE1 in the | for IPv6-CPE1 | |
	| | Binding Table. | | |		| reception. | Binding Table. | bound to Link- | |
	| Existing | o Link-layer-CPE2 | - | - |		| | | layer-CPE2 in the | |
	| entry | bound to IPv6-CPE1 | | |		| | | Binding Table. | |
	| | in the Binding | | |		| | * Entry for | - | Existing |
	| | Table. | | |		| | IPv6-CPE1 in the | | entry. |
	| | o Another | - | Conflict? |		| | Binding Table. | | |
	| | Link-layer address, | | |		| | | | |
	| | Link-layer-CPE1, | | |		| Existing | * Link-layer-CPE2 | - | - |
	| | bound to IPv6-CPE1 | | |		| entry. | bound to IPv6-CPE1 | | |
	| | in the Binding | | |		| | in the Binding | | |
	| | Table. | | |		| | Table. | | |
	| Conflict? | o IPv6-CPE1 | - | Reachable? |		| | * Another link- | - | Conflict? |
	| | associated to | | |		| | layer address, | | |
	| | Link-layer-CPE1 in | | |		| | Link-layer-CPE1, | | |
	| | the Neighbor Cache. | | |		| | bound to IPv6-CPE1 | | |
	| | o IPv6-CPE1 | Out of scope. | - |		| | in the Binding | | |
	| | associated to | | |		| | Table. | | |
	| | another Link-layer | | |		| | | | |
	| | address than | | |		| Conflict? | * IPv6-CPE1 | - | Reachable? |
	| | Link-layer-CPE1 in | | |		| | associated to | | |
	| | the Neighbor Cache. | | |		| | Link-layer-CPE1 in | | |
	| | o IPv6-CPE1 is not | Create an entry | Reachable? |		| | the Neighbor | | |
	| | in the Neighbor | for IPv6-CPE1 | |		| | Cache. | | |
	| | Cache. | associated to | |		| | * IPv6-CPE1 | Out of scope. | - |
	| | | Link-layer-CPE1 | |		| | associated to | | |
	| | | in the Neighbor | |		| | another link-layer | | |
	| | | Cache. | |		| | address than Link- | | |
	| Reachable? | o NUD process is | IPv6-CPE2 is | - |		| | layer-CPE1 in the | | |
	| | negative. | bound to | |		| | Neighbor Cache. | | |
	| | | Link-layer-CPE2, | |		| | * IPv6-CPE1 is not | Create an entry | Reachable? |
	| | | instead to | |		| | in the Neighbor | for IPv6-CPE1 | |
	| | | Link-layer-CPE1, | |		| | Cache. | associated to | |
	| | | in the Binding | |		| | | Link-layer-CPE1 in | |
	| | | Table. | |		| | | the Neighbor | |
	| | o NUD process is | A NA message is | - |		| | | Cache. | |
	| | positive. | sent. | |		| Reachable? | * NUD process is | IPv6-CPE2 is bound | - |
	+------------+---------------------+-------------------+------------+		| | negative. | to Link-layer- | |
	Table 1		| | | CPE2, instead to | |
			| | | Link-layer-CPE1, | |
			| | | in the Binding | |
			| | | Table. | |
			| | * NUD process is | A NA message is | - |
			| | positive. | sent. | |
			+------------+--------------------+--------------------+------------+
			Table 1: DAD-Proxy State Machine
	Authors' Addresses		Authors' Addresses
	Fabio Costa		Fabio Costa
	France Telecom Orange		France Telecom Orange
	61 rue des Archives		61 rue des Archives
	75141 Paris Cedex 03		75141 Paris Cedex 03
	France		France
	Email: fabio.costa@orange.com		EMail: fabio.costa@orange.com
	Jean-Michel Combes (editor)		Jean-Michel Combes (editor)
	France Telecom Orange		France Telecom Orange
	38 rue du General Leclerc		38 rue du General Leclerc
	92794 Issy-les-Moulineaux Cedex 9		92794 Issy-les-Moulineaux Cedex 9
	France		France
	Email: jeanmichel.combes@orange.com		EMail: jeanmichel.combes@orange.com
	Xavier Pougnard		Xavier Pougnard
	France Telecom Orange		France Telecom Orange
	2 avenue Pierre Marzin		2 avenue Pierre Marzin
	22300 Lannion		22300 Lannion
	France		France
	Email: xavier.pougnard@orange.com		EMail: xavier.pougnard@orange.com
	Hongyu Li		Hongyu Li
	Huawei Technologies		Huawei Technologies
	Huawei Industrial Base		Huawei Industrial Base
	Shenzhen		Shenzhen
	China		China
	Email: lihy@huawei.com		EMail: lihy@huawei.com
End of changes. 107 change blocks.
	298 lines changed or deleted		297 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/