< draft-geng-homenet-mpvd-use-cases-01.txt		draft-geng-homenet-mpvd-use-cases-02.txt >
	Homenet Working Group L. Geng
			Homenet L. Geng
	Internet-Draft H. Deng		Internet-Draft H. Deng
	Intended status: Standards Track China Mobile		Intended status: Standards Track China Mobile
	Expires: January 4, 2016 July 3, 2015		Expires: April 18, 2016 October 16, 2015
	Use Cases for Multiple Provisioning Domain in Homenet		Use Cases for Multiple Provisioning Domain in Homenet
	draft-geng-homenet-mpvd-use-cases-01		draft-geng-homenet-mpvd-use-cases-02
	Abstract		Abstract
	This document describes the use cases of multiple provisioning domain		This document describes the use cases of multiple provisioning domain
	(MPVD) in homenet. Although most residential networks nowadays are		(MPVD) in homenet. Although most residential networks nowadays are
	connected to a single ISP and normally subscribed to standard		connected to a single ISP and normally subscribed to standard
	internet service, it is expected that much wider range of devices and		internet service, it is expected that much wider range of devices and
	services will become common in home networks. Homenet defines such		services will become common in home networks. Homenet defines such
	home network topologies with increasing number of devices with the		home network topologies with increasing number of devices with the
	assumption that it requires minimum configuration by residential		assumption that it requires minimum configuration by residential
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 47 ¶
	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 January 4, 2016.		This Internet-Draft will expire on April 18, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3		2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
	3. Homenet with Multiple PvDs . . . . . . . . . . . . . . . . . 3		3. Homenet with Multiple PvDs . . . . . . . . . . . . . . . . . 3
	3.1. PvD associating an interface in homenet . . . . . . . . . 4		4. Examples of MPvD Configurations in Home Network . . . . . . . 4
	3.2. PvD associating a service in homenet . . . . . . . . . . 4		4.1. Single CE Router Connected to Single ISP with interior
	3.3. PvD for hybrid purposes in home network . . . . . . . . . 5		router . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Examples of MPvD Configurations in Home Network . . . . . . . 5		4.2. Two CE Routers Connected to two ISPs with Shared Subnets 6
	4.1. Homenet Connected to a Single ISP . . . . . . . . . . . . 5		4.3. One CE Routers Connected to two ISPs with Shared Subnets 6
	4.2. Multihomed Homenet . . . . . . . . . . . . . . . . . . . 7		5. PvD-aware node in homenet . . . . . . . . . . . . . . . . . . 6
	5. PvD-aware node in homenet . . . . . . . . . . . . . . . . . . 8		6. IPv4 compatibility . . . . . . . . . . . . . . . . . . . . . 7
	6. Conveying PvD information . . . . . . . . . . . . . . . . . . 8		7. Conveying PvD information . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 9		10. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	10.1. Normative References . . . . . . . . . . . . . . . . . . 9		11.1. Normative References . . . . . . . . . . . . . . . . . . 8
	10.2. Informative References . . . . . . . . . . . . . . . . . 9		11.2. Informative References . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	It is believed that future residential network will more commonly be		It is believed that future residential network will more commonly be
	multihomed, which potentially provides either resilience or more		multihomed, which potentially provides either resilience or more
	flexible services. At the same time, more internal routing and		flexible services. At the same time, more internal routing and
	multiple subnets are expected to commonly exist in such networks.		multiple subnets are expected to commonly exist in such networks.
	For example, customer may want independent subnets for private and		For example, customer may want independent subnets for private and
	guest usages. Homenet describes such future home network involving		guest usages. Homenet describes such future home network involving
	multiple routers and subnets ([RFC7368]).		multiple routers and subnets ([RFC7368]).
	skipping to change at page 3, line 34 ¶		skipping to change at page 3, line 34 ¶
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Terminology and Abbreviations		2. Terminology and Abbreviations
	The terminology and abbreviations used in this document are defined		The terminology and abbreviations used in this document are defined
	in this section.		in this section.
	o ISP: Internet Service Provider. A traditional network operator		o ISP: Internet Service Provider. A traditional network operator
	who provides internet access to customers.		who provides internet access to customers.
	o VSP: Virtual Service Provider. An service provider who typically
	provides over-the-top services including but not limited to
	Internet of Things services (IoT).
	3. Homenet with Multiple PvDs		3. Homenet with Multiple PvDs
	In the most common multihoming scenarios, the home network has		In the most common multihoming scenarios, the home network has
	multiple physical connections to the ISP networks. Section 3.2.2.2		multiple physical connections to the ISP networks. Section 3.2.2.2
	and 3.2.2.3 in [RFC7368] give the topology examples of such homenet.		and 3.2.2.3 in [RFC7368] give the topology examples of such homenet.
	In the examples, homenet hosts are connected to a single or multiple		In the examples, homenet hosts are connected to a single or multiple
	customer edge routers (CE router), the CE routers are then connected		customer edge routers (CE router), the CE routers are then connected
	to separate ISP networks. For the particular topology with a single		to separate ISP networks. For the particular topology with a single
	CE router given in Section 3.2.2.3 in [RFC7368], the CE router is a		CE router given in Section 3.2.2.3 in [RFC7368], the CE router is a
	mif node since it has two interfaces connected to individual service		mif node since it has two interfaces connected to individual service
	provider routers. Given that the CE router is a PvD-aware node, it		provider routers. Given that the CE router is a PvD-aware node, it
	may have a single PvD as it is connected to only one ISP and an		may have two PvDs provided by ISPs respectively.
	additional PvD if connected to both.
	Apart from the multihoming resulted from physical connections to		Apart from the multihoming resulted from physical connections , PvDs
	different ISPs, the future residential network may also logically		in Homenet can also be used for service provisioning. For example, a
	connected to multiple Over-the-top service providers(i.e. IoT		host may subscribe one ISP for internet service, whilst subscribe to
	service providers), who do not directly provide internet access		another ISP for Internet of Things (IoT) service given that the CE
	service to customers. For example, one customer may subscribe to a		router have access to both ISPs. On the other hand, the host user
	traditional service ISP for basic internet service, whilst subscribe		may also subscribe to the same ISP for both services. In either
	to other providers for Internet of Things service. The latter are		case, PvDs can be used for customized network configurations
	likely to be VSPs as defined in Section 2 of this document, who are		purposes. This enables the service providers to provide independent
	not bounded to any of the ISPs providing basic access service for the		and flexible provisioning for different services. Meanwhile, IoT
	residential network. In this case, a particular VSP may also use		service providers may also want to use independent PvDs to avoid the
	PvDs for customized network configurations purposes. This enables		configuration conflicts between each other as stated in RFC6418.
	the VSPs to provide independent and flexible provisioning between on
	its subscriber's network for different services. Meanwhile, VSPs may
	also want to use independent PvDs to avoid the configuration
	conflicts between each other as stated in RFC6418.
	The following sections outline differenct types of PvD in homenet.		A typical example of a PvD in home network is the one associating
			corresponding network configuration with an HNCP routers. These
			includes both CE router and interior router in Homenet. As described
			in ([RFC7368]), an CE router in homenet may have one or more external
			interfaces with ISPs and internal interfaces with interior routers.
			For external interfaces, the CE router can receive associated PvD
			information from corresponding ISPs. For interior interfaces, the
			interior router can receive PvD information from connected CE router
			or other interior routers.
	3.1. PvD associating an interface in homenet		Hosts in homenet are expected to be multihomed as well. Hence, PvD
			may also be used in such cases to associate different network
			configurations. In this case, the PvD information is received from
			the HNCP router a host is attached to, either a CE router or a
			interior router.
	One typical example of a PvD in home network is the one associating		4. Examples of MPvD Configurations in Home Network
	an interface with network configuration. As described in
	([RFC7368]), a multihomed CE router in homnet connects with multiple
	ISPs. It may have several different uplink interfaces (i.e. PON and
	LTE). ISP can use PvDs to associate its network configurations with
	specific uplink interface the CE router provides to its subscriber.
	PvD information can be delivered by ISP through the corresponding
	uplink interface of the CE router.
	Another scenario is when the interior routers and hosts in homenet		This section gives some examples of MPvD configurations in home
	have multiple uplink interfaces(i.e. LAN, WIFI, Zigbee). Depending		network.
	on the actual network implementation, PvDs for these interfaces can
	be either configured by ISPs or VSPs. Since these devices connect
	with the internet through the CE router within homnnet, mechanism
	needs to be defined for PvD information delivery within homenet.
	3.2. PvD associating a service in homenet		4.1. Single CE Router Connected to Single ISP with interior router
			<----"Internet" PvD----------->
			_____
			+-------+ ( )
			+--------+ | | ( ISP ) +------+
			| PC +------+ +--------------------+ WWW |
			+--------+ | HNCP | ( ) +------+
			| CE | ( )
			+--------+ |Router | ( ) +------+
			| SETBOX +------+ +--------------------+ VOD |
			+--------+ | | ( ) +------+
			| | ( )
			| <----"VOD" PvD--------------->
			| | ( )
			<------------------"VPN" PvD ------------------------->
			+--------+ | | ( )
			| +----+ | +--------+ | | ( ) +------+
			| |VPN +---+ | | +--------------------+ VPN |
			| +----+ | |Interior| | | ( ) +------+
			| Host 3 | | HNCP +------+ | ( )
			| +----+ | | Router | | | ( __) +------+
			| |IoT +---+ | | +--------------------+ IoT |
			| +----+ | +--------+ +-------+ (__ ) +------+
			+--------+
			<------------------"IoT" PvD-------------------------->
	This type of PvD is useful in homenet when a provisioning domain is		Figure 1
	needed for a specific service that a homenet user subscribe to.
	Unlike the PvD associating an interface in homenet, this PvD
	associates the network configuration with a service. The service can
	be provided by any ISP or VSP that is available to the user.
	In homenet, ISPs and VSPs can use this PvD for service-specific		In this example, A homenet is connected with a single ISP as seen in
	provisioning in CE routers, interior routers and hosts. Service		Figure 1. Four different services are provided to this home network
	providers could decide the number of PvDs they offer depending on the		including Internet, VOD, VPN and IoT. There are 3 Hosts in this set-
	services a user subscribes to. This enables complete dependency		up. PC and setbox use "Internet" and "VoD" PvDs respectively and
	between the provisioning of different services provided by either		Host 3 uses both "VPN" and "IoT" PvD.
	same or different sources.
	A good example of a device in homenet that may use such PvD is a IoT		The four PVDs could be either implicit or explicit PvDs. Explicit
	box provided by VSP. This box may be connected to a CE router as an		PvDs should be initially assigned to HNCP CE router by ISP. And then
	interior router as demonstrated in section 3.2.2.1 of [RFC7368], or		forwarded to interior routers and host. Given that all PvDs are
	integrated with the CE router or the host in some circumstances.		explicit in the case above, the "Internet" PvD is forwarded to PC and
			"VOD" PvD to SETBOX by the CE router, and the "VPN" and "IoT" PvDs
			are forwarded to interior HNCP router and then Host 3. The PvD_ID
			should be kept the same when the PvDs are forwarded. However, other
			associated network configuration (i.e. delegated prefixes) should be
			changed accordingly.
	Since some services may need provisioning domain in multiple devices		4.2. Two CE Routers Connected to two ISPs with Shared Subnets
	in homenet(i.e. Both IoT service gateway and host need to be
	provisioned), PvDs associated with the same service in different
	devices should ideally be managed by a single provider. Hence,
	necessary collaboration can be taken care of by the VSP/ISP.
	3.3. PvD for hybrid purposes in home network		To be added
	The coexistence of multiple interfaces and services is possible when		4.3. One CE Routers Connected to two ISPs with Shared Subnets
	a device in homenet is both multihomed with more than one ISPs and
	subscribed to multiple services. Assuming that a service provider
	has access to the interface of the device on which its service is
	provided, a provisioning domain associating both the service and
	corresponding interface can be used for a simpler set-up. For
	example, instead of separately maintaining a WIFI interface PvD and
	an IoT service PvD, an VSP can merge the information of these to PvD
	and only use a single PvD for hybrid provisioning. It is always
	preferred that PvD for hybrid provisioning is used when possible,
	since it offers better network configuration flexibility for service
	provider and enables seamless coordination between interface and the
	service runs on it.
	4. Examples of MPvD Configurations in Home Network		To be added
	This section gives some examples of MPvD configurations in home		5. PvD-aware node in homenet
	network.
	4.1. Homenet Connected to a Single ISP		As defined in MIF, "PvD-aware node is a a node that supports the
	<----"Internet" PvD of ISP---->		association of network configuration information into PvDs and the
	_____		use of these PvDs to serve requests for network connections". In
	+--------+ +-------+ ( )		Homenet, the HNCP CE router, interior router and host are all PvD-
	|Internet+---+ + +------( ISP )		aware nodes.
	+--------+ | | | ( )
	<------"IoT1" PvD of VSP1-------------->
	+--------+ | | | ( ) +------+
	| IoT1 +---|--+ | ( )------+ VSP1 |
	+--------+ | | | ( ) +------+
	<------"IoT2" PvD of VSP2-------------->
	+--------+ | | | ( ) +------+
	| IoT2 +---+ + | ( )---+ VSP2 |
	+--------+ | | ( ) +------+
	<------------"IoT3" PvD of VSP3------------------>
	+----+ +--------+ | HNCP | ( ) +------+
	|IoT3+-+ + | | Home | ( ) | |
	+----+ | |Interior| |Gateway| ( ) | |
	|-+ HNCP +------+ | ( )------+ VSP3 |
	+----+ | | Router | | | ( __) | |
	|IoT4+-+ + | | | (___ ) | |
	+----+ +--------+ +-------+ (__ ) +------+
	<------------"IoT4" PvD of VSP3------------------>		The HNCP CE router PvD-related functionality is define as follows:
	Figure 1		o Generates implicit PvDs for different uplink interfaces.
	A homenet home gateway (CE router) is singlehomed with a single ISP		o Requests and receives all explicit PvDs provided by the connected
	as seen in Figure 1. In this scenario, basic internet service is		ISPs.
	provided by this ISP, IoT services are provided by 3 different VSPs.
	Multiple PvDs are created for the CE router for the purpose of
	service provisioning. The home gateway, connected with multiple
	service providers, receives basic internet PvD information from the
	connected ISP, IoT1 PvD information from VSP1 and IoT2 PvD
	information from VSP2.
	Additionally, an HNCP-enabled interior router is connected to the		o Generates explicit PvDs for interior routers and hosts referring
	home gateway and provides another 2 IoT services from VSP3 to the		to the ISP-provided PvDs and forwards them accordingly.
	user. VSP3 may create 2 PvDs associating IoT3 and IoT4 respectively
	for the interior router, subject to the user's subscription.
	In this example, ISP provides basic internet service through a		o Creates and stores the PvD mapping between the PvD applied itself
	homenet home gateway and VSPs provides multiple IoT services through		the the one forwarded to interior routers and hosts using the
	both the HNCP home gateway and the interior HNCP router. Since none		assigned PvD_ID and prefix.
	of the gateway devices are multihomed, all of the PvDs associate
	corresponding network configuration with a specific service. The PvD
	information is delivered by ISP and VSPs through the corresponding
	singlehomed interface.
	4.2. Multihomed Homenet		o Identify the prefix received from homenet nodes and performs PvD
			selection based on PvD mapping.
	<--------"Internet1" PvD of ISP1--------->		The interior router PvD-related functionality is defined as follows:
	<-"LTE" PvD of ISP1---->
	_____
	+---------+ +-------+ ( )
	|Internet1+------+ +-LTE--( ) +-----+
	+---------+ | | ( ) | |
	| | ( ISP1 )--+ |
	<----------"IoT1" PvD of VSP--------------> | |
	| | ( _) | |
	+----+ +--------+ | | ( ____) | |
	|IoT1+-+ + | | | | |
	+----+ | |Interior| | HNCP | | |
	|-+ HNCP +---+ Home | | VSP |
	+----+ | | Router | |Gateway| | |
	|IoT2+-+ + | | | _____ | |
	+----+ +--------+ | | ( ) | |
	| | __( ) | |
	<----------"IoT2" PvD of VSP--------------> | |
	| | ( ISP2 )--+ |
	+---------+ | | ( __) | |
	|Internet2+------+ +-PON-( _) +-----+
	+---------+ +-------+ ( ____)
	<-"PON" PvD of ISP2---->		o Generates implicit PvDs for different homenet internal interface.
	<--------"Internet2" PvD of ISP2--------->
	Figure 2		o Requests and receives all explicit PvDs provided by connected
			homenet routers.
	Figure 2 illustrates an example of multihomed HNCP home gateway. In		o Generates explicit PvDs for interior routers and hosts referring
	this example, two ISPs are connected with the HNCP home gateway and		to the homenet-router-provided PvDs and forwards them accordingly.
	both provide internet services. The interfaces used by the HNCP home
	gateway for these 2 ISPs are LTE and PON, which are provisioned
	within the LTE PvD of ISP1 and PON PvD of ISP2. Another 2 PvD for
	individual internet service are also created by ISP1 and ISP2
	respectively. In principle, it is preferred in this example that the
	2 PvDs of the same ISP should be merged as one hybrid PvD, which
	associates the complete set of network configuration with both the
	internet service and the corresponding uplink interface.
	The interior HNCP router in this example are similiar to the one in		o Creates and stores the PvD mapping between the PvD applied itself
	the previous example, providing 2 IoT services provisioned separately		the the one forwarded to interior routers and hosts using the
	by VSP. However, it is worth mentioning that the IoT1 and IoT2 PvDs		assigned PvD_ID and prefix.
	information is not necessarily delivered from a fixed ISP because of
	the nature of multihomed gateway. It is upto the VSP to make the
	decision according to the available network resources.
	Although not shown in Figure 2, the HNCP home gateway may also		o Identify the prefix received from homenet nodes and performs PvD
	directly provide IoT service from VSP. Since VSP is normally homed		selection based on PvD mapping.
	with multiple ISPs, the multihomed HNCP home gateway may receive PvD
	information from different ISPs for the IoT service. PvD
	configuration conflicts need to be avoided in this case.
	5. PvD-aware node in homenet		The host PvD-related functionality is defined as follows:
	PvD-aware node is the device where the provisioning domains and		o Generates implicit PvDs for different interfaces between host and
	associated network configuration are set up. In the examples given		homenet routers.
	in Section 4, the HNCP home gateways and Interior HNCP routers are
	all PvD-aware nodes. The HNCP home gateway receives MPvD identity
	and associated network configuration from the network and forward the
	MPvD information belonging to interior routers. It is worth
	mentioning that a PvD-aware node may also be a host in homenet,which
	is not shown in the given examples. For instance, a mobile device
	connected with the interior router may have MPvDs for it's Wifi and
	cellular interfaces, or for multiple services it subscribed to.
	As introduced in RFC7556, typical information a PvD-aware node		o Requests and receives all explicit PvDs provided by connected
	learned from network by a provisioning domain including source		homenet routers.
	address prefixes for use by the connected hosts within the PvD,IP
	address(es) of the DNS server(s) and default gateway address. While
	these information is maintained in the PvD-aware node, it needs to
	assign prefixes to the connected hosts within homenet using homenet-
	defined approaches.
	6. Conveying PvD information		6. IPv4 compatibility
	The PvD associated with an VSP service may be directly provided by		PvD in homenet can be either single-family or dual-stack. For
	VSP using application layer approach, or provided by the the ISPs in		single-family PvD, the IPV4 and IPV6 configurations should be managed
	which the VSP is homed if there are collaboration between ISPs and		in separate PvDs with different PvD identities. For Dual-stack PvDs,
	VSPs.		IPV4 and IPV6 configurations can exist in the same PvD. In both
			cases, there can either be only one IPV4 PvD for each interface or
			multiple IPV4 PvDs with different default gateway addresses.
			7. Conveying PvD information
	At the time this document was written, the conveying of PvD		At the time this document was written, the conveying of PvD
	information was still under discussion in mif working group. Popular		information was still under discussion in mif working group. Popular
	choices include DHCP and Route Advertisement. For PvD information		choices include DNS, DHCP and Route Advertisement. For PvD
	provided from ISPs and VSPs to the CE routers, the approaches for PvD		information provided from ISP to CE router and router to host, the
	information delivery defined by mif may be directly used. For PvD		approaches for PvD information delivery defined by mif may be
	information delivery within homenet between HNCP-enabled routers and		directly used. For PvD information delivery within homenet between
	hosts, HNCP-related approach need to be concerned. The detail of how		HNCP-enabled routers, HNCP-based approach need to be defined. The
	homenet could support the delivery of PvD information is subjected to		detail of how homenet could support the delivery of PvD information
	further discussions and will be addressed in a separate document.		between routers is subjected to further discussions and will be
			addressed in a separate document.
	7. Acknowledgements		8. Acknowledgements
	The author would like to thank Ted Lemon for valuable initial		The author would like to thank Ted Lemon, Mark Townsley, Markus
	discussions of this document.		Stenberg and Steven Barth for valuable discussions and contributions
			to this document.
	8. IANA Considerations		9. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	9. Security Considerations		10. Security Considerations
	TBA		TBA
	10. References		11. References
	10.1. Normative References		11.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, DOI 10.17487/
			RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,		[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI
	June 1999.		10.17487/RFC2629, June 1999,
			<http://www.rfc-editor.org/info/rfc2629>.
	10.2. Informative References		11.2. Informative References
	[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and		[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
	Provisioning Domains Problem Statement", RFC 6418,		Provisioning Domains Problem Statement", RFC 6418, DOI
	November 2011.		10.17487/RFC6418, November 2011,
			<http://www.rfc-editor.org/info/rfc6418>.
	[RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,		[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
	"IPv6 Home Networking Architecture Principles", RFC 7368,		Weil, "IPv6 Home Networking Architecture Principles", RFC
	October 2014.		7368, DOI 10.17487/RFC7368, October 2014,
			<http://www.rfc-editor.org/info/rfc7368>.
	Authors' Addresses		Authors' Addresses
	Liang Geng		Liang Geng
	China Mobile		China Mobile
	Email: gengliang@chinamobile.com		Email: gengliang@chinamobile.com
	Hui Deng		Hui Deng
	China Mobile		China Mobile
End of changes. 51 change blocks.
	230 lines changed or deleted		165 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/