draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt		draft-ietf-v6ops-unique-ipv6-prefix-per-host-11.txt
	v6ops J. Brzozowski		v6ops J. Brzozowski
	Internet-Draft Comcast Cable		Internet-Draft Comcast Cable
	Intended status: Best Current Practice G. Van De Velde		Intended status: Best Current Practice G. Van De Velde
	Expires: March 22, 2018 Nokia		Expires: April 1, 2018 Nokia
	September 18, 2017		September 28, 2017
	Unique IPv6 Prefix Per Host		Unique IPv6 Prefix Per Host
	draft-ietf-v6ops-unique-ipv6-prefix-per-host-10		draft-ietf-v6ops-unique-ipv6-prefix-per-host-11
	Abstract		Abstract
	This document outlines an approach utilising existing IPv6 protocols		This document outlines an approach utilising existing IPv6 protocols
	to allow hosts to be assigned a unique IPv6 prefix (instead of a		to allow hosts to be assigned a unique IPv6 prefix (instead of a
	unique IPv6 address from a shared IPv6 prefix). Benefits of unique		unique IPv6 address from a shared IPv6 prefix). Benefits of unique
	IPv6 prefix over a unique service provider IPv6 address include		IPv6 prefix over a unique service provider IPv6 address include
	improved host isolation and enhanced subscriber management on shared		improved host isolation and enhanced subscriber management on shared
	network segments.		network segments.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 March 22, 2018.		This Internet-Draft will expire on April 1, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 17 ¶		skipping to change at page 2, line 17 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Motivation and Scope of Applicability . . . . . . . . . . . . 3		2. Motivation and Scope of Applicability . . . . . . . . . . . . 3
	3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4		3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4
	4. IPv6 Unique Prefix Assignment . . . . . . . . . . . . . . . . 4		4. IPv6 Unique Prefix Assignment . . . . . . . . . . . . . . . . 4
	5. IPv6 Neighbor Discovery Best Practices . . . . . . . . . . . 6		5. IPv6 Neighbor Discovery Best Practices . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	9. Normative References . . . . . . . . . . . . . . . . . . . . 8		9. Normative References . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The concepts in this document are originally developed as part of a		The concepts in this document are originally developed as part of a
	large scale, production deployment of IPv6 support for a provider		large scale, production deployment of IPv6 support for a provider
	managed shared access network service.		managed shared access network service.
	A shared network service, is a service offering where a particular L2		A shared network service, is a service offering where a particular L2
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	mechanisms to be employed. The goal here is to ensure that the		mechanisms to be employed. The goal here is to ensure that the
	widest population of UE implementations can leverage the		widest population of UE implementations can leverage the
	availability of IPv6		availability of IPv6
	o Lay the technological foundation for future work related to the		o Lay the technological foundation for future work related to the
	use of IPv6 over shared media requiring optimized subscriber		use of IPv6 over shared media requiring optimized subscriber
	management		management
	o Two devices (subscriber/hosts), both attached to the same provider		o Two devices (subscriber/hosts), both attached to the same provider
	managed shared network should only be able to communicate through		managed shared network should only be able to communicate through
	the provider managed First Hop Router		the provider managed First Hop Router. Often service providers
			have legal requirements, or find it good practice, to provide
			isolation between the connected visitor devices to control
			potential abuse of the shared access network.
	o Provide guidelines regarding best common practices around IPv6		o Provide guidelines regarding best common practices around IPv6
	neighborship discovery RFC4861 [RFC4861] and IPv6 address managent		neighborship discovery RFC4861 [RFC4861] and IPv6 address
	settings between the First Hop router and directly connected		management settings between the First Hop router and directly
	hosts/subscribers.		connected hosts/subscribers.
	3. Design Principles		3. Design Principles
	The First Hop router discussed in this document is the L3-Edge router		The First Hop router discussed in this document is the L3-Edge router
	responsible for the communication with the devices (hosts and		responsible for the communication with the devices (hosts and
	subscribers) directly connected to a provider managed shared network,		subscribers) directly connected to a provider managed shared network,
	and to transport traffic between the directly connected devices and		and to transport traffic between the directly connected devices and
	between directly connected devices and remote devices.		between directly connected devices and remote devices.
	The work detailed in this document is focused on providing details		The work detailed in this document is focused on providing details
	skipping to change at page 5, line 45 ¶		skipping to change at page 5, line 48 ¶
	o A-flag = 1 (The subscriber can configure itself using SLAAC)		o A-flag = 1 (The subscriber can configure itself using SLAAC)
	o L-flag = 0 (the prefix is not an on-link prefix, which means that		o L-flag = 0 (the prefix is not an on-link prefix, which means that
	the subscriber will never assume destination addresses that match		the subscriber will never assume destination addresses that match
	the prefix are on-link and will always send packets to those		the prefix are on-link and will always send packets to those
	addresses to the appropriate gateway according to route selection		addresses to the appropriate gateway according to route selection
	rules.)		rules.)
	The use of a unique IPv6 prefix per subscriber adds an additional		The use of a unique IPv6 prefix per subscriber adds an additional
	level of protection and efficiency as it relates to how IPv6 Neighbor		level of protection and efficiency. The protection is driven because
	Discovery and Router Discovery processing. Since the UE has a unique		all external communication of a connected device is directed to the
	IPv6 prefix all traffic by default will be directed to the First Hop		first hop router as required by RFC4861 [RFC4861]. Best efficiency
	router. Further, the flag combinations documented above maximise the		is achieved because the recommended RA flags allow broadest support
	IPv6 configurations that are available by hosts including the use of		on connected devices to receive a valid IPv6 address (i.e. privacy
	privacy IPv6 addressing.		addresses RFC4941 [RFC4941] or SLAAC RFC4862 [RFC4862]).
	The architected result of designing the RA as documented above is		The architected result of designing the RA as documented above is
	that each subscriber gets its own unique IPv6 prefix. Each host can		that each subscriber gets its own unique IPv6 prefix. Each host can
	consequently use SLAAC or any other method of choice to select its		consequently use SLAAC or any other method of choice to select its
	/128 unique address. Either stateless DHCPv6 RFC3736 [RFC3736] or		/128 unique address. Either stateless DHCPv6 RFC3736 [RFC3736] or
	IPv6 Router Advertisement Options for DNS Configuration RFC8106		IPv6 Router Advertisement Options for DNS Configuration RFC8106
	[RFC8106] can be used to get the IPv6 address of the DNS server. If		[RFC8106] can be used to get the IPv6 address of the DNS server. If
	the subscriber desires to send anything external including other		the subscriber desires to send anything external including towards
	subscriber devices (assuming device to device communications is		other subscriber devices (assuming device to device communications is
	enabled and supported), then, due to the L-bit being unset, it SHOULD		enabled and supported), then, due to the L-bit being unset, then
	send this traffic to the First Hop Router.		RFC4861 [RFC4861] requires that this traffic is sent to the First Hop
			Router.
	After the subscriber received the RA, and the associated flags, it		After the subscriber received the RA, and the associated flags, it
	will assign itself a 128 bit IPv6 address using SLAAC. Since the		will assign itself a 128 bit IPv6 address using SLAAC. Since the
	address is composed by the subscriber device itself, it will need to		address is composed by the subscriber device itself, it will need to
	verify that the address is unique on the shared network. The		verify that the address is unique on the shared network. The
	subscriber will for that purpose, perform Duplicate Address Detection		subscriber will for that purpose, perform Duplicate Address Detection
	algorithm. This will occur for each address the UE attempts to		algorithm. This will occur for each address the UE attempts to
	utilize on the shared provider managed network.		utilize on the shared provider managed network.
	5. IPv6 Neighbor Discovery Best Practices		5. IPv6 Neighbor Discovery Best Practices
	skipping to change at page 6, line 43 ¶		skipping to change at page 6, line 46 ¶
	when a subscriber stops using addresses from a prefix and additional		when a subscriber stops using addresses from a prefix and additional
	procedures are required to help the First Hop Router to gain this		procedures are required to help the First Hop Router to gain this
	information. When using stateful DHCPv6 IA_NA for IPv6 subscriber		information. When using stateful DHCPv6 IA_NA for IPv6 subscriber
	address assignment, this uncertainty on the First Hop Router is not		address assignment, this uncertainty on the First Hop Router is not
	of impact due to the stateful nature of DHCPv6 IA_NA address		of impact due to the stateful nature of DHCPv6 IA_NA address
	assignment.		assignment.
	Following is a reference table of the key IPv6 router discovery and		Following is a reference table of the key IPv6 router discovery and
	neighbor discovery timers for provider managed shared networks:		neighbor discovery timers for provider managed shared networks:
	o Maximum IPv6 Router Advertisement Interval = 300s (or 600s when		o Maximum IPv6 Router Advertisement Interval = 300s (or when battery
	battery consumption is a concern according RFC7772 [RFC7772]).		consumption is a concern then a MinRtrAdvInterval of 514 seconds
			(1/7 of an hour) is better according RFC7772 [RFC7772]).
	o IPv6 Router LifeTime = 3600s		o IPv6 Router LifeTime = 3600s
	o Reachable time = 30s		o Reachable time = 30s
	o IPv6 Valid Lifetime = 3600s		o IPv6 Valid Lifetime = 3600s
	o IPv6 Preferred Lifetime = 1800s		o IPv6 Preferred Lifetime = 1800s
	o Retransmit timer = 0s		o Retransmit timer = 0s
	The stateless nature of the subscriber IPv6 SLAAC connectivity model		IPv6 SLAAC requires the router to maintain neighbor state, which
	introduces non-optimal resource consumption (i.e. memory, neighbor		implies costs in terms of memory, power, message exchanges, and
	state) on the First Hop Router. To reduce undesired resource		message processing. Stale entries can prove an unnecessary burden,
	consumption, such as in the case of WiFi hotspots, is to remove		especially on WiFi interfaces. It is RECOMMENDED that stale neighbor
	subscriber context as quickly as possible when a device or subscriber		state be removed quickly.
	becomes non-active. A possible solution is to use a subscriber or
	device inactivity timer, that after tracking a pre-defined (currently
	unspecified) number of minutes, deletes the subscriber context on the
	First Hop Router.
	When employing stateless IPv6 address assignment, a number of widely		When employing stateless IPv6 address assignment, a number of widely
	deployed operating systems will attempt to utilise RFC 4941 RFC4941		deployed operating systems will attempt to utilise RFC 4941 RFC4941
	[RFC4941] temporary 'private' addresses.		[RFC4941] temporary 'private' addresses.
	Similarly, when using this technology in a datacenter, the UE server		Similarly, when using this technology in a datacenter, the UE server
	may need to use several addresses from the same Unique IPv6 Prefix,		may need to use several addresses from the same Unique IPv6 Prefix,
	for example because is using multiple virtual hosts, containers, etc.		for example because is using multiple virtual hosts, containers, etc.
	in the bridged virtual switch. This can lead to the consequence that		in the bridged virtual switch. This can lead to the consequence that
	a UE has multiple /128 addresses from the same IPv6 prefix. The		a UE has multiple /128 addresses from the same IPv6 prefix. The
	First Hop Provider Router MUST be able to handle the presence and use		First Hop Provider Router MUST be able to handle the presence and use
	of multiple globally routable IPv6 addresses.		of multiple globally routable IPv6 addresses.
	For accounting purposes, the First Hop Provider Router must be able
	to send usage statistics per subscriber using Radius attributes.
	6. IANA Considerations		6. IANA Considerations
	No IANA considerations are defined at this time.		No IANA considerations are defined at this time.
	7. Security Considerations		7. Security Considerations
	The mechanics of IPv6 privacy extensions RFC4941 [RFC4941] is		The mechanics of IPv6 privacy extensions RFC4941 [RFC4941] is
	compatible with assignment of a unique IPv6 Prefix per Host.		compatible with assignment of a unique IPv6 Prefix per Host.
	However, when combining both IPv6 privacy extensions and a unique		However, when combining both IPv6 privacy extensions and a unique
	IPv6 Prefix per Host a reduced privacy experience for the subscriber		IPv6 Prefix per Host a reduced privacy experience for the subscriber
	skipping to change at page 8, line 10 ¶		skipping to change at page 8, line 5 ¶
	[RFC4941].		[RFC4941].
	No other additional security considerations are made in this		No other additional security considerations are made in this
	document.		document.
	8. Acknowledgements		8. Acknowledgements
	The authors would like to thank the following, in alphabetical order,		The authors would like to thank the following, in alphabetical order,
	for their contributions:		for their contributions:
	Ben Campbell, Brian Carpenter, Tim Chown, Lorenzo Colitti, Killian		Fred Baker, Ben Campbell, Brian Carpenter, Tim Chown, Lorenzo
	Desmedt, David Farmer, Brad Hilgenfeld, Wim Henderickx, Erik Kline,		Colitti, Killian Desmedt, David Farmer, Brad Hilgenfeld, Wim
	Suresh Krishnan, Warren Kumari, Thomas Lynn, Jordi Palet, Phil		Henderickx, Erik Kline, Suresh Krishnan, Warren Kumari, Thomas Lynn,
	Sanderson, Colleen Szymanik, Jinmei Tatuya, Eric Vyncke, Sanjay		Jordi Palet, Phil Sanderson, Colleen Szymanik, Jinmei Tatuya, Eric
	Wadhwa		Vyncke, Sanjay Wadhwa
	9. Normative References		9. 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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,		[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
	C., and M. Carney, "Dynamic Host Configuration Protocol		C., and M. Carney, "Dynamic Host Configuration Protocol
End of changes. 14 change blocks.
	39 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/