draft-ietf-ngtrans-harden-00.txt		draft-ietf-ngtrans-harden-01.txt
	INTERNET DRAFT R. Rockell		INTERNET DRAFT R. Rockell
	NGTRANS WG Sprint		NGTRANS WG Sprint
	Category: Informational B. Fink		Category: Informational B. Fink
	Expires December 1999 ESNet		Expires December 1999 ESNet
	A. Durand
	IMAG
	B. Buclin
	AT&T Labs Europe
	6Bone Hardening Effort		6Bone Backbone Routing Guildelines
	<draft-ietf-ngtrans-harden-00.txt>		<draft-ietf-ngtrans-harden-01.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet Draft and is in full conformance with all		This document is an Internet Draft and is in full conformance with all
	provisions of Section 10 of RFC2026.		provisions of Section 10 of RFC2026.
	Internet Drafts are working documents of		Internet Drafts are working documents of
	the Internet Engineering Task Force (IETF), its Areas, and it Working		the Internet Engineering Task Force (IETF), its Areas, and it Working
	Groups. Note that other groups may also distribute working documents as		Groups. Note that other groups may also distribute working documents as
	Internet Drafts.		Internet Drafts.
	skipping to change at line 49		skipping to change at line 45
	1. Abstract		1. Abstract
	The 6Bone is an Ipv6 testbed to assist in the evolution and deployment		The 6Bone is an Ipv6 testbed to assist in the evolution and deployment
	of IPv6. Because of this, it is important that the core backbone		of IPv6. Because of this, it is important that the core backbone
	of the IPv6 network maintain stability, and that all operators have		of the IPv6 network maintain stability, and that all operators have
	a common set of rules and guildelines by which to deploy IPv6 routing		a common set of rules and guildelines by which to deploy IPv6 routing
	equipment. This document provides a set of guildelines for all IPv6		equipment. This document provides a set of guildelines for all IPv6
	routing equipment operators to use as a reference for efficient and stable		routing equipment operators to use as a reference for efficient and stable
	deployment of IPv6 routing systems. As the complexity of the 6Bone grows,		deployment of IPv6 routing systems. As the complexity of the 6Bone grows,
	the adherence to a common set of rules becomes increasingly important in		the adherence to a common set of rules becomes increasingly important in
	order for an efficient backbone to exist.		order for an efficient, scalable backbone to exist.
	This document uses BGP4+ as the currently accepted EGP.		This document uses BGP4+ as the currently accepted EGP.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC 2119].		document are to be interpreted as described in [RFC 2119].
	2. Scope of this document.		2. Scope of this document.
	This document is a best-practices document aimed at all entities which		This document is a best-practices document aimed at all entities which
	skipping to change at line 91		skipping to change at line 87
	8) yet undefined unicast prefixes (from a different /3 prefix)		8) yet undefined unicast prefixes (from a different /3 prefix)
	9) inter-site links issues		9) inter-site links issues
	10) aggregation & advertisement issues		10) aggregation & advertisement issues
	3.1 Link-local prefix		3.1 Link-local prefix
	This link-local prefix (FE80::/10) MUST NOT be advertised through either an		This link-local prefix (FE80::/10) MUST NOT be advertised through either an
	IGP or an EGP.		IGP or an EGP. Under no circumstance should this prefix be seen in the
			6Bone backbone routing table.
	By definition, the link-local prefix has a scope limited to a specific link.		By definition, the link-local prefix has a scope limited to a specific link.
	Since the prefix is the same on all IPv6 links, advertising it in any		Since the prefix is the same on all IPv6 links, advertising it in any
	routing protocol does not make sense and, worse, may introduce nasty error		routing protocol does not make sense and, worse, may introduce nasty error
	conditions.		conditions.
	Well known cases where link-local prefixes could be advertised by mistake		Well known cases where link-local prefixes could be advertised by mistake
	include, but are not limited to:		include, but are not limited to:
	- a router advertising all directly connected network prefixes including the		- a router advertising all directly connected network prefixes including the
	skipping to change at line 132		skipping to change at line 129
	operational problems).		operational problems).
	3.2 Site-local prefixes		3.2 Site-local prefixes
	Site local prefixes (in the FEC0::/10 range) MAY be advertised by IGP's or		Site local prefixes (in the FEC0::/10 range) MAY be advertised by IGP's or
	EGP's within a site. The precise definition of a site is ongoing work		EGP's within a site. The precise definition of a site is ongoing work
	discussed in the IPng working group, but should generally include a group of		discussed in the IPng working group, but should generally include a group of
	nodes that are operating under one administrator or group of		nodes that are operating under one administrator or group of
	administrators, or a group of nodes which are used for a common purpose.		administrators, or a group of nodes which are used for a common purpose.
	Site-local prefixes MUST NOT be advertised to transit pNLAs, pTLAs, or		Site-local prefixes MUST NOT be advertised across transit pNLAs, pTLAs, or
	leaf-sites.		leaf-sites.
	Again, should site-local prefixes be leaked unwantedly outside of a given		Again, should site-local prefixes be leaked unwantedly outside of a given
	site, it is the responsibility of the site to fix the problem in a timely		site, it is the responsibility of the site to fix the problem in a timely
	manner, either through filters, or via other means which remove the		manner, either through filters, or via other means which remove the
	operational impact that those prefixes had on the peering sites involved.		operational impact that those prefixes had on the peering sites involved.
	However, every site SHOULD filter not only outbound on their EGP, but also		However, every site SHOULD filter not only outbound on their EGP, but also
	inbound, in order to ensure proper routing announcements are not only sent,		inbound, in order to ensure proper routing announcements are not only sent,
	but also received.		but also received.
	skipping to change at line 229		skipping to change at line 226
	are discussed in section 4, Routing policies, below.		are discussed in section 4, Routing policies, below.
	3.9 Inter-site links		3.9 Inter-site links
	Global IPv6 addresses must be used for the end points of inter-site links.		Global IPv6 addresses must be used for the end points of inter-site links.
	In particular, IPv4 compatible addresses MUST NOT be used for tunnels.		In particular, IPv4 compatible addresses MUST NOT be used for tunnels.
	Prefixes for inter-site links MUST NOT be injected in the global routing		Prefixes for inter-site links MUST NOT be injected in the global routing
	tables.		tables.
	3.10 Aggregation & advertisement issues.		3.10 6to4 Prefix (2010::/16)
			The 6to4 prefix, or some portion thereof, MAY be announced
			by any pTLA which has a current implementation of 6to4 in their IPv6
			network. However, as 6to4 implementors gain more operational
			experience, it MAY be necessary to change this in some way.
			At the time of the writing of this docuement, any pTLA MAY announce
			the 6to4 prefix into global EBGP. However, in order to announce this
			block, the pTLA MUST have a 6to4 router active, sourcing this prefix
			announcement.
			3.11 Aggregation & advertisement issues.
	Route aggregation MUST be performed by any border router talking EGP with		Route aggregation MUST be performed by any border router talking EGP with
	any other IPv6 sites.		any other IPv6 sites. More-specifics MUST NOT be leaked into or across the
			IPv6 6Bone backbone.
	4. Routing Policies		4. Routing Policies
	Leaf sites or pNLAs MUST only advertise to an upstream provider the		Leaf sites or pNLAs MUST only advertise to an upstream provider the
	prefixes assigned by that provider. Advertising a prefix assigned by another		prefixes assigned by that provider. Advertising a prefix assigned by another
	provider to a provider is not acceptable, and breaks the aggregation model.		provider to a provider is not acceptable, and breaks the aggregation model.
	A site MUST not advertise a prefix from another provider to a provider as a		A site MUST not advertise a prefix from another provider to a provider as a
	way around the multi-homing problem.		way around the multi-homing problem.
	To clarify, if one has two upstream pNLA or pTLA providers, (A and B for		To clarify, if one has two upstream pNLA or pTLA providers, (A and B for
	this example), one MUST only announce the prefix delegated to one by provider		this example), one MUST only announce the prefix delegated to one by provider
	A to provider A, and one MUST only announce the prefeix delegated by one		A to provider A, and one MUST only announce the prefeix delegated by one
	from provider B upstream to provider B. There exists no circumstance where		from provider B upstream to provider B. There exists no circumstance where
	this should be violated, as it breaks the aggregation model, and could		this should be violated, as it breaks the aggregation model, and could
	globally affect routing decisions if downstreams are able to leak other		globally affect routing decisions if downstreams are able to leak other
	providers' more specific delegations up to a pTLA.		providers' more specific delegations up to a pTLA. As the IPNG working group
			hashes through the Multi-Homing Problem, there may be a need to alter this
			rule slightly, to test new strategies for deployment. However, in the case
			of current specifications at the time of this writing, there is no reason to
			advertise more specifics, and pTLA's MUST adhere to the current aggregation
			model.
	Site border routers for pNLA or leaf sites MUST NOT advertise prefixes more		Site border routers for pNLA or leaf sites MUST NOT advertise prefixes more
	specific (longer) than the prefix that was allocated by their upstream		specific (longer) than the prefix that was allocated by their upstream
	provider.		provider.
	All pTLAs MUST NOT advertise prefixes longer than a given pTLA		All pTLAs MUST NOT advertise prefixes longer than a given pTLA
	delegation (currently /24 or /28) to other pTLAs unless special peering		delegation (currently /24 or /28) to other pTLAs unless special peering
	arrangements are implemented. When such special peering aggreements are in		arrangements are implemented. When such special peering aggreements are in
	place between any two or more pTLAs, care MUST be taken not to leak the more		place between any two or more pTLAs, care MUST be taken not to leak the more
	specifics to other pTLAs not participating in the peering aggreement. pTLAs		specifics to other pTLAs not participating in the peering aggreement. pTLAs
End of changes.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/