idnits 2.17.1 draft-white-linklocalnh-02.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 2021) is 892 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) == Unused Reference: 'RFC2119' is defined on line 252, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 290, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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.S. Sharp 5 Expires: 11 May 2022 Cumulus Networks 6 D.D. Dutt 7 Stardust Consulting 8 B.S. Sadhu 9 VMWare 10 J.T. Tantsura 11 Apstra, Inc. 12 D.A. Abraitis 13 Hostinger 14 November 2021 16 Link Local Next Hop Handling for BGP 17 draft-white-linklocalnh-02 19 Abstract 21 BGP, described in [RFC4271], was originally designed to provide 22 reachability between domains and between the edges of a domain. As 23 such, BGP assumes the next hop towards any reachable destination may 24 not reside on the advertising speaker, but rather may either be 25 through a router connected to the same subnet as the speaker, or 26 through a router only reachable by traversing multiple hops through 27 the network. Because of this, BGP does not recognize the use of IPv6 28 link local addresses, as described in [RFC4291], as a valid next hop 29 for forwarding purposes. 31 However, BGP speakers are now often deployed on point-to-point links 32 in networks where multihop reachability of any kind is not assumed or 33 desired (all next hops are assumed to be the speaker reachable 34 through a directly connected point-to-point link). This is common, 35 for instance, in data center fabrics. In these situations, a global 36 IPv6 address is not required for the advertisement of reachability 37 information; in fact, providing global IPv6 addresses in these kinds 38 of networks can be detrimental to Zero Touch Provisioning (ZTP). 40 This draft standardizes the operation of BGP over a point-to-point 41 link using link local IPv6 addressing only. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at https://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on 5 May 2022. 60 Copyright Notice 62 Copyright (c) 2021 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 67 license-info) in effect on the date of publication of this document. 68 Please review these documents carefully, as they describe your rights 69 and restrictions with respect to this document. Code Components 70 extracted from this document must include Simplified BSD License text 71 as described in Section 4.e of the Trust Legal Provisions and are 72 provided without warranty as described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Changes to BGP Next Hop Attribute to Support Link Local on 78 Point-to-Point . . . . . . . . . . . . . . . . . . . . . 3 79 3. Receiver Processing of IPv6 Link Local Forwarding 80 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 81 4. Error handling . . . . . . . . . . . . . . . . . . . . . . . 4 82 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 87 8.2. Informative References . . . . . . . . . . . . . . . . . 7 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 90 1. Introduction 92 BGP, described in [RFC4271], was originally designed to provide 93 reachability between domains and between the edges of a domain. As 94 such, BGP assumes the next hop towards any reachable destination may 95 not reside on the advertising speaker, but rather may either be 96 through a router connected to the same subnet as the speaker, or 97 through a router only reachable by traversing multiple hops through 98 the network. Because of this, BGP does not recognize the use of IPv6 99 link local addresses, as described in [RFC4271], as a valid next hop 100 for forwarding purposes. 102 However, BGP speakers are now often deployed on point-to-point links 103 in networks where multihop reachability of any kind is not assumed or 104 desired (all next hops are assumed to be the speaker reachable 105 through a directly connected point-to-point link). This is common, 106 for instance, in data center fabrics. In these situations, a global 107 IPv6 address is not required for the advertisement of reachability 108 information; in fact, providing global IPv6 addresses in these kinds 109 of networks can be detrimental to Zero Touch Provisioning (ZTP). 111 2. Changes to BGP Next Hop Attribute to Support Link Local on Point-to- 112 Point 114 [RFC2545], section 2, notes link local IPv6 addresses are not 115 generally suitable for use in the Next Hop field of the 116 MP_REACH_NLRI. In order to support the many uses of link local 117 addresses, however, [RFC2545] constructs the Next Hop field in IPv6 118 route advertisements by setting the length of the field to 32, and 119 including both a link local and global IPv6 address in the resulting 120 enlarged field. In this way, the receiving BGP speaker can use the 121 global IPv6 address to build local forwarding information, and the 122 link local address for ICMPv6 redirects, etc. [RFC2545] does not, 123 however, provide an explanation for situations where there is only a 124 link local IPv6 address in the Next Hop field of the MP_REACH_NLRI. 125 The result is each implementation that supports link local peering 126 along with forwarding to a link local address has implemented the 127 construction of the Next Hop field in the MP_REACH_NLRI when there is 128 only a link local address available in slightly different ways. 130 If an implementation intends to send a single link local forwarding 131 address in the Next Hop field of the MP_REACH_NLRI, it MUST set the 132 length of the Next Hop field to 16 and include only the IPv6 link 133 local address in the Next Hop field. 135 If an implementation intends to send both a link local and global 136 IPv6 forwarding address in the Next Hop field of the MP_REACH_NLRI, 137 it MUST set the length of the Next Hop field to 32 and include both 138 the IPv6 link local and global IPv6 forwarding addresses in the Next 139 Hop field. If both link local and global IPv6 forwarding addresses 140 are carried in the Next Hop Field, the speaker SHOULD provide a local 141 configuration option to determine which address is preferred for 142 forwarding. 144 3. Receiver Processing of IPv6 Link Local Forwarding Addresses 146 On receiving an MP_REACH_NLRI with a Next Hop length of 16, 147 implementations SHOULD form the forwarding information using the IPv6 148 next hop contained in the Next Hop field, regardless of whether it is 149 a link local or globally reachable IPv6 address. 151 Implementations MAY check the validity of any IPv6 link local address 152 used to calculate forwarding information by insuring the address is 153 in the local neighbor table for the interface on which the BGP update 154 was received (or through which the BGP speaker from which the update 155 was received is reachable). There MUST be a configuration option to 156 enable/disable this check. 158 Note: It is possible that checking the IPv6 neighbor table for the 159 existence or validity of a link local next hop may make instances 160 where a link is being overwhelmed through some form of Denial of 161 Service (DoS) attack worse than they would otherwise be. If the IPv6 162 neighbor cache is overrun in a way that causes the link local address 163 being used for BGP peering to be removed from the table, which is 164 possible through an on-link DoS attack, any fresh BGP update will 165 cause the entire peering session to fail if the implementation is 166 checking the validity of link local next hops as described above. 167 Operators should carefully assess the use of validation against the 168 local IPv6 neighbor table to determine if it is appropriate for any 169 particular peering session. 171 4. Error handling 173 A BGP speaker receiving an MP_REACH_NLRI with the length of the Next 174 Hop Field set to 32, where the update contains anything other than a 175 link local IPv6 address and a global IPv6 address, SHOULD consider 176 this a malformed UPDATE message, and proceed as described in the 177 following paragraphs. In order to support backwards compatibility 178 with existing implementations, an implementation MAY ignore a second 179 link local IPv6 address or 0::0/0 included with an IPv6 link local 180 address when the length of the Next Hop Field is set to 32; in this 181 case, the implementation SHOULD report the existence of this 182 additional information so the operator can correct the sending BGP 183 implementation. 185 If the Next Hop field is malformed, the implementation MUST handle 186 the mailformed UPDATE message using the approach of "treat-as- 187 withdraw", as described in section 7.3 of [RFC7606]. It MAY send a 188 NOTIFICATION message as described in section 4 of [RFC4271], using 189 the UPDATE error message code (8 - Invalid NEXT_HOP Attribute) 190 indicating there is an invalid NEXT_HOP field 192 If the Next Hop field is properly formed, but the link local next hop 193 is not reachable (as determined by an examination of the IPv6 194 neighbor table), the implementation MAY handle the mailformed UPDATE 195 message using the approach of "treat-as-withdraw", as described in 196 section 7.3 of [RFC7606] (see note above on checking the local 197 neighbor table for the correctness of the next hop). The 198 implementation MAY send a NOTIFICATION message as described in 199 section 4 of [RFC4271] using the UPDATE error message code (TBA), 200 indicating a link local address was included in the MP_REACH_NLRI, 201 but the link local address included cannot be reached. As this could 202 indicate a security breach of some type (see the security 203 considerations section below), the operator SHOULD have a local 204 configuration option to terminate the peering session until manual 205 intervention is initiated. 207 5. Acknowledgements 209 The authors would like to thank Don Slice, Jeff Haas, and John 210 Scudder for their contributions to this draft. 212 6. IANA Considerations 214 This memo requests IANA assign a number from the "Error Subcodes" 215 registry defined in the IANA Considerations section in [RFC4271]. 216 This allocation will be for a new UPDATE error subcode, code (TBA), 217 with a value of "Unreachable Link Local Address." 219 7. Security Considerations 221 The mechanism described in this draft can be used as a component of 222 ZTP for building BGP adjacencies across point-to-point links. This 223 method, then, can be used by an attacker to form a peering session 224 with a BGP speaker, ultimately advertising incorrect routing 225 information into a routing domain in order to misdirect traffic or 226 cause a denial of service. By using link local IPv6 addresses, the 227 attacker would be able to forego the use of a valid IPv6 address 228 within the domain, making such an attack easier. 230 Operators SHOULD carefully consider security when deploying link 231 local addresses for BGP peering. Operators SHOULD filter traffic on 232 links where BGP peering is not intended to occur to prevent speakers 233 from accepting BGP session requests, as well as other mechanisms 234 described in [RFC7454]. 236 Operators MAY also use some form of cryptographic validation on links 237 within the network to prevent unauthorized devices from forming BGP 238 peering sessions. Authentication, such as the TCP authentication 239 described in [RFC5925], may provide some relief, if it is present and 240 correctly configured. However, the distribution and management of 241 keys in an environment where global addresses are not present on BGP 242 speakers may be challenging. 244 Operators also MAY instruct a BGP peer which has received an UPDATE 245 with an unreachable NEXT_HOP to disable the peering session over 246 which the invalid NEXT_HOP was received pending manual intervention. 248 8. References 250 8.1. Normative References 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, 254 DOI 10.17487/RFC2119, March 1997, 255 . 257 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 258 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 259 DOI 10.17487/RFC2545, March 1999, 260 . 262 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 263 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 264 DOI 10.17487/RFC4271, January 2006, 265 . 267 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 268 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 269 2006, . 271 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 272 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 273 June 2010, . 275 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 276 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 277 February 2015, . 279 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 280 Patel, "Revised Error Handling for BGP UPDATE Messages", 281 RFC 7606, DOI 10.17487/RFC7606, August 2015, 282 . 284 8.2. Informative References 286 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 287 DOI 10.17487/RFC2629, June 1999, 288 . 290 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 291 Text on Security Considerations", BCP 72, RFC 3552, 292 DOI 10.17487/RFC3552, July 2003, 293 . 295 Authors' Addresses 297 Russ White 298 Juniper Networks 300 Email: russ@riw.us 302 Donald Sharp 303 Cumulus Networks 305 Email: sharpd@cumulusnetworks.com 307 Dinesh Dutt 308 Stardust Consulting 310 Email: ddutt@hobbesdutt.com 312 Biswajit Sadhu 313 VMWare 315 Email: biswajit.sadhu@gmail.com 317 Jeff Tantsura 318 Apstra, Inc. 320 Email: jefftant.ietf@gmail.com 321 Donatas Abraitis 322 Hostinger 324 Email: donatas.abraitis@gmail.com