idnits 2.17.1 draft-ietf-idr-bgp-ext-communities-08.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 3667, Section 5.1 on line 36. -- Found old boilerplate from RFC 3978, Section 5.5 on line 59. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 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: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.5 boilerplate, a section with a similar start was also found: This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 MER-CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. == Line 98 has weird spacing: '...es with the E...' == Line 389 has weird spacing: '...tribute as de...' == Line 549 has weird spacing: '...for the purpo...' -- 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 498, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Missing Reference: 'RFC2026' is mentioned on line 515, but not defined == Unused Reference: 'BGP-4' is defined on line 571, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) Summary: 14 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Srihari R. Sangli (Cisco Systems) 3 Internet Draft Daniel Tappan (Cisco Systems) 4 Expiration Date: August 2005 Yakov Rekhter (Juniper Networks) 6 BGP Extended Communities Attribute 8 draft-ietf-idr-bgp-ext-communities-08.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 IPR Disclosure Acknowledgement 33 By submitting this Internet-Draft, I certify that any applicable 34 patent or other IPR claims of which I am aware have been disclosed, 35 and any of which I become aware will be disclosed, in accordance with 36 RFC 3668. 38 Copyright Notice 40 Copyright (C) The Internet Society (year). This document is subject 41 to the rights, licenses and restrictions contained in BCP 78, and 42 except as set forth therein, the authors retain all their rights. 44 Additional copyright notices are not permitted in IETF Documents 45 except in the case where such document is the product of a joint 46 development effort between the IETF and another standards development 47 organization or the document is a republication of the work of 48 another standards organization. Such exceptions must be approved on 49 an individual basis by the IAB. 51 Disclaimer 53 This document and the information contained herein are provided on an 54 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 55 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 56 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 57 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 58 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 59 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 61 Abstract 63 This document describes an extension to BGP-4 which may be used to 64 provide flexible control over the distribution of routing 65 information. 67 Specification of Requirements 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [RFC2119]. 73 1. Introduction 75 The Extended Community Attribute provides two important enhancements 76 over the existing BGP Community Attribute: 78 - It provides an extended range, ensuring that communities can be 79 assigned for a plethora of uses, without fear of overlap. 81 - The addition of a Type field provides structure for the 82 community space. 84 The addition of structure allows the usage of policy based on the 85 application for which the community value will be used. For example, 86 one can filter out all communities of a particular type, or allow 87 only certain values for a particular type of community. It also 88 allows one to specify whether a particular community is transitive or 89 non-transitive across Autonomous system boundary. Without structure, 90 this can only be accomplished by explicitly enumerating all community 91 values which will be denied or allowed and passed to BGP speakers in 92 neighboring ASes based on the transitive property. 94 2. BGP Extended Communities Attribute 96 The Extended Communities Attribute is a transitive optional BGP 97 attribute, with the Type Code 16. The attribute consists of a set of 98 "extended communities". All routes with the Extended Communities 99 attribute belong to the communities listed in the attribute. 101 Each Extended Community is encoded as an eight octet quantity, as 102 follows: 104 - Type Field : 1 or 2 octets 105 - Value Field : Remaining octets 107 0 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Type high | Type low(*) | | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | 112 | | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 *) Present for Extended types only, used for the Value field 116 otherwise 117 Type Field: 119 Two classes of Type Field are introduced: Regular type and 120 Extended type. 122 The size of Type Field for Regular types is 1 octet and the 123 size of the Type Field for Extended types is 2 octets. 125 The value of the high-order octet of the Type Field determines 126 if an extended community is a Regular type or an Extended type. 128 The high-order octet of the Type Field is as shown below: 130 0 1 2 3 4 5 6 7 131 +-+-+-+-+-+-+-+-+ 132 |I|T| | 133 +-+-+-+-+-+-+-+-+ 135 I - IANA authority bit 137 Value 0: IANA assignable type using the "First Come First 138 Serve" policy 140 Value 1: IANA assignable type using the IETF Consensus 141 policy and experimental 143 T - Transitive bit 145 Value 0: The community is transitive across ASes 147 Value 1: The community is non-transitive across ASes 149 Remaining 6 bits: Indicates the structure of the community 151 Value Field: 153 The encoding of the Value Field is dependent on the "type" of 154 the community as specified by the Type Field. 156 Two extended communities are declared equal only when all 8 octets of 157 their encoding are equal. 159 The two members in the tuple should be enumerated to 160 specify any community value. Based on the value of the Type field, 161 the remaining octets of the community should be interpreted. 163 3. Defined BGP Extended Community Types 165 This section introduces a few extended types and defines the format 166 of the Value Field for those types. The types introduced here provide 167 "templates", where each template is identified by the high order 168 octet of the extended community Type field, and the lower order octet 169 (sub-type) is used to indicate a particular type of extended commu- 170 nity. 172 3.1. Two-octet AS specific extended community 174 This is an extended type with Type Field comprising of 2 octets and 175 Value Field comprising of 6 octets. 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | 0x00 or 0x40 | Sub-Type | Global Administrator | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Local Administrator | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 The value of the high-order octet of this extended type is either 186 0x00 or 0x40. The low-order octet of this extended type is used to 187 indicate sub-types. 189 The Value Field consists of two sub-fields: 191 Global Administrator sub-field: 2 octets 193 This sub-field contains an Autonomous System number assigned by 194 IANA. 196 Local Administrator sub-field: 4 octets 198 The organization identified by Autonomous System number in the 199 Global Administrator sub-field, can encode any information in 200 this sub-field. The format and meaning of the value encoded in 201 this sub-field should be defined by the sub-type of the commu- 202 nity. 204 3.2. IPv4 address specific extended community 206 This is an extended type with Type Field comprising of 2 octets and 207 Value Field comprising of 6 octets. 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | 0x01 or 0x41 | Sub-Type | Global Administrator | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Global Administrator (cont.) | Local Administrator | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 The value of the high-order octet of this extended type is either 218 0x01 or 0x41. The low-order octet of this extended type is used to 219 indicate sub-types. 221 The Value field consists of two sub-fields: 223 Global Administrator sub-field: 4 octets 225 This sub-field contains an IPv4 address assigned by IANA. 227 Local Administrator sub-field: 2 octets 229 The organization which has been assigned the IPv4 address in 230 the Global Administrator sub-field, can encode any information 231 in this sub-field. The format and meaning of this value 232 encoded in this sub-field should be defined by the sub-type of 233 the community. 235 3.3. Four-octet AS specific extended community 237 This is an extended type with Type Field comprising of 2 octets and 238 Value Field comprising of 6 octets. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | 0x02 or 0x42 | Sub-Type | Global Administrator | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Global Administrator (cont.) | Local Administrator | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 The value of the high-order octet of this extended type is either 248 0x02 or 0x42. The low-order octet of this extended type is used to 249 indicate sub-types. 251 The Value Field consists of two sub-fields: 253 Global Administrator sub-field: 4 octets 255 This sub-field contains a 4-octets Autonomous System number 256 assigned by IANA. 258 Local Administrator sub-field: 2 octets 260 The organization identified by Autonomous System number in the 261 Global Administrator sub-field, can encode any information in 262 this sub-field. The format and meaning of the value encoded in 263 this sub-field should be defined by the sub-type of the commu- 264 nity. 266 3.4. Opaque extended community 268 This is an extended type with Type Field comprising of 2 octets and 269 Value Field comprising of 6 octets. 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | 0x03 or 0x43 | Sub-Type | Value | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Value (cont.) | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 The value of the high-order octet of this extended type is either 280 0x03 or 0x43. The low-order octet of this extended type is used to 281 indicate sub-types. 283 This is a generic community of extended type. The value of the sub- 284 type which should define the Value Field is to be assigned by IANA. 286 4. Route Target Community 288 The Route Target Community identifies one or more routers that may 289 receive a set of routes (that carry this Community) carried by BGP. 290 This is transitive across the Autonomous system boundary. 292 The Route Target Community is of an extended type. 294 The value of the high-order octet of the Type field for the Route 295 Target Community can be 0x00, 0x01 or 0x02. The value of the low- 296 order octet of the Type field for this community is 0x02. 298 When the value of the high-order octet of the Type field is 0x00 or 299 0x02, the Local Administrator sub-field contains a number from a num- 300 bering space which is administered by the organization to which the 301 Autonomous System number carried in the Global Administrator subfield 302 has been assigned by an appropriate authority. 304 When the value of the high-order octet of the Type field is 0x01, the 305 Local Administrator sub-field contains a number from a numbering 306 space which is administered by the organization to which the IP 307 address carried in the Global Administrator subfield has been 308 assigned by an appropriate authority. 310 5. Route Origin Community 312 The Route Origin Community identifies one or more routers that inject 313 a set of routes (that carry this Community) into BGP. This is transi- 314 tive across the Autonomous system boundary. 316 The Route Origin Community is of an extended type. 318 The value of the high-order octet of the Type field for the Route 319 Origin Community can be 0x00, 0x01 or 0x02. The value of the low- 320 order octet of the Type field for this community is 0x03. 322 When the value of the high-order octet of the Type field is 0x00 or 323 0x02, the Local Administrator sub-field contains a number from a num- 324 bering space which is administered by the organization to which the 325 Autonomous System number carried in the Global Administrator subfield 326 has been assigned by an appropriate authority. 328 When the value of the high-order octet of the Type field is 0x01, the 329 Local Administrator sub-field contains a number from a numbering 330 space which is administered by the organization to which the IP 331 address carried in the Global Administrator subfield has been 332 assigned by an appropriate authority. 334 6. Link Bandwidth Community 336 When a router receives a route from a directly connected external 337 neighbor (the external neighbor that is one IP hop away), and adver- 338 tises this route (via IBGP) to internal neighbors, as part of this 339 advertisement the router may carry the bandwidth of the link that 340 connects the router with the external neighbor. The bandwidth of such 341 a link is carried in the Link Bandwidth Community. 343 The Link Bandwidth Community is of an extended type. 345 The value of the high-order octet of the Type Field is 0x00. The 346 value of the low-order octet of the Type field for this community is 347 0x04. 349 The value of the Global Administrator sub-field in the Value Field 350 MUST represent the Autonomous System of the router that attaches the 351 Link Bandwidth Community. 353 The bandwidth of the link is expressed as 4 octets in IEEE floating 354 point format, units being bytes per second. It is carried in the 355 Local Administrator sub-field of the Value Field. 357 7. Operations 359 A BGP speaker may use the Extended Communities attribute to control 360 which routing information it accepts or distributes to its peers. 362 The Extended Community attribute MUST NOT be used to modify the BGP 363 best path selection algorithm in a way that leads to forwarding 364 loops. 366 A BGP speaker receiving a route that doesn't have the Extended Commu- 367 nities attribute MAY append this attribute to the route when propa- 368 gating it to its peers. 370 A BGP speaker receiving a route with the Extended Communities 371 attribute MAY modify this attribute according to the local policy. 373 By default if a range of routes is to be aggregated and the resultant 374 aggregates path attributes do not carry the ATOMIC_AGGREGATE 375 attribute, then the resulting aggregate should have an Extended Com- 376 munities path attribute which contains the set union of all the 377 Extended Communities from all of the aggregated routes. The default 378 behavior could be overriden via local configuration, in which case 379 handling the Extended Communities attribute in the presence of route 380 aggregation becomes a matter of the local policy of the BGP speaker 381 that performs the aggregation. 383 If a route has a non-transitivity extended community, then before 384 advertising the route across the Autonomous system boundary the com- 385 munity SHOULD be removed from the route. However, the community 386 SHOULD NOT be removed when advertising the route across the BGP Con- 387 federation boundary. 389 A route may carry both the BGP Communities attribute as defined in 390 [RFC1997]), and the Extended BGP Communities attribute. In this case 391 the BGP Communities attribute is handled as specified in [RFC1997], 392 and the Extended BGP Communities attribute is handled as specified in 393 this document. 395 8. IANA Considerations 397 All the BGP Extended Communities contain a Type field for which IANA 398 is to create and maintain a registry entitled BGP Extended Communi- 399 ties Type. 401 The Type could be either regular or extended. For a regular Type the 402 IANA allocates an 8-bits value; for an extended Type the IANA allo- 403 cates a 16-bits value. 405 The value allocated for a regular Type MUST NOT be reused as the 406 value of the high-order octet when allocating an extended Type. The 407 value of the high-order octet allocated for an extended Type MUST NOT 408 be reused when allocating a regular Type. 410 The Type field indicates where the Extended Community is transitive 411 or not. 413 Future assignment are to be made using either the Standards Action 414 process defined in [RFC2434], or the Early IANA Allocation process 415 defined in [kompella-zinin], or the "First Come First Served" policy 416 defined in [RFC2434]. 418 The following table summarizes the ranges for the assignment of 419 Types: 421 Type Standard Action First Come 422 Early IANA Allocation First Served 423 ------------------ --------------------- ------------ 425 regular, transitive 0x90-0xbf 0x00-x3f 427 regular, non-transitive 0xd0-0xff 0x40-0x7f 428 extended, transitive 0x9000-0xbfff 0x0000-0x3fff 430 extended, non-transitive 0xd000-0xffff 0x4000-0x7fff 432 Assignments consist of a name and the value. 434 The Type values 0x80-0x8f and 0xc0-0xcf for regular Types, and 435 0x8000-0x8fff and 0xc000-0xcfff for extended Types are experimental, 436 and are not to be assigned by IANA. 438 This document defines a class of extended communities called two- 439 octet AS specific extended community for which the IANA is to create 440 and maintain a registry entitled Two-octet AS Specific Extended Com- 441 munity. All the communities in this class are of extended Types. 442 Future assignment are to be made using the "First Come First Served" 443 policy defined in [RFC2434]. The Type values for the transitive com- 444 munities of the two-octet AS specific extended community class are 445 0x0000-0x00ff, and for the non-transitive communities of that class 446 are 0x4000-0x40ff. Assignments consist of a name and the value. 448 This document makes the following assignments for the two-octet AS 449 specific extended community: 451 Name Type Value 452 ---- ---------- 453 two-octet AS specific Route Target 0x0002 454 two-octet AS specific Route Origin 0x0003 455 two-octet AS specific Link Bandwidth 0x0004 457 This document defines a class of extended communities called IPv4 458 address specific extended community for which the IANA is to create 459 and maintain a registry entitled IPv4 Address Specific Extended 460 Community. All the communities in this class are of extended Types. 461 Future assignment are to be made using the "First Come First Served" 462 policy defined in [RFC2434]. The Type values for the transitive 463 communities of the two-octet AS specific extended community class 464 are 0x0100-0x01ff, and for the non-transitive communities of that 465 class are 0x4100-0x41ff. Assignments consist of a name and the 466 value. 468 This document makes the following assignments for the IPv4 address 469 specific extended community: 471 Name Type Value 472 ---- ---------- 473 IPv4 address specific Route Target 0x0102 474 IPv4 address specific Route Origin 0x0103 475 This document defines a class of extended communities called 476 four-octet AS specific extended community for which the IANA is to 477 create and maintain a registry entitled Four-octet AS Specific 478 Extended Community. All the communities in this class are of 479 extended Types. Future assignment are to be made using the "First 480 Come First Served" policy defined in [RFC2434]. The Type values for 481 the transitive communities of the two-octet AS specific extended 482 community class are 0x0200-0x02ff, and for the non-transitive 483 communities of that class are 0x4200-0x42ff. Assignments consist 484 of a name and the value. 486 This document makes the following assignments for the four-octet 487 AS specific extended community: 489 Name Type Value 490 ---- ---------- 491 four-octet AS specific Route Target 0x0202 492 four-octet AS specific Route Origin 0x0203 494 This document defines a class of extended communities called opaque 495 extended community for which the IANA is to create and maintain a 496 registry entitled Opaque Extended Community. All the communities 497 in this class are of extended Types. Future assignment are to be 498 made using the "First Come First Served" policy defined in [RFC2434]. 499 The Type values for the transitive communities of the opaque extended 500 community class are 0x0300-0x03ff, and for the non-transitive 501 communities of that class are 0x4300-0x43ff. Assignments consist 502 of a name and the value. 504 When requesting an allocation from more than one registry defined 505 above, one may ask for allocating the same Type value from 506 these registries. If possible, the IANA should accommodate such 507 requests. 509 9. Security Considerations 511 This extension to BGP does not change the underlying security issues. 513 10. Intellectual Property Considerations 515 This section is taken from Section 10.4 of [RFC2026]. 517 The IETF takes no position regarding the validity or scope of any 518 intellectual property or other rights that might be claimed to per- 519 tain to the implementation or use of the technology described in this 520 document or the extent to which any license under such rights might 521 or might not be available; neither does it represent that it has made 522 any effort to identify any such rights. Information on the IETF's 523 procedures with respect to rights in standards-track and standards- 524 related documentation can be found in BCP-11. Copies of claims of 525 rights made available for publication and any assurances of licenses 526 to be made available, or the result of an attempt made to obtain a 527 general license or permission for the use of such proprietary rights 528 by implementors or users of this specification can be obtained from 529 the IETF Secretariat. 531 The IETF invites any interested party to bring to its attention any 532 copyrights, patents or patent applications, or other proprietary 533 rights which may cover technology that may be required to practice 534 this standard. Please address the information to the IETF Executive 535 Director. 537 11. Copyright Notice 539 Copyright (C) The Internet Society (date). All Rights Reserved. 541 This document and translations of it may be copied and furnished to 542 others, and derivative works that comment on or otherwise explain it 543 or assist in its implmentation may be prepared, copied, published and 544 distributed, in whole or in part, without restriction of any kind, 545 provided that the above copyright notice and this paragraph are 546 included on all such copies and derivative works. However, this doc- 547 ument itself may not be modified in any way, such as by removing the 548 copyright notice or references to the Internet Society or other 549 Internet organizations, except as needed for the purpose of develop- 550 ing Internet standards in which case the procedures for copyrights 551 defined in the Internet Standards process must be followed, or as 552 required to translate it into languages other than English. 554 The limited permissions granted above are perpetual and will not be 555 revoked by the Internet Society or its successors or assigns. 557 This document and the information contained herein is provided on an 558 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 559 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 560 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 561 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 562 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 564 12. Acknowledgements 566 The authors would like to thank John Hawkinson, Jeffrey Haas, Bruno 567 Rijsman, and Alex Zinin for their suggestions and feedback. 569 13. Normative References 571 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 572 (BGP-4)", RFC 1771, March 1995. 574 [RFC1997] Chandra, R., Traina, P., Li, T., "BGP Communities 575 Attribute", RFC1997, August 1996. 577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 578 Requirement Levels", BCP 14, RFC 2119, March 1997. 580 14. Author Information 582 Srihari R. Sangli 583 Cisco Systems, Inc. 585 Dan Tappan 586 Cisco Systems, Inc. 587 250 Apollo Drive 588 Chelmsford, MA 01824 589 e-mail: tappan@cisco.com 591 Yakov Rekhter 592 Juniper Networks, Inc. 593 1194 N. Mathilda Ave 594 Sunnyvale, CA 94089 595 e-mail: yakov@juniper.net