idnits 2.17.1 draft-ietf-idr-bgp-ext-communities-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 32. -- Found old boilerplate from RFC 3978, Section 5.5 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 459. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2434' is mentioned on line 413, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'BGP-4' is defined on line 485, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Srihari R. Sangli (Cisco Systems) 2 Internet Draft Daniel Tappan (Cisco Systems) 3 Expiration Date: January 2006 Yakov Rekhter (Juniper Networks) 5 BGP Extended Communities Attribute 7 draft-ietf-idr-bgp-ext-communities-09.txt 9 Status of this Memo 11 Internet-Drafts are working documents of the Internet Engineering 12 Task Force (IETF), its areas, and its working groups. Note that 13 other groups may also distribute working documents as Internet- 14 Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress". 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 IPR Disclosure Acknowledgement 29 By submitting this Internet-Draft, each author represents that any 30 applicable patent or other IPR claims of which he or she is aware 31 have been or will be disclosed, and any of which he or she becomes 32 aware will be disclosed, in accordance with Section 6 of BCP 79. 34 Abstract 36 This document describes the "extended community" BGP-4 attribute. 37 This attribute provides a mechanism for labeling information carried 38 in BGP-4. These labels can be used to control the distribution of 39 this information, or for other applications. 41 Specification of Requirements 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC 2119 [RFC2119]. 47 1. Introduction 49 The Extended Community Attribute provides two important enhancements 50 over the existing BGP Community Attribute [RFC1997]: 52 - It provides an extended range, ensuring that communities can be 53 assigned for a plethora of uses, without fear of overlap. 55 - The addition of a Type field provides structure for the 56 community space. 58 The addition of structure allows the usage of policy based on the 59 application for which the community value will be used. For example, 60 one can filter out all communities of a particular type, or allow 61 only certain values for a particular type of community. It also 62 allows one to specify whether a particular community is transitive or 63 non-transitive across Autonomous system boundary. Without structure, 64 this can only be accomplished by explicitly enumerating all community 65 values which will be denied or allowed and passed to BGP speakers in 66 neighboring ASes based on the transitive property. 68 2. BGP Extended Communities Attribute 70 The Extended Communities Attribute is a transitive optional BGP 71 attribute, with the Type Code 16. The attribute consists of a set of 72 "extended communities". All routes with the Extended Communities 73 attribute belong to the communities listed in the attribute. 75 Each Extended Community is encoded as an eight octet quantity, as 76 follows: 78 - Type Field : 1 or 2 octets 79 - Value Field : Remaining octets 80 0 1 2 3 81 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 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 | Type high | Type low(*) | | 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | 85 | | 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 *) Present for Extended types only, used for the Value field 89 otherwise 91 Type Field: 93 Two classes of Type Field are introduced: Regular type and 94 Extended type. 96 The size of Type Field for Regular types is 1 octet and the 97 size of the Type Field for Extended types is 2 octets. 99 The value of the high-order octet of the Type Field determines 100 if an extended community is a Regular type or an Extended type. 101 The class of a type (Regular or Extended) is not encoded in the 102 structure of the type itself. The class of a type is specified 103 in the document which defines the type and the IANA registry. 105 The high-order octet of the Type Field is as shown below: 107 0 1 2 3 4 5 6 7 108 +-+-+-+-+-+-+-+-+ 109 |I|T| | 110 +-+-+-+-+-+-+-+-+ 112 I - IANA authority bit 114 Value 0: IANA assignable type using the "First Come First 115 Serve" policy 117 Value 1: Part of this Type Field space is for IANA 118 assignable types using either the Standard Action or the 119 Early IANA Allocation policy. The rest of this Type 120 Field space is for Experimental use. 122 T - Transitive bit 123 Value 0: The community is transitive across ASes 125 Value 1: The community is non-transitive across ASes 127 Remaining 6 bits: Indicates the structure of the community 129 Value Field: 131 The encoding of the Value Field is dependent on the "type" of 132 the community as specified by the Type Field. 134 Two extended communities are declared equal only when all 8 octets of 135 the community are equal. 137 The two members in the tuple should be enumerated to 138 specify any community value. The remaining octets of the community 139 interpreted based on the value of the Type field. 141 3. Defined BGP Extended Community Types 143 This section introduces a few extended types and defines the format 144 of the Value Field for those types. The types introduced here provide 145 "templates", where each template is identified by the high order 146 octet of the extended community Type field, and the lower order octet 147 (sub-type) is used to indicate a particular type of extended 148 community. 150 3.1. Two-octet AS specific extended community 152 This is an extended type with Type Field comprising of 2 octets and 153 Value Field comprising of 6 octets. 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | 0x00 or 0x40 | Sub-Type | Global Administrator | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Local Administrator | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 The value of the high-order octet of this extended type is either 164 0x00 or 0x40. The low-order octet of this extended type is used to 165 indicate sub-types. 167 The Value Field consists of two sub-fields: 169 Global Administrator sub-field: 2 octets 171 This sub-field contains an Autonomous System number assigned by 172 IANA. 174 Local Administrator sub-field: 4 octets 176 The organization identified by Autonomous System number in the 177 Global Administrator sub-field, can encode any information in 178 this sub-field. The format and meaning of the value encoded in 179 this sub-field should be defined by the sub-type of the 180 community. 182 3.2. IPv4 address specific extended community 184 This is an extended type with Type Field comprising of 2 octets and 185 Value Field comprising of 6 octets. 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | 0x01 or 0x41 | Sub-Type | Global Administrator | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Global Administrator (cont.) | Local Administrator | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 The value of the high-order octet of this extended type is either 196 0x01 or 0x41. The low-order octet of this extended type is used to 197 indicate sub-types. 199 The Value field consists of two sub-fields: 201 Global Administrator sub-field: 4 octets 203 This sub-field contains an IPv4 unicast address assigned by one 204 of the Internet registries. 206 Local Administrator sub-field: 2 octets 208 The organization which has been assigned the IPv4 address in 209 the Global Administrator sub-field, can encode any information 210 in this sub-field. The format and meaning of this value 211 encoded in this sub-field should be defined by the sub-type of 212 the community. 214 3.3. Opaque extended community 216 This is an extended type with Type Field comprising of 2 octets and 217 Value Field comprising of 6 octets. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | 0x03 or 0x43 | Sub-Type | Value | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Value (cont.) | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 The value of the high-order octet of this extended type is either 228 0x03 or 0x43. The low-order octet of this extended type is used to 229 indicate sub-types. 231 This is a generic community of extended type. The value of the sub- 232 type which should define the Value Field is to be assigned by IANA. 234 4. Route Target Community 236 The Route Target Community identifies one or more routers that may 237 receive a set of routes (that carry this Community) carried by BGP. 238 This is transitive across the Autonomous system boundary. 240 The Route Target Community is of an extended type. 242 The value of the high-order octet of the Type field for the Route 243 Target Community can be 0x00, 0x01 or 0x02. The value of the low- 244 order octet of the Type field for this community is 0x02. 246 When the value of the high-order octet of the Type field is 0x00 or 247 0x02, the Local Administrator sub-field contains a number from a 248 numbering space which is administered by the organization to which 249 the Autonomous System number carried in the Global Administrator 250 subfield has been assigned by an appropriate authority. 252 When the value of the high-order octet of the Type field is 0x01, the 253 Local Administrator sub-field contains a number from a numbering 254 space which is administered by the organization to which the IP 255 address carried in the Global Administrator subfield has been 256 assigned by an appropriate authority. 258 One possible use of the Route Target Community is specified in [BGP- 259 MPLS-VPN]. 261 5. Route Origin Community 263 The Route Origin Community identifies one or more routers that inject 264 a set of routes (that carry this Community) into BGP. This is 265 transitive across the Autonomous system boundary. 267 The Route Origin Community is of an extended type. 269 The value of the high-order octet of the Type field for the Route 270 Origin Community can be 0x00, 0x01 or 0x02. The value of the low- 271 order octet of the Type field for this community is 0x03. 273 When the value of the high-order octet of the Type field is 0x00 or 274 0x02, the Local Administrator sub-field contains a number from a 275 numbering space which is administered by the organization to which 276 the Autonomous System number carried in the Global Administrator 277 subfield has been assigned by an appropriate authority. 279 When the value of the high-order octet of the Type field is 0x01, the 280 Local Administrator sub-field contains a number from a numbering 281 space which is administered by the organization to which the IP 282 address carried in the Global Administrator subfield has been 283 assigned by an appropriate authority. 285 One possible use of the Route Origin Community is specified in [BGP- 286 MPLS-VPN]. 288 6. Operations 290 A BGP speaker may use the Extended Communities attribute to control 291 which routing information it accepts or distributes to its peers. 293 The Extended Community attribute MUST NOT be used to modify the BGP 294 best path selection algorithm in a way that leads to forwarding 295 loops. 297 A BGP speaker receiving a route that doesn't have the Extended 298 Communities attribute MAY append this attribute to the route when 299 propagating it to its peers. 301 A BGP speaker receiving a route with the Extended Communities 302 attribute MAY modify this attribute according to the local policy. 304 By default if a range of routes is to be aggregated and the resultant 305 aggregates path attributes do not carry the ATOMIC_AGGREGATE 306 attribute, then the resulting aggregate should have an Extended 307 Communities path attribute which contains the set union of all the 308 Extended Communities from all of the aggregated routes. The default 309 behavior could be overriden via local configuration, in which case 310 handling the Extended Communities attribute in the presence of route 311 aggregation becomes a matter of the local policy of the BGP speaker 312 that performs the aggregation. 314 If a route has a non-transitivity extended community, then before 315 advertising the route across the Autonomous system boundary the 316 community SHOULD be removed from the route. However, the community 317 SHOULD NOT be removed when advertising the route across the BGP 318 Confederation boundary. 320 A route may carry both the BGP Communities attribute as defined in 321 [RFC1997]), and the Extended BGP Communities attribute. In this case 322 the BGP Communities attribute is handled as specified in [RFC1997], 323 and the Extended BGP Communities attribute is handled as specified in 324 this document. 326 7. IANA Considerations 328 All the BGP Extended Communities contain a Type field for which IANA 329 is to create and maintain a registry entitled "BGP Extended 330 Communities Type". 332 The Type could be either regular or extended. For a regular Type the 333 IANA allocates an 8-bits value; for an extended Type the IANA 334 allocates a 16-bits value. 336 The value allocated for a regular Type MUST NOT be reused as the 337 value of the high-order octet when allocating an extended Type. The 338 value of the high-order octet allocated for an extended Type MUST NOT 339 be reused when allocating a regular Type. 341 The Type field indicates where the Extended Community is transitive 342 or not. Future requests for assignment of a Type value must specify 343 whether the Type value is intended for a transitive or a non- 344 transitive Extended Community. 346 Future assignment are to be made using either the Standards Action 347 process defined in [RFC2434], or the Early IANA Allocation process 348 defined in [kompella-zinin], or the "First Come First Served" policy 349 defined in [RFC2434]. 351 The following table summarizes the ranges for the assignment of 352 Types: 354 Type Standard Action First Come 355 Early IANA Allocation First Served 356 ------------------ --------------------- ------------ 358 regular, transitive 0x90-0xbf 0x00-x3f 360 regular, non-transitive 0xd0-0xff 0x40-0x7f 362 extended, transitive 0x9000-0xbfff 0x0000-0x3fff 364 extended, non-transitive 0xd000-0xffff 0x4000-0x7fff 366 Assignments consist of a name and the value. 368 The Type values 0x80-0x8f and 0xc0-0xcf for regular Types, and 369 0x8000-0x8fff and 0xc000-0xcfff for extended Types are for 370 Experimental use as defined in RFC3692. 372 This document defines a class of extended communities called two- 373 octet AS specific extended community for which the IANA is to create 374 and maintain a registry entitled "Two-octet AS Specific Extended 375 Community". All the communities in this class are of extended Types. 376 Future assignment are to be made using the "First Come First Served" 377 policy defined in [RFC2434]. The Type values for the transitive 378 communities of the two-octet AS specific extended community class are 379 0x0000-0x00ff, and for the non-transitive communities of that class 380 are 0x4000-0x40ff. Assignments consist of a name and the value. 382 This document makes the following assignments for the two-octet AS 383 specific extended community: 385 Name Type Value 386 ---- ---------- 387 two-octet AS specific Route Target 0x0002 388 two-octet AS specific Route Origin 0x0003 390 This document defines a class of extended communities called IPv4 391 address specific extended community for which the IANA is to create 392 and maintain a registry entitled "IPv4 Address Specific Extended 393 Community". All the communities in this class are of extended Types. 394 Future assignment are to be made using the "First Come First Served" 395 policy defined in [RFC2434]. The Type values for the transitive 396 communities of the two-octet AS specific extended community class 397 are 0x0100-0x01ff, and for the non-transitive communities of that 398 class are 0x4100-0x41ff. Assignments consist of a name and the 399 value. 401 This document makes the following assignments for the IPv4 address 402 specific extended community: 404 Name Type Value 405 ---- ---------- 406 IPv4 address specific Route Target 0x0102 407 IPv4 address specific Route Origin 0x0103 409 This document defines a class of extended communities called opaque 410 extended community for which the IANA is to create and maintain a 411 registry entitled "Opaque Extended Community". All the communities 412 in this class are of extended Types. Future assignment are to be 413 made using the "First Come First Served" policy defined in [RFC2434]. 414 The Type values for the transitive communities of the opaque extended 415 community class are 0x0300-0x03ff, and for the non-transitive 416 communities of that class are 0x4300-0x43ff. Assignments consist 417 of a name and the value. 419 When requesting an allocation from more than one registry defined 420 above, one may ask for allocating the same Type value from 421 these registries. If possible, the IANA should accommodate such 422 requests. 424 8. Security Considerations 426 This extension to BGP has similar security implications as BGP 427 Communities [RFC1997]. 429 This extension to BGP does not change the underlying security issues. 430 Specifically, an operator who is relying on the information carried 431 in BGP must have a transitive trust relationship back to the source 432 of the information. Specifying the mechanism(s) to provide such a 433 relationship is beyond the scope of this document. 435 9. Intellectual Property Considerations 437 This section is taken from Section 5 of RFC 3668. 439 The IETF takes no position regarding the validity or scope of any 440 Intellectual Property Rights or other rights that might be claimed to 441 pertain to the implementation or use of the technology described in 442 this document or the extent to which any license under such rights 443 might or might not be available; nor does it represent that it has 444 made any independent effort to identify any such rights. Information 445 on the procedures with respect to rights in RFC documents can be 446 found in BCP 78 and BCP 79. 448 Copies of IPR disclosures made to the IETF Secretariat and any 449 assurances of licenses to be made available, or the result of an 450 attempt made to obtain a general license or permission for the use of 451 such proprietary rights by implementers or users of this 452 specification can be obtained from the IETF on-line IPR repository at 453 http://www.ietf.org/ipr. 455 The IETF invites any interested party to bring to its attention any 456 copyrights, patents or patent applications, or other proprietary 457 rights that may cover technology that may be required to implement 458 this standard. Please address the information to the IETF at ietf- 459 ipr@ietf.org. 461 10. Copyright Notice 463 Copyright (C) The Internet Society (2005). 465 This document is subject to the rights, licenses and restrictions 466 contained in BCP 78, and except as set forth therein, the authors 467 retain all their rights. 469 This document and the information contained herein are provided on an 470 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 471 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 472 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 473 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 474 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 475 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 477 11. Acknowledgements 479 The authors would like to thank John Hawkinson, Jeffrey Haas, Bruno 480 Rijsman, Bill Fenner, and Alex Zinin for their suggestions and 481 feedback. 483 12. Normative References 485 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 486 (BGP-4)", RFC 1771, March 1995. 488 [RFC1997] Chandra, R., Traina, P., Li, T., "BGP Communities 489 Attribute", RFC1997, August 1996. 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 13. Non-normative References 496 [BGP-MPLS-VPN] Rosen, E., Rekhter, Y., "BGP/MPLS IP VPNs", draft- 497 ietf-l3vpn-rfc2547bis-03.txt 499 [RFC1997] Chandra, R., Traina, P., Li, T., "BGP Communities 500 Attribute" RFC1997 502 14. Author Information 504 Srihari R. Sangli 505 Cisco Systems, Inc. 506 e-mail: rsrihari@cisco.com 508 Dan Tappan 509 Cisco Systems, Inc. 510 250 Apollo Drive 511 Chelmsford, MA 01824 512 e-mail: tappan@cisco.com 514 Yakov Rekhter 515 Juniper Networks, Inc. 516 1194 N. Mathilda Ave 517 Sunnyvale, CA 94089 518 e-mail: yakov@juniper.net