< draft-ietf-ipngwg-scoped-routing-01.txt		draft-ietf-ipngwg-scoped-routing-02.txt >
			IPNGWG Working Group B. Haberman
			Internet Draft Nortel Networks
			draft-ietf-ipngwg-scoped-routing-02.txt
			November 1999
			Expires May 2000
	INTERNET DRAFT Brian Haberman		Routing of Scoped Addresses
	April 1999 IBM		in the Internet Protocol Version 6 (IPv6)
	Routing of Scoped Addresses
	in the Internet Protocol Version 6 (IPv6)
	<draft-ietf-ipngwg-scoped-routing-01.txt>
	Status of This Memo
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC 2026.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working
	groups. Note that other groups may also distribute working documents
	as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six
	months, and may be updated, replaced, or obsoleted by other documents
	at any time. It is not appropriate to use Internet-Drafts as
	reference material, or to cite them other than as a ``working draft''
	or ``work in progress.''
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	Abstract
	This document outlines a mechanism for generating routing tables that
	include scoped IPv6 addresses. It defines a set of
	rules for routers to implement in order to forward scoped unicast and
	multicast addresses regardless of the routing protocol. It should be
	noted that these rules will apply to all scoped addresses.
	Contents
	1. Introduction 1
	2. Assumptions and Definitions 1
	3. Single Site Routing 1
	4. Site Boundary Unicast Routing 2
	4.1. Routing Protocols . . . . . . . . . . . . . . . . . . . . 2
	4.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 4
	5. Scoped Multicast Routing 5
	5.1. Routing Protocols . . . . . . . . . . . . . . . . . . . . 5
	5.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 5
	6. Protocol Impact 6
	1. Introduction
	This document defines a set of rules for the generation of forwarding
	tables that contain scoped addresses. This document describes the
	handling of scoped addresses for both single site and
	site boundary routers. Ideally, these concepts should be included in
	followup drafts of IPv6 routing protocols.
	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 [RFC 2119].
	2. Assumptions and Definitions
	This document makes several assumptions concerning sites :
	- Site boundaries cut through nodes
	- Site boundaries are identical for unicast and multicast traffic
	- A single interface can only be in one site
	- Each interface participating in a site has a site identifier
	- In the absence of explicit configuration, all site identifiers on
	a node default to the same value
	A single site router is defined as a router configured with the same
	site identifier on all interfaces. A site boundary router is defined
	as a router that has at least 2 distinct site identifiers configured.
	This could include a router connected to 2 distinct sites or a router
	connected to 1 site and a separate global network (Figure ??).
	3. Single Site Routing
	In a single site router, a routing protocol
	can advertise and route all addresses and prefixes on all interfaces.
	This configuration does not require any special handling for site
	local addresses. The reception and transmission of site local
	addresses is handled in the same manner as globally scoped addresses.
	This applies to both unicast and multicast routing protocols.
	* *
	* *
	* Site ID = X *
	* *
	* *
	+-*---|--------|---*-+
	| * i/f 1 i/f 2 * |
	| **************** |
	| |
	| |
	| Router |
	***************** *******************
	| * * |
	Site ID = Y - i/f 3 * * i/f 4 - Site ID = Default
	| * * |
	***************** *******************
	+--------------------+
	Figure 1: Multi-Sited Router		Status of this Memo
	4. Site Boundary Unicast Routing		This document is an Internet-Draft and is in full conformance with all
			provisions of Section 10 of RFC2026.
	With respect to site boundaries,		Internet-Drafts are working documents of the Internet Engineering Task
	routers must consider which interfaces a packet can be transmitted on		Force (IETF), its areas, and its working groups. Note that other groups
	as well as control the propagation of routing information specific to		may also distribute working documents as Internet-Drafts. Internet-
	the site. This includes controlling which prefixes can be advertised		Drafts are draft documents valid for a maximum of six months and may be
	on an interface.		updated, replaced, or obsoleted by other documents at any time. It is
			inappropriate to use Internet- Drafts as reference material or to cite
			them other than as "work in progress."
	4.1. Routing Protocols		The list of current Internet-Drafts can be accessed at
			http://www.ietf.org/ietf/1id-abstracts.txt.
	When a routing protocol determines that it is a site boundary router,		The list of Internet-Draft Shadow Directories can be accessed at
	it must perform additional work in order to protect inter site		http://www.ietf.org/shadow.html.
	integrity and still maintain intra site connectivity.
	In order to maintain connectivity, the routing protocol must be		Abstract
	able to create forwarding information for the global prefixes as well
	as for all of the site prefixes for each of its attached sites. The
	most straight forward way of doing this is to create up to (n + 1)
	routing tables; one for the global prefixes, if any, and one for each
	of the (n) sites.
	To protect inter site integrity, routers must be selective in the		This document outlines a mechanism for generating forwarding tables
	forwarding information that is shared with neighboring routers.		that include scoped IPv6 addresses. It defines a set of rules for
	Routing protocols routinely transmit their routing information to		routers to implement in order to forward packets addressed to scoped
	neighboring routers. When a router is transmitting this routing		unicast or multicast addresses regardless of the routing protocol.
	information, it must not include any information about sites other		These rules apply to all scoped addresses.
	than the site defined on the interface used to reach a neighbor.
	* *		1.
	* *		Introduction
	* Site ID = X *
	* *
	* *
	+-*---|--------|---*-+
	| * i/f 1 i/f 2 * |
	| **************** |
	| |
	| |
	| Router |
	***************** *******************
	| * * |
	Site ID = Y - i/f 3 * * i/f 4 - Site ID = Default
	| * * |
	***************** *******************
	+--------------------+
	i/f 1 : global prefix = 3FFE:20::/64		This document defines a set of rules for the generation of forwarding
	site prefix = FEC0:0:0:N/64		table entries for scoped addresses. These rules will describe the
			handling of scoped addresses for both single site and site boundary
			routers. These rules apply to all routing protocols that support IPv6
			addresses.
	i/f 2 : no global prefix		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	site prefix = FEC0:0:0:K/64		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC 2119].
	i/f 3 : global prefix = 3FFE:40::/64		2.
	site prefix = FEC0:0:0:M/64		Assumptions and Definitions
	i/f 4 : global prefix = 3FFE:80::/64		This document makes several assumptions concerning sites:
	no site prefix
	Figure 2: Routing Information Exchange		- Links belong to at most one site
			- Interfaces belong to the site of the attached link, if any
	As an example, the router in Figure ?? must advertise routing		Haberman 1
	information on four interfaces. The information advertised is as		- Nodes are a part of all sites which their interfaces belong to,
	follows :		and no other sites
			- Site boundaries are identical for unicast and multicast traffic
			- A single interface can be in at most one site
			- Each interface participating in a site has a site identifier
			- In the absence of explicit configuration, all site identifiers on
			a node default to the same value
	- Interface 1		A single site router is defined as a router configured with the same
			site identifier on all interfaces. A site boundary router is defined
			as a router that has at least 2 distinct site identifiers.
	* All global prefixes (3FFE:20::/64, 3FFE:40::/64, and		* *
	3FFE:80::/64)		* *
			* Site ID = X *
			* *
			+-*---|-------|---*-+
			| * i/f 1 i/f 2 * |
			| *************** |
			| |
			| |
			| Router |
			******************* *******************
			| * * |
			Site ID = Y -i/f 3 * * i/f 4- Site ID = Default
			| * * |
			******************* *******************
			+-------------------+
	* Site prefix FEC0:0:0:N/64		Figure 1: Multi-Sited Router
	* Site prefix FEC0:0:0:K/64		3.
			Single Site Routing
	- Interface 2		In a single site router, a routing protocol can advertise and route all
			addresses and prefixes, except the link-local prefixes, on all
			interfaces. This configuration does not require any special handling
			for site local addresses. The reception and transmission of site local
			addresses is handled in the same manner as globally scoped addresses.
			This applies to both unicast and multicast routing protocols.
	* All global prefixes (3FFE:20::/64, 3FFE:40::/64, and		4.
	3FFE:80::/64)		Site Boundary Unicast Routing
	* Site prefix FEC0:0:0:N/64		With respect to site boundaries, routers must consider which interfaces
			a packet can be transmitted on as well as control the propagation of
			routing information specific to the site. This includes controlling
			which prefixes can be advertised on an interface.
	* Site prefix FEC0:0:0:K/64		4.1 Routing Protocols
	- Interface 3		When a routing protocol determines that it is a site boundary router,
			it must perform additional work in order to protect inter site
			integrity and still maintain intra site connectivity.
	* All global prefixes (3FFE:20::/64, 3FFE:40::/64, and		Haberman 2
	3FFE:80::/64)		In order to maintain connectivity, the routing protocol must be able to
			create forwarding information for the global prefixes as well as for
			all of the site prefixes for each of its attached sites. The most
			straightforward way of doing this is to create up to (n+1) forwarding
			tables; one for the global prefixes, if any, and one for each of the
			(n) sites.
	* Site prefix FEC0:0:0:M/64		To protect inter site integrity; routers must be selective in the
			forwarding information that is shared with neighboring routers.
			Routing protocols routinely transmit their routing information to its
			neighboring routers. When a router is transmitting this routing
			information, it must not include any information about sites other than
			the site defined on the interface used to reach a neighbor.
	- Interface 4		As an example, the router in Figure 1 must advertise routing
			information on four interfaces. The information advertised is as
			follows:
	* All global prefixes (3FFE:20::/64, 3FFE:40::/64, and		- Interface 1
	3FFE:80::/64)		- All global prefixes
			- All site prefixes learned from Interfaces 1 and 2
			- Interface 2
			- All global prefixes
			- All site prefixes learned from Interfaces 1 and 2
			- Interface 3
			- All global prefixes
			- All site prefixes learned from Interface 3
			- Interface 4
			- All global prefixes
			- No site prefixes
	By imposing advertisement rules, site integrity is maintained by		By imposing advertisement rules, site integrity is maintained by
	keeping all site routing information contained within the site.		keeping all site routing information contained within the site.
	4.2. Packet Forwarding		4.2 Packet Forwarding
	In addition to the extra cost of generating additional		In addition to the extra cost of generating additional forwarding
	forwarding information for each site, site boundary routers must also		information for each site, site boundary routers must also do some
	do some additional checking when forwarding packets that contain site		additional checking when forwarding packets that contain site local
	local addresses.		addresses.
	If a packet being forwarded contains a		If a packet being forwarded contains a site local destination address,
	site local destination address, regardless of the scope of the source		regardless of the scope of the source address, the router must perform
	address, the router must perform the following :		the following:
	- Lookup incoming interface's site identifier		- Lookup incoming interface's site identifier
	- Perform route lookup for destination address in arrival		- Perform route lookup for destination address in arrival
	interfaces site scoped routing table		interface's site scoped routing table
	If a packet being forwarded contains a site local source		If a packet being forwarded contains a site local source address and a
	address and a globally scoped destination address, the following must		global scoped destination address, the following must be performed:
	be performed :
	- Lookup outgoing interface's site identifier		- Lookup outgoing interface's site identifier
			- Compare inbound and outbound interfaces' site identifiers
	- Compare inbound and outbound interfaces' site identifiers		If the site identifiers match, the packet can be forwarded. If they do
			not match, an ICMPv6 destination unreachable message must be sent to
	If the site identifiers match, the		Haberman 3
	packet can be forwarded. If they do not match, an ICMPv6 destination		the sender with a code value, code = 2 (beyond scope of source
	unreachable message must be sent to the sender with a new code value,		address).
	code = 5 (Scope Mismatch).
	This ICMPv6 message will indicate that the destination address is not
	reachable with the specified source address.
	5. Scoped Multicast Routing		5.
			Scoped Multicast Routing
	With IPv6 multicast, there are multiple scopes		With IPv6 multicast, there are multiple scopes supported. Multicast
	supported. Multicast routers must be able to control the propagation		routers must be able to control the propagation of scoped packets based
	of scoped packets based on administratively configured boundaries.		on administratively configured boundaries.
	5.1. Routing Protocols		5.1 Routing Protocols
	Multicast routing protocols must follow the same rules as the unicast		Multicast routing protocols must follow the same rules as the unicast
	protocols. They will be required to maintain information about		protocols. They will be required to maintain information about global
	global prefixes as well as information about all scope boundaries		prefixes as well as information about all scope boundaries that exist
	that pass through the router. Multicast protocols that rely on		on the router.
	underlying unicast protocols (i.e. PIM) will not suffer as much of a
	performance impact since the unicast protocol will handle the
	forwarding table generation. They must be able to handle the
	additional scope boundaries used in multicast addresses. Multicast
	protocols that generate and
	maintain their own routing tables will have to perform the additional
	route calculations for scope. All multicast protocols will be forced
	to handle 14 additional scoping identifiers above the site
	identifiers supported in IPv6 unicast addresses.
	5.2. Packet Forwarding		Multicast protocols that rely on underlying unicast protocols for route
			exchange (i.e. PIM, MOSPF) will not suffer as much of a performance
			impact since the unicast protocol will handle the forwarding table
			generation. They must be able to handle the additional scope
			boundaries used in multicast addresses.
	The forwarding rules for multicast can be described by the following		Multicast protocols that generate and maintain their own routing tables
	combinations :		will have to perform the additional route calculations for scope
			boundaries. All multicast protocols will be forced to handle fourteen
			additional scooping identifiers above the site identifiers supported in
			IPv6 unicast addresses.
	- Global multicast destination address / Global unicast source		5.2 Packet Forwarding
	address
	- Global multicast destination address / Site local unicast source		The following combinations describe the forwarding rules for multicast:
	address
	- Scoped multicast destination address / Global unicast source		- Global multicast destination / Global unicast source
	address		- Global multicast destination / Site local unicast source
			- Scoped multicast destination / Global unicast source
			- Scoped multicast destination / Site local unicast source
	- Scoped multicast destination address / Site local unicast source		The first combination requires no special processing over what is
	address		currently in place for global IPv6 multicast. The remaining
			combinations should result in the router performing the same
			identifiers check as outlined for the site local unicast addresses.
			Since IPv6 multicast supports fifteen unique multicast scopes, it is
			assumed that scopes 0x1 through 0x4 are strictly less than the unicast
			site scope, scope 0x5 (site) is equal to the unicast site scope, scopes
			0x6 through 0xd are strictly greater than the unicast site scope and
			strictly less than the unicast global scope, and scope 0xe is equal to
			the unicast global scope.
	The first combination requires no special		6.
	processing over what is currently in place for global IPv6 multicast.		Protocol Impact
	Combinations 2,3, and 4 should result in the router performing the
	same identifiers check as outlined for site local unicast addresses.
	Since IPv6 supports fifteen unique multicast scopes, it is assumed
	that scopes 0x1 through 0x4 are strictly less than
	the unicast site scope, scope 0x5 (site) is equal to the unicast site
	scope, scopes 0x6 through 0xd are strictly greater than the unicast
	site scope and strictly less than the unicast global scope, and scope
	0xe is equal to the unicast global scope.
	6. Protocol Impact		The performance impact on routing protocols is obvious. Routers
			implementing scoped address support will be forced to perform an
			additional check in the main forwarding path to determine if the source
			address is a site-local address. This will add overhead to the
			processing of every packet flowing through the router. In addition,
	The performance impact on routing protocols is obvious.		Haberman 4
	Routers implementing scoped address support will be forced to perform		there will be some storage overhead for the scope identifiers. If
	an additional check in the main forwarding path to		scoped addresses are going to be realized, this performance impact may
	determine if the source address is scoped. This will add overhead to		be acceptable.
	the processing of every packet flowing through the router. In
	addition, there will be some storage overhead for
	the scope identifiers. If scoped addresses are going to be realized,
	this performance impact may be acceptable.
	References		7.
			Security Considerations
	[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate		This document specifies a set of guidelines that allow routers to
	Requirement Levels", RFC 2119, BCP14, March 1997.		prevent site-specific information from leaking out of each site. If
			site boundary routers allow site routing information to be forwarded
			outside of the site, the integrity of the site could be compromised.
	Security Considerations		8.
			References
	This document specifies a set of guidelines that allow routers to		[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
	prevent site		Requirement Levels", RFC 2119, BCP14, March 1999.
	specific information from leaking out of each site. If site boundary
	routers allow site routing information to be forwarded outside of the
	site, the integrity of the site could be compromised.
	Acknowledgements		Acknowledgements
	I would like to thank Thomas Narten, Steve Deering, and Erik Nordmark		The author would like to thank Thomas Narten, Steve Deering, Erik
	for their comments and reviews of this document.		Nordmark, and Matt Crawford for their comments and reviews of this
			document.
	Author's Address		Haberman 5
			Author's Address
	Brian Haberman		Brian Haberman
	IBM Corporation		Nortel Networks
	800 Park Office Drive		4309 Emperor Blvd.
	Research Triangle Park, NC 27709		Suite 200
	USA		Durham, NC 27703
	+1-919-254-2673		1-919-992-4439
	haberman@raleigh.ibm.com		Email : haberman@nortelnetworks.com
			Haberman 6
End of changes. 59 change blocks.
	269 lines changed or deleted		201 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/