Diff: draft-ietf-ospf-ospfv3-autoconfig-05.txt - draft-ietf-ospf-ospfv3-autoconfig-06.txt

	< draft-ietf-ospf-ospfv3-autoconfig-05.txt	draft-ietf-ospf-ospfv3-autoconfig-06.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: April 23, 2014 October 20, 2013	Expires: August 14, 2014 February 10, 2014

	OSPFv3 Auto-Configuration	OSPFv3 Auto-Configuration

	draft-ietf-ospf-ospfv3-autoconfig-05.txt	draft-ietf-ospf-ospfv3-autoconfig-06.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 April 23, 2014.	This Internet-Draft will expire on August 14, 2014.

	Copyright Notice	Copyright Notice


	Copyright (c) 2013 IETF Trust and the persons identified as the	Copyright (c) 2014 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

	skipping to change at page 2, line 33 ¶	skipping to change at page 2, line 33 ¶
	3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 7	3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 7
	3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . . 7	3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . . 7
	4. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . . 8	4. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . . 8
	5. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . . 9	5. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . . 9
	6. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 10	6. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 10
	6.1. Duplicate Router ID Detection for Neighbors . . . . . . . 10	6.1. Duplicate Router ID Detection for Neighbors . . . . . . . 10
	6.2. Duplicate Router ID Detection for OSPFv3 Routers that	6.2. Duplicate Router ID Detection for OSPFv3 Routers that
	are not Neighbors . . . . . . . . . . . . . . . . . . . . 10	are not Neighbors . . . . . . . . . . . . . . . . . . . . 10
	6.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . . 10	6.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . . 10
	6.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 12	6.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 12

	6.3. Duplicate Router ID Resolution . . . . . . . . . . . . . . 12	6.3. Duplicate Router ID Resolution . . . . . . . . . . . . . . 13
	6.4. Change to RFC 2328 Section 13.4, 'Receiving	6.4. Change to RFC 2328 Section 13.4, 'Receiving
	Self-Originated LSA' Processing . . . . . . . . . . . . . 13	Self-Originated LSA' Processing . . . . . . . . . . . . . 13
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 14	7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	8. Management Considerations . . . . . . . . . . . . . . . . . . 15	8. Management Considerations . . . . . . . . . . . . . . . . . . 15
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 17	10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	10.2. Informative References . . . . . . . . . . . . . . . . . . 17	10.2. Informative References . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18


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

	Thanks for Alvaro Retana and Michael Barnes for comments regarding	Thanks for Alvaro Retana and Michael Barnes for comments regarding
	OSPFv3 Instance ID auto-configuration.	OSPFv3 Instance ID auto-configuration.

	Thanks to Faraz Shamim for review and comments.	Thanks to Faraz Shamim for review and comments.

	Thanks to Mark Smith for the requirement to reduce the adjacency	Thanks to Mark Smith for the requirement to reduce the adjacency
	formation delay in the back-to-back ethernet topologies that are	formation delay in the back-to-back ethernet topologies that are
	prevalent in home networks.	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.

	The RFC text was produced using Marshall Rose's xml2rfc tool.	The RFC text was produced using Marshall Rose's xml2rfc tool.

	Special thanks go to Markus Stenberg for his implementation of this	Special thanks go to Markus Stenberg for his implementation of this
	specification.	specification.

	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:


	skipping to change at page 8, line 11 ¶	skipping to change at page 8, line 11 ¶
	Designated Router (DR) flapping but is preferable to the long	Designated Router (DR) flapping but is preferable to the long
	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 Router ID Selection	4. 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 the applicable OSPFv3 router deployment. A	likely to be unique in the applicable OSPFv3 router deployment. A

	good choice of seed would be some portion or hash of the Route-	good choice of seed would be some portion or hash of the Router-
	Hardware-Fingerprint as described in Section 6.2.2.	Hardware-Fingerprint as described in Section 6.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 6 and Section 6.3.	Section 6 and Section 6.3. OSPFv3 Routers SHOULD maintain the last
		successfully chosen Router ID in non-volatile storage to avoid
		collisions subsequent to when an autoconfigured OSPFv3 router is
		first added to the OSPFv3 routing domain.

	5. OSPFv3 Adjacency Formation	5. 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
	has completed Duplicate Address Detection (DAD) as specified in IPv6	has completed Duplicate Address Detection (DAD) as specified in IPv6
	Stateless Address Autoconfiguration [SLAAC]. Otherwise, the only	Stateless Address Autoconfiguration [SLAAC]. Otherwise, the only
	changes to the OSPFv3 base specification are supporting	changes to the OSPFv3 base specification are supporting

	skipping to change at page 12, line 23 ¶	skipping to change at page 12, line 23 ¶

	6.2.2. Router-Hardware-Fingerprint TLV	6.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.


	The contents of the hardware fingerprint SHOULD be some combination	The contents of the hardware fingerprint MUST be some combination of
	of MAC addresses, CPU ID, or serial number(s) that provides an	MAC addresses, CPU ID, or serial number(s) that provides an extremely
	extremely high probability of uniqueness. It MUST be based on	high probability of uniqueness. It is RECOMMENDED that one or more
	hardware attributes that will not change across hard and soft	available universal tokens (e.g., IEEE 802 48-bit MAC addresses or
	restarts.	IEEE EUI-64 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

	skipping to change at page 16, line 5 ¶	skipping to change at page 15, line 14 ¶

	8. Management Considerations	8. 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 7. However, it is	key configuration recommended in Section 7. 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,
		manual configuration of OSPFv3 Router-IDs is RECOMMENDED in OSPFv3
		routing domains where route recovergence due to a router ID change is
		intolerable.

	9. IANA Considerations	9. 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 6.2.1. The value TBD	Configuration (AC) LSA, as described in Section 6.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 17, line 44 ¶	skipping to change at page 17, line 44 ¶
	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-01.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.


		[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
		Registration Authority", IEEE Tutorial http://
		standards.ieee.org/regauth/oui/tutorials/EUI64.html,
		March 1997.

	[IPv6-CPE]	[IPv6-CPE]
	Singh, H., Beebee, W., Donley, C., Stark, B., and O.	Singh, H., Beebee, W., Donley, C., Stark, B., and O.
	Troan, "Basic Requirements for IPv6 Customer Edge	Troan, "Basic Requirements for IPv6 Customer Edge
	Routers", RFC 6204, April 2011.	Routers", RFC 6204, April 2011.

	Authors' Addresses	Authors' Addresses

	Acee Lindem	Acee Lindem
	Ericsson	Ericsson
	301 Midenhall Way	301 Midenhall Way

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