draft-ietf-idr-bgp4-24.txt   draft-ietf-idr-bgp4-25.txt 
Network Working Group Y. Rekhter Network Working Group Y. Rekhter
INTERNET DRAFT T.Li INTERNET DRAFT T.Li
S. Hares Obsoletes: RFC1771 S. Hares
Editors Editors
A Border Gateway Protocol 4 (BGP-4) A Border Gateway Protocol 4 (BGP-4)
<draft-ietf-idr-bgp4-24.txt> <draft-ietf-idr-bgp4-25.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 3, line 5 skipping to change at page 2, line 27
based forwarding paradigm, which assumes that a router forwards a based forwarding paradigm, which assumes that a router forwards a
packet based solely on the destination address carried in the IP packet based solely on the destination address carried in the IP
header of the packet. This, in turn, reflects the set of policy header of the packet. This, in turn, reflects the set of policy
decisions that can (and can not) be enforced using BGP. BGP can decisions that can (and can not) be enforced using BGP. BGP can
support only the policies conforming to the destination-based support only the policies conforming to the destination-based
forwarding paradigm. forwarding paradigm.
This specification covers only the exchange of IP version 4 network This specification covers only the exchange of IP version 4 network
reachability information. reachability information.
This document obsoletes RFC1771.
Table of Contents Table of Contents
1. Definition of commonly used terms . . . . . . . . . . . . . . 5 1. Definition of commonly used terms . . . . . . . . . . . . . . 5
2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
Specification of Requirements . . . . . . . . . . . . . . . . . . 8 Specification of Requirements . . . . . . . . . . . . . . . . . . 8
3. Summary of Operation . . . . . . . . . . . . . . . . . . . . . 8 3. Summary of Operation . . . . . . . . . . . . . . . . . . . . . 8
3.1 Routes: Advertisement and Storage . . . . . . . . . . . . . . 9 3.1 Routes: Advertisement and Storage . . . . . . . . . . . . . . 9
3.2 Routing Information Bases . . . . . . . . . . . . . . . . . . 10 3.2 Routing Information Bases . . . . . . . . . . . . . . . . . . 10
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Message Header Format . . . . . . . . . . . . . . . . . . . . 12 4.1 Message Header Format . . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 4, line 38 skipping to change at page 4, line 38
Appendix E. TCP options that may be used with BGP . . . . . . . . 91 Appendix E. TCP options that may be used with BGP . . . . . . . . 91
Appendix F. Implementation Recommendations . . . . . . . . . . . 91 Appendix F. Implementation Recommendations . . . . . . . . . . . 91
Appendix F.1 Multiple Networks Per Message . . . . . . . . . . . 91 Appendix F.1 Multiple Networks Per Message . . . . . . . . . . . 91
Appendix F.2 Reducing route flapping . . . . . . . . . . . . . . 92 Appendix F.2 Reducing route flapping . . . . . . . . . . . . . . 92
Appendix F.3 Path attribute ordering . . . . . . . . . . . . . . 92 Appendix F.3 Path attribute ordering . . . . . . . . . . . . . . 92
Appendix F.4 AS_SET sorting . . . . . . . . . . . . . . . . . . . 92 Appendix F.4 AS_SET sorting . . . . . . . . . . . . . . . . . . . 92
Appendix F.5 Control over version negotiation . . . . . . . . . . 93 Appendix F.5 Control over version negotiation . . . . . . . . . . 93
Appendix F.6 Complex AS_PATH aggregation . . . . . . . . . . . . 93 Appendix F.6 Complex AS_PATH aggregation . . . . . . . . . . . . 93
Security Considerations . . . . . . . . . . . . . . . . . . . . . 94 Security Considerations . . . . . . . . . . . . . . . . . . . . . 94
IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 95 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 95
IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . . . 97
Full Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 96 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . 98
Normative References . . . . . . . . . . . . . . . . . . . . . . 97 Normative References . . . . . . . . . . . . . . . . . . . . . . 98
Non-normative References . . . . . . . . . . . . . . . . . . . . 98 Non-normative References . . . . . . . . . . . . . . . . . . . . 99
Authors Information . . . . . . . . . . . . . . . . . . . . . . . 99 Authors Information . . . . . . . . . . . . . . . . . . . . . . . 100
Abstract Abstract
The Border Gateway Protocol (BGP) is an inter-Autonomous System rout- The Border Gateway Protocol (BGP) is an inter-Autonomous System rout-
ing protocol. ing protocol.
The primary function of a BGP speaking system is to exchange network The primary function of a BGP speaking system is to exchange network
reachability information with other BGP systems. This network reacha- reachability information with other BGP systems. This network reacha-
bility information includes information on the list of Autonomous bility information includes information on the list of Autonomous
Systems (ASs) that reachability information traverses. This informa- Systems (ASs) that reachability information traverses. This informa-
skipping to change at page 94, line 24 skipping to change at page 94, line 24
as doing so will not cause a segment with length greater than as doing so will not cause a segment with length greater than
255 to be generated. 255 to be generated.
If as a result of the above procedure a given AS number appears If as a result of the above procedure a given AS number appears
more than once within the aggregated AS_PATH attribute, all, but more than once within the aggregated AS_PATH attribute, all, but
the last instance (rightmost occurrence) of that AS number should the last instance (rightmost occurrence) of that AS number should
be removed from the aggregated AS_PATH attribute. be removed from the aggregated AS_PATH attribute.
Security Considerations Security Considerations
The authentication mechanism that an implementation of BGP MUST sup- A BGP implementation MUST support the authentication mechanism speci-
port is specified in RFC 2385 [RFC2385]. The authentication provided fied in RFC 2385 [RFC2385]. The authentication provided by this mech-
by this mechanism could be done on a per peer basis. anism could be done on a per peer basis.
BGP makes use of TCP for reliable transport of its traffic between BGP makes use of TCP for reliable transport of its traffic between
peer routers. To provide connection-oriented integrity and data ori- peer routers. To provide connection-oriented integrity and data ori-
gin authentication, on a point-to-point basis, BGP specifies use of gin authentication, on a point-to-point basis, BGP specifies use of
the mechanism defined in RFC 2385. These services are intended to the mechanism defined in RFC 2385. These services are intended to
detect and reject active wiretapping attacks against the inter-router detect and reject active wiretapping attacks against the inter-router
TCP connections. Absent use of mechanisms that effect these security TCP connections. Absent use of mechanisms that effect these security
services, attackers can disrupt these TCP connections and/or masquer- services, attackers can disrupt these TCP connections and/or masquer-
ade as a legitimate peer router. Because the mechanism defined in the ade as a legitimate peer router. Because the mechanism defined in the
RFC does not provide peer-entity authentication, these connections RFC does not provide peer-entity authentication, these connections
skipping to change at page 95, line 41 skipping to change at page 95, line 41
analogous MAC algorithms, which typically employ keys in the range of analogous MAC algorithms, which typically employ keys in the range of
16-20 bytes. RFC 3562 also observes that, to provide enough random 16-20 bytes. RFC 3562 also observes that, to provide enough random
bits at the low end of this range, a typical ACSII text string would bits at the low end of this range, a typical ACSII text string would
have to be close to the upper bound for key length specified in RFC have to be close to the upper bound for key length specified in RFC
2385. 2385.
BGP vulnerabilities analysis is discussed in [BGP_VULN]. BGP vulnerabilities analysis is discussed in [BGP_VULN].
IANA Considerations IANA Considerations
All new BGP message types, Path Attributes Type codes, Message Header All the BGP messages contain an 8-bit message type, for which IANA is
Error subcodes, OPEN Message Error subcodes, and UPDATE Message Error to create and maintain a registry entitled "BGP Message Types". This
subcodes MUST only be made using the Standards Action process defined document defines the following message types:
in [RFC2434].
This document defines the following message types: OPEN, UPDATE, Name Value Definition
KEEPALIVE, NOTIFICATION. ---- ----- ----------
OPEN 1 See Section 4.2
UPDATE 2 See Section 4.3
KEEPALIVE 3 See Section 4.4
NOTIFICATION 4 See Section 4.5
Future assignment are to be made using the Standards Action process
defined in [RFC2434]. Assignments consist of a name and the value.
This document defines the following Path Attributes Type codes: ORI- The BGP UPDATE messages may carry one or more Path Attributes, where
GIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC, LOCAL_PREF, each Attribute contains an 8-bit Attribute Type Code. IANA is already
ATOMIC_AGGREGATE, AGGREGATOR. maintaining such a registry, entitled "BGP Path Attributes". [note to
IANA, the registry already exists at http://www.iana.org/assign-
ments/bgp-parameters, but should be renamed per this document. XXX to
be removed upon RFC publication.] This document defines the following
Path Attributes Type Codes:
Name Value Definition
---- ----- ----------
ORIGIN 1 See Section 5.1.1
AS_PATH 2 See Section 5.1.2
NEXT_HOP 3 See Section 5.1.3
MULTI_EXIT_DISC 4 See Section 5.1.4
LOCAL_PREF 5 See Section 5.1.5
ATOMIC_AGGREGATE 6 See Section 5.1.6
AGGREGATOR 7 See Section 5.1.7
Future assignment are to be made using the Standards Action process
defined in [RFC2434]. Assignments consist of a name and the value.
The BGP NOTIFICATION message carries an 8-bit Error Code, for which
IANA is to create and maintain a registry entitled "BGP Error Codes".
This document defines the following Error Codes:
Name Value Definition
------------ ----- ----------
Message Header Error 1 Section 6.1
OPEN Message Error 2 Section 6.2
UPDATE Message Error 3 Section 6.3
Hold Timer Expired 4 Section 6.5
Finite State Machine Error 5 Section 6.6
Cease 6 Section 6.7
Future assignment are to be made using the Standards Action process
defined in [RFC2434]. Assignments consist of a name and the value.
The BGP NOTIFICATION message carries an 8-bit Error Subcode, where
each Subcode has to be defined within the context of a particular
Error Code, and thus has to be unique only within that context.
IANA is to create and maintain a set of registries, "Error Subcodes",
with a separate registry for each BGP Error Code. Future assignments
are to be made using the Standards Action process defined in
[RFC2434]. Assignments consist of a name and the value.
This document defines the following Message Header Error subcodes: This document defines the following Message Header Error subcodes:
Connection Not Synchronized, Bad Message Length, Bad Message Type.
Name Value Definition
-------------------- ----- ----------
Connection Not Synchronized 1 See Section 6.1
Bad Message Length 2 See Section 6.1
Bad Message Type 3 See Section 6.1
This document defines the following OPEN Message Error subcodes: This document defines the following OPEN Message Error subcodes:
Unsupported Version Number, Bad Peer AS, Bad BGP Identifier, Unsup-
ported Optional Parameter, Unacceptable Hold Time.
This document defines the following UPDATE Message Error subcodes: Name Value Definition
Malformed Attribute List, Unrecognized Well-known Attribute, Missing -------------------- ----- ----------
Well-known Attribute, Attribute Flags Error, Attribute Length Error, Unsupported Version Number 1 See Section 6.2
Invalid ORIGIN Attribute, Invalid NEXT_HOP Attribute, Optional Bad Peer AS 2 See Section 6.2
Attribute Error, Invalid Network Field, Malformed AS_PATH. Bad BGP Identifier 3 See Section 6.2
Unsupported Optional Parameter 4 See Section 6.2
[Deprecated] 5 See Appendix A
Unacceptable Hold Time 6 See Section 6.2
IPR Notice This document defines the following UPDATE Message Error subcodes:
The IETF has been notified of intellectual property rights claimed in Name Value Definition
regard to some or all of the specification contained in this docu- -------------------- --- ----------
ment. For more information consult the online list of claimed rights. Malformed Attribute List 1 See Section 6.3
Unrecognized Well-known Attribute 2 See Section 6.3
Missing Well-known Attribute 3 See Section 6.3
Attribute Flags Error 4 See Section 6.3
Attribute Length Error 5 See Section 6.3
Invalid ORIGIN Attribute 6 See Section 6.3
[Deprecated] 7 See Appendix A
Invalid NEXT_HOP Attribute 8 See Section 6.3
Optional Attribute Error 9 See Section 6.3
Invalid Network Field 10 See Section 6.3
Malformed AS_PATH 11 See Section 6.3
The IETF takes no position regarding the validity or scope of any IPR Disclosure Acknowledgement
intellectual property or other rights that might be claimed to per-
tain 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; neither does it represent that it has made
any effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of
rights made available for publication 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 implementors or users of this specification can be obtained from
the IETF Secretariat.
The IETF invites any interested party to bring to its attention any By submitting this Internet-Draft, I certify that any applicable
copyrights, patents or patent applications, or other proprietary patent or other IPR claims of which I am aware have been disclosed,
rights which may cover technology that may be required to practice and any of which I become aware will be disclosed, in accordance with
this standard. Please address the information to the IETF Executive RFC 3668.
Director.
Full Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (year). 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 translations of it may be copied and furnished to Additional copyright notices are not permitted in IETF Documents
others, and derivative works that comment on or otherwise explain it except in the case where such document is the product of a joint
or assist in its implementation may be prepared, copied, published development effort between the IETF and another standards development
and distributed, in whole or in part, without restriction of any organization or the document is a republication of the work of
kind, provided that the above copyright notice and this paragraph are another standards organization. Such exceptions must be approved on
included on all such copies and derivative works. However, this doc- an individual basis by the IAB.
ument itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be Disclaimer
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Normative References Normative References
[RFC791] Postel, J., "Internet Protocol - DARPA Internet Program Pro- [RFC791] Postel, J., "Internet Protocol - DARPA Internet Program Pro-
tocol Specification", RFC791, September 1981. tocol Specification", RFC791, September 1981.
[RFC793] Postel, J., "Transmission Control Protocol - DARPA Internet [RFC793] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC793, September 1981. Program Protocol Specification", RFC793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC2385, August 1998. Signature Option", RFC2385, August 1998.
[RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC2434, October 1998 Considerations Section in RFCs", RFC2434, October 1998
[RFC2474] Nichols, K., et al.,"Definition of the Differentiated Ser- [RFC2474] Nichols, K., et al.,"Definition of the Differentiated Ser-
vices Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474, vices Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474, Decem-
December 1998 ber 1998
Non-normative References Non-normative References
[RFC904] Mills, D., "Exterior Gateway Protocol Formal Specification", [RFC904] Mills, D., "Exterior Gateway Protocol Formal Specification",
RFC904, April 1984. RFC904, April 1984.
[RFC1092] Rekhter, Y., "EGP and Policy Based Routing in the New [RFC1092] Rekhter, Y., "EGP and Policy Based Routing in the New
NSFNET Backbone", RFC1092, February 1989. NSFNET Backbone", RFC1092, February 1989.
[RFC1093] Braun, H-W., "The NSFNET Routing Architecture", RFC1093, [RFC1093] Braun, H-W., "The NSFNET Routing Architecture", RFC1093,
skipping to change at page 98, line 26 skipping to change at page 99, line 25
[RFC1772] Rekhter, Y., and P. Gross, "Application of the Border Gate- [RFC1772] Rekhter, Y., and P. Gross, "Application of the Border Gate-
way Protocol in the Internet", RFC1772, March 1995. way Protocol in the Internet", RFC1772, March 1995.
[RFC1518] Rekhter, Y., Li, T., "An Architecture for IP Address Allo- [RFC1518] Rekhter, Y., Li, T., "An Architecture for IP Address Allo-
cation with CIDR", RFC 1518, September 1993. cation with CIDR", RFC 1518, September 1993.
[RFC1519] Fuller, V., Li, T., Yu, J., and Varadhan, K., ""Classless [RFC1519] Fuller, V., Li, T., Yu, J., and Varadhan, K., ""Classless
Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Inter-Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC1519, September 1993. Strategy", RFC1519, September 1993.
[RFC1930] Hawkinson, J., Bates, T.,"Guidelines for creation, selec-
tion, and registration of an Autonomous System (AS)", RFC1930, March
1996.
[RFC1997] R. Chandra, P. Traina, T. Li, "BGP Communities Attribute", [RFC1997] R. Chandra, P. Traina, T. Li, "BGP Communities Attribute",
RFC 1997, August 1996. RFC 1997, August 1996.
[RFC2439] C. Villamizar, R. Chandra, R. Govindan, "BGP Route Flap [RFC2439] C. Villamizar, R. Chandra, R. Govindan, "BGP Route Flap
Damping", RFC2439, November 1998. Damping", RFC2439, November 1998.
[RFC2796] Bates, T., Chandra, R., Chen, E., "BGP Route Reflection - [RFC2796] Bates, T., Chandra, R., Chen, E., "BGP Route Reflection -
An Alternative to Full Mesh IBGP", RFC2796, April 2000. An Alternative to Full Mesh IBGP", RFC2796, April 2000.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/