< draft-ietf-ospf-ospfv3-autoconfig-09.txt		draft-ietf-ospf-ospfv3-autoconfig-10.txt >
	Network Working Group A. Lindem		Network Working Group A. Lindem
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track J. Arkko		Intended status: Standards Track J. Arkko
	Expires: March 13, 2015 Ericsson		Expires: July 9, 2015 Ericsson
	September 9, 2014		January 5, 2015
	OSPFv3 Auto-Configuration		OSPFv3 Auto-Configuration
	draft-ietf-ospf-ospfv3-autoconfig-09.txt		draft-ietf-ospf-ospfv3-autoconfig-10.txt
	Abstract		Abstract
	OSPFv3 is a candidate for deployments in environments where auto-		OSPFv3 is a candidate for deployments in environments where auto-
	configuration is a requirement. One such environment is the IPv6		configuration is a requirement. One such environment is the IPv6
	home network where users expect to simply plug in a router and have		home network where users expect to simply plug in a router and have
	it automatically use OSPFv3 for intra-domain routing. This document		it automatically use OSPFv3 for intra-domain routing. This document
	describes the necessary mechanisms for OSPFv3 to be self-configuring.		describes the necessary mechanisms for OSPFv3 to be self-configuring.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 13, 2015.		This Internet-Draft will expire on July 9, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3		1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
	1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 3		1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 3
	2. OSPFv3 Default Configuration . . . . . . . . . . . . . . . . . 5		2. OSPFv3 Default Configuration . . . . . . . . . . . . . . . . 4
	3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 7		3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 5
	3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . . 7		3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . 5
	4. OSPFv3 Minimal Authentication Configuration . . . . . . . . . 8		4. OSPFv3 Minimal Authentication Configuration . . . . . . . . . 5
	5. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . . 9		5. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . 5
	6. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . . 10		6. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . 6
	7. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 11		7. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 6
	7.1. Duplicate Router ID Detection for Neighbors . . . . . . . 11		7.1. Duplicate Router ID Detection for Neighbors . . . . . . . 6
	7.2. Duplicate Router ID Detection for OSPFv3 Routers that		7.2. Duplicate Router ID Detection for OSPFv3 Routers that are
	are not Neighbors . . . . . . . . . . . . . . . . . . . . 11		not Neighbors . . . . . . . . . . . . . . . . . . . . . . 7
	7.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . . 11		7.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . 7
	7.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 13		7.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 9
	7.3. Duplicate Router ID Resolution . . . . . . . . . . . . . . 14		7.3. Duplicate Router ID Resolution . . . . . . . . . . . . . 9
	7.4. Change to RFC 2328 Section 13.4, 'Receiving		7.4. Change to RFC 2328 Section 13.4, 'Receiving Self-
	Self-Originated LSA' Processing . . . . . . . . . . . . . 14		Originated LSA' Processing . . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 15		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. Management Considerations . . . . . . . . . . . . . . . . . . 16		9. Management Considerations . . . . . . . . . . . . . . . . . . 10
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 18		11.1. Normative References . . . . . . . . . . . . . . . . . . 11
	11.2. Informative References . . . . . . . . . . . . . . . . . . 18		11.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	OSPFv3 [OSPFV3] is a candidate for deployments in environments where		OSPFv3 [OSPFV3] is a candidate for deployments in environments where
	auto-configuration is a requirement. Its operation is largely		auto-configuration is a requirement. Its operation is largely
	unchanged from the base OSPFv3 protocol specification [OSPFV3].		unchanged from the base OSPFv3 protocol specification [OSPFV3].
	The following aspects of OSPFv3 auto-configuration are described:		The following aspects of OSPFv3 auto-configuration are described:
	1. Default OSPFv3 Configuration		1. Default OSPFv3 Configuration
	2. HelloInterval/RouterDeadInterval Flexibility		2. HelloInterval/RouterDeadInterval Flexibility
	3. Unique OSPFv3 Router-ID generation		3. Unique OSPFv3 Router ID generation
	4. OSPFv3 Adjacency Formation		4. OSPFv3 Adjacency Formation
	5. Duplicate OSPFv3 Router-ID Resolution		5. Duplicate OSPFv3 Router ID Resolution
	1.1. Requirements notation		1.1. Requirements notation
	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-KEYWORDS].		document are to be interpreted as described in [RFC-KEYWORDS].
	1.2. Acknowledgments		1.2. Acknowledgments
	This specification was inspired by the work presented in the Homenet		This specification was inspired by the work presented in the Homenet
	skipping to change at page 4, line 13 ¶		skipping to change at page 3, line 43 ¶
	prevalent in home networks.		prevalent in home networks.
	Thanks to Les Ginsberg for document review and recommendations on		Thanks to Les Ginsberg for document review and recommendations on
	OSPFv3 hardware fingerprint content.		OSPFv3 hardware fingerprint content.
	Thanks to Curtis Villamizar for document review and analysis of		Thanks to Curtis Villamizar for document review and analysis of
	duplicate router-id resolution nuances.		duplicate router-id resolution nuances.
	Thanks to Uma Chunduri for comments during OSPF WG last call.		Thanks to Uma Chunduri for comments during OSPF WG last call.
			Thanks to Martin Vigoureux for Routing Area Directorate review and
			comments.
	Special thanks go to Markus Stenberg for his implementation of this		Special thanks go to Markus Stenberg for his implementation of this
	specification in Bird.		specification in Bird.
	Special thanks also go to David Lamparter for his implementation of		Special thanks also go to David Lamparter for his implementation of
	this specification in Quagga.		this specification in Quagga.
	The RFC text was produced using Marshall Rose's xml2rfc tool.		The RFC text was produced using Marshall Rose's xml2rfc tool.
	2. OSPFv3 Default Configuration		2. OSPFv3 Default Configuration
	For complete auto-configuration, OSPFv3 will need to choose suitable		For complete auto-configuration, OSPFv3 will need to choose suitable
	configuration defaults. These include:		configuration defaults. These include:
	1. Area 0 Only - All auto-configured OSPFv3 interfaces MUST be in		1. Area 0 Only - All auto-configured OSPFv3 interfaces MUST be in
	area 0.		area 0.
	2. OSPFv3 SHOULD be auto-configured on for IPv6 on all interfaces		2. OSPFv3 SHOULD be auto-configured for IPv6 on all interfaces
	intended as general IPv6-capable routers. Optionally, an		intended as general IPv6-capable routers. Optionally, an
	interface MAY be excluded if it is clear that running OSPFv3 on		interface MAY be excluded if it is clear that running OSPFv3 on
	the interface is not required. For example, if manual		the interface is not required. For example, if manual
	configuration or another condition indicates that an interface is		configuration or another condition indicates that an interface is
	connected to an Internet Service Provider (ISP) and there is no		connected to an Internet Service Provider (ISP) and there is no
	Border Gateway Protocol (BGP) [BGP] peering, there is typically		Border Gateway Protocol (BGP) [BGP] peering, there is typically
	no need to employ OSPFv3. In fact, [IPv6-CPE] specifically		no need to employ OSPFv3. In fact, [IPv6-CPE] specifically
	requires that IPv6 Customer Premise Equipment (CPE) routers do		requires that IPv6 Customer Premise Equipment (CPE) routers do
	not initiate any dynamic routing protocol by default on the		not initiate any dynamic routing protocol by default on the
	router's WAN, i.e., ISP-facing, interface. In home networking		router's WAN, i.e., ISP-facing, interface. In home networking
	skipping to change at page 9, line 7 ¶		skipping to change at page 5, line 47 ¶
	overrides the goal of complete OSPFv3 autoconfiguration. Therefore,		overrides the goal of complete OSPFv3 autoconfiguration. Therefore,
	it is RECOMMENDED that OSPFv3 routers supporting this specification		it is RECOMMENDED that OSPFv3 routers supporting this specification
	minimally offer an option to explicitly configure a single password		minimally offer an option to explicitly configure a single password
	for HMAC-SHA authentication as described in [OSPFV3-AUTH-TRAILER].		for HMAC-SHA authentication as described in [OSPFV3-AUTH-TRAILER].
	When configured, the password will be used on all auto-configured		When configured, the password will be used on all auto-configured
	interfaces with the Security Association Identifier (SA ID) set to 1		interfaces with the Security Association Identifier (SA ID) set to 1
	and HMAC-SHA-256 used as the authentication algorithm.		and HMAC-SHA-256 used as the authentication algorithm.
	5. OSPFv3 Router ID Selection		5. OSPFv3 Router ID Selection
	As OSPFv3 Router implementing this specification must select a unique		An OSPFv3 router requires a unique Router ID for correct protocol
	Router ID. A pseudo-random number SHOULD be used for the OSPFv3		operation. An OSPFv3 router implementing this specification will
	Router ID. The generation should be seeded with a variable that is		select a router-id that has a high probability of uniqueness. A
	likely to be unique in the applicable OSPFv3 router deployment. A		pseudo-random number SHOULD be used for the OSPFv3 Router ID. The
	good choice of seed would be some portion or hash of the Router-		generation should be seeded with a variable that is likely to be
	Hardware-Fingerprint as described in Section 7.2.2.		unique in the applicable OSPFv3 router deployment. A good choice of
			seed would be some portion or hash of the Router-Hardware-Fingerprint
			as described in Section 7.2.2.
	Since there is a possibility of a Router ID collision, duplicate		Since there is a possibility of a Router ID collision, duplicate
	Router ID detection and resolution are required as described in		Router ID detection and resolution are required as described in
	Section 7 and Section 7.3. OSPFv3 Routers SHOULD maintain the last		Section 7 and Section 7.3. OSPFv3 routers SHOULD maintain the last
	successfully chosen Router ID in non-volatile storage to avoid		successfully chosen Router ID in non-volatile storage to avoid
	collisions subsequent to when an autoconfigured OSPFv3 router is		collisions subsequent to when an autoconfigured OSPFv3 router is
	first added to the OSPFv3 routing domain.		first added to the OSPFv3 routing domain.
	6. OSPFv3 Adjacency Formation		6. OSPFv3 Adjacency Formation
	Since OSPFv3 uses IPv6 link-local addresses for all protocol messages		Since OSPFv3 uses IPv6 link-local addresses for all protocol messages
	other than messages sent on virtual links (which are not applicable		other than messages sent on virtual links (which are not applicable
	to auto-configuration), OSPFv3 adjacency formation can proceed as		to auto-configuration), OSPFv3 adjacency formation can proceed as
	soon as a Router ID has been selected and the IPv6 link-local address		soon as a Router ID has been selected and the IPv6 link-local address
	skipping to change at page 11, line 30 ¶		skipping to change at page 7, line 8 ¶
	fact that the OSPFv3 router is a neighbor on a non-virtual interface		fact that the OSPFv3 router is a neighbor on a non-virtual interface
	implies that the router is directly connected. An OSPFv3 router		implies that the router is directly connected. An OSPFv3 router
	implementing this specification should assure that the inadvertent		implementing this specification should assure that the inadvertent
	connection of multiple router interfaces to the same physical link is		connection of multiple router interfaces to the same physical link is
	not misconstrued as detection of an OSPFv3 neighbor with a duplicate		not misconstrued as detection of an OSPFv3 neighbor with a duplicate
	Router ID.		Router ID.
	7.2. Duplicate Router ID Detection for OSPFv3 Routers that are not		7.2. Duplicate Router ID Detection for OSPFv3 Routers that are not
	Neighbors		Neighbors
	OSPFv3 Routers implementing auto-configuration, as specified herein,		OSPFv3 routers implementing auto-configuration, as specified herein,
	MUST originate an Auto-Configuration (AC) Link State Advertisement		MUST originate an Auto-Configuration (AC) Link State Advertisement
	(LSA) including the Router-Hardware-Fingerprint Type-Length-Value		(LSA) including the Router-Hardware-Fingerprint Type-Length-Value
	(TLV). The Router-Hardware-Fingerprint TLV contains a variable		(TLV). The Router-Hardware-Fingerprint TLV contains a variable
	length value that has a very high probability of uniquely identifying		length value that has a very high probability of uniquely identifying
	the advertising OSPFv3 router. An OSPFv3 router implementing this		the advertising OSPFv3 router. An OSPFv3 router implementing this
	specification MUST compare a received self-originated Auto-		specification MUST detect received Auto-Configuration LSAs with its
	Configuration LSA's Router-Hardware-Fingerprint TLV against its own		Router ID specified in the LSA header. LSAs received with the local
	router hardware fingerprint. If the fingerprints are not equal,		OSPFv3 Router's Router ID in the LSA header are perceived as self-
	there is a duplicate Router ID conflict and the OSPFv3 Router with		originated (see section 4.6 of [OSPFV3]). In these received Auto-
	the numerically smaller router hardware fingerprint MUST select a new		Configuration LSAs, the Router-Hardware-Fingerprint TLV is compared
	Router ID as described in Section 7.3.		against the OSPFv3 Router's own router hardware fingerprint. If the
			fingerprints are not equal, there is a duplicate Router ID conflict
			and the OSPFv3 router with the numerically smaller router hardware
			fingerprint MUST select a new Router ID as described in Section 7.3.
	This new LSA is designated for information related to OSPFv3 Auto-		This new LSA is designated for information related to OSPFv3 Auto-
	configuration and, in the future, could be used other auto-		configuration and, in the future, could be used other auto-
	configuration information, e.g., global IPv6 prefixes. However, this		configuration information, e.g., global IPv6 prefixes. However, this
	is beyond the scope of this document.		is beyond the scope of this document.
	7.2.1. OSPFv3 Router Auto-Configuration LSA		7.2.1. OSPFv3 Router Auto-Configuration LSA
	The OSPFv3 Auto-Configuration (AC) LSA has a function code of TBD and		The OSPFv3 Auto-Configuration (AC) LSA has a function code of TBD and
	the S2/S1 bits set to 01 indicating Area Flooding Scope. The U bit		the S2/S1 bits set to 01 indicating Area Flooding Scope. The U bit
	will be set indicating that the OSPFv3 AC LSA should be flooded even		will be set indicating that the OSPFv3 AC LSA should be flooded even
	if it is not understood. The Link State ID (LSID) value will be a		if it is not understood. The Link State ID (LSID) value will be a
	integer index used to discriminate between multiple AC LSAs		integer index used to discriminate between multiple AC LSAs
	originated by the same OSPFv3 Router. This specification only		originated by the same OSPFv3 router. This specification only
	describes the contents of an AC LSA with a Link State ID (LSID) of 0.		describes the contents of an AC LSA with a Link State ID (LSID) of 0.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LS age |1|0|1| TBD |		| LS age |1|0|1| TBD |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Link State ID |		| Link State ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Advertising Router |		| Advertising Router |
	skipping to change at page 14, line 7 ¶		skipping to change at page 9, line 38 ¶
	o		o
	o		o
	o		o
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Router-Hardware-Fingerprint TLV Format		Router-Hardware-Fingerprint TLV Format
	7.3. Duplicate Router ID Resolution		7.3. Duplicate Router ID Resolution
	The OSPFv3 Router selected to resolve the duplicate OSPFv3 Router ID		The OSPFv3 router selected to resolve the duplicate OSPFv3 Router ID
	condition must select a new OSPFv3 Router ID. After selecting a new		condition must select a new OSPFv3 Router ID. After selecting a new
	Router ID, all self-originated LSAs MUST be reoriginated, and any		Router ID, all self-originated LSAs MUST be reoriginated, and any
	OSPFv3 neighbor adjacencies MUST be reestablished. The OSPFv3 router		OSPFv3 neighbor adjacencies MUST be reestablished. The OSPFv3 router
	retaining the Router ID causing the conflict will reoriginate or		retaining the Router ID causing the conflict will reoriginate or
	purge stale any LSAs as described in Section 13.4 [OSPFV2].		purge stale any LSAs as described in Section 13.4 [OSPFV2].
	7.4. Change to RFC 2328 Section 13.4, 'Receiving Self-Originated LSA'		7.4. Change to RFC 2328 Section 13.4, 'Receiving Self-Originated LSA'
	Processing		Processing
	RFC 2328 [OSPFV2], Section 13.4, describes the processing of received		RFC 2328 [OSPFV2], Section 13.4, describes the processing of received
	self-originated LSAs. If the received LSA doesn't exist, the		self-originated LSAs. If the received LSA doesn't exist, the
	receiving router will purge it from the OSPF routing domain. If the		receiving router will purge it from the OSPF routing domain. If the
	LSA is newer than the version in the Link State Database (LSDB), the		LSA is newer than the version in the Link State Database (LSDB), the
	receiving router will originate a newer version by advancing the LSA		receiving router will originate a newer version by advancing the LSA
	sequence number and reflooding. Since it is possible for an auto-		sequence number and reflooding. Since it is possible for an auto-
	configured OSPFv3 router to choose a duplicate OSPFv3 Router ID,		configured OSPFv3 router to choose a duplicate OSPFv3 Router ID,
	OSPFv3 routers implementing this specification should detect when		OSPFv3 routers implementing this specification should detect when
	multiple instances of the same self-originated LSA are purged or		multiple instances of the same self-originated LSA are purged or
	reoriginated since this is indicative of an OSPFv3 router with a		reoriginated since this is indicative of an OSPFv3 router with a
	duplicate Router ID in the OSPFv3 routing domain. When this		duplicate Router ID in the OSPFv3 routing domain. When this
	condition is detected, the OSPFv3 Router SHOULD delay self-originated		condition is detected, the OSPFv3 router SHOULD delay self-originated
	LSA processing for LSAs that have recently been purged or reflooded.		LSA processing for LSAs that have recently been purged or reflooded.
	This specification recommends 10 seconds as the interval defining		This specification recommends 10 seconds as the interval defining
	recent self-originated LSA processing and an exponential back off of		recent self-originated LSA processing and an exponential back off of
	1 to 8 seconds for the processing delay. This additional delay		1 to 8 seconds for the processing delay. This additional delay
	should allow for the mechanisms described in Section 7 to resolve the		should allow for the mechanisms described in Section 7 to resolve the
	duplicate OSPFv3 Router ID conflict.		duplicate OSPFv3 Router ID conflict.
	8. Security Considerations		8. Security Considerations
	A unique OSPFv3 Interface Instance ID is used for auto-configuration		A unique OSPFv3 Interface Instance ID is used for auto-configuration
	skipping to change at page 16, line 15 ¶		skipping to change at page 10, line 44 ¶
	9. Management Considerations		9. Management Considerations
	It is RECOMMENDED that OSPFv3 routers supporting this specification		It is RECOMMENDED that OSPFv3 routers supporting this specification
	also allow explicit configuration of OSPFv3 parameters as specified		also allow explicit configuration of OSPFv3 parameters as specified
	in Appendix C of [OSPFV3]. This is in addition to the authentication		in Appendix C of [OSPFV3]. This is in addition to the authentication
	key configuration recommended in Section 4. However, it is		key configuration recommended in Section 4. However, it is
	acknowledged that there may be some deployment scenarios where manual		acknowledged that there may be some deployment scenarios where manual
	authentication key configuration is not required.		authentication key configuration is not required.
	Since there is a small possibility of OSPFv3 Router ID collisions,		Since there is a small possibility of OSPFv3 Router ID collisions,
	manual configuration of OSPFv3 Router-IDs is RECOMMENDED in OSPFv3		manual configuration of OSPFv3 Router IDs is RECOMMENDED in OSPFv3
	routing domains where route recovergence due to a router ID change is		routing domains where route recovergence due to a router ID change is
	intolerable.		intolerable.
	10. IANA Considerations		10. IANA Considerations
	This specification defines an OSPFv3 LSA Type for the OSPFv3 Auto-		This specification defines an OSPFv3 LSA Type for the OSPFv3 Auto-
	Configuration (AC) LSA, as described in Section 7.2.1. The value TBD		Configuration (AC) LSA, as described in Section 7.2.1. The value TBD
	will be allocated from the existing "OSPFv3 LSA Function Code"		will be allocated from the existing "OSPFv3 LSA Function Code"
	registry for the OSPFv3 Auto-Configuration LSA.		registry for the OSPFv3 Auto-Configuration LSA.
	skipping to change at page 18, line 16 ¶		skipping to change at page 11, line 37 ¶
	11.1. Normative References		11.1. Normative References
	[OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.		[OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
	[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF		[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
	for IPv6", RFC 5340, July 2008.		for IPv6", RFC 5340, July 2008.
	[OSPFV3-AF]		[OSPFV3-AF]
	Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.		Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
	Aggarwal, "Support of Address Families in OSPFv3",		Aggarwal, "Support of Address Families in OSPFv3", RFC
	RFC 5838, April 2010.		5838, April 2010.
	[OSPFV3-AUTH-TRAILER]		[OSPFV3-AUTH-TRAILER]
	Bhatia, M., Manral, V., and A. Lindem, "Supporting		Bhatia, M., Manral, V., and A. Lindem, "Supporting
	Authentication Trailer for OSPFv3", RFC 7166,		Authentication Trailer for OSPFv3", RFC 7166, February
	February 2012.		2012.
	[RFC-KEYWORDS]		[RFC-KEYWORDS]
	Bradner, S., "Key words for use in RFCs to Indicate		Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	[SLAAC] Thomson, S., Narten, T., and J. Tatuya, "IPv6 Stateless		[SLAAC] Thomson, S., Narten, T., and J. Tatuya, "IPv6 Stateless
	Address Autoconfiguration", RFC 4862, September 2007.		Address Autoconfiguration", RFC 4862, September 2007.
	[TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering		[TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering
	Extensions to OSPF", RFC 3630, September 2003.		Extensions to OSPF", RFC 3630, September 2003.
	11.2. Informative References		11.2. Informative References
	[ASYNC-HELLO]		[ASYNC-HELLO]
	Anand, M., Grover, H., and A. Roy, "Asymmetric OSPF Hold		Anand, M., Grover, H., and A. Roy, "Asymmetric OSPF Hold
	Timer", draft-madhukar-ospf-agr-asymmetric-01.txt (work in		Timer", draft-madhukar-ospf-agr-asymmetric-01.txt (work in
	progress).		progress), June 2013.
	[BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		[BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Protocol 4 (BGP-4)", RFC 4271, January 2006.
	[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)		[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
	Registration Authority", IEEE Tutorial http://		Registration Authority", IEEE Tutorial
	standards.ieee.org/regauth/oui/tutorials/EUI64.html,		http://standards.ieee.org/regauth/oui/tutorials/
	March 1997.		EUI64.html, March 1997.
	[IPv6-CPE]		[IPv6-CPE]
	Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic		Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
	Requirements for IPv6 Customer Edge Routers", RFC 7084,		Requirements for IPv6 Customer Edge Routers", RFC 7084,
	November 2013.		November 2013.
	Authors' Addresses		Authors' Addresses
	Acee Lindem		Acee Lindem
	Cisco Systems		Cisco Systems
End of changes. 22 change blocks.
	60 lines changed or deleted		68 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/