draft-ietf-ipv6-deprecate-site-local-00.txt		draft-ietf-ipv6-deprecate-site-local-01.txt
	INTERNET DRAFT C. Huitema		INTERNET DRAFT C. Huitema
	< draft-ietf-ipv6-deprecate-site-local-00.txt> Microsoft		<draft-ietf-ipv6-deprecate-site-local-01.txt> Microsoft
	August 16, 2003 B. Carpenter		October 13, 2003 B. Carpenter
	Expires February 16, 2003 IBM		Expires May 13, 2004 IBM
	Deprecating Site Local Addresses		Deprecating Site Local Addresses
	Status of this memo		Status of this memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	skipping to change at line 43		skipping to change at page 10, line ?
	deprecates them. This deprecation does not prevent their continued		deprecates them. This deprecation does not prevent their continued
	use until a replacement has been standardized and implemented.		use until a replacement has been standardized and implemented.
	1 Introduction		1 Introduction
	For some time, the IPv6 working group has been debating a set of		For some time, the IPv6 working group has been debating a set of
	issues surrounding the use of "site local" addresses. In its meeting		issues surrounding the use of "site local" addresses. In its meeting
	in March 2003, the group reached a measure of agreement that these		in March 2003, the group reached a measure of agreement that these
	issues were serious enough to warrant a replacement of site local		issues were serious enough to warrant a replacement of site local
	addresses in their original form. Although the consensus was far		addresses in their original form. Although the consensus was far
	from unanimous, the working group decided in its meeting in July		from unanimous, the working group confirmed in its meeting in July
	2003 to document these issues and the consequent decision to		2003 the need to document these issues and the consequent decision
	deprecate IPv6 site-local unicast addresses.		to deprecate IPv6 site-local unicast addresses.
	Site-local addresses are defined in the IPv6 addressing architecture		Site-local addresses are defined in the IPv6 addressing architecture
	[RFC3513], especially in section 2.5.6.		[RFC3513], especially in section 2.5.6.
	The remainder of this document describes the adverse effects of		The remainder of this document describes the adverse effects of
	site-local addresses according to the above definition, and formally		site-local addresses according to the above definition, and formally
	deprecates them.		deprecates them.
	Carpenter, Huitema. [Page 1]		Carpenter, Huitema. [Page 1]
	Companion documents will describe the goals of a replacement		Companion documents will describe the goals of a replacement
	solution [Hain/Templin] and specify a replacement solution		solution [Hain/Templin] and specify a replacement solution
	[Hinden/Haberman]. However, the formal deprecation allows existing		[Hinden/Haberman]. However, the formal deprecation allows existing
	usage of site-local addresses to continue until the replacement is		usage of site-local addresses to continue until the replacement is
	standardized and implemented.		standardized and implemented.
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
	2 Adverse effects of site local addresses		2 Adverse effects of site local addresses
	Discussions in the IPv6 working group outlined several defects of		Discussions in the IPv6 working group outlined several defects of
	the current site local addressing scope. These defects fall in two		the current site local addressing scope. These defects fall in two
	broad categories: ambiguity of addresses, and fuzzy definition of		broad categories: ambiguity of addresses, and fuzzy definition of
	sites.		sites.
	As currently defined, site local addresses are ambiguous: an address		As currently defined, site local addresses are ambiguous: an address
	such as FEC0::1 can be present in multiple sites, and the address		such as FEC0::1 can be present in multiple sites, and the address
	itself does not contain any indication of the site to which it		itself does not contain any indication of the site to which it
	skipping to change at line 103		skipping to change at page 10, line ?
	In short, the developer pain is caused by the ambiguity of site		In short, the developer pain is caused by the ambiguity of site
	local addresses. Since site-local addresses are ambiguous,		local addresses. Since site-local addresses are ambiguous,
	application developers have to manage the "site identifiers" that		application developers have to manage the "site identifiers" that
	qualify the addresses of the hosts. This management of identifiers		qualify the addresses of the hosts. This management of identifiers
	has proven hard to understand by developers, and also hard to		has proven hard to understand by developers, and also hard to
	execute by those developers who understand the concept.		execute by those developers who understand the concept.
	2.2 Manager pain, leaks		2.2 Manager pain, leaks
			Carpenter, Huitema. [Page 2]
	The management of IPv6 site local addresses is in many ways similar		The management of IPv6 site local addresses is in many ways similar
	to the management of RFC 1918 [RFC1918] addresses in some IPv4		to the management of RFC 1918 [RFC1918] addresses in some IPv4
	networks. In theory, the private addresses defined in RFC 1918		networks. In theory, the private addresses defined in RFC 1918
	should only be used locally, and should never appear in the		should only be used locally, and should never appear in the
	Carpenter, Huitema. [Page 2]
	Internet. In practice, these addresses "leak". The conjunction of		Internet. In practice, these addresses "leak". The conjunction of
	leaks and ambiguity ends up causing management problems.		leaks and ambiguity ends up causing management problems.
	Names and literal addresses of "private" hosts leak in mail		Names and literal addresses of "private" hosts leak in mail
	messages, web pages, or files. Private addresses end up being used		messages, web pages, or files. Private addresses end up being used
	as source or destination of TCP requests or UDP messages, for		as source or destination of TCP requests or UDP messages, for
	example in DNS or trace-route requests, causing the request to fail,		example in DNS or trace-route requests, causing the request to fail,
	or the response to arrive at unsuspecting hosts. Private addresses		or the response to arrive at unsuspecting hosts.
	also end up being used as targets of reverse lookup requests in the
	DNS, uselessly overloading the DNS infrastructure.		The experience with RFC1918 addresses also shows some non trivial
			leaks, besides pacing these addresses in IP headers. Private
			addresses also end up being used as targets of reverse DNS queries
			for RFC1918, uselessly overloading the DNS infrastructure. In
			general, many applications that use IP addresses directly end up
			passing RFC1918 addresses in application payloads, creating
			confusion and failures.
	The leakage issue is largely unavoidable. While some applications		The leakage issue is largely unavoidable. While some applications
	are intrinsically scoped (eg. RA, ND), most applications have no		are intrinsically scoped (eg. Router Advertisement, Neighbor
	concept of scope, and no way of expressing scope. As a result,		Discovery), most applications have no concept of scope, and no way
	"stuff leaks across the borders". Since the addresses are ambiguous,		of expressing scope. As a result, "stuff leaks across the borders".
	the network managers cannot easily find out "who did it". Leaks are		Since the addresses are ambiguous, the network managers cannot
	thus hard to fix, resulting in a lot of frustration.		easily find out "who did it". Leaks are thus hard to fix, resulting
			in a lot of frustration.
	2.3 Router pain, routing tables		2.3 Router pain, routing tables
	The ambiguity of site local addresses also creates problems for the		The ambiguity of site local addresses also creates problems for the
	routers. In theory, site local addresses are only used within a		routers. In theory, site local addresses are only used within a
	contiguous site, and all routers in that site can treat them as if		contiguous site, and all routers in that site can treat them as if
	they were not ambiguous. In practice, problem occurs when sites are		they were not ambiguous. In practice, problem occurs when sites are
	disjoint, or when routers have to handle several sites.		disjoint, or when routers have to handle several sites.
	In theory, sites should never be disjoint. In practice, if site		In theory, sites should never be disjoint. In practice, if site
	skipping to change at line 150		skipping to change at page 10, line ?
	techniques, or the use of multi-sited routers, or both.		techniques, or the use of multi-sited routers, or both.
	Ambiguous addresses have fairly obvious consequences on multi-sited		Ambiguous addresses have fairly obvious consequences on multi-sited
	routers. In classic router architecture, the exit interface is a		routers. In classic router architecture, the exit interface is a
	direct function of the destination address, as specified by a single		direct function of the destination address, as specified by a single
	routing table. However, if a router is connected to multiple sites,		routing table. However, if a router is connected to multiple sites,
	the routing of site local packets depends on the interface on which		the routing of site local packets depends on the interface on which
	the packet arrived. Interfaces have to be associated to sites, and		the packet arrived. Interfaces have to be associated to sites, and
	the routing entries for the site local addresses are site-dependent.		the routing entries for the site local addresses are site-dependent.
	The route management software and the routing protocols have to		The route management software and the routing protocols have to
	account for the site boundaries.
			Carpenter, Huitema. [Page 3]
			account for the site boundaries. This can be particularly hard to do
			when sites are adjacent or overlap.
	In multi-homed routers, such as for example site border routers, the		In multi-homed routers, such as for example site border routers, the
	routing process should be complemented by a filtering process, to		routing process should be complemented by a filtering process, to
	guarantee that packets sourced with a site local address never leave		guarantee that packets sourced with a site local address never leave
	the site. This filtering process will in turn interact with the		the site. This filtering process will in turn interact with the
	routing of packets, as it may cause the drop of packets sent to a		routing of packets, as it may cause the drop of packets sent to a
	global address, even if that global address happen to belong to the		global address, even if that global address happen to belong to the
	target site.		target site.
	In summary, the ambiguity of site local addresses makes them hard to		In summary, the ambiguity of site local addresses makes them hard to
	Carpenter, Huitema. [Page 3]
	manage in multi-sited routers, while the requirement to support		manage in multi-sited routers, while the requirement to support
	disjoint sites creates a demand for such routers.		disjoint sites creates a demand for such routers.
	2.4 Site is an ill-defined concept		2.4 Site is an ill-defined concept
	The current definition of scopes follows an idealized "concentric		The current definition of scopes follows an idealized "concentric
	scope" model. Hosts are supposed to be attached to a link, which		scopes" model. Hosts are supposed to be attached to a link, which
	belongs to a site, which belongs to the Internet. Packets could be		belongs to a site, which belongs to the Internet. Packets could be
	sent to the same link, the same site, or outside that site. However,		sent to the same link, the same site, or outside that site. However,
	experts have been arguing about the definition of sites for years		experts have been arguing about the definition of sites for years
	and have reached no sort of consensus. That suggests that there is		and have reached no sort of consensus. That suggests that there is
	in fact no consensus to be reached.		in fact no consensus to be reached.
	Apart from link-local, scope boundaries are ill-defined. What is a		Apart from link-local, scope boundaries are ill-defined. What is a
	site? Is the whole of a corporate network a site, or are sites		site? Is the whole of a corporate network a site, or are sites
	limited to single geographic locations? Many networks today are		limited to single geographic locations? Many networks today are
	split between an internal area and an outside facing "DMZ",		split between an internal area and an outside facing "DMZ",
	separated by a firewall. Servers in the DMZ are supposedly		separated by a firewall. Servers in the DMZ are supposedly
	accessible by both the internal hosts and external hosts on the		accessible by both the internal hosts and external hosts on the
	Internet. Does the DMZ belong to the same site as the internal host?		Internet. Does the DMZ belong to the same site as the internal host?
	Depending on whom we ask, the definition of the site scope varies.		Depending on whom we ask, the definition of the site scope varies.
	It may map security boundaries, reachability boundaries, routing		It may map security boundaries, reachability boundaries, routing
	boundaries, QOS boundaries, administrative boundaries, funding		boundaries, QOS boundaries, administrative boundaries, funding
	boundaries, some other kinds of boundaries, or a combination. It is		boundaries, some other kinds of boundaries, or a combination of
	very unclear that a single scope could satisfy all these		these. It is very unclear that a single scope could satisfy all
	requirements.		these requirements.
	There are some well known and important scope-breaking phenomena,		There are some well known and important scope-breaking phenomena,
	such as intermittently connected networks, mobile nodes, mobile		such as intermittently connected networks, mobile nodes, mobile
	networks, inter-domain VPNs, hosted networks, network merges and		networks, inter-domain VPNs, hosted networks, network merges and
	splits, etc. Specifically, this means that scope *cannot* be mapped		splits, etc. Specifically, this means that scope *cannot* be mapped
	into concentric circles such as a naive link/local/global model.		into concentric circles such as a naive link/local/global model.
	Scopes overlap and extend into one another. The scope relationship		Scopes overlap and extend into one another. The scope relationship
	between two hosts may even be different for different protocols.		between two hosts may even be different for different protocols.
	In summary, the current concept of site is naive, and does not map		In summary, the current concept of site is naive, and does not map
	operational requirements.		operational requirements.
	3 Development of a better alternative		3 Development of a better alternative
			Carpenter, Huitema. [Page 4]
	The previous section reviewed the arguments against site-local		The previous section reviewed the arguments against site-local
	addresses. Obviously, site locals also have some benefits, without		addresses. Obviously, site locals also have some benefits, without
	which they would have been removed from the specification long ago.		which they would have been removed from the specification long ago.
	The perceived benefits of site local are that they are simple,		The perceived benefits of site local are that they are simple,
	stable, and private [Hain/Templin]. However, it appears that these		stable, and private [Hain/Templin]. However, it appears that these
	benefits can be also obtained with an alternative architecture, for		benefits can be also obtained with an alternative architecture, for
	example [Hinden/Haberman], in which addresses are not ambiguous and		example [Hinden/Haberman], in which addresses are not ambiguous and
	do not have a simple explicit scope.		do not have a simple explicit scope.
	Having non ambiguous address solves a large part of the developers'		Having non-ambiguous address solves a large part of the developers'
	pain, as it removes the need to manage site identifiers. The		pain, as it removes the need to manage site identifiers. The
	Carpenter, Huitema. [Page 4]
	application can use the addresses as if they were regular global		application can use the addresses as if they were regular global
	addresses, and the stack will be able to use standard techniques to		addresses, and the stack will be able to use standard techniques to
	discover which interface should be used. Some level of pain will		discover which interface should be used. Some level of pain will
	remain, as these addresses will not always be reachable; however,		remain, as these addresses will not always be reachable; however,
	applications can deal with the un-reachability issues by trying		applications can deal with the un-reachability issues by trying
	connections at a different time, or with a different address.		connections at a different time, or with a different address.
	Speculatively, a more sophisticated scope mechanism might be		Speculatively, a more sophisticated scope mechanism might be
	introduced at a later date.		introduced at a later date.
	Having non ambiguous addresses will not eliminate the leaks that		Having non ambiguous addresses will not eliminate the leaks that
	skipping to change at line 253		skipping to change at page 10, line ?
	One question remains, anycast addressing. Anycast addresses are		One question remains, anycast addressing. Anycast addresses are
	ambiguous by construction, since they refer by definition to any		ambiguous by construction, since they refer by definition to any
	host that has been assigned a given anycast address. Link-local or		host that has been assigned a given anycast address. Link-local or
	global anycast addresses can be"baked in the code". Further study is		global anycast addresses can be"baked in the code". Further study is
	required on the need for anycast addresses with scope between link-		required on the need for anycast addresses with scope between link-
	local and global.		local and global.
	4 Deprecation		4 Deprecation
	This document formally deprecates the IPv6 link-local unicast prefix		This document formally deprecates the IPv6 site-local unicast prefix
	defined in [RFC3513], i.e. 1111111011 binary or FEC0::/10. The		defined in [RFC3513], i.e. 1111111011 binary or FEC0::/10. The
	special behavior of this prefix MUST no longer be supported in new		special behavior of this prefix MUST no longer be supported in new
	implementations. The prefix MUST NOT be reassigned for other use		implementations. The prefix MUST NOT be reassigned for other use
			Carpenter, Huitema. [Page 5]
	except by a future IETF standards action. Future versions of the		except by a future IETF standards action. Future versions of the
	addressing architecture [RFC3513] will include this information.		addressing architecture [RFC3513] will include this information.
	However, router implementations SHOULD be configured to prevent		However, router implementations SHOULD be configured to prevent
	routing of this prefix by default.		routing of this prefix by default.
	Existing implementations and deployments MAY continue to use this		Existing implementations and deployments MAY continue to use this
	prefix.		prefix.
	5 Security Considerations		5 Security Considerations
	The link-local unicast prefix allows for some blocking action in		The site-local unicast prefix allows for some blocking action in
	Carpenter, Huitema. [Page 5]
	firewall rules and address selection rules, which are commonly		firewall rules and address selection rules, which are commonly
	viewed as a security feature since they prevent packets crossing		viewed as a security feature since they prevent packets crossing
	administrative boundaries. However, such blocking rules can be		administrative boundaries. Such blocking rules can be configured for
	configured for any prefix, including the expected future replacement		any prefix, including the expected future replacement for the site-
	for the site-local prefix. Thus the deprecation of the site-local		local prefix. If these blocking rules are actually enforced, the
	prefix does not endanger security.		deprecation of the site-local prefix does not endanger security.
	6 IANA Considerations		6 IANA Considerations
	IANA is specifically requested not to reassign the 1111111011 binary		IANA is specifically requested not to reassign the 1111111011 binary
	or FEC0::/10 prefix unless requested to do so by a future IETF		or FEC0::/10 prefix unless requested to do so by a future IETF
	standards action.		standards action.
	7 Copyright		7 Copyright
	The following copyright notice is copied from RFC 2026 [Bradner,		The following copyright notice is copied from RFC 2026 [Bradner,
	1996], Section 10.4, and describes the applicable copyright for this		1996], Section 10.4, and describes the applicable copyright for this
	document.		document.
	Copyright (C) The Internet Society August 13, 2003. All Rights		Copyright (C) The Internet Society October 10, 2003. All Rights
	Reserved.		Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph		kind, provided that the above copyright notice and this paragraph
	are included on all such copies and derivative works. However, this		are included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for		developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be		copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than		followed, or as required to translate it into languages other than
	English.		English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assignees.		revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
			Carpenter, Huitema. [Page 6]
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	8 Intellectual Property		8 Intellectual Property
	The following notice is copied from RFC 2026 [Bradner, 1996],		The following notice is copied from RFC 2026 [Bradner, 1996],
	Section 10.4, and describes the position of the IETF concerning		Section 10.4, and describes the position of the IETF concerning
	intellectual property claims made against this document.		intellectual property claims made against this document.
	Carpenter, Huitema. [Page 6]
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use other technology described in		pertain to the implementation or use other technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the		has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and		IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of		standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication and any assurances		claims of rights made available for publication and any assurances
	of licenses to be made available, or the result of an attempt made		of licenses to be made available, or the result of an attempt made
	skipping to change at line 346		skipping to change at page 10, line ?
	can be obtained from the IETF Secretariat.		can be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	9 Acknowledgements		9 Acknowledgements
			The authors would like to thank Fred Templin, Peter Bieringer,
			Chirayu Patel, Pekka Savola, and Alain Baudot for their review of
			the initial draft.
	10 References		10 References
	Normative References		Normative References
	[RFC3513] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC3513] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 3513, April 2003		Architecture", RFC 3513, April 2003
			[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
			Requirement Levels", RFC 2119, March 1997.
	Informative references		Informative references
	[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.		[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
	J. and E. Lear, "Address Allocation for Private Internets", RFC		J. and E. Lear, "Address Allocation for Private Internets", RFC
			Carpenter, Huitema. [Page 7]
	1918, February 1996		1918, February 1996
	[Hain/Templin] Hain, T. and F. Templin, "Addressing Requirements for		[Hain/Templin] Hain, T. and F. Templin, "Addressing Requirements for
	Local Communications within Sites", work in progress.		Local Communications within Sites", work in progress.
	[Hinden/Haberman] Hinden, R. and B. Haberman, "Unique Local IPv6		[Hinden/Haberman] Hinden, R. and B. Haberman, "Unique Local IPv6
	Unicast Addresses", work in progress.		Unicast Addresses", work in progress.
	11 Authors' Addresses		11 Authors' Addresses
	Christian Huitema		Christian Huitema
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052-6399		Redmond, WA 98052-6399
	USA		USA
	Email: huitema@microsoft.com		Email: huitema@microsoft.com
	Brian Carpenter		Brian Carpenter
	IBM Corporation		IBM Corporation
	Carpenter, Huitema. [Page 7]
	Sauemerstrasse 4		Sauemerstrasse 4
	8803 Rueschlikon		8803 Rueschlikon
	Switzerland		Switzerland
	Email: brc@zurich.ibm.com		Email: brc@zurich.ibm.com
			12 History of changes
			12.1 Changes from draft-00 to draft-01
			Changed the text in the introduction to say that the decision was
			"confirmed" in July 2003.
			Add some explanatory text in section 2.2, address leak, and section
			2.3, routing pain.
			In section 4, and 5 change the erroneous "link local" to "site
			local".
			Add a reference to RFC 2119 describing the use of keywords.
			In section 5, qualify that the replacement of site local is only as
			secure if blocking rules are actually implemented at site
			boundaries.
	Carpenter, Huitema. [Page 8]		Carpenter, Huitema. [Page 8]
			Carpenter, Huitema. [Page 9]
			Table of Contents:
			1 Introduction .................................................... 1
			2 Adverse effects of site local addresses ......................... 2
			2.1 Developer pain ................................................ 2
			2.2 Manager pain, leaks ........................................... 2
			2.3 Router pain, routing tables ................................... 3
			2.4 Site is an ill-defined concept ................................ 4
			3 Development of a better alternative ............................. 4
			4 Deprecation ..................................................... 5
			5 Security Considerations ......................................... 6
			6 IANA Considerations ............................................. 6
			7 Copyright ....................................................... 6
			8 Intellectual Property ........................................... 7
			9 Acknowledgements ................................................ 7
			10 References ..................................................... 7
			11 Authors' Addresses ............................................. 8
			12 History of changes ............................................. 8
			12.1 Changes from draft-00 to draft-01 ............................ 8
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/