Network Working Group D. Meyer Internet-Draft M. Teplov Request for Comments: 4384-bis June 2008 Intended status: Recommendation Expires: December 18, 2008 BGP Communities use for the prefix origination tagging draft-teplov-grow-rfc4384-bis-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." Prior it use of this draft IANA will need to assign specific value(s) as it is defined in Chapter 7 of this document. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 16, 2008. Copyright Notice 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. 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 D. Meyer, M. Teplov Expires 18 December, 2008 [Page 1] Internet-Draft BGP Communities for data origination June 2008 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. Copyright (C) The IETF Trust (2008). Table of Contents 1. Abstract..............................................2 2. Introduction..........................................3 3. Definitions...........................................3 3.1. Peers and Peering...................................3 3.2 Prefixes.............................................4 3.3 Geographical indexes.................................4 4. Tagging...............................................5 4.1 Tagging rules........................................5 4.2 Additional restrictions per prefix type..............6 4.2.1 Customer prefixes..................................6 4.2.2 BGP customers prefixes.............................6 4.2.3 Peer prefixes......................................6 4.2.4 Internal prefixes..................................6 4.2.5 Internal more specific prefixes....................6 4.2.6 Special Purpose prefixes...........................6 4.2.7 Other prefixes.....................................7 4.3 Tagging schemas......................................7 4.3.1 Standard community layout..........................7 4.3.2 Extended community layout..........................7 5. Word on summarization.................................8 6. Security Considerations...............................8 6.1 Inappropriate use...................................8 6.2 Integrity and confidentiality........................8 7. IANA Considerations...................................8 8. References............................................8 8.1. Informative references..............................8 8.2. Normative references................................9 9. Author addresses......................................9 1. Abstract BGP communities [RFC 1997] are 64-bit values that are used to tag the originated or traversing prefixes for the different purposes, such D. Meyer, M. Teplov Expires 18 December, 2008 [Page 2] Internet-Draft BGP Communities for data origination June 2008 as origination tagging or policy application purposes. These values can be displayed in a new and old format, which notes different representation of the same 64-bit value. This document defines the way of tagging prefixes based upon their geographical origination to assist in development of geographically-based policies that, ideally, will result in RTD (Round Trip Delay) value improvements, as optimized paths can be established. 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. Introduction BGP communities [RFC1997] are used for tagging purposes. These tags can be re-defined by the peer if needed by complete deletion or addition of a new one's. It is a good practice to keep the original tags untouched, so that originator can identify which entry point is used by the peer by consulting its BGP table through the looking glass facilities. Because the BGP is inter-domain routing protocol it is not taking into account actual low-level network elements, such as links for example, thus distancing itself from the realityof material world. This, being an obvious advantage, also is at the same time huge disadvantage when the traffic starts using paths that are not optimal in any way. Nowadays we see that even most of the delay-independent IGP routing protocols are adapted by the users to become delay-aware by reflecting the real-world delay in their IGP metric. Absence of the unified attributes in the BGP leads to the inability to create a routing policy which will rely on the well-known values. Defining such will ease troubleshooting and provisioning process of the ISP as well as add some clarity for the end-users. In addition to this small intra-country ISP's, or end customers, may choose to receive only limited continent (or less) prefixes, which will allow excellent possibilities to reduce the size of routing table that it necessary to achieve connectivity within their area of interest. This document will not provide any policies, neither ways to implement them - this is not a purpose of it, but values to be used and their application/modification points. RFC4384 provided the way to mark the prefixes in the different way, which proved to be less readable from the human eye, as values have been represented in HEX and binary formats, as well as it is hard to analyse them using regular expressions. This RFC is not there to substictute it, but to create an alternative path to mark the routes in a more convinient way. 3. Definitions In this section terms will be defined that are going to be used in this document. 3.1. Peers and Peering Peering is a BGP protocol/policy based relationship between the parties named as peers. In another words peering is an administrative D. Meyer, M. Teplov Expires 18 December, 2008 [Page 3] Internet-Draft BGP Communities for data origination June 2008 boundary of the domain managed by the single administrative entity. 3.2 Prefixes Prefix is a routing entry which represents NLRI (network layer reachability information) for a particular destination. Depending on a type of destination prefix can be a summary or more specific entry. Summary is an aggregated set more specific NLRI used to reduce number of the prefixes announced to the peers this is done by the party set of prefixes is registered to by the Internet registries (such as ARIN, RIPE, APNIC, etc). Each summary generated by the peer should equal or less specific to the one hes been assigned to him, for example: If peer is having eight class-C subnets he should not use aggregated address of /20, but only /21, which he has been assigned by the Internet authority. Aggregation advantages are widely recognized and being used (RFC2519). 3.3 Geographical indexes Indexes are common attributes to the set of routes that can be used to address and, as the result, manipulate prefixes using defined policies. Currently are defined as: - Region - geographical region. Should use the number padded to three digits. The following is proposed as a possible solution: Region code can consist of round to ten numbers, and can possibly be divided into the ten sub-regions. Lowest possible number is unallocated giving ability to address whole region. Region of world is used to preserve country specifics if the region it intentionally kept undefined. This can be done if the network spans more than two geographical regions, linked to the same upstream provider and it is using summarization to address it externally. No community of this kind should be advertised to the Internet. The regions are: World (000) Africa (010) has the following subregions that are encoded: - Eastern Africa (011) - Middle Africa (012) - Northern Africa (013) - Southern Africa (014) - Western Africa (015) Americas (020) has the following subregions that are encoded: - Northern America (021) - Caribbean (022) - Central America (023) - South America (024) Asia (030) has the following subregions that are encoded: - Central Asia (031) - Eastern Asia (032) - Southern Asia (033) - South-Eastern Asia (034) - Western Asia (035) D. Meyer, M. Teplov Expires 18 December, 2008 [Page 4] Internet-Draft BGP Communities for data origination June 2008 Europe (040) has the following subregions that are encoded: - Eastern Europe (041) - Northern Europe (042) - Southern Europe (043) - Western Europe (044) Oceania (050) has the following subregions that are encoded: - Australia and New Zealand (051) - Melanesia (052) - Micronesia (053) - Polynesia (054) - Country - three digits of E.164 country code, e.g.: USA (001), Russia (007), UK (044), NL (031), PA (501). Countries should be linked to the regions in according to the scheme for geographic sub-regions used by the United Nations. To prevent misunderstanding no codes from this documents are used, but relations between the region and the country. - State - code defined by the local internet authorities if needed - City - three digits of intra-county city dialling code with the padded to three leading zeros, e.g.: Amsterdam (020), Moscow (495), Washington DC (202). If there is more than one code that is used then local internet authorities should standardize such. Geographical indexes widening can be expressed as a zoom-out action, in direction from a city to the country, this city belongs to, and can happen during the prefix aggregation. Number of the cities can be aggregated into the country. As an example can be taken if the ISP A defines prefix range and allocates it to Netherlands, where certain subset of it belongs to Amsterdam, while another one belongs to Den Haag, for example. Sometimes, when the country is big and distances between the cities are high, sizes of the local ISP's can be significant to cover state area. In special case scenarios, when the country is spanning multiple time zones and multiple external, to the country links can exist, more than one region code can be assigned depending on the targeted area. 4. Tagging 4.1 Tagging rules The following rules should apply for the tags applied to the exchanged prefixes: 1. Location community should not be modified by the party being at the same level, unless this prefix belongs to that party, or it's sub-affiliate. It is allowed to perform error-checking if the party is an end customer or sub-tier ISP. 2. Region is a mandatory part. If region encoding is not present, then the specifics must be ignored. If the "World" region is specified it should be substituted with the one that has been used to receive the prefix, by itself it is not allowed to be admitted to the Internet. 3. Country index is an optional part. Country can be only present if the region is defined. 4. State and city indexes are independent of each-other, i.e. can be D. Meyer, M. Teplov Expires 18 December, 2008 [Page 5] Internet-Draft BGP Communities for data origination June 2008 applied one without another. They must not be applied without country index and must be ignored if country index is not identified. 4.2 Additional restrictions per prefix type 4.2.1 Customer prefixes Customer prefix is a minimal set of routing information used to direct customer's traffic from within the ISP network. This definition is only applicable to the single-homed customers (i.e. customers connected to one ISP) that are not sharing it with more than one ISP. Number of the connections of the specific customer to the specific ISP is irrelevant as soon as this ISP represents it as a single connection to all of it's peers. Type of the connection is irrelevant as in this case addresses belong to the ISP and it will define how to tag them. 4.2.2 BGP customers prefixes If the customer chooses to act as an independent entity and establish it's own relationships with the different ISPs then it may choose to be multi-homed, i.e. announce prefixes to the several different ISP's. Marking of such prefixes should be done by the ISP in conjunction with the customer, i.e. ISP can try to verify wherever the right marking is applied or not. 4.2.3 Peer prefixes Peer routes are those routes heard from peers via BGP, and not propagated to other peers. In particular, these routes are only propagated to the service provider's customers. No location tagging should be modified or stacked on top of such prefixes by parties that don't have any administrative control over received prefixes. Tagging is done only by the prefix owner and, if applicable, by the authorized by him party. One peer can check another peer's prefixes to identify wherever the tagging has been set correctly. 4.2.4 Internal prefixes Internal routes are those routes that a service provider originates and passes to its peers and customers. These routes are frequently taken out of the address space allocated to a provider. It is up to the prefix owner wherever to tag them or not. 4.2.5 Internal more specific prefixes Internal more specific routes are used for intra-ISP purposes, such as link assignments, device addresses, etc. Internal more specific prefixes are not exported to any external peer. It is up to the prefix owner wherever to tag them or not. In many cases this is not needed as many of them are accessible via IGP only. 4.2.6 Special Purpose prefixes Special purpose routes are those prefixes that do not fall into any of D. Meyer, M. Teplov Expires 18 December, 2008 [Page 6] Internet-Draft BGP Communities for data origination June 2008 the other classes described here. In those cases in which such routes need to be distinguished, a service provider may mark such routes with a unique value. In many cases Special Purpose prefixes are a custom case of Internal More Specific prefixes, for example multicast anycast RP, which is heavily relying on the IGP to be routed to. Due to the nature of these prefixes owner of them can choose to mark them based upon the advertisement point. This will, if implemented right, allow closest hop routing and, as the result, optimize the traffic flow for each entry point. 4.2.7 Other prefixes Other prefixes are: - Upstream prefixes, which are typically prefixes learned from the upstream ISP. - Peer routes - routes heard from peers via BGP, and not propagated to other peers. One example is an Internet exchange. - Transit prefixes - prefixes that are received from the Tier 1 ISP's for the destinations that are not a subject of peering agreements of any kind and, as the result, are accessible over so called transit. No location tagging should be modified or stacked on top of such prefixes by parties that don't have any administrative control over them. Tagging is done only by the prefix owner and, if applicable, by the party he authorized to do so. 4.3 Tagging schemas 4.3.1 Non-extended community layout This section provides encoding for the non-extended community values and geographical indexes encoding. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: - is IANA-standardized dedicated AS number, according to RFC 1997, that is not assigned and can be freely used for tagging purposes; - is the region, country, state or city code encoded in the following decimal way: - Value of 1 means that three tail digits are the region code; - Value of 2 means that three tail digits are the country code; - Value of 3 means that three tail digits are the state code; - Value of 4 means that three tail digits are the city code; 4.3.2 Extended community layout It is preferred not to use extended community encoding for the data origination tagging at this time as many ISP's are not allowing extended communities to transit their network, hence it will be useless D. Meyer, M. Teplov Expires 18 December, 2008 [Page 7] Internet-Draft BGP Communities for data origination June 2008 for the public activity to have any. In the future it maybe considered to ask IANA to allocate specific type value to cover such purpose. 5. Word on summarization This tagging schema will, perhaps, pose possible summarization problems, but only if the subnets are sporadically assigned. In many cases this is not an issue, but in some it is. An easiest way out will be to define minimal prefix length that can be chosen to be aggregated to and specific tag will be applied without stretching any rules. ISP home addresses, such as functional addresses of the network devices participating in ISP's network, can be, for example, be chosen to belong to the ISP's primary region, while can be located in many other regions. 6. Security Considerations 6.1 Inappropriate use If one will be using these communities to define policies, to prefer or not certain prefixes over one path than another, one can also attempt to influence that decision by tempering into the existing communities and overwriting them. This can, possibly, result in sub-optimal routing for the tempered prefixes for other members of Internet community. In event of such it will be possible to trace the source of such advertisement as the nature of it should be more or less static. In addition to that T1-T2 providers may, if it will be considered possible, to prevent such attempts by enforcing region/country/state validity check at their borders. 6.2 Integrity and confidentiality Communities attributes are public, if they are advertised throughout the borders of the AS that applied them. Integrity of them is checked by the means TCP and BGP methods. Authentication is provided by means of BGP protocol that carry them [RFC4271]. 7. IANA considerations IANA should maintain the assignments of the unique AS number to be used in such communities as well as delegate assignments below country levels to the local Internet registries, which should make them publicly available. The AS number mentioned should be circulated by IANA prior to this document official release and will not be altered in any way. 8. References 8.1. Informative references [UN-M49] United Nations Geographical region and composition of each region, Web page: http://unstats.un.org/unsd /methods/m49/m49regin.htm D. Meyer, M. Teplov Expires 18 December, 2008 [Page 8] Internet-Draft BGP Communities for data origination June 2008 [RFC3552] E. Rescorla, B. Korver, "Security Considerations Guidelines", RFC 3552, July 2003. 8.2. Normative references [E.164] "ITU Telecommunication Standardization Sector (ITU- T) International Numbering Resources ", Web Page: http://www.itu.int/ITU-T/inr/ [IANA] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC5226, May 2008. [RFC1997] Chandra, R. and P. Traina, "BGP Communities Attribute", RFC 1997, August 1996. [RFC4271] Y. Rekhter, T. Li, S. Hares, (Editors), "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, January 2006. [RFC4384] D. Meyer, "BGP Communities for Data Collection", RFC 4384, February 2006 9. Author's Address David Meyer EMail: dmm@1-4-5.net Matvey Teplov EMail: matvey.teplov@gmail.com D. Meyer, M. Teplov Expires 18 December, 2008 [Page 9]