< draft-acee-ospf-ospfv3-autoconfig-02.txt		draft-acee-ospf-ospfv3-autoconfig-03.txt >
	Network Working Group A. Lindem		Network Working Group A. Lindem
	Internet-Draft J. Arkko		Internet-Draft J. Arkko
	Intended status: Standards Track Ericsson		Intended status: Standards Track Ericsson
	Expires: November 29, 2012 May 28, 2012		Expires: January 10, 2013 July 9, 2012
	OSPFv3 Auto-Configuration		OSPFv3 Auto-Configuration
	draft-acee-ospf-ospfv3-autoconfig-02.txt		draft-acee-ospf-ospfv3-autoconfig-03.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 34 ¶		skipping to change at page 1, line 34 ¶
	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 November 29, 2012.		This Internet-Draft will expire on January 10, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	4. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . . 6		4. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . . 6
	5. OSPFv3 Duplicate Router-ID Detection and Resolution . . . . . 7		5. OSPFv3 Duplicate Router-ID Detection and Resolution . . . . . 7
	5.1. Duplicate Router-ID Detection for Neighbors . . . . . . . 7		5.1. Duplicate Router-ID Detection for Neighbors . . . . . . . 7
	5.2. Duplicate Router-ID Detection for OSPFv3 Routers that		5.2. Duplicate Router-ID Detection for OSPFv3 Routers that
	are not Neighbors . . . . . . . . . . . . . . . . . . . . 7		are not Neighbors . . . . . . . . . . . . . . . . . . . . 7
	5.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . . 7		5.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . . 7
	5.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 9		5.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 9
	5.3. Duplicate Router-ID Resolution . . . . . . . . . . . . . . 9		5.3. Duplicate Router-ID Resolution . . . . . . . . . . . . . . 9
	5.4. Change to Received Self-Originated LSA Processing . . . . 10		5.4. Change to Received Self-Originated LSA Processing . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. Management Considerations . . . . . . . . . . . . . . . . . . 12
	8. Normative References . . . . . . . . . . . . . . . . . . . . . 13		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		9. Normative References . . . . . . . . . . . . . . . . . . . . . 14
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	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
	skipping to change at page 3, line 42 ¶		skipping to change at page 3, line 42 ¶
	Ole Troan, Mark Townsley, and Michael Richardson.		Ole Troan, Mark Townsley, and Michael Richardson.
	Arthur Dimitrelis and Aidan Williams did prior work in OSPFv3 auto-		Arthur Dimitrelis and Aidan Williams did prior work in OSPFv3 auto-
	configuration in the expired "Autoconfiguration of routers using a		configuration in the expired "Autoconfiguration of routers using a
	link state routing protocol" IETF Draft. There are many similarities		link state routing protocol" IETF Draft. There are many similarities
	between the concepts and techniques in this document.		between the concepts and techniques in this document.
	Thanks for Abhay Roy and Manav Bhatia for comments regarding		Thanks for Abhay Roy and Manav Bhatia for comments regarding
	duplicate router-id processing.		duplicate router-id processing.
			Thanks for Alvaro Retana and Michael Barnes for comments regarding
			OSPFv3 Instance ID auto-configuration.
	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 on 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 an other condition indicates that an interface		configuration or an other condition indicates that an interface
	is connected to an Internet Service Provider (ISP), there is		is connected to an Internet Service Provider (ISP), there is
	typically no need to employ OSPv3. However, note that in many		typically no need to employ OSPFv3. However, note that in many
	environments it can be useful to test whether an OSPFv3 adjacency		environments it can be useful to test whether an OSPFv3 adjacency
	can be established. In home networking environments, an		can be established. In home networking environments, an
	interface where no OSPFv3 neighbors are found but a DHCP prefix		interface where no OSPFv3 neighbors are found but a DHCP prefix
	can be acquired may be considered as an ISP interface.		can be acquired may be considered as an ISP interface.
	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 will be auto-configured as broadcast networks and		interfaces will be auto-configured as broadcast networks and
	Point-to-Point Protocol (PPP) interfaces will be auto-configured		Point-to-Point Protocol (PPP) interfaces will be auto-configured
	as Point-to-Point interfaces. Most extant OSPFv3 implementations		as Point-to-Point interfaces. Most extant OSPFv3 implementations
	do this already.		do this already.
	4. OSPFv3 interfaces MUST auto-configure the default HelloInterval		4. OSPFv3 interfaces MUST auto-configure the default HelloInterval
	and RouterDeadInterval as specified in [OSPFV3].		and RouterDeadInterval as specified in [OSPFV3].
	5. All OSPFv3 interfaces SHOULD auto-configure the Interface		5. All OSPFv3 interfaces SHOULD be auto-configured to use an
	Instance ID to be the IANA reserved value TBD to prevent		Interface Instance ID of 0 that corresponds to the base IPv6
	inadvertent adjacencies with OSPFv3 implementation that don't		unicast address family instance ID as defined in [OSPFV3-AF].
	support this specification. Implementations SHOULD add a simple		Similarly, if IPv4 unicast addresses are advertised in a separate
	configuration option to disable this and use the default OSPFv3		auto-configured OSPFv3 instance, the base IPv4 unicast address
	Interface Instance ID, if interoperability with legacy OSPFv3		family instance ID value, i.e., 64, SHOULD be auto-configured as
	routers is desired.		the Interface Instance ID for all interfaces corresponding to the
			OSPFv3 instance [OSPFV3-AF].
	3. OSPFv3 Router ID Selection		3. OSPFv3 Router ID Selection
	As OSPFv3 Router implementing this specification must select a unique		As OSPFv3 Router implementing this specification must select a unique
	Router-ID. A pseudo-random number SHOULD be used for the OSPFv3		Router-ID. A pseudo-random number SHOULD be used for the OSPFv3
	Router-ID. The generation should be seeded with a variable that is		Router-ID. The generation should be seeded with a variable that is
	likely to be unique in that environment. A good choice of seed would		likely to be unique in that environment. A good choice of seed would
	be some portion or hash of the Route-Hardware-Fingerprint as		be some portion or hash of the Route-Hardware-Fingerprint as
	described in Section 5.2.2.		described in Section 5.2.2.
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	pairing between devices. These mechanisms can help provide an		pairing between devices. These mechanisms can help provide an
	automatically configured, securely routed network.		automatically configured, securely routed network.
	It is RECOMMENDED that OSPFv3 routers supporting this specification		It is RECOMMENDED that OSPFv3 routers supporting this specification
	also offer an option to explicitly configure a password for HMAC- SHA		also offer an option to explicitly configure a password for HMAC- SHA
	authentication as described in [OSPFV3-AUTH-TRAILER]. When		authentication as described in [OSPFV3-AUTH-TRAILER]. When
	configured, the password will be used on all auto-configured		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 will be used as the authentication algorithm.		and HMAC-SHA-256 will be used as the authentication algorithm.
	7. IANA Considerations		7. Management Considerations
	This specification allocates a new OSPFv3 Interface Instance ID, TBD,		It is RECOMMENDED that OSPFv3 routers supporting this specification
	for OSPFv3 auto-configured interfaces as described in Section 2. The		also allow explicit configuration of OSPFv3 parameters as specified
	"OSPFv3 Instance ID Address Family Values" registry should be		in Appendix C of [OSPFV3]. This is in addition to the authentication
	extended to include Instance ID allocations other than those		key configuration recommended in Section 6. However, it is
	corresponding to address families.		acknowledged that there may be some deployment scenarios where manual
			configuration is not required.
			8. IANA Considerations
	This specification allocates a new OSPFv3 LSA, OSPFv3 Auto-		This specification allocates a new OSPFv3 LSA, OSPFv3 Auto-
	Configuration (AC) LSA, TBD, as described in Section 5.2.1.		Configuration (AC) LSA, TBD, as described in Section 5.2.1.
	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
	IETF Consensus or IESG Approval.		IETF Consensus or IESG Approval.
	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 5.2.2).		o 1 is Router-Hardware-Fingerprint TLV (Section 5.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.
	8. Normative References		9. 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]
			Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
			Aggarwal, "Support of Address Families in OSPFv3",
			RFC 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 6506,		Authentication Trailer for OSPFv3", RFC 6506,
	February 2012.		February 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
End of changes. 11 change blocks.
	21 lines changed or deleted		34 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/