RFC 4276 BGP-4 Implementation Report January 2006
In this document, the editors have compiled the results of the
implementation survey results and the informal survey.
1.1. Conventions Used in This Document
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 [RFC2119].
2. Results of Survey
The respondents replied "Y" (yes) or "N" (no) to the survey's 259
questions to indicate whether their implementation supports the
Functionality/Description of the [RFC2119] language in [RFC4271].
The respondents replied "O" (other) to indicate that the support is
neither "Y" nor "N" (for example, an alternate behavior).
2.1. Significant Differences
Each question received affirmative responses from at least two
implementers (i.e., two "Y" responses, or one "Y" and one "O"),
except the following questions:
a) MUST - Linked Questions 212/213, regarding Section 9.1.4
Due to the format of the linked questions, three vendors (Cisco,
Laurel, and NextHop) replied "N" to Question 213. (See Section2.2 for details.)
b) SHALL NOT - Question 228, regarding Section 9.2.2.2
Three vendors (Alcatel, Cisco, and Laurel) answered "N" to SHALL
NOT (meaning they did). One vendor (NextHop) indicated "O"
matching the specification.
Text: Routes that have different MULTI_EXIT_DISC attribute SHALL
NOT be aggregated. (Section 9.2.2.2, [RFC4271])
c) SHOULD - Questions 257 and 258, regarding Appendix F
Three vendors answered "N" and one vendor answered "Y" to Question
257. All four vendors answered "N" to Question 258. (Please note
that support of Appendix F, "Implementation Recommendations", is
optional.)
Hares & Retana Informational [Page 4]

RFC 4276 BGP-4 Implementation Report January 2006
Text: A BGP speaker which needs to withdraw a destination and
send an update about a more specific or less specific route
SHOULD combine them into the same UPDATE message.
(Appendix F.2, [RFC4271])
Text: The last instance (rightmost occurrence) of that AS number
is kept. (Appendix F.6, [RFC4271])
d) MAY - Questions 180 and 254, regarding Sections 8.1.2.4 and 10
Three vendors answered "N", and 1 replied "Y" to Question 180.
Text: The Event numbers (1-28) utilized in this state machine
description aid in specifying the behavior of the BGP state
machine. Implementations MAY use these numbers to provide
network management information. The exact form of a FSM or
the FSM events are specific to each implementation.
(Section 8.1.2.4, [RFC4271])
Editors' note: Section 8.1.2.4 was written to allow existing
implementations to transition to the new event
numbering. It was expected over time (3 years)
that the FSM event numbering would be updated to
the new numbering.
Three vendors answered "N" and one answered "Y" to Question 254
about configurable jitter time values.
Text: A given BGP speaker MAY apply the same jitter to each of
these quantities regardless of the destinations to which
the updates are being sent; that is, jitter need not be
configured on a "per peer" basis. (Section 10, [RFC4271])
Question: Is the jitter range configurable?
2.2. Overview of Differences
This section provides the reader with a shortcut to the points where
the four implementations differ.
The following questions were not answered "Y" by all four respondents
(Note that the question numbers correspond to the final digit of
subsection numbers of Section 3):
MUST
97, 106, 107, 111, 122, 125, 138, 141, 213
Hares & Retana Informational [Page 5]

RFC 4276 BGP-4 Implementation Report January 2006
3.0.2. Local Policy Changes
Functionality/Description: 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]
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.1. Routes: Advertisement and Storage / Section 3.1 [RFC4271]
3.1.3. Withdraw Routes from Service
Functionality/Description: Does your implementation support the
three methods described in this section?
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.1.4. Path Attributes
Functionality/Description: Added to or modified before
advertising the route
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 8]

RFC 4276 BGP-4 Implementation Report January 2006
3.11.48. Prepending
Functionality/Description: The local system MAY include/prepend
more than one instance of its own AS number in the AS_PATH
attribute
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.12. NEXT_HOP / Section 5.1.3 [RFC4271]
3.12.49. NEXT_HOP
Functionality/Description: Used as the next hop to the
destinations listed in the UPDATE message
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.12.50. NEXT_HOP
Functionality/Description: When sending a message to an internal
peer, if the route is not locally originated, the BGP speaker
SHOULD NOT modify the NEXT_HOP attribute, unless it has been
explicitly configured to announce its own IP address as the
NEXT_HOP
RFC2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 23]

