draft-ietf-v6ops-routing-guidelines-00.txt		draft-ietf-v6ops-routing-guidelines-01.txt
	Network Working Group M. Blanchet		Network Working Group M. Blanchet
	Internet-Draft Viagenie		Internet-Draft Viagenie
			Intended status: Standards Track February 26, 2007
			Expires: August 30, 2007
	IPv6 Routing Policies Guidelines		IPv6 Routing Policies Guidelines
	draft-ietf-v6ops-routing-guidelines-00.txt		draft-ietf-v6ops-routing-guidelines-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 31		skipping to change at page 1, line 34
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 2, 2006.		This Internet-Draft will expire on August 30, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	Guidelines on how to manage IPv6 routes are needed for operators of		Guidelines on how to manage and filter IPv6 routes are needed for
	networks, either providers or enterprises. This document is a		operators of networks, either providers or enterprises. It describes
	followup on RFC2772 work but for the production IPv6 Internet.		IPv6 routes from the protocol point of view. It does not discuss
	RFC2772 becomes historic.		operational or policy issues such as the maximum length of prefixes
			to filter. This document is a followup on RFC2772 work but for the
			production IPv6 Internet. RFC2772 is obsoleted.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Address Types . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Address Types . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Node-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3		2.1. Node-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3
	2.2. IPv4-Mapped Addresses . . . . . . . . . . . . . . . . . . . 3		2.2. IPv4-Mapped Addresses . . . . . . . . . . . . . . . . . . . 3
	2.3. Link-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3		2.3. Link-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3
	2.4. Site-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3		2.4. Site-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3
	2.5. Global Unicast . . . . . . . . . . . . . . . . . . . . . . 3		2.5. Global Unicast . . . . . . . . . . . . . . . . . . . . . . 3
	2.5.1. Documentation Prefix . . . . . . . . . . . . . . . . . 4		2.5.1. Documentation Prefix . . . . . . . . . . . . . . . . . 4
	2.5.2. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . 4		2.5.2. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.5.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . . 4		2.5.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.5.4. 6bone . . . . . . . . . . . . . . . . . . . . . . . . . 4		2.5.4. 6bone . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.6. Default Route . . . . . . . . . . . . . . . . . . . . . . . 4		2.6. Default Route . . . . . . . . . . . . . . . . . . . . . . . 4
	2.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.8. Unknown addresses . . . . . . . . . . . . . . . . . . . . . 5		2.8. Unknown addresses . . . . . . . . . . . . . . . . . . . . . 5
	3. Implementing routing policies . . . . . . . . . . . . . . . . . 5		3. Implementing routing policies . . . . . . . . . . . . . . . . . 5
	4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		4. RPSL Implementation . . . . . . . . . . . . . . . . . . . . . . 5
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 6		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6.2. Informative References . . . . . . . . . . . . . . . . . . 6		7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
			7.2. Informative References . . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
	Intellectual Property and Copyright Statements . . . . . . . . . . 8		Intellectual Property and Copyright Statements . . . . . . . . . . 8
	1. Introduction		1. Introduction
	To maintain stability, efficiency and scalability of the IPv6		To maintain stability, efficiency and scalability of the IPv6
	Internet, guidelines for routing policies are needed for operators		Internet, guidelines for routing policies are needed for operators
	deploying IPv6 networks. Prior experience on IPv6 routing guidelines		deploying IPv6 networks. Prior experience on IPv6 routing guidelines
	on the 6bone[RFC2772], practical deployment of the IPv6 internet and		on the 6bone[RFC2772], practical deployment of the IPv6 internet and
	IPv6 specifications were used as input to this document.		IPv6 specifications were used as input to this document.
	skipping to change at page 3, line 29		skipping to change at page 3, line 29
	2. Address Types		2. Address Types
	2.1. Node-scoped Unicast		2.1. Node-scoped Unicast
	The node-scoped unicast addresses[RFC4291] such as the loopback		The node-scoped unicast addresses[RFC4291] such as the loopback
	(::1/128), the unspecified (::/128) must not be advertised in an IGP		(::1/128), the unspecified (::/128) must not be advertised in an IGP
	or EGP and should be filtered out when received.		or EGP and should be filtered out when received.
	2.2. IPv4-Mapped Addresses		2.2. IPv4-Mapped Addresses
	IPv4-mapped addresses (::FFFF:0:0/96)[RFC4291] must not be advertised		IPv4-mapped addresses (::FFFF:0:0/96) [RFC4291] must not be
	and should be filtered out.		advertised and should be filtered out.
	2.3. Link-scoped Unicast		2.3. Link-scoped Unicast
	The link-scoped unicast[RFC4291] routes (fe80::/10) must not be		The link-scoped unicast[RFC4291] routes (fe80::/10) must not be
	advertised in an IGP or EGP and should be filtered out when received.		advertised in an IGP or EGP and should be filtered out when received.
	2.4. Site-scoped Unicast		2.4. Site-scoped Unicast
	The site-scoped unicast routes, known as Unique-local[RFC4193],		The site-scoped unicast routes, known as Unique-local[RFC4193],
	(fc00::/7) may be advertised in an IGP. It must not be advertised in		(fc00::/7) may be advertised in an IGP. It must not be advertised in
	an EGP connected to the global Internet and should be filtered out		an EGP connected to the global Internet and should be filtered out
	when received. However, it may be advertised in an EGP between two		when received. However, it may be advertised in an EGP between two
	networks sharing a private interconnect, but must not be advertised		networks sharing a private interconnect, but must not be advertised
	outside the scope of these networks. When advertised in an EGP,		outside the scope of these networks. When advertised in an EGP,
	these routes should be of length /48.		these routes should be of length /48 or smaller.
	2.5. Global Unicast		2.5. Global Unicast
	The global unicast routes (2000::/3)[RFC4291] may be advertised in an		The global unicast routes (2000::/3) [RFC4291] may be advertised in
	IGP or EGP. A minimal EGP routing policy should filter out routes		an IGP or EGP.
	that exceed a maximum length. Determining the maximum length of a
	global Internet route is outside the scope of this document.		A minimal EGP routing policy should filter out routes that exceed a
			maximum length. Determining the maximum length of a global Internet
			route is outside the scope of this document.
	A finer EGP routing policy may use only the allocated address space		A finer EGP routing policy may use only the allocated address space
	from IANA to registry as specified in		from IANA to registries as specified in
	http://www.iana.org/assignments/ipv6-unicast-address-assignments.		http://www.iana.org/assignments/ipv6-unicast-address-assignments.
	This would result in better filtering since the non-allocated		This would result in better filtering since the non-allocated
	prefixes will be filtered out.		prefixes will be filtered out.
	An even finer EGP routing policy may use only the assigned address		An even finer EGP routing policy may use only the assigned address
	space from registries to providers as available in the registry		space from registries to providers as available in the registries
	databases. This would result in the best filtering since the non-		databases. This would result in the best filtering since the non-
	assigned prefixes will be filtered out. However, this requires the		assigned prefixes will be filtered out. However, this requires the
	synchronization of the filters with the registry databases.		synchronization of the filters with the registries databases.
	2.5.1. Documentation Prefix		2.5.1. Documentation Prefix
	The 2001:0db8::/32 prefix[RFC3849] is used for documentation purposes		The 2001:0db8::/32 prefix[RFC3849] is used for documentation purposes
	and must not be advertised in an IGP or EGP and should be filtered		and must not be advertised in an IGP or EGP and should be filtered
	out when received.		out when received.
	2.5.2. 6to4		2.5.2. 6to4
	The 6to4[RFC4291] prefix (2002::/16) may be advertised in an IGP or		The 6to4[RFC4291][RFC3056] prefix (2002::/16) may be advertised in an
	EGP, when the site is running a 6to4 relay or offering a 6to4 transit		IGP or EGP, when the site is running a 6to4 relay or offering a 6to4
	service. However, the provider of this service should be aware of		transit service. However, the provider of this service should be
	the implications of running such service[RFC3964], which includes		aware of the implications of running such service[RFC3964], which
	some specific filtering rules for 6to4.		includes some specific filtering rules for 6to4.
	2.5.3. Teredo		2.5.3. Teredo
	The Teredo[RFC4380] prefix (2001::/32) may be advertised in an IGP or		The Teredo[RFC4380] prefix (2001::/32) may be advertised in an IGP or
	EGP, when the site is running a Teredo relay or offering a Teredo		EGP, when the site is running a Teredo relay or offering a Teredo
	transit service.		transit service.
	2.5.4. 6bone		2.5.4. 6bone
	The 6bone experimental network used some experimental allocations,		The 6bone experimental network used some experimental allocations,
	such as 5f00::/8[RFC1897] and 3ffe::/16[RFC2471] that were later		such as 5f00::/8[RFC1897] and 3ffe::/16[RFC2471] that were later
	returned to IANA[RFC3701]. These prefixes should not be advertised		returned to IANA[RFC3701]. These prefixes should not be advertised
	in an EGP unless IANA reallocates them subsequently.		in an EGP unless IANA reallocates them subsequently.
	2.6. Default Route		2.6. Default Route
	The default unicast route (::) may be advertised in an IGP. In an		The default unicast route (::) may be advertised in an IGP. It must
	EGP, it may be only advertised to the downstream but must not be		not be advertised in an EGP unless it has been requested by the
	advertised in the core.		recipient.
	2.7. Multicast		2.7. Multicast
	Multicast addresses (ff00::/8)[RFC4291] have a scope in the address		Multicast addresses (ff00::/8) [RFC4291] have a 4 bits scope in the
	field. In the multicast routing, the routes should be announced		address field. Only addresses having the 'E' value in the scope
	according to the scope, similar to unicast routes. Multicast routes		field are of global scope, all other values are local or reserved.
	must not appear in unicast routing tables.		Therefore, only ffXe:: routes may be advertised outside an
			organisation network, where X may be any value.
			Multicast routes must not appear in unicast routing tables.
	2.8. Unknown addresses		2.8. Unknown addresses
	Any non listed address above must not be advertised and should be		Any non listed address above must not be advertised and should be
	filtered out. Future work might reserve additional address space for		filtered out. Future work might reserve additional address space for
	protocol use which might require specific routing guidelines. The		protocol use which might require specific routing guidelines. The
	reader should refer to newer versions of the normative references in		reader should refer to newer versions of the normative references in
	this document to verify the existence of newer protocol address		this document to verify the existence of newer protocol address
	space.		space.
	3. Implementing routing policies		3. Implementing routing policies
	This document focuses on protocol addresses and their use in the		This document focuses on protocol addresses and their use in the
	networks. It does not discuss any allocation policies and their		networks. It does not discuss any allocation policies and their
	impact on the routing policies, such as /48 Micro-allocations for		impact on the routing policies, such as /48 Micro-allocations for
	infrastructure providers or maximum length of a unicast prefix. As		infrastructure providers or maximum length of a unicast prefix. As
	such, to implement a complete routing policy, one should augment		such, to implement a complete routing policy, one should augment
	these guidelines with the current registry allocation policies and by		these guidelines with the current registry allocation policies and by
	appropriate ingress filtering techniques[RFC3704].		appropriate ingress filtering techniques[RFC3704].
			4. RPSL Implementation
	The Route Policy Specification Language(RPSL)[RFC4012] used in route		The Route Policy Specification Language(RPSL)[RFC4012] used in route
	registries supports the policies described in this document and		registries supports the policies described in this document and
	should be considered to manage route policies.		should be considered to manage route policies.
	The following RPSL code implements the policies described in this		The following RPSL code implements the policies described in this
	document. This code should be considered as an example and should be		document. This code should be considered as an example and should be
	adapted to its target usage.		adapted to the target usage.
	TBD: RPSL code to fill		route-set: rs-exclude
			mp-members: ::1/128, ::/128, ::ffff:0:0/96^+, fe80::/10^+,
			2001:0db8::/32^+
	4. Security Considerations		route-set: rs-ula
			mp-members: fc00::/7^+
	This document list guidelines to improve the security of networks by		route-set: rs-global-unicast
	filtering of routing prefixes.		mp-members: 2000::/3^+
	5. Acknowledgements		route-set: rs-6to4
			mp-members: 2002::/16^+
			route-set: rs-teredo
			mp-members: 2001::/32^+
			filter-set: fltr-v6egp
			mp-filter: NOT (rs-exclude AND rs-ula) AND rs-global-unicast
			filter-set: fltr-v6igp
			mp-filter: NOT rs-exclude AND rs-global-unicast
			5. Security Considerations
			This document list guidelines that should improve the security of
			networks by the filtering of invalid routing prefixes.
			6. Acknowledgements
	Florent Parent, Pekka Savola, Tim Chown, Alain Baudot, Stig Venaas,		Florent Parent, Pekka Savola, Tim Chown, Alain Baudot, Stig Venaas,
	Vincent Jardin, Olaf Bonness, David Green, Gunter Van de Velde,		Vincent Jardin, Olaf Bonness, David Green, Gunter Van de Velde,
	Michael Barnes and Fred Baker have provided input and suggestions to		Michael Barnes, Fred Baker, Edward Lewis, Marla Azinger, Brian
	this document.		Carpenter, Mark Smith and Kevin Loch have provided input and
			suggestions to this document.
	6. References		7. References
	6.1. Normative References		7.1. Normative References
	[RFC1897] Hinden, R. and J. Postel, "IPv6 Testing Address		[RFC1897] Hinden, R. and J. Postel, "IPv6 Testing Address
	Allocation", RFC 1897, January 1996.		Allocation", RFC 1897, January 1996.
	[RFC2471] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address		[RFC2471] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address
	Allocation", RFC 2471, December 1998.		Allocation", RFC 2471, December 1998.
			[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
			via IPv4 Clouds", RFC 3056, February 2001.
	[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix		[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
	Reserved for Documentation", RFC 3849, July 2004.		Reserved for Documentation", RFC 3849, July 2004.
	[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky,		[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky,
	"Routing Policy Specification Language next generation		"Routing Policy Specification Language next generation
	(RPSLng)", RFC 4012, March 2005.		(RPSLng)", RFC 4012, March 2005.
	[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.
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, February 2006.		Architecture", RFC 4291, February 2006.
	[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through		[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
	Network Address Translations (NATs)", RFC 4380,		Network Address Translations (NATs)", RFC 4380,
	February 2006.		February 2006.
	6.2. Informative References		7.2. Informative References
	[RFC2772] Rockell, R. and B. Fink, "6Bone Backbone Routing		[RFC2772] Rockell, R. and B. Fink, "6Bone Backbone Routing
	Guidelines", RFC 2772, February 2000.		Guidelines", RFC 2772, February 2000.
	[RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address		[RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address
	Allocation) Phaseout", RFC 3701, March 2004.		Allocation) Phaseout", RFC 3701, March 2004.
	[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed		[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
	Networks", BCP 84, RFC 3704, March 2004.		Networks", BCP 84, RFC 3704, March 2004.
	[RFC3964] Savola, P. and C. Patel, "Security Considerations for		[RFC3964] Savola, P. and C. Patel, "Security Considerations for
	6to4", RFC 3964, December 2004.		6to4", RFC 3964, December 2004.
	Author's Address		Author's Address
	Marc Blanchet		Marc Blanchet
	Viagenie		Viagenie
	Email: Marc.Blanchet@viagenie.ca		Email: Marc.Blanchet@viagenie.ca
	Intellectual Property Statement		Full Copyright Statement
			Copyright (C) The IETF Trust (2007).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
			THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
			OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
			THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Intellectual Property
	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 Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the 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; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 8, line 29		skipping to change at page 8, line 45
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	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 that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Disclaimer of Validity
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement
	Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 29 change blocks.
	62 lines changed or deleted		99 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/