idnits 2.17.00 (12 Aug 2021) /tmp/idnits3429/draft-white-linklocal-capability-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4291], [RFC4271]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 145: '...hops with a peer SHOULD advertise the ...' RFC 2119 keyword, line 172: '... of the MP_REACH_NLRI, it MUST set the...' RFC 2119 keyword, line 178: '... it MUST set the length of the Next ...' RFC 2119 keyword, line 181: '...eld, the speaker SHOULD provide a loca...' RFC 2119 keyword, line 187: '...(only) next hops MUST not be reflected...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: For internal BGP peers configured as a route-reflector, when route-reflector isn't configured to be in the data-path, the proposed link-local (only) next hops MUST not be reflected. -- The document date (December 2021) is 150 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5309 ** Obsolete normative reference: RFC 5549 (Obsoleted by RFC 8950) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Interdomain Routing R.W. White 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track D.A. Abraitis 5 Expires: 10 June 2022 Hostinger 6 December 2021 8 Link-Local Next Hop Capability for BGP 9 draft-white-linklocal-capability-00 11 Abstract 13 BGP, described in [RFC4271], was originally designed to provide 14 reachability between domains and between the edges of a domain. As 15 such, BGP assumes the next hop towards any reachable destination may 16 not reside on the advertising speaker, but rather may either be 17 through a router connected to the same subnet as the speaker, or 18 through a router only reachable by traversing multiple hops through 19 the network. Because of this, BGP does not recognize the use of IPv6 20 link-local addresses, as described in [RFC4291], as a valid next hop 21 for forwarding purposes. 23 However, BGP speakers are now often deployed on point-to-point links 24 in networks where multihop reachability of any kind is not assumed or 25 desired (all next hops are assumed to be the speaker reachable 26 through a directly connected point-to-point link). This is common, 27 for instance, in data center fabrics. In these situations, a global 28 IPv6 address is not required for the advertisement of reachability 29 information; in fact, providing global IPv6 addresses in these kinds 30 of networks can be detrimental to Zero Touch Provisioning (ZTP). 32 This draft standardizes the operation of BGP over a point-to-point 33 link using link-local IPv6 addressing only. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 4 June 2022. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Revised BSD License text as 62 described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Revised BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Link-Local Next Hop Capability . . . . . . . . . . . . . . . 3 69 3. Changes to BGP Next Hop Attribute to Support Link-Local on 70 Point-to-Point . . . . . . . . . . . . . . . . . . . . . 4 71 4. Receiver Processing of IPv6 Link-Local Forwarding 72 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 73 5. Error handling . . . . . . . . . . . . . . . . . . . . . . . 5 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 79 9.2. Informative References . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 BGP, described in [RFC4271], was originally designed to provide 85 reachability between domains and between the edges of a domain. As 86 such, BGP assumes the next hop towards any reachable destination may 87 not reside on the advertising speaker, but rather may either be 88 through a router connected to the same subnet as the speaker, or 89 through a router only reachable by traversing multiple hops through 90 the network. Because of this, BGP does not recognize the use of IPv6 91 link-local addresses, as described in [RFC4271], as a valid next hop 92 for forwarding purposes. 94 However, BGP speakers are now often deployed on point-to-point links 95 in networks where multihop reachability of any kind is not assumed or 96 desired (all next hops are assumed to be the speaker reachable 97 through a directly connected point-to-point link). This is common, 98 for instance, in data center fabrics. In these situations, a global 99 IPv6 address is not required for the advertisement of reachability 100 information; in fact, providing global IPv6 addresses in these kinds 101 of networks can be detrimental to Zero Touch Provisioning (ZTP). 103 Such BGP deployment models require BGP to run on each link, and any 104 ease or simplification of BGP configuration can result in simplifying 105 orchestration and configuration management. This proposal is a step 106 in that direction. 108 With the requirement of any global interface address being removed by 109 this new capability, BGP neighbor configuration can be further 110 simplified by making it (look) address-family independent. E.g. BGP 111 can just take the interface name for the peer config and link-local 112 IPv6 address of the peer can be learned via a discovery protocol 113 running on the link or by an out-of-band tool. In essence, link- 114 local next hop in combination with [RFC5549] makes it possible to 115 achieve an unnumbered interface-like solution [RFC5309] in BGP. 117 2. Link-Local Next Hop Capability 119 The Link-Local Next Hop capability is a new BGP capability. A BGP 120 speaker that supports capabilities advertisement [RFC5492] in an OPEN 121 message should send this capability only when: 123 1. It is capable of sending link-local IPv6 address as the only next 124 hop address for a route. 126 2. The implementation is capable of processing link-local address 127 next hops with the help of peer interface binding to come up with 128 interface-specific next hops for its routing table. 130 The presence of this capability does not affect the support of global 131 IPv6 only (16 bytes next hop) and global IPv6 combined with link- 132 local IPv6 (32 bytes next hop), which should continue to be supported 133 as before. The Capability Code for this capability is TBA (based on 134 the procedure described in the IANA Considerations section of this 135 document). The Capability Length field of this capability is 0. 137 The advantage of using this capability is that it can let two 138 conforming implementations interoperate [correctly] without 139 additional configuration, in contrast to the current situation. 140 Existing implementations of using a BGP next hop over an IPv6 link- 141 local address are [inconsistent], and can't readily change their 142 behavior without negative side effects. 144 A BGP speaker that is willing to use (send and receive) only link- 145 local addresses as next hops with a peer SHOULD advertise the Link- 146 Local Next Hop Capability to the peer using BGP Capabilities 147 advertisement. 149 The peers have the flexibility to include both link-local and global 150 next hops or link-local only next hop. 152 3. Changes to BGP Next Hop Attribute to Support Link-Local on Point-to- 153 Point 155 [RFC2545], section 2, notes link-local IPv6 addresses are not 156 generally suitable for use in the Next Hop field of the 157 MP_REACH_NLRI. In order to support the many uses of link-local 158 addresses, however, [RFC2545] constructs the Next Hop field in IPv6 159 route advertisements by setting the length of the field to 32, and 160 including both a link-local and global IPv6 address in the resulting 161 enlarged field. In this way, the receiving BGP speaker can use the 162 global IPv6 address to build local forwarding information, and the 163 link-local address for ICMPv6 redirects, etc. [RFC2545] does not, 164 however, provide an explanation for situations where there is only a 165 link-local IPv6 address in the Next Hop field of the MP_REACH_NLRI. 166 The result is each implementation that supports link-local peering 167 along with forwarding to a link-local address has implemented the 168 construction of the Next Hop field in the MP_REACH_NLRI when there is 169 only a link-local address available in slightly different ways. 171 If an implementation intends to send a single link-local forwarding 172 address in the Next Hop field of the MP_REACH_NLRI, it MUST set the 173 length of the Next Hop field to 16 and include only the IPv6 link- 174 local address in the Next Hop field. 176 If an implementation intends to send both a link-local and global 177 IPv6 forwarding address in the Next Hop field of the MP_REACH_NLRI, 178 it MUST set the length of the Next Hop field to 32 and include both 179 the IPv6 link-local and global IPv6 forwarding addresses in the Next 180 Hop field. If both link local and global IPv6 forwarding addresses 181 are carried in the Next Hop Field, the speaker SHOULD provide a local 182 configuration option to determine which address is preferred for 183 forwarding. 185 For internal BGP peers configured as a route-reflector, when route- 186 reflector isn't configured to be in the data-path, the proposed link- 187 local (only) next hops MUST not be reflected. 189 A single (only) link-local next hop address needs to always be reset 190 as next hop self when passed to another link. 192 4. Receiver Processing of IPv6 Link-Local Forwarding Addresses 194 On receiving an MP_REACH_NLRI with a Next Hop length of 16, 195 implementations SHOULD form the forwarding information using the IPv6 196 next hop contained in the Next Hop field, regardless of whether it is 197 a link-local or globally reachable IPv6 address. 199 Implementations MAY check the validity of any IPv6 link-local address 200 used to calculate forwarding information by insuring the address is 201 in the local neighbor table for the interface on which the BGP update 202 was received (or through which the BGP speaker from which the update 203 was received is reachable). There MUST be a configuration option to 204 enable/disable this check. 206 Note: It is possible that checking the IPv6 neighbor table for the 207 existence or validity of a link-local next hop may make instances 208 where a link is being overwhelmed through some form of Denial of 209 Service (DoS) attack worse than they would otherwise be. If the IPv6 210 neighbor cache is overrun in a way that causes the link-local address 211 being used for BGP peering to be removed from the table, which is 212 possible through an on-link DoS attack, any fresh BGP update will 213 cause the entire peering session to fail if the implementation is 214 checking the validity of link-local next hops as described above. 215 Operators should carefully assess the use of validation against the 216 local IPv6 neighbor table to determine if it is appropriate for any 217 particular peering session. 219 5. Error handling 221 A BGP speaker receiving an MP_REACH_NLRI with the length of the Next 222 Hop Field set to 32, where the update contains anything other than a 223 link-local IPv6 address and a global IPv6 address, SHOULD consider 224 this a malformed UPDATE message, and proceed as described in the 225 following paragraphs. In order to support backward compatibility 226 with existing implementations, an implementation MAY ignore a second 227 link-local IPv6 address or 0::0/0 included with an IPv6 link-local 228 address when the length of the Next Hop Field is set to 32; in this 229 case, the implementation SHOULD report the existence of this 230 additional information so the operator can correct the sending BGP 231 implementation. 233 If the Next Hop field is malformed, the implementation MUST handle 234 the malformed UPDATE message using the approach of "treat-as- 235 withdraw", as described in section 7.3 of [RFC7606]. It MAY send a 236 NOTIFICATION message as described in section 4 of [RFC4271], using 237 the UPDATE error message code (8 - Invalid NEXT_HOP Attribute) 238 indicating there is an invalid NEXT_HOP field 239 If the Next Hop field is properly formed, but the link-local next hop 240 is not reachable (as determined by an examination of the IPv6 241 neighbor table), the implementation MAY handle the malformed UPDATE 242 message using the approach of "treat-as-withdraw", as described in 243 section 7.3 of [RFC7606] (see the note above on checking the local 244 neighbor table for the correctness of the next hop). The 245 implementation MAY send a NOTIFICATION message as described in 246 section 4 of [RFC4271] using the UPDATE error message code (TBA), 247 indicating a link-local address was included in the MP_REACH_NLRI, 248 but the link-local address included cannot be reached. As this could 249 indicate a security breach of some type (see the security 250 considerations section below), the operator SHOULD have a local 251 configuration option to terminate the peering session until manual 252 intervention is initiated. 254 6. Acknowledgements 256 The authors would like to thank Vipin Kumar, Dinesh Dutt, Jeff Haas, 257 and for their contributions to this draft. 259 7. IANA Considerations 261 This memo requests IANA assign a number from the "Error Subcodes" 262 registry defined in the IANA Considerations section in [RFC4271]. 263 This allocation will be for a new UPDATE error subcode, code (TBA), 264 with a value of "Unreachable Link-Local Address." 266 Also, IANA is requested to assign a capability number to the same. 268 8. Security Considerations 270 The mechanism described in this draft can be used as a component of 271 ZTP for building BGP adjacencies across point-to-point links. This 272 method, then, can be used by an attacker to form a peering session 273 with a BGP speaker, ultimately advertising incorrect routing 274 information into a routing domain in order to misdirect traffic or 275 cause a denial of service. By using link-local IPv6 addresses, the 276 attacker would be able to forego the use of a valid IPv6 address 277 within the domain, making such an attack easier. 279 Operators SHOULD carefully consider security when deploying link- 280 local addresses for BGP peering. Operators SHOULD filter traffic on 281 links where BGP peering is not intended to occur to prevent speakers 282 from accepting BGP session requests, as well as other mechanisms 283 described in [RFC7454]. 285 Operators MAY also use some form of cryptographic validation on links 286 within the network to prevent unauthorized devices from forming BGP 287 peering sessions. Authentication, such as the TCP authentication 288 described in [RFC5925], may provide some relief if it is present and 289 correctly configured. However, the distribution and management of 290 keys in an environment where global addresses are not present on BGP 291 speakers may be challenging. 293 Operators also MAY instruct a BGP peer which has received an UPDATE 294 with an unreachable NEXT_HOP to disable the peering session over 295 which the invalid NEXT_HOP was received pending manual intervention. 297 9. References 299 9.1. Normative References 301 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 302 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 303 DOI 10.17487/RFC2545, March 1999, 304 . 306 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 307 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 308 DOI 10.17487/RFC4271, January 2006, 309 . 311 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 312 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 313 2006, . 315 [RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation 316 over LAN in Link State Routing Protocols", RFC 5309, 317 DOI 10.17487/RFC5309, October 2008, 318 . 320 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 321 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 322 2009, . 324 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 325 Layer Reachability Information with an IPv6 Next Hop", 326 RFC 5549, DOI 10.17487/RFC5549, May 2009, 327 . 329 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 330 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 331 June 2010, . 333 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 334 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 335 February 2015, . 337 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 338 Patel, "Revised Error Handling for BGP UPDATE Messages", 339 RFC 7606, DOI 10.17487/RFC7606, August 2015, 340 . 342 9.2. Informative References 344 [correctly] 345 Abraitis, D.A., "FRRouting - An example of inconsistent 346 interoperational implementation", 2020, 347 . 350 [inconsistent] 351 Zajicek, O.Z., "Bird - An example of inconsistent 352 interoperational implementation", 2020, 353 . 356 Authors' Addresses 358 Russ White 359 Juniper Networks 361 Email: russ@riw.us 363 Donatas Abraitis 364 Hostinger 366 Email: donatas.abraitis@gmail.com