idnits 2.17.00 (12 Aug 2021) /tmp/idnits10480/draft-behringer-lla-only-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2012) is 3589 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-grow-private-ip-sp-cores has been published as RFC 6752 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Behringer 3 Internet-Draft E. Vyncke 4 Intended status: Informational Cisco 5 Expires: January 17, 2013 July 16, 2012 7 Using Only Link-Local Addressing Inside an IPv6 Network 8 draft-behringer-lla-only-01 10 Abstract 12 This document proposes to use only IPv6 link-local addresses on 13 infrastructure links between routers, wherever possible. It 14 discusses the advantages and disadvantages of this approach to aide 15 the decision process for a given network, 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 17, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 50 2. Using Link-Local Address on Infrastructure Links . . . . . . . 3 51 2.1. The Suggested Approach . . . . . . . . . . . . . . . . . . 3 52 2.2. Advantages . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.3. Caveats and Possible Workarounds . . . . . . . . . . . . . 5 54 2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 60 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 An infrastructure link between a set of routers typically does not 66 require global or even unique local addressing [RFC4193]. Using 67 link-local addressing on such links has a number of advantages, for 68 example that routing tables do not need to carry link addressing, and 69 can therefore be significantly smaller. This helps to decrease 70 failover times in certain routing convergence events. An interface 71 of a router is also not reachable beyond the link boundaries, 72 therefore reducing the attack horizon. 74 We propose to configure neither globally routable IPv6 addresses nor 75 unique local addresses on infrastructure links of routers, wherever 76 possible. We recommend to use exclusively link-local addresses on 77 such links. 79 This document discusses the advantages and caveats of this approach. 81 1.1. Requirements Language 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119] when they 86 appear in ALL CAPS. These words may also appear in this document in 87 lower case as plain English words, absent their normative meanings. 89 2. Using Link-Local Address on Infrastructure Links 91 This document proposes to use only link-local addresses (LLA) on all 92 router interfaces on infrastructure links. Routers typically do not 93 need to be reached from from users of the network, nor from outside 94 the network. For an network operator there may be reasons to send 95 packets to an infrastructure link for certain monitoring tasks; we 96 suggest that many of those tasks could also be handled differently, 97 not requiring routable address space on infrastructure links. 99 2.1. The Suggested Approach 101 Neither global IPv6 addresses nor unique local addresses are 102 configured on infrastructure links. In the absence of specific 103 global or unique local address definitions, the default behavior of 104 routers is to use link-local addresses. These link-local addresses 105 MAY be hard-coded to prevent the change of EUI-64 addresses when 106 changing of MAC address (such as after changing a network interface 107 card). 109 ICMPv6 [RFC4443] error messages (packet-too-big...) are required for 110 routers, therefore a loopback interface MUST be configured with a 111 global scope IPv6 address. This global scope IPv6 address MUST be 112 used as the source IPv6 address for all generated ICMPv6 messages. 114 The effect on specific traffic types is as follows: 116 o Control plane protocols, such as BGP, ISIS, OSPFv3, RIPng, PIM 117 work by default or can be configured to work with link-local 118 addresses. 120 o Management plane traffic, such as SSH, Telnet, SNMP, ICMP echo 121 request ... can be addressed to loopback addresses of routers with 122 a global scope address. Router management can also be done over 123 out-of-band channels. 125 o ICMP error message can also be sourced from the global scope 126 loopback address. 128 o Data plane traffic is forwarded independently of the link address 129 type. 131 o Neighbor discovery (neighbor solicitation and neighbor 132 advertisement) is done by using link-local unicast and multicast 133 addresses, therefore neighbor discovery is not affected. 135 We therefore conclude that it is possible to construct a working 136 network in this way. 138 2.2. Advantages 140 Smaller routing tables: Since the routing protocol only needs to 141 carry one loopback address per router, it is smaller than in the 142 traditional approach where every infrastructure link addresses are 143 carried in the routing protocol. This reduces memory consumption, 144 and increases the convergence speed in some routing failover cases. 145 Note: smaller routing tables can also be achieved by putting 146 interfaces in passive mode for the IGP. 148 Reduced attack surface: Every globally routable address on a router 149 constitutes a potential attack point: a remote attacker can send 150 traffic to that address, for example a TCP SYN flood, or he can 151 intent SSH brute force password attacks. If a network only uses 152 loopback addresses for the routers, only those loopback addresses 153 need to be protected from outside the network. This significantly 154 eases protection measures, such as infrastructure access control 155 lists. See also [I-D.ietf-grow-private-ip-sp-cores] for further 156 discussion on this topic. 158 Lower configuration complexity: LLAs require no specific 159 configuration, thereby lowering the complexity and size of router 160 configurations. This also reduces the likelihood of configuration 161 mistakes. 163 Simpler DNS: Less address space in use also means less DNS mappings 164 to maintain. 166 2.3. Caveats and Possible Workarounds 168 Interface ping: If an interface doesn't have a globally routable 169 address, it can only be pinged from a node on the same link. 170 Therefore it is not possible to ping a specific link interface 171 remotely. A possible workaround is to ping the loopback address of a 172 router instead. In most cases today it is not possible to see which 173 link the packet was received on; however, RFC5837 [RFC5837] suggests 174 to include the interface identifier of the interface a packet was 175 received on in the ICMP response; it must be noted that there are 176 little implemented of this extension. With this approach it would be 177 possible to ping a router on the loopback address, yet see which 178 interface the packet was received on. To check liveliness of a 179 specific interface it may be necessary to use other methods, for 180 example to connect to the router via SSH and to check locally. 182 Traceroute: Similar to the ping case, a reply to a traceroute packet 183 would come from a loopback address with a global address. Today this 184 does not display the specific interface the packets came in on. Also 185 here, RFC5837 [RFC5837] provides a solution. 187 Hardware dependency: LLAs are usually EUI-64 based, hence, they 188 change when the MAC address is changed. This could pose problem in a 189 case where the routing neighbor must be configured explicitly (e.g. 190 BGP) and a line card needs to be physically replaced hence changing 191 the EUI-64 LLA and breaking the routing neighborship. But, LLAs can 192 be statically configured such as fe80::1 and fe80::2 which can be 193 used to configure any required static routing neighborship. 195 NMS toolkits: If there is any NMS tool that makes use of interface IP 196 address of a router to carry out any of NMS functions, then it would 197 no longer work, if the interface is missing globally routable 198 address. A possible workaround for such tools is to use the globally 199 routable lopback address of the router instead. 201 MPLS and RSVP-TE [RFC3209] allows establishing MPLS LSP on a path 202 that is explicitly identified by a strict sequence of IP prefixes or 203 addresses (each pertaining to an interface or a router on the path). 204 This is commonly used for FRR. However, if an interface uses only a 205 link-local address, then such LSPs can not be established. A 206 possible workaround is to use loose sequence of IP prefixes or 207 addresses (each pertaining to a router) to identify an explicit path 208 along with shared-risk-link-group (to not use a set of common 209 interfaces). 211 2.4. Summary 213 Using link-local addressing only on infrastructure links has a number 214 of advantages, such as a smaller routing table size and a reduced 215 attack surface. It also simplifies router configurations. However, 216 the way certain network management tasks are carried out has to be 217 adapted to provide the same level of detail, for example interface 218 identifiers in traceroute. 220 3. Security Considerations 222 Using LLAs only on infrastructure links reduces the attack surface of 223 a router: Loopback addresses with globally routed addresses are still 224 reachable and must be secured, but infrastructure links can only be 225 attacked from the local link. This simplifies security of control 226 and management planes. The proposal does not impact the security of 227 the data plane. This proposal does not address control plane 228 [RFC6192] attacks generated by data plane packets (such as hop-limit 229 expiration). 231 As in the traditional approach, also this approach relies on the 232 assumption that all routers can be trusted due to physical and 233 operational security. 235 4. IANA Considerations 237 There are no IANA considerations or implications that arise from this 238 document. 240 5. Acknowledgements 242 The authors would like to thank Salman Asadullah, Janos Mohacsi and 243 Wes George for their useful comments about this work. 245 6. References 246 6.1. Normative References 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, March 1997. 251 6.2. Informative References 253 [I-D.ietf-grow-private-ip-sp-cores] 254 Kirkham, A., "Issues with Private IP Addressing in the 255 Internet", draft-ietf-grow-private-ip-sp-cores-05 (work in 256 progress), June 2012. 258 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 259 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 260 Tunnels", RFC 3209, December 2001. 262 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 263 Addresses", RFC 4193, October 2005. 265 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 266 Message Protocol (ICMPv6) for the Internet Protocol 267 Version 6 (IPv6) Specification", RFC 4443, March 2006. 269 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 270 Rivers, "Extending ICMP for Interface and Next-Hop 271 Identification", RFC 5837, April 2010. 273 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 274 Router Control Plane", RFC 6192, March 2011. 276 Authors' Addresses 278 Michael Behringer 279 Cisco 280 400 Avenue Roumanille, Bat 3 281 Biot, 06410 282 France 284 Email: mbehring@cisco.com 285 Eric Vyncke 286 Cisco 287 De Kleetlaan, 6A 288 Diegem, 1831 289 Belgium 291 Email: evyncke@cisco.com