draft-ietf-opsec-lla-only-07.txt		draft-ietf-opsec-lla-only-08.txt
	OPsec Working Group M. Behringer		OPsec Working Group M. Behringer
	Internet-Draft E. Vyncke		Internet-Draft E. Vyncke
	Intended status: Informational Cisco		Intended status: Informational Cisco
	Expires: August 17, 2014 February 13, 2014		Expires: November 15, 2014 May 14, 2014
	Using Only Link-Local Addressing Inside an IPv6 Network		Using Only Link-Local Addressing Inside an IPv6 Network
	draft-ietf-opsec-lla-only-07		draft-ietf-opsec-lla-only-08
	Abstract		Abstract
	In an IPv6 network it is possible to use only link-local addresses on		In an IPv6 network it is possible to use only link-local addresses on
	infrastructure links between routers. This document discusses the		infrastructure links between routers. This document discusses the
	advantages and disadvantages of this approach to help the decision		advantages and disadvantages of this approach to help the decision
	process for a given network.		process for a given network.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 33		skipping to change at page 1, line 33
	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 August 17, 2014.		This Internet-Draft will expire on November 15, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Using Link-Local Address on Infrastructure Links . . . . . . 2		2. Using Link-Local Addressing on Infrastructure Links . . . . . 2
	2.1. The Approach . . . . . . . . . . . . . . . . . . . . . . 2		2.1. The Approach . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Advantages . . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Advantages . . . . . . . . . . . . . . . . . . . . . . . 4
	2.3. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.3. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.4. Internet Exchange Points . . . . . . . . . . . . . . . . 6		2.4. Internet Exchange Points . . . . . . . . . . . . . . . . 6
	2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7		2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 7		3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	6. Informative References . . . . . . . . . . . . . . . . . . . 8		6. Informative References . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	An infrastructure link between a set of routers typically does not		An infrastructure link between a set of routers typically does not
	require global or unique local addresses [RFC4193]. Using only link-		require global or unique local addresses [RFC4193]. Using only link-
	local addressing on such links has a number of advantages. For		local addressing on such links has a number of advantages. For
	example, that routing tables do not need to carry link addressing,		example, that routing tables do not need to carry link addressing,
	and can therefore be significantly smaller. This helps to decrease		and can therefore be significantly smaller. This helps to decrease
	failover times in certain routing convergence events. An interface		failover times in certain routing convergence events. An interface
	of a router is also not reachable beyond the link boundaries,		of a router is also not reachable beyond the link boundaries,
	therefore reducing the attack horizon.		therefore reducing the attack horizon.
	This document discusses the advantages and caveats of this approach.		This document discusses the advantages and caveats of this approach.
	2. Using Link-Local Address on Infrastructure Links		Note that some traditionally used techniques to operate a network
			such as pinging interfaces, or seeing interface information in a
			traceroute do not work with this approach. Details are discussed
			below.
			2. Using Link-Local Addressing on Infrastructure Links
	This document discusses the approach of using only link-local		This document discusses the approach of using only link-local
	addresses (LLA) on all router interfaces on infrastructure links.		addresses (LLA) on all router interfaces on infrastructure links.
	Routers don't typically need to receive packets from hosts or nodes		Routers don't typically need to receive packets from hosts or nodes
	outside the network. For a network operator, there may be reasons to		outside the network. For a network operator, there may be reasons to
	use greater than link-local scope addresses on infrastructure		use greater than link-local scope addresses on infrastructure
	interfaces for certain operational tasks, such as pings to an		interfaces for certain operational tasks, such as pings to an
	interface or traceroutes across the network. This document discusses		interface or traceroutes across the network. This document discusses
	such cases and proposes alternative procedures.		such cases and proposes alternative procedures.
	skipping to change at page 3, line 17		skipping to change at page 3, line 25
	must be configured with an IPv6 address with a greater scope than		must be configured with an IPv6 address with a greater scope than
	link-local. This address will usually be a loopback interface with a		link-local. This address will usually be a loopback interface with a
	global scope address belonging to the operator and part of an		global scope address belonging to the operator and part of an
	announced prefix (with a suitable prefix length) to avoid being		announced prefix (with a suitable prefix length) to avoid being
	dropped by other routers implementing [RFC3704]. This is		dropped by other routers implementing [RFC3704]. This is
	implementation dependent. For the remainder of this document we will		implementation dependent. For the remainder of this document we will
	refer to this interface as a "loopback interface".		refer to this interface as a "loopback interface".
	[RFC6724] recommends that greater than link-local scope IPv6		[RFC6724] recommends that greater than link-local scope IPv6
	addresses are used as the source IPv6 address for all generated		addresses are used as the source IPv6 address for all generated
	ICMPv6 messages sent to a non link-local address, with the exception		ICMPv6 messages sent to a non-link-local address, with the exception
	of ICMPv6 redirect messages, as defined in [RFC4861] section 4.5.		of ICMPv6 redirect messages, as defined in [RFC4861] section 4.5.
	The effect on specific traffic types is as follows:		The effect on specific traffic types is as follows:
	o Most control plane protocols, such as BGP [RFC4271], ISIS [IS-IS],		o Most control plane protocols, such as BGP [RFC4271], ISIS [IS-IS],
	OSPFv3 [RFC5340], RIPng [RFC2080], PIM [RFC4609] work by default		OSPFv3 [RFC5340], RIPng [RFC2080], PIM [RFC4609] work by default
	or can be configured to work with link-local addresses.		or can be configured to work with link-local addresses.
	Exceptions are explained in the caveats section (Section 2.3).		Exceptions are explained in the caveats section (Section 2.3).
	o Management plane traffic, such as SSH [RFC4251], Telnet [RFC0495],		o Management plane traffic, such as SSH [RFC4251], Telnet [RFC0495],
	skipping to change at page 4, line 12		skipping to change at page 4, line 19
	The following list of advantages is in no particular order.		The following list of advantages is in no particular order.
	Smaller routing tables: Since the routing protocol only needs to		Smaller routing tables: Since the routing protocol only needs to
	carry one global address (the loopback interface) per router, it is		carry one global address (the loopback interface) per router, it is
	smaller than the traditional approach where every infrastructure link		smaller than the traditional approach where every infrastructure link
	address is carried in the routing protocol. This reduces memory		address is carried in the routing protocol. This reduces memory
	consumption, and increases the convergence speed in some routing		consumption, and increases the convergence speed in some routing
	failover cases. Because the Forwarding Information Base to be		failover cases. Because the Forwarding Information Base to be
	downloaded to line cards is smaller and there are fewer prefixes in		downloaded to line cards is smaller and there are fewer prefixes in
	the Routing Information Base, the routing algorithm is accellerated.		the Routing Information Base, the routing algorithm is accelerated.
	Note: smaller routing tables can also be achieved by putting		Note: smaller routing tables can also be achieved by putting
	interfaces in passive mode for the Interior Gateway Protocol (IGP).		interfaces in passive mode for the Interior Gateway Protocol (IGP).
	Simpler address management: Only loopback interface addresses need to		Simpler address management: Only loopback interface addresses need to
	be considered in an addressing plan. This also allows for easier		be considered in an addressing plan. This also allows for easier
	renumbering.		renumbering.
	Lower configuration complexity: link-local addresses require no		Lower configuration complexity: link-local addresses require no
	specific configuration, thereby lowering the complexity and size of		specific configuration, thereby lowering the complexity and size of
	router configurations. This also reduces the likelihood of		router configurations. This also reduces the likelihood of
	configuration mistakes.		configuration mistakes.
	Simpler DNS: Less routable address space in use also means less		Simpler DNS: Less routable address space in use also means less
	reverse and forward mapping DNS resource records to maintain.		reverse and forward mapping DNS resource records to maintain. Of
			course, if the operator selects not to enter any global interface
			addresses in the DNS anyway, then this is less of an advantage.
	Reduced attack surface: Every routable address on a router		Reduced attack surface: Every routable address on a router
	constitutes a potential attack point: a remote attacker can send		constitutes a potential attack point: a remote attacker can send
	traffic to that address. Examples are a TCP SYN flood (see		traffic to that address. Examples are a TCP SYN flood (see
	[RFC4987]), or SSH brute force password attacks. If a network only		[RFC4987]) and SSH brute force password attacks. If a network only
	uses the addresses of the router loopback interface(s), only those		uses the addresses of the router loopback interface(s), only those
	addresses need to be protected from outside the network. This may		addresses need to be protected from outside the network. This may
	ease protection measures, such as infrastructure access control		ease protection measures, such as infrastructure access control lists
	lists.		(iACL).
	Without using link-local addresses, it is still possible to achieve		Without using link-local addresses, it is still possible to achieve
	the same result if the network addressing scheme is set up such that		the simple iACL if the network addressing scheme is set up such that
	all link and loopback interfaces have greater than link-local		all link and loopback interfaces have greater than link-local
	addresses and are aggregatable, and if the infrastructure access list		addresses and are aggregatable, and if the infrastructure access list
	covers that entire aggregated space. See also [RFC6752] for further		covers that entire aggregated space. See also [RFC6752] for further
	discussion on this topic.		discussion on this topic.
	[RFC6860] describes another approach to hide addressing on		[RFC6860] describes another approach to hide addressing on
	infrastructure links for OSPFv2 and OSPFv3, by modifying the existing		infrastructure links for OSPFv2 and OSPFv3, by modifying the existing
	protocols. This document does not modify any protocol, however it		protocols. This document does not modify any protocol, however it
	works only for IPv6.		works only for IPv6.
	skipping to change at page 5, line 38		skipping to change at page 5, line 43
	interface if it only has a link-local address.		interface if it only has a link-local address.
	Hardware dependency: LLAs are usually EUI-64 based, hence, they		Hardware dependency: LLAs are usually EUI-64 based, hence, they
	change when the MAC address is changed. This could pose problem in a		change when the MAC address is changed. This could pose problem in a
	case where the routing neighbor must be configured explicitly (e.g.		case where the routing neighbor must be configured explicitly (e.g.
	BGP) and a line card needs to be physically replaced hence changing		BGP) and a line card needs to be physically replaced hence changing
	the EUI-64 LLA and breaking the routing neighborship. LLAs can be		the EUI-64 LLA and breaking the routing neighborship. LLAs can be
	statically configured such as fe80::1 and fe80::2 which can be used		statically configured such as fe80::1 and fe80::2 which can be used
	to configure any required static routing neighborship. However, this		to configure any required static routing neighborship. However, this
	static LLA configuration may be more complex to operate than		static LLA configuration may be more complex to operate than
	statically configured greater than link-local addresses, because the		statically configured greater than link-local scope addresses,
	link scope must also be considered, as in this example: 'BGP neighbor		because LLAs are inherently ambiguous for a multi-link node such as a
	fe80::1%eth0 is down'.		router; to deal with the ambiguity, the link zone index must also be
			considered explicitly, e.g., using the extended textual notation
			described in [RFC4007] as in this example: 'BGP neighbor fe80::1%eth0
			is down'.
	Network Management System (NMS) toolkits: if there is any NMS tool		Network Management System (NMS) toolkits: if there is any NMS tool
	that makes use of interface IP address of a router to carry out any		that makes use of interface IP address of a router to carry out any
	of its NMS functions, then it would no longer work if the interface		of its NMS functions, then it would no longer work if the interface
	does not have a routable address. A possible workaround for such		does not have a routable address. A possible workaround for such
	tools is to use the routable address of the router loopback interface		tools is to use the routable address of the router loopback interface
	instead. Most vendor implementations allow the specification of		instead. Most vendor implementations allow the specification of
	loopback interface addresses for SYSLOG, IPfix, and SNMP. The		loopback interface addresses for SYSLOG, IPfix, and SNMP. The
	protocol LLDP (IEEE 802.1AB-2009) runs directly over Ethernet and		protocol LLDP (IEEE 802.1AB-2009) runs directly over Ethernet and
	does not require any IPv6 address, so dynamic network discovery is		does not require any IPv6 address, so dynamic network discovery is
	not hindered when using LLDP. But, network discovery based on NDP		not hindered when using LLDP. But, network discovery based on NDP
	cache content will only display the link-local addresses and not the		cache content will only display the link-local addresses and not the
	addresses of the loopback interfaces; therefore, network discovery		addresses of the loopback interfaces; therefore, network discovery
	should rather be based on the Route Information Base to detect		should rather be based on the Route Information Base to detect
	adjacent nodes.		adjacent nodes.
	MPLS and RSVP-TE [RFC3209] allows establishing MPLS LSP on a path		MPLS and RSVP-TE [RFC3209] allow establishing a MPLS LSP on a path
	that is explicitly identified by a strict sequence of IP prefixes or		that is explicitly identified by a strict sequence of IP prefixes or
	addresses (each pertaining to an interface or a router on the path).		addresses (each pertaining to an interface or a router on the path).
	This is commonly used for Fast Re-Route (FRR). However, if an		This is commonly used for Fast Re-Route (FRR). However, if an
	interface uses only a link-local address, then such LSPs cannot be		interface uses only a link-local address, then such LSPs cannot be
	established. At the time of writing this document, there is no		established. At the time of writing this document, there is no
	workaround for this case; therefore, where RSVP-TE is being used, the		workaround for this case; therefore, where RSVP-TE is being used, the
	approach described in this document does not work.		approach described in this document does not work.
	2.4. Internet Exchange Points		2.4. Internet Exchange Points
	skipping to change at page 8, line 10		skipping to change at page 8, line 17
	4. IANA Considerations		4. IANA Considerations
	There are no IANA considerations or implications that arise from this		There are no IANA considerations or implications that arise from this
	document.		document.
	5. Acknowledgements		5. Acknowledgements
	The authors would like to thank Salman Asadullah, Brian Carpenter,		The authors would like to thank Salman Asadullah, Brian Carpenter,
	Bill Cerveny, Benoit Claise, Rama Darbha, Simon Eng, Wes George,		Bill Cerveny, Benoit Claise, Rama Darbha, Simon Eng, Wes George,
	Fernando Gont, Jen Linkova, Harald Michl, Janos Mohacsi, Ivan		Fernando Gont, Jen Linkova, Harald Michl, Janos Mohacsi, Ivan
	Pepelnjak, and Alvaro Retana for their useful comments about this		Pepelnjak, Alvaro Retana, Jinmei Tatuya and Peter Yee for their
	work.		useful comments about this work.
	6. Informative References		6. Informative References
	[I-D.ietf-opsec-bgp-security]		[I-D.ietf-opsec-bgp-security]
	Durand, J., Pepelnjak, I., and G. Doering, "BGP operations		Durand, J., Pepelnjak, I., and G. Doering, "BGP operations
	and security", draft-ietf-opsec-bgp-security-02 (work in		and security", draft-ietf-opsec-bgp-security-03 (work in
	progress), January 2014.		progress), April 2014.
	[IS-IS] ISO/IEC 10589, , "Intermediate System to Intermediate		[IS-IS] ISO/IEC 10589, , "Intermediate System to Intermediate
	System Intra-Domain Routing Exchange Protocol for use in		System Intra-Domain Routing Exchange Protocol for use in
	Conjunction with the Protocol for Providing the		Conjunction with the Protocol for Providing the
	Connectionless-mode Network Service (ISO 8473)", June		Connectionless-mode Network Service (ISO 8473)", June
	1992.		1992.
	[RFC0495] McKenzie, A., "Telnet Protocol specifications", RFC 495,		[RFC0495] McKenzie, A., "Telnet Protocol specifications", RFC 495,
	May 1973.		May 1973.
	skipping to change at page 8, line 43		skipping to change at page 9, line 5
	[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,		[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
	January 1997.		January 1997.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001.		Tunnels", RFC 3209, December 2001.
	[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed		[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
	Networks", BCP 84, RFC 3704, March 2004.		Networks", BCP 84, RFC 3704, March 2004.
			[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
			B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
			March 2005.
	[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast		[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
	Addresses", RFC 4193, October 2005.		Addresses", RFC 4193, October 2005.
	[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)		[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
	Protocol Architecture", RFC 4251, January 2006.		Protocol Architecture", RFC 4251, January 2006.
	[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		[RFC4271] 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.
	[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control		[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
End of changes. 18 change blocks.
	24 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/