idnits 2.17.1 draft-ietf-idr-rfc4893bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 13, 2012) is 4395 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Vohra 3 Internet Draft Juniper Networks 4 Obsoletes: 4893 (if approved) E. Chen 5 Intended Status: Standards Track Cisco Systems 6 Expiration Date: Oct 14, 2012 April 13, 2012 8 BGP Support for Four-octet AS Number Space 9 draft-ietf-idr-rfc4893bis-05.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on October 14, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 The Autonomous System (AS) number is encoded as a two-octet entity in 52 the base BGP specification. This document describes extensions to BGP 53 to carry the Autonomous System numbers as four-octet entities. This 54 document obsoletes RFC 4893. 56 1. Introduction 58 In the base BGP specification [RFC4271] the Autonomous System number 59 is encoded as a two-octet entity. To prepare for the anticipated 60 exhaustion of the two-octet AS numbers, this document describes 61 extensions to BGP to carry the Autonomous System numbers as four- 62 octet entities. 64 More specifically, this document defines a BGP capability, "support 65 for 4-octet AS number capability", to be used by a BGP speaker to 66 indicate its support for the four-octet AS numbers. Two attributes, 67 AS4_PATH and AS4_AGGREGATOR, are introduced that can be used to 68 propagate four-octet based AS path information across BGP speakers 69 that do not support the four-octet AS numbers. This document also 70 specifies mechanisms for constructing the AS path information from 71 the AS_PATH attribute and the AS4_PATH attribute. 73 The extensions specified in this document allow a gradual transition 74 from 2-octet AS numbers to 4-octet AS numbers. 76 2. Specification of Requirements 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 3. Protocol Extensions 84 For the purpose of this document we define a BGP speaker that does 85 not support the new 4-octet AS number extensions as an OLD BGP 86 speaker, and a BGP speaker that supports the new 4-octet AS number 87 extensions as a NEW BGP speaker. 89 BGP carries the Autonomous System numbers in the "My Autonomous 90 System" field of the OPEN message, in the AS_PATH attribute of the 91 UPDATE message, and in the AGGREGATOR attribute of the UPDATE 92 message. BGP also carries the Autonomous System numbers in the BGP 93 Communities attribute. 95 A NEW BGP speaker uses BGP Capability Advertisements [RFC5492] to 96 advertise to its neighbors (either internal or external) that it 97 supports 4-octet AS number extensions, as specified in this document. 99 The Capability that is used by a BGP speaker to convey to its BGP 100 peer the 4-octet Autonomous System number capability, also carries 101 the Autonomous System number (encoded as a 4-octet entity) of the 102 speaker in the Capability Value field of the Capability Optional 103 Parameter. The Capability Length field of the Capability is set to 104 4. 106 The AS path information exchanged between NEW BGP speakers are 107 carried in the existing AS_PATH attribute, except that each AS number 108 in the attribute is encoded as a 4-octet entity (instead of a 2-octet 109 entity). The same applies to the AGGREGATOR attribute - the same 110 attribute is used between NEW BGP speakers, except that the AS number 111 carried in the attribute is encoded as a 4-octet entity. 113 The AS_PATH attribute and the AGGREGATOR attribute carried between a 114 NEW BGP speaker and an OLD BGP speaker will continue to contain 115 2-octet AS numbers. 117 To preserve the AS path information with 4-octet AS numbers across 118 OLD BGP speakers, this document defines a new AS path attribute, 119 called AS4_PATH. This is an optional transitive attribute that 120 contains the AS path encoded with 4-octet AS numbers. The AS4_PATH 121 attribute has the same semantics as the AS_PATH attribute, except 122 that it is optional transitive, and it carries 4-octet AS numbers. 124 To prevent the possible propagation of confederation path segments 125 outside of a confederation, the path segment types AS_CONFED_SEQUENCE 126 and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH 127 attribute, and MUST NOT be included in the AS4_PATH attribute of an 128 UPDATE message. 130 Similarly, this document defines a new aggregator attribute called 131 AS4_AGGREGATOR, which is optional transitive. The AS4_AGGREGATOR 132 attribute has the same semantics as the AGGREGATOR attribute, except 133 that it carries a 4-octet AS number. 135 Currently assigned 2-octet Autonomous System numbers are converted 136 into 4-octet Autonomous System numbers by setting the two high-order 137 octets of the 4-octet field to zero. Such a 4-octet AS number is 138 said to be mappable to a 2-octet AS number. 140 To represent 4-octet AS numbers (which are not mapped from 2-octets) 141 as 2-octet AS numbers in the AS path information encoded with 2-octet 142 AS numbers, this document reserves a 2-octet AS number. We denote 143 this special AS number as AS_TRANS for ease of description in the 144 rest of this specification. This AS number is also placed in the "My 145 Autonomous System" field of the OPEN message originated by a NEW BGP 146 speaker, if the speaker does not have a (globally unique) 2-octet AS 147 number. 149 4. Operations 151 4.1. Interaction Between NEW BGP Speakers 153 A BGP speaker that supports 4-octet Autonomous System numbers SHALL 154 advertise this to its peers using the BGP Capability Advertisements. 155 The Autonomous System number of the BGP speaker MUST be carried in 156 the capability value field of the "support for 4-octet AS number 157 capability". 159 When a NEW BGP speaker processes an OPEN message from another NEW BGP 160 speaker, it MUST use the Autonomous System number encoded in the 161 Capability Value field of the Capability in lieu of the "My 162 Autonomous System" field of the OPEN message. 164 A BGP speaker that advertises such capability to a particular peer, 165 and receives from that peer the advertisement of such capability MUST 166 encode Autonomous System numbers as 4-octet entities in both the 167 AS_PATH and the AGGREGATOR attributes in the updates it sends to the 168 peer, and MUST assume that these attributes in the updates received 169 from the peer encode Autonomous System numbers as 4-octet entities. 171 The new attributes, AS4_PATH and AS4_AGGREGATOR MUST NOT be carried 172 in an UPDATE message between NEW BGP speakers. A NEW BGP speaker 173 that receives the AS4_PATH attribute or the AS4_AGGREGATOR attribute 174 in an UPDATE message from another NEW BGP speaker MUST discard the 175 path attribute and continue processing the UPDATE message. 177 4.2. Interaction Between NEW and OLD BGP Speakers 179 4.2.1. BGP Peering 181 Note that peering between a NEW BGP speaker and an OLD one is 182 possible only if the NEW BGP speaker has a 2-octet AS number. 183 However, this document does not assume that an Autonomous System with 184 NEW speakers has to have a globally unique 2-octet AS number -- 185 AS_TRANS could be used instead (even if a multiple Autonomous System 186 would use it). 188 4.2.2. Generating Updates 190 When communicating with an OLD BGP speaker, a NEW speaker MUST send 191 the AS path information in the AS_PATH attribute encoded with 2-octet 192 AS numbers. The NEW speaker MUST also send the AS path information 193 in the AS4_PATH attribute (encoded with 4-octet AS numbers), except 194 for the case where the entire AS path information is composed of 195 2-octet AS numbers only. In this case, the NEW speaker MUST NOT send 196 the AS4_PATH attribute. 198 In the AS_PATH attribute encoded with 2-octet AS numbers, non- 199 mappable 4-octet AS numbers are represented by the well-known 2-octet 200 AS number, AS_TRANS. This will preserve the path length property of 201 the AS path information and also help in updating the AS path 202 information received on a NEW BGP speaker from an OLD speaker, as 203 explained in the next section. 205 The NEW speaker constructs the AS4_PATH attribute from the AS path 206 information. Whenever the AS path information contains the 207 AS_CONFED_SEQUENCE or AS_CONFED_SET path segment, the NEW BGP speaker 208 MUST exclude such path segments from the AS4_PATH attribute being 209 constructed. 211 The AS4_PATH attribute, being optional transitive, will be carried 212 across a series of OLD BGP speakers without modification and will 213 help preserve the non-mappable 4-octet AS numbers in the AS path 214 information. 216 Similarly, if the NEW speaker has to send the AGGREGATOR attribute, 217 and if the aggregating Autonomous System's AS number is a non- 218 mappable 4-octet AS number, then the speaker MUST use the 219 AS4_AGGREGATOR attribute, and set the AS number field in the existing 220 AGGREGATOR attribute to the reserved AS number, AS_TRANS. Note that 221 if the AS number is 2-octets only, then the AS4_AGGREGATOR attribute 222 MUST NOT be sent. 224 4.2.3. Processing Received Updates 226 When a NEW BGP speaker receives an update from an OLD one, it MUST be 227 prepared to receive the AS4_PATH attribute along with the existing 228 AS_PATH attribute. If the AS4_PATH attribute is also received, both 229 the attributes will be used to construct the exact AS path 230 information, and therefore the information carried by both the 231 attributes will be considered for AS path loop detection. 233 Note that a route may have traversed a series of autonomous systems 234 with 2-octet AS numbers and OLD BGP speakers only. In that case, if 235 the route carries the AS4_PATH attribute, this attribute must have 236 remained unmodified since the route left the last NEW BGP speaker. 237 The trailing AS path information (representing autonomous systems 238 with 2-octet AS numbers and OLD BGP speakers only) is contained only 239 in the current AS_PATH attribute (encoded in the leading part of the 240 AS_PATH attribute). 242 Under certain conditions, it may not be possible to reconstruct the 243 entire AS path information from the AS_PATH and the AS4_PATH 244 attributes of a route. This occurs, for example, when two or more 245 routes that carry the AS4_PATH attribute are aggregated by an OLD BGP 246 speaker, and the AS4_PATH attribute of at least one of these routes 247 carries at least one 4-octet AS number (as oppose to a 2-octet AS 248 number that is encoded in 4 octets). Depending on the 249 implementation, either the AS4_PATH attribute would be lost during 250 route aggregation, or both the AS_PATH attribute and the AS4_PATH 251 attribute would contain valid, partial information that cannot be 252 combined seamlessly, resulting in incomplete AS path information in 253 these cases. 255 A NEW BGP speaker MUST also be prepared to receive the AS4_AGGREGATOR 256 attribute along with the AGGREGATOR attribute from an OLD BGP 257 speaker. When both the attributes are received, if the AS number in 258 the AGGREGATOR attribute is not AS_TRANS, then: 260 - the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL 261 be ignored, 263 - the AGGREGATOR attribute SHALL be taken as the information 264 about the aggregating node, and 266 - the AS_PATH attribute SHALL be taken as the AS path 267 information. 269 Otherwise, 271 - the AGGREGATOR attribute SHALL be ignored, 273 - the AS4_AGGREGATOR attribute SHALL be taken as the information 274 about the aggregating node, and 276 - the AS path information would need to be constructed, as in all 277 other cases. 279 In order to construct the AS path information, it would be necessary 280 to first calculate the number of AS numbers in the AS_PATH and 281 AS4_PATH attributes using the method specified in Section 9.1.2.2 283 [RFC4271] and [RFC5065] for route selection. 285 If the number of AS numbers in the AS_PATH attribute is less than the 286 number of AS numbers in the AS4_PATH attribute, then the AS4_PATH 287 attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken 288 as the AS path information. 290 If the number of AS numbers in the AS_PATH attribute is larger than 291 or equal to the number of AS numbers in the AS4_PATH attribute, then 292 the AS path information SHALL be constructed by taking as many AS 293 numbers and path segments as necessary from the leading part of the 294 AS_PATH attribute, and then prepending them to the AS4_PATH attribute 295 so that the AS path information has an identical number of AS numbers 296 as the AS_PATH attribute. Note that a valid AS_CONFED_SEQUENCE or 297 AS_CONFED_SET path segment SHALL be prepended if it is either the 298 leading path segment or adjacent to a path segment that is prepended. 300 5. Handling BGP Communities 302 As specified in [RFC1997], when the high-order two-octets of the 303 community attribute is neither 0x0000 nor 0xffff, these two octets 304 encode the Autonomous System number. Quite clearly this would not 305 work for a NEW BGP speaker with a non-mappable 4-octet AS number. 306 Such BGP speakers should use the Four-octet AS Specific Extended 307 Communities [RFC5668] instead. 309 6. Error Handling 311 Given that the two-octet AS numbers dominate during the transition, 312 and are carried in the AS_PATH attribute by an OLD BGP speaker, in 313 this document the "attribute discard" approach is chosen to handle a 314 malformed AS4_PATH attribute. 316 Similarly, as the AS4_AGGREGATOR is just informational, the 317 "attribute discard" approach is chosen to handle a malformed 318 AS4_AGGREGATOR attribute. 320 The AS4_PATH attribute and AS4_AGGREGATOR attribute MUST NOT be 321 carried in an UPDATE message between NEW BGP speakers. A NEW BGP 322 speaker that receives the AS4_PATH attribute or the AS4_AGGREGATOR 323 attribute in an UPDATE message from another NEW BGP speaker MUST 324 discard the path attribute and continue processing the UPDATE 325 message. This case SHOULD be logged locally for analysis. 327 In addition, the path segment types AS_CONFED_SEQUENCE and 328 AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute 329 of an UPDATE message. A NEW BGP speaker that receives these path 330 segment types in the AS4_PATH attribute of an UPDATE message from an 331 OLD BGP speaker MUST discard these path segments, adjust the relevant 332 attribute fields accordingly, and continue processing the UPDATE 333 message. This case SHOULD be logged locally for analysis. 335 The AS4_PATH attribute in an UPDATE message SHALL be considered 336 malformed under the following conditions: 338 - the attribute length is not a multiple of two, or is too small 339 (i.e., less than 6) for the attribute to carry at least one 340 AS number, or 342 - the path segment length in the attribute is either zero, or 343 is inconsistent with the attribute length, or 345 - the path segment type in the attribute is not one of the 346 types defined: AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE 347 and AS_CONFED_SET. 349 A NEW BGP speaker that receives a malformed AS4_PATH attribute in an 350 UPDATE message from an OLD BGP speaker MUST discard the attribute, 351 and continue processing the UPDATE message. The error SHOULD be 352 logged locally for analysis. 354 The AS4_AGGREGATOR attribute in an UPDATE message SHALL be considered 355 malformed if the attribute length is not 8. 357 A NEW BGP speaker that receives a malformed AS4_AGGREGATOR attribute 358 in an UPDATE message from an OLD BGP speaker MUST discard the 359 attribute, and continue processing the UPDATE message. The error 360 SHOULD be logged locally for analysis. 362 7. Transition 364 The scheme described in this document allows a gradual transition 365 from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one 366 Autonomous System or one BGP speaker at a time. 368 To simplify transition, this document assumes that an Autonomous 369 System could start using a 4-octet AS number only after all the BGP 370 speakers within that Autonomous System have been upgraded to support 371 4-octet AS numbers. 373 A non-mappable 4-octet AS number cannot be used as a "Member AS 374 Number" of a BGP Confederation until all the BGP speakers within the 375 Confederation have transitioned to support 4-octet AS numbers. 377 In an environment where an Autonomous System that has OLD BGP 378 speakers peers with two or more Autonomous Systems that have NEW BGP 379 speakers and use AS_TRANS (rather than having a globally unique AS 380 number), use of Multi-Exit Discriminators by the Autonomous System 381 with the OLD speakers may result in a situation where Multi-Exit 382 Discriminator will influence route selection among the routes that 383 were received from different neighboring Autonomous Systems. 385 Under certain conditions, it may not be possible to reconstruct the 386 entire AS path information from the AS_PATH and the AS4_PATH 387 attributes of a route. This occurs when two or more routes that 388 carry the AS4_PATH attribute are aggregated by an OLD BGP speaker, 389 and the AS4_PATH attribute of at least one of these routes carries at 390 least one 4-octet AS number (as oppose to a 2-octet AS number that is 391 encoded in 4 octets). When such aggregation results in creating a 392 route that is less specific than any of the component routes (route 393 whose Network Layer Reachability Information (NLRI) covers NLRI of 394 all the component routes), loss of the AS path information does not 395 create a risk of a routing loop. In all other cases, loss of the AS 396 path information does create a risk of a routing loop. 398 8. IANA Considerations 400 This document expands the pool for AS numbers from 0 - 65535 to 0 - 401 4294967295. The AS numbers are managed by the IANA "Autonomous 402 System Numbers" registry. Other than expanding the AS number pool, 403 this document does not propose any modifications to the existing 404 policies and procedures pertaining to the AS number allocation. 406 This document uses a BGP Capability code to indicate that a BGP 407 speaker supports the 4-octet AS numbers. The Capability Code 65 has 408 been assigned by IANA per [RFC5492]. 410 In addition, this document introduces two BGP optional transitive 411 attributes, and their type codes have been assigned by the IANA. The 412 first one is the AS4_PATH attribute, value 17, which preserves the AS 413 path information with 4-octet AS numbers across old BGP speakers. 414 The second one is the AS4_AGGREGATOR attribute, value 18, which is 415 similar in use to the current AGGREGATOR attribute, but it carries a 416 4-octet AS number. 418 Finally, this document introduces a reserved 2-octet AS number -- 419 AS_TRANS. The AS number 23456 has been assigned by the IANA for 420 AS_TRANS. 422 9. Security Considerations 424 This extension to BGP does not change the underlying security issues 425 inherent in the existing BGP, except for the following: 427 The inconsistency between the AS_PATH attribute and the AS4_PATH 428 attribute can create loss of the AS path information, and potential 429 routing loops in certain cases as discussed in the document. This 430 could be exploited by an attacker. 432 It is a misconfiguration to assign a non-mappable 4-octet AS number 433 as the "Member AS Number" in a BGP confederation before all the BGP 434 speakers within the confederation have transitioned to support 435 4-octet AS numbers. Such a misconfiguration would weaken the AS path 436 loop detection within a confederation. 438 10. Acknowledgments 440 The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina, 441 and Jeffrey Haas for the numerous discussions that went into the 442 making of this document. 444 The authors would also like to thank members of the IDR Working Group 445 for their review and comments. 447 11. Normative References 449 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 450 Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 451 2006. 453 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 454 Attribute", RFC 1997, August 1996. 456 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 457 with BGP-4", RFC 5492, February 2009. 459 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 460 System Confederations for BGP", RFC 5065, August 2007. 462 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 463 Requirement Levels", BCP 14, RFC 2119, March 1997. 465 [RFC5668] Rekhter, Y., Ramachandra, S., and D. Tappan, "4-Octet AS 466 Specific BGP Extended Community", RFC 5668, October 2009. 468 Appendix A. Comparison with RFC 4893 470 This document includes several clarifications and editorial changes, 471 and specifies the error handling for the new attributes. 473 12. Authors' Addresses 475 Quaizar Vohra 476 Juniper Networks 477 1194 N. Mathilda Ave. 478 Sunnyvale, CA 94089 479 USA 481 EMail: quaizar.vohra@gmail.com 483 Enke Chen 484 Cisco Systems, Inc. 485 170 W. Tasman Dr. 486 San Jose, CA 95134 487 USA 489 EMail: enkechen@cisco.com