< draft-bhandari-dhc-class-based-prefix-00.txt		draft-bhandari-dhc-class-based-prefix-01.txt >
	Internet Engineering Task Force S. Bhandari		Internet Engineering Task Force S. Bhandari
	Internet-Draft G. Halwasia		Internet-Draft G. Halwasia
	Intended status: Standards Track S. Bandi		Intended status: Standards Track S. Bandi
	Expires: April 23, 2012 S. Gundavelli		Expires: September 13, 2012 S. Gundavelli
	Cisco Systems		Cisco Systems
	H. Deng		H. Deng
	China Mobile		China Mobile
	October 21, 2011		March 12, 2012
	DHCPv6 class based prefix		DHCPv6 class based prefix
	draft-bhandari-dhc-class-based-prefix-00		draft-bhandari-dhc-class-based-prefix-01
	Abstract		Abstract
	DHCPv6 defines class based allocation of IA_NA and IA_TA IPv6		DHCPv6 defines class based allocation of IA_NA and IA_TA IPv6
	addresses. This document extends DHCPv6 prefix delegation with class		addresses. This document extends DHCPv6 prefix delegation with class
	based prefix allocation. It defines a new prefix class option to		based prefix allocation. It defines a new prefix class option to
	classify a prefix. It defines the behavior of a DHCPv6 client		classify a prefix. It defines the behavior of a DHCPv6 client
	requesting a prefix to include the class of the prefix to be		requesting a prefix to include the class of the prefix to be
	allocated and the DHCPv6 server behavior to select and offer a prefix		allocated and the DHCPv6 server behavior to select and offer a prefix
	from a given class. It discusses how IA_NA can be requested and		from a given class. It discusses how IA_NA can be requested and
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 23, 2012.		This Internet-Draft will expire on September 13, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1.1. Mobile network . . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1.2. Homenet . . . . . . . . . . . . . . . . . . . . . . . 4		1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5		2.1. Prefix Class Option in IA_PD . . . . . . . . . . . . . . . 4
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.2. Consideration for different DHCPv6 entities . . . . . . . 5
	2.1. Prefix Class Option in IA_PD . . . . . . . . . . . . . . . 6		2.2.1. Requesting Router Behavior . . . . . . . . . . . . . . 5
	2.2. Consideration for different DHCPv6 entities . . . . . . . 6		2.2.2. Delegating Router Behavior . . . . . . . . . . . . . . 6
	2.2.1. Requesting Router Behavior . . . . . . . . . . . . . . 7		2.2.3. DHCPv6 Client Behavior for IA_NA allocation . . . . . 7
	2.2.2. Delegating Router Behavior . . . . . . . . . . . . . . 7		2.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.2.3. DHCPv6 Client Behavior for IA_NA allocation . . . . . 8		2.3.1. Class based prefix and IA_NA allocation . . . . . . . 7
	2.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8		2.3.2. Class based prefix and IA_PD allocation . . . . . . . 8
	2.3.1. Class based prefix and IA_NA allocation . . . . . . . 8		2.3.3. Class based prefix and SLAAC . . . . . . . . . . . . . 8
	2.3.2. Class based prefix and IA_PD allocation . . . . . . . 9		3. Example Application . . . . . . . . . . . . . . . . . . . . . 8
	2.3.3. Class based prefix and SLAAC . . . . . . . . . . . . . 9		3.1. Class based prefix delegation . . . . . . . . . . . . . . 11
	3. Example Application . . . . . . . . . . . . . . . . . . . . . 9
	3.1. Class based prefix delegation . . . . . . . . . . . . . . 10
	3.2. IPv6 address assignment from class based prefix . . . . . 11		3.2. IPv6 address assignment from class based prefix . . . . . 11
	3.3. IPv6 prefix delegation from class based prefix . . . . . . 12
	4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. Change History (to be removed prior to publication as an
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 12		RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.2. Informative References . . . . . . . . . . . . . . . . . . 13		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
			8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
			8.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	DHCPv6 based prefix delegation as defined in [RFC3633] is a mechanism		DHCPv6 based prefix delegation as defined in [RFC3633] is a mechanism
	for the delegation of IPv6 prefixes using DHCPv6 options. Through		for the delegation of IPv6 prefixes using DHCPv6 options. Through
	these options, a delegating router can delegate prefixes to		these options, a delegating router can delegate prefixes to
	authorized requesting routers. If the requesting router has to		authorized requesting routers. If the requesting router has to
	function as a DHCPv6 server there needs to be additional information		function as a DHCPv6 server there needs to be additional information
	in the delegated prefix that helps the requesting router to select		in the delegated prefix that helps the requesting router to select
	skipping to change at page 3, line 32 ¶		skipping to change at page 3, line 32 ¶
	OPTION_PREFIX_CLASS option in IA_PD option for the purpose of		OPTION_PREFIX_CLASS option in IA_PD option for the purpose of
	selecting a prefix for further delegation either via IA_NA or IA_PD		selecting a prefix for further delegation either via IA_NA or IA_PD
	DHCPv6 request. It defines the behavior of the DHCPv6 server, the		DHCPv6 request. It defines the behavior of the DHCPv6 server, the
	DHCPv6 prefix requesting router and the DHCPv6 client to use this		DHCPv6 prefix requesting router and the DHCPv6 client to use this
	option.		option.
	1.1. Motivation		1.1. Motivation
	In this section motivation for class based prefix delegation that		In this section motivation for class based prefix delegation that
	qualifies the delegated prefix with additional class information is		qualifies the delegated prefix with additional class information is
	described in the context of mobile networks and homenet. The class		described in the context of mobile networks. The class information
	information attached to a delegated prefix helps to distinguish		attached to a delegated prefix helps to distinguish property of a
	property of a delegated IPv6 prefix and selection of the prefix by		delegated IPv6 prefix and selection of the prefix by different
	different applications using it.		applications using it.
	1.1.1. Mobile network
	In the mobile network architecture, there is a mobile router which		In the mobile network architecture, there is a mobile router which
	functions as a IP network gateway and provides IP connectivity to		functions as a IP network gateway and provides IP connectivity to
	mobile nodes. Mobile router can be the requesting router requesting		mobile nodes. Mobile router can be the requesting router requesting
	delegated IPv6 prefix using DHCPv6. Mobile router can assume the		delegated IPv6 prefix using DHCPv6. Mobile router can assume the
	role of DHCPv6 server for mobile nodes(DHCPv6 clients) attached to		role of DHCPv6 server for mobile nodes(DHCPv6 clients) attached to
	it. A mobile node in mobile network architecture can be associated		it. A mobile node in mobile network architecture can be associated
	with multiple IPv6 prefixes beloging to different domains for e.g.		with multiple IPv6 prefixes belonging to different domains for e.g.
	home address prefix, care of address prefix as specified in		home address prefix, care of address prefix as specified in
	[RFC3775]. The delegated prefixes when seen from the mobile router		[RFC3775].
	perspective appear to be like any other prefix, but each prefixes
	have different properties. Some delegated prefixes may be
	topologically local and some may be remote prefixes anchored on a
	global anchor, but available to the local anchor by means of
	tunneling setup in the network between the local and global anchor.
	Some may be local with low latency characteristics suitable for voice
	call break-out, some may have global mobility support. So, the
	prefixes have different properties and it is required for the
	application using the prefix to learn about this property in order to
	use it intelligently. There is currently no semantics in DHCPv6
	prefix delegation that can carry this information to specify
	properties of a delegated prefix. In this scenario, the mobile
	router is unable to further delegate a longer prefix intelligently
	based on properties of the prefix learnt.
	1.1.2. Homenet
	With the introduction of IPv6 and possible absence of Network Address
	Translation(NAT) in home networks, the IPv6 source address of the
	hosts can be used as a parameter for route decision and providing
	differentiated service for different classes of devices within a home
	network. [I-D.baker-fun-routing-class] and
	[I-D.baker-fun-multi-router] introduce use-cases and requirements for
	source based routing. The home network architecture and associated
	requirements are specified in [I-D.chown-homenet-arch]. To support
	source based routing it is necessary to have a mechanism to assign
	the source address or prefix based on parameters that identify the
	class of device or network.
	[RFC3315] defines OPTION_USER_CLASS option in the IA_NA/IA_TA
	assignment, which influences the address allocated based on the user
	class of the device requesting IA_NA or IA_TA. A typical deployment
	in a home network is the Customer Premise Equipment (CPE) to be a
	DHCPv6 client requesting a prefix as defined in [RFC3633] from
	upstream the DHCPv6 server and playing the role of a DHCPv6 server
	for devices in the Local Area Network (LAN). The CPE can get a
	shorter prefix from a DHCPv6 server in Wide Area Network(WAN) and
	allocate longer prefixes to its DHCPv6 clients. Today the CPE has to
	be manually configured to associate a prefix acquired from the WAN to
	devices in the LAN. A means of classifying and associating an
	acquired prefix via DHCPv6 for further delegation either via IA_NA/
	IA_TA or IA_PD requests is missing.
	For e.g. as shown in Figure 1 the CPE in a home network may request
	prefixes from the DHCPv6 server of the service provider and assume
	the role of a DHCPv6 server for devices within the home network.
	Residential and Small-Office/Home-Office (SOHO) networks may have
	separate domains for their "data network" and "home video network".
	Devices in these different domains are to be assigned addresses from
	different prefix ranges. The CPE router will need a way to assign
	prefixes to the home video network from a prefix that is meant for
	home video devices to provide differentiated service for such devices
	in the provider network that has source address based routing policy
	configured.
	Simple home network with Data and Video devices
	+-------+-------+ \
	| Service | \
	| Provider | | Service
	| Router | | Provider
	+-------+-------+ | network
	| /
	| Customer /
	| Internet connection (WAN) /
	| /
	|DHCPv6 Client \
	+------+--------+ \
	| IPv6 | \
	| Customer Edge | \
	| Router (CPE) | /
	+------+--------+ /
	|DHCPv6 Server | End-User
	Local Network | | network(s)
	---+-----+-------+--- \
	| | \
	+----+-----+ +-----+----+ \
	|IPv6 Host | |IPv6 Host | /
	| (video | | (PC) | /
	| device) | | | /
	+----------+ +----------+
	Figure 1		The delegated prefixes when seen from the mobile router perspective
			appear to be like any other prefix, but each prefixes have different
			properties referred to as "Prefix Color" in the mobile networks.
			Some delegated prefixes may be topologically local and some may be
			remote prefixes anchored on a global anchor, but available to the
			local anchor by means of tunnel setup in the network between the
			local and global anchor. Some may be local with low latency
			characteristics suitable for voice call break-out, some may have
			global mobility support. So, the prefixes have different properties
			and it is required for the application using the prefix to learn
			about this property in order to use it intelligently. There is
			currently no semantics in DHCPv6 prefix delegation that can carry
			this information to specify properties of a delegated prefix. In
			this scenario, the mobile router is unable to further delegate a
			longer prefix intelligently based on properties of the prefix learnt.
	1.2. Terminology		1.2. Terminology
	This document uses the terminology defined in [RFC2460], [RFC3315]		This document uses the terminology defined in [RFC2460], [RFC3315]
	and [RFC3633].		and [RFC3633].
	1.3. Requirements Language		1.3. 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
	skipping to change at page 9, line 35 ¶		skipping to change at page 8, line 32 ¶
	2.3.3. Class based prefix and SLAAC		2.3.3. Class based prefix and SLAAC
	DHCPv6 IA_NA and IPv6 Stateless Address Autoconfiguration (SLAAC as		DHCPv6 IA_NA and IPv6 Stateless Address Autoconfiguration (SLAAC as
	defined in [RFC4862]) are two ways by IPv6 addresses can be		defined in [RFC4862]) are two ways by IPv6 addresses can be
	dynamically assigned to end hosts. Making SLAAC class aware is		dynamically assigned to end hosts. Making SLAAC class aware is
	outside the scope of this document.		outside the scope of this document.
	3. Example Application		3. Example Application
	The following sub-sections provide examples of class based prefix		The following sub-sections provide examples of class based prefix
	delegation and how it is used in a home network. Each of the		delegation and how it is used in a mobile network. Each of the
	examples will refer to the below network:		examples will refer to the below network:
	The example network consists of an IPv6 video endpoint, IPv6 hosts,		The example network consists of :
	and a Smart grid network consisting of IPv6 sensors and a router that
	supports Smart Grid Energy Services Interface (ESI) to which sensors
	are connected. The customer edge router acts as a home gateway
	router for all the devices and networks within the home.
	Example home network		Mobile Gateway It is network entity anchoring IP traffic in the
			mobile core network. This entity allocates an IP address which is
			topologically valid in the mobile network and may act as a mobility
			anchor if handover between mobile and Wi-Fi is supported.
	+-------+-------+ \		Mobile Nodes (MN) A host or router that changes its point of
	| Service | \		attachment from one network or subnetwork to another. A mobile node
	| Provider | | Service		may change its location without changing its IP address; it may
	| Router | | Provider		continue to communicate with other Internet nodes at any location
	+-------+-------+ | network		using its (constant) IP address, assuming link-layer connectivity to
	| /		a point of attachment is available.
	| Customer /
	| Internet connection
	|
	+------+--------+ \
	| IPv6 | Network D (guest) \
	| Customer Edge +------------+ \
	| Router(CPE) | | |
	+----+-+---+--+-+ | |
	Network A | | |Network B | |
	+----+ | | | |
	| | +---+ | |
	+-----+----+ | +----+-----+ +-----+----+ |
	|IPv6 Video| | | IPv6 Host| |IPv6 Host | |
	|endpoint | | | A | | B | |
	+-----+----+ | +----------+ +----------+ |
	| |
	| |
	| |
	+------+--------+ | End-User
	| IPv6 | | networks
	| Smart grid + |
	| Router | |
	+--------+------+ |
	Network C | |
	+----+-------------+---+ |
	| | |
	+----+-----+ +-----+----+ |
	| IPv6 | | IPv6 | |
	| Sensor | | Sensor | /
	+----------+ +-----+----+ /
	Figure 2		Access Point (AP) A wireless access point, identified by a MAC
			address, providing service to the wired network for wireless nodes.
			Access Router (AR) An IP router residing in an access network and
			connected to one or more Acess Point(AP)s. An AR offers IP
			connectivity to MNs.
			WLAN controller (WLC) The entity that provides the centralized
			forwarding, routing function for the user traffic.
			Example mobile network
			_----_ _----_ _----_
			_( )_ _( )_ _( )_
			(Operator-1) (Operator-2) (Operator-3)
			(_ _) (_ _) (_ _)
			-+-- -+-- '-+--'
			+--------+ +--------+ +--------+
			| Mobile | | Mobile | | Mobile |
			|gateway | |gateway | |gateway |
			+--------+ +--------+ +--------+
			| | |
			+-------------. | .-------------+
			| | |
			| | |
			| | |P1:"global-anchor"
			| | |
			+--------+ _----_
			+---+ | |P2:"local-breakout"_( )_
			|AAA|. . . . . . . | Access |------------------( Internet )
			+---+ | Aggreg |-----------+ (_ _)
			| Gateway| P3:"guest"| '----'
			+--------+ |
			| | +----- Guest Access
			| | Network
			| +-------------+
			| |
			| +-----+
			| | AR |
			+-----+ +-----+
			| WLC | * ---------*
			| | ( LAN )
			+-----+ * ---------*
			/ \ / \
			+----+ +----+ +----+ +----+
			|WiFi| |WiFi| |WiFi| |WiFi|
			| AP | | AP | | AP | | AP |
			+----+ +----+ +----+ +----+
			. .
			/ \ / \
			MN1 MN2 MN3 MN4(guest)
			Figure 1
	3.1. Class based prefix delegation		3.1. Class based prefix delegation
	The Service Provider Router is preconfigured to provide prefixes from		The Access Aggregation Gateway requests for Prefix delegation from
	the following classes: "video", "default", "guest", and "smart-grid".		Mobile gateway and associates the prefix received with prefix class
	It has a preconfigured policy to advertise prefixes to requesting		"global-anchor". The Access Aggregation Gateway is preconfigured to
	routers based on the services supported by the service provider for a		provide prefixes from the following classes: "global-anchor", "local-
	given home. In the example home network, the CPE requests class		breakout", "guest". It has a preconfigured policy to advertise
			prefixes to requesting routers and mobile nodes based on the service
			class supported by the service provider for the requesting device.
			In the example mobile network, the Access Router(AR) requests class
	based prefix allocation by sending a DHCPv6 SOLICIT message and		based prefix allocation by sending a DHCPv6 SOLICIT message and
	include OPTION_PREFIX_CLASS in the OPTION_ORO.		include OPTION_PREFIX_CLASS in the OPTION_ORO.
	The CPE receives an advertise with following prefixes in the IA_PD		The Access Router (AR) receives an advertise with following prefixes
	option :		in the IA_PD option:
	1. IA_PD Prefix option with a prefix 3001::1::/64 containing
	OPTION_PREFIX_CLASS set to "video"
	2. IA_PD Prefix option with a prefix 3001::2::/64 containing		1. P1: IA_PD Prefix option with a prefix 3001::1::/64 containing
	OPTION_PREFIX_CLASS set to "guest"		OPTION_PREFIX_CLASS set to "global-anchor"
	3. IA_PD Prefix option with a prefix 3001::3::/64 containing		2. P2: IA_PD Prefix option with a prefix 3001::2::/64 containing
	OPTION_PREFIX_CLASS set to "smart-grid"		OPTION_PREFIX_CLASS set to "local-breakout"
	4. IA_PD Prefix option with a prefix 3001::4::/64 containing		3. P3: IA_PD Prefix option with a prefix 3001::3::/64 containing
	OPTION_PREFIX_CLASS set to "default"		OPTION_PREFIX_CLASS set to "guest"
	It sends a REQUEST message with all of above prefixes and receives a		It sends a REQUEST message with all of above prefixes and receives a
	REPLY message.		REPLY message with prefixes allocated for each of the requested
			class.
	3.2. IPv6 address assignment from class based prefix		3.2. IPv6 address assignment from class based prefix
	The video endpoint in Network A inFigure 2 sends a DHCPv6 SOLICIT		When the Access Router(AR) receives a DHCPv6 SOLICIT requesting IA_NA
	message requesting IA_NA address assignment with OPTION_USER_CLASS		from the mobile node that has mobility service enabled, it offers an
	option containing the value "video" towards the CPE. The CPE assumes		IPv6 address from the prefix class "global-anchor". For MN3 it
	the role of the DHCPv6 server and sends an ADVERTISE to the video		advertises 3001::1::1 as the IPv6 address in OPTION_IAADDR in
	endpoint with OPTION_IA_NA containing an IPv6 address in		response to the IA_NA request.
	OPTION_IAADDR from the "video" prefix class. The IPv6 address in the
	OPTION_IAADDR is set to 3001::1::1.
	When the CPE receives a DHCPv6 SOLICIT requesting IA_NA for the IPv6
	host from Network B, it offers an IPv6 address from the prefix class
	"default". For IPv6 host A it advertises 3001::4::1 as the IPv6
	address in OPTION_IAADDR in response to the IA_NA request.
	When the CPE receives a DHCPv6 SOLICIT requesting IA_NA for the IPv6
	host from Network D (guest network), it offers an IPv6 address from
	the prefix class "guest". For IPv6 host B it advertises 3001::2::1
	as the IPv6 address in OPTION_IAADDR in response to the IA_NA
	request. The Network D can be distinguished based on a preconfigured
	interface or SSID advertised by this CPE for guest hosts connecting
	to it.
	3.3. IPv6 prefix delegation from class based prefix		The Mobile Node(MN4) Figure 1 sends a DHCPv6 SOLICIT message
			requesting IA_NA address assignment with OPTION_USER_CLASS option
			containing the value "guest" towards the CPE. The Access Router(AR)
			assumes the role of the DHCPv6 server and sends an ADVERTISE to the
			MN with OPTION_IA_NA containing an IPv6 address in OPTION_IAADDR from
			the "guest" prefix class. The IPv6 address in the OPTION_IAADDR is
			set to 3001::3::1. The "guest" class can also be distinguished based
			on a preconfigured interface or SSID advertised for MNs connecting to
			it.
	The IPv6 Smart Grid router in Figure 2 sends a SOLICIT towards the		When the Access Aggregation Gateway receives a DHCPv6 SOLICIT
	CPE requesting prefix delegation in the "smart-grid" class by		requesting IA_NA from MNs through WLC and it has a preconfigured
	including the IA_PD option with the OPTION_PREFIX_CLASS containing		profile to provide both local-breakout internet access and global-
	"smart-grid". The CPE selects a longer prefix from "smart-grid"		anchor, it offers an IPv6 address from the prefix class "local-
	prefix previously obtained from Service Provider Router. It sends a		breakout" and "global-anchor". For MN1 it advertises 3001::2::1 and
	DHCPv6 ADVERTISE message with IA_PD option containing the IPv6 prefix		3001::1::2 as the IPv6 address in OPTION_IAADDR in response to the
	3001:: 3:1::/96 and OPTION_PREFIX_CLASS set to "smart-grid". The		IA_NA request. Applications within MN1 can choose to use the
	Smart Grid router MAY then advertise that prefix in IPv6 Router		appropriate prefix based on the mobility enabled or local-breakout
	Advertisement (RA) messages towards IPv6 sensors connected to it.		property.
	IPv6 sensors can do SLAAC (as defined in [RFC4862]) to configure IPv6
	address from the received RA message.
	4. Acknowledgements		4. Acknowledgements
	The authors would like to acknowledge review and guidance received		The authors would like to acknowledge review and guidance received
	from Frank Brockners, Wojciech Dec, Richard Johnson, Erik Nordmark,		from Frank Brockners, Wojciech Dec, Richard Johnson, Erik Nordmark,
	Hemant Singh, Mark Townsley, Ole Troan, Bernie Volz		Hemant Singh, Mark Townsley, Ole Troan, Bernie Volz
	5. IANA Considerations		5. IANA Considerations
	IANA is requested to assign an option code to OPTION_PREFIX_CLASS		IANA is requested to assign an option code to OPTION_PREFIX_CLASS
	from the "DHCPv6 and DHCPv6 options" registry (http://www.iana.org/		from the "DHCPv6 and DHCPv6 options" registry (http://www.iana.org/
	assignments/dhcpv6-parameters/dhcpv6-parameters.xml).		assignments/dhcpv6-parameters/dhcpv6-parameters.xml).
	6. Security Considerations		6. Security Considerations
	Security issues related to DHCPv6 which are described in section 23		Security issues related to DHCPv6 which are described in section 23
	of [RFC3315] and [RFC3633] apply for scenarios mentioned in this		of [RFC3315] and [RFC3633] apply for scenarios mentioned in this
	draft as well.		draft as well.
	7. References		7. Change History (to be removed prior to publication as an RFC)
	7.1. Normative References		Changes from -00 to -01
	[I-D.baker-fun-multi-router]		a. Modified motivation section to focus on mobile networks
	Baker, F., "Exploring the multi-router SOHO network",
	draft-baker-fun-multi-router-00 (work in progress),
	July 2011.
	[I-D.baker-fun-routing-class]		b. Modified example with a mobile network and class based prefix
	Baker, F., "Routing a Traffic Class",		delegation in it
	draft-baker-fun-routing-class-00 (work in progress),
	July 2011.
	[I-D.chown-homenet-arch]		8. References
	Arkko, J., Chown, T., Weil, J., and O. Troan, "Home
	Networking Architecture for IPv6",		8.1. Normative References
	draft-chown-homenet-arch-00 (work in progress),
	September 2011.
	[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.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, December 1998.		(IPv6) Specification", RFC 2460, December 1998.
	[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,		[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
	"Remote Authentication Dial In User Service (RADIUS)",		"Remote Authentication Dial In User Service (RADIUS)",
	RFC 2865, June 2000.		RFC 2865, June 2000.
	skipping to change at page 13, line 36 ¶		skipping to change at page 13, line 26 ¶
	[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic		[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
	Host Configuration Protocol (DHCP) version 6", RFC 3633,		Host Configuration Protocol (DHCP) version 6", RFC 3633,
	December 2003.		December 2003.
	[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support		[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
	in IPv6", RFC 3775, June 2004.		in IPv6", RFC 3775, June 2004.
	[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.
	7.2. Informative References		8.2. Informative References
	[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,		[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
	June 1999.		June 1999.
	[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC		[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Text on Security Considerations", BCP 72, RFC 3552,		Text on Security Considerations", BCP 72, RFC 3552,
	July 2003.		July 2003.
	Authors' Addresses		Authors' Addresses
	skipping to change at page 15, line 4 ¶		skipping to change at page 14, line 29 ¶
	Phone: +91 80 4426 2347		Phone: +91 80 4426 2347
	Email: sinb@cisco.com		Email: sinb@cisco.com
	Sri Gundavelli		Sri Gundavelli
	Cisco Systems		Cisco Systems
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: sgundave@cisco.com		Email: sgundave@cisco.com
	Hui Deng		Hui Deng
	China Mobile		China Mobile
	53A, Xibianmennei Ave., Xuanwu District		53A, Xibianmennei Ave., Xuanwu District
	Beijing 100053		Beijing 100053
	China		China
	Email: sinb@cisco.com		Email: denghui02@gmail.com
End of changes. 34 change blocks.
	224 lines changed or deleted		160 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/