doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc4893.txt b/doc/rfc/rfc4893.txt
new file mode 100644
index 0000000..2c9a28b
--- /dev/null
+++ b/doc/rfc/rfc4893.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                           Q. Vohra
+Request for Comments: 4893                              Juniper Networks
+Category: Standards Track                                        E. Chen
+                                                           Cisco Systems
+                                                                May 2007
+
+
+               BGP Support for Four-octet AS Number Space
+
+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 IETF Trust (2007).
+
+Abstract
+
+   Currently the Autonomous System (AS) number is encoded as a two-octet
+   entity in BGP. This document describes extensions to BGP to carry the
+   Autonomous System number as a four-octet entity.
+
+1.  Introduction
+
+   Currently the Autonomous System number is encoded as a two-octet
+   entity in BGP [BGP].  To prepare for the anticipated exhaustion of
+   the two-octet AS numbers, this document describes extensions to BGP
+   to carry the Autonomous System number as a four-octet entity.
+
+   More specifically, this document defines a new BGP capability, Four-
+   octet AS Number Capability, that can be used by a BGP speaker to
+   indicate its support for the four-octet AS numbers.  Two new
+   attributes, AS4_PATH and AS4_AGGREGATOR, are introduced that can be
+   used to propagate four-octet based AS path information across BGP
+   speakers that do not support the four-octet AS numbers.  This
+   document also specifies mechanisms for constructing the AS path
+   information from the AS_PATH attribute and the AS4_PATH attribute.
+
+   The extensions proposed in this document allow a gradual transition
+   from 2-octet AS numbers to 4-octet AS numbers.
+
+
+
+
+
+
+Vohra & Chen                Standards Track                     [Page 1]
+
+RFC 4893       BGP Support for Four-octet AS Number Space       May 2007
+
+
+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 [RFC2119].
+
+3.  Protocol Extensions
+
+   For the purpose of this document we define a BGP speaker that does
+   not support the new 4-octet AS number extensions as an OLD BGP
+   speaker, and a BGP speaker which supports the new 4-octet AS number
+   extensions as a NEW BGP speaker.
+
+   BGP carries the Autonomous System number in the "My Autonomous
+   System" field of the OPEN message, in the AS_PATH attribute of the
+   UPDATE message, and in the AGGREGATOR attribute of the UPDATE
+   message.  BGP also carries the Autonomous System number in the BGP
+   Communities attribute.
+
+   A NEW BGP speaker uses BGP Capability Advertisements [RFC2842] to
+   advertise to its neighbors (either internal or external) that it
+   supports 4-octet AS number extensions, as specified in this document.
+
+   The Capability that is used by a BGP speaker to convey to its BGP
+   peer the 4-octet Autonomous System number capability, also carries
+   the 4-octet Autonomous System number of the speaker in the Capability
+   Value field of the Capability Optional Parameter.  The Capability
+   Length field of the Capability is set to 4.
+
+   NEW BGP speakers carry AS path information expressed in terms of 4-
+   octet Autonomous Systems numbers by using the existing AS_PATH
+   attribute, except that each AS number in this attribute is encoded
+   not as a 2-octet, but as a 4-octet entity.  The same applies to the
+   AGGREGATOR attribute - NEW BGP speakers use the same attribute,
+   except that the AS carried in this attribute is encoded as a 4-octet
+   entity.
+
+   To preserve AS path information with 4-octet AS numbers across OLD
+   BGP speakers, this document defines a new AS path attribute, called
+   AS4_PATH.  This is an optional transitive attribute that contains the
+   AS path encoded with 4-octet AS numbers.  The AS4_PATH attribute has
+   the same semantics as the AS_PATH attribute, except that it is
+   optional transitive, and it carries 4-octet AS numbers.
+
+   To prevent the possible propagation of confederation path segments
+   outside of a confederation, the path segment types AS_CONFED_SEQUENCE
+   and AS_CONFED_SET [RFC3065] are declared invalid for the AS4_PATH
+   attribute.
+
+
+
+Vohra & Chen                Standards Track                     [Page 2]
+
+RFC 4893       BGP Support for Four-octet AS Number Space       May 2007
+
+
+   Similarly, this document defines a new aggregator attribute called
+   AS4_AGGREGATOR, which is optional transitive.  The AS4_AGGREGATOR
+   attribute has the same semantics as the AGGREGATOR attribute, except
+   that it carries a 4-octet AS number.
+
+   Currently assigned 2-octet Autonomous System numbers are converted
+   into 4-octet Autonomous System numbers by setting the two high-order
+   octets of the 4-octet field to zero.  Such a 4-octet AS number is
+   said to be mappable to a 2-octet AS number.
+
+   To represent 4-octet AS numbers (which are not mapped from 2-octets)
+   as 2-octet AS numbers in the AS path information encoded with 2-octet
+   AS numbers, this document reserves a 2-octet AS number.  We denote
+   this special AS number as AS_TRANS for ease of description in the
+   rest of this specification.  This AS number is also placed in the "My
+   Autonomous System" field of the OPEN message originated by a NEW BGP
+   speaker, if the speaker does not have a (globally unique) 2-octet AS
+   number.
+
+4.  Operations
+
+4.1.  Interaction Between NEW BGP Speakers
+
+   A BGP speaker that supports 4-octet Autonomous System numbers SHOULD
+   advertise this to its peers using the BGP Capability Advertisements.
+   A BGP speaker that advertises such capability to a particular peer,
+   and receives from that peer the advertisement of such capability MUST
+   encode Autonomous System numbers as 4-octet entities in both the
+   AS_PATH and the AGGREGATOR attributes in the updates it sends to the
+   peer, and MUST assume that these attributes in the updates received
+   from the peer encode Autonomous System numbers as 4-octet entities.
+
+   The new attributes, AS4_PATH and AS4_AGGREGATOR SHOULD NOT be carried
+   in the UPDATE messages between NEW BGP peers.  A NEW BGP speaker that
+   receives the AS4_PATH and AS4_AGGREGATOR path attributes in an UPDATE
+   message from a NEW BGP speaker SHOULD discard these path attributes
+   and continue processing the UPDATE message.
+
+4.2.  Interaction Between NEW and OLD BGP Speakers
+
+4.2.1.  BGP Peering
+
+   Note that peering between a NEW BGP speaker and an OLD one is
+   possible only if the NEW BGP speaker has a 2-octet AS number.
+   However, this document does not assume that an Autonomous System with
+   NEW speakers has to have a globally unique 2-octet AS number --
+   AS_TRANS could be used instead (even if a multiple Autonomous System
+   would use it).
+
+
+
+Vohra & Chen                Standards Track                     [Page 3]
+
+RFC 4893       BGP Support for Four-octet AS Number Space       May 2007
+
+
+4.2.2.  Generating Updates
+
+   When communicating with an OLD BGP speaker, a NEW speaker MUST send
+   the AS path information in the AS_PATH attribute encoded with 2-octet
+   AS numbers.  The NEW speaker MUST also send the AS path information
+   in the AS4_PATH attribute (encoded with 4-octet AS numbers), except
+   for the case where the entire AS path information is composed of 2-
+   octet AS numbers only.  In this case, the NEW speaker SHOULD NOT send
+   the AS4_PATH attribute.
+
+   In the AS_PATH attribute encoded with 2-octet AS numbers, non-
+   mappable 4-octet AS numbers are represented by the well-known 2-octet
+   AS number, AS_TRANS.  This will preserve the path length property of
+   the AS path information and also help in updating the AS path
+   information received on a NEW BGP speaker from an OLD speaker, as
+   explained in the next section.
+
+   The NEW speaker constructs the AS4_PATH attribute from the
+   information carried in the AS_PATH attribute.  In the case where the
+   AS_PATH attribute contains either AS_CONFED_SEQUENCE or AS_CONFED_SET
+   path segments, the NEW speaker, when constructing the AS4_PATH
+   attribute from the AS_PATH attribute, MUST exclude such path
+   segments.  The AS4_PATH attribute will be carried across a series of
+   OLD BGP speakers without modification and will help preserve the
+   truly 4-octet AS numbers in the AS path information.
+
+   Similarly, if the NEW speaker has to send the AGGREGATOR attribute,
+   and if the aggregating Autonomous System's AS number is truly 4-
+   octets, then the speaker constructs the AS4_AGGREGATOR attributes by
+   taking the attribute length and attribute value from the AGGREGATOR
+   attribute and placing them into the attribute length and attribute
+   value of the AS4_AGGREGATOR attribute, and sets the AS number field
+   in the existing AGGREGATOR attribute to the reserved AS number,
+   AS_TRANS.  Note that if the AS number is 2-octets only, then the
+   AS4_AGGREGATOR attribute SHOULD NOT be sent.
+
+4.2.3.  Processing Received Updates
+
+   When a NEW BGP speaker receives an update from an OLD one, it should
+   be prepared to receive the AS4_PATH attribute along with the existing
+   AS_PATH attribute.  If the AS4_PATH attribute is also received, both
+   the attributes will be used to construct the exact AS path
+   information, and therefore the information carried by both the
+   attributes will be considered for AS path loop detection.
+
+   Note that a route may have traversed a series of autonomous systems
+   with 2-octet AS numbers and OLD BGP speakers only.  In that case, if
+   the route carries the AS4_PATH attribute, this attribute must have
+
+
+
+Vohra & Chen                Standards Track                     [Page 4]
+
+RFC 4893       BGP Support for Four-octet AS Number Space       May 2007
+
+
+   remained unmodified since the route left the last NEW BGP speaker.
+   The trailing AS path information (representing autonomous systems
+   with 2-octet AS numbers and OLD BGP speakers only) is contained only
+   in the current AS_PATH attribute (encoded in the leading part of the
+   AS_PATH attribute).
+
+   Under certain conditions, it may not be possible to reconstruct the
+   entire AS path information from the AS_PATH and the AS4_PATH
+   attributes of a route.  This occurs when two or more routes that
+   carry the AS4_PATH attribute are aggregated by an OLD BGP speaker,
+   and the AS4_PATH attribute of at least one of these routes carries at
+   least one 4-octet AS number (as oppose to a 2-octet AS number that is
+   encoded in 4 octets).  Depending on the implementation, either the
+   AS4_PATH attribute would be lost during route aggregation, or both
+   the AS_PATH attribute and the AS4_PATH attribute would contain valid,
+   partial information that cannot be combined seamlessly, resulting in
+   incomplete AS path information in these cases.
+
+   A NEW BGP speaker should also be prepared to receive the
+   AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an
+   OLD BGP speaker.  When both the attributes are received, if the AS
+   number in the AGGREGATOR attribute is not AS_TRANS, then:
+
+      -  the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL
+         be ignored,
+
+      -  the AGGREGATOR attribute SHALL be taken as the information
+         about the aggregating node, and
+
+      -  the AS_PATH attribute SHALL be taken as the AS path
+         information.
+
+   Otherwise,
+
+      -  the AGGREGATOR attribute SHALL be ignored,
+
+      -  the AS4_AGGREGATOR attribute SHALL be taken as the information
+         about the aggregating node, and
+
+      -  the AS path information would need to be constructed, as in all
+         other cases.
+
+   In order to construct the AS path information, it would be necessary
+   to first calculate the number of AS numbers in the AS_PATH and
+   AS4_PATH attributes using the method specified in Section 9.1.2.2
+   [BGP] and [RFC3065] for route selection.
+
+
+
+
+
+Vohra & Chen                Standards Track                     [Page 5]
+
+RFC 4893       BGP Support for Four-octet AS Number Space       May 2007
+
+
+   If the number of AS numbers in the AS_PATH attribute is less than the
+   number of AS numbers in the AS4_PATH attribute, then the AS4_PATH
+   attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken
+   as the AS path information.
+
+   If the number of AS numbers in the AS_PATH attribute is larger than
+   or equal to the number of AS numbers in the AS4_PATH attribute, then
+   the AS path information SHALL be constructed by taking as many AS
+   numbers and path segments as necessary from the leading part of the
+   AS_PATH attribute, and then prepending them to the AS4_PATH attribute
+   so that the AS path information has an identical number of AS numbers
+   as the AS_PATH attribute.  Note that a valid AS_CONFED_SEQUENCE or
+   AS_CONFED_SET path segment SHALL be prepended if it is either the
+   leading path segment or adjacent to a path segment that is prepended.
+
+5.  Handling BGP Communities
+
+   As specified in [RFC1997], when the high-order two-octets of the
+   community attribute is neither 0x0000 nor 0xffff, these two octets
+   encode the Autonomous System number.  Quite clearly this would not
+   work for BGP speakers that use 4-octets Autonomous System numbers.
+   Such BGP speakers should use the Four-octet AS Specific Extended
+   Communities [AS-EXT-COM] instead.
+
+6.  Transition
+
+   The scheme described in this document allows a gradual transition
+   from 2-octet AS numbers to 4-octet AS numbers.  One can upgrade one
+   Autonomous System or one BGP speaker at a time.
+
+   To simplify transition, this document assumes that an Autonomous
+   System could start using a 4-octet AS number only after all the BGP
+   speakers within that Autonomous System have been upgraded to support
+   4-octet AS numbers.
+
+   An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System
+   number.
+
+   A non-mappable 4-octet AS number cannot be used as a "Member AS
+   Number" of a BGP Confederation until all the BGP speakers within the
+   Confederation have transitioned to support 4-octet AS numbers.
+
+   In an environment where an Autonomous System that has OLD BGP
+   speakers peers with two or more Autonomous Systems that have NEW BGP
+   speakers and use AS_TRANS (rather than having a globally unique AS
+   number), use of Multi-Exit Discriminators by the Autonomous System
+
+
+
+
+
+Vohra & Chen                Standards Track                     [Page 6]
+
+RFC 4893       BGP Support for Four-octet AS Number Space       May 2007
+
+
+   with the OLD speakers may result in a situation where Multi-Exit
+   Discriminator will influence route selection among the routes that
+   were received from different neighboring Autonomous Systems.
+
+   Under certain conditions, it may not be possible to reconstruct the
+   entire AS path information from the AS_PATH and the AS4_PATH
+   attributes of a route.  This occurs when two or more routes that
+   carry the AS4_PATH attribute are aggregated by an OLD BGP speaker,
+   and the AS4_PATH attribute of at least one of these routes carries at
+   least one 4-octet AS number (as oppose to a 2-octet AS number that is
+   encoded in 4 octets).  When such aggregation results in creating a
+   route that is less specific than any of the component routes (route
+   whose Network Layer Reachability Information (NLRI) covers NLRI of
+   all the component routes), loss of the AS path information does not
+   create a risk of a routing loop.  In all other cases, loss of the AS
+   path information does create a risk of a routing loop.
+
+7.  IANA Considerations
+
+   This document expands the pool for AS numbers from 0 - 65535 to 0 -
+   4294967295.  The AS numbers are managed by the IANA "Autonomous
+   System Numbers" registry.  Other than expanding the AS number pool,
+   this document does not propose any modifications to the existing
+   policies and procedures pertaining to the AS number allocation.
+
+   This document uses a BGP Capability code to indicate that a BGP
+   speaker supports the 4-octet AS numbers.  The Capability Code 65 has
+   been assigned by IANA per RFC 2842.
+
+   In addition, this document introduces two new BGP optional transitive
+   attributes, and their type codes have been assigned by the IANA.  The
+   first one is the AS4_PATH attribute, value 17, which preserves the AS
+   path information with 4-octet AS numbers across old BGP speakers.
+   The second one is the AS4_AGGREGATOR attribute, value 18, which is
+   similar in use to the current AGGREGATOR attribute, but it carries a
+   4-octet AS number.
+
+   Finally, this document introduces a reserved 2-octet AS number --
+   AS_TRANS.  The AS number 23456 has been assigned by the IANA for
+   AS_TRANS.
+
+
+
+
+
+
+
+
+
+
+
+Vohra & Chen                Standards Track                     [Page 7]
+
+RFC 4893       BGP Support for Four-octet AS Number Space       May 2007
+
+
+8.  Security Considerations
+
+   This extension to BGP does not change the underlying security issues
+   inherent in the existing BGP, except for the following:
+
+   The inconsistency between the AS_PATH attribute and the AS4_PATH
+   attribute can create loss of the AS path information, and potential
+   routing loops in certain cases as discussed in the document.  This
+   could be exploited by an attacker.
+
+9.  Acknowledgments
+
+   The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina,
+   and Jeffrey Haas for the numerous discussions that went into the
+   making of this document.
+
+10.  Normative References
+
+   [BGP]        Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+                Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
+                2006.
+
+   [RFC1997]    Chandra, R., Traina, P., and T. Li, "BGP Communities
+                Attribute", RFC 1997, August 1996.
+
+   [RFC3392]    Chandra, R. and J. Scudder, "Capabilities Advertisement
+                with BGP-4", RFC 3392, November 2002.
+
+   [RFC3065]    Traina, P., McPherson, D., and J. Scudder, "Autonomous
+                System Confederations for BGP", RFC 3065, February 2001.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+11.  Informative References
+
+   [AS-EXT-COM] Rekhter, Y., Ramachandra, S., and D. Tappan, "Four-octet
+                AS Specific BGP Extended Community", Work in Progress,
+                April 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+Vohra & Chen                Standards Track                     [Page 8]
+
+RFC 4893       BGP Support for Four-octet AS Number Space       May 2007
+
+
+Authors' Addresses
+
+   Quaizar Vohra
+   Juniper Networks
+   1194 N.Mathilda Ave
+   Sunnyvale, CA 94089
+
+   EMail: quaizar.vohra@gmail.com
+
+
+   Enke Chen
+   Cisco Systems, Inc.
+   170 W. Tasman Dr.
+   San Jose, CA 95134
+
+   EMail: enkechen@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vohra & Chen                Standards Track                     [Page 9]
+
+RFC 4893       BGP Support for Four-octet AS Number Space       May 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST 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 currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Vohra & Chen                Standards Track                    [Page 10]
+