< draft-ietf-ospf-ospfv3-autoconfig-13.txt		draft-ietf-ospf-ospfv3-autoconfig-14.txt >
	Network Working Group A. Lindem		Network Working Group A. Lindem
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Updates: 5340 (if approved) J. Arkko		Updates: 5340 (if approved) J. Arkko
	Intended status: Standards Track Ericsson		Intended status: Standards Track Ericsson
	Expires: July 31, 2015 January 27, 2015		Expires: August 13, 2015 February 9, 2015
	OSPFv3 Auto-Configuration		OSPFv3 Auto-Configuration
	draft-ietf-ospf-ospfv3-autoconfig-13.txt		draft-ietf-ospf-ospfv3-autoconfig-14.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
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 July 31, 2015.		This Internet-Draft will expire on August 13, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3		1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
	1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 3		2. OSPFv3 Default Configuration . . . . . . . . . . . . . . . . 3
	2. OSPFv3 Default Configuration . . . . . . . . . . . . . . . . 4		3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 4
	3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 5		3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . 4
	3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . 5		4. OSPFv3 Minimal Authentication Configuration . . . . . . . . . 4
	4. OSPFv3 Minimal Authentication Configuration . . . . . . . . . 5		5. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . 5
	5. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . 6		6. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . 5
	6. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . 6		7. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 5
	7. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 6		7.1. Duplicate Router ID Detection for Neighbors . . . . . . . 6
	7.1. Duplicate Router ID Detection for Neighbors . . . . . . . 7		7.2. Duplicate Router ID Detection for Non-Neighbors . . . . . 6
	7.2. Duplicate Router ID Detection for Non-Neighbors . . . . . 7		7.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . 6
	7.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . 7		7.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 8
	7.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 9		7.3. Duplicate Router ID Resolution . . . . . . . . . . . . . 8
	7.3. Duplicate Router ID Resolution . . . . . . . . . . . . . 9
	7.4. Change to RFC 2328 Section 13.4, 'Receiving Self-		7.4. Change to RFC 2328 Section 13.4, 'Receiving Self-
	Originated LSAs' . . . . . . . . . . . . . . . . . . . . 9		Originated LSAs' . . . . . . . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. Management Considerations . . . . . . . . . . . . . . . . . . 10		9. Management Considerations . . . . . . . . . . . . . . . . . . 10
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	11.1. Normative References . . . . . . . . . . . . . . . . . . 11		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	11.2. Informative References . . . . . . . . . . . . . . . . . 12		12.1. Normative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		12.2. Informative References . . . . . . . . . . . . . . . . . 13
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	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. This document describes
	unchanged from the base OSPFv3 protocol specification [OSPFV3].		extensions to OSPFv3 to enable it to operate in these environments.
			In this mode of operation, the protocol is largely unchanged from the
			base OSPFv3 protocol specification [OSPFV3]. Since the goals of
			auto-configuration and security can be conflicting, operators and
			network administrators should carefully consider their security
			requirements before deploying the solution described in this
			document. Refer to Section 8 for more information.
	The following aspects of OSPFv3 auto-configuration are described:		The following aspects of OSPFv3 auto-configuration are described in
			this document:
	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
	This specification was inspired by the work presented in the Homenet
	working group meeting in October 2011 in Philadelphia, Pennsylvania.
	In particular, we would like to thank Fred Baker, Lorenzo Colitti,
	Ole Troan, Mark Townsley, and Michael Richardson.
	Arthur Dimitrelis and Aidan Williams did prior work in OSPFv3 auto-
	configuration in the expired "Autoconfiguration of routers using a
	link state routing protocol" IETF Draft. There are many similarities
	between the concepts and techniques in this document.
	Thanks for Abhay Roy and Manav Bhatia for comments regarding
	duplicate router-id processing.
	Thanks for Alvaro Retana and Michael Barnes for comments regarding
	OSPFv3 Instance ID auto-configuration.
	Thanks to Faraz Shamim for review and comments.
	Thanks to Mark Smith for the requirement to reduce the adjacency
	formation delay in the back-to-back ethernet topologies that are
	prevalent in home networks.
	Thanks to Les Ginsberg for document review and recommendations on
	OSPFv3 hardware fingerprint content.
	Thanks to Curtis Villamizar for document review and analysis of
	duplicate router-id resolution nuances.
	Thanks to Uma Chunduri for comments during OSPF WG last call.
	Thanks to Martin Vigoureux for Routing Area Directorate review and
	comments.
	Thanks to Adam Montville for Security Area Directorate review and
	comments.
	Thanks to Qin Wu for Operations & Management Area Directorate review
	and comments.
	Thanks to Robert Sparks for General Area (GEN-ART) review and
	comments.
	Thanks to Rama Darbha for review and comments.
	Special thanks go to Markus Stenberg for his implementation of this
	specification in Bird.
	Special thanks also go to David Lamparter for his implementation of
	this specification in Quagga.
	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 for IPv6 on all interfaces		2. OSPFv3 SHOULD be auto-configured on all IPv6-capable interface on
	intended as general IPv6-capable routers. Optionally, an		the router. An interface MAY be excluded if it is clear that
	interface MAY be excluded if it is clear that running OSPFv3 on		running OSPFv3 on the interface is not required. For example, if
	the interface is not required. For example, if manual		manual configuration or another condition indicates that an
	configuration or another condition indicates that an interface is		interface is connected to an Internet Service Provider (ISP),
	connected to an Internet Service Provider (ISP) and there is no		there is typically no need to employ OSPFv3. In fact, [IPv6-CPE]
	Border Gateway Protocol (BGP) [BGP] peering, there is typically		specifically requires that IPv6 Customer Premise Equipment (CPE)
	no need to employ OSPFv3. In fact, [IPv6-CPE] specifically		routers do not initiate any dynamic routing protocol by default
	requires that IPv6 Customer Premise Equipment (CPE) routers do		on the router's WAN, i.e., ISP-facing, interface. In home
	not initiate any dynamic routing protocol by default on the		networking environments, an interface where no OSPFv3 neighbors
	router's WAN, i.e., ISP-facing, interface. In home networking		are found but a DHCP IPv6 prefix can be acquired may be
	environments, an interface where no OSPFv3 neighbors are found		considered an ISP-facing interface and running OSPFv3 is
	but a DHCP IPv6 prefix can be acquired may be considered an ISP-		unnecessary.
	facing interface and running OSPFv3 is unnecessary.
	3. OSPFv3 interfaces will be auto-configured to an interface type		3. OSPFv3 interfaces will be auto-configured to an interface type
	corresponding to their layer-2 capability. For example, Ethernet		corresponding to their layer-2 capability. For example, Ethernet
	interfaces and vanilla Wi-Fi interfaces will be auto-configured		interfaces and Wi-Fi interfaces will be auto-configured as OSPFv3
	as OSPFv3 broadcast networks and Point-to-Point Protocol (PPP)		broadcast networks and Point-to-Point Protocol (PPP) interfaces
	interfaces will be auto-configured as OSPFv3 Point-to-Point		will be auto-configured as OSPFv3 Point-to-Point interfaces.
	interfaces. Most extant OSPFv3 implementations do this already.		Most extant OSPFv3 implementations do this already. Auto-
	Auto-configured operation over wireless networks requiring a		configured operation over wireless networks requiring a point-to-
	point-to-multipoint (P2MP) topology and dynamic metrics based on		multipoint (P2MP) topology and dynamic metrics based on wireless
	wireless feedback is not within the scope of this document.		feedback is not within the scope of this document. However,
	However, auto-configuration is not precluded in these		auto-configuration is not precluded in these environments.
	environments.
	4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and		4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and
	RouterDeadInterval as specified in Section 3. Of course, an		RouterDeadInterval as specified in Section 3. Of course, an
	identical HelloInterval and RouterDeadInterval will still be		identical HelloInterval and RouterDeadInterval will still be
	required to form an adjacency with an OSPFv3 router not		required to form an adjacency with an OSPFv3 router not
	supporting auto-configuration [OSPFV3].		supporting auto-configuration [OSPFV3].
	5. All OSPFv3 interfaces SHOULD be auto-configured to use an		5. All OSPFv3 interfaces SHOULD be auto-configured to use an
	Interface Instance ID of 0 that corresponds to the base IPv6		Interface Instance ID of 0 that corresponds to the base IPv6
	unicast address family instance ID as defined in [OSPFV3-AF].		unicast address family instance ID as defined in [OSPFV3-AF].
	skipping to change at page 6, line 5 ¶		skipping to change at page 4, line 50 ¶
	adjacency formation delay. Note that this value is not included in		adjacency formation delay. Note that this value is not included in
	OSPFv3 Hello packets and does not impact interoperability.		OSPFv3 Hello packets and does not impact interoperability.
	4. OSPFv3 Minimal Authentication Configuration		4. OSPFv3 Minimal Authentication Configuration
	In many deployments, the requirement for OSPFv3 authentication		In many deployments, the requirement for OSPFv3 authentication
	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		It is RECOMMENDED that the password entered as ASCII hexadecimal
	interfaces with the Security Association Identifier (SA ID) set to 1		digits and that 32 or more digits to facilitate a password with a
	and HMAC-SHA-256 used as the authentication algorithm.		high degree of entropy. When configured, the password will be used
			on all auto-configured interfaces with the Security Association
			Identifier (SA ID) set to 1 and HMAC-SHA-256 used as the
			authentication algorithm.
	5. OSPFv3 Router ID Selection		5. OSPFv3 Router ID Selection
	An OSPFv3 router requires a unique Router ID within the OSPFv3		An OSPFv3 router requires a unique Router ID within the OSPFv3
	routing domain for correct protocol operation. Existing Router ID		routing domain for correct protocol operation. Existing Router ID
	selection algorithms (section C.1 in [OSPFV2] and [OSPFV3]) are not		selection algorithms (section C.1 in [OSPFV2] and [OSPFV3]) are not
	viable since they are dependent on a unique IPv4 interface address		viable since they are dependent on a unique IPv4 interface address
	which is not likely to be available in autoconfigured deployments.		which is not likely to be available in autoconfigured deployments.
	An OSPFv3 router implementing this specification will select a		An OSPFv3 router implementing this specification will select a
	router-id that has a high probability of uniqueness. A pseudo-random		router-id that has a high probability of uniqueness. A pseudo-random
	skipping to change at page 9, line 13 ¶		skipping to change at page 8, line 13 ¶
	configuration information.		configuration information.
	7.2.2. Router-Hardware-Fingerprint TLV		7.2.2. Router-Hardware-Fingerprint TLV
	The Router-Hardware-Fingerprint TLV is the first TLV defined for the		The Router-Hardware-Fingerprint TLV is the first TLV defined for the
	OSPFv3 Auto-Configuration (AC) LSA. It will have type 1 and MUST be		OSPFv3 Auto-Configuration (AC) LSA. It will have type 1 and MUST be
	advertised in the LSID OSPFv3 AC LSA with an LSID of 0. It SHOULD		advertised in the LSID OSPFv3 AC LSA with an LSID of 0. It SHOULD
	occur, at most, once and the first instance of the TLV will take		occur, at most, once and the first instance of the TLV will take
	precedence over subsequent TLV instances. The length of the Router-		precedence over subsequent TLV instances. The length of the Router-
	Hardware-Fingerprint is variable but must be 32 octets or greater.		Hardware-Fingerprint is variable but must be 32 octets or greater.
			If the Router-Hardware-Fingerprint TLV is not present as the first
			TLV, the AC-LSA is considered malformed and is ignored for the
			purposes of duplicate Router ID detection. Additionally, the event
			SHOULD be logged.
	The contents of the hardware fingerprint MUST be some combination of		The contents of the hardware fingerprint MUST have an extremely high
	MAC addresses, CPU ID, or serial number(s) that provides an extremely		probability of uniqueness. It SHOULD be constructed from the
	high probability of uniqueness. It is RECOMMENDED that one or more		concatenation of a number of local values that themselves have a high
	available universal tokens (e.g., IEEE 802 48-bit MAC addresses or		likelihood of uniqueness, such as MAC addresses, CPU ID, or serial
	IEEE EUI-64 Identifiers [EUI64]) associated with the OSPFv3 router be		numbers. It is RECOMMENDED that one or more available universal
	included in the hardware fingerprint. It MUST be based on hardware		tokens (e.g., IEEE 802 48-bit MAC addresses or IEEE EUI-64
	attributes that will not change across hard and soft restarts.		Identifiers [EUI64]) associated with the OSPFv3 router be included in
			the hardware fingerprint. It MUST be based on hardware attributes
			that will not change across hard and soft restarts.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 1 | >32 |		| 1 | >32 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Router Hardware Fingerprint |		| Router Hardware Fingerprint |
	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. The OSPFv3 router
	Router ID, all self-originated LSAs MUST be reoriginated, and any		SHOULD reduce the possibility of a subsequent Router ID collision by
	OSPFv3 neighbor adjacencies MUST be reestablished. The OSPFv3 router		checking the Link State Database for an OSPFv3 Auto-Configuration LSA
	retaining the Router ID causing the conflict will reoriginate or		with the newly selected Router ID and a different Router-Hardware-
	purge stale any LSAs as described in Section 13.4 [OSPFV2].		Fingerprint. If one is detected, a new Router ID should be selected
			without going through the resolution process Section 7. After
			selecting a new Router ID, all self-originated LSAs MUST be
			reoriginated, and any OSPFv3 neighbor adjacencies MUST be
			reestablished. The OSPFv3 router retaining the Router ID causing the
			conflict will reoriginate or purge stale any LSAs as described in
			Section 13.4 [OSPFV2].
	7.4. Change to RFC 2328 Section 13.4, 'Receiving Self-Originated LSAs'		7.4. Change to RFC 2328 Section 13.4, 'Receiving Self-Originated LSAs'
	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,
	skipping to change at page 10, line 33 ¶		skipping to change at page 9, line 45 ¶
	The goals of security and complete OSPFv3 auto-configuration are		The goals of security and complete OSPFv3 auto-configuration are
	somewhat contradictory. When no explicit security configuration		somewhat contradictory. When no explicit security configuration
	takes place, auto-configuration implies that additional devices		takes place, auto-configuration implies that additional devices
	placed in the network are automatically adopted as a part of the		placed in the network are automatically adopted as a part of the
	network. However, auto-configuration can also be combined with		network. However, auto-configuration can also be combined with
	password configuration (see Section 4) or future extensions for		password configuration (see Section 4) or future extensions for
	automatic pairing between devices. These mechanisms can help provide		automatic pairing between devices. These mechanisms can help provide
	an automatically configured, securely routed network.		an automatically configured, securely routed network.
	In deployments where stronger authentification or encryption is		In deployments where different authentification algorithm, per-
	required, OSPFv3 IPsec [OSPFV3-IPSEC] or stronger OSPFv3		interface keys, or encryption is required, OSPFv3 IPsec
	Authentication trailer [OSPFV3-AUTH-TRAILER] algorithms MAY be used		[OSPFV3-IPSEC] or alternate OSPFv3 Authentication trailer
	at the expense of additional configuration. The configuration and		[OSPFV3-AUTH-TRAILER] algorithms MAY be used at the expense of
	operational description of such deployments is beyond the scope of		additional configuration. The configuration and operational
	this document.		description of such deployments is beyond the scope of this document.
			However, a deployment could always revert to explicit configuration
			as described in Section 9 for features such as IPsec, per-interface
			keys, or alternate authentication algorithms.
			The introduction, either malious or accidental, of an OSPFv3 router
			with a duplicate Router ID is an attack point for OSPFv3 routing
			domains. This is due to the fact that OSPFv3 routers will interpret
			LSAs advertised by the router with the same ROuter ID as self-
			originated LSAs and attempt to purge them from the routing domain.
			The mechanisms in Section 7.4 will mitigate the effects of
			duplication.
	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 support explicit configuration of OSPFv3 parameters as specified
	in Appendix C of [OSPFV3]. The would allow explicit override of		in Appendix C of [OSPFV3]. The would allow explicit override of
	autoconfigured parameters in situations where it is required (e.g.,		autoconfigured parameters in situations where it is required (e.g.,
	if the deployment requires multiple OSPFv3 areas). This is in		if the deployment requires multiple OSPFv3 areas). This is in
	addition to the authentication key configuration recommended in		addition to the authentication key configuration recommended in
	Section 4 which supports OSPFv3 authentication with the absolute		Section 4. Additionally, it is RECOMMENDED that OSPFv3 routers
	minimum manual configuration.		supporting this specification allow autoconfiguration to be
			completely disabled.
	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.
			OSPFv3 Routers supporting this specification MUST augment mechanisms
			for displaying or otherwise conveying OSPFv3 operational state to
			indicate whether or not the OSPFv3 router was autoconfigured and
			whether or not its OSPFv3 interfaces have been auto-configured.
	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.
	This specification also creates a registry for OSPFv3 Auto-		This specification also creates a registry for OSPFv3 Auto-
	Configuration (AC) LSA TLVs. This registry should be placed in the		Configuration (AC) LSA TLVs. This registry should be placed in the
	existing OSPFv3 IANA registry, and new values can be allocated via		existing OSPFv3 IANA registry, and new values can be allocated via
	skipping to change at page 11, line 32 ¶		skipping to change at page 11, line 12 ¶
	Three initial values are allocated:		Three initial values are allocated:
	o 0 is marked as reserved.		o 0 is marked as reserved.
	o 1 is Router-Hardware-Fingerprint TLV (Section 7.2.2).		o 1 is Router-Hardware-Fingerprint TLV (Section 7.2.2).
	o 65535 is an Auto-configuration-Experiment-TLV, a common value that		o 65535 is an Auto-configuration-Experiment-TLV, a common value that
	can be used for experimental purposes.		can be used for experimental purposes.
	11. References		11. Acknowledgments
	11.1. Normative References		This specification was inspired by the work presented in the Homenet
			working group meeting in October 2011 in Philadelphia, Pennsylvania.
			In particular, we would like to thank Fred Baker, Lorenzo Colitti,
			Ole Troan, Mark Townsley, and Michael Richardson.
			Arthur Dimitrelis and Aidan Williams did prior work in OSPFv3 auto-
			configuration in the expired "Autoconfiguration of routers using a
			link state routing protocol" IETF Draft. There are many similarities
			between the concepts and techniques in this document.
			Thanks for Abhay Roy and Manav Bhatia for comments regarding
			duplicate router-id processing.
			Thanks for Alvaro Retana and Michael Barnes for comments regarding
			OSPFv3 Instance ID auto-configuration.
			Thanks to Faraz Shamim for review and comments.
			Thanks to Mark Smith for the requirement to reduce the adjacency
			formation delay in the back-to-back ethernet topologies that are
			prevalent in home networks.
			Thanks to Les Ginsberg for document review and recommendations on
			OSPFv3 hardware fingerprint content.
			Thanks to Curtis Villamizar for document review and analysis of
			duplicate router-id resolution nuances.
			Thanks to Uma Chunduri for comments during OSPF WG last call.
			Thanks to Martin Vigoureux for Routing Area Directorate review and
			comments.
			Thanks to Adam Montville for Security Area Directorate review and
			comments.
			Thanks to Qin Wu for Operations & Management Area Directorate review
			and comments.
			Thanks to Robert Sparks for General Area (GEN-ART) review and
			comments.
			Thanks to Rama Darbha for review and comments.
			Special thanks to Adrian Farrel for his in-depth review, copious
			comments, and suggested text.
			Special thanks go to Markus Stenberg for his implementation of this
			specification in Bird.
			Special thanks also go to David Lamparter for his implementation of
			this specification in Quagga.
			The RFC text was produced using Marshall Rose's xml2rfc tool.
			12. References
			12.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", RFC		Aggarwal, "Support of Address Families in OSPFv3", RFC
	5838, April 2010.		5838, April 2010.
	skipping to change at page 12, line 15 ¶		skipping to change at page 13, line 5 ¶
	[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		12.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), June 2013.		progress), June 2013.
	[BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
	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		Registration Authority", IEEE Tutorial
	http://standards.ieee.org/regauth/oui/tutorials/		http://standards.ieee.org/regauth/oui/tutorials/
	EUI64.html, March 1997.		EUI64.html, March 1997.
	[IANA-GUIDELINES]		[IANA-GUIDELINES]
	Narten, T. and H. Alvestrand, "Guidelines for Writing an		Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Sectino in RFCs", RFC 5226, May 2008.		IANA Considerations Sectino in RFCs", RFC 5226, May 2008.
	[IPv6-CPE]		[IPv6-CPE]
End of changes. 24 change blocks.
	133 lines changed or deleted		169 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/