doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc4360.txt b/doc/rfc/rfc4360.txt
new file mode 100644
index 0000000..c439c0f
--- /dev/null
+++ b/doc/rfc/rfc4360.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                          S. Sangli
+Request for Comments: 4360                                     D. Tappan
+Category: Standards Track                                  Cisco Systems
+                                                              Y. Rekhter
+                                                        Juniper Networks
+                                                           February 2006
+
+
+                   BGP Extended Communities Attribute
+
+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 Internet Society (2006).
+
+Abstract
+
+   This document describes the "extended community" BGP-4 attribute.
+   This attribute provides a mechanism for labeling information carried
+   in BGP-4.  These labels can be used to control the distribution of
+   this information, or for other applications.
+
+1.  Introduction
+
+   The Extended Community Attribute provides a mechanism for labeling
+   information carried in BGP-4 [BGP-4].  It provides two important
+   enhancements over the existing BGP Community Attribute [RFC1997]:
+
+      - An extended range, ensuring that communities can be assigned for
+        a plethora of uses, without fear of overlap.
+
+      - The addition of a Type field provides structure for the
+        community space.
+
+   The addition of structure allows the usage of policy based on the
+   application for which the community value will be used.  For example,
+   one can filter out all communities of a particular type, or allow
+   only certain values for a particular type of community.  It also
+   allows one to specify whether a particular community is transitive or
+   non-transitive across an Autonomous System (AS) boundary.  Without
+   structure, this can only be accomplished by explicitly enumerating
+
+
+
+Sangli, et al.              Standards Track                     [Page 1]
+
+RFC 4360           BGP Extended Communities Attribute      February 2006
+
+
+   all community values that will be denied or allowed and passed to BGP
+   speakers in neighboring ASes based on the transitive property.
+
+1.1.  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 RFC 2119 [RFC2119].
+
+2.  BGP Extended Communities Attribute
+
+   The Extended Communities Attribute is a transitive optional BGP
+   attribute, with the Type Code 16.  The attribute consists of a set of
+   "extended communities".  All routes with the Extended Communities
+   attribute belong to the communities listed in the attribute.
+
+   Each Extended Community is encoded as an 8-octet quantity, as
+   follows:
+
+      - Type Field  : 1 or 2 octets
+      - Value Field : Remaining octets
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Type high    |  Type low(*)  |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Value                |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      (*) Present for Extended types only, used for the Value field
+          otherwise.
+
+      Type Field:
+
+         Two classes of Type Field are introduced: Regular type and
+         Extended type.
+
+         The size of Type Field for Regular types is 1 octet, and the
+         size of the Type Field for Extended types is 2 octets.
+
+         The value of the high-order octet of the Type Field determines
+         if an extended community is a Regular type or an Extended type.
+         The class of a type (Regular or Extended) is not encoded in the
+         structure of the type itself.  The class of a type is specified
+         in the document that defines the type and the IANA registry.
+
+
+
+
+
+Sangli, et al.              Standards Track                     [Page 2]
+
+RFC 4360           BGP Extended Communities Attribute      February 2006
+
+
+         The high-order octet of the Type Field is as shown below:
+
+             0 1 2 3 4 5 6 7
+            +-+-+-+-+-+-+-+-+
+            |I|T|           |
+            +-+-+-+-+-+-+-+-+
+
+            I - IANA authority bit
+
+               Value 0: IANA-assignable type using the "First Come First
+               Serve" policy
+
+               Value 1: Part of this Type Field space is for IANA
+               assignable types using either the Standard Action or the
+               Early IANA Allocation policy.  The rest of this Type
+               Field space is for Experimental use.
+
+            T - Transitive bit
+
+               Value 0: The community is transitive across ASes
+
+               Value 1: The community is non-transitive across ASes
+
+            Remaining 6 bits: Indicates the structure of the community
+
+      Value Field:
+
+         The encoding of the Value Field is dependent on the "type" of
+         the community as specified by the Type Field.
+
+   Two extended communities are declared equal only when all 8 octets of
+   the community are equal.
+
+   The two members in the tuple <Type, Value> should be enumerated to
+   specify any community value.  The remaining octets of the community
+   interpreted based on the value of the Type field.
+
+3.  Defined BGP Extended Community Types
+
+   This section introduces a few extended types and defines the format
+   of the Value Field for those types.  The types introduced here
+   provide "templates", where each template is identified by the high-
+   order octet of the extended community Type field, and the lower-order
+   octet (sub-type) is used to indicate a particular type of extended
+   community.
+
+
+
+
+
+
+Sangli, et al.              Standards Track                     [Page 3]
+
+RFC 4360           BGP Extended Communities Attribute      February 2006
+
+
+3.1.  Two-Octet AS Specific Extended Community
+
+   This is an extended type with Type Field composed of 2 octets and
+   Value Field composed of 6 octets.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | 0x00 or 0x40  |   Sub-Type    |    Global Administrator       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Local Administrator                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The value of the high-order octet of this extended type is either
+   0x00 or 0x40.  The low-order octet of this extended type is used to
+   indicate sub-types.
+
+   The Value Field consists of two sub-fields:
+
+      Global Administrator sub-field: 2 octets
+
+         This sub-field contains an Autonomous System number assigned by
+         IANA.
+
+      Local Administrator sub-field: 4 octets
+
+         The organization identified by Autonomous System number in the
+         Global Administrator sub-field can encode any information in
+         this sub-field.  The format and meaning of the value encoded in
+         this sub-field should be defined by the sub-type of the
+         community.
+
+3.2.  IPv4 Address Specific Extended Community
+
+   This is an extended type with Type Field composed of 2 octets and
+   Value Field composed of 6 octets.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | 0x01 or 0x41  |   Sub-Type    |    Global Administrator       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Global Administrator (cont.)  |    Local Administrator        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The value of the high-order octet of this extended type is either
+   0x01 or 0x41.  The low-order octet of this extended type is used to
+   indicate sub-types.
+
+
+
+Sangli, et al.              Standards Track                     [Page 4]
+
+RFC 4360           BGP Extended Communities Attribute      February 2006
+
+
+   The Value field consists of two sub-fields:
+
+      Global Administrator sub-field: 4 octets
+
+         This sub-field contains an IPv4 unicast address assigned by one
+         of the Internet registries.
+
+      Local Administrator sub-field: 2 octets
+
+         The organization that has been assigned the IPv4 address in the
+         Global Administrator sub-field can encode any information in
+         this sub-field.  The format and meaning of this value encoded
+         in this sub-field should be defined by the sub-type of the
+         community.
+
+3.3.  Opaque Extended Community
+
+   This is an extended type with Type Field composed of 2 octets and
+   Value Field composed of 6 octets.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | 0x03 or 0x43  |   Sub-Type    |                Value          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Value (cont.)                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The value of the high-order octet of this extended type is either
+   0x03 or 0x43.  The low-order octet of this extended type is used to
+   indicate sub-types.
+
+   This is a generic community of extended type.  The value of the sub-
+   type that should define the Value Field is to be assigned by IANA.
+
+4.  Route Target Community
+
+   The Route Target Community identifies one or more routers that may
+   receive a set of routes (that carry this Community) carried by BGP.
+   This is transitive across the Autonomous System boundary.
+
+   The Route Target Community is of an extended type.
+
+   The value of the high-order octet of the Type field for the Route
+   Target Community can be 0x00, 0x01, or 0x02.  The value of the low-
+   order octet of the Type field for this community is 0x02.
+
+
+
+
+
+Sangli, et al.              Standards Track                     [Page 5]
+
+RFC 4360           BGP Extended Communities Attribute      February 2006
+
+
+   When the value of the high-order octet of the Type field is 0x00 or
+   0x02, the Local Administrator sub-field contains a number from a
+   numbering space that is administered by the organization to which the
+   Autonomous System number carried in the Global Administrator sub-
+   field has been assigned by an appropriate authority.
+
+   When the value of the high-order octet of the Type field is 0x01, the
+   Local Administrator sub-field contains a number from a numbering
+   space that is administered by the organization to which the IP
+   address carried in the Global Administrator sub-field has been
+   assigned by an appropriate authority.
+
+   One possible use of the Route Target Community is specified in
+   [RFC4364].
+
+5.  Route Origin Community
+
+   The Route Origin Community identifies one or more routers that inject
+   a set of routes (that carry this Community) into BGP.  This is
+   transitive across the Autonomous System boundary.
+
+   The Route Origin Community is of an extended type.
+
+   The value of the high-order octet of the Type field for the Route
+   Origin Community can be 0x00, 0x01, or 0x02.  The value of the low-
+   order octet of the Type field for this community is 0x03.
+
+   When the value of the high-order octet of the Type field is 0x00 or
+   0x02, the Local Administrator sub-field contains a number from a
+   numbering space that is administered by the organization to which the
+   Autonomous System number carried in the Global Administrator sub-
+   field has been assigned by an appropriate authority.
+
+   When the value of the high-order octet of the Type field is 0x01, the
+   Local Administrator sub-field contains a number from a numbering
+   space that is administered by the organization to which the IP
+   address carried in the Global Administrator sub-field has been
+   assigned by an appropriate authority.
+
+   One possible use of the Route Origin Community is specified in
+   [RFC4364].
+
+
+
+
+
+
+
+
+
+
+Sangli, et al.              Standards Track                     [Page 6]
+
+RFC 4360           BGP Extended Communities Attribute      February 2006
+
+
+6.  Operations
+
+   A BGP speaker may use the Extended Communities attribute to control
+   which routing information it accepts or distributes to its peers.
+
+   The Extended Community attribute MUST NOT be used to modify the BGP
+   best path selection algorithm in a way that leads to forwarding
+   loops.
+
+   A BGP speaker receiving a route that doesn't have the Extended
+   Communities attribute MAY append this attribute to the route when
+   propagating it to its peers.
+
+   A BGP speaker receiving a route with the Extended Communities
+   attribute MAY modify this attribute according to the local policy.
+
+   By default if a range of routes is to be aggregated and the resultant
+   aggregates path attributes do not carry the ATOMIC_AGGREGATE
+   attribute, then the resulting aggregate should have an Extended
+   Communities path attribute that contains the set union of all the
+   Extended Communities from all of the aggregated routes.  The default
+   behavior could be overridden via local configuration, in which case
+   handling the Extended Communities attribute in the presence of route
+   aggregation becomes a matter of the local policy of the BGP speaker
+   that performs the aggregation.
+
+   If a route has a non-transitivity extended community, then before
+   advertising the route across the Autonomous System boundary the
+   community SHOULD be removed from the route.  However, the community
+   SHOULD NOT be removed when advertising the route across the BGP
+   Confederation boundary.
+
+   A route may carry both the BGP Communities attribute, as defined in
+   [RFC1997]), and the Extended BGP Communities attribute.  In this
+   case, the BGP Communities attribute is handled as specified in
+   [RFC1997], and the Extended BGP Communities attribute is handled as
+   specified in this document.
+
+7.  IANA Considerations
+
+   All the BGP Extended Communities contain a Type field.  The IANA has
+   created a registry entitled, "BGP Extended Communities Type".  The
+   IANA will maintain this registry.
+
+   The Type could be either regular or extended.  For a regular Type the
+   IANA allocates an 8-bit value; for an extended Type the IANA
+   allocates a 16-bit value.
+
+
+
+
+Sangli, et al.              Standards Track                     [Page 7]
+
+RFC 4360           BGP Extended Communities Attribute      February 2006
+
+
+   The value allocated for a regular Type MUST NOT be reused as the
+   value of the high-order octet when allocating an extended Type.  The
+   value of the high-order octet allocated for an extended Type MUST NOT
+   be reused when allocating a regular Type.
+
+   The Type field indicates where the Extended Community is transitive
+   or not.  Future requests for assignment of a Type value must specify
+   whether the Type value is intended for a transitive or a non-
+   transitive Extended Community.
+
+   Future assignment are to be made using either the Standards Action
+   process defined in [RFC2434], the Early IANA Allocation process
+   defined in [RFC4020], or the "First Come First Served" policy defined
+   in [RFC2434].
+
+   The following table summarizes the ranges for the assignment of
+   Types:
+
+      Type                        Standard Action         First Come
+                                  Early IANA Allocation   First Served
+      ------------------          ---------------------   ------------
+
+      regular, transitive          0x90-0xbf              0x00-x3f
+
+      regular, non-transitive      0xd0-0xff              0x40-0x7f
+
+      extended, transitive         0x9000-0xbfff          0x0000-0x3fff
+
+      extended, non-transitive     0xd000-0xffff          0x4000-0x7fff
+
+   Assignments consist of a name and the value.
+
+   The Type values 0x80-0x8f and 0xc0-0xcf for regular Types, and
+   0x8000-0x8fff and 0xc000-0xcfff for extended Types are for
+   Experimental use as defined in RFC 3692.
+
+   This document defines a class of extended communities called two-
+   octet AS specific extended community for which the IANA is to create
+   and maintain a registry entitled "Two-octet AS Specific Extended
+   Community".  All the communities in this class are of extended Types.
+   Future assignment are to be made using the "First Come First Served"
+   policy defined in [RFC2434].  The Type values for the transitive
+   communities of the two-octet AS specific extended community class are
+   0x0000-0x00ff, and for the non-transitive communities of that class
+   are 0x4000-0x40ff.  Assignments consist of a name and the value.
+
+   This document makes the following assignments for the two-octet AS
+   specific extended community:
+
+
+
+Sangli, et al.              Standards Track                     [Page 8]
+
+RFC 4360           BGP Extended Communities Attribute      February 2006
+
+
+      Name                                     Type Value
+      ----                                     ----------
+      two-octet AS specific Route Target       0x0002
+      two-octet AS specific Route Origin       0x0003
+
+   This document defines a class of extended communities called IPv4
+   address specific extended community for which the IANA is to create
+   and maintain a registry entitled "IPv4 Address Specific Extended
+   Community".  All the communities in this class are of extended Types.
+   Future assignment are to be made using the "First Come First Served"
+   policy defined in [RFC2434].  The Type values for the transitive
+   communities of the two-octet AS specific extended community class
+   are 0x0100-0x01ff, and for the non-transitive communities of that
+   class are 0x4100-0x41ff.  Assignments consist of a name and the
+   value.
+
+   This document makes the following assignments for the IPv4 address
+   specific extended community:
+
+      Name                                     Type Value
+      ----                                     ----------
+      IPv4 address specific Route Target       0x0102
+      IPv4 address specific Route Origin       0x0103
+
+   This document defines a class of extended communities called opaque
+   extended community for which the IANA is to create and maintain a
+   registry entitled "Opaque Extended Community".  All the communities
+   in this class are of extended Types.  Future assignment are to be
+   made using the "First Come First Served" policy defined in [RFC2434].
+   The Type values for the transitive communities of the opaque extended
+   community class are 0x0300-0x03ff, and for the non-transitive
+   communities of that class are 0x4300-0x43ff.  Assignments consist of
+   a name and the value.
+
+   When requesting an allocation from more than one registry defined
+   above, one may ask for allocating the same Type value from these
+   registries.  If possible, the IANA should accommodate such requests.
+
+8.  Security Considerations
+
+   This extension to BGP has similar security implications as BGP
+   Communities [RFC1997].
+
+   This extension to BGP does not change the underlying security issues.
+   Specifically, an operator who is relying on the information carried
+   in BGP must have a transitive trust relationship back to the source
+   of the information.  Specifying the mechanism(s) to provide such a
+   relationship is beyond the scope of this document.
+
+
+
+Sangli, et al.              Standards Track                     [Page 9]
+
+RFC 4360           BGP Extended Communities Attribute      February 2006
+
+
+9.  Acknowledgements
+
+   The authors would like to thank John Hawkinson, Jeffrey Haas, Bruno
+   Rijsman, Bill Fenner, and Alex Zinin for their suggestions and
+   feedback.
+
+10.  Normative References
+
+   [BGP-4]        Rekhter, Y. and T. Li, "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.
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2434]      Narten, T. and H. Alvestrand, "Guidelines for Writing
+                  an IANA Considerations Section in RFCs", BCP 26, RFC
+                  2434, October 1998.
+
+   [RFC4020]      Kompella, K. and A. Zinin, "Early IANA Allocation of
+                  Standards Track Code Points", BCP 100, RFC 4020,
+                  February 2005.
+
+11.  Informative References
+
+   [RFC4364]      Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+                  Networks (VPNs)", RFC 4364, February 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangli, et al.              Standards Track                    [Page 10]
+
+RFC 4360           BGP Extended Communities Attribute      February 2006
+
+
+Authors' Addresses
+
+   Srihari R. Sangli
+   Cisco Systems, Inc.
+
+   EMail: rsrihari@cisco.com
+
+
+   Dan Tappan
+   Cisco Systems, Inc.
+   250 Apollo Drive
+   Chelmsford, MA 01824
+
+   EMail: tappan@cisco.com
+
+
+   Yakov Rekhter
+   Juniper Networks, Inc.
+   1194 N. Mathilda Ave
+   Sunnyvale, CA 94089
+
+   EMail: yakov@juniper.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangli, et al.              Standards Track                    [Page 11]
+
+RFC 4360           BGP Extended Communities Attribute      February 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).
+
+
+
+
+
+
+
+Sangli, et al.              Standards Track                    [Page 12]
+