/
rfc4271.txt
5827 lines (3743 loc) · 217 KB
/
rfc4271.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
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Network Working Group Y. Rekhter, Ed.
Request for Comments: 4271 T. Li, Ed.
Obsoletes: 1771 S. Hares, Ed.
Category: Standards Track January 2006
A Border Gateway Protocol 4 (BGP-4)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document discusses the Border Gateway Protocol (BGP), which is
an inter-Autonomous System routing protocol.
The primary function of a BGP speaking system is to exchange network
reachability information with other BGP systems. This network
reachability information includes information on the list of
Autonomous Systems (ASes) that reachability information traverses.
This information is sufficient for constructing a graph of AS
connectivity for this reachability from which routing loops may be
pruned, and, at the AS level, some policy decisions may be enforced.
BGP-4 provides a set of mechanisms for supporting Classless Inter-
Domain Routing (CIDR). These mechanisms include support for
advertising a set of destinations as an IP prefix, and eliminating
the concept of network "class" within BGP. BGP-4 also introduces
mechanisms that allow aggregation of routes, including aggregation of
AS paths.
This document obsoletes RFC 1771.
Rekhter, et al. Standards Track [Page 1]
RFC 4271 BGP-4 January 2006
Table of Contents
1. Introduction ....................................................4
1.1. Definition of Commonly Used Terms ..........................4
1.2. Specification of Requirements ..............................6
2. Acknowledgements ................................................6
3. Summary of Operation ............................................7
3.1. Routes: Advertisement and Storage ..........................9
3.2. Routing Information Base ..................................10
4. Message Formats ................................................11
4.1. Message Header Format .....................................12
4.2. OPEN Message Format .......................................13
4.3. UPDATE Message Format .....................................14
4.4. KEEPALIVE Message Format ..................................21
4.5. NOTIFICATION Message Format ...............................21
5. Path Attributes ................................................23
5.1. Path Attribute Usage ......................................25
5.1.1. ORIGIN .............................................25
5.1.2. AS_PATH ............................................25
5.1.3. NEXT_HOP ...........................................26
5.1.4. MULTI_EXIT_DISC ....................................28
5.1.5. LOCAL_PREF .........................................29
5.1.6. ATOMIC_AGGREGATE ...................................29
5.1.7. AGGREGATOR .........................................30
6. BGP Error Handling. ............................................30
6.1. Message Header Error Handling .............................31
6.2. OPEN Message Error Handling ...............................31
6.3. UPDATE Message Error Handling .............................32
6.4. NOTIFICATION Message Error Handling .......................34
6.5. Hold Timer Expired Error Handling .........................34
6.6. Finite State Machine Error Handling .......................35
6.7. Cease .....................................................35
6.8. BGP Connection Collision Detection ........................35
7. BGP Version Negotiation ........................................36
8. BGP Finite State Machine (FSM) .................................37
8.1. Events for the BGP FSM ....................................38
8.1.1. Optional Events Linked to Optional Session
Attributes .........................................38
8.1.2. Administrative Events ..............................42
8.1.3. Timer Events .......................................46
8.1.4. TCP Connection-Based Events ........................47
8.1.5. BGP Message-Based Events ...........................49
8.2. Description of FSM ........................................51
8.2.1. FSM Definition .....................................51
8.2.1.1. Terms "active" and "passive" ..............52
8.2.1.2. FSM and Collision Detection ...............52
8.2.1.3. FSM and Optional Session Attributes .......52
8.2.1.4. FSM Event Numbers .........................53
Rekhter, et al. Standards Track [Page 2]
RFC 4271 BGP-4 January 2006
8.2.1.5. FSM Actions that are Implementation
Dependent .................................53
8.2.2. Finite State Machine ...............................53
9. UPDATE Message Handling ........................................75
9.1. Decision Process ..........................................76
9.1.1. Phase 1: Calculation of Degree of Preference .......77
9.1.2. Phase 2: Route Selection ...........................77
9.1.2.1. Route Resolvability Condition .............79
9.1.2.2. Breaking Ties (Phase 2) ...................80
9.1.3. Phase 3: Route Dissemination .......................82
9.1.4. Overlapping Routes .................................83
9.2. Update-Send Process .......................................84
9.2.1. Controlling Routing Traffic Overhead ...............85
9.2.1.1. Frequency of Route Advertisement ..........85
9.2.1.2. Frequency of Route Origination ............85
9.2.2. Efficient Organization of Routing Information ......86
9.2.2.1. Information Reduction .....................86
9.2.2.2. Aggregating Routing Information ...........87
9.3. Route Selection Criteria ..................................89
9.4. Originating BGP routes ....................................89
10. BGP Timers ....................................................90
Appendix A. Comparison with RFC 1771 .............................92
Appendix B. Comparison with RFC 1267 .............................93
Appendix C. Comparison with RFC 1163 .............................93
Appendix D. Comparison with RFC 1105 .............................94
Appendix E. TCP Options that May Be Used with BGP ................94
Appendix F. Implementation Recommendations .......................95
Appendix F.1. Multiple Networks Per Message .........95
Appendix F.2. Reducing Route Flapping ...............96
Appendix F.3. Path Attribute Ordering ...............96
Appendix F.4. AS_SET Sorting ........................96
Appendix F.5. Control Over Version Negotiation ......96
Appendix F.6. Complex AS_PATH Aggregation ...........96
Security Considerations ...........................................97
IANA Considerations ...............................................99
Normative References .............................................101
Informative References ...........................................101
Rekhter, et al. Standards Track [Page 3]
RFC 4271 BGP-4 January 2006
1. Introduction
The Border Gateway Protocol (BGP) is an inter-Autonomous System
routing protocol.
The primary function of a BGP speaking system is to exchange network
reachability information with other BGP systems. This network
reachability information includes information on the list of
Autonomous Systems (ASes) that reachability information traverses.
This information is sufficient for constructing a graph of AS
connectivity for this reachability, from which routing loops may be
pruned and, at the AS level, some policy decisions may be enforced.
BGP-4 provides a set of mechanisms for supporting Classless Inter-
Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include
support for advertising a set of destinations as an IP prefix and
eliminating the concept of network "class" within BGP. BGP-4 also
introduces mechanisms that allow aggregation of routes, including
aggregation of AS paths.
Routing information exchanged via BGP supports only the destination-
based forwarding paradigm, which assumes that a router forwards a
packet based solely on the destination address carried in the IP
header of the packet. This, in turn, reflects the set of policy
decisions that can (and cannot) be enforced using BGP. BGP can
support only those policies conforming to the destination-based
forwarding paradigm.
1.1. Definition of Commonly Used Terms
This section provides definitions for terms that have a specific
meaning to the BGP protocol and that are used throughout the text.
Adj-RIB-In
The Adj-RIBs-In contains unprocessed routing information that has
been advertised to the local BGP speaker by its peers.
Adj-RIB-Out
The Adj-RIBs-Out contains the routes for advertisement to specific
peers by means of the local speaker's UPDATE messages.
Autonomous System (AS)
The classic definition of an Autonomous System is a set of routers
under a single technical administration, using an interior gateway
protocol (IGP) and common metrics to determine how to route
packets within the AS, and using an inter-AS routing protocol to
determine how to route packets to other ASes. Since this classic
definition was developed, it has become common for a single AS to
Rekhter, et al. Standards Track [Page 4]
RFC 4271 BGP-4 January 2006
use several IGPs and, sometimes, several sets of metrics within an
AS. The use of the term Autonomous System stresses the fact that,
even when multiple IGPs and metrics are used, the administration
of an AS appears to other ASes to have a single coherent interior
routing plan, and presents a consistent picture of the
destinations that are reachable through it.
BGP Identifier
A 4-octet unsigned integer that indicates the BGP Identifier of
the sender of BGP messages. A given BGP speaker sets the value of
its BGP Identifier to an IP address assigned to that BGP speaker.
The value of the BGP Identifier is determined upon startup and is
the same for every local interface and BGP peer.
BGP speaker
A router that implements BGP.
EBGP
External BGP (BGP connection between external peers).
External peer
Peer that is in a different Autonomous System than the local
system.
Feasible route
An advertised route that is available for use by the recipient.
IBGP
Internal BGP (BGP connection between internal peers).
Internal peer
Peer that is in the same Autonomous System as the local system.
IGP
Interior Gateway Protocol - a routing protocol used to exchange
routing information among routers within a single Autonomous
System.
Loc-RIB
The Loc-RIB contains the routes that have been selected by the
local BGP speaker's Decision Process.
NLRI
Network Layer Reachability Information.
Route
A unit of information that pairs a set of destinations with the
attributes of a path to those destinations. The set of
Rekhter, et al. Standards Track [Page 5]
RFC 4271 BGP-4 January 2006
destinations are systems whose IP addresses are contained in one
IP address prefix carried in the Network Layer Reachability
Information (NLRI) field of an UPDATE message. The path is the
information reported in the path attributes field of the same
UPDATE message.
RIB
Routing Information Base.
Unfeasible route
A previously advertised feasible route that is no longer available
for use.
1.2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Acknowledgements
This document was originally published as [RFC1267] in October 1991,
jointly authored by Kirk Lougheed and Yakov Rekhter.
We would like to express our thanks to Guy Almes, Len Bosack, and
Jeffrey C. Honig for their contributions to the earlier version
(BGP-1) of this document.
We would like to specially acknowledge numerous contributions by
Dennis Ferguson to the earlier version of this document.
We would like to explicitly thank Bob Braden for the review of the
earlier version (BGP-2) of this document, and for his constructive
and valuable comments.
We would also like to thank Bob Hinden, Director for Routing of the
Internet Engineering Steering Group, and the team of reviewers he
assembled to review the earlier version (BGP-2) of this document.
This team, consisting of Deborah Estrin, Milo Medin, John Moy, Radia
Perlman, Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya, acted
with a strong combination of toughness, professionalism, and
courtesy.
Certain sections of the document borrowed heavily from IDRP
[IS10747], which is the OSI counterpart of BGP. For this, credit
should be given to the ANSI X3S3.3 group chaired by Lyman Chapin and
to Charles Kunzinger, who was the IDRP editor within that group.
Rekhter, et al. Standards Track [Page 6]
RFC 4271 BGP-4 January 2006
We would also like to thank Benjamin Abarbanel, Enke Chen, Edward
Crabbe, Mike Craren, Vincent Gillet, Eric Gray, Jeffrey Haas, Dimitry
Haskin, Stephen Kent, John Krawczyk, David LeRoy, Dan Massey,
Jonathan Natale, Dan Pei, Mathew Richardson, John Scudder, John
Stewart III, Dave Thaler, Paul Traina, Russ White, Curtis Villamizar,
and Alex Zinin for their comments.
We would like to specially acknowledge Andrew Lange for his help in
preparing the final version of this document.
Finally, we would like to thank all the members of the IDR Working
Group for their ideas and the support they have given to this
document.
3. Summary of Operation
The Border Gateway Protocol (BGP) is an inter-Autonomous System
routing protocol. It is built on experience gained with EGP (as
defined in [RFC904]) and EGP usage in the NSFNET Backbone (as
described in [RFC1092] and [RFC1093]). For more BGP-related
information, see [RFC1772], [RFC1930], [RFC1997], and [RFC2858].
The primary function of a BGP speaking system is to exchange network
reachability information with other BGP systems. This network
reachability information includes information on the list of
Autonomous Systems (ASes) that reachability information traverses.
This information is sufficient for constructing a graph of AS
connectivity, from which routing loops may be pruned, and, at the AS
level, some policy decisions may be enforced.
In the context of this document, we assume that a BGP speaker
advertises to its peers only those routes that it uses itself (in
this context, a BGP speaker is said to "use" a BGP route if it is the
most preferred BGP route and is used in forwarding). All other cases
are outside the scope of this document.
In the context of this document, the term "IP address" refers to an
IP Version 4 address [RFC791].
Routing information exchanged via BGP supports only the destination-
based forwarding paradigm, which assumes that a router forwards a
packet based solely on the destination address carried in the IP
header of the packet. This, in turn, reflects the set of policy
decisions that can (and cannot) be enforced using BGP. Note that
some policies cannot be supported by the destination-based forwarding
paradigm, and thus require techniques such as source routing (aka
explicit routing) to be enforced. Such policies cannot be enforced
using BGP either. For example, BGP does not enable one AS to send
Rekhter, et al. Standards Track [Page 7]
RFC 4271 BGP-4 January 2006
traffic to a neighboring AS for forwarding to some destination
(reachable through but) beyond that neighboring AS, intending that
the traffic take a different route to that taken by the traffic
originating in the neighboring AS (for that same destination). On
the other hand, BGP can support any policy conforming to the
destination-based forwarding paradigm.
BGP-4 provides a new set of mechanisms for supporting Classless
Inter-Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms
include support for advertising a set of destinations as an IP prefix
and eliminating the concept of a network "class" within BGP. BGP-4
also introduces mechanisms that allow aggregation of routes,
including aggregation of AS paths.
This document uses the term `Autonomous System' (AS) throughout. The
classic definition of an Autonomous System is a set of routers under
a single technical administration, using an interior gateway protocol
(IGP) and common metrics to determine how to route packets within the
AS, and using an inter-AS routing protocol to determine how to route
packets to other ASes. Since this classic definition was developed,
it has become common for a single AS to use several IGPs and,
sometimes, several sets of metrics within an AS. The use of the term
Autonomous System stresses the fact that, even when multiple IGPs and
metrics are used, the administration of an AS appears to other ASes
to have a single coherent interior routing plan and presents a
consistent picture of the destinations that are reachable through it.
BGP uses TCP [RFC793] as its transport protocol. This eliminates the
need to implement explicit update fragmentation, retransmission,
acknowledgement, and sequencing. BGP listens on TCP port 179. The
error notification mechanism used in BGP assumes that TCP supports a
"graceful" close (i.e., that all outstanding data will be delivered
before the connection is closed).
A TCP connection is formed between two systems. They exchange
messages to open and confirm the connection parameters.
The initial data flow is the portion of the BGP routing table that is
allowed by the export policy, called the Adj-Ribs-Out (see 3.2).
Incremental updates are sent as the routing tables change. BGP does
not require a periodic refresh of the routing table. To allow local
policy changes to have the correct effect without resetting any BGP
connections, a BGP speaker SHOULD either (a) retain the current
version of the routes advertised to it by all of its peers for the
duration of the connection, or (b) make use of the Route Refresh
extension [RFC2918].
Rekhter, et al. Standards Track [Page 8]
RFC 4271 BGP-4 January 2006
KEEPALIVE messages may be sent periodically to ensure that the
connection is live. NOTIFICATION messages are sent in response to
errors or special conditions. If a connection encounters an error
condition, a NOTIFICATION message is sent and the connection is
closed.
A peer in a different AS is referred to as an external peer, while a
peer in the same AS is referred to as an internal peer. Internal BGP
and external BGP are commonly abbreviated as IBGP and EBGP.
If a particular AS has multiple BGP speakers and is providing transit
service for other ASes, then care must be taken to ensure a
consistent view of routing within the AS. A consistent view of the
interior routes of the AS is provided by the IGP used within the AS.
For the purpose of this document, it is assumed that a consistent
view of the routes exterior to the AS is provided by having all BGP
speakers within the AS maintain IBGP with each other.
This document specifies the base behavior of the BGP protocol. This
behavior can be, and is, modified by extension specifications. When
the protocol is extended, the new behavior is fully documented in the
extension specifications.
3.1. Routes: Advertisement and Storage
For the purpose of this protocol, a route is defined as a unit of
information that pairs a set of destinations with the attributes of a
path to those destinations. The set of destinations are systems
whose IP addresses are contained in one IP address prefix that is
carried in the Network Layer Reachability Information (NLRI) field of
an UPDATE message, and the path is the information reported in the
path attributes field of the same UPDATE message.
Routes are advertised between BGP speakers in UPDATE messages.
Multiple routes that have the same path attributes can be advertised
in a single UPDATE message by including multiple prefixes in the NLRI
field of the UPDATE message.
Routes are stored in the Routing Information Bases (RIBs): namely,
the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out, as described in
Section 3.2.
If a BGP speaker chooses to advertise a previously received route, it
MAY add to, or modify, the path attributes of the route before
advertising it to a peer.
Rekhter, et al. Standards Track [Page 9]
RFC 4271 BGP-4 January 2006
BGP provides mechanisms by which a BGP speaker can inform its peers
that a previously advertised route is no longer available for use.
There are three methods by which a given BGP speaker can indicate
that a route has been withdrawn from service:
a) the IP prefix that expresses the destination for a previously
advertised route can be advertised in the WITHDRAWN ROUTES
field in the UPDATE message, thus marking the associated route
as being no longer available for use,
b) a replacement route with the same NLRI can be advertised, or
c) the BGP speaker connection can be closed, which implicitly
removes all routes the pair of speakers had advertised to each
other from service.
Changing the attribute(s) of a route is accomplished by advertising a
replacement route. The replacement route carries new (changed)
attributes and has the same address prefix as the original route.
3.2. Routing Information Base
The Routing Information Base (RIB) within a BGP speaker consists of
three distinct parts:
a) Adj-RIBs-In: The Adj-RIBs-In stores routing information learned
from inbound UPDATE messages that were received from other BGP
speakers. Their contents represent routes that are available
as input to the Decision Process.
b) Loc-RIB: The Loc-RIB contains the local routing information the
BGP speaker selected by applying its local policies to the
routing information contained in its Adj-RIBs-In. These are
the routes that will be used by the local BGP speaker. The
next hop for each of these routes MUST be resolvable via the
local BGP speaker's Routing Table.
c) Adj-RIBs-Out: The Adj-RIBs-Out stores information the local BGP
speaker selected for advertisement to its peers. The routing
information stored in the Adj-RIBs-Out will be carried in the
local BGP speaker's UPDATE messages and advertised to its
peers.
In summary, the Adj-RIBs-In contains unprocessed routing information
that has been advertised to the local BGP speaker by its peers; the
Loc-RIB contains the routes that have been selected by the local BGP
Rekhter, et al. Standards Track [Page 10]
RFC 4271 BGP-4 January 2006
speaker's Decision Process; and the Adj-RIBs-Out organizes the routes
for advertisement to specific peers (by means of the local speaker's
UPDATE messages).
Although the conceptual model distinguishes between Adj-RIBs-In,
Loc-RIB, and Adj-RIBs-Out, this neither implies nor requires that an
implementation must maintain three separate copies of the routing
information. The choice of implementation (for example, 3 copies of
the information vs 1 copy with pointers) is not constrained by the
protocol.
Routing information that the BGP speaker uses to forward packets (or
to construct the forwarding table used for packet forwarding) is
maintained in the Routing Table. The Routing Table accumulates
routes to directly connected networks, static routes, routes learned
from the IGP protocols, and routes learned from BGP. Whether a
specific BGP route should be installed in the Routing Table, and
whether a BGP route should override a route to the same destination
installed by another source, is a local policy decision, and is not
specified in this document. In addition to actual packet forwarding,
the Routing Table is used for resolution of the next-hop addresses
specified in BGP updates (see Section 5.1.3).
4. Message Formats
This section describes message formats used by BGP.
BGP messages are sent over TCP connections. A message is processed
only after it is entirely received. The maximum message size is 4096
octets. All implementations are required to support this maximum
message size. The smallest message that may be sent consists of a
BGP header without a data portion (19 octets).
All multi-octet fields are in network byte order.
Rekhter, et al. Standards Track [Page 11]
RFC 4271 BGP-4 January 2006
4.1. Message Header Format
Each message has a fixed-size header. There may or may not be a data
portion following the header, depending on the message type. The
layout of these fields is shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Marker |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Marker:
This 16-octet field is included for compatibility; it MUST be
set to all ones.
Length:
This 2-octet unsigned integer indicates the total length of the
message, including the header in octets. Thus, it allows one
to locate the (Marker field of the) next message in the TCP
stream. The value of the Length field MUST always be at least
19 and no greater than 4096, and MAY be further constrained,
depending on the message type. "padding" of extra data after
the message is not allowed. Therefore, the Length field MUST
have the smallest value required, given the rest of the
message.
Type:
This 1-octet unsigned integer indicates the type code of the
message. This document defines the following type codes:
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE
[RFC2918] defines one more type code.
Rekhter, et al. Standards Track [Page 12]
RFC 4271 BGP-4 January 2006
4.2. OPEN Message Format
After a TCP connection is established, the first message sent by each
side is an OPEN message. If the OPEN message is acceptable, a
KEEPALIVE message confirming the OPEN is sent back.
In addition to the fixed-size BGP header, the OPEN message contains
the following fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Autonomous System |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Parm Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Optional Parameters (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version:
This 1-octet unsigned integer indicates the protocol version
number of the message. The current BGP version number is 4.
My Autonomous System:
This 2-octet unsigned integer indicates the Autonomous System
number of the sender.
Hold Time:
This 2-octet unsigned integer indicates the number of seconds
the sender proposes for the value of the Hold Timer. Upon
receipt of an OPEN message, a BGP speaker MUST calculate the
value of the Hold Timer by using the smaller of its configured
Hold Time and the Hold Time received in the OPEN message. The
Hold Time MUST be either zero or at least three seconds. An
implementation MAY reject connections on the basis of the Hold
Rekhter, et al. Standards Track [Page 13]
RFC 4271 BGP-4 January 2006
Time. The calculated value indicates the maximum number of
seconds that may elapse between the receipt of successive
KEEPALIVE and/or UPDATE messages from the sender.
BGP Identifier:
This 4-octet unsigned integer indicates the BGP Identifier of
the sender. A given BGP speaker sets the value of its BGP
Identifier to an IP address that is assigned to that BGP
speaker. The value of the BGP Identifier is determined upon
startup and is the same for every local interface and BGP peer.
Optional Parameters Length:
This 1-octet unsigned integer indicates the total length of the
Optional Parameters field in octets. If the value of this
field is zero, no Optional Parameters are present.
Optional Parameters:
This field contains a list of optional parameters, in which
each parameter is encoded as a <Parameter Type, Parameter
Length, Parameter Value> triplet.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Parm. Type | Parm. Length | Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Parameter Type is a one octet field that unambiguously
identifies individual parameters. Parameter Length is a one
octet field that contains the length of the Parameter Value
field in octets. Parameter Value is a variable length field
that is interpreted according to the value of the Parameter
Type field.
[RFC3392] defines the Capabilities Optional Parameter.
The minimum length of the OPEN message is 29 octets (including the
message header).
4.3. UPDATE Message Format
UPDATE messages are used to transfer routing information between BGP
peers. The information in the UPDATE message can be used to
construct a graph that describes the relationships of the various
Autonomous Systems. By applying rules to be discussed, routing
Rekhter, et al. Standards Track [Page 14]
RFC 4271 BGP-4 January 2006
information loops and some other anomalies may be detected and
removed from inter-AS routing.
An UPDATE message is used to advertise feasible routes that share
common path attributes to a peer, or to withdraw multiple unfeasible
routes from service (see 3.1). An UPDATE message MAY simultaneously
advertise a feasible route and withdraw multiple unfeasible routes
from service. The UPDATE message always includes the fixed-size BGP
header, and also includes the other fields, as shown below (note,
some of the shown fields may not be present in every UPDATE message):
+-----------------------------------------------------+
| Withdrawn Routes Length (2 octets) |
+-----------------------------------------------------+
| Withdrawn Routes (variable) |
+-----------------------------------------------------+
| Total Path Attribute Length (2 octets) |
+-----------------------------------------------------+
| Path Attributes (variable) |
+-----------------------------------------------------+
| Network Layer Reachability Information (variable) |
+-----------------------------------------------------+
Withdrawn Routes Length:
This 2-octets unsigned integer indicates the total length of
the Withdrawn Routes field in octets. Its value allows the
length of the Network Layer Reachability Information field to
be determined, as specified below.
A value of 0 indicates that no routes are being withdrawn from
service, and that the WITHDRAWN ROUTES field is not present in
this UPDATE message.
Withdrawn Routes:
This is a variable-length field that contains a list of IP
address prefixes for the routes that are being withdrawn from
service. Each IP address prefix is encoded as a 2-tuple of the
form <length, prefix>, whose fields are described below:
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
Rekhter, et al. Standards Track [Page 15]
RFC 4271 BGP-4 January 2006
The use and the meaning of these fields are as follows:
a) Length:
The Length field indicates the length in bits of the IP
address prefix. A length of zero indicates a prefix that
matches all IP addresses (with prefix, itself, of zero
octets).
b) Prefix:
The Prefix field contains an IP address prefix, followed by
the minimum number of trailing bits needed to make the end
of the field fall on an octet boundary. Note that the value
of trailing bits is irrelevant.
Total Path Attribute Length:
This 2-octet unsigned integer indicates the total length of the
Path Attributes field in octets. Its value allows the length
of the Network Layer Reachability field to be determined as
specified below.
A value of 0 indicates that neither the Network Layer
Reachability Information field nor the Path Attribute field is
present in this UPDATE message.
Path Attributes:
A variable-length sequence of path attributes is present in
every UPDATE message, except for an UPDATE message that carries
only the withdrawn routes. Each path attribute is a triple
<attribute type, attribute length, attribute value> of variable
length.
Attribute Type is a two-octet field that consists of the
Attribute Flags octet, followed by the Attribute Type Code
octet.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr. Flags |Attr. Type Code|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The high-order bit (bit 0) of the Attribute Flags octet is the
Optional bit. It defines whether the attribute is optional (if
set to 1) or well-known (if set to 0).
Rekhter, et al. Standards Track [Page 16]
RFC 4271 BGP-4 January 2006
The second high-order bit (bit 1) of the Attribute Flags octet
is the Transitive bit. It defines whether an optional
attribute is transitive (if set to 1) or non-transitive (if set
to 0).
For well-known attributes, the Transitive bit MUST be set to 1.
(See Section 5 for a discussion of transitive attributes.)
The third high-order bit (bit 2) of the Attribute Flags octet
is the Partial bit. It defines whether the information
contained in the optional transitive attribute is partial (if
set to 1) or complete (if set to 0). For well-known attributes
and for optional non-transitive attributes, the Partial bit
MUST be set to 0.
The fourth high-order bit (bit 3) of the Attribute Flags octet
is the Extended Length bit. It defines whether the Attribute
Length is one octet (if set to 0) or two octets (if set to 1).
The lower-order four bits of the Attribute Flags octet are
unused. They MUST be zero when sent and MUST be ignored when
received.
The Attribute Type Code octet contains the Attribute Type Code.
Currently defined Attribute Type Codes are discussed in Section
5.
If the Extended Length bit of the Attribute Flags octet is set
to 0, the third octet of the Path Attribute contains the length
of the attribute data in octets.
If the Extended Length bit of the Attribute Flags octet is set
to 1, the third and fourth octets of the path attribute contain
the length of the attribute data in octets.
Rekhter, et al. Standards Track [Page 17]
RFC 4271 BGP-4 January 2006
The remaining octets of the Path Attribute represent the
attribute value and are interpreted according to the Attribute
Flags and the Attribute Type Code. The supported Attribute
Type Codes, and their attribute values and uses are as follows:
a) ORIGIN (Type Code 1):
ORIGIN is a well-known mandatory attribute that defines the
origin of the path information. The data octet can assume
the following values:
Value Meaning
0 IGP - Network Layer Reachability Information
is interior to the originating AS
1 EGP - Network Layer Reachability Information
learned via the EGP protocol [RFC904]
2 INCOMPLETE - Network Layer Reachability
Information learned by some other means
Usage of this attribute is defined in 5.1.1.
b) AS_PATH (Type Code 2):
AS_PATH is a well-known mandatory attribute that is composed
of a sequence of AS path segments. Each AS path segment is
represented by a triple <path segment type, path segment
length, path segment value>.
The path segment type is a 1-octet length field with the
following values defined:
Value Segment Type
1 AS_SET: unordered set of ASes a route in the
UPDATE message has traversed
2 AS_SEQUENCE: ordered set of ASes a route in
the UPDATE message has traversed