RFC Errata
Found 20 records.
Status: Verified (4)
RFC 4271, "A Border Gateway Protocol 4 (BGP-4)", January 2006
Note: This RFC has been updated by RFC 4724, RFC 6286, RFC 6608, RFC 6793, RFC 7606, RFC 7607, RFC 7705, RFC 8212, RFC 8654, RFC 9072, RFC 9687
Source of RFC: idr (rtg)
Errata ID: 2838
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jamie Taylor
Date Reported: 2011-06-16
Verifier Name: Stewart Bryant
Date Verified: 2011-08-02
Section 8.2.2 says:
on page 72, description of the Established state: If the HoldTimer_Expires event occurs (Event 10), the local system: ...[list of actions to take]...
It should say:
If the HoldTimer_Expires event occurs (Event 10), the local system: - deletes all routes associated with this connection ...[list of actions in original text]...
Notes:
All other transitions from Established to Idle explicitly state that all routes associated with the connection are deleted. This transition should as well.
Errata ID: 1633
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Scudder
Date Reported: 2008-12-12
Verifier Name: Stewart Bryant
Date Verified: 2011-08-02
Section 6.3 says:
If an optional attribute is recognized, then the value of this attribute MUST be checked. If an error is detected, the attribute MUST be discarded, and the Error Subcode MUST be set to Optional Attribute Error. The Data field MUST contain the attribute (type, length, and value).
It should say:
If an optional attribute is recognized, then the value of this attribute MUST be checked. If an error is detected, the Error Subcode MUST be set to Optional Attribute Error. The Data field MUST contain the attribute (type, length, and value).
Notes:
This simply removes the clause "the attribute MUST be discarded", which doesn't make sense since the peering is to be terminated anyway.
Errata ID: 4493
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruno Decraene
Date Reported: 2015-10-06
Verifier Name: Alvaro Retana
Date Verified: 2016-07-14
Section 4.5 says:
Message Header Error subcodes: 1 - Connection Not Synchronized. 2 - Bad Message Length. 3 - Bad Message Type. OPEN Message Error subcodes: 1 - Unsupported Version Number. 2 - Bad Peer AS. 3 - Bad BGP Identifier. 4 - Unsupported Optional Parameter. 5 - [Deprecated - see Appendix A]. 6 - Unacceptable Hold Time. UPDATE Message Error subcodes: 1 - Malformed Attribute List. 2 - Unrecognized Well-known Attribute. 3 - Missing Well-known Attribute. 4 - Attribute Flags Error. 5 - Attribute Length Error. 6 - Invalid ORIGIN Attribute. 7 - [Deprecated - see Appendix A]. 8 - Invalid NEXT_HOP Attribute. 9 - Optional Attribute Error. 10 - Invalid Network Field. 11 - Malformed AS_PATH.
It should say:
Message Header Error subcodes: 0 - Unspecific. 1 - Connection Not Synchronized. 2 - Bad Message Length. 3 - Bad Message Type. OPEN Message Error subcodes: 0 - Unspecific. 1 - Unsupported Version Number. 2 - Bad Peer AS. 3 - Bad BGP Identifier. 4 - Unsupported Optional Parameter. 5 - [Deprecated - see Appendix A]. 6 - Unacceptable Hold Time. UPDATE Message Error subcodes: 0 - Unspecific. 1 - Malformed Attribute List. 2 - Unrecognized Well-known Attribute. 3 - Missing Well-known Attribute. 4 - Attribute Flags Error. 5 - Attribute Length Error. 6 - Invalid ORIGIN Attribute. 7 - [Deprecated - see Appendix A]. 8 - Invalid NEXT_HOP Attribute. 9 - Optional Attribute Error. 10 - Invalid Network Field. 11 - Malformed AS_PATH.
Notes:
RFC 4271 defines a use and a name for Error subcode 0:
- §4.5 (any error code):
If no appropriate Error Subcode is defined, then a zero
(Unspecific) value is used for the Error Subcode field.
- §6.2 (OPEN error code):
If one of the Optional Parameters in the OPEN message is recognized,
but is malformed, then the Error Subcode MUST be set to 0
(Unspecific).
The "IANA Considerations" section would also need to be updated
accordingly (says "0 Reserved”). However, IANA has corrected the
corresponding registry at http://www.iana.org/assignments/bgp-parameters.
Errata ID: 5369
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eric Osborne
Date Reported: 2018-05-25
Verifier Name: RFC Editor
Date Verified: 2018-05-25
Section 9.2.2.2 says:
route MUST have the ORIGIN attribute with the value EGP. In all other cases,, the value of the ORIGIN attribute of the aggregated route is IGP.
It should say:
route MUST have the ORIGIN attribute with the value EGP. In all other cases, the value of the ORIGIN attribute of the aggregated route is IGP.
Notes:
Extra comma after 'cases'.
Status: Held for Document Update (12)
RFC 4271, "A Border Gateway Protocol 4 (BGP-4)", January 2006
Note: This RFC has been updated by RFC 4724, RFC 6286, RFC 6608, RFC 6793, RFC 7606, RFC 7607, RFC 7705, RFC 8212, RFC 8654, RFC 9072, RFC 9687
Source of RFC: idr (rtg)
Errata ID: 5000
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: John Scudder
Date Reported: 2017-04-19
Held for Document Update by: Alvaro Retana
Date Held: 2017-04-27
Section 9.1.1 says:
If the route is learned from an external peer, then the local BGP speaker computes the degree of preference based on preconfigured policy information. If the return value indicates the route is ineligible, the route MAY NOT serve as an input to the next phase of route selection; otherwise, the return value MUST be used as the LOCAL_PREF value in any IBGP readvertisement.
It should say:
If the route is learned from an external peer, then the local BGP speaker computes the degree of preference based on preconfigured policy information. If the return value indicates the route is ineligible, the route MUST NOT serve as an input to the next phase of route selection; otherwise, the return value MUST be used as the LOCAL_PREF value in any IBGP readvertisement.
Notes:
The original text uses "MAY NOT" capitalized as if it were an RFC 2119 keyword. However, RFC 2119 does not have any defined meaning for "MAY NOT". If a reader were to interpret this text as suggesting it is optional -- meaning, in effect, "the route MAY serve as an input to the next phase of route selection" -- that would be wrong and potentially problematic.
The minimal correction would be to use lower-case "may not", which makes the proper meaning reasonably clear. However, the English construct "may not" is notoriously ambiguous, therefore the proposed correction is "MUST NOT".
=====
After consultation with the idr WG, it was confirmed that the correct interpretation (based on implementation experience) is "MUST NOT". --- Alvaro.
Errata ID: 5001
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: John Scudder
Date Reported: 2017-04-19
Held for Document Update by: Alvaro Retana
Date Held: 2017-04-27
Section 5 says:
BGP implementations MUST recognize all well-known attributes. Some of these attributes are mandatory and MUST be included in every UPDATE message that contains NLRI. Others are discretionary and MAY or MAY NOT be sent in a particular UPDATE message.
It should say:
BGP implementations MUST recognize all well-known attributes. Some of these attributes are mandatory and MUST be included in every UPDATE message that contains NLRI. Others are discretionary and may or may not be sent in a particular UPDATE message.
Notes:
The original text uses "MAY NOT" capitalized as if it were an RFC 2119 keyword. However, RFC 2119 does not have any defined meaning for "MAY NOT". In context, it is unlikely the reader would be at risk of misinterpreting the text, but nonetheless it's a misuse of RFC 2119 terminology and difficult to parse if reading closely.
(The replacement text was suggested by Eric Rosen; thanks.)
=====
I updated the Corrected Text to simply use lower case wording, eliminating any rfc2119-related confusion. -- Alvaro.
Errata ID: 6498
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Graham Paasch
Date Reported: 2021-03-27
Held for Document Update by: Alvaro Retana
Date Held: 2021-03-29
Section 5.1.5 says:
LOCAL_PREF is a well-known attribute that SHALL be included in all UPDATE messages that a given BGP speaker sends to other internal peers.
It should say:
LOCAL_PREF is a well-known discretionary attribute that SHALL be included in all UPDATE messages that a given BGP speaker sends to other internal peers.
Notes:
It is unclear from the text to which of the four path attribute categories LOCAL_PREF belongs. There was even submitted an errata to create a fifth category for this attribute, but it is clear from the definition of the categories, that this attribute is well known discretionary. All routers must be capable of sending or receiving the LOCAL_PREF attribute, however it is up to a routers discretion whether to include that attribute in an UPDATE message.
=====
[Verifier notes.]
This is a valid report. The terminology in rfc4271 is not ideal, so using "discretionary" with a required action can cause significant confusion, even if that is the correct term for this attribute. A future version of this RFC should consider updating/cleaning up the terminology.
Errata ID: 150
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2006-01-26
Held for Document Update by: Stewart Bryant
Date Held: 2011-08-02
Section 9.1.1 says:
The Phase 1 decision function is a separate process,f which completes when it has no further work to do.
It should say:
The Phase 1 decision function is a separate process, which completes when it has no further work to do.
Errata ID: 3264
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anmol Khirbat
Date Reported: 2012-06-19
Held for Document Update by: Stewart Bryant
Section Appendix F.3 says:
Implementations that combine update messages (as described above in Section 6.1) may prefer to see all path attributes presented in a known order.
It should say:
Implementations that combine update messages (as described above in Appendix F.1) may prefer to see all path attributes presented in a known order.
Notes:
Section 6.1 does not say anything about combining update messages.
Errata ID: 3459
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lawrence Hui
Date Reported: 2013-01-16
Held for Document Update by: Stewart Bryant
Section 6.8 says:
If a pair of BGP speakers try to establish a BGP connection with each other simultaneously, then two parallel connections well be formed.
It should say:
If a pair of BGP speakers try to establish a BGP connection with each other simultaneously, then two parallel connections will be formed.
Notes:
This edit will replace the "well" with "will".
Errata ID: 3464
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lawrence Hui
Date Reported: 2013-01-17
Held for Document Update by: Stewart Bryant
Date Held: 2013-01-28
Section 9.1.1 says:
The Phase 1 decision function is a separate process,f which completes when it has no further work to do.
It should say:
The Phase 1 decision function is a separate process, which completes when it has no further work to do.
Notes:
This edit will remove the "f".
This is correct, but will not cause an interoperability issue, and thus can be fixed when the document is updated.
Errata ID: 3809
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-11-21
Held for Document Update by: Stewart Bryant
Date Held: 2013-11-22
Section 6 says:
Before the invalid routes are deleted from the system, it advertises, to its peers, either withdraws for the routes marked as invalid, or the new best routes before the invalid routes are deleted from the system.
It should say:
Before the invalid routes are deleted from the system, it advertises, to its peers, either withdraws for the routes marked as invalid, or the new best routes.
Notes:
The phrase "Before the invalid routes are deleted from the system" is unnecessarily repeated in the same sentence.
Errata ID: 4496
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2015-10-10
Held for Document Update by: Alvaro Retana
Date Held: 2015-10-12
Section 9.1.1 says:
... If the return value indicates the route is ineligible, the route MAY NOT serve as an input to the next phase of route selection; ...
It should say:
... If the return value indicates the route is ineligible, the route MUST NOT serve as an input to the next phase of route selection; ...
Notes:
RFC 2119 does not define special word MAY NOT. Obviously, ineligible route must not be used in route selection.
====
Errata ID: 5421
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Greg Skinner
Date Reported: 2018-07-15
Held for Document Update by: Alvaro Retana
Date Held: 2018-11-04
Section 8.2.2 says:
If the local system receives a KeepaliveTimer_Expires event (Event 11), the local system: - sends a KEEPALIVE message, - restarts the KeepaliveTimer, and - remains in the OpenConfirmed state.
It should say:
If the local system receives a KeepaliveTimer_Expires event (Event 11), the local system: - sends a KEEPALIVE message, - restarts the KeepaliveTimer, and - remains in the OpenConfirm state.
Errata ID: 5766
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alvaro Retana
Date Reported: 2019-06-28
Held for Document Update by: Alvaro Retana
Date Held: 2019-06-28
Section 9.2 says:
If, due to the limits on the maximum size of an UPDATE message (see Section 4), a single route doesn't fit into the message, the BGP speaker MUST not advertise the route to its peers and MAY choose to log an error locally.
It should say:
If, due to the limits on the maximum size of an UPDATE message (see Section 4), a single route doesn't fit into the message, the BGP speaker MUST NOT advertise the route to its peers and MAY choose to log an error locally.
Notes:
The Normative text should be "MUST NOT", and not "MUST not" -- both words should be capitalized.
Errata ID: 6256
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anton Yushkov
Date Reported: 2020-08-12
Held for Document Update by: Alvaro Retana
Date Held: 2020-08-18
Section 5.1.3 says:
3) When sending a message to an external peer X, and the peer is multiple IP hops away from the speaker (aka "multihop EBGP"): ... - By default, the BGP speaker SHOULD use the IP address of the interface that the speaker uses in the NEXT_HOP attribute to establish the BGP connection to peer X.
It should say:
3) When sending a message to an external peer X, and the peer is multiple IP hops away from the speaker (aka "multihop EBGP"): ... - By default, the BGP speaker SHOULD use the IP address of the interface that the speaker uses to establish the BGP connection to peer X in the NEXT_HOP attribute.
Notes:
confusing incorrect word order:
reading the original text, the reader might think that the BGP speaker is using the NEXT_HOP attribute as part of establishing a connection with the peer
Status: Rejected (4)
RFC 4271, "A Border Gateway Protocol 4 (BGP-4)", January 2006
Note: This RFC has been updated by RFC 4724, RFC 6286, RFC 6608, RFC 6793, RFC 7606, RFC 7607, RFC 7705, RFC 8212, RFC 8654, RFC 9072, RFC 9687
Source of RFC: idr (rtg)
Errata ID: 1332
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Aaron Hughes
Date Reported: 2008-02-26
Rejected by: Stewart Bryant
Date Rejected: 2011-08-02
Section 4.5 says:
OPEN Message Error subcodes: 1 - Unsupported Version Number. 2 - Bad Peer AS. 3 - Bad BGP Identifier. 4 - Unsupported Optional Parameter. 5 - [Deprecated - see Appendix A]. 6 - Unacceptable Hold Time.
It should say:
OPEN Message Error subcodes: 1 - Unsupported Version Number. 2 - Bad Peer AS. 3 - Bad BGP Identifier. 4 - Unsupported Optional Parameter. 5 - [Deprecated - see Appendix A]. 6 - Unacceptable Hold Time. 7 - Unsupported Capability
Notes:
7 - Unsupported Capability orig from RFC3392 seems to have accidently disappeared.
Thanks!
Aaron
--VERIFIER NOTES--
The working group debated this point and concluded the following:
The functionality (specifically, BGP Capabilities) this error code applies to does not appear anywhere in RFC 4271 (or RFC 1771). As IANA records, this error subcode is defined in RFC5492/RFC3392, along with the related functionality. The IANA registry is the final authority as to code point assignments, and is correct as written. Accordingly, this erratum is rejected.
Errata ID: 3366
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Shashank Tyagi
Date Reported: 2012-09-26
Rejected by: Stewart Bryant
Date Rejected: 2013-09-20
Section 8.2.2 says:
If a TcpConnectionFails event (Event 18) is received, the local system: - closes the BGP connection, - restarts the ConnectRetryTimer, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active.
It should say:
If a TcpConnectionFails event (Event 18) is received, the local system: - closes the BGP connection, - sets the HoldTimer to 0, - restarts the ConnectRetryTimer, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active.
Notes:
HoldTimer should only be used to control time in between BGP packets.
Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state.
--VERIFIER NOTES--
This represents a technical change to RFC4271 and is outside the scope of the errata system. The submitter is welcome to submit a draft proposing the change to RFC 4271 and work for consensus for the change in the IDR WG.
Errata ID: 3673
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: William McCall
Date Reported: 2013-06-28
Rejected by: Stewart Bryant
Date Rejected: 2013-10-04
Section 5 says:
Path attributes fall into four separate categories: 1. Well-known mandatory. 2. Well-known discretionary. 3. Optional transitive. 4. Optional non-transitive.
It should say:
Path attributes fall into five separate categories: 1. Well-known mandatory. 2. Well-known discretionary. 3. Well-known. 4. Optional transitive. 5. Optional non-transitive.
Notes:
Local pref is only a "well-known" attribute as it fails the definition for the behavior as a mandatory attribute and it is not exactly discretionary per 5.1.5's definition of local pref and section 5's definition of discretionary which states:
"5.1.5. LOCAL_PREF
LOCAL_PREF is a well-known attribute that SHALL be included in all
UPDATE messages that a given BGP speaker sends to other internal
peers."
Section 5's definition of discretionary:
" [...]Others are discretionary and MAY
or MAY NOT be sent in a particular UPDATE message."
As a well-known mandatory attribute would result in a NOTIFICATION per section 6.3, it cannot be well-known mandatory because it is only for internal peers. Thus, it is a separate category.
6.3
" If any of the well-known mandatory attributes are not present, then
the Error Subcode MUST be set to Missing Well-known Attribute. The
Data field MUST contain the Attribute Type Code of the missing,
well-known attribute."
In a future revision, a new term would probably be best to describe this. However, the categorization of attributes is misleading for now and the simplest approach is to add the new category already used by 5.1.5.
--VERIFIER NOTES--
This erratum was discussed on the IDR list.
The consensus was that whilst an alternative is to revert
from OpenSent to Idle on event 18 at that point, this was not
what was decided when RFC4271 was being produced, and
no one saw a good engineering reason to change it at this
stage.
On a matter of process, this proposal is not an Erratum
as the IETF sees it but an engineering change.
The submitter is, of course, welcome to submit a draft
proposing this change to RFC 4271 and the to discuss the
merits of the change with the IDR Working Group.
Errata ID: 3031
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kireeti Kompella
Date Reported: 2011-11-14
Rejected by: Stewart Bryant
Date Rejected: 2013-02-28
Section 9.1.2 says:
The Phase 2 decision function is blocked from running while the Phase 3 decision function is in process.
It should say:
The Phase 3 decision function is blocked from running while the Phase 2 decision function is in process.
Notes:
I believe that is what was intended; the text as is confuses me no end.
--VERIFIER NOTES--
It is accepted that the RFC text is confusing, but the proposed errata text is incorrect because this proposed revision implies that Phase 2 can begin running while Phase 3 is still running this contradicts other text in the RFC (9.1.2) which states that "The Phase 3 Routing Decision function is blocked from running whilst the Phase 2 decision function is in process."
It is anticipated that the IDR WG will publish material clarifying mutual exclusion in RFC4271.