Diff: draft-ietf-ospf-ospfv3-autoconfig-12.txt - draft-ietf-ospf-ospfv3-autoconfig-13.txt

	< draft-ietf-ospf-ospfv3-autoconfig-12.txt	draft-ietf-ospf-ospfv3-autoconfig-13.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 20, 2015 January 16, 2015	Expires: July 31, 2015 January 27, 2015

	OSPFv3 Auto-Configuration	OSPFv3 Auto-Configuration

	draft-ietf-ospf-ospfv3-autoconfig-12.txt	draft-ietf-ospf-ospfv3-autoconfig-13.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 20, 2015.	This Internet-Draft will expire on July 31, 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

	skipping to change at page 2, line 19 ¶	skipping to change at page 2, line 19 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2	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 . . . . . . . . . . . . . . . . 4	2. OSPFv3 Default Configuration . . . . . . . . . . . . . . . . 4
	3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 5	3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 5
	3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . 5	3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . 5
	4. OSPFv3 Minimal Authentication Configuration . . . . . . . . . 5	4. OSPFv3 Minimal Authentication Configuration . . . . . . . . . 5
	5. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . 6	5. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . 6
	6. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . 6	6. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . 6
	7. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 6	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 OSPFv3 Routers that are	7.2. Duplicate Router ID Detection for Non-Neighbors . . . . . 7
	not Neighbors . . . . . . . . . . . . . . . . . . . . . . 7
	7.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . 7	7.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . 7
	7.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 9	7.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 9
	7.3. Duplicate Router ID Resolution . . . . . . . . . . . . . 9	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 LSA' Processing . . . . . . . . . . . . . . . 9	Originated LSAs' . . . . . . . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. Management Considerations . . . . . . . . . . . . . . . . . . 10	9. Management Considerations . . . . . . . . . . . . . . . . . . 10
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	11.1. Normative References . . . . . . . . . . . . . . . . . . 11	11.1. Normative References . . . . . . . . . . . . . . . . . . 11
	11.2. Informative References . . . . . . . . . . . . . . . . . 12	11.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12

	1. Introduction	1. Introduction


	skipping to change at page 4, line 8 ¶	skipping to change at page 4, line 8 ¶

	Thanks to Adam Montville for Security Area Directorate review and	Thanks to Adam Montville for Security Area Directorate review and
	comments.	comments.

	Thanks to Qin Wu for Operations & Management Area Directorate review	Thanks to Qin Wu for Operations & Management Area Directorate review
	and comments.	and comments.

	Thanks to Robert Sparks for General Area (GEN-ART) review and	Thanks to Robert Sparks for General Area (GEN-ART) review and
	comments.	comments.


		Thanks to Rama Darbha for 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


	skipping to change at page 6, line 10 ¶	skipping to change at page 6, line 12 ¶
	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

	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. An OSPFv3 router	routing domain for correct protocol operation. Existing Router ID
	implementing this specification will select a router-id that has a	selection algorithms (section C.1 in [OSPFV2] and [OSPFV3]) are not
	high probability of uniqueness. A pseudo-random number SHOULD be	viable since they are dependent on a unique IPv4 interface address
	used for the OSPFv3 Router ID. The generation SHOULD be seeded with	which is not likely to be available in autoconfigured deployments.
	a variable that is likely to be unique in the applicable OSPFv3	An OSPFv3 router implementing this specification will select a
	router deployment. A good choice of seed would be some portion or	router-id that has a high probability of uniqueness. A pseudo-random
	hash of the Router-Hardware-Fingerprint as described in	number SHOULD be used for the OSPFv3 Router ID. The generation
	Section 7.2.2.	SHOULD be seeded with a variable that is likely to be 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


	skipping to change at page 7, line 13 ¶	skipping to change at page 7, line 19 ¶
	IPv6 link-local source address. Once this occurs, the OSPFv3 router	IPv6 link-local source address. Once this occurs, the OSPFv3 router
	with the numerically smaller IPv6 link-local address will need to	with the numerically smaller IPv6 link-local address will need to
	select a new Router ID as described in Section 7.3. Note that the	select a new Router ID as described in Section 7.3. Note that the
	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 Non-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 detect received Auto-Configuration LSAs with its	specification MUST detect received Auto-Configuration LSAs with its
	Router ID specified in the LSA header. LSAs received with the local	Router ID specified in the LSA header. LSAs received with the local
	OSPFv3 Router's Router ID in the LSA header are perceived as self-	OSPFv3 Router's Router ID in the LSA header are perceived as self-

	skipping to change at page 9, line 45 ¶	skipping to change at page 9, line 45 ¶

	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 LSAs'
	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

	skipping to change at page 11, line 20 ¶	skipping to change at page 11, line 20 ¶
	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

	IETF Consensus or IESG Approval.	IETF Review or, under exceptional circumstances, IESG Approval.
		[IANA-GUIDELINES]

	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.


	skipping to change at page 12, line 26 ¶	skipping to change at page 12, line 30 ¶
	progress), June 2013.	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	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]
		Narten, T. and H. Alvestrand, "Guidelines for Writing an
		IANA Considerations Sectino in RFCs", RFC 5226, May 2008.

	[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.

	[OSPFV3-IPSEC]	[OSPFV3-IPSEC]
	Gupta, M. and S. Melam, "Authentication/Confidentiality	Gupta, M. and S. Melam, "Authentication/Confidentiality
	for OSPFv3", RFC 4552, June 2006.	for OSPFv3", RFC 4552, June 2006.

	Authors' Addresses	Authors' Addresses

End of changes. 11 change blocks.
	20 lines changed or deleted	27 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/