Network Working Group B. Decraene Internet-Draft France Telecom - Orange Intended status: Standards Track P. Francois Expires: April 20, 2011 UCL October 17, 2010 Reserved BGP extended communities draft-decraene-idr-reserved-extended-communities-00 Abstract This document assigns two BGP extended community types, one transitive and one non-transitive. It also defines two IANA registries in order to allow the allocation of reserved transitive and non-transitive extended communities. These are similar to the existing reserved (formerly Well-known) BGP communities defined in RFC 1997 but provides an easier control of inter-AS community advertissement as a community could be chosen as transitive or non- transitive across ASes. Requirements Language 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]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 20, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Decraene & Francois Expires April 20, 2011 [Page 1] Internet-Draft Reserved extended communities October 2010 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. 1. Introduction RFC1997 [RFC1997] defines the BGP community attribute and some BGP Well known communities whose meaning SHALL be understood by all implementations compliant with RFC1997 [RFC1997]). New reserved communities can be registred in the IANA "BGP Well-known Communities" registry but can't anymore be considered as well known. Implementations which do not reconize those new reserved communities will propagate them from BGP neigbour to BGP neigbour and from AS to AS with an unlimited scope. RFC 4360[RFC4360] defines the BGP extended community attribute with a structure including a type and a transitive bit "T". The transitive bit, when set, allows to restrict the scope of the community within an AS. Without structure, this can only be accomplished by explicitly enumerating all community values that will be denied or allowed and passed to BGP speakers in neighboring ASes. RFC 4360[RFC4360] defines IANA registries to allocate BGP Extended Communities types. Each type is able to encode 2^48 or 2^56 values depending on the type being extended or regular. It does not define an IANA registry to allocate single reserved communities. Therefore, one needing to reserve a single non-transitive extended community would need to reserve an extended subtype which represents 2^48 communities. This would both waste the ressources and disable the ability to define global policies on reserved communities, such as to filter them out. This document assigns two BGP extended community types, one transitive and one non-transitive. It also defines two IANA registries in order to allow the allocation of reserved transitive and non-transitive extended communities. These are similar to the existing reserved ("Well-known") BGP communities defined in RFC 1997 but provides an easier control of inter-AS community advertissement as a community could be chosen as transitive or non-transitive across ASes. Decraene & Francois Expires April 20, 2011 [Page 2] Internet-Draft Reserved extended communities October 2010 2. IANA Considerations IANA is requested to assign, from the registry "BGP Extended Communities Type - extended, transitive type", a type value TBD for "BGP Reserved transitive extended communities": Registry Name: BGP Extended Communities Type - extended, transitive Name Type Value ---- ---------- BGP Reserved transitive extended communities TBD (e.g. 0x9000) IANA is requested to assign, from the registry "BGP Extended Communities Type - extended, non-transitive", a type value TBD for "BGP Reserved non-transitive extended communities": Registry Name: BGP Extended Communities Type - extended, non-transitive Name Type Value ---- ---------- BGP Reserved non-transitive extended communities TBD (e.g. 0xd000) Note to the IANA: suggested value for the two reserved BGP Extended Communities extended type are 0x9000 and 0xd000. Otherwise, both values should be identical, except for their T - Transitive bit (bit 1 as defined in RFC 4360 [RFC4360]). The IANA is requested to create and maintain a registry entitled "BGP Reserved transitive extended communities". Registry Name: BGP Reserved transitive extended communities Range Registration Procedures --------------------------- ------------------------- 0x000000000000-FFFFFFFEFFFF Reserved 0xFFFFFFFF0000-00FFFFFF8000 First Come First Served 0x00FFFFFF8001-FFFFFFFFFFFF Standards Action/Early IANA Allocation The IANA is requested to create and maintain a registry entitled "BGP Reserved non-transitive extended communities". Decraene & Francois Expires April 20, 2011 [Page 3] Internet-Draft Reserved extended communities October 2010 Registry Name: BGP Reserved non-transitive extended communities Range Registration Procedures --------------------------- ------------------------- 0x000000000000-FFFFFFFEFFFF Reserved 0xFFFFFFFF0000-00FFFFFF8000 First Come First Served 0x00FFFFFF8001-FFFFFFFFFFFF Standards Action/Early IANA Allocation An application may need both a transitive and non-transitive reserved community. It may be beneficial to have the same value for both communities. (Note that both extended community will still be different as they will differ from their T bit). IThe IANA SHOULD try to accomodate such request to have both a transitive and non- transitive reserved community with the same value for both. 3. Security Considerations This document defines IANA actions. In itself, it has no impact on the security of the BGP protocol. 4. Normative References [RFC1997] Chandrasekeran, 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. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Decraene & Francois Expires April 20, 2011 [Page 4] Internet-Draft Reserved extended communities October 2010 Authors' Addresses Bruno Decraene France Telecom - Orange 38-40 rue du General Leclerc Issy Moulineaux cedex 9 92794 France Email: bruno.decraene@orange-ftgroup.com Pierre Francois UCL Place Ste Barbe, 2 Louvain-la-Neuve 1348 BE Email: francois@info.ucl.ac.be Decraene & Francois Expires April 20, 2011 [Page 5]