rfc4360.txt (24145B)
1 2 3 4 5 6 7 Network Working Group S. Sangli 8 Request for Comments: 4360 D. Tappan 9 Category: Standards Track Cisco Systems 10 Y. Rekhter 11 Juniper Networks 12 February 2006 13 14 15 BGP Extended Communities Attribute 16 17 Status of This Memo 18 19 This document specifies an Internet standards track protocol for the 20 Internet community, and requests discussion and suggestions for 21 improvements. Please refer to the current edition of the "Internet 22 Official Protocol Standards" (STD 1) for the standardization state 23 and status of this protocol. Distribution of this memo is unlimited. 24 25 Copyright Notice 26 27 Copyright (C) The Internet Society (2006). 28 29 Abstract 30 31 This document describes the "extended community" BGP-4 attribute. 32 This attribute provides a mechanism for labeling information carried 33 in BGP-4. These labels can be used to control the distribution of 34 this information, or for other applications. 35 36 1. Introduction 37 38 The Extended Community Attribute provides a mechanism for labeling 39 information carried in BGP-4 [BGP-4]. It provides two important 40 enhancements over the existing BGP Community Attribute [RFC1997]: 41 42 - An extended range, ensuring that communities can be assigned for 43 a plethora of uses, without fear of overlap. 44 45 - The addition of a Type field provides structure for the 46 community space. 47 48 The addition of structure allows the usage of policy based on the 49 application for which the community value will be used. For example, 50 one can filter out all communities of a particular type, or allow 51 only certain values for a particular type of community. It also 52 allows one to specify whether a particular community is transitive or 53 non-transitive across an Autonomous System (AS) boundary. Without 54 structure, this can only be accomplished by explicitly enumerating 55 56 57 58 Sangli, et al. Standards Track [Page 1] 59 60 RFC 4360 BGP Extended Communities Attribute February 2006 61 62 63 all community values that will be denied or allowed and passed to BGP 64 speakers in neighboring ASes based on the transitive property. 65 66 1.1. Specification of Requirements 67 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in RFC 2119 [RFC2119]. 71 72 2. BGP Extended Communities Attribute 73 74 The Extended Communities Attribute is a transitive optional BGP 75 attribute, with the Type Code 16. The attribute consists of a set of 76 "extended communities". All routes with the Extended Communities 77 attribute belong to the communities listed in the attribute. 78 79 Each Extended Community is encoded as an 8-octet quantity, as 80 follows: 81 82 - Type Field : 1 or 2 octets 83 - Value Field : Remaining octets 84 85 0 1 2 3 86 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 87 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 | Type high | Type low(*) | | 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | 90 | | 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 93 (*) Present for Extended types only, used for the Value field 94 otherwise. 95 96 Type Field: 97 98 Two classes of Type Field are introduced: Regular type and 99 Extended type. 100 101 The size of Type Field for Regular types is 1 octet, and the 102 size of the Type Field for Extended types is 2 octets. 103 104 The value of the high-order octet of the Type Field determines 105 if an extended community is a Regular type or an Extended type. 106 The class of a type (Regular or Extended) is not encoded in the 107 structure of the type itself. The class of a type is specified 108 in the document that defines the type and the IANA registry. 109 110 111 112 113 114 Sangli, et al. Standards Track [Page 2] 115 116 RFC 4360 BGP Extended Communities Attribute February 2006 117 118 119 The high-order octet of the Type Field is as shown below: 120 121 0 1 2 3 4 5 6 7 122 +-+-+-+-+-+-+-+-+ 123 |I|T| | 124 +-+-+-+-+-+-+-+-+ 125 126 I - IANA authority bit 127 128 Value 0: IANA-assignable type using the "First Come First 129 Serve" policy 130 131 Value 1: Part of this Type Field space is for IANA 132 assignable types using either the Standard Action or the 133 Early IANA Allocation policy. The rest of this Type 134 Field space is for Experimental use. 135 136 T - Transitive bit 137 138 Value 0: The community is transitive across ASes 139 140 Value 1: The community is non-transitive across ASes 141 142 Remaining 6 bits: Indicates the structure of the community 143 144 Value Field: 145 146 The encoding of the Value Field is dependent on the "type" of 147 the community as specified by the Type Field. 148 149 Two extended communities are declared equal only when all 8 octets of 150 the community are equal. 151 152 The two members in the tuple <Type, Value> should be enumerated to 153 specify any community value. The remaining octets of the community 154 interpreted based on the value of the Type field. 155 156 3. Defined BGP Extended Community Types 157 158 This section introduces a few extended types and defines the format 159 of the Value Field for those types. The types introduced here 160 provide "templates", where each template is identified by the high- 161 order octet of the extended community Type field, and the lower-order 162 octet (sub-type) is used to indicate a particular type of extended 163 community. 164 165 166 167 168 169 170 Sangli, et al. Standards Track [Page 3] 171 172 RFC 4360 BGP Extended Communities Attribute February 2006 173 174 175 3.1. Two-Octet AS Specific Extended Community 176 177 This is an extended type with Type Field composed of 2 octets and 178 Value Field composed of 6 octets. 179 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | 0x00 or 0x40 | Sub-Type | Global Administrator | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Local Administrator | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 188 The value of the high-order octet of this extended type is either 189 0x00 or 0x40. The low-order octet of this extended type is used to 190 indicate sub-types. 191 192 The Value Field consists of two sub-fields: 193 194 Global Administrator sub-field: 2 octets 195 196 This sub-field contains an Autonomous System number assigned by 197 IANA. 198 199 Local Administrator sub-field: 4 octets 200 201 The organization identified by Autonomous System number in the 202 Global Administrator sub-field can encode any information in 203 this sub-field. The format and meaning of the value encoded in 204 this sub-field should be defined by the sub-type of the 205 community. 206 207 3.2. IPv4 Address Specific Extended Community 208 209 This is an extended type with Type Field composed of 2 octets and 210 Value Field composed of 6 octets. 211 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | 0x01 or 0x41 | Sub-Type | Global Administrator | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Global Administrator (cont.) | Local Administrator | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 220 The value of the high-order octet of this extended type is either 221 0x01 or 0x41. The low-order octet of this extended type is used to 222 indicate sub-types. 223 224 225 226 Sangli, et al. Standards Track [Page 4] 227 228 RFC 4360 BGP Extended Communities Attribute February 2006 229 230 231 The Value field consists of two sub-fields: 232 233 Global Administrator sub-field: 4 octets 234 235 This sub-field contains an IPv4 unicast address assigned by one 236 of the Internet registries. 237 238 Local Administrator sub-field: 2 octets 239 240 The organization that has been assigned the IPv4 address in the 241 Global Administrator sub-field can encode any information in 242 this sub-field. The format and meaning of this value encoded 243 in this sub-field should be defined by the sub-type of the 244 community. 245 246 3.3. Opaque Extended Community 247 248 This is an extended type with Type Field composed of 2 octets and 249 Value Field composed of 6 octets. 250 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | 0x03 or 0x43 | Sub-Type | Value | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Value (cont.) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 259 The value of the high-order octet of this extended type is either 260 0x03 or 0x43. The low-order octet of this extended type is used to 261 indicate sub-types. 262 263 This is a generic community of extended type. The value of the sub- 264 type that should define the Value Field is to be assigned by IANA. 265 266 4. Route Target Community 267 268 The Route Target Community identifies one or more routers that may 269 receive a set of routes (that carry this Community) carried by BGP. 270 This is transitive across the Autonomous System boundary. 271 272 The Route Target Community is of an extended type. 273 274 The value of the high-order octet of the Type field for the Route 275 Target Community can be 0x00, 0x01, or 0x02. The value of the low- 276 order octet of the Type field for this community is 0x02. 277 278 279 280 281 282 Sangli, et al. Standards Track [Page 5] 283 284 RFC 4360 BGP Extended Communities Attribute February 2006 285 286 287 When the value of the high-order octet of the Type field is 0x00 or 288 0x02, the Local Administrator sub-field contains a number from a 289 numbering space that is administered by the organization to which the 290 Autonomous System number carried in the Global Administrator sub- 291 field has been assigned by an appropriate authority. 292 293 When the value of the high-order octet of the Type field is 0x01, the 294 Local Administrator sub-field contains a number from a numbering 295 space that is administered by the organization to which the IP 296 address carried in the Global Administrator sub-field has been 297 assigned by an appropriate authority. 298 299 One possible use of the Route Target Community is specified in 300 [RFC4364]. 301 302 5. Route Origin Community 303 304 The Route Origin Community identifies one or more routers that inject 305 a set of routes (that carry this Community) into BGP. This is 306 transitive across the Autonomous System boundary. 307 308 The Route Origin Community is of an extended type. 309 310 The value of the high-order octet of the Type field for the Route 311 Origin Community can be 0x00, 0x01, or 0x02. The value of the low- 312 order octet of the Type field for this community is 0x03. 313 314 When the value of the high-order octet of the Type field is 0x00 or 315 0x02, the Local Administrator sub-field contains a number from a 316 numbering space that is administered by the organization to which the 317 Autonomous System number carried in the Global Administrator sub- 318 field has been assigned by an appropriate authority. 319 320 When the value of the high-order octet of the Type field is 0x01, the 321 Local Administrator sub-field contains a number from a numbering 322 space that is administered by the organization to which the IP 323 address carried in the Global Administrator sub-field has been 324 assigned by an appropriate authority. 325 326 One possible use of the Route Origin Community is specified in 327 [RFC4364]. 328 329 330 331 332 333 334 335 336 337 338 Sangli, et al. Standards Track [Page 6] 339 340 RFC 4360 BGP Extended Communities Attribute February 2006 341 342 343 6. Operations 344 345 A BGP speaker may use the Extended Communities attribute to control 346 which routing information it accepts or distributes to its peers. 347 348 The Extended Community attribute MUST NOT be used to modify the BGP 349 best path selection algorithm in a way that leads to forwarding 350 loops. 351 352 A BGP speaker receiving a route that doesn't have the Extended 353 Communities attribute MAY append this attribute to the route when 354 propagating it to its peers. 355 356 A BGP speaker receiving a route with the Extended Communities 357 attribute MAY modify this attribute according to the local policy. 358 359 By default if a range of routes is to be aggregated and the resultant 360 aggregates path attributes do not carry the ATOMIC_AGGREGATE 361 attribute, then the resulting aggregate should have an Extended 362 Communities path attribute that contains the set union of all the 363 Extended Communities from all of the aggregated routes. The default 364 behavior could be overridden via local configuration, in which case 365 handling the Extended Communities attribute in the presence of route 366 aggregation becomes a matter of the local policy of the BGP speaker 367 that performs the aggregation. 368 369 If a route has a non-transitivity extended community, then before 370 advertising the route across the Autonomous System boundary the 371 community SHOULD be removed from the route. However, the community 372 SHOULD NOT be removed when advertising the route across the BGP 373 Confederation boundary. 374 375 A route may carry both the BGP Communities attribute, as defined in 376 [RFC1997]), and the Extended BGP Communities attribute. In this 377 case, the BGP Communities attribute is handled as specified in 378 [RFC1997], and the Extended BGP Communities attribute is handled as 379 specified in this document. 380 381 7. IANA Considerations 382 383 All the BGP Extended Communities contain a Type field. The IANA has 384 created a registry entitled, "BGP Extended Communities Type". The 385 IANA will maintain this registry. 386 387 The Type could be either regular or extended. For a regular Type the 388 IANA allocates an 8-bit value; for an extended Type the IANA 389 allocates a 16-bit value. 390 391 392 393 394 Sangli, et al. Standards Track [Page 7] 395 396 RFC 4360 BGP Extended Communities Attribute February 2006 397 398 399 The value allocated for a regular Type MUST NOT be reused as the 400 value of the high-order octet when allocating an extended Type. The 401 value of the high-order octet allocated for an extended Type MUST NOT 402 be reused when allocating a regular Type. 403 404 The Type field indicates where the Extended Community is transitive 405 or not. Future requests for assignment of a Type value must specify 406 whether the Type value is intended for a transitive or a non- 407 transitive Extended Community. 408 409 Future assignment are to be made using either the Standards Action 410 process defined in [RFC2434], the Early IANA Allocation process 411 defined in [RFC4020], or the "First Come First Served" policy defined 412 in [RFC2434]. 413 414 The following table summarizes the ranges for the assignment of 415 Types: 416 417 Type Standard Action First Come 418 Early IANA Allocation First Served 419 ------------------ --------------------- ------------ 420 421 regular, transitive 0x90-0xbf 0x00-x3f 422 423 regular, non-transitive 0xd0-0xff 0x40-0x7f 424 425 extended, transitive 0x9000-0xbfff 0x0000-0x3fff 426 427 extended, non-transitive 0xd000-0xffff 0x4000-0x7fff 428 429 Assignments consist of a name and the value. 430 431 The Type values 0x80-0x8f and 0xc0-0xcf for regular Types, and 432 0x8000-0x8fff and 0xc000-0xcfff for extended Types are for 433 Experimental use as defined in RFC 3692. 434 435 This document defines a class of extended communities called two- 436 octet AS specific extended community for which the IANA is to create 437 and maintain a registry entitled "Two-octet AS Specific Extended 438 Community". All the communities in this class are of extended Types. 439 Future assignment are to be made using the "First Come First Served" 440 policy defined in [RFC2434]. The Type values for the transitive 441 communities of the two-octet AS specific extended community class are 442 0x0000-0x00ff, and for the non-transitive communities of that class 443 are 0x4000-0x40ff. Assignments consist of a name and the value. 444 445 This document makes the following assignments for the two-octet AS 446 specific extended community: 447 448 449 450 Sangli, et al. Standards Track [Page 8] 451 452 RFC 4360 BGP Extended Communities Attribute February 2006 453 454 455 Name Type Value 456 ---- ---------- 457 two-octet AS specific Route Target 0x0002 458 two-octet AS specific Route Origin 0x0003 459 460 This document defines a class of extended communities called IPv4 461 address specific extended community for which the IANA is to create 462 and maintain a registry entitled "IPv4 Address Specific Extended 463 Community". All the communities in this class are of extended Types. 464 Future assignment are to be made using the "First Come First Served" 465 policy defined in [RFC2434]. The Type values for the transitive 466 communities of the two-octet AS specific extended community class 467 are 0x0100-0x01ff, and for the non-transitive communities of that 468 class are 0x4100-0x41ff. Assignments consist of a name and the 469 value. 470 471 This document makes the following assignments for the IPv4 address 472 specific extended community: 473 474 Name Type Value 475 ---- ---------- 476 IPv4 address specific Route Target 0x0102 477 IPv4 address specific Route Origin 0x0103 478 479 This document defines a class of extended communities called opaque 480 extended community for which the IANA is to create and maintain a 481 registry entitled "Opaque Extended Community". All the communities 482 in this class are of extended Types. Future assignment are to be 483 made using the "First Come First Served" policy defined in [RFC2434]. 484 The Type values for the transitive communities of the opaque extended 485 community class are 0x0300-0x03ff, and for the non-transitive 486 communities of that class are 0x4300-0x43ff. Assignments consist of 487 a name and the value. 488 489 When requesting an allocation from more than one registry defined 490 above, one may ask for allocating the same Type value from these 491 registries. If possible, the IANA should accommodate such requests. 492 493 8. Security Considerations 494 495 This extension to BGP has similar security implications as BGP 496 Communities [RFC1997]. 497 498 This extension to BGP does not change the underlying security issues. 499 Specifically, an operator who is relying on the information carried 500 in BGP must have a transitive trust relationship back to the source 501 of the information. Specifying the mechanism(s) to provide such a 502 relationship is beyond the scope of this document. 503 504 505 506 Sangli, et al. Standards Track [Page 9] 507 508 RFC 4360 BGP Extended Communities Attribute February 2006 509 510 511 9. Acknowledgements 512 513 The authors would like to thank John Hawkinson, Jeffrey Haas, Bruno 514 Rijsman, Bill Fenner, and Alex Zinin for their suggestions and 515 feedback. 516 517 10. Normative References 518 519 [BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 520 (BGP-4)", RFC 4271, January 2006. 521 522 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 523 Attribute", RFC 1997, August 1996. 524 525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 526 Requirement Levels", BCP 14, RFC 2119, March 1997. 527 528 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing 529 an IANA Considerations Section in RFCs", BCP 26, RFC 530 2434, October 1998. 531 532 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 533 Standards Track Code Points", BCP 100, RFC 4020, 534 February 2005. 535 536 11. Informative References 537 538 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 539 Networks (VPNs)", RFC 4364, February 2006. 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 Sangli, et al. Standards Track [Page 10] 563 564 RFC 4360 BGP Extended Communities Attribute February 2006 565 566 567 Authors' Addresses 568 569 Srihari R. Sangli 570 Cisco Systems, Inc. 571 572 EMail: rsrihari@cisco.com 573 574 575 Dan Tappan 576 Cisco Systems, Inc. 577 250 Apollo Drive 578 Chelmsford, MA 01824 579 580 EMail: tappan@cisco.com 581 582 583 Yakov Rekhter 584 Juniper Networks, Inc. 585 1194 N. Mathilda Ave 586 Sunnyvale, CA 94089 587 588 EMail: yakov@juniper.net 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 Sangli, et al. Standards Track [Page 11] 619 620 RFC 4360 BGP Extended Communities Attribute February 2006 621 622 623 Full Copyright Statement 624 625 Copyright (C) The Internet Society (2006). 626 627 This document is subject to the rights, licenses and restrictions 628 contained in BCP 78, and except as set forth therein, the authors 629 retain all their rights. 630 631 This document and the information contained herein are provided on an 632 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 633 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 634 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 635 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 636 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 637 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 638 639 Intellectual Property 640 641 The IETF takes no position regarding the validity or scope of any 642 Intellectual Property Rights or other rights that might be claimed to 643 pertain to the implementation or use of the technology described in 644 this document or the extent to which any license under such rights 645 might or might not be available; nor does it represent that it has 646 made any independent effort to identify any such rights. Information 647 on the procedures with respect to rights in RFC documents can be 648 found in BCP 78 and BCP 79. 649 650 Copies of IPR disclosures made to the IETF Secretariat and any 651 assurances of licenses to be made available, or the result of an 652 attempt made to obtain a general license or permission for the use of 653 such proprietary rights by implementers or users of this 654 specification can be obtained from the IETF on-line IPR repository at 655 http://www.ietf.org/ipr. 656 657 The IETF invites any interested party to bring to its attention any 658 copyrights, patents or patent applications, or other proprietary 659 rights that may cover technology that may be required to implement 660 this standard. Please address the information to the IETF at 661 ietf-ipr@ietf.org. 662 663 Acknowledgement 664 665 Funding for the RFC Editor function is provided by the IETF 666 Administrative Support Activity (IASA). 667 668 669 670 671 672 673 674 Sangli, et al. Standards Track [Page 12] 675