< draft-faq-netmod-cpe-yang-profile-00.txt		draft-faq-netmod-cpe-yang-profile-01.txt >
	NETMOD WG I. Farrer		NETMOD WG I. Farrer
	Internet-Draft Q. Sun		Internet-Draft Q. Sun
	Intended status: Informational S. Zoric		Intended status: Informational S. Zoric
	Expires: April 18, 2016 Deutsche Telekom AG		Expires: September 14, 2017 Deutsche Telekom AG
	M. Abrahamsson		M. Abrahamsson
	T-Systems		T-Systems
	October 16, 2015		March 13, 2017
	YANG Models Required for Managing Customer Premises Equipment (CPE)		YANG Models Required for Managing Residential Gateway (RG) Devices
	Devices		draft-faq-netmod-cpe-yang-profile-01
	draft-faq-netmod-cpe-yang-profile-00
	Abstract		Abstract
	This document collects together the YANG models necessary for		This document collects together the set of YANG models necessary for
	managing NETCONF-enabled Customer Premises Equipment (CPE) devices.		managing NETCONF-enabled Residential Gateway (RG) devices.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at 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."
	This Internet-Draft will expire on April 18, 2016.		This Internet-Draft will expire on September 14, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Management Requirements . . . . . . . . . . . . . . . . . . . 3		3. Management Requirements . . . . . . . . . . . . . . . . . . . 3
	3.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 3		3.1. General Requirements . . . . . . . . . . . . . . . . . . 3
	3.1.1. Requirements . . . . . . . . . . . . . . . . . . . . 4		3.1.1. Requirements . . . . . . . . . . . . . . . . . . . . 4
	3.1.2. Development Status of Relevant YANG Models . . . . . 4		3.1.2. Development Status of Relevant YANG Models . . . . . 4
	3.2. IP Management . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2.1. Requirements . . . . . . . . . . . . . . . . . . . . 5		3.2.1. Requirements . . . . . . . . . . . . . . . . . . . . 4
	3.2.2. Development of Relevant YANG Models . . . . . . . . . 5		3.2.2. Development Status of Relevant YANG Models . . . . . 5
	3.3. Routing and Multicast Management . . . . . . . . . . . . 5		3.3. IP Management . . . . . . . . . . . . . . . . . . . . . . 5
	3.3.1. Requirements . . . . . . . . . . . . . . . . . . . . 5		3.3.1. Requirements . . . . . . . . . . . . . . . . . . . . 5
	3.3.2. Development of Relevant YANG Models . . . . . . . . . 6		3.3.2. Development Status of Relevant YANG Models . . . . . 6
	3.4. CPE NETCONF Server Management . . . . . . . . . . . . . . 6		3.4. Routing and Multicast Management . . . . . . . . . . . . 6
	3.4.1. Requirements . . . . . . . . . . . . . . . . . . . . 6		3.4.1. Requirements . . . . . . . . . . . . . . . . . . . . 6
	3.4.2. Development Status of Relevant YANG Models . . . . . 6		3.4.2. Development of Relevant YANG Models . . . . . . . . . 6
	3.5. DHCP/SLAAC/ND Management . . . . . . . . . . . . . . . . 7		3.5. RG NETCONF Server Management . . . . . . . . . . . . . . 7
	3.5.1. Requirements . . . . . . . . . . . . . . . . . . . . 7		3.5.1. Requirements . . . . . . . . . . . . . . . . . . . . 7
	3.5.2. Development Status of Relevant YANG Models . . . . . 7		3.5.2. Development Status of Relevant YANG Models . . . . . 7
	3.6. NAT Management . . . . . . . . . . . . . . . . . . . . . 8		3.6. DHCP/SLAAC/ND Management . . . . . . . . . . . . . . . . 7
	3.6.1. Requirements . . . . . . . . . . . . . . . . . . . . 8		3.6.1. Requirements . . . . . . . . . . . . . . . . . . . . 7
	3.6.2. Development Status of Relevant YANG Models . . . . . 8		3.6.2. Development Status of Relevant YANG Models . . . . . 8
	3.7. IPv6 Transition Mechanisms Management . . . . . . . . . . 8		3.7. NAT Management . . . . . . . . . . . . . . . . . . . . . 8
	3.7.1. Requirements . . . . . . . . . . . . . . . . . . . . 8		3.7.1. Requirements . . . . . . . . . . . . . . . . . . . . 8
	3.7.2. Development of Relevant YANG Models . . . . . . . . . 9		3.7.2. Development Status of Relevant YANG Models . . . . . 9
	3.8. Management of Specific Services . . . . . . . . . . . . . 9		3.8. IPv6 Transition Mechanisms Management . . . . . . . . . . 9
	3.8.1. Requirements . . . . . . . . . . . . . . . . . . . . 9		3.8.1. Requirements . . . . . . . . . . . . . . . . . . . . 9
	3.8.2. Development of Relevant YANG Models . . . . . . . . . 9		3.8.2. Development of Relevant YANG Models . . . . . . . . . 9
	3.9. Management of Security Components . . . . . . . . . . . . 10		3.9. Management of Specific Services . . . . . . . . . . . . . 10
	3.9.1. Requirements . . . . . . . . . . . . . . . . . . . . 10		3.9.1. Requirements . . . . . . . . . . . . . . . . . . . . 10
	3.9.2. Development of Relevant YANG Models . . . . . . . . . 10		3.9.2. Development of Relevant YANG Models . . . . . . . . . 10
	3.10. Remote CPE Software Upgrade . . . . . . . . . . . . . . . 10		3.10. Management of Security Components . . . . . . . . . . . . 10
	3.10.1. Requirements . . . . . . . . . . . . . . . . . . . . 10		3.10.1. Requirements . . . . . . . . . . . . . . . . . . . . 10
	3.10.2. Development of Relevant YANG Models . . . . . . . . 11		3.10.2. Development of Relevant YANG Models . . . . . . . . 11
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 11		3.11. Remote RG Software Upgrade . . . . . . . . . . . . . . . 11
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		3.11.1. Requirements . . . . . . . . . . . . . . . . . . . . 11
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		3.11.2. Development of Relevant YANG Models . . . . . . . . 11
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	7.1. Normative References . . . . . . . . . . . . . . . . . . 11		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7.2. Informative References . . . . . . . . . . . . . . . . . 14		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
			7.1. Normative References . . . . . . . . . . . . . . . . . . 12
			7.2. Informative References . . . . . . . . . . . . . . . . . 15
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	This document defines the requirements and specifies the necessary		This document defines the requirements and specifies the necessary
	YANG models for managing residential CPE devices using NETCONF and		YANG models for managing RG devices using NETCONF [RFC6241] and YANG
	YANG. Implementing NETCONF on CPE devices, along with the relevant		[RFC6020]. Implementing NETCONF on RG devices, along with the
	YANG models, provides operators with a flexible and extensible		relevant YANG models, provides operators with a flexible and
	management interface.		extensible management interface.
	Many of the YANG models referenced here are in various stages in the		Many of the YANG models referenced here are in various stages in the
	development process. In some cases there is currently no existing		development process. In some cases there is currently no existing
	work. The aim of this document is to catalog which models are		work. The aim of this document is to catalog which models are
	necessary, and for each referenced YANG model, provide information		necessary, and for each referenced YANG model, provide information
	about the current status of the existing work. It is intended as a		about the current status of the existing work. It is intended as a
	'living document', which will be updated as the required / referenced		'living document', which will be updated as the required / referenced
	YANG models progress. Once finalised, the goal of the document is to		YANG models progress. Once finalised, the goal of the document is to
	serve as a CPE YANG 'Device profile' that can be used as a reference		serve as a RG YANG 'Device profile' that can be used as a reference
	for operators and implementors who are adding YANG management		for operators and implementors who are adding YANG management
	capabilities to their devices.		capabilities to their devices.
	2. Terminology		2. Terminology
	CPE Customer Premises Equipment; provides access		RG Residential Gateway; provides access between a
	between a customer's LAN connected devices and		customer's LAN connected devices and their ISP's
	their ISP's network. In the context of this		network. In the context of this document, the RG
	document, the CPE device implements NETCONF/YANG.		device implements NETCONF/YANG. This document
	This document focuses on the type of residential		focuses on the type of Residential Gateway that
	CPE that typically exists between the Internet		typically exists between the Internet Service
	Service Provider access line and residential		Provider access line and residential customer home,
	customer home, doing similar functions that for		performing functions such as those described in
	example [RFC7084] lists.		[RFC7084].
	Existing RFCs Lists YANG models defined in published RFCs.		Existing RFCs Lists YANG models defined in published RFCs.
	Work In Progress YANG models under development in active Internet		Work In Progress YANG models under development in active Internet
	Drafts, or relevant documents being produced by		Drafts, or relevant documents being produced by
	SDOs other than the IETF.		SDOs other than the IETF.
	To Be Defined YANG models that are identified as necessary for		To Be Defined YANG models that are identified as necessary for RG
	CPE management, but are not currently known to be		management, but are not currently known to be in
	in development at the time of writing.		development at the time of writing.
	3. Management Requirements		3. Management Requirements
	3.1. Interfaces		3.1. General Requirements
	A CPE has a number of network interfaces, usually including some of		The following requirements are necessary for basic RG hardware
			management.
			3.1.1. Requirements
			GEN-1 The RG YANG implementation MUST provide a model for the
			management of hardware.
			3.1.2. Development Status of Relevant YANG Models
			Existing RFCs:
			o None
			Work In Progress:
			o A YANG Data Model for Hardware Management:
			[I-D.han-netmod-intf-ext-ppp-yang]
			To Be Defined (and SDOs that might be responsible for the standards)
			o None
			3.2. Interfaces
			A RG has a number of network interfaces, usually including some of
	the following interface types: Ethernet LAN, Ethernet WAN, Ethernet		the following interface types: Ethernet LAN, Ethernet WAN, Ethernet
	802.1q, Ethernet 802.1ag, and WLAN (802.11a/b/n/g/ac). [RFC7223]		802.1q, Ethernet 802.1ag, and WLAN (802.11a/b/n/g/ac). [RFC7223]
	defines a YANG model for general interface management, which		defines a YANG model for general interface management, which
	identifies these (and other) interface types. However, Ethernet		identifies these (and other) interface types.
	standardisation is carried out by the IEEE, so it is probable where
	YANG models for managing these interfaces would be developed.
	NB - The list of interface types necessary for a complete, general		NB - The list of interface types necessary for a complete, general
	HGW model needs to include xDSL (BBF) and DOCSIS (ITU) interfaces.		HGW model needs to include xDSL (BBF) and DOCSIS (ITU) interfaces.
	These will be included in a future version of this document.		These will be included in a future version of this document.
	3.1.1. Requirements		3.2.1. Requirements
	The following requirements are necessary for basic CPE management		The following requirements are necessary for basic RG interface
	functionality.		management functionality.
	INT-1: The CPE YANG implementation MUST implement general interface		INT-1: The RG YANG implementation MUST implement general interface
	management.		management.
	INT-2: The CPE YANG implementation MUST enable the configuration and		INT-2: The RG YANG implementation MUST enable the configuration and
	management for the following interface types:		management (incl operational information) for the following
			interface types:
	o Ethernet LAN		o Ethernet LAN
	o Ethernet 802.1q		o Ethernet 802.1q
	o Ethernet 802.1ag (including Ethernet CFM)		o Ethernet 802.1ag (including Ethernet CFM)
	o Ethernet WAN		o Ethernet WAN
	o WLAN (802.11a/b/n/g/ac)		o WLAN (802.11a/b/n/g/ac)
	INT-3: The CPE YANG implementation MUST provide support for optical
			INT-3: The RG YANG implementation MUST provide support for optical
	parameter configuration for the Ethernet WAN interface YANG		parameter configuration for the Ethernet WAN interface YANG
	model.		model.
			INT-4 The RG YANG implementation MUST provide a model for the
			management of hardware.
	3.1.2. Development Status of Relevant YANG Models		3.2.2. Development Status of Relevant YANG Models
	Existing RFCs:		Existing RFCs:
	o YANG Data Model for Interface Management [RFC7223].		o YANG Data Model for Interface Management [RFC7223].
	o IANA Interface Type YANG Module [RFC7224].		o IANA Interface Type YANG Module [RFC7224].
	Work In Progress:		Work In Progress:
	o IEEE 802.1q YANG Model [IEEE-ETH-YANG]		o IEEE 802.1q YANG Model [IEEE-ETH-YANG]
	o Common Interface Extension YANG Data Models:
	[I-D.wilton-netmod-intf-ext-yang].
	o Interface VLAN YANG Data Models:		o Interface VLAN YANG Data Models:
	[I-D.wilton-netmod-intf-vlan-yang].		[I-D.ietf-netmod-sub-intf-vlan-model].
			o Common Interface Extension YANG Data Models:
			[I-D.ietf-netmod-intf-ext-yang]
			o YANG Model for the PPP Protocol:
			[I-D.han-netmod-intf-ext-ppp-yang]
			o A YANG Data Model for Hardware Management:
			[I-D.han-netmod-intf-ext-ppp-yang]
	To Be Defined:		To Be Defined (and SDOs that might be responsible for the standards)
	o Ethernet WAN		o Ethernet WAN (IEEE/BBF)
	o Ethernet 802.1ag		o Ethernet 802.1ag (IEEE)
	o Ethernet LAN		o Ethernet LAN (IEEE/BBF)
	o WLAN (802.11a/b/n/g/ac)		o WLAN (802.11a/b/n/g/ac) (IEEE/WFA/BBF)
	3.2. IP Management		3.3. IP Management
	3.2.1. Requirements		3.3.1. Requirements
	The following requirements are necessary for the management and		The following requirements are necessary for the management and
	configuration of IPv4 and IPv6.		configuration of IPv4 and IPv6.
	IP-1: The CPE YANG implementation MUST enable the configuration and		IP-1: The RG YANG implementation MUST enable the configuration and
	management of IPv4 addresses and associated parameters on L3		management of IPv4 addresses and associated parameters on L3
	interfaces.		interfaces.
	IP-2: The CPE YANG implementation MUST enable the configuration and		IP-2: The RG YANG implementation MUST enable the configuration and
	management of IPv6 addresses and associated parameters on L3		management of IPv6 addresses and associated parameters on L3
	interfaces.		interfaces.
			IP-3 The RG YANG implementation MUST allow for the configuration of
			differentiated services [RFC2474] related parameters on its
			interfaces.
	3.2.2. Development of Relevant YANG Models		3.3.2. Development Status of Relevant YANG Models
	Existing RFCs:		Existing RFCs:
	o YANG Data Model for IP Management [RFC7277].		o YANG Data Model for IP Management [RFC7277].
	Work In Progress:		Work In Progress:
	o YANG Model for DiffServ: [I-D.asechoud-netmod-diffserv-model].		o YANG Model for DiffServ: [I-D.asechoud-netmod-diffserv-model].
	To Be Defined:		To Be Defined:
	o None		o None
	3.3. Routing and Multicast Management		3.4. Routing and Multicast Management
	3.3.1. Requirements		3.4.1. Requirements
	The following requirements are necessary for routing management.		The following requirements are necessary for routing management.
	ROUT-1: The CPE YANG implementation MUST provide support for the		ROUT-1: The RG YANG implementation MUST provide support for the
	configuration and management of relevant IPv4/IPv6 dynamic		configuration and management of relevant IPv4/IPv6 dynamic
	routing protocols (for instance the ones relevant to IETF		routing protocols (for instance the ones relevant to IETF
	HOMENET WG).		HOMENET WG).
	ROUT-2: The CPE YANG implementation MUST include YANG models for the		ROUT-2: The RG YANG implementation MUST include YANG models for the
	management of static IPv4/IPv6 routes.		management of static IPv4/IPv6 routes.
	ROUT-3: The CPE YANG implementation MUST provide support for the		ROUT-3: The RG YANG implementation MUST provide support for the
	management of Protocol Independent Multicast (PIM).		management of Protocol Independent Multicast (PIM).
	ROUT-4: The CPE YANG implementation MUST provide support for the		ROUT-4: The RG YANG implementation MUST provide support for the
	management of static multicast routes.		management of static multicast routes.
	3.3.2. Development of Relevant YANG Models		3.4.2. Development of Relevant YANG Models
	Existing RFCs:		Existing RFCs:
	o None		o None
	Work In Progress:		Work In Progress:
	o YANG Data Model for Routing Management:		o YANG Data Model for Routing Management: [RFC8022].
	[I-D.ietf-netmod-routing-cfg].		o YANG model for static IPv4/IPv6 route: Appendix B in [RFC8022].
	o YANG model for static IPv4/IPv6 route: Appendix B in
	[I-D.ietf-netmod-routing-cfg].
	o YANG Data Model for ISIS protocol: [I-D.ietf-isis-yang-isis-cfg].		o YANG Data Model for ISIS protocol: [I-D.ietf-isis-yang-isis-cfg].
	o YANG model for PIM: [I-D.mcallister-pim-yang].		o YANG model for PIM: [I-D.ietf-pim-yang].
	o YANG model for IGMP and MLD: [I-D.liu-pim-igmp-mld-yang].		o YANG model for IGMP and MLD: [I-D.ietf-pim-igmp-mld-yang].
	To Be Defined:		To Be Defined:
	o Static Multicast Route		o Static Multicast Route
	o What is the HOMENET relevant dynamic routing protocol.		o What is the HOMENET relevant dynamic routing protocol(s).
	3.4. CPE NETCONF Server Management		3.5. RG NETCONF Server Management
	3.4.1. Requirements		3.5.1. Requirements
	The following requirements are necessary for management of the CPE's		The following requirements are necessary for management of the RG's
	NETCONF Server.		NETCONF Server.
	NETCONF-1: The CPE YANG implementation MUST provide support for		NETCONF-1: The RG YANG implementation MUST provide support for
	management and configuration of its local NETCONF server		management and configuration of its local NETCONF server
	using the NETCONF protocol.		using the NETCONF protocol.
	NETCONF-2: The CPE YANG implementation MUST provide support for the		NETCONF-2: The RG YANG implementation MUST provide support for the
	base notification function in order to allow a NETCONF		base notification function in order to allow a NETCONF
	client to retrieve notifications for common system		client to retrieve notifications for common system
	events.		events.
	NETCONF-3: The CPE YANG implementation MUST be able to retrieve		NETCONF-3: The RG YANG implementation MUST be able to retrieve
	NETCONF server configuration automatically during the		NETCONF server configuration automatically during the
	bootstrap process (ZeroTouch).		bootstrap process (ZeroTouch).
	NETCONF-4: The CPE YANG implementation as a NETCONF server MUST		NETCONF-4: The RG YANG implementation as a NETCONF server MUST
	provide support for the Call Home function so that a		provide support for the Call Home function so that a
	secure connection to a NETCONF client can be initiated.		secure connection to a NETCONF client can be initiated.
	3.4.2. Development Status of Relevant YANG Models		3.5.2. Development Status of Relevant YANG Models
	Existing RFCs:		Existing RFCs:
	o YANG Module for NETCONF Monitoring: [RFC6022].		o YANG Module for NETCONF Monitoring: [RFC6022].
	o NETCONF Base Notifications: [RFC6470].		o NETCONF Base Notifications: [RFC6470].
	Work In Progress:		Work In Progress:
	o ZeroTouch: [I-D.ietf-netconf-zerotouch].		o ZeroTouch: [I-D.ietf-netconf-zerotouch].
	o NETCONF Call Home: [I-D.ietf-netconf-call-home].		o NETCONF Call Home: [RFC8071].
	o NETCONF Server Configuration Models:		o NETCONF Server Configuration Models:
	[I-D.ietf-netconf-server-model].		[I-D.ietf-netconf-netconf-client-server].
	To Be Defined:		To Be Defined:
	o None		o None
	3.5. DHCP/SLAAC/ND Management		3.6. DHCP/SLAAC/ND Management
	3.5.1. Requirements		3.6.1. Requirements
	The following requirements are necessary for management of DHCP,		The following requirements are necessary for management of DHCP,
	SLAAC and ND.		SLAAC and ND.
	V6CONF-1: The CPE YANG implementation MUST provide support for		V6CONF-1: The RG YANG implementation MUST provide support for
	management of its DHCPv4 server, which typically runs at		management of its DHCPv4 server, which typically runs at
	the IPv4 LAN side.		the IPv4 LAN side.
	V6CONF-2: The CPE YANG implementation MUST provide support for the		V6CONF-2: The RG YANG implementation MUST provide support for the
	management of its DHCPv6 server, which can run at the IPv6		management of its DHCPv6 server, which can run at the IPv6
	LAN side.		LAN side.
	V6CONF-3: The CPE YANG implementation MUST provide support for the		V6CONF-3: The RG YANG implementation MUST provide support for the
	management of its DHCPv6 client, which typically runs at		management of its DHCPv6 client, which typically runs at
	the IPv6 WAN side.		the IPv6 WAN side.
	V6CONF-4: The CPE YANG implementation MUST provide support for the		V6CONF-4: The RG YANG implementation MUST provide support for the
	management of its DHCPv6 Prefix Delegation configuration		management of its DHCPv6 Prefix Delegation configuration
	(as a requesting router).		(as a requesting router).
	V6CONF-5: The CPE YANG implementation MUST provide support for the		V6CONF-5: The RG YANG implementation MUST provide support for the
	management of SLAAC for stateless IPv6 configuration.		management of SLAAC for stateless IPv6 configuration (as
			router on its LAN interfaces).
	3.5.2. Development Status of Relevant YANG Models		3.6.2. Development Status of Relevant YANG Models
	Existing RFCs:		Existing RFCs:
	o None		o IPv6 Router Advertisements: [RFC8022]
	Work In Progress:		Work In Progress:
	o YANG models for DHCPv4: [I-D.liu-dhc-dhcp-yang-model].		o YANG Data Model for DHCPv4 Configuration:
			[I-D.liu-dhc-dhcp-yang-model].
	o YANG Data Model for DHCPv6 Configuration:		o YANG Data Model for DHCPv6 Configuration:
	[I-D.cui-dhc-dhcpv6-yang].		[I-D.ietf-dhc-dhcpv6-yang].
	To Be Defined:		To Be Defined:
	o YANG model for SLAAC (Router Advertisement)		o YANG model for SLAAC (Router Advertisement). (IETF)
	o YANG model for Neighbour Discovery Protocol (NDP)		o YANG model for Neighbour Discovery Protocol (NDP). (IETF)
	o YANG model for DHCPv6 Prefix Delegation (requesting router)		o YANG model for DHCPv6 Prefix Delegation (requesting router).
	o YANG model for IPCP.		(IETF)
	o YANG model for IPv6CP.		o YANG model for IPCP. (IETF)
			o YANG model for IPv6CP. (IETF)
	3.6. NAT Management		3.7. NAT Management
	3.6.1. Requirements		3.7.1. Requirements
	The following requirements are necessary for NAT Management.		The following requirements are necessary for NAT Management.
	NAT-1: The CPE YANG implementation MUST provide support for		NAT-1: The RG YANG implementation MUST provide support for
	management of NAT44 configuration, as well as NAPT44		management of NAT44 configuration, as well as NAPT44
	configuration.		configuration.
	3.6.2. Development Status of Relevant YANG Models		3.7.2. Development Status of Relevant YANG Models
	Existing RFCs:		Existing RFCs:
	o None		o None
	Work In Progress:		Work In Progress:
	o YANG Data Model for NAT44 and stateful NAT64 function		o YANG Data Model for NAT44 and stateful NAT64 function
	[I-D.sivakumar-yang-nat].		[I-D.sivakumar-yang-nat].
	To Be Defined:		To Be Defined:
	o None		o None
	3.7. IPv6 Transition Mechanisms Management		3.8. IPv6 Transition Mechanisms Management
	3.7.1. Requirements		3.8.1. Requirements
	The following requirements are necessary for management of IPv6		The following requirements are necessary for management of IPv6
	Transition Mechanisms.		Transition Mechanisms.
	TRAN-2: The CPE YANG implementation must include configuration and		TRAN-2: The RG YANG implementation must include configuration and
	management for 6rd [RFC5969].		management for 6rd [RFC5969].
	TRAN-2: The CPE YANG implementation must include configuration and		TRAN-2: The RG YANG implementation must include configuration and
	management for DS-Lite [RFC6333].		management for DS-Lite [RFC6333].
	TRAN-3: The CPE YANG implementation must include configuration and		TRAN-3: The RG YANG implementation must include configuration and
	management for Lightweight 4over6 [RFC7596].		management for Lightweight 4over6 [RFC7596].
	TRAN-4: The CPE YANG implementation must include configuration and		TRAN-4: The RG YANG implementation must include configuration and
	management for MAP-E [RFC7597].		management for MAP-E [RFC7597].
	TRAN-5: The CPE YANG implementation must include configuration and		TRAN-5: The RG YANG implementation must include configuration and
	management for MAP-T [RFC7599].		management for MAP-T [RFC7599].
	3.7.2. Development of Relevant YANG Models		3.8.2. Development of Relevant YANG Models
	Existing RFCs:		Existing RFCs:
	o None		o None
	Work In Progress:		Work In Progress:
	o YANG model for IPv4-in-IPv6 Softwire: [I-D.sun-softwire-yang].		o YANG model for IPv4-in-IPv6 Softwire: [I-D.ietf-softwire-yang].
	o YANG Data Model for the DS-Lite Address Family Transition Router		o YANG Data Model for the DS-Lite Address Family Transition Router
	(AFTR): [I-D.boucadair-softwire-dslite-yang].		(AFTR): [I-D.ietf-softwire-dslite-yang].
	To Be Defined:		To Be Defined:
	o YANG model for 6rd.		o YANG model for 6rd. (IETF)
	o DHCP 4o6 client: May be combined in DHCPv6 YANG model as a		o DHCP 4o6 client: May be combined in DHCPv6 YANG model as a
	feature.		feature. (IETF)
	o DNS64		o DNS64. (IETF)
	o Stateless NAT64 (required for MAP-T and 464xlat).		o Stateless NAT64 (required for MAP-T and 464xlat). (IETF)
	3.8. Management of Specific Services		3.9. Management of Specific Services
	3.8.1. Requirements		3.9.1. Requirements
	The following requirements are necessary for management of specific		The following requirements are necessary for management of specific
	services which the CPE may offer.		services which the RG may offer.
	SERVICE-1: The CPE YANG implementation MUST provide support for the		SERVICE-1: The RG YANG implementation MUST provide support for the
	management of a SIP client.		management of a SIP client.
	SERVICE-2: The CPE YANG implementation MUST provide support for the		SERVICE-2: The RG YANG implementation MUST provide support for the
	management of a the CPEs Web server (used to provide a		management of a the RG Web server (used to provide a
	local management interface).		local management interface).
	SERVICE-3: The CPE YANG implementation MUST provide support for the		SERVICE-3: The RG YANG implementation MUST provide support for the
	management of an NTP client and server.		management of an NTP client and server.
	SERVICE-4: The CPE YANG implementation MUST provide support for the		SERVICE-4: The RG YANG implementation MUST provide support for the
	management of the SSH server.		management of the SSH server.
	3.8.2. Development of Relevant YANG Models		3.9.2. Development of Relevant YANG Models
	Existing RFCs:		Existing RFCs:
	o NTP Client: [RFC7317]		o NTP Client: [RFC7317]
	Work In Progress:		Work In Progress:
	o None		o None
	To Be Defined:		To Be Defined:
	o SIP Client		o SIP/VoIP Client. (IETF)
	o Web server, used by the customer for configuring their CPE device.		o Web server, used by the customer for configuring their RG. (?)
	o NTP server		o NTP server. (IETF)
	o SSH server		o SSH server. (IETF)
	3.9. Management of Security Components		3.10. Management of Security Components
	3.9.1. Requirements		3.10.1. Requirements
	The following requirements are necessary for management of security		The following requirements are necessary for management of security
	components.		components.
	SEC-1: The CPE YANG implementation MUST provide support for the		SEC-1: The RG YANG implementation MUST provide support for the
	management of IPv4 firewall and ACL functions.		management of IPv4 firewall and ACL functions.
	SEC-1: The CPE YANG implementation MUST provide support for the
			SEC-1: The RG YANG implementation MUST provide support for the
	management of IPv6 firewall and ACL functions.		management of IPv6 firewall and ACL functions.
	3.9.2. Development of Relevant YANG Models		3.10.2. Development of Relevant YANG Models
	Existing RFCs:		Existing RFCs:
	o None		o None
	Work In Progress:		Work In Progress:
	o IPv4 Firewall configuration: [I-D.ietf-netmod-acl-model]		o IPv4 Firewall configuration: [I-D.ietf-netmod-acl-model]
	o IPv6 Firewall configuration: [I-D.ietf-netmod-acl-model]		o IPv6 Firewall configuration: [I-D.ietf-netmod-acl-model]
	o Access Control List (ACL): [I-D.ietf-netmod-acl-model]		o Access Control List (ACL): [I-D.ietf-netmod-acl-model]
	To Be Defined:		To Be Defined:
	o IPv4/v6 Firewall (if needed in addition to the above)		o IPv4/v6 Firewall (if needed in addition to the above) (IETF?)
	o Parental controls		o Parental controls (?)
	3.10. Remote CPE Software Upgrade		3.11. Remote RG Software Upgrade
	3.10.1. Requirements		3.11.1. Requirements
	The following requirements are necessary to perform remote CPE		The following requirements are necessary to perform remote RG
	Software file transfer and software upgrades.		Software file transfer and software upgrades.
	SWUPG-1: The CPE implementation must provide a YANG model for the		SWUPG-1: The RG implementation must provide a YANG model for the
	upgrade of firmware and software packages in order to fix		upgrade of firmware and software packages in order to fix
	bugs, enable new features, and resolve security issues.		bugs, enable new features, and resolve security issues.
	SWUPG-2: The CPE YANG implementation MUST enable RPCs for file		SWUPG-2: The RG YANG implementation MUST enable RPCs for file
	transfer in order to retrieve files from an operator-		transfer in order to retrieve files from an operator-
	managed data centre, or upload logging.		managed data centre, or upload logging.
	3.10.2. Development of Relevant YANG Models		3.11.2. Development of Relevant YANG Models
	Existing RFCs:		Existing RFCs:
	o None		o None
	Work In Progress:		Work In Progress:
	o File transfer: [I-D.sf-netmod-file-transfer-yang]		o File transfer: [I-D.sf-netmod-file-transfer-yang]
	To Be Defined:		To Be Defined:
	o YANG model for firmware upgrade RPCs		o YANG model for firmware upgrade RPCs. (BBF?)
	4. Security Considerations		4. Security Considerations
	A NETCONF/YANG managed CPE should follow the Section 3.9 for enabling		A NETCONF/YANG managed RG should follow the Section 3.10 for enabling
	and managing IPv4/IPv6 firewalls. Security considerations from the		and managing IPv4/IPv6 firewalls. Security considerations from the
	related documents should be followed.		related documents should be followed.
	5. IANA Considerations		5. IANA Considerations
	There are no IANA considerations for this document.		There are no IANA considerations for this document.
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank xxx for their contributions to this		The authors would like to thank xxx for their contributions to this
	skipping to change at page 11, line 43 ¶		skipping to change at page 12, line 29 ¶
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.asechoud-netmod-diffserv-model]		[I-D.asechoud-netmod-diffserv-model]
	Choudhary, A., Shah, S., Jethanandani, M., Liu, B., and N.		Choudhary, A., Shah, S., Jethanandani, M., Liu, B., and N.
	Strahle, "YANG Model for Diffserv", draft-asechoud-netmod-		Strahle, "YANG Model for Diffserv", draft-asechoud-netmod-
	diffserv-model-03 (work in progress), June 2015.		diffserv-model-03 (work in progress), June 2015.
	[I-D.boucadair-softwire-dslite-yang]		[I-D.han-netmod-intf-ext-ppp-yang]
	Boucadair, M., Jacquenet, C., and S. Sivakumar, "YANG Data		Han, H., Gu, X., Lv, H., and J. Zhang, "Yang Data Model
	Model for the DS-Lite Address Family Transition Router		for PPP Protocol", draft-han-netmod-intf-ext-ppp-yang-02
	(AFTR)", draft-boucadair-softwire-dslite-yang-02 (work in		(work in progress), February 2017.
	progress), September 2015.
	[I-D.cui-dhc-dhcpv6-yang]		[I-D.ietf-dhc-dhcpv6-yang]
	Cui, Y., Wang, H., Sun, L., Lemon, T., and I. Farrer,		Cui, Y., Wang, H., Sun, L., Lemon, T., Farrer, I., and S.
	"YANG Data Model for DHCPv6 Configuration", draft-cui-dhc-		Zoric, "YANG Data Model for DHCPv6 Configuration", draft-
	dhcpv6-yang-04 (work in progress), September 2015.		ietf-dhc-dhcpv6-yang-03 (work in progress), June 2016.
	[I-D.ietf-isis-yang-isis-cfg]		[I-D.ietf-isis-yang-isis-cfg]
	Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L.		Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L.
	Lhotka, "YANG Data Model for ISIS protocol", draft-ietf-		Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf-
	isis-yang-isis-cfg-06 (work in progress), September 2015.		isis-yang-isis-cfg-15 (work in progress), February 2017.
	[I-D.ietf-netconf-call-home]		[I-D.ietf-netconf-call-home]
	Watsen, K., "NETCONF Call Home and RESTCONF Call Home",		Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
	draft-ietf-netconf-call-home-11 (work in progress),		draft-ietf-netconf-call-home-17 (work in progress),
	September 2015.		December 2015.
			[I-D.ietf-netconf-netconf-client-server]
			Watsen, K., Wu, G., and J. Schoenwaelder, "NETCONF Client
			and Server Models", draft-ietf-netconf-netconf-client-
			server-01 (work in progress), November 2016.
	[I-D.ietf-netconf-server-model]		[I-D.ietf-netconf-server-model]
	Watsen, K. and J. Schoenwaelder, "NETCONF Server and		Watsen, K. and J. Schoenwaelder, "NETCONF Server and
	RESTCONF Server Configuration Models", draft-ietf-netconf-		RESTCONF Server Configuration Models", draft-ietf-netconf-
	server-model-08 (work in progress), October 2015.		server-model-09 (work in progress), March 2016.
	[I-D.ietf-netconf-zerotouch]		[I-D.ietf-netconf-zerotouch]
	Watsen, K., Clarke, J., and M. Abrahamsson, "Zero Touch		Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning
	Provisioning for NETCONF Call Home (ZeroTouch)", draft-		for NETCONF or RESTCONF based Management", draft-ietf-
	ietf-netconf-zerotouch-03 (work in progress), July 2015.		netconf-zerotouch-12 (work in progress), January 2017.
	[I-D.ietf-netmod-acl-model]		[I-D.ietf-netmod-acl-model]
	Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair,		Bogdanovic, D., Koushik, K., Huang, L., and D. Blair,
	"Network Access Control List (ACL) YANG Data Model",		"Network Access Control List (ACL) YANG Data Model",
	draft-ietf-netmod-acl-model-03 (work in progress), June		draft-ietf-netmod-acl-model-10 (work in progress), March
	2015.		2017.
	[I-D.ietf-netmod-routing-cfg]		[I-D.ietf-netmod-intf-ext-yang]
	Lhotka, L. and A. Lindem, "A YANG Data Model for Routing		Wilton, R., Ball, D., tsingh@juniper.net, t., and S.
	Management", draft-ietf-netmod-routing-cfg-19 (work in		Sivaraj, "Common Interface Extension YANG Data Models",
	progress), May 2015.		draft-ietf-netmod-intf-ext-yang-04 (work in progress),
			March 2017.
	[I-D.liu-dhc-dhcp-yang-model]		[I-D.ietf-netmod-sub-intf-vlan-model]
	Liu, B. and K. Lou, "A YANG Data Model for DHCP		Wilton, R., Ball, D., tapsingh@cisco.com, t., and S.
	Configuration", draft-liu-dhc-dhcp-yang-model-01 (work in		Sivaraj, "Sub-interface VLAN YANG Data Models", draft-
	progress), July 2015.		ietf-netmod-sub-intf-vlan-model-00 (work in progress),
			February 2017.
	[I-D.liu-pim-igmp-mld-yang]		[I-D.ietf-pim-igmp-mld-yang]
	Liu, Y. and F. Guo, "Yang Model for Internet Group		Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A.
	Management Protocol (IGMP) and Multicast Listener		Peter, "A YANG data model for Internet Group Management
	Discovery (MLD)", draft-liu-pim-igmp-mld-yang-01 (work in		Protocol (IGMP) and Multicast Listener Discovery (MLD)",
	progress), March 2015.		draft-ietf-pim-igmp-mld-yang-03 (work in progress), March
			2017.
	[I-D.mcallister-pim-yang]		[I-D.ietf-pim-yang]
	Liu, X., McAllister, P., and A. Peter, "A YANG data model		Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu,
	for Protocol-Independent Multicast (PIM)", draft-		Y., and f. hu, "A YANG data model for Protocol-Independent
	mcallister-pim-yang-00 (work in progress), July 2015.		Multicast (PIM)", draft-ietf-pim-yang-07 (work in
			progress), March 2017.
	[I-D.perrault-behave-natv2-mib]		[I-D.ietf-softwire-dslite-yang]
	Perreault, S., Tsou, T., Sivakumar, S., and T. Taylor,		Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG
	"Definitions of Managed Objects for Network Address		Data Model for the DS-Lite", draft-ietf-softwire-dslite-
	Translators (NAT)", draft-perrault-behave-natv2-mib-05		yang-02 (work in progress), January 2017.
	(work in progress), June 2015.
			[I-D.ietf-softwire-yang]
			Sun, Q., Wang, H., Cui, Y., Farrer, I., Zoric, S.,
			Boucadair, M., and R. Asati, "A YANG Data Model for IPv4-
			in-IPv6 Softwires", draft-ietf-softwire-yang-01 (work in
			progress), October 2016.
			[I-D.liu-dhc-dhcp-yang-model]
			Liu, B., Lou, K., and C. Chen, "Yang Data Model for DHCP
			Protocol", draft-liu-dhc-dhcp-yang-model-06 (work in
			progress), March 2017.
	[I-D.sf-netmod-file-transfer-yang]		[I-D.sf-netmod-file-transfer-yang]
	Sun, Q. and I. Farrer, "A YANG Data Model for Transferring		Sun, Q. and I. Farrer, "A YANG Data Model for Transferring
	Files", draft-sf-netmod-file-transfer-yang-00 (work in		Files", draft-sf-netmod-file-transfer-yang-00 (work in
	progress), March 2015.		progress), March 2015.
	[I-D.sivakumar-yang-nat]		[I-D.sivakumar-yang-nat]
	Sivakumar, S., Boucadair, M., and S. <>, "YANG Data Model		Sivakumar, S., Boucadair, M., and S. <>, "YANG Data Model
	for Network Address Translation (NAT)", draft-sivakumar-		for Network Address Translation (NAT)", draft-sivakumar-
	yang-nat-03 (work in progress), September 2015.		yang-nat-05 (work in progress), September 2016.
	[I-D.sun-softwire-yang]
	Sun, Q., Wang, H., Cui, Y., Farrer, I., Boucadair, M., and
	R. Asati, "YANG Data Model for IPv4-in-IPv6 Softwire",
	draft-sun-softwire-yang-04 (work in progress), October
	2015.
	[I-D.wilton-netmod-intf-ext-yang]
	Wilton, R., Ball, D., Singh, T., and S. Sivaraj, "Common
	Interface Extension YANG Data Models", draft-wilton-
	netmod-intf-ext-yang-00 (work in progress), July 2015.
	[I-D.wilton-netmod-intf-vlan-yang]
	Wilton, R., Ball, D., Singh, T., and S. Sivaraj,
	"Interface VLAN YANG Data Models", draft-wilton-netmod-
	intf-vlan-yang-00 (work in progress), July 2015.
	[IEEE-ETH-YANG]		[IEEE-ETH-YANG]
	"IEEE 802.1q YANG Model",		"IEEE 802.1q YANG Model",
	<http://www.ieee802.org/1/files/public/docs2015/>.		<http://www.ieee802.org/1/files/public/docs2015/>.
	[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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
			[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
			the Network Configuration Protocol (NETCONF)", RFC 6020,
			DOI 10.17487/RFC6020, October 2010,
			<http://www.rfc-editor.org/info/rfc6020>.
	[RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF		[RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF
	Monitoring", RFC 6022, DOI 10.17487/RFC6022, October 2010,		Monitoring", RFC 6022, DOI 10.17487/RFC6022, October 2010,
	<http://www.rfc-editor.org/info/rfc6022>.		<http://www.rfc-editor.org/info/rfc6022>.
			[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
			and A. Bierman, Ed., "Network Configuration Protocol
			(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
			<http://www.rfc-editor.org/info/rfc6241>.
	[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF)		[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF)
	Base Notifications", RFC 6470, DOI 10.17487/RFC6470,		Base Notifications", RFC 6470, DOI 10.17487/RFC6470,
	February 2012, <http://www.rfc-editor.org/info/rfc6470>.		February 2012, <http://www.rfc-editor.org/info/rfc6470>.
	[RFC7223] Bjorklund, M., "A YANG Data Model for Interface		[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
	Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,		Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
	<http://www.rfc-editor.org/info/rfc7223>.		<http://www.rfc-editor.org/info/rfc7223>.
	[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC		[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
	7224, DOI 10.17487/RFC7224, May 2014,		RFC 7224, DOI 10.17487/RFC7224, May 2014,
	<http://www.rfc-editor.org/info/rfc7224>.		<http://www.rfc-editor.org/info/rfc7224>.
	[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC		[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
	7277, DOI 10.17487/RFC7277, June 2014,		RFC 7277, DOI 10.17487/RFC7277, June 2014,
	<http://www.rfc-editor.org/info/rfc7277>.		<http://www.rfc-editor.org/info/rfc7277>.
	[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for		[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
	System Management", RFC 7317, DOI 10.17487/RFC7317, August		System Management", RFC 7317, DOI 10.17487/RFC7317, August
	2014, <http://www.rfc-editor.org/info/rfc7317>.		2014, <http://www.rfc-editor.org/info/rfc7317>.
			[RFC7659] Perreault, S., Tsou, T., Sivakumar, S., and T. Taylor,
			"Definitions of Managed Objects for Network Address
			Translators (NATs)", RFC 7659, DOI 10.17487/RFC7659,
			October 2015, <http://www.rfc-editor.org/info/rfc7659>.
			[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
			Management", RFC 8022, DOI 10.17487/RFC8022, November
			2016, <http://www.rfc-editor.org/info/rfc8022>.
			[RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
			RFC 8071, DOI 10.17487/RFC8071, February 2017,
			<http://www.rfc-editor.org/info/rfc8071>.
	7.2. Informative References		7.2. Informative References
			[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
			"Definition of the Differentiated Services Field (DS
			Field) in the IPv4 and IPv6 Headers", RFC 2474,
			DOI 10.17487/RFC2474, December 1998,
			<http://www.rfc-editor.org/info/rfc2474>.
	[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4		[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
	Infrastructures (6rd) -- Protocol Specification", RFC		Infrastructures (6rd) -- Protocol Specification",
	5969, DOI 10.17487/RFC5969, August 2010,		RFC 5969, DOI 10.17487/RFC5969, August 2010,
	<http://www.rfc-editor.org/info/rfc5969>.		<http://www.rfc-editor.org/info/rfc5969>.
	[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-		[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
	Stack Lite Broadband Deployments Following IPv4		Stack Lite Broadband Deployments Following IPv4
	Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,		Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
	<http://www.rfc-editor.org/info/rfc6333>.		<http://www.rfc-editor.org/info/rfc6333>.
	[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic		[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
	Requirements for IPv6 Customer Edge Routers", RFC 7084,		Requirements for IPv6 Customer Edge Routers", RFC 7084,
	DOI 10.17487/RFC7084, November 2013,		DOI 10.17487/RFC7084, November 2013,
	<http://www.rfc-editor.org/info/rfc7084>.		<http://www.rfc-editor.org/info/rfc7084>.
	[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.		[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
	Farrer, "Lightweight 4over6: An Extension to the Dual-		Farrer, "Lightweight 4over6: An Extension to the Dual-
	Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,		Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
	July 2015, <http://www.rfc-editor.org/info/rfc7596>.		July 2015, <http://www.rfc-editor.org/info/rfc7596>.
	[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,		[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
	Murakami, T., and T. Taylor, Ed., "Mapping of Address and		Murakami, T., and T. Taylor, Ed., "Mapping of Address and
	Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/		Port with Encapsulation (MAP-E)", RFC 7597,
	RFC7597, July 2015,		DOI 10.17487/RFC7597, July 2015,
	<http://www.rfc-editor.org/info/rfc7597>.		<http://www.rfc-editor.org/info/rfc7597>.
	[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,		[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
	and T. Murakami, "Mapping of Address and Port using		and T. Murakami, "Mapping of Address and Port using
	Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July		Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
	2015, <http://www.rfc-editor.org/info/rfc7599>.		2015, <http://www.rfc-editor.org/info/rfc7599>.
	Authors' Addresses		Authors' Addresses
	Ian Farrer		Ian Farrer
	skipping to change at page 15, line 25 ¶		skipping to change at page 16, line 46 ¶
	Qi Sun		Qi Sun
	Deutsche Telekom AG		Deutsche Telekom AG
	CTO-ATI, Landgrabenweg 151		CTO-ATI, Landgrabenweg 151
	Bonn, NRW 53227		Bonn, NRW 53227
	Germany		Germany
	Email: sunqi.ietf@gmail.com		Email: sunqi.ietf@gmail.com
	Sladjana Zoric		Sladjana Zoric
	Deutsche Telekom AG		Deutsche Telekom AG
	CTO-IPT, Landgrabenweg 151		CTO-ATI, Landgrabenweg 151
	Bonn, NRW 53227		Bonn, NRW 53227
	Germany		Germany
	Email: sladjana.zoric@telekom.de		Email: sladjana.zoric@telekom.de
	Mikael Abrahamsson		Mikael Abrahamsson
	T-Systems		T-Systems
	Email: mikael.abrahamsson@t-systems.se		Email: mikael.abrahamsson@t-systems.se
End of changes. 136 change blocks.
	234 lines changed or deleted		302 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/