< draft-ietf-ospf-ospfv3-autoconfig-01.txt		draft-ietf-ospf-ospfv3-autoconfig-02.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: October 16, 2013 April 14, 2013		Expires: October 17, 2013 April 15, 2013
	OSPFv3 Auto-Configuration		OSPFv3 Auto-Configuration
	draft-ietf-ospf-ospfv3-autoconfig-01.txt		draft-ietf-ospf-ospfv3-autoconfig-02.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 October 16, 2013.		This Internet-Draft will expire on October 17, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 5, line 24 ¶		skipping to change at page 5, line 24 ¶
	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 another condition indicates that an interface is		configuration or another condition indicates that an interface is
	connected to an Internet Service Provider (ISP) and there is no		connected to an Internet Service Provider (ISP) and there is no
	Border Gateway Protocol (BGP) [BGP] peering, there is typically		Border Gateway Protocol (BGP) [BGP] peering, there is typically
	no need to employ OSPFv3. However, note that in many		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 IPv6		interface where no OSPFv3 neighbors are found but a DHCP IPv6
	prefix can be acquired may be considered as an ISP-facing		prefix can be acquired may be considered an ISP-facing interface
	interface and running OSPFv3 is unnecessary.		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 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. Auto-configured operation over wireless		do this already. Auto-configured operation over wireless
	networks required point-to-multipoint (P2MP) and dynamic metrics		networks requiring a point-to-multipoint (P2MP) topology and
	based on wireless feedback is not within the scope of this		dynamic metrics based on wireless feedback is not within the
	document. However, auto-configuration is not precluded in these		scope of this document. However, auto-configuration is not
	environments.		precluded in these environments.
	4. OSPFv3 interfaces MAY use arbitrary HelloInterval and		4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and
	RouterDeadInterval as specified in Section 3. Of course,		RouterDeadInterval as specified in Section 3. Of course, an
	identical an 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].
	Similarly, if IPv4 unicast addresses are advertised in a separate		Similarly, if IPv4 unicast addresses are advertised in a separate
	auto-configured OSPFv3 instance, the base IPv4 unicast address		auto-configured OSPFv3 instance, the base IPv4 unicast address
	family instance ID value, i.e., 64, SHOULD be auto-configured as		family instance ID value, i.e., 64, SHOULD be auto-configured as
	the Interface Instance ID for all interfaces corresponding to the		the Interface Instance ID for all interfaces corresponding to the
	OSPFv3 instance [OSPFV3-AF].		OSPFv3 instance [OSPFV3-AF].
	3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility		3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility
	Auto-configured OSPFv3 routers will not require identical an		Auto-configured OSPFv3 routers will not require an identical
	HelloInterval and RouterDeadInterval to form adjacencies. Rather,		HelloInterval and RouterDeadInterval to form adjacencies. Rather,
	the received HelloInterval will be ignored and the received		the received HelloInterval will be ignored and the received
	RouterDeadInterval will be used to determine OSPFv3 liveliness with		RouterDeadInterval will be used to determine OSPFv3 liveliness with
	the sending router. In other words, the Inactivity Timer for each		the sending router. In other words, the Inactivity Timer for each
	neighbor will reflect that neighbor's advertised RouterDeadInterval		neighbor will reflect that neighbor's advertised RouterDeadInterval
	and MAY be different from other OSPFv3 routers on the link without		and MAY be different from other OSPFv3 routers on the link without
	impacting adjacency formation. A similar mechanism requiring		impacting adjacency formation. A similar mechanism requiring
	additional signaling is being proposed for all OSPFv2 and OSPFv3		additional signaling is proposed for all OSPFv2 and OSPFv3 routers
	routers [ASYNC-HELLO].		[ASYNC-HELLO].
	3.1. Wait Timer Reduction		3.1. Wait Timer Reduction
	In many situations, auto-configured OSPFv3 routers will be deployed		In many situations, auto-configured OSPFv3 routers will be deployed
	in environments where back-to-back ethernet connections are utilized.		in environments where back-to-back ethernet connections are utilized.
	When this is the case, an OSPFv3 broadcast interface will not come up		When this is the case, an OSPFv3 broadcast interface will not come up
	until the other OSPFv3 router is connected and the routers will wait		until the other OSPFv3 router is connected and the routers will wait
	RouterDeadInterval seconds before forming an adjacency [OSPFV2]. In		RouterDeadInterval seconds before forming an adjacency [OSPFV2]. In
	order to reduce this delay, an auto-configured OSPFv3 router MAY		order to reduce this delay, an auto-configured OSPFv3 router MAY
	reduce the wait interval to a value no less than (HelloInterval + 1),		reduce the wait interval to a value no less than (HelloInterval + 1),
	skipping to change at page 8, line 15 ¶		skipping to change at page 8, line 15 ¶
	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
	HelloInterval/RouterDeadInterval flexibility as described in		HelloInterval/RouterDeadInterval flexibility as described in
	Section 3. and duplicate Router ID detection and resolution as		Section 3 and duplicate Router ID detection and resolution as
	described in Section 6 and Section 6.3.		described in Section 6 and Section 6.3.
	6. OSPFv3 Duplicate Router ID Detection and Resolution		6. OSPFv3 Duplicate Router ID Detection and Resolution
	There are two cases of duplicate OSPFv3 Router ID detection. One		There are two cases of duplicate OSPFv3 Router ID detection. One
	where the OSPFv3 router with the duplicate Router ID is directly		where the OSPFv3 router with the duplicate Router ID is directly
	connected and one where it is not. In both cases, the resolution is		connected and one where it is not. In both cases, the resolution is
	for one of the routers with the duplicate OSPFv3 Router ID to select		for one of the routers with the duplicate OSPFv3 Router ID to select
	a new one.		a new one.
End of changes. 9 change blocks.
	16 lines changed or deleted		16 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/