< draft-ietf-ospf-ospfv3-autoconfig-03.txt		draft-ietf-ospf-ospfv3-autoconfig-04.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: February 20, 2014 August 19, 2013		Expires: February 20, 2014 August 19, 2013
	OSPFv3 Auto-Configuration		OSPFv3 Auto-Configuration
	draft-ietf-ospf-ospfv3-autoconfig-03.txt		draft-ietf-ospf-ospfv3-autoconfig-04.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 12, line 4 ¶		skipping to change at page 12, line 4 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Router-Hardware-Fingerprint TLV Format		Router-Hardware-Fingerprint TLV Format
	6.3. Duplicate Router ID Resolution		6.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 of		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].
	6.4. Change to RFC 2328 Section 13.4, 'Receiving Self-Originated LSA'		6.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
	skipping to change at page 12, line 27 ¶		skipping to change at page 12, line 27 ¶
	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 6 to resolve the		should allow for the mechanisms described in Section 6 to resolve the
	duplication OSPFv3 Router ID conflict.		duplicate OSPFv3 Router ID conflict.
	7. Security Considerations		7. Security Considerations
	A unique OSPFv3 Interface Instance ID is used for auto-configuration		A unique OSPFv3 Interface Instance ID is used for auto-configuration
	to prevent inadvertent OSPFv3 adjacency formation, see Section 2		to prevent inadvertent OSPFv3 adjacency formation, see Section 2
	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
	skipping to change at page 16, line 38 ¶		skipping to change at page 16, line 38 ¶
	[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.
	10.2. Informative References		10.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-00.txt (work in		Timer", draft-madhukar-ospf-agr-asymmetric-01.txt (work in
	progress).		progress).
	[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.
	Authors' Addresses		Authors' Addresses
	Acee Lindem		Acee Lindem
	Ericsson		Ericsson
	301 Midenhall Way		301 Midenhall Way
End of changes. 4 change blocks.
	4 lines changed or deleted		4 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/