< draft-ietf-intarea-shared-addressing-issues-04.txt		draft-ietf-intarea-shared-addressing-issues-05.txt >
	Internet Engineering Task Force M. Ford, Ed.		Internet Engineering Task Force M. Ford, Ed.
	Internet-Draft Internet Society		Internet-Draft Internet Society
	Intended status: Informational M. Boucadair		Intended status: Informational M. Boucadair
	Expires: August 26, 2011 France Telecom		Expires: September 4, 2011 France Telecom
	A. Durand		A. Durand
	Juniper Networks		Juniper Networks
	P. Levis		P. Levis
	France Telecom		France Telecom
	P. Roberts		P. Roberts
	Internet Society		Internet Society
	February 22, 2011		March 03, 2011
	Issues with IP Address Sharing		Issues with IP Address Sharing
	draft-ietf-intarea-shared-addressing-issues-04		draft-ietf-intarea-shared-addressing-issues-05
	Abstract		Abstract
	The completion of IPv4 address allocations from IANA and the RIRs is		The completion of IPv4 address allocations from IANA and the RIRs is
	causing service providers around the world to question how they will		causing service providers around the world to question how they will
	continue providing IPv4 connectivity service to their subscribers		continue providing IPv4 connectivity service to their subscribers
	when there are no longer sufficient IPv4 addresses to allocate them		when there are no longer sufficient IPv4 addresses to allocate them
	one per subscriber. Several possible solutions to this problem are		one per subscriber. Several possible solutions to this problem are
	now emerging based around the idea of shared IPv4 addressing. These		now emerging based around the idea of shared IPv4 addressing. These
	solutions give rise to a number of issues and this memo identifies		solutions give rise to a number of issues and this memo identifies
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 August 26, 2011.		This Internet-Draft will expire on September 4, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 5, line 28 ¶		skipping to change at page 5, line 28 ¶
	Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite], NAT64		Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite], NAT64
	[I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate],		[I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate],
	Address+Port (A+P) proposals [I-D.ymbk-aplusp],		Address+Port (A+P) proposals [I-D.ymbk-aplusp],
	[I-D.boucadair-port-range] and SAM [I-D.despres-sam]. Section 26		[I-D.boucadair-port-range] and SAM [I-D.despres-sam]. Section 26
	provides a classification of these different types of solutions and		provides a classification of these different types of solutions and
	discusses some of the design considerations to be borne in mind when		discusses some of the design considerations to be borne in mind when
	deploying large-scale address sharing. Whether we're talking about		deploying large-scale address sharing. Whether we're talking about
	DS-Lite, A+P, NAT64 or CGN isn't especially important - it's the view		DS-Lite, A+P, NAT64 or CGN isn't especially important - it's the view
	from the outside that matters, and given that, most of the issues		from the outside that matters, and given that, most of the issues
	identified below apply regardless of the specific address sharing		identified below apply regardless of the specific address sharing
	scenario in question. Issues specific to A+P proposals are addressed		scenario in question.
	in [I-D.thaler-port-restricted-ip-issues].
	In these new proposals, a single public IPv4 address would be shared		In these new proposals, a single public IPv4 address would be shared
	by multiple homes or small businesses (i.e., multiple subscribers) so		by multiple homes or small businesses (i.e., multiple subscribers) so
	the operational paradigm described above would no longer apply. In		the operational paradigm described above would no longer apply. In
	this document we refer to this new paradigm as large-scale address		this document we refer to this new paradigm as large-scale address
	sharing. All these proposals extend the address space by adding port		sharing. All these proposals extend the address space by adding port
	information, they differ in the way they manage the port value.		information, they differ in the way they manage the port value.
	Security issues associated with NAT have long been documented (see		Security issues associated with NAT have long been documented (see
	[RFC2663] and [RFC2993] ). However, sharing IPv4 addresses across		[RFC2663] and [RFC2993] ). However, sharing IPv4 addresses across
	skipping to change at page 22, line 18 ¶		skipping to change at page 22, line 18 ¶
	would be for a 6to4 IPv6 address to embed not only an IPv4 address		would be for a 6to4 IPv6 address to embed not only an IPv4 address
	but also a port range value.		but also a port range value.
	Subscribers allocated with private addresses will not be able to		Subscribers allocated with private addresses will not be able to
	utilize 6to4 [RFC3056] to access IPv6, but may be able to utilize		utilize 6to4 [RFC3056] to access IPv6, but may be able to utilize
	Teredo [RFC4380].		Teredo [RFC4380].
	Some routers enable 6to4 on their WAN link. 6to4 requires a publicly-		Some routers enable 6to4 on their WAN link. 6to4 requires a publicly-
	routable IPv4 address. Enabling 6to4 when the apparently public IPv4		routable IPv4 address. Enabling 6to4 when the apparently public IPv4
	WAN address is in fact behind a NAT creates a disconnected IPv6		WAN address is in fact behind a NAT creates a disconnected IPv6
	island. Issues created by assigning the same public address space		island.
	across multiple hosts are specifically addressed in
	[I-D.thaler-port-restricted-ip-issues].
	18. Introduction of Single Points of Failure		18. Introduction of Single Points of Failure
	In common with all deployments of new network functionality, the		In common with all deployments of new network functionality, the
	introduction of new nodes or functions to handle the multiplexing of		introduction of new nodes or functions to handle the multiplexing of
	multiple subscribers across shared IPv4 addresses could create single		multiple subscribers across shared IPv4 addresses could create single
	points of failure in the network. Any IP address sharing solution		points of failure in the network. Any IP address sharing solution
	should consider the opportunity to add redundancy features in order		should consider the opportunity to add redundancy features in order
	to alleviate the impact on the robustness of the offered IP		to alleviate the impact on the robustness of the offered IP
	connectivity service. The ability of the solution to allow hot		connectivity service. The ability of the solution to allow hot
	skipping to change at page 26, line 42 ¶		skipping to change at page 26, line 42 ¶
	[I-D.ietf-behave-v6v4-xlate-stateful]		[I-D.ietf-behave-v6v4-xlate-stateful]
	Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful		Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
	NAT64: Network Address and Protocol Translation from IPv6		NAT64: Network Address and Protocol Translation from IPv6
	Clients to IPv4 Servers",		Clients to IPv4 Servers",
	draft-ietf-behave-v6v4-xlate-stateful-12 (work in		draft-ietf-behave-v6v4-xlate-stateful-12 (work in
	progress), July 2010.		progress), July 2010.
	[I-D.ietf-pcp-base]		[I-D.ietf-pcp-base]
	Wing, D., Cheshire, S., Boucadair, M., Penno, R., and F.		Wing, D., Cheshire, S., Boucadair, M., Penno, R., and F.
	Dupont, "Port Control Protocol (PCP)",		Dupont, "Port Control Protocol (PCP)",
	draft-ietf-pcp-base-05 (work in progress), February 2011.		draft-ietf-pcp-base-06 (work in progress), February 2011.
	[I-D.ietf-softwire-dual-stack-lite]		[I-D.ietf-softwire-dual-stack-lite]
	Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-		Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
	Stack Lite Broadband Deployments Following IPv4		Stack Lite Broadband Deployments Following IPv4
	Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work		Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work
	in progress), August 2010.		in progress), August 2010.
	[I-D.shirasaki-nat444]		[I-D.shirasaki-nat444]
	Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,		Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
	and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work		and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work
	in progress), January 2011.		in progress), January 2011.
	[I-D.thaler-port-restricted-ip-issues]
	Thaler, D., "Issues With Port-Restricted IP Addresses",
	draft-thaler-port-restricted-ip-issues-00 (work in
	progress), February 2010.
	[I-D.ymbk-aplusp]		[I-D.ymbk-aplusp]
	Bush, R., "The A+P Approach to the IPv4 Address Shortage",		Bush, R., "The A+P Approach to the IPv4 Address Shortage",
	draft-ymbk-aplusp-09 (work in progress), February 2011.		draft-ymbk-aplusp-09 (work in progress), February 2011.
	[IANA_Ports]		[IANA_Ports]
	Geoff Huston, "IANA Port Number Assignments",		Geoff Huston, "IANA Port Number Assignments",
	February 2011,		February 2011,
	<http://www.iana.org/assignments/port-numbers>.		<http://www.iana.org/assignments/port-numbers>.
	[IPv4_Pool]		[IPv4_Pool]
	skipping to change at page 29, line 7 ¶		skipping to change at page 28, line 51 ¶
	[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,		[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
	"Internet Key Exchange Protocol Version 2 (IKEv2)",		"Internet Key Exchange Protocol Version 2 (IKEv2)",
	RFC 5996, September 2010.		RFC 5996, September 2010.
	[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-		[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
	Protocol Port Randomization", BCP 156, RFC 6056,		Protocol Port Randomization", BCP 156, RFC 6056,
	January 2011.		January 2011.
	[UPnP-IGD]		[UPnP-IGD]
	UPnP Forum, "Universal Plug and Play (UPnP) Internet		UPnP Forum, "Universal Plug and Play (UPnP) Internet
	Gateway Device (IGD) V 2.0", December 2010,		Gateway Device (IGD) V 2.0", December 2010,
	<http://upnp.org/specs/gw/igd2/>.		<http://upnp.org/specs/gw/igd2/>.
	[Windows-Logo]		[Windows-Logo]
	Microsoft, "Windows Logo Program Device Requirements",		Microsoft, "Windows Logo Program Device Requirements",
	2006, <http://www.microsoft.com/whdc/winlogo/		2006, <http://www.microsoft.com/whdc/winlogo/
	hwrequirements/default.mspx>.		hwrequirements/default.mspx>.
	Authors' Addresses		Authors' Addresses
	Mat Ford (editor)		Mat Ford (editor)
End of changes. 9 change blocks.
	16 lines changed or deleted		8 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/