RFC 4276 BGP-4 Implementation Report January 2006
3.12.51. NEXT_HOP
Functionality/Description: When announcing a locally originated
route to an internal peer, the BGP speaker SHOULD use as the
NEXT_HOP the interface address of the router through which the
announced network is reachable for the speaker
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.12.52. NEXT_HOP
Functionality/Description: If the route is directly connected to
the speaker, or the interface address of the router through
which the announced network is reachable for the speaker is the
internal peer's address, then the BGP speaker SHOULD use for the
NEXT_HOP attribute its own IP address (the address of the
interface that is used to reach the peer)
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.12.53. "First Party" NEXT_HOP
Functionality/Description: If the external peer to which the
route is being advertised shares a common subnet with one of the
interfaces of the announcing BGP speaker, the speaker MAY use
the IP address associated with such an interface in the NEXT_HOP
attribute
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 24]

RFC 4276 BGP-4 Implementation Report January 2006
3.12.54. Default NEXT_HOP
Functionality/Description: IP address of the interface that the
speaker uses to establish the BGP connection to peer X
RFC2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.12.55. NEXT_HOP Propagation
Functionality/Description: The speaker MAY be configured to
propagate the NEXT_HOP attribute. In this case when advertising
a route that the speaker learned from one of its peers, the
NEXT_HOP attribute of the advertised route is exactly the same
as the NEXT_HOP attribute of the learned route (the speaker just
doesn't modify the NEXT_HOP attribute)
RFC2119: MAY
Alcatel Y/N/O/Comments: O
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.12.56. Third Party NEXT_HOP
Functionality/Description: MUST be able to support disabling it
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 25]

RFC 4276 BGP-4 Implementation Report January 2006
3.20.121. First Neighbor in AS_PATH Check
Functionality/Description: If the UPDATE message is received
from an external peer, the local system MAY check whether the
leftmost AS in the AS_PATH attribute is equal to the autonomous
system number of the peer that sent the message
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: Y
3.20.122. First Neighbor in AS_PATH Check
Functionality/Description: If the check determines that this is
not the case, the Error Subcode MUST be set to Malformed AS_PATH
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: n/a
NextHop Y/N/O/Comments: Y
3.20.123. Optional Attributes
Functionality/Description: Value MUST be checked if the
attribute is recognized
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 47]

RFC 4276 BGP-4 Implementation Report January 2006
3.24.136. Cease NOTIFICATION
Functionality/Description: Not used for specified fatal errors
RFC2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.24.137. Upper bound on the number of address prefixes the speaker
is willing to accept from a neighbor
Functionality/Description: Support by local configuration
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.24.138. Upper bound on the number of address prefixes the speaker
is willing to accept from a neighbor
Functionality/Description: If exceeded and the BGP speaker
decides to terminate its BGP connection, the Cease NOTIFICATION
MUST be used
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N We don't send CEASE but we plan to
correct that soon.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y No termination of peers is supported
We are considering support with the
maximum prefix document for later
releases.
Hares & Retana Informational [Page 52]

RFC 4276 BGP-4 Implementation Report January 2006
3.24.139. Upper bound on the number of address prefixes the speaker
is willing to accept from a neighbor
Functionality/Description: Log locally
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.25. BGP Connection Collision Detection / Section 6.8 [RFC4271]
3.25.140. Connection Collision
Functionality/Description: One of the connections MUST be closed
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.25.141. Receipt of an OPEN Message
Functionality/Description: The local system MUST examine all of
its connections that are in the OpenConfirm state
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: O We detect collision through some
other implementation specific way
and resolve by method specified in
the document.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 53]

RFC 4276 BGP-4 Implementation Report January 2006
3.25.142. Receipt of an OPEN Message
Functionality/Description: Examine connections in an OpenSent
state if it knows the BGP Identifier of the peer by means
outside of the protocol
RFC2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.26. BGP Version Negotiation / Section 7 [RFC4271]
3.26.143. Version Negotiation
Functionality/Description: Multiple attempts to open a BGP
connection, starting with the highest version number each
supports
RFC2119: MAY
Alcatel Y/N/O/Comments: N Supports only version 4
Cisco Y/N/O/Comments: O We resolve it through config. If
Config is for version 3, and we get
version 4, OPEN will always fail.
Similarly, if configed (default) is
version 4 and peers configured is 3,
we don't try to negotiate version 3
unless we have configured it.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: N Supports only version 4.
3.26.144. Future Versions of BGP
Functionality/Description: MUST retain the format of the OPEN
and NOTIFICATION messages
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 54]

RFC 4276 BGP-4 Implementation Report January 20063.45. Frequency of Route Advertisement / Section 9.2.1.1 [RFC4271]
3.45.224. MinRouteAdvertisementIntervalTimer
Functionality/Description: Minimum separation between two UPDATE
messages sent by a BGP speaker to a peer that advertise feasible
routes and/or withdrawal of unfeasible routes to some common set
of destinations
RFC2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.45.225. Fast Convergence
Functionality/Description: MinRouteAdvertisementIntervalTimer
used for internal peers SHOULD be shorter than the
MinRouteAdvertisementIntervalTimer used for external peers, or
RFC2119: SHOULD
Alcatel Y/N/O/Comments: O Configurable on per peer basis.
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: N they are same for ebgp and ibgp
NextHop Y/N/O/Comments: Y Configuration option allows to set
the time per peer.
3.45.226. Fast Convergence
Functionality/Description: The procedure describes in this
section SHOULD NOT apply for routes sent to internal peers
RFC2119: SHOULD NOT
Alcatel Y/N/O/Comments: O Operator has to ensure that through
configuration.
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: Y Default setting is off for BGP
peers.
Hares & Retana Informational [Page 81]

