< draft-ietf-ipngwg-scoping-arch-01.txt		draft-ietf-ipngwg-scoping-arch-02.txt >
	IPNGWG Working Group S. Deering		IPNGWG Working Group S. Deering
	Internet Draft Cisco Systems		Internet Draft Cisco Systems
	draft-ietf-ipngwg-scoping-arch-01.txt B. Haberman		draft-ietf-ipngwg-scoping-arch-02.txt B. Haberman
	March 2000 Nortel Networks		March 2001 Nortel Networks
	Expires September 2000 B. Zill		Expires September 2001 T. Jinmei
	Microsoft		Toshiba
			E. Nordmark
			Sun Microsystems
			A. Onoe
			Sony
			B. Zill
			Microsoft
	IP Version 6 Scoped Address Architecture		IPv6 Scoped Address Architecture
	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.
	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 other
	other groups may also distribute working documents as Internet-		groups may also distribute working documents as Internet-Drafts.
	Drafts. Internet-Drafts are draft documents valid for a maximum of		Internet-Drafts are draft documents valid for a maximum of six months
	six months and may be updated, replaced, or obsoleted by other		and may be updated, replaced, or obsoleted by other documents at any
	documents at any time. It is inappropriate to use Internet-Drafts as		time. It is inappropriate to use Internet-Drafts as reference
	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.
	Abstract		Abstract
	This document specifies the architectural characteristics, expected		This document specifies the architectural characteristics, expected
	behavior, and usage of IPv6 addresses of different scopes		behavior, textual representation, and usage of IPv6 addresses of
			different scopes.
	1. Introduction		1. Introduction
	The Internet Protocol version 6 (IPv6) introduces the concept of		Internet Protocol version 6 includes support for addresses of
	limited scope addresses to the IP lexicon. While operational		different "scope", that is, both global and non-global (e.g., link-
	practice with IPv4 has included the concept of a private address		local, site-local, etc.) addresses. While non-global addressing has
	space (net 10, etc.), the design of IPv6 incorporates such addresses		been introduced operationally in the IPv4 Internet, both in the use
	into its base architecture. This document defines terms associated		of private address space ("net 10", etc.) and with administratively
	with such addresses and describes mechanisms for their behavior.		scoped multicast addresses, the design of IPv6 formally incorporates
			Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 1
			the notion of address scope into its base architecture. This
			document specifies the architectural characteristics, expected
			behavior, textual representation, and usage of IPv6 addresses of
			different scopes.
	Deering, Haberman, Zill 1
	2. Definitions		2. Definitions
	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		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	this document are to be interpreted as described in [RFC 2119].		document are to be interpreted as described in [RFC 2119].
	3. Basic Terminology		3. Basic Terminology
	The terms link, interface, node, host, and router are defined in		The terms link, interface, node, host, and router are defined in [RFC
	[RFC 2460]. The definitions of unicast address scopes (link-local,		2460]. The definitions of unicast address scopes (link-local, site-
	site-local, and global) and multicast address scopes (node-local,		local, and global) and multicast address scopes (interface-local,
	link-local, etc.) are contained in [RFC 2373].		link-local, etc.) are contained in [ADDRARCH].
	4. Address Scope		4. Address Scope
	Every IPv6 address has a specific scope, that is, a topological		Every IPv6 address has a specific scope, that is, a topological span
	"distance" within which the address may be used as a unique		within which the address may be used as a unique identifier for an
	identifier for an interface. The scope of an address is encoded as		interface or set of interfaces. The scope of an address is encoded
	part of the address, as specified in [RFC 2373].		as part of the address, as specified in [ADDRARCH].
	For unicast addresses, there are three defined scopes:		For unicast addresses, there are three defined scopes:
	o Link-local scope, for uniquely identifying interfaces		o Link-local scope, for uniquely identifying interfaces
	within a single link only.		within (i.e., attached to) a single link only.
	o Site-local scope, for uniquely identifying interfaces		o Site-local scope, for uniquely identifying interfaces
	within a single site only. A "site" is, by intent, not		within a single site only. A "site" is, by intent, not
	rigorously defined, but is typically expected to cover a		rigorously defined, but is typically expected to cover a
	region of topology that belongs to a single organization		region of topology that belongs to a single organization
	and is located within a single geographic location, such		and is located within a single geographic location, such
	as an office, an office complex, or a campus. A personal		as an office, an office complex, or a campus. A personal
	residence may be treated as a site (for example, when the		residence may be treated as a site (for example, when the
	residence obtains Internet access via a public Internet		residence obtains Internet access via a public Internet
	service provider), or as a part of a site (for example,		service provider), or as a part of a site (for example,
	when the residence obtains Internet access via an		when the residence obtains Internet access via an
	employer's or school's site).		employer's or school's site).
	o Global scope, for uniquely identifying interfaces		o Global scope, for uniquely identifying interfaces anywhere
	anywhere in the Internet.		in the Internet.
			The IPv6 unicast loopback address, ::1, is treated as having link-
			local scope within an imaginary link to which a virtual "loopback
			interface" is attached.
			Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 2
			Anycast addresses [ADDRARCH] are allocated from the unicast address
			space and have the same scope properties as unicast addresses. All
			statements in this document regarding unicast apply equally to
			anycast.
	For multicast addresses, there are fourteen possible scopes, ranging		For multicast addresses, there are fourteen possible scopes, ranging
	from node-local to global (including both link-local and site-		from interface-local to global (including both link-local and site-
	local). A node-local multicast address serves as a unique		local). The interface-local scope spans a single interface only; a
	identifier for an interface within a single node only; such an		multicast address of interface-local scope is useful only for
	address is used only for "loopback" delivery of multicasts within a		loopback delivery of multicasts within a single node, for example, as
	single node, for example, as a form of inter-process communication		a form of inter-process communication within a computer. Unlike the
	within a computer.		unicast loopback address, interface-local multicast addresses may be
			assigned to any interface.
	Deering, Haberman, Zill 2		There is a size relationship among scopes:
	There is an ordering relationship among scopes:
	o for unicast scopes, link-local is a smaller scope than		o for unicast scopes, link-local is a smaller scope than
	site-local, and site-local is a smaller scope than		site-local, and site-local is a smaller scope than global.
	global.
	o for multicast scopes, scopes with lesser values in the		o for multicast scopes, scopes with lesser values in the
	"scop" subfield of the multicast address [RFC 2373,		"scop" subfield of the multicast address [ADDRARCH,
	section 2.7] are smaller than scopes with greater values,		section 2.7] are smaller than scopes with greater values,
	with node-local being the smallest and global being the		with interface-local being the smallest and global being
	largest.		the largest.
	However, two scopes of different size may cover the exact same		However, two scopes of different size may cover the exact same region
	region of topology, for example, a site may consist of a single		of topology. For example, a site may consist of a single link, in
	link, in which both link-local and site-local scope effectively		which both link-local and site-local scope effectively cover the same
	cover the same topological "distance".		topological span.
	5. Scope Zones		5. Scope Zones
	A scope zone, or a simply a zone, is a connected region of topology		A scope zone, or a simply a zone, is a connected region of topology
	of a given scope. For example, the set of links connected by		of a given scope. For example, the set of links connected by routers
	routers within a particular site, and the interfaces attached to		within a particular site, and the interfaces attached to those links,
	those links, comprise a single zone of site-local scope. To		comprise a single zone of site-local scope. Note that a zone is a
	understand the distinction between scopes and zones, observe that		particular instance of a topological region (e.g., AliceÆs site or
	the topological regions within two different sites are considered to		BobÆs site), whereas a scope is the size of a topological region
	be two DIFFERENT zones, but of the SAME scope.		(i.e., a site or a link or a ...).
	Addresses of a given (non-global) scope may be re-used in different
	zones of that scope. The zone to which a particular non-global
	address pertains is not encoded in the address itself, but rather is
	determined by context, such as the interface from which it is sent
	or received.
	Zones of the different scopes are defined as follows:		The zone to which a particular non-global address pertains is not
			encoded in the address itself, but rather is determined by context,
			such as the interface from which it is sent or received. Thus,
			addresses of a given (non-global) scope may be re-used in different
			zones of that scope. For example, Alice's site and Bob's site may
			each contain a node with site-local address fec0::1.
	o A node-local zone (for multicast only) consists of a		Zones of the different scopes are instantiated as follows:
	single interface on a node. [Note: node-local scope
	would have been more accurately named interface-local.]
	o A link-local zone (for unicast and multicast) consists of		Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 3
	a single link and all the interfaces attached to that		o Each interface on a node comprises a single zone of
	link.		interface-local scope (for multicast only).
	o There is a single zone of global scope (for both unicast		o Each link, and the interfaces attached to that link,
	and multicast), comprising all the links and interfaces		comprises a single zone of link-local scope (for both
	in the Internet.		unicast and multicast).
	o The boundaries of zones of scope other than node-local,		o There is a single zone of global scope (for both unicast
	link-local, and global must be defined and configured by		and multicast), comprising all the links and interfaces in
	network administrators. The only required such		the Internet.
	Deering, Haberman, Zill 3		o The boundaries of zones of scope other than interface-
	boundaries are site boundaries. A site boundary serves		local, link-local, and global must be defined and
	for both unicast and multicast.		configured by network administrators. A site boundary
			serves as such for both unicast and multicast.
	Zone boundaries are relatively static features, not changing in		Zone boundaries are relatively static features, not changing in
	response to short-term changes in topology. Thus, the requirement		response to short-term changes in topology. Thus, the requirement
	that the topology within a zone be "connected" is intended to		that the topology within a zone be "connected" is intended to include
	include links and interfaces that may be only occasionally		links and interfaces that may be only occasionally connected. For
	connected. For example, a residential node or network that obtains		example, a residential node or network that obtains Internet access
	Internet access by dial-up to an employer's site may be treated as		by dial-up to an employer's site may be treated as part of the
	part of the employer's site-local zone even when the dial-up link is		employer's site-local zone even when the dial-up link is
	disconnected. Similarly, a failure of a router, interface, or link		disconnected. Similarly, a failure of a router, interface, or link
	that causes a zone to become partitioned does not split that zone		that causes a zone to become partitioned does not split that zone
	into multiple zones; rather, the different partitions are still		into multiple zones; rather, the different partitions are still
	considered to belong to the same zone.		considered to belong to the same zone.
	Zones have the following additional properties:		Zones have the following additional properties:
	o Zone boundaries cut through nodes, not links. (There are		o Zone boundaries cut through nodes, not links. (Note that
	two exceptions: the global zone has no boundary, and the		the global zone has no boundary, and the boundary of an
	boundary of a node-local zone conceptually cuts through		interface-local zone encloses just a single interface.)
	an interface between a node and a link.)
	o Zones of the same scope cannot overlap, i.e., they can		o Zones of the same scope cannot overlap, i.e., they can
	have no links or interfaces in common.		have no links or interfaces in common.
	o A zone of a given scope (less than global) falls		o A zone of a given scope (less than global) falls
	completely within zones of larger scope, i.e., a smaller		completely within zones of larger scope, i.e., a smaller
	scope zone cannot include more topology than any larger		scope zone cannot include more topology than any larger
	scope zone with which it shares any links or interfaces.		scope zone with which it shares any links or interfaces.
	Each interface belongs to one node-local zone, one link-local zone,		Each interface belongs to exactly one zone of each possible scope.
	one site-local zone, and the global zone. Each link belongs to one
	link-local zone, one site-local zone, and the global zone. An
	interface or link only belongs to additional (i.e., multicast) zones
	if it falls within the configured boundaries of such additional
	zones.
	6. Zone Indices		6. Zone Indices
	Because the same address of a given (non-global) scope can be re-		Considering the fact that the same non-global address may be in use
	used in different zones of that scope, a node must have a means --		in more than one zone of the same scope (e.g., the use of site-local
	other than examining the address itself -- of associating non-global		address fec0::1 in both Alice's site and Bob's site), and that a node
	addresses with particular zones when sending, receiving, or		may have interfaces attached to different zones of the same scope
	forwarding packets containing such addresses. This is accomplished
	by assigning a local "zone index" to each zone to which a node is		Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 4
	attached. Each attached zone of the same scope must be assigned a		(e.g., having one interface attached to Alice's site and another to
	different index value; attached zones of different scopes can re-use		Bob's site), a node requires an internal means of identifying to
	the same index values.		which zone a non-global address belongs. This is accomplished by
			assigning, within the node, a distinct "zone index" to each zone of
			the same scope to which that node is attached, and allowing all
			internal uses of an address to be qualified by a zone index.
	Deering, Haberman, Zill 4
	The assignment of zone indices is illustrated in the example in the		The assignment of zone indices is illustrated in the example in the
	figure below:		figure below:
	---------------------------------------------------------------		---------------------------------------------------------------
	| a node |		| a node |
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	| |		| |
	| /--site1--\ /--------------site2--------------\ /--site3--\ |		| /--------------------site1--------------------\ /--site2--\ |
	| |		| |
	| /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ |		| /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ |
	| |		| |
	| intf1 intf2 intf3 intf4 intf5 |		| /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ |
	---------------------------------------------------------------		---------------------------------------------------------------
	: | | | |		: | | | |
	: | | | |		: | | | |
	: | | | |		: | | | |
	the ================= a point- a		(imaginary ================= a point- a
	loopback an Ethernet to-point tunnel		loopback an Ethernet to-point tunnel
	link link		link) link
	Figure 1 : Zone Indices Example		Figure 1 : Zone Indices Example
	This example node has five interfaces:		This example node has five interfaces:
	o A loopback interface, which can be thought of as an		o A loopback interface to the imaginary loopback link (a
	interface to a phantom link -- the "loopback link" --		phantom link that goes nowhere),
	that goes nowhere,
	o Two interfaces to the same Ethernet,		o Two interfaces to the same Ethernet,
	o An interface to a point-to-point link, and		o An interface to a point-to-point link, and
	o A tunnel interface (e.g., the abstract endpoint of an		o A tunnel interface (e.g., the abstract endpoint of an
	IPv6-over-IPv6 tunnel [RFC 2473], presumably established		IPv6-over-IPv6 tunnel [RFC 2473], presumably established
	over either the Ethernet or the point-to-point link.)		over either the Ethernet or the point-to-point link.)
	It is thus attached to five node-local zones, identified by the		It is thus attached to five interface-local zones, identified by the
	interface indices 1 through 5.		interface indices 1 through 5.
	Because the two Ethernet interfaces are attached to the same link,		Because the two Ethernet interfaces are attached to the same link,
	the node is attached to only four link-local zones, identified by		the node is attached to only four link-local zones, identified by
	link indices 1 through 4.		link indices 1 through 4.
	It is attached to three site-local zones: one imaginary one to which		Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 5
	the loopback interface belongs, one to which the Ethernet and the		It is attached to two site-local zones: one to which the loopback
	point-to-point link belong, and one to which the tunnel belongs		link, the Ethernet, and the point-to-point link belong, and one to
	(perhaps because it is a tunnel to another organization). These		which the tunnel belongs (perhaps because it is a tunnel to another
	site-local zones are identified by the site indices 1 through 3.		organization). These site-local zones are identified by the site
			indices 1 and 2.
			Note that each attached zone of the same scope must be assigned a
			different index value, whereas attached zones of different scopes can
			re-use the same index.
	Deering, Haberman, Zill 5
	The zone indices are strictly local to the node. For example, the		The zone indices are strictly local to the node. For example, the
	node on the other end of the point-to-point link may well be using		node on the other end of the point-to-point link may well be using
	entirely different interface, link, and site index values for that		entirely different interface, link, and site index values for that
	link.		link.
	The zone index values are arbitrary. An implementation may use any		An implementation should also support the concept of a "default" zone
	value it chooses to label a zone as long as it maintains the		for each scope. It is convenient to reserve the index value zero, at
	requirement that the index value of each attached zone of the same		each scope, to mean "use the default zone". This default index can
	scope must be unique within the node. Implementations choosing to		also be used as the zone qualifier for an address for which the node
	follow the recommended basic API [RFC 2553] will also want to		is attached to only one zone, e.g., when using global addresses.
	restrict their index values to those that can be represented by the
	sin6_scope_id field of a sockaddr_in6.
	An implementation may also support the concept of a "default" zone
	for each scope. It is convenient to reserve the index value zero,
	at each scope, to mean "use the default zone". This default index
	can also be used to identify the zone for any scopes for which the
	node has not assigned any indices, such as the various multicast-
	only scopes.
	There is at present no way for a node to automatically determine		There is at present no way for a node to automatically determine
	which of its interfaces belongs to the same zones, e.g., the same		which of its interfaces belong to the same zones, e.g., the same link
	link or the same site. In the future, protocols may be developed to		or the same site. In the future, protocols may be developed to
	determine that information. In the absence of such protocols, an		determine that information. In the absence of such protocols, an
	implementation must provide a means for manual assignment and/or		implementation must provide a means for manual assignment and/or
	reassignment of zone indices. Furthermore, to avoid the need to		reassignment of zone indices. Furthermore, to avoid the need to
	perform manual configuration in most cases, an implementation		perform manual configuration in most cases, an implementation should,
	should, by default, initially assign zone indices as follows:		by default, initially assign zone indices as follows, and only as
			follows:
	o A unique interface index for each interface		o A unique interface index for each interface
	o A unique link index for each interface		o A unique link index for each interface
	o A single site index for all interfaces		o A unique subnet (multicast "scop" value 3) index for each
			interface
	Then, manual configuration would be necessary only for the less		Then, manual configuration would be necessary only for the less
	common cases of nodes with multiple interfaces to a single link,		common cases of nodes with multiple interfaces to a single link or a
	interfaces to different sites, or interfaces to zones of different		single subnet, interfaces to different sites, or interfaces to zones
	(multicast-only) scopes.		of different (multicast-only) scopes.
			Thus, the default zone index assignments for the example node from
			Figure 1 would be as illustrated in Figure 2, below. Manual
			configuration would then be required to, for example, assign the same
			link index to the two Ethernet interfaces as shown in Figure 1.
			Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 6
			---------------------------------------------------------------
			| a node |
			| |
			| |
			| |
			| |
			| |
			| /-subnet1-\ /-subnet2-\ /-subnet3-\ /-subnet4-\ /-subnet5-\ |
			| |
			| /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ |
			| |
			| /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ |
			---------------------------------------------------------------
			: | | | |
			: | | | |
			: | | | |
			(imaginary ================= a point- a
			loopback an Ethernet to-point tunnel
			link) link
			Figure 2 : Example of Default Zone Indices
			As well as initially assigning zone indices, as specified above, an
			implementation should automatically select a default zone for each
			scope for which there is more than one choice, to be used whenever an
			address is specified without a zone index (or with a zone index of
			zero). For instance, in the example shown in Figure 2, the
			implementation might automatically select intf2, link2, and subnet2
			as the default zones for each of those three scopes. (Perhaps the
			selection algorithm is to choose the first zone that includes an
			interface other than the loopback interface as the default for each
			scope.) A means must also be provided for manually assigning the
			default zone for a scope, overriding any automatic assignment.
			Because the unicast loopback address, ::1, may not be assigned to
			any interface other than the loopback interface, it is recommended
			that whenever ::1 is specified without a zone index, or with the
			default zone index, that it be interpreted as belonging to the
			loopback link-local zone, regardless of which link-local zone has
			been selected as the default. If this is done, then in the common
			case of nodes with only a single non-loopback interface (e.g., a
			single Ethernet interface), it becomes possible to avoid any need
			to qualify link-local addresses with a zone index: the unqualified
			address ::1 would always refer to the link-local zone containing
			the loopback interface, and all other unqualified link-local
			addresses would refer to the link-local zone containing the non-
			loopback interface (as long as the default link-local zone were set
			to be the zone containing the non-loopback interface).
			Because of the requirement that a zone of a given scope fall
			completely within zones of larger scope (see section 5, above), if
			two interfaces are assigned to different zones of scope S, they must
			Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 7
			also be assigned to different zones of all scopes smaller than S.
			Thus, the manual assignment of distinct zone indices for one scope
			may require the automatic assignment of distinct zone indices for
			smaller scopes. For example, the manual assignment of distinct site-
			local indices 1 and 2 in the node in Figure 1 would cause the
			automatic creation of corresponding admin-local (i.e. multicast
			"scop" value 4) indices 1 and 2, because admin-local scope is smaller
			than site-local scope.
			Taking all of the above considerations in account, the complete set
			of zone indices for our example node from Figure 1 is shown in Figure
			3, below.
			---------------------------------------------------------------
			| a node |
			| |
			| |
			| |
			| |
			| |
			| /--------------------site1--------------------\ /--site2--\ |
			| |
			| /-------------------admin1--------------------\ /-admin2--\ |
			| |
			| /-subnet1-\ /-------subnet2-------\ /-subnet3-\ /-subnet4-\ |
			| |
			| /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ |
			| |
			| /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ |
			---------------------------------------------------------------
			: | | | |
			: | | | |
			: | | | |
			(imaginary ================= a point- a
			loopback an Ethernet to-point tunnel
			link) link
			Figure 3 : Complete Zone Indices Example
			Although the examples above show the zones being assigned index
			values sequentially, starting at one, the zone index values are
			arbitrary. An implementation may use any value it chooses to label a
			zone as long as it meets the requirement that the index value of each
			attached zone of the same scope be unique within the node.
			Similarly, an implementation may choose an index value other than
			zero to represent the default zone. Implementations choosing to
			follow the recommended basic API [RFC 2553] will want to restrict
			their index values to those that can be represented by the
			sin6_scope_id field of a sockaddr_in6.
			(Authors' note to selves: The Working Group seemed to be
			in favor of allowing all zone indices for all scopes to
			Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 8
			have unique values in a sin6 scope id field, e.g., by
			using the first four bits of the scope id to identify the
			scope [using the same encoding as the scop field in
			multicast addresses], and placing the zone id in the
			remaining 28 bits. This would probably be best specified
			the advanced API spec, rather than here.)
	7. Sending Packets		7. Sending Packets
	When an upper-layer protocol sends a packet to a non-global		When an upper-layer protocol sends a packet to a non-global
	destination address, the node must also identify the intended zone		destination address, it must have a means of identifying to the IPv6
	to be used for transmission.		layer the intended zone, for cases in which the node is attached to
			more than one zone of the destination address's scope.
	Deering, Haberman, Zill 6
	Note that there is one exception to the above statement: when
	sending to the IPv6 unicast loopback address, ::1, there is no
	need to identify the intended zone, even though that address is
	non-global. Conceptually, the unicast loopback address is a link-
	local address for a node's loopback interface, and is never
	assigned to any other interface. Therefore, it unambiguously
	identifies a single zone of link-scope, that being the phantom
	loopback link.
	Although identification of an outgoing interface is sufficient to		Although identification of an outgoing interface is sufficient to
	identify an intended zone (because each interface is attached to no		identify an intended zone (because each interface is attached to no
	more than one zone of each scope), that is more specific than		more than one zone of each scope), that is more specific than desired
	desired in many cases. For example, when sending to a site-local		in many cases. For example, when sending to a site-local unicast
	unicast address, from a node that has more than one interface to the		address, from a node that has more than one interface to the intended
	intended site, the upper layer protocol may not care which of those		site, the upper layer protocol may not care which of those interfaces
	interfaces is used for the transmission, but rather would prefer to		is used for the transmission, but rather would prefer to leave that
	leave that choice to the routing function in the IP layer. Thus,		choice to the routing function in the IP layer. Thus, the upper-
	the upper-layer requires the ability to specify a zone index, rather		layer requires the ability to specify a zone index, rather than an
	than an interface index, when sending to a non-global, non-loopback		interface identifier, when sending to a non-global, non-loopback
	destination address.		destination address.
	There may also be cases where the upper-layer wishes to restrict the
	choice of outgoing interface to those belonging to a zone of smaller
	scope than the destination address. For example, when sending to a
	site-local destination, the upper-layer may wish to specify a
	specific link on which the packet should be transmitted, but leave
	the choice of which specific interface to use on that link to the IP
	layer. One possible reason for such behavior is that the source
	address chosen by the upper-layer is of smaller scope than the
	destination, e.g., when using a link-local source address and a
	site-local destination address. Thus, the upper layer requires the
	ability, when sending a packet, to specify any zone of scope less
	than or equal to the scope of the destination address, including the
	case in which the destination address is of global scope. For this
	reason, an implementation might find it useful to assign a distinct
	value for each zone index, so that they are unique across all zones,
	regardless of scope.
	(Authors' note to selves: Think about distinct values
	for default at each scope level.)
	8. Receiving Packets		8. Receiving Packets
	When an upper-layer protocol receives a packet containing a non-		When an upper-layer protocol receives a packet containing a non-
	global source or destination address, the zone to which that address		global source or destination address, the zone to which that address
	pertains can be determined from the arrival interface, because the		pertains can be determined from the arrival interface, because the
	arrival interface can attached to only one zone of the same scope as		arrival interface can be attached to only one zone of the same scope
	the address under consideration.		as the address under consideration. However, it is recommended that
			the IP layer convey to the upper layer the correct zone indices for
			the arriving source and destination addresses, in addition to the
			arrival interface identifier.
	Deering, Haberman, Zill 7
	9. Forwarding		9. Forwarding
	When a router receives a packet addressed to a node other than		When a router receives a packet addressed to a node other than
	itself, it must take the zone of the destination and source		itself, it must take the zone of the destination and source addresses
	addresses into account as follows:		into account as follows:
	o The zone of the destination address is determined by the		o The zone of the destination address is determined by the
	scope of the address and arrival interface of the packet.		scope of the address and arrival interface of the packet.
	The next-hop interface is chosen by looking up the		The next-hop interface is chosen by looking up the
	destination address in a (conceptual) routing table		destination address in a (conceptual) routing table
			Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 9
	specific to that zone. That routing table is restricted		specific to that zone. That routing table is restricted
	to refer only to interfaces belonging to that zone.		to refer only to interfaces belonging to that zone.
	o After the next-hop interface is chosen, the zone of the		o After the next-hop interface is chosen, the zone of the
	source address is considered. As with the destination		source address is considered. As with the destination
	address, the zone of the source address is determined by		address, the zone of the source address is determined by
	the scope of the address and arrival interface of the		the scope of the address and arrival interface of the
	packet. If transmitting the packet on the chosen next-		packet. If transmitting the packet on the chosen next-hop
	hop interface would cause the packet to leave the zone of		interface would cause the packet to leave the zone of the
	the source address, i.e., cross a zone boundary of the		source address, i.e., cross a zone boundary of the scope
	scope of the source address, then the packet is discarded		of the source address, then the packet is discarded and an
	and an ICMP Destination Unreachable message [RFC 2463]		ICMP Destination Unreachable message [RFC 2463] with Code
	with Code 2 ("beyond scope of source address") is sent to		2 ("beyond scope of source address") is sent to the source
	the source of the packet.		of the packet.
	Note that the above procedure applies for addresses of all scopes,		Note that the above procedure applies for addresses of all scopes,
	including link-local. Thus, if a router receives a packet with a		including link-local. Thus, if a router receives a packet with a
	link-local destination address that is not one of the router's own		link-local destination address that is not one of the router's own
	link-local addresses on the arrival link, the router is expected to		link-local addresses on the arrival link, the router is expected to
	try to forward the packet to the destination on that link (subject		try to forward the packet to the destination on that link (subject to
	to successful determination of the destination's link-layer address		successful determination of the destination's link-layer address via
	via the Neighbor Discovery protocol [RFC 2461]). The forwarded		the Neighbor Discovery protocol [RFC 2461]). The forwarded packet may
	packet may be transmitted back out the arrival interface, or out any		be transmitted back out the arrival interface, or out any other
	other interface attached to the same link.		interface attached to the same link.
	A node that receives a packet addressed to itself and containing a		A node that receives a packet addressed to itself and containing a
	Routing Header with more than zero Segments Left [RFC 2460, section		Routing Header with more than zero Segments Left [RFC 2460, section
	4.4] swaps the original destination address with the next address in		4.4] swaps the original destination address with the next address in
	the Routing Header. Then the above forwarding rules are applied,		the Routing Header. Then the above forwarding rules are applied,
	using the new destination address. An implementation MUST NOT		using the new destination address where the zone of the new
	examine additional addresses in the Routing header to determine		destination address should be determined by the scope of the previous
	whether they are crossing boundaries for their scopes. Thus, it is		destination address and the interface to which the previous address
	possible, though generally inadvisable, to use a Routing Header to		belongs (which is not necessarily equal to the incoming interface).
	convey a non-global address across its associated zone boundary.		An implementation MUST NOT examine additional addresses in the
			Routing header to determine whether they are crossing boundaries for
			their scopes. Thus, it is possible, though generally inadvisable, to
			use a Routing Header to convey a non-global address across its
			associated zone boundary.
	10. Routing		10. Routing
	When a routing protocol determines that it is operating on a zone		When a routing protocol determines that it is operating on a zone
	boundary, it MUST protect inter-zone integrity and maintain intra-		boundary, it MUST protect inter-zone integrity and maintain intra-
	zone connectivity.		zone connectivity.
	Deering, Haberman, Zill 8
	In order to maintain connectivity, the routing protocol must be able		In order to maintain connectivity, the routing protocol must be able
	to create forwarding information for the global prefixes as well as		to create forwarding information for the global prefixes as well as
	for all of the zone prefixes for each of its attached zones. The		for all of the zone prefixes for each of its attached zones. The
	most straightforward way of doing this is to create (conceptual)		most straightforward way of doing this is to create (conceptual)
	forwarding tables for each specific zone.		forwarding tables for each specific zone.
	To protect inter-zone integrity routers must be selective in the		Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 10
			To protect inter-zone integrity, routers must be selective in the
	prefix information that is shared with neighboring routers. Routers		prefix information that is shared with neighboring routers. Routers
	routinely exchange routing information with neighboring routers.		routinely exchange routing information with neighboring routers.
	When a router is transmitting this routing information, it must not		When a router is transmitting this routing information, it must not
	include any information about zones other than the zones assigned to		include any information about zones other than the zones assigned to
	the interface used to transmit the information.		the interface used to transmit the information.
	* *		* *
	* *		* *
	* ----------- Site ID = X *		* =========== Site X *
	* | | *		* | | *
	+-*---|-------|-----+ *		* | | *
	| * i/f 1 i/f 2 | *		+-*----|-------|------+ *
	| * | *		| * intf1 intf2 | *
	| * i/f 5 - *		| * | *
	| *******************************		| * intf3 --- *
	| |		| * | *
	| Router |		| ***********************************
	******************* *******************		| |
	| * * |		| Router |
	Site ID = Y - i/f 3 * * i/f 4 - Site ID = Z		| |
	| * * |		********************** **********************
	******************* *******************		| * * |
	+-------------------+		Site Y --- intf4 * * intf5 --- Site Z
			| * * |
			********************** **********************
			+---------------------+
	Figure 2: Multi-Sited Router		Figure 4: Multi-Sited Router
	As an example, the router in Figure 2 must exchange routing		As an example, the router in Figure 4 must exchange routing
	information on five interfaces. The information exchanged is as		information on five interfaces. The information exchanged is as
	follows:		follows:
	o Interface 1		o Interface 1
	o All global prefixes		o All global prefixes
	o All site prefixes learned from Interfaces 1, 2, and 5		o All site prefixes learned from Interfaces 1, 2, and 3
	o Interface 2		o Interface 2
	o All global prefixes		o All global prefixes
	o All site prefixes learned from Interfaces 1, 2, and 5		o All site prefixes learned from Interfaces 1, 2, and 3
	Deering, Haberman, Zill 9		o Interface 3
	o Interface 3
	o All global prefixes		o All global prefixes
	o All site prefixes learned from Interface 3		Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 11
			o All site prefixes learned from Interface 1, 2, and 3
	o Interface 4		o Interface 4
	o All global prefixes		o All global prefixes
	o All site prefixes learned from Interface 4		o All site prefixes learned from Interface 4
	o Interface 5		o Interface 5
	o All global prefixes		o All global prefixes
	o All site prefixes learned from Interfaces 1, 2, and 5		o All site prefixes learned from Interfaces 5
	By imposing route exchange rules, zone integrity is maintained by		By imposing route exchange rules, zone integrity is maintained by
	keeping all zone-specific routing information contained within the		keeping all zone-specific routing information contained within the
	zone.		zone.
	11. Related Documents		11. Mobility
	The following list is a set of documents that are related to IPv6		A mobile node that moves outside its "home site" must maintain the
	address scope:		"home site-local addresses" for continued communication with nodes in
			its "home site". This implies that such a mobile node conceptually
			will have one interface (for the traffic destined to and from its
			home site) which is assigned the home site-local addresses in
			addition to its other interfaces which might be part of the visited
			site.
	o Site Prefixes in Neighbor Discovery, draft-ietf-ipngwg-		A mobile node may choose to autoconfigure site-local addresses in the
	site-prefixes-03.txt		visited site. However, such addresses add complexity to the mobile
			node with little or no benefit. Thus it is recommended that mobile
			nodes only autoconfigure global addresses when moving to links
			outside its home site.
	o An Extension of Format for IPv6 Scoped Addresses, draft-		A mobile node needs to be able to detect when it has moved to a
	ietf-ipngwg-scopedaddr-format-00.txt		different site. Thus in addition to the regular movement detection
			in [MOBILE] it should inspect the site prefixes in the Router
			Advertisement messages to determine when it is outside its home site.
	o Default Address Selection for IPv6, draft-ietf-ipngwg-		(Authors' note to selves: complete section description on
	default-addr-select-00.txt		mobility aspects)
	o Basic Socket Interface Extensions for IPv6, RFC 2553		12. Textual Representation
	o Advanced Sockets API for IPv6, draft-ietf-ipngwg-		As already mentioned, to specify an IPv6 non-global address without
	rfc2292bis-01.txt		ambiguity, an intended scope zone should be specified as well. As a
			common notation to specify the scope zone, an implementation SHOULD
			support the following format.
	12. Mobility		Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 12
			<address>%<zone_id>
	TBD		where
			<address> is a literal IPv6 address,
			<zone_id> is a string to identify the scope zone of the
			address, and
			`%' is a delimiter character to distinguish between <address>
			and <zone_id>.
	13. Textual Representation		The following subsections describe detail definitions, concrete
			examples, and additional notes of the format.
	TBD		12.1 Non-Global Addresses
	Deering, Haberman, Zill 10		The format is applied to all kinds of unicast and multicast addresses
			of non-global scope. Although the format is meaningless and should
			not be used for global addresses, an implementation which handles
			addresses (e.g. name to address mapping functions) MAY allow users to
			use such a notation.
			12.2 Zone Indices
			An implementation SHOULD support at least numerical indices as
			<zone_id>, which are non-negative decimal integers. Positive indices
			MUST uniquely specify a single zone for a given address. An
			implementation MAY use zero ("0") to specify a "default" zone as
			described in Section 6 of this document.
			An implementation MAY support other kinds of non-null strings as
			<zone_id>. However, the strings must not conflict with the delimiter
			character. The precise semantics of such additional strings is
			implementation dependent.
			One possible candidate of such strings would be interface names,
			since interfaces uniquely disambiguate any type of scopes. In
			particular, if an implementation can assume that there is a one-to-
			one mapping between links and interfaces (and the assumption is
			usually reasonable,) using interface names as link indices would be
			natural.
			An implementation could also use interface names as <zone_id> for
			larger scopes than links, but there might be some confusion in such
			use. For example, when more than one interface belongs to a same
			site, a user would be confused about which interface should be used.
			Also, a mapping function from an address to a name would encounter a
			same kind of problem, when it prints an address with an interface
			name as a zone index. This document does not specify how these cases
			should be treated and leaves it implementation dependent.
			Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 13
			It cannot be assumed that a same index is common to all nodes in a
			zone (see Section 6). Hence, the format MUST be used only within a
			node and MUST NOT be sent on a wire.
			12.3 Examples
			Here are examples. The following addresses
			fe80::1234 (whose link index is 1)
			fec0::5678 (whose site index is 2)
			ff02::9abc (whose link index is 5)
			ff08::def0 (whose organization index is 10)
			would be represented as follows:
			fe80::1234%1
			fec0::5678%2
			ff02::9abc%5
			ff08::def0%10
			If we use interface names as <zone_id>, those addresses could also be
			represented as follows:
			fe80::1234%ne0
			fec0::5678%ether2
			ff02::9abc%pvc1.3
			ff08::def0%interface10
			where the interface "ne0" belongs to link 1, "ether2" belongs to site
			2, and so on.
			12.4 Usage Examples
			Applications that are supposed to be used in end hosts like telnet,
			ftp, and ssh, may not explicitly support the notion of address scope,
			especially of link-local addresses. However, an expert user (e.g. a
			network administrator) sometimes has to give even link-local
			addresses to such applications.
			Here is a concrete example. Consider a multi-linked router, called
			"R1", that has at least two point-to-point interfaces (links). Each
			of the interfaces is connected to another router, called "R2" and
			"R3", respectively. Also assume that the point-to-point interfaces
			are "unnumbered", that is, they have link-local addresses only.
			Now suppose that the routing system on R2 hangs up and has to be
			reinvoked. In this situation, we may not be able to use a global
			address of R2, because this is a routing trouble and we cannot expect
			that we have enough routes for global reachability to R2.
			Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 14
			Hence, we have to login R1 first, and then try to login R2 using
			link-local addresses. In such a case, we have to give the link-local
			address of R2 to, for example, telnet. Here we assume the address is
			fe80::2.
			Note that we cannot just type like
			% telnet fe80::2
			here, since R1 has more than one link and hence the telnet command
			cannot detect which link it should try to connect. Instead, we
			should type the link-local address with the link index as follows:
			% telnet fe80::2%3
			where 3 after the delimiter character `%' is the link index of the
			point-to-point link.
			Another example is an EBGP peering. When two IPv6 ISPs establish an
			EBGP peering, using a particular ISP's global addresses for the peer
			would be unfair, and using their link-local addresses would be better
			in a neutral IX. In such a case, link-local addresses should be
			specified in a router's configuration file and the link for the
			addresses should be disambiguated, since a router usually connects to
			multiple links.
			12.5 Related API
			The "Basic Socket API" [BASICAPI] defines how the format for non-
			global addresses should be treated in library functions that
			translate a nodename to an address, or vice versa.
			12.6 Omitting Zone Indices
			The format defined in this document does not intend to invalidate the
			original format for non-global addresses, that is, the format without
			the scope index portion. An implementation SHOULD rather provide a
			user with a "default" zone of each scope and allow the user to omit
			zone indices in textual representations.
			Also, when an implementation can assume that there is no ambiguity of
			any type of scopes on a node, it MAY even omit the whole
			functionality to handle the format. An end host with a single
			interface would be an example of such a case.
			12.7 Combinations of Delimiter Characters
			There are other kinds of delimiter characters defined for IPv6
			addresses. In this subsection, we describe how they should be
			combined with the format for non-global addresses.
			Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 15
			The IPv6 addressing architecture [ADDRARCH] also defines the syntax
			of IPv6 prefixes. If the address portion of a prefix is non-global
			and its scope zone should be disambiguated, the address portion
			SHOULD be in the format. For example, the prefix fec0:0:0:1::/64 on
			a site whose index is 2 should be represented as follows:
			fec0:0:0:1::%2/64
			In this combination, it is important to place the zone index portion
			before the prefix length, when we consider parsing the format by a
			name-to-address library function [RFC2553BIS]. That is, we can first
			separate the address with the zone index from the prefix length, and
			just pass the former to the library function.
			The preferred format for literal IPv6 addresses in URL's are also
			defined [RFC 2732]. When a user types the preferred format for an
			IPv6 non-global address whose zone should be explicitly specified,
			the user could use the format for the non-global address combined
			with the preferred format.
			However, the typed URL is often sent on a wire, and it would cause
			confusion if an application did not strip the <zone_id> portion
			before sending. Also, the format for non-global addresses might
			conflict with the URI syntax [RFC 2396], since the syntax defines the
			delimiter character (`%') as the escape character.
			Hence, this document does not specify how the format for non-global
			addresses should be combined with the preferred format for literal
			IPv6 addresses. As for the conflict issue with the URI format, it
			would be better to wait until the relationship between the preferred
			format and the URI syntax is clarified. In fact, the preferred
			format for IPv6 literal addresses itself has same kind of conflict.
			In any case, it is recommended to use an FQDN instead of a literal
			IPv6 address in a URL, whenever an FQDN is available.
			13. Related Documents
			The following documents have aspects related to IPv6 address scope,
			but are not cited elsewhere in this document:
			o Site Prefixes in Neighbor Discovery, draft-ietf-ipngwg-
			site-prefixes-06.txt
			o Default Address Selection for IPv6, draft-ietf-ipngwg-
			default-addr-select-02.txt
			o Advanced Sockets API for IPv6, draft-ietf-ipngwg-
			rfc2292bis-02.txt
			Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 16
	14. Security Considerations		14. Security Considerations
	The routing section of this document specifies a set of guidelines		The routing section of this document specifies a set of guidelines
	that allow routers to prevent zone-specific information from leaking		that allow routers to prevent zone-specific information from leaking
	out of each site. If site boundary routers allow site routing		out of each site. If site boundary routers allow site routing
	information to be forwarded outside of the site, the integrity of		information to be forwarded outside of the site, the integrity of the
	the site could be compromise		site could be compromised.
			Since the use of the textual representation of non-global addresses
			is restricted within a single node, it does not create a security
			vulnerability from outside the node. However, a malicious node might
			send a packet that contains a textual IPv6 non-global address with a
			zone index, intending to deceive the receiving node about the zone of
			the non-global address. Thus, an implementation should be careful
			when it receives packets that contain textual non-global addresses as
			data.
	15. References		15. References
	[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate		[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, BCP14, March 1999.		Requirement Levels", RFC 2119, BCP14, March 1999.
	[RFC 2373] Hinden, R., and Deering, S., "IP Version 6 Addressing		[ADDRARCH] Hinden, R., and Deering, S., "IP Version 6 Addressing
	Architecture", RFC 2373, July 1998.		Architecture", Internet Draft, draft-ietf-ipngwg-addr-
			arch-v3-04.txt, February 2001.
	[RFC 2460] Deering, S., and Hinden, R., "Internet Protocol Version		[RFC 2460] Deering, S., and Hinden, R., "Internet Protocol Version
	6 (IPv6) Specification", RFC 2460, December 1998.		6 (IPv6) Specification", RFC 2460, December 1998.
	[RFC 2473] Conta, A., and Deering, S., "Generic Packet Tunneling in		[RFC 2473] Conta, A., and Deering, S., "Generic Packet Tunneling in
	IPv6 Specification", RFC 2473, December 1998.		IPv6 Specification", RFC 2473, December 1998.
	[RFC 2463] Conta, A., and Deering, S., "Internet Control Message		[RFC 2463] Conta, A., and Deering, S., "Internet Control Message
	Protocol (RFC 2463) for Internet Protocol Version 6		Protocol (RFC 2463) for Internet Protocol Version 6
	(IPv6)", RFC 2463, December 1998.		(IPv6)", RFC 2463, December 1998.
	[RFC 2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor		[RFC 2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor
	Discovery for IP Version 6 (IPv6)", RFC 2461, December		Discovery for IP Version 6 (IPv6)", RFC 2461, December
	1998.		1998.
	[RFC 2553] Gilligan, R., Thomson, S., Bound, J., and Stevens, W.,		[RFC 2553] Gilligan, R., Thomson, S., Bound, J., and Stevens, W.,
	"Basic Socket Interface Extensions for IPv6", RFC 2553,		"Basic Socket Interface Extensions for IPv6", RFC 2553,
	March 1999.		March 1999.
			[MOBILE] Johnson, D.B., and Perkins, C., "Mobility Support in
			IPv6", Internet Draft, draft-ietf-mobileip-ipv6-13.txt,
			November 2000.
			[BASICAPI] Gilligan, R. E., Thomson, S., Bound, J., Stevens, W.,
			"Basic Socket Interface Extensions for IPv6", Internet
			Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 17
			Draft, draft-ietf-ipngwg-rfc2553bis-03.txt, February 2001.
			[RFC 2732] Hinden, R., Carpenter, B., Masinter, L., "Preferred
			Format for Literal IPv6 Addresses in URL's", RFC 2732,
			December 1999.
			[RFC 2396] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform
			Resource Identifiers (URI): Generic Syntax", RFC 2396,
			August 1998.
	Acknowledgements		Acknowledgements
	Authors' Addresses		Authors' Addresses
	Stephen E. Deering		Stephen E. Deering
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134-1706		San Jose, CA 95134-1706
	USA		USA
	Phone: +1-408-527-8213		Phone: +1-408-527-8213
	Fax: +1-408-527-8213		Fax: +1-408-527-8213
	Deering, Haberman, Zill 11
	Email: deering@cisco.com		Email: deering@cisco.com
	Brian Haberman		Brian Haberman
	Nortel Networks		Nortel Networks
	4309 Emperor Blvd.		4309 Emperor Blvd.
	Suite 200		Suite 200
	Durham, NC 27703		Durham, NC 27703
	USA		USA
	Phone: +1-919-992-4439		Phone: +1-919-992-4439
			Fax: +1-919-992-9080
	Email: haberman@nortelnetworks.com		Email: haberman@nortelnetworks.com
			Tatuya JINMEI
			Corporate Research & Development Center, Toshiba Corporation
			1 Komukai Toshiba-cho, Kawasaki-shi
			Kanagawa 212-8582, JAPAN
			Phone: +81-44-549-2230
			Fax: +81-44-520-1841
			Email: jinmei@isl.rdc.toshiba.co.jp
			Erik Nordmark
			Sun Microsystems
			901 San Antonio Road
			Palo Alto, CA 94303
			Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 18
			USA
			Phone: +1-650-786-5166
			Fax: +1-650-786-5896
			Email: nordmark@sun.com
			Atsushi Onoe
			Internet Systems Laboratory, IN Laboratories, Sony Corporation
			6-7-35 Kitashinagawa, Shinagawa-ku
			Tokyo 141-0001, JAPAN
			Phone: +81-3-5448-4620
			Fax: +81-3-5448-4622
			Email: onoe@sm.sony.co.jp
	Brian D. Zill		Brian D. Zill
	Microsoft Research		Microsoft Research
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052-6399		Redmond, WA 98052-6399
	USA		USA
	Phone: +1-425-703-3568		Phone: +1-425-703-3568
	Fax: +1-425-936-7329		Fax: +1-425-936-7329
	Email: bzill@microsoft.com		Email: bzill@microsoft.com
	Deering, Haberman, Zill 12		Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 19
End of changes. 95 change blocks.
	269 lines changed or deleted		647 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/