draft-ietf-ipngwg-unicast-aggr-02.txt		draft-ietf-ipngwg-unicast-aggr-03.txt
	INTERNET-DRAFT R. Hinden, Ipsilon Networks		INTERNET-DRAFT R. Hinden, Nokia
	July 16, 1997 M. O'Dell, UUNET		January 22, 1998 M. O'Dell, UUNET
	S. Deering, Cisco		S. Deering, Cisco
	An IPv6 Aggregatable Global Unicast Address Format		An IPv6 Aggregatable Global Unicast Address Format
	<draft-ietf-ipngwg-unicast-aggr-02.txt>		<draft-ietf-ipngwg-unicast-aggr-03.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet Draft. Internet Drafts are working		This document is an Internet Draft. Internet Drafts are working
	documents of the Internet Engineering Task Force (IETF), its Areas,		documents of the Internet Engineering Task Force (IETF), its Areas,
	and its Working Groups. Note that other groups may also distribute		and its Working Groups. Note that other groups may also distribute
	working documents as Internet Drafts.		working documents as Internet Drafts.
	Internet Drafts are draft documents valid for a maximum of six		Internet Drafts are draft documents valid for a maximum of six
	months. Internet Drafts may be updated, replaced, or obsoleted by		months. Internet Drafts may be updated, replaced, or obsoleted by
	other documents at any time. It is not appropriate to use Internet		other documents at any time. It is not appropriate to use Internet
	Drafts as reference material or to cite them other than as a		Drafts as reference material or to cite them other than as a
	``working draft'' or ``work in progress.''		``working draft'' or ``work in progress.''
	Please check the 1id-abstracts.txt listing contained in the internet-		Please check the 1id-abstracts.txt listing contained in the internet-
	drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,		drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
	nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the		nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
	current status of any Internet Draft.		current status of any Internet Draft.
	This internet draft expires on January 17, 1998.		This internet draft expires on August 22, 1998.
	1.0 Introduction		1.0 Introduction
	This document defines an IPv6 aggregatable global unicast address		This document defines an IPv6 aggregatable global unicast address
	format for use in the Internet. The address format defined in this		format for use in the Internet. The address format defined in this
	document is consistent with the IPv6 Protocol [IPV6] and the "IPv6		document is consistent with the IPv6 Protocol [IPV6] and the ''IPv6
	Addressing Architecture" [ARCH]. It is designed to facilitate		Addressing Architecture'' [ARCH]. It is designed to facilitate
	scalable Internet routing.		scalable Internet routing.
	This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast		This documented replaces RFC 2073, ''An IPv6 Provider-Based Unicast
	Address Format". RFC 2073 will become historic.		Address Format''. RFC 2073 will become historic.
	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.0 Overview of the IPv6 Address		2.0 Overview of the IPv6 Address
	IPv6 addresses are 128-bit identifiers for interfaces and sets of		IPv6 addresses are 128-bit identifiers for interfaces and sets of
	interfaces. There are three types of addresses: Unicast, Anycast,		interfaces. There are three types of addresses: Unicast, Anycast,
	and Multicast. This document defines a specific type of Unicast		and Multicast. This document defines a specific type of Unicast
	skipping to change at page 3, line 47		skipping to change at page 3, line 43
	( S.A ) ( S.B ) ( P5 ) ( P6 )( S.C )		( S.A ) ( S.B ) ( P5 ) ( P6 )( S.C )
	\___/ \___/ \___/ \___/ \___/		\___/ \___/ \___/ \___/ \___/
	| / \		| / \
	_|_ _/_ \ ___		_|_ _/_ \ ___
	/ \ / \ +-/ \		/ \ / \ +-/ \
	( S.D ) ( S.E ) ( S.F )		( S.D ) ( S.E ) ( S.F )
	\___/ \___/ \___/		\___/ \___/ \___/
	As shown in the figure above, the aggregatable address format is		As shown in the figure above, the aggregatable address format is
	designed to support long-haul providers (shown as P1, P2, P3, and		designed to support long-haul providers (shown as P1, P2, P3, and
	P4), exchanges [EXCH] (shown as X1 and X2), multiple levels of		P4), exchanges (shown as X1 and X2), multiple levels of providers
	providers (shown at P5 and P6), and subscribers (shown as S.x)		(shown at P5 and P6), and subscribers (shown as S.x) Exchanges
	Exchanges (unlike current NAPs, FIXes, etc.) will allocate IPv6		(unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses.
	addresses. Organizations who connect to these exchanges will also		Organizations who connect to these exchanges will also subscribe
	subscribe (directly, indirectly via the exchange, etc.) for long-haul		(directly, indirectly via the exchange, etc.) for long-haul service
	service from one or more long-haul providers. Doing so, they will		from one or more long-haul providers. Doing so, they will achieve
	achieve addressing independence from long-haul transit providers.		addressing independence from long-haul transit providers. They will
	They will be able to change long-haul providers without having to		be able to change long-haul providers without having to renumber
	renumber their organization. They can also be multihomed via the		their organization. They can also be multihomed via the exchange to
	exchange to more than one long-haul provider without having to have		more than one long-haul provider without having to have address
	address prefixes from each long-haul provider. Note that the		prefixes from each long-haul provider. Note that the mechanisms used
	mechanisms used for this type of provider selection and portability		for this type of provider selection and portability are not discussed
	are not discussed in the document.		in the document.
	3.1 Aggregatable Global Unicast Address Structure		3.1 Aggregatable Global Unicast Address Structure
	The aggregatable global unicast address format is as follows:		The aggregatable global unicast address format is as follows:
	| 3 | 13 | 32 | 16 | 64 bits |		| 3| 13 | 8 | 24 | 16 | 64 bits |
	+---+-----+-----------+--------+--------------------------------+		+--+-----+---+--------+--------+--------------------------------+
	|FP | TLA | NLA ID | SLA ID | Interface ID |		|FP| TLA |RES| NLA | SLA | Interface ID |
	| | ID | | | |		| | ID | | ID | ID | |
	+---+-----+-----------+--------+--------------------------------+		+--+-----+---+--------+--------+--------------------------------+
	<--Public Topology---> Site		<--Public Topology---> Site
	<-------->		<-------->
	Topology		Topology
	<------Interface Identifier----->		<------Interface Identifier----->
	Where		Where
	FP Format Prefix (001)		FP Format Prefix (001)
	TLA ID Top-Level Aggregation Identifier		TLA ID Top-Level Aggregation Identifier
			RES Reserved for future use
	NLA ID Next-Level Aggregation Identifier		NLA ID Next-Level Aggregation Identifier
	SLA ID Site-Level Aggregation Identifier		SLA ID Site-Level Aggregation Identifier
	INTERFACE ID Interface Identifier		INTERFACE ID Interface Identifier
	The following sections specify each part of the IPv6 Aggregatable		The following sections specify each part of the IPv6 Aggregatable
	Global Unicast address format.		Global Unicast address format.
	3.2 Top-Level Aggregation ID		3.2 Top-Level Aggregation ID
	Top-Level Aggregation Identifiers (TLA ID) are the top level in the		Top-Level Aggregation Identifiers (TLA ID) are the top level in the
	routing hierarchy. Default-free routers must have a routing table		routing hierarchy. Default-free routers must have a routing table
	entry for every active TLA ID and will probably have additional		entry for every active TLA ID and will probably have additional
	entries providing routing information for the TLA ID in which they		entries providing routing information for the TLA ID in which they
	are located. They may have additional entries in order to optimize		are located. They may have additional entries in order to optimize
	routing for their specific topology, but the routing topology at all		routing for their specific topology, but the routing topology at all
	levels must be designed to minimize the number of additional entries		levels must be designed to minimize the number of additional entries
	fed into the default free routing tables.		fed into the default free routing tables.
	This addressing format supports 8,192 (2^13) TLA ID's. Additional		This addressing format supports 8,192 (2^13) TLA ID's. Additional
	TLA ID's may be added by using this format for additional format		TLA ID's may be added by either growing the TLA field to the right
	prefixes. The addition of another FP will add another 8,192 TLA		into the reserved field or by using this format for additional format
	ID's.		prefixes.
	The rules for TLA ID assignment are defined in [TLAASN].		The issues relating to TLA ID assignment are beyond the scope of this
			document. They will be described in a document under preparation.
	3.3 Next-Level Aggregation Identifier		3.3 Reserved
			The Reserved field is reserved for future use and must be set to
			zero.
			The Reserved field allows for future growth of the TLA and NLA fields
			as appropriate. See section 4.0 for a discussion.
			3.4 Next-Level Aggregation Identifier
	Next-Level Aggregation Identifier's are used by organizations		Next-Level Aggregation Identifier's are used by organizations
	assigned a TLA ID to create an addressing hierarchy and to identify		assigned a TLA ID to create an addressing hierarchy and to identify
	sites. The organization can assign the top part of the NLA ID in a		sites. The organization can assign the top part of the NLA ID in a
	manner to create an addressing hierarchy appropriate to its network.		manner to create an addressing hierarchy appropriate to its network.
	It can use the remainder of the bits in the field to identify sites		It can use the remainder of the bits in the field to identify sites
	it wishes to serve. This is shown as follows:		it wishes to serve. This is shown as follows:
	| n | 32-n bits | 16 | 64 bits |		| n | 24-n bits | 16 | 64 bits |
	+-----+--------------------+--------+-----------------+		+-----+--------------------+--------+-----------------+
	|NLA1 | Site ID | SLA ID | Interface ID |		|NLA1 | Site ID | SLA ID | Interface ID |
	+-----+--------------------+--------+-----------------+		+-----+--------------------+--------+-----------------+
	Each organization assigned a TLA ID receives 32 bits of NLA ID space.		Each organization assigned a TLA ID receives 24 bits of NLA ID space.
	This NLA ID space allows each organization to provide service to		This NLA ID space allows each organization to provide service to
	approximately as many organizations as the current IPv4 Internet can		approximately as many organizations as the current IPv4 Internet can
	support total nodes.		support total networks.
	Organizations assigned TLA ID's may also support NLA ID's in their		Organizations assigned TLA ID's may also support NLA ID's in their
	own Site ID space. This allows the organization assigned a TLA ID to		own Site ID space. This allows the organization assigned a TLA ID to
	provide service to organizations providing public transit service and		provide service to organizations providing public transit service and
	to organizations who do not provide public transit service. These		to organizations who do not provide public transit service. These
	organizations receiving an NLA ID may also choose to use their Site		organizations receiving an NLA ID may also choose to use their Site
	ID space to support other NLA ID's. This is shown as follows:		ID space to support other NLA ID's. This is shown as follows:
	| n | 32-n bits | 16 | 64 bits |		| n | 24-n bits | 16 | 64 bits |
	+-----+--------------------+--------+-----------------+		+-----+--------------------+--------+-----------------+
	|NLA1 | Site ID | SLA ID | Interface ID |		|NLA1 | Site ID | SLA ID | Interface ID |
	+-----+--------------------+--------+-----------------+		+-----+--------------------+--------+-----------------+
	| m | 32-n-m | 16 | 64 bits |		| m | 24-n-m | 16 | 64 bits |
	+-----+--------------+--------+-----------------+		+-----+--------------+--------+-----------------+
	|NLA2 | Site ID | SLA ID | Interface ID |		|NLA2 | Site ID | SLA ID | Interface ID |
	+-----+--------------+--------+-----------------+		+-----+--------------+--------+-----------------+
	| o |32-n-m-o| 16 | 64 bits |		| o |24-n-m-o| 16 | 64 bits |
	+-----+--------+--------+-----------------+		+-----+--------+--------+-----------------+
	|NLA3 | Site ID| SLA ID | Interface ID |		|NLA3 | Site ID| SLA ID | Interface ID |
	+-----+--------+--------+-----------------+		+-----+--------+--------+-----------------+
	The rules for NLA ID assignment are defined in [TLAASN].
	The design of the bit layout of the NLA ID space for a specific TLA		The design of the bit layout of the NLA ID space for a specific TLA
	ID is left to the organization responsible for that TLA ID. Likewise		ID is left to the organization responsible for that TLA ID. Likewise
	the design of the bit layout of the next level NLA ID is the		the design of the bit layout of the next level NLA ID is the
	responsibility of the previous level NLA ID. It is recommended that		responsibility of the previous level NLA ID. It is recommended that
	organizations assigning NLA address space use "slow start" allocation		organizations assigning NLA address space use "slow start" allocation
	procedures as is currently done with IPv4 CIDR blocks.		procedures similar to [RFC2050].
	The design of an NLA ID allocation plan is a tradeoff between routing		The design of an NLA ID allocation plan is a tradeoff between routing
	aggregation efficiency and flexibility. Creating hierarchies allows		aggregation efficiency and flexibility. Creating hierarchies allows
	for greater amount of aggregation and results in smaller routing		for greater amount of aggregation and results in smaller routing
	tables. Flat NLA ID assignment provides for easier allocation and		tables. Flat NLA ID assignment provides for easier allocation and
	attachment flexibility, but results in larger routing tables.		attachment flexibility, but results in larger routing tables.
	3.4 Site-Level Aggregation Identifier		3.5 Site-Level Aggregation Identifier
	The SLA ID field is used by an individual organization to create its		The SLA ID field is used by an individual organization to create its
	own local addressing hierarchy and to identify subnets. This is		own local addressing hierarchy and to identify subnets. This is
	analogous to subnets in IPv4 except that each organization has a much		analogous to subnets in IPv4 except that each organization has a much
	greater number of subnets. The 16 bit SLA ID field support 65,535		greater number of subnets. The 16 bit SLA ID field support 65,535
	individual subnets.		individual subnets.
	Organizations may choose to either route their SLA ID "flat" (e.g.,		Organizations may choose to either route their SLA ID "flat" (e.g.,
	not create any logical relationship between the SLA identifiers that		not create any logical relationship between the SLA identifiers that
	results in larger routing tables), or to create a two or more level		results in larger routing tables), or to create a two or more level
	skipping to change at page 7, line 24		skipping to change at page 7, line 24
	The approach chosen for structuring an SLA ID field is the		The approach chosen for structuring an SLA ID field is the
	responsibility of the individual organization.		responsibility of the individual organization.
	The number of subnets supported in this address format should be		The number of subnets supported in this address format should be
	sufficient for all but the largest of organizations. Organizations		sufficient for all but the largest of organizations. Organizations
	which need additional subnets can arrange with the organization they		which need additional subnets can arrange with the organization they
	are obtaining Internet service from to obtain additional site		are obtaining Internet service from to obtain additional site
	identifiers and use this to create additional subnets.		identifiers and use this to create additional subnets.
	3.5 Interface ID		3.6 Interface ID
	Interface identifiers are used to identify interfaces on a link.		Interface identifiers are used to identify interfaces on a link.
	They are required to be unique on that link. They may also be unique		They are required to be unique on that link. They may also be unique
	over a broader scope. In many cases an interface's identifier will		over a broader scope. In many cases an interfaces identifier will be
	be the same or be based on the interface's link-layer address.		the same or be based on the interface's link-layer address.
	Interface IDs used in the aggregatable global unicast address format		Interface IDs used in the aggregatable global unicast address format
	are required to be 64 bits long and to be constructed in IEEE EUI-64		are required to be 64 bits long and to be constructed in IEEE EUI-64
	format [EUI-64]. These identifiers may have global scope when a		format [EUI-64]. These identifiers may have global scope when a
	global token (e.g., IEEE 48bit MAC) is available or may have local		global token (e.g., IEEE 48bit MAC) is available or may have local
	scope where a global token is not available (e.g., serial links,		scope where a global token is not available (e.g., serial links,
	tunnel end-points, etc.). The "u" bit (universal/local bit in IEEE		tunnel end-points, etc.). The "u" bit (universal/local bit in IEEE
	EUI-64 terminology) in the EUI-64 identifier must be set correctly,		EUI-64 terminology) in the EUI-64 identifier must be set correctly,
	as defined in [ARCH], to indicate global or local scope.		as defined in [ARCH], to indicate global or local scope.
	The procedures for creating EUI-64 based Interface Identifiers is		The procedures for creating EUI-64 based Interface Identifiers is
	defined in [ARCH]. The details on forming interface identifiers is		defined in [ARCH]. The details on forming interface identifiers is
	defined in the appropriate "IPv6 over <link>" specification such as		defined in the appropriate "IPv6 over <link>" specification such as
	"IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.		"IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
	4.0 Acknowledgments		4.0 Technical Motivation
			The design choices for the size of the fields in the aggregatable
			address format were based on the need to meet a number of technical
			requirements. These are described in the following paragraphs.
			The size of the Top-Level Aggregation Identifier is 13 bits. This
			allows for 8,192 TLA ID's. This size was chosen to insure that the
			default-free routing table in top level routers in the Internet is
			kept within the limits, with a reasonable margin, of the current
			routing technology. The margin is important because default-free
			routers will also carry a significant number of longer (i.e., more-
			specific) prefixes for optimizing paths internal to a TLA and between
			TLAs.
			The important issue is not only the size of the default-free routing
			table, but the complexity of the topology that determines the number
			of copies of the default-free routes that a router must examine while
			computing a forwarding table. Current practice with IPv4 it is
			common to see a prefix announced fifteen times via different paths.
			The complexity of Internet topology is very likely to increase in the
			future. It is important that IPv6 default-free routing support
			additional complexity as well as a considerably larger internet.
			It should be noted for comparison that the current IPv4 default-free
			routing table is approximately 47,000 prefixes. While this shows
			that it is possible to support more routes than 8,192 it is matter of
			debate if the number of prefixes supported today in IPv4 is already
			too high for current routing technology. There are serious issues of
			route stability as well as cases of providers not supporting all top
			level prefixes. The technical requirement was to pick a TLA ID size
			that was below, with a reasonable margin, what was being done with
			IPv4.
			The choice of 13 bits for the TLA field was an engineering
			compromise. Fewer bits would have been too small by not supporting
			enough top level organizations. More bits would have exceeded what
			can be reasonably accommodated, with a reasonable margin, with
			current routing technology in order to deal with the issues described
			in the previous paragraphs.
			If in the future, routing technology improves to support a larger
			number of top level routes in the default-free routing tables there
			are two choices on how to increase the number TLA identifiers. The
			first is to expand the TLA ID field into the reserved field. This
			would increase the number of TLA ID's to approximately 2 million.
			The second approach is to allocate another format prefix (FP) for use
			with this address format. Either or a combination of these
			approaches allows the number of TLA ID's to increase significantly.
			The size of the Reserved field is 8 bits. This size was chosen to
			allow significant growth of either the TLA ID and/or the NLA ID
			fields.
			The size of the Next-Level Aggregation Identifier field is 24 bits.
			This allows for approximately sixteen million NLA ID's if used in a
			flat manner. Used hierarchically it allows for a complexity roughly
			equivalent to the IPv4 address space (assuming an average network
			size of 254 interfaces). If in the future additional room for
			complexity is needed in the NLA ID, this may be accommodated by
			extending the NLA ID into the Reserved field.
			The size of the Site-Level Aggregation Identifier field is 16 bits.
			This supports 65,535 individual subnets per site. The design goal
			for the size of this field was to be sufficient for all but the
			largest of organizations. Organizations which need additional
			subnets can arrange with the organization they are obtaining Internet
			service from to obtain additional site identifiers and use this to
			create additional subnets.
			The Site-Level Aggregation Identifier field was given a fixed size in
			order to force the length of all prefixes identifying a particular
			site to be the same length (i.e., 48 bits). This facilitates
			movement of sites in the topology (e.g., changing service providers
			and multi-homing to multiple service providers).
			The Interface ID Interface Identifier field is 64 bits. This size
			was chosen to meet the requirement specified in [ARCH] to support
			EUI-64 based Interface Identifiers.
			5.0 Acknowledgments
	The authors would like to express our thanks to Thomas Narten, Bob		The authors would like to express our thanks to Thomas Narten, Bob
	Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,		Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
	Scott Bradner, Brian Carpenter, and John Stewart for their review and		Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg
	constructive comments.		for their review and constructive comments.
	5.0 References		6.0 References
	[ALLOC] IAB and IESG, "IPv6 Address Allocation Management",		[ALLOC] IAB and IESG, "IPv6 Address Allocation Management",
	RFC1881, December 1995.		RFC1881, December 1995.
	[ARCH] Hinden, R., "IP Version 6 Addressing Architecture",		[ARCH] Hinden, R., "IP Version 6 Addressing Architecture",
	Internet Draft, <draft-ietf-ipngwg-addr-arch-v2-02.txt>,		Internet Draft, <draft-ietf-ipngwg-addr-arch-v2-02.txt>,
	July 1997.		July 1997.
	[AUTH] Atkinson, R., "IP Authentication Header", RFC1826, August		[AUTH] Atkinson, R., "IP Authentication Header", RFC1826, August
	1995.		1995.
	[AUTO] Thompson, S., Narten T., "IPv6 Stateless Address		[AUTO] Thompson, S., T. Narten., "IPv6 Stateless Address
	Autoconfiguration", RFC1971, August 1996.		Autoconfiguration", RFC1971, August 1996.
	[CIDR] Fuller, V., T. Li, K. Varadhan, J. Yu, "Supernetting: an
	Address Assignment and Aggregation Strategy", RFC1338.
	[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet		[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
	Networks", Internet Draft, <draft-ietf-ipngwg-trans-		Networks", Internet Draft, <draft-ietf-ipngwg-trans-
	ethernet-00.txt>, March 1997.		ethernet-00.txt>, March 1997.
	[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)		[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
	Registration Authority",		Registration Authority",
	http://standards.ieee.org/db/oui/tutorials/EUI64.html,		http://standards.ieee.org/db/oui/tutorials/EUI64.html,
	March 1997.		March 1997.
	[EXCH] Huitema, C., R. Hinden, "Internet Exchanges", document
	under preparation.
	[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI		[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
	Networks", Internet Draft, <draft-ietf-ipngwg-trans-fddi-		Networks", Internet Draft, <draft-ietf-ipngwg-trans-fddi-
	net-00.txt>, March 1997.		net-00.txt>, March 1997.
	[IPV6] Deering, S., Hinden, R., Editors, "Internet Protocol,		[IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6
	Version 6 (IPv6) Specification", RFC1883, December 1995.		(IPv6) Specification", RFC1883, December 1995.
			[RFC2050] Hubbard, K., M. Kosters, D. Conrad, D. Karrenberg, J.
			Postel, "Internet Registry IP Allocation Guidelines",
			RFC1466, BCP12, November 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC2119, BCP14, March 1997.		Requirement Levels", RFC2119, BCP14, March 1997.
	[TLAASN] Hinden, R., "TLA and NLA Assignment Rules", Internet Draft,		7.0 Security Considerations
	<draft-ietf-ipngwg-tla-assignment-00.txt>, July 1997.
	6.0 Security Considerations
	IPv6 addressing documents do not have any direct impact on Internet		IPv6 addressing documents do not have any direct impact on Internet
	infrastructure security. Authentication of IPv6 packets is defined		infrastructure security. Authentication of IPv6 packets is defined
	in [AUTH].		in [AUTH].
	7.0 Authors' Addresses		8.0 Authors' Addresses
	Robert M. Hinden phone: 1 408 990-2004		Robert M. Hinden phone: 1 408 990-2004
	Ipsilon Networks, Inc. email: hinden@ipsilon.com		Nokia . email: hinden@ipsilon.com
	232 Java Drive		232 Java Drive
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	USA		USA
	Mike O'Dell phone: 1 703 206-5890		Mike O'Dell phone: 1 703 206-5890
	UUNET Technologies, Inc. email: mo@uunet.uu.net		UUNET Technologies, Inc. email: mo@uunet.uu.net
	3060 Williams Drive		3060 Williams Drive
	Fairfax, VA 22030		Fairfax, VA 22030
	USA		USA
End of changes. 32 change blocks.
	63 lines changed or deleted		147 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/