RFC 4276 BGP-4 Implementation Report January 2006
3.46.233. Routes to be aggregated have different AS_PATH attributes
Functionality/Description: The aggregated AS_PATH attribute
SHALL satisfy all of the following conditions: ...
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.46.234. Routes to be aggregated have different AS_PATH attributes
Functionality/Description: All tuples of type AS_SEQUENCE in the
aggregated AS_PATH SHALL appear in all of the AS_PATH in the
initial set of routes to be aggregated
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.46.235. Routes to be aggregated have different AS_PATH attributes
Functionality/Description: All tuples of type AS_SET in the
aggregated AS_PATH SHALL appear in at least one of the AS_PATH
in the initial set
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 84]

RFC 4276 BGP-4 Implementation Report January 2006
3.46.236. Routes to be aggregated have different AS_PATH attributes
Functionality/Description: For any tuple X of type AS_SEQUENCE
in the aggregated AS_PATH which precedes tuple Y in the
aggregated AS_PATH, X precedes Y in each AS_PATH in the initial
set which contains Y, regardless of the type of Y
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.46.237. Routes to be aggregated have different AS_PATH attributes
Functionality/Description: No tuple of type AS_SET with the same
value SHALL appear more than once in the aggregated AS_PATH
RFC2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.46.238. Routes to be aggregated have different AS_PATH attributes
Functionality/Description: Multiple tuples of type AS_SEQUENCE
with the same value may appear in the aggregated AS_PATH only
when adjacent to another tuple of the same type and value
RFC2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 85]

RFC 4276 BGP-4 Implementation Report January 20064. Additional BGP Implementations Information
Three implementations responded to a call (5/20/04-6/2/04) for
information on those implementations that had a BGP implementation,
but did not complete the full survey. The responses for the call for
additional information are below.
4.1. Avici
If you have an implementation of BGP and you did not send in an
implementation report (answering the 259 questions), could you send
me the answer the following questions:
1) BGP product
Contributor (your name):Curtis Villamizar [curtis@fictitious.org]
Company: Avici
name of product: IPriori (TM)
minor version: No interoperability problems with any version.
Current deployed versions are 5.x and 6.0.x.
Version 6.1 and beyond are tested against the
latest BGP specification [RFC4271].
2) What other implementations you interoperate with.
Cisco: IOS 12.0(22)
Juniper: JUNOS (version not given)
3) Do you inter-operate with:
1) Alcatel BGP (release) - not tested
2) cisco BGP IOS 12.0(27)s - not tested
tested with IOS 12.0(22); BGP is the same
3) laurel BGP (specify release) - not tested
4) NextHop GateD - not tested
4) Did the length of the survey for BGP cause you to not
submit the BGP implementation report?
yes
Hares & Retana Informational [Page 93]

RFC 4276 BGP-4 Implementation Report January 20064.2. Data Connection Ltd.
If you have an implementation of BGP and you did not send in an
implementation report (answering the 259 questions), could you send
me the answer the following questions:
1) BGP product
Contributor (your name): Mike Dell
Company: Data Connection Ltd.
name of product: DC-BGP
version and minor of software: v1.1
release date: April 2003
2) What other implementations you interoperate with.
Cisco (12.0(26)S)
Alcatal (7770 0BX)
Agilent (Router Tester)
Ixia (1600T)
Netplane (Powercode)
Nortel (Shasta 5000 BSN)
Redback (SmartEdge 800)
Riverstone (RS8000)
Spirent (AX4000)
IP Infusion (ZebOs)
Nokia (IP400)
Juniper (M5)
3) Do you inter-operate with
1) Alcatel BGP (release) YES
2) cisco BGP IOS 12.0(27)s
Unknown, but we do inter-operate with v12.0(26)s
3) laurel BGP (specify release) Unknown
4) NextHop GateD YES
4) Did the length of the survey for BGP
cause you to not submit the BGP
implementation report?
YES
4.3. Nokia
If you have an implementation of BGP and you did not send in an
implementation report (answering the 259 questions), could you send
me the answer the following questions:
Hares & Retana Informational [Page 94]

RFC 4276 BGP-4 Implementation Report January 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hares & Retana Informational [Page 97]