forked from ton31337/draft-white-linklocal-capability
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-white-linklocal-capability.txt
448 lines (314 loc) · 19.3 KB
/
draft-white-linklocal-capability.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
Interdomain Routing R. White
Internet-Draft Juniper Networks
Intended status: Standards Track D. Abraitis
Expires: May 18, 2022 Hostinger
November 14, 2021
Link-Local Next Hop Capability for BGP
draft-white-linklocal-capability-00
Abstract
BGP, described in [RFC4271], was originally designed to provide
reachability between domains and between the edges of a domain. As
such, BGP assumes the next hop towards any reachable destination may
not reside on the advertising speaker, but rather may either be
through a router connected to the same subnet as the speaker, or
through a router only reachable by traversing multiple hops through
the network. Because of this, BGP does not recognize the use of IPv6
link-local addresses, as described in [RFC4291], as a valid next hop
for forwarding purposes.
However, BGP speakers are now often deployed on point-to-point links
in networks where multihop reachability of any kind is not assumed or
desired (all next hops are assumed to be the speaker reachable
through a directly connected point-to-point link). This is common,
for instance, in data center fabrics. In these situations, a global
IPv6 address is not required for the advertisement of reachability
information; in fact, providing global IPv6 addresses in these kinds
of networks can be detrimental to Zero Touch Provisioning (ZTP).
This draft standardizes the operation of BGP over a point-to-point
link using link-local IPv6 addressing only.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
White & Abraitis Expires May 18, 2022 [Page 1]
Internet-Draft Link-Local Next Hop Capability for BGP November 2021
This Internet-Draft will expire on May 18, 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Link-Local Next Hop Capability . . . . . . . . . . . . . . . 3
3. Changes to BGP Next Hop Attribute to Support Link-Local on
Point-to-Point . . . . . . . . . . . . . . . . . . . . . . . 4
4. Receiver Processing of IPv6 Link-Local Forwarding Addresses . 5
5. Error handling . . . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
BGP, described in [RFC4271], was originally designed to provide
reachability between domains and between the edges of a domain. As
such, BGP assumes the next hop towards any reachable destination may
not reside on the advertising speaker, but rather may either be
through a router connected to the same subnet as the speaker, or
through a router only reachable by traversing multiple hops through
the network. Because of this, BGP does not recognize the use of IPv6
link-local addresses, as described in [RFC4271], as a valid next hop
for forwarding purposes.
However, BGP speakers are now often deployed on point-to-point links
in networks where multihop reachability of any kind is not assumed or
desired (all next hops are assumed to be the speaker reachable
White & Abraitis Expires May 18, 2022 [Page 2]
Internet-Draft Link-Local Next Hop Capability for BGP November 2021
through a directly connected point-to-point link). This is common,
for instance, in data center fabrics. In these situations, a global
IPv6 address is not required for the advertisement of reachability
information; in fact, providing global IPv6 addresses in these kinds
of networks can be detrimental to Zero Touch Provisioning (ZTP).
Such BGP deployment models require BGP to run on each link, and any
ease or simplification of BGP configuration can result in simplifying
orchestration and configuration management. This proposal is a step
in that direction.
With the requirement of any global interface address being removed by
this new capability, BGP neighbor configuration can be further
simplified by making it (look) address-family independent. E.g BGP
can just take the interface name for the peer config and link-local
IPv6 address of the peer can be learned via a discovery protocol
running on the link or by an out-of-band tool. In essence, link-
local next hop in combination with [RFC5549] makes it possible to
achieve an unnumbered interface-like solution [RFC5309] in BGP.
2. Link-Local Next Hop Capability
The Link-Local Next Hop capability is a new BGP capability. A BGP
speaker that supports capabilities advertisement [RFC5492] in an OPEN
message should send this capability only when:
1. It is capable of sending link-local IPv6 address as the only next
hop address for a route.
2. The implementation is capable of processing link-local address
next hops with the help of peer interface binding to come up with
interface-specific next hops for its routing table.
The presence of this capability does not affect the support of global
IPv6 only (16 bytes next hop) and global IPv6 combined with link-
local IPv6 (32 bytes next hop), which should continue to be supported
as before. The Capability Code for this capability is specified in
the IANA Considerations section of this document. The Capability
Length field of this capability is 0.
The advantage of using this capability is that it can let two
conforming implementations know that they aren't talking to [buggy]
implementations with [unknown] behaviors. Implementations are
inconsistently broken, and can't readily change their default
behavior.
By announcing the capability and having the capability negotiated,
implementations don't need to set interoperational knobs to get a
White & Abraitis Expires May 18, 2022 [Page 3]
Internet-Draft Link-Local Next Hop Capability for BGP November 2021
particular set of fields populated a particular way or worry about
how they are received.
Implementations that don't support this new capability would still
require an additional knob for whatever variety of inconsistent
implementations they want to deal with.
A BGP speaker that is willing to use (send and receive) only link-
local addresses as next hops with a peer SHOULD advertise the Link-
Local Next Hop Capability to the peer using BGP Capabilities
advertisement.
The peers have the flexibility to include both link-local and global
next hops or link-local only next hop.
3. Changes to BGP Next Hop Attribute to Support Link-Local on Point-to-
Point
[RFC2545], section 2, notes link-local IPv6 addresses are not
generally suitable for use in the Next Hop field of the
MP_REACH_NLRI. In order to support the many uses of link-local
addresses, however, [RFC2545] constructs the Next Hop field in IPv6
route advertisements by setting the length of the field to 32, and
including both a link-local and global IPv6 address in the resulting
enlarged field. In this way, the receiving BGP speaker can use the
global IPv6 address to build local forwarding information, and the
link-local address for ICMPv6 redirects, etc. [RFC2545] does not,
however, provide an explanation for situations where there is only a
link-local IPv6 address in the Next Hop field of the MP_REACH_NLRI.
The result is each implementation that supports link-local peering
along with forwarding to a link-local address has implemented the
construction of the Next Hop field in the MP_REACH_NLRI when there is
only a link-local address available in slightly different ways.
If an implementation intends to send a single link-local forwarding
address in the Next Hop field of the MP_REACH_NLRI, it MUST set the
length of the Next Hop field to 16 and include only the IPv6 link-
local address in the Next Hop field.
If an implementation intends to send both a link-local and global
IPv6 forwarding address in the Next Hop field of the MP_REACH_NLRI,
it MUST set the length of the Next Hop field to 32 and include both
the IPv6 link-local and global IPv6 forwarding addresses in the Next
Hop field. If both link local and global IPv6 forwarding addresses
are carried in the Next Hop Field, the speaker SHOULD provide a local
configuration option to determine which address is preferred for
forwarding.
White & Abraitis Expires May 18, 2022 [Page 4]
Internet-Draft Link-Local Next Hop Capability for BGP November 2021
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.
Single (only) link-local next hop address needs to always be reset as
next hop self when passed to another link.
4. Receiver Processing of IPv6 Link-Local Forwarding Addresses
On receiving an MP_REACH_NLRI with a Next Hop length of 16,
implementations SHOULD form the forwarding information using the IPv6
next hop contained in the Next Hop field, regardless of whether it is
a link-local or globally reachable IPv6 address.
Implementations MAY check the validity of any IPv6 link-local address
used to calculate forwarding information by insuring the address is
in the local neighbor table for the interface on which the BGP update
was received (or through which the BGP speaker from which the update
was received is reachable). There MUST be a configuration option to
enable/disable this check.
Note: It is possible that checking the IPv6 neighbor table for the
existence or validity of a link-local next hop may make instances
where a link is being overwhelmed through some form of Denial of
Service (DoS) attack worse than they would otherwise be. If the IPv6
neighbor cache is overrun in a way that causes the link-local address
being used for BGP peering to be removed from the table, which is
possible through an on-link DoS attack, any fresh BGP update will
cause the entire peering session to fail if the implementation is
checking the validity of link-local next hops as described above.
Operators should carefully assess the use of validation against the
local IPv6 neighbor table to determine if it is appropriate for any
particular peering session.
5. Error handling
A BGP speaker receiving an MP_REACH_NLRI with the length of the Next
Hop Field set to 32, where the update contains anything other than a
link-local IPv6 address and a global IPv6 address, SHOULD consider
this a malformed UPDATE message, and proceed as described in the
following paragraphs. In order to support backward compatibility
with existing implementations, an implementation MAY ignore a second
link-local IPv6 address or 0::0/0 included with an IPv6 link-local
address when the length of the Next Hop Field is set to 32; in this
case, the implementation SHOULD report the existence of this
additional information so the operator can correct the sending BGP
implementation.
White & Abraitis Expires May 18, 2022 [Page 5]
Internet-Draft Link-Local Next Hop Capability for BGP November 2021
If the Next Hop field is malformed, the implementation MUST handle
the malformed UPDATE message using the approach of "treat-as-
withdraw", as described in section 7.3 of [RFC7606]. It MAY send a
NOTIFICATION message as described in section 4 of [RFC4271], using
the UPDATE error message code (8 - Invalid NEXT_HOP Attribute)
indicating there is an invalid NEXT_HOP field
If the Next Hop field is properly formed, but the link-local next hop
is not reachable (as determined by an examination of the IPv6
neighbor table), the implementation MAY handle the malformed UPDATE
message using the approach of "treat-as-withdraw", as described in
section 7.3 of [RFC7606] (see the note above on checking the local
neighbor table for the correctness of the next hop). The
implementation MAY send a NOTIFICATION message as described in
section 4 of [RFC4271] using the UPDATE error message code (TBA),
indicating a link-local address was included in the MP_REACH_NLRI,
but the link-local address included cannot be reached. As this could
indicate a security breach of some type (see the security
considerations section below), the operator SHOULD have a local
configuration option to terminate the peering session until manual
intervention is initiated.
6. Acknowledgements
The authors would like to thank Vipin Kumar, Dinesh Dutt, Jeff Haas,
and for their contributions to this draft.
7. IANA Considerations
This memo requests IANA assign a number from the "Error Subcodes"
registry defined in the IANA Considerations section in [RFC4271].
This allocation will be for a new UPDATE error subcode, code (TBA),
with a value of "Unreachable Link-Local Address."
Also, IANA is requested to assign a capability number to the same.
8. Security Considerations
The mechanism described in this draft can be used as a component of
ZTP for building BGP adjacencies across point-to-point links. This
method, then, can be used by an attacker to form a peering session
with a BGP speaker, ultimately advertising incorrect routing
information into a routing domain in order to misdirect traffic or
cause a denial of service. By using link-local IPv6 addresses, the
attacker would be able to forego the use of a valid IPv6 address
within the domain, making such an attack easier.
White & Abraitis Expires May 18, 2022 [Page 6]
Internet-Draft Link-Local Next Hop Capability for BGP November 2021
Operators SHOULD carefully consider security when deploying link-
local addresses for BGP peering. Operators SHOULD filter traffic on
links where BGP peering is not intended to occur to prevent speakers
from accepting BGP session requests, as well as other mechanisms
described in [RFC7454].
Operators MAY also use some form of cryptographic validation on links
within the network to prevent unauthorized devices from forming BGP
peering sessions. Authentication, such as the TCP authentication
described in [RFC5925], may provide some relief if it is present and
correctly configured. However, the distribution and management of
keys in an environment where global addresses are not present on BGP
speakers may be challenging.
Operators also MAY instruct a BGP peer which has received an UPDATE
with an unreachable NEXT_HOP to disable the peering session over
which the invalid NEXT_HOP was received pending manual intervention.
9. References
9.1. Normative References
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545,
DOI 10.17487/RFC2545, March 1999,
<https://www.rfc-editor.org/info/rfc2545>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation
over LAN in Link State Routing Protocols", RFC 5309,
DOI 10.17487/RFC5309, October 2008,
<https://www.rfc-editor.org/info/rfc5309>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <https://www.rfc-editor.org/info/rfc5492>.
White & Abraitis Expires May 18, 2022 [Page 7]
Internet-Draft Link-Local Next Hop Capability for BGP November 2021
[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
Layer Reachability Information with an IPv6 Next Hop",
RFC 5549, DOI 10.17487/RFC5549, May 2009,
<https://www.rfc-editor.org/info/rfc5549>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
February 2015, <https://www.rfc-editor.org/info/rfc7454>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
9.2. Informative References
[buggy] Abraitis, D., "FRRouting - An example of buggy
interoperational implementation", 2020,
<https://github.com/frrouting/frr/
commit/606fdbb1fab98bac305dca3d19eb38b140b7c3e6>.
[unknown] Zajicek, O., "Bird - An example of buggy interoperational
implementation", 2020, <https://gitlab.nic.cz/labs/
bird/-/commit/17de3a023f7bde293892b41bfafe5740c8553fc8>.
Authors' Addresses
Russ White
Juniper Networks
Email: [email protected]
Donatas Abraitis
Hostinger
Email: [email protected]
White & Abraitis Expires May 18, 2022 [Page 8]