< draft-azinger-additional-private-ipv4-space-issues-04.txt		draft-azinger-additional-private-ipv4-space-issues-05.txt >
	Network Working Group M. Azinger		Network Working Group M. Azinger
	Internet-Draft Frontier Communications		Internet-Draft Frontier Communications
	Intended status: Informational Corporation		Intended status: Informational Corporation
	Expires: October 19, 2010 L. Vegoda		Expires: July 8, 2011 L. Vegoda
	ICANN		ICANN
	April 17, 2010		January 4, 2011
	Additional Private IPv4 Space Issues		Issues Associated with Designating Additional Private IPv4 Address Space
	draft-azinger-additional-private-ipv4-space-issues-04		draft-azinger-additional-private-ipv4-space-issues-05
	Abstract		Abstract
	When a private network or internetwork grows very large it is		When a private network or internetwork grows very large it is
	sometimes not possible to address all interfaces using private IPv4		sometimes not possible to address all interfaces using private IPv4
	address space because there are not enough addresses. This document		address space because there are not enough addresses. This document
	describes the problems faced by those networks, the available options		describes the problems faced by those networks, the available options
	and the issues involved in assigning a new block of private IPv4		and the issues involved in assigning a new block of private IPv4
	address space.		address space.
	While this informational document does not make a recommendation for		While this informational document does not make a recommendation for
	action, it documents the issues surrounding the various options that		action, it documents the issues surrounding the various options that
	have been considered.		have been considered.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that
	working documents as Internet-Drafts. The list of current Internet-		other groups may also distribute working documents as Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts.
	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 October 19, 2010.		The list of current Internet-Drafts can be accessed at
			http://www.ietf.org/ietf/1id-abstracts.txt.
	Copyright Notice		The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html.
	Copyright (c) 2010 IETF Trust and the persons identified as the		This Internet-Draft will expire on July 8, 2011.
			Copyright Notice
			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
	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 BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Large Networks . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Large Networks . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Network Address Translation . . . . . . . . . . . . . . . . . 3		3. Non-Unique Addresses . . . . . . . . . . . . . . . . . . . . . 3
			3.1. Subscriber Use Network Address Translation . . . . . . . . 3
			3.2. Carrier Grade Network Address Translation . . . . . . . . 4
	4. Available Options . . . . . . . . . . . . . . . . . . . . . . 4		4. Available Options . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. Unique Globally Scoped IPv6 Unicast Addresses . . . . . . 4		4.1. IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . 4
	4.2. Unique Local IPv6 Unicast Addresses . . . . . . . . . . . 4		4.1.1. Unique Globally Scoped IPv6 Unicast Addresses . . . . 4
	4.3. Address Transfers or Leases From Organizations with		4.1.2. Unique Local IPv6 Unicast Addresses . . . . . . . . . 4
	Available Address Space . . . . . . . . . . . . . . . . . 4		4.2. IPv4 Options . . . . . . . . . . . . . . . . . . . . . . . 5
	4.4. Using Unannounced Address Space Allocated to Another		4.2.1. Address Transfers or Leases From Organizations
	Organization . . . . . . . . . . . . . . . . . . . . . . . 5		with Available Address Space . . . . . . . . . . . . . 5
	4.5. Unique IPv4 Space Registered by an RIR . . . . . . . . . . 5		4.2.2. Using Unannounced Address Space Allocated to
			Another Organization . . . . . . . . . . . . . . . . . 5
			4.2.3. Unique IPv4 Space Registered by an RIR . . . . . . . . 6
	5. Options and Consequences for Defining New Private Use Space . 6		5. Options and Consequences for Defining New Private Use Space . 6
	5.1. Redefining Existing Unicast Space as Private Address		5.1. Redefining Existing Unicast Space as Private Address
	Space . . . . . . . . . . . . . . . . . . . . . . . . . . 6		Space . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5.2. Unique IPv4 Space Shared by a Group of Operators . . . . . 7		5.2. Unique IPv4 Space Shared by a Group of Operators . . . . . 7
	5.3. Potential Consequences of Not Redefining Existing		5.3. Potential Consequences of Not Redefining Existing
	Unicast Space as Private Address Space . . . . . . . . . . 7		Unicast Space as Private Address Space . . . . . . . . . . 8
	5.4. Redefining Future Use Space as Unicast Address Space . . . 7		5.4. Redefining Future Use Space as Unicast Address Space . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	8.2. Informative References . . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	[RFC1918] sets aside three blocks of IPv4 address space for use in		[RFC1918] sets aside three blocks of IPv4 address space for use in
	private networks: 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8.		private networks: 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8.
	These blocks can be used simultaneously in multiple, separately		These blocks can be used simultaneously in multiple, separately
	managed networks without registration or coordination with IANA or		managed networks without registration or coordination with IANA or
	any Internet registry. Very large networks can find that they need		any Internet registry. Very large networks can find that they need
	to connect more interfaces than the number of addresses available in		to number more device interfaces than there are available addresses
	these three ranges. It has occasionally been suggested that		in these three ranges. It has occasionally been suggested that
	additional private IPv4 address space should be reserved for use by		additional private IPv4 address space should be reserved for use by
	these networks. Although such an action might address some of the		these networks. Although such an action might address some of the
	needs for these very large network operators it is not without		needs for these very large network operators it is not without
	consequences, particularly as we near the date when the IANA free		consequences, particularly as we near the date when the IANA free
	pool will be fully allocated.		pool will be fully allocated.
	2. Large Networks		2. Large Networks
	The main categories of very large networks using private address		The main categories of very large networks using private address
	space are: cable operators, wireless (cell phone) operators, private		space are: cable operators, wireless (cell phone) operators, private
	internets and VPN service providers. In the case of the first two		internets and VPN service providers. In the case of the first two
	categories, the complete address space reserved in [RFC1918] tends to		categories, the complete address space reserved in [RFC1918] tends to
	be used by a single organization. In the case of private internets		be used by a single organization. In the case of private internets
	and VPN service providers there are multiple independently managed		and VPN service providers there are multiple independently managed
	and operated networks and the difficulty is in avoiding address		and operated networks and the difficulty is in avoiding address
	clashes.		clashes.
	3. Network Address Translation		3. Non-Unique Addresses
			3.1. Subscriber Use Network Address Translation
	The address space set aside in [RFC1918] is a finite resource which		The address space set aside in [RFC1918] is a finite resource which
	can be used to provide limited Internet access via Network Address		can be used to provide limited Internet access via Network Address
	Translation (NAT). A discussion of the advantages and disadvantages		Translation (NAT). A discussion of the advantages and disadvantages
	of NATs is outside the scope of this document. Nonetheless, it must		of NATs is outside the scope of this document but a an analysis of
	be acknowledged that NAT is adequate in some situations and not in		the advantages, disadvantages and architectural implications can be
	others. For instance, it is often technically feasible to use NAT or		found in [RFC2993]. Nonetheless, it must be acknowledged that NAT is
	even multiple layers of NAT within the networks operated by		adequate in some situations and not in others. For instance, it
	residential users or corporations where peer to peer communication is		might technically feasible to use NAT or even multiple layers of NAT
	not needed. Where true peer to peer communication is needed or where		within the networks operated by residential users or corporations
	services or applications do not work properly behind NAT, globally		where only limited Internet access is required. A more detailed
	unique address space is required. In other cases, NAT traversal		analysis can be found in [RFC3022]. Where true peer to peer
	techniques facilitate peer-to-peer like communication for devices		communication is needed or where services or applications do not work
	behind NATs.		properly behind NAT, globally unique address space is required. In
			other cases, NAT traversal techniques facilitate peer-to-peer like
			communication for devices behind NATs.
	In many cases it is possible to use multiple layers of NAT to re-use		In many cases it is possible to use multiple layers of NAT to re-use
	parts of the address space defined in [RFC1918]. It is not always		parts of the address space defined in [RFC1918]. It is not always
	possible to rely on CPE devices using any particular range, however.		possible to rely on CPE devices using any particular range, however.
	In some cases this means that CPE devices can use unallocated address		In some cases this means that unorthodox workarounds including
	space or address space allocated to other network operators. In		assigning CPE devices unallocated address space or address space
	other cases, organizations choose to operate multiple separate		allocated to other network operators are feasible. In other cases,
	routing domains to allow them to re-use the same private address		organizations choose to operate multiple separate routing domains to
	ranges in multiple contexts. One consequence of this is the added		allow them to re-use the same private address ranges in multiple
	complexity involved in identifying which system is referred to when		contexts. One consequence of this is the added complexity involved
	an IP address is identified in a log or management systems.		in identifying which system is referred to when an IP address is
			identified in a log or management systems.
			3.2. Carrier Grade Network Address Translation
	Another option is to share one address across multiple interfaces and		Another option is to share one address across multiple interfaces and
	in some cases, subscribers. This model breaks the classical model		in some cases, subscribers. This model breaks the classical model
	used for logging address assignments and creates some risks		used for logging address assignments and creates significant risks
	[CLAYTON]. This concept is more fully explored in [FORD].		and additional burdens, as described in [CLAYTON] and more fully
			discussed in [FORD] and is documented in [DS-LITE].
	4. Available Options		4. Available Options
	When a network operator has exhausted the private address space set		When a network operator has exhausted the private address space set
	aside in [RFC1918] but needs to continue operating a single routing		aside in [RFC1918] but needs to continue operating a single routing
	domain a number of options are available. These include:		domain a number of options are available. These include:
	4.1. Unique Globally Scoped IPv6 Unicast Addresses		4.1. IPv6 Options
	Using unique, globally scoped IPv6 unicast addresses is the preferred		4.1.1. Unique Globally Scoped IPv6 Unicast Addresses
	option as it removes any concerns about address scarcity. In some
	cases implementing a new network protocol on a very large network		Using unique, globally scoped IPv6 unicast addresses is the best
	takes more time than is available, based on network growth and the		permanent solution as it removes any concerns about address scarcity
			within the next few decades. Implementing IPv6 is a major endeavor
			for service providers with millions of consumer customers and is
			likely to take considerable effort and time. In some cases
			implementing a new network protocol on a very large network takes
			more time than is available, based on network growth and the
	proportion of private space that has already been used. In these		proportion of private space that has already been used. In these
	cases, there is a call for additional private address space that can		cases, there is a call for additional private address space that can
	be shared by all network operators. [DAVIES] makes one such case.		be shared by all network operators. [DAVIES] makes one such case.
	4.2. Unique Local IPv6 Unicast Addresses		4.1.2. Unique Local IPv6 Unicast Addresses
	Using the unique, local IPv6 unicast addresses defined in [RFC4193]		Using the unique, local IPv6 unicast addresses defined in [RFC4193]
	is another approach and does not require coordination with an		is another approach and does not require coordination with an
	Internet registry. Although the addresses defined in [RFC4193] are		Internet registry. Although the addresses defined in [RFC4193] are
	probabilistically unique, network operators on private internets and		probabilistically unique, network operators on private internets and
	those providing VPN services might not want to use them because there		those providing VPN services might not want to use them because there
	is a very low probability of non-unique locally assigned global IDs		is a very low probability of non-unique locally assigned global IDs
	being generated by the algorithm. Also, in the case of private		being generated by the algorithm. Also, in the case of private
	internets, it can be very challenging to coordinate the introduction		internets, it can be very challenging to coordinate the introduction
	of a new network protocol to support the internet's continued growth.		of a new network protocol to support the internet's continued growth.
	4.3. Address Transfers or Leases From Organizations with Available		4.2. IPv4 Options
	Address Space
			4.2.1. Address Transfers or Leases From Organizations with Available
			Address Space
	The Regional Internet Registry (RIR) communities have recently been		The Regional Internet Registry (RIR) communities have recently been
	developing policies to allow organizations with available address		developing policies to allow organizations with available address
	space to transfer such designated space to other organizations		space to transfer such designated space to other organizations
	[RIR-POLICY]. In other cases, leases might be arranged. This		[RIR-POLICY]. In other cases, leases might be arranged. This
	approach is only viable for operators of very large networks if		approach is only viable for operators of very large networks if
	enough address space is made available for transfer or lease and if		enough address space is made available for transfer or lease and if
	the very large networks are able to pay the costs of these transfers.		the very large networks are able to pay the costs of these transfers.
	It is not possible to know how much address space will become		It is not possible to know how much address space will become
	available in this way, when it will be available and how much it will		available in this way, when it will be available and how much it will
	cost. However, it is unlikely to become available in large		cost. However, it is unlikely to become available in large
	contiguous blocks and this would add to the network managment burden		contiguous blocks and this would add to the network management burden
	for the operator. For these reasons, address transfers will not be		for the operator as a significant number of small prefixes would
	an attractive proposition to many large network operators. Leases		inflate the size of the operators routing table at a time when it is
	might not be attractive to some organizations if both parties cannot		also adding an IPv6 routing table. These reasons will make address
	agree a suitable length of time. Also, the lessor might worry about		transfers a less attractive proposition to many large network
	its own unanticipated needs for additional IPv4 address space.		operators. Leases might not be attractive to some organizations if
			both parties cannot agree a suitable length of time. Also, the
			lessor might worry about its own unanticipated needs for additional
			IPv4 address space.
	4.4. Using Unannounced Address Space Allocated to Another Organization		4.2.2. Using Unannounced Address Space Allocated to Another
			Organization
	Some network operators have considered using IP address space which		Some network operators have considered using IP address space which
	is allocated to another organization but is not publicly visible in		is allocated to another organization but is not publicly visible in
	BGP routing tables. This option is very strongly discouraged as the		BGP routing tables. This option is very strongly discouraged as the
	fact that an address block is not visible from one view does not mean		fact that an address block is not visible from one view does not mean
	that it is not visible from another. Furthermore, address usage		that it is not visible from another. Furthermore, address usage
	tends to leak beyond private network borders in e-mail headers, DNS		tends to leak beyond private network borders in e-mail headers, DNS
	queries, traceroute output and other ways. The ambiguity this causes		queries, traceroute output and other ways. The ambiguity this causes
	is problematic for multiple organizations. This issue is addressed		is problematic for multiple organizations. This issue is discussed
	in [RFC3879], section 2.3.		in [RFC3879], section 2.3.
	It is also possible that the registrant of the address block might		It is also possible that the registrant of the address block might
	want to increase its visibility to other networks in the future,		want to increase its visibility to other networks in the future,
	causing problems for anyone using it unofficially. In some cases		causing problems for anyone using it unofficially. In some cases
	there might also be legal risks involved in using address space		there might also be legal risks involved in using address space
	officially allocated to another organization.		officially allocated to another organization.
	Where this has happened in the past it has caused operational		Where this has happened in the past it has caused operational
	problems [FASTWEB].		problems [FASTWEB].
	4.5. Unique IPv4 Space Registered by an RIR		4.2.3. Unique IPv4 Space Registered by an RIR
	The policy framework shared by the RIRs does not discriminate based		RIRs policies allow network operators to receive unique IP addresses
	on what an address is used to do, just on how efficiently the		for use on internal networks. Further, network operators are not
	assigned addresses are used. Unique IPv4 addresses registered by an		required to have already exhausted the private address space set
	RIR are potentially available to organizations whose networks have		aside in [RFC1918]. Nonetheless, network operators are naturally
	used all the addresses set aside in [RFC1918]. Nonetheless, network		disinclined to request unique IPv4 addresses for the private areas of
	operators are naturally disinclined to request unique IPv4 addresses		their networks as using addresses in this way means they are not
	for a purpose that could be met with private addresses were it not		available for use by new Internet user connections.
	for the size of the network because addresses assigned in this way
	are not available for anyone else to use and so their registration
	denies them to new entrants, including potential customers.
	It is likely to become more difficult for network operators to obtain		It is likely to become more difficult for network operators to obtain
	large blocks of unique address space as we approach the point where		large blocks of unique address space as we approach the point where
	all IPv4 unicast /8s have been allocated. Several RIRs already have		all IPv4 unicast /8s have been allocated. Several RIRs already have
	policies how to allocate from their last /8 [RIR-POLICY-FINAL-8] and		policies how to allocate from their last /8 [RIR-POLICY-FINAL-8] and
	there have been policy discussions that would reduce the maximum		there have been policy discussions that would reduce the maximum
	allocation size available to network operators [MAX-ALLOC] or would		allocation size available to network operators [MAX-ALLOC] or would
	reduce the period of need for which the RIR can allocate		reduce the period of need for which the RIR can allocate
	[SHORTER-PERIODS].		[SHORTER-PERIODS].
	5. Options and Consequences for Defining New Private Use Space		5. Options and Consequences for Defining New Private Use Space
	5.1. Redefining Existing Unicast Space as Private Address Space		5.1. Redefining Existing Unicast Space as Private Address Space
	It is be possible to re-designate a portion of the current global		It is possible to re-designate a portion of the current global
	unicast IPv4 address space as private unicast address space. Doing		unicast IPv4 address space as private unicast address space. Doing
	this could benefit a number of operators of large network for the		this could benefit a number of operators of large network for the
	short period before they complete their IPv6 roll-out. However, this		short period before they complete their IPv6 roll-out. However, this
	benefit incurs a cost by reducing the pool of global unicast		benefit incurs a cost by reducing the pool of global unicast
	addresses available to users in general.		addresses available to users in general.
	When considering re-designating a portion of the current global		When discussing re-designating a portion of the current global
	unicast IPv4 address space as private unicast address space it is		unicast IPv4 address space as private unicast address space it is
	important to consider how much space would be used and for how long		important to consider how much space would be used and for how long
	it would be sufficient. Not all of the large networks making full		it would be sufficient. Not all of the large networks making full
	use of the space defined in [RFC1918] would have their needs met with		use of the space defined in [RFC1918] would have their needs met with
	a single /8. In 2005, [HAIN] suggested reserving three /8s for this		a single /8. In 2005, [HAIN] suggested reserving three /8s for this
	purpose while in 2009 [DAVIES] suggested a single /10 would be		purpose while in 2009 [DAVIES] suggested a single /10 would be
	sufficient. There does not seem to be a consensus for a particular		sufficient. There does not seem to be a consensus for a particular
	prefix length nor an agreed basis for deciding what is sufficient.		prefix length nor an agreed basis for deciding what is sufficient.
	The problem is exacerbated by the continually changing needs of ever		The problem is exacerbated by the continually changing needs of ever
	expanding networks.		expanding networks.
	skipping to change at page 8, line 28 ¶		skipping to change at page 9, line 4 ¶
	6. Security Considerations		6. Security Considerations
	This document has no security implications.		This document has no security implications.
	7. IANA Considerations		7. IANA Considerations
	This document makes no request of IANA.		This document makes no request of IANA.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and		[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
	E. Lear, "Address Allocation for Private Internets",		E. Lear, "Address Allocation for Private Internets",
	BCP 5, RFC 1918, February 1996.		BCP 5, RFC 1918, February 1996.
	[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of		[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
	Understanding Concerning the Technical Work of the		November 2000.
	Internet Assigned Numbers Authority", RFC 2860, June 2000.
			[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
			Address Translator (Traditional NAT)", RFC 3022,
			January 2001.
	[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast		[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
	Addresses", RFC 4193, October 2005.		Addresses", RFC 4193, October 2005.
	8.2. Informative References		8.2. Informative References
	[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local		[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
	Addresses", RFC 3879, September 2004.		Addresses", RFC 3879, September 2004.
	[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol		[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
	skipping to change at page 9, line 16 ¶		skipping to change at page 9, line 39 ¶
	<http://www.anonet.org/>.		<http://www.anonet.org/>.
	[CLAYTON] Clayton, R., "Practical mobile Internet access		[CLAYTON] Clayton, R., "Practical mobile Internet access
	traceability", January 2010, <http://		traceability", January 2010, <http://
	www.lightbluetouchpaper.org/2010/01/13/		www.lightbluetouchpaper.org/2010/01/13/
	practical-mobile-internet-access-traceability/>.		practical-mobile-internet-access-traceability/>.
	[CYMRU] Greene, B., "The Bogon Reference",		[CYMRU] Greene, B., "The Bogon Reference",
	<http://www.team-cymru.org/Services/Bogons/>.		<http://www.team-cymru.org/Services/Bogons/>.
	[DAVIES] Davies, G. and C. Liljenstolpe, "Transitional non-		[DAVIES] Davies, G. and C. Liljenstolpe, "Work in Progress:
	conflicting reusable IPv4 address block", November 2009, <		Transitional non-conflicting reusable IPv4 address block",
	http://tools.ietf.org/html/		November 2009, <http://tools.ietf.org/html/
	draft-davies-reusable-ipv4-address-block-00>.		draft-davies-reusable-ipv4-address-block-00>.
			[DS-LITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Work in
			Progress: Dual-Stack Lite Broadband Deployments Following
			IPv4 Exhaustion", August 2010, <http://tools.ietf.org/
			html/draft-ietf-softwire-dual-stack-lite-06>.
	[FASTWEB] Aina, A., "41/8 announcement", May 2006,		[FASTWEB] Aina, A., "41/8 announcement", May 2006,
	<http://www.afnog.org/archives/2006-May/002117.html>.		<http://www.afnog.org/archives/2006-May/002117.html>.
	[FORD] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.		[FORD] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
	Roberts, "Issues with IP Address Sharing", March 2010, <ht		Roberts, "Work in Progress: Issues with IP Address
	tp://tools.ietf.org/html/		Sharing", March 2010, <http://tools.ietf.org/html/
	draft-ford-shared-addressing-issues-02>.		draft-ford-shared-addressing-issues-02>.
	[FULLER] Fuller, V., Lear, E., and D. Meyer, "Reclassifying 240/4		[FULLER] Fuller, V., Lear, E., and D. Meyer, "Work in Progress:
	as usable unicast address space", March 2008,		Reclassifying 240/4 as usable unicast address space",
			March 2008,
	<http://tools.ietf.org/html/draft-fuller-240space-02>.		<http://tools.ietf.org/html/draft-fuller-240space-02>.
	[HAIN] Hain, T., "Expanded Address Allocation for Private		[HAIN] Hain, T., "Work in Progress: Expanded Address Allocation
	Internets", January 2005,		for Private Internets", January 2005,
	<http://tools.ietf.org/html/draft-hain-1918bis-01>.		<http://tools.ietf.org/html/draft-hain-1918bis-01>.
	[LEWIS] Lewis, J., "This system has been setup for testing		[LEWIS] Lewis, J., "This system has been setup for testing
	purposes for 69/8 address space", March 2003,		purposes for 69/8 address space", March 2003,
	<http://69box.atlantic.net/>.		<http://69box.atlantic.net/>.
	[MAX-ALLOC]		[MAX-ALLOC]
	Spenceley, J. and J. Martin, "prop-070: Maximum IPv4		Spenceley, J. and J. Martin, "prop-070: Maximum IPv4
	allocation size", January 2009,		allocation size", January 2009,
	<http://www.apnic.net/policy/proposals/prop-070>.		<http://www.apnic.net/policy/proposals/prop-070>.
	skipping to change at page 10, line 40 ¶		skipping to change at page 11, line 21 ¶
	ipj_10-3/103_awkward.html>.		ipj_10-3/103_awkward.html>.
	[WESSELS] Wessels, D., "Searching for Evidence of Unallocated		[WESSELS] Wessels, D., "Searching for Evidence of Unallocated
	Address Space Usage in DITL 2008 Data", June 2008, <https:		Address Space Usage in DITL 2008 Data", June 2008, <https:
	//www.dns-oarc.net/files/dnsops-2008/		//www.dns-oarc.net/files/dnsops-2008/
	Wessels-Unused-space.pdf>.		Wessels-Unused-space.pdf>.
	[WIANA] WIANA, "The Wireless Internet Assigned Numbers Authority",		[WIANA] WIANA, "The Wireless Internet Assigned Numbers Authority",
	<http://www.wiana.org/>.		<http://www.wiana.org/>.
	[WILSON] Wilson, P., Michaelson, G., and G. Huston, "Redesignation		[WILSON] Wilson, P., Michaelson, G., and G. Huston, "Work in
	of 240/4 from "Future Use" to "Private Use"",		Progress: Redesignation of 240/4 from "Future Use" to
			"Private Use"",
	<http://tools.ietf.org/html/draft-wilson-class-e-02>.		<http://tools.ietf.org/html/draft-wilson-class-e-02>.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	The authors would also like to thank Ron Bonica, Michelle Cotton, Lee		The authors would also like to thank Ron Bonica, Michelle Cotton, Lee
	Howard and Barbara Roseman for their assistance in early discussions		Howard and Barbara Roseman for their assistance in early discussions
	of this document and to Alex Bligh, Maria Blackmore, Ricardo Patara		of this document and to Maria Blackmore, Alex Bligh, Mat Ford, Thomas
	and Mat Ford for improvement suggestions.		Narten, Ricardo Patara and for improvement suggestions.
	Authors' Addresses		Authors' Addresses
	Marla Azinger		Marla Azinger
	Frontier Communications Corporation		Frontier Communications Corporation
	Vancouver, WA		Vancouver, WA
	United States of America		United States of America
	Email: marla.azinger@frontiercorp.com		Email: marla.azinger@ftr.com
	URI: http://www.frontiercorp.com/		URI: http://www.frontiercorp.com/
	Leo Vegoda		Leo Vegoda
	Internet Corporation for Assigned Names and Numbers		Internet Corporation for Assigned Names and Numbers
	4676 Admiralty Way, Suite 330		4676 Admiralty Way, Suite 330
	Marina del Rey, CA 90292		Marina del Rey, CA 90292
	United States of America		United States of America
	Phone: +1-310-823-9358		Phone: +1-310-823-9358
	Email: leo.vegoda@icann.org		Email: leo.vegoda@icann.org
	URI: http://www.iana.org/		URI: http://www.iana.org/
End of changes. 40 change blocks.
	96 lines changed or deleted		129 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/