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/