doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc6793.txt b/doc/rfc/rfc6793.txt
new file mode 100644
index 0000000..f446115
--- /dev/null
+++ b/doc/rfc/rfc6793.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          Q. Vohra
+Request for Comments: 6793                              Juniper Networks
+Obsoletes: 4893                                                  E. Chen
+Updates: 4271                                              Cisco Systems
+Category: Standards Track                                  December 2012
+ISSN: 2070-1721
+
+
+     BGP Support for Four-Octet Autonomous System (AS) Number Space
+
+Abstract
+
+   The Autonomous System number is encoded as a two-octet entity in the
+   base BGP specification.  This document describes extensions to BGP to
+   carry the Autonomous System numbers as four-octet entities.  This
+   document obsoletes RFC 4893 and updates RFC 4271.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6793.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+Vohra & Chen                 Standards Track                    [Page 1]
+
+RFC 6793         BGP Support for 4-Octet AS Number Space   December 2012
+
+
+1.  Introduction
+
+   In the base BGP specification [RFC4271], the Autonomous System (AS)
+   number is encoded as a two-octet entity.  To prepare for the
+   anticipated exhaustion of the two-octet AS numbers, this document
+   describes extensions to BGP to carry the AS numbers as four-octet
+   entities.
+
+   More specifically, this document defines a BGP capability code,
+   "support for four-octet AS number capability", to be used by a BGP
+   speaker to indicate its support for four-octet AS numbers.  Two
+   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 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 specified in this document allow a gradual transition
+   from two-octet AS numbers to four-octet AS numbers.
+
+   This document obsoletes RFC 4893 and updates RFC 4271.  It includes
+   several clarifications and editorial changes, and it specifies the
+   error handling for the new attributes.
+
+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 four-octet AS number extensions as an OLD BGP
+   speaker, and a BGP speaker that supports the new four-octet AS number
+   extensions as a NEW BGP speaker.
+
+   BGP carries the AS numbers 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
+   AS numbers in the BGP Communities attribute.
+
+   A NEW BGP speaker uses BGP Capabilities Advertisements [RFC5492] to
+   advertise to its neighbors (either internal or external) that it
+   supports four-octet AS number extensions, as specified in this
+   document.
+
+
+
+
+
+Vohra & Chen                 Standards Track                    [Page 2]
+
+RFC 6793         BGP Support for 4-Octet AS Number Space   December 2012
+
+
+   The capability that is used by a BGP speaker to convey to its BGP
+   peer the four-octet Autonomous System number capability also carries
+   the AS number (encoded as a four-octet entity) of the speaker in the
+   Capability Value field of the capability.  The Capability Length
+   field of the capability is set to 4.
+
+   The AS path information exchanged between NEW BGP speakers is carried
+   in the existing AS_PATH attribute, except that each AS number in the
+   attribute is encoded as a four-octet entity (instead of a two-octet
+   entity).  The same applies to the AGGREGATOR attribute -- the same
+   attribute is used between NEW BGP speakers, except that the AS number
+   carried in the attribute is encoded as a four-octet entity.
+
+   The AS_PATH attribute and the AGGREGATOR attribute carried between a
+   NEW BGP speaker and an OLD BGP speaker will continue to contain
+   two-octet AS numbers.
+
+   To preserve the AS path information with four-octet AS numbers across
+   OLD BGP speakers, this document defines a new BGP path attribute
+   called AS4_PATH.  This is an optional transitive attribute that
+   contains the AS path encoded with four-octet AS numbers.  The
+   AS4_PATH attribute has the same semantics and the same encoding as
+   the AS_PATH attribute, except that it is "optional transitive", and
+   it carries four-octet AS numbers.
+
+   To prevent the possible propagation of Confederation-related path
+   segments outside of a Confederation, the path segment types
+   AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC5065] are declared invalid
+   for the AS4_PATH attribute and MUST NOT be included in the AS4_PATH
+   attribute of an UPDATE message.
+
+   Similarly, this document defines a new BGP path attribute called
+   AS4_AGGREGATOR, which is optional transitive.  The AS4_AGGREGATOR
+   attribute has the same semantics and the same encoding as the
+   AGGREGATOR attribute, except that it carries a four-octet AS number.
+
+   Currently assigned two-octet AS numbers are converted into four-octet
+   AS numbers by setting the two high-order octets of the four-octet
+   field to zero.  Such a four-octet AS number is said to be mappable to
+   a two-octet AS number.
+
+   This document reserves a two-octet AS number called "AS_TRANS".
+   AS_TRANS can be used to represent non-mappable four-octet AS numbers
+   as two-octet AS numbers in AS path information that is encoded with
+   two-octet AS numbers.  (In this context, four-octet AS numbers that
+   are not mapped from two-octet AS numbers are referred to as
+   "non-mappable".) We denote this special AS number as AS_TRANS for
+   ease of description in the rest of this specification.  This AS
+
+
+
+Vohra & Chen                 Standards Track                    [Page 3]
+
+RFC 6793         BGP Support for 4-Octet AS Number Space   December 2012
+
+
+   number is also placed in the "My Autonomous System" field of the OPEN
+   message originated by a NEW BGP speaker, if and only if the speaker
+   does not have a (globally unique) two-octet AS number.
+
+4.  Operations
+
+4.1.  Interaction between NEW BGP Speakers
+
+   A BGP speaker that supports four-octet AS numbers SHALL advertise
+   this to its peers using BGP Capabilities Advertisements.  The AS
+   number of the BGP speaker MUST be carried in the Capability Value
+   field of the "support for four-octet AS number capability".
+
+   When a NEW BGP speaker processes an OPEN message from another NEW BGP
+   speaker, it MUST use the AS number encoded in the Capability Value
+   field of the "support for four-octet AS number capability" in lieu of
+   the "My Autonomous System" field of the OPEN message.
+
+   A BGP speaker that advertises such a capability to a particular peer,
+   and receives from that peer the advertisement of such a capability,
+   MUST encode AS numbers as four-octet entities in both the AS_PATH
+   attribute and the AGGREGATOR attribute in the updates it sends to the
+   peer and MUST assume that these attributes in the updates received
+   from the peer encode AS numbers as four-octet entities.
+
+   The new attributes, AS4_PATH and AS4_AGGREGATOR, MUST NOT be carried
+   in an UPDATE message between NEW BGP speakers.  A NEW BGP speaker
+   that receives the AS4_PATH attribute or the AS4_AGGREGATOR attribute
+   in an UPDATE message from another NEW BGP speaker MUST discard the
+   path attribute 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 BGP speaker is
+   possible only if the NEW BGP speaker has a two-octet AS number.
+   However, this document does not assume that an Autonomous System with
+   NEW BGP speakers has to have a globally unique two-octet AS number --
+   AS_TRANS MUST be used when the NEW BGP speaker does not have a
+   two-octet AS number (even if multiple Autonomous Systems would
+   use it).
+
+
+
+
+
+
+
+
+
+Vohra & Chen                 Standards Track                    [Page 4]
+
+RFC 6793         BGP Support for 4-Octet AS Number Space   December 2012
+
+
+4.2.2.  Generating Updates
+
+   When communicating with an OLD BGP speaker, a NEW BGP speaker MUST
+   send the AS path information in the AS_PATH attribute encoded with
+   two-octet AS numbers.  The NEW BGP speaker MUST also send the AS path
+   information in the AS4_PATH attribute (encoded with four-octet AS
+   numbers), except for the case where all of the AS path information is
+   composed of mappable four-octet AS numbers only.  In this case, the
+   NEW BGP speaker MUST NOT send the AS4_PATH attribute.
+
+   In the AS_PATH attribute encoded with two-octet AS numbers,
+   non-mappable four-octet AS numbers are represented by the well-known
+   two-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 BGP
+   speaker, as explained in the next section.
+
+   The NEW BGP speaker constructs the AS4_PATH attribute from the AS
+   path information.  Whenever the AS path information contains the
+   AS_CONFED_SEQUENCE or AS_CONFED_SET path segment, the NEW BGP speaker
+   MUST exclude such path segments from the AS4_PATH attribute being
+   constructed.
+
+   The AS4_PATH attribute, being optional transitive, will be carried
+   across a series of OLD BGP speakers without modification and will
+   help preserve the non-mappable four-octet AS numbers in the AS path
+   information.
+
+   Similarly, if the NEW BGP speaker has to send the AGGREGATOR
+   attribute, and if the aggregating Autonomous System's AS number is a
+   non-mappable four-octet AS number, then the speaker MUST use the
+   AS4_AGGREGATOR attribute and set the AS number field in the existing
+   AGGREGATOR attribute to the reserved AS number, AS_TRANS.  Note that
+   if the AS number is mappable, then the AS4_AGGREGATOR attribute MUST
+   NOT be sent.
+
+4.2.3.  Processing Received Updates
+
+   When a NEW BGP speaker receives an update from an OLD BGP speaker, it
+   MUST be prepared to receive the AS4_PATH attribute along with the
+   existing AS_PATH attribute.  If the AS4_PATH attribute is also
+   received, both of the attributes will be used to construct the exact
+   AS path information, and therefore the information carried by both of
+   the attributes will be considered for AS path loop detection.
+
+
+
+
+
+
+
+Vohra & Chen                 Standards Track                    [Page 5]
+
+RFC 6793         BGP Support for 4-Octet AS Number Space   December 2012
+
+
+   Note that a route may have traversed a series of Autonomous Systems
+   with two-octet AS numbers and OLD BGP speakers only.  In that case,
+   if the route carries the AS4_PATH attribute, this attribute would
+   have remained unmodified since the route left the last NEW BGP
+   speaker.  The trailing AS path information (representing Autonomous
+   Systems with two-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 all
+   of the AS path information from the AS_PATH and the AS4_PATH
+   attributes of a route.  This occurs, for example, 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 four-octet AS number (as opposed to a two-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 MUST also be prepared to receive the AS4_AGGREGATOR
+   attribute along with the AGGREGATOR attribute from an OLD BGP
+   speaker.  When both of 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.
+
+
+
+
+
+
+Vohra & Chen                 Standards Track                    [Page 6]
+
+RFC 6793         BGP Support for 4-Octet AS Number Space   December 2012
+
+
+   In order to construct the AS path information, it is 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 of [RFC4271]
+   and in [RFC5065] for route selection.
+
+   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 a number of AS numbers identical
+   to that of 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 is 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 AS number.  Quite clearly, this would not work for a NEW
+   BGP speaker with a non-mappable four-octet AS number.  Such BGP
+   speakers should use four-octet AS specific extended communities
+   [RFC5668] instead.
+
+6.  Error Handling
+
+   This section provides an update to RFC 4271 [RFC4271] with respect to
+   the error conditions noted here and their handling.
+
+   Given that the two-octet AS numbers dominate during the transition
+   and are carried in the AS_PATH attribute by an OLD BGP speaker, in
+   this document the "attribute discard" approach is chosen to handle a
+   malformed AS4_PATH attribute.
+
+   Similarly, as the AS4_AGGREGATOR is just informational, the
+   "attribute discard" approach is chosen to handle a malformed
+   AS4_AGGREGATOR attribute.
+
+
+
+
+
+
+
+
+Vohra & Chen                 Standards Track                    [Page 7]
+
+RFC 6793         BGP Support for 4-Octet AS Number Space   December 2012
+
+
+   The AS4_PATH attribute and AS4_AGGREGATOR attribute MUST NOT be
+   carried in an UPDATE message between NEW BGP speakers.  A NEW BGP
+   speaker that receives the AS4_PATH attribute or the AS4_AGGREGATOR
+   attribute in an UPDATE message from another NEW BGP speaker MUST
+   discard the path attribute and continue processing the UPDATE
+   message.  This case SHOULD be logged locally for analysis.
+
+   In addition, the path segment types AS_CONFED_SEQUENCE and
+   AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute
+   of an UPDATE message.  A NEW BGP speaker that receives these path
+   segment types in the AS4_PATH attribute of an UPDATE message from an
+   OLD BGP speaker MUST discard these path segments, adjust the relevant
+   attribute fields accordingly, and continue processing the UPDATE
+   message.  This case SHOULD be logged locally for analysis.
+
+   The AS4_PATH attribute in an UPDATE message SHALL be considered
+   malformed under the following conditions:
+
+      -  the attribute length is not a multiple of two or is too small
+         (i.e., less than 6) for the attribute to carry at least one AS
+         number, or
+
+      -  the path segment length in the attribute is either zero or is
+         inconsistent with the attribute length, or
+
+      -  the path segment type in the attribute is not one of the types
+         defined: AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE, and
+         AS_CONFED_SET.
+
+   A NEW BGP speaker that receives a malformed AS4_PATH attribute in an
+   UPDATE message from an OLD BGP speaker MUST discard the attribute and
+   continue processing the UPDATE message.  The error SHOULD be logged
+   locally for analysis.
+
+   The AS4_AGGREGATOR attribute in an UPDATE message SHALL be considered
+   malformed if the attribute length is not 8.
+
+   A NEW BGP speaker that receives a malformed AS4_AGGREGATOR attribute
+   in an UPDATE message from an OLD BGP speaker MUST discard the
+   attribute and continue processing the UPDATE message.  The error
+   SHOULD be logged locally for analysis.
+
+
+
+
+
+
+
+
+
+
+Vohra & Chen                 Standards Track                    [Page 8]
+
+RFC 6793         BGP Support for 4-Octet AS Number Space   December 2012
+
+
+7.  Transition
+
+   When an Autonomous System is using a two-octet AS number, then the
+   BGP speakers within that Autonomous System MAY be upgraded to support
+   the four-octet AS number extensions on a piecemeal basis.  There is
+   no requirement for a coordinated upgrade of the four-octet AS number
+   capability in this case.  However, if an Autonomous System wishes to
+   use a four-octet AS number as its own AS number, then this document
+   assumes that an Autonomous System can use a four-octet AS number only
+   after all the BGP speakers within that Autonomous System have been
+   upgraded to support four-octet AS numbers.
+
+   A non-mappable four-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 four-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
+   mappable AS number), the use of the MULTI_EXIT_DISC attribute
+   [RFC4271] by the Autonomous System with the OLD BGP speakers may
+   result in a situation where the MULTI_EXIT_DISC attribute 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 all
+   of the 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 four-octet AS number (as opposed to a two-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 (routes whose Network Layer Reachability Information (NLRI)
+   covers the NLRI of all the component routes), loss of the AS path
+   information does not create the risk of a routing loop.  In all other
+   cases, loss of the AS path information does create the risk of a
+   routing loop.
+
+8.  Manageability Considerations
+
+   If the BGP4-MIB [RFC4273] is supported, there are no additional
+   manageability concerns that arise from the use of four-octet AS
+   numbers, since the InetAutonomousSystemNumber textual convention
+   [RFC4001] is defined as Unsigned32.
+
+
+
+
+
+
+Vohra & Chen                 Standards Track                    [Page 9]
+
+RFC 6793         BGP Support for 4-Octet AS Number Space   December 2012
+
+
+   When IP Flow Information Export (IPFIX) [RFC5101] is supported, there
+   are no additional manageability concerns that arise from the use of
+   four-octet AS numbers.  The bgpSourceAsNumber and
+   bgpDestinationAsNumber information elements [IANA-IPFIX] can continue
+   to be used, with a new template record, specifying the new length of
+   4 bytes.
+
+9.  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 allocation of AS numbers.
+
+   This document uses a BGP capability code to indicate that a BGP
+   speaker supports four-octet AS numbers.  Capability Code 65 has been
+   assigned by IANA per [RFC5492].
+
+   In addition, this document introduces two BGP optional transitive
+   attributes, and their type codes have been assigned by IANA.  The
+   first one is the AS4_PATH attribute, value 17, which preserves the AS
+   path information with four-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
+   four-octet AS number.
+
+   Finally, IANA has replaced a reference to RFC 4893 with a reference
+   to this document for a reserved two-octet AS number -- AS_TRANS
+   (23456).  Also, IANA has replaced a reference to RFC 4893 with a
+   reference to this document for the "32-bit Autonomous System Numbers"
+   registry.
+
+10.  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 this document.  This
+   could be exploited by an attacker.
+
+   It is a misconfiguration to assign a non-mappable four-octet AS
+   number as the "Member AS Number" in a BGP Confederation before all
+   the BGP speakers within the Confederation have transitioned to
+   support four-octet AS numbers.  Such a misconfiguration would weaken
+   AS path loop detection within a Confederation.
+
+
+
+Vohra & Chen                 Standards Track                   [Page 10]
+
+RFC 6793         BGP Support for 4-Octet AS Number Space   December 2012
+
+
+11.  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.
+
+   The authors would also like to thank members of the IDR Working Group
+   for their review and comments.
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC1997]    Chandra, R., Traina, P., and T. Li, "BGP Communities
+                Attribute", RFC 1997, August 1996.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4271]    Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+                Border Gateway Protocol 4 (BGP-4)", RFC 4271,
+                January 2006.
+
+   [RFC5065]    Traina, P., McPherson, D., and J. Scudder, "Autonomous
+                System Confederations for BGP", RFC 5065, August 2007.
+
+   [RFC5492]    Scudder, J. and R. Chandra, "Capabilities Advertisement
+                with BGP-4", RFC 5492, February 2009.
+
+   [RFC5668]    Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS
+                Specific BGP Extended Community", RFC 5668,
+                October 2009.
+
+12.2.  Informative References
+
+   [IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities",
+                <http://www.iana.org/assignments/ipfix>.
+
+   [RFC4001]    Daniele, M., Haberman, B., Routhier, S., and J.
+                Schoenwaelder, "Textual Conventions for Internet Network
+                Addresses", RFC 4001, February 2005.
+
+   [RFC4273]    Haas, J., Ed., and S. Hares, Ed., "Definitions of
+                Managed Objects for BGP-4", RFC 4273, January 2006.
+
+   [RFC5101]    Claise, B., Ed., "Specification of the IP Flow
+                Information Export (IPFIX) Protocol for the Exchange of
+                IP Traffic Flow Information", RFC 5101, January 2008.
+
+
+
+Vohra & Chen                 Standards Track                   [Page 11]
+
+RFC 6793         BGP Support for 4-Octet AS Number Space   December 2012
+
+
+Authors' Addresses
+
+   Quaizar Vohra
+   Juniper Networks
+   1194 N. Mathilda Ave.
+   Sunnyvale, CA  94089
+   USA
+
+   EMail: quaizar.vohra@gmail.com
+
+
+   Enke Chen
+   Cisco Systems, Inc.
+   170 W. Tasman Dr.
+   San Jose, CA  95134
+   USA
+
+   EMail: enkechen@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vohra & Chen                 Standards Track                   [Page 12]
+