idnits 2.17.1 draft-ietf-idr-rfc4893bis-04.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC4893, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2011) is 4666 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 (~~), 3 warnings (==), 2 comments (--). 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: Jan 12, 2012 July 11, 2011 8 BGP Support for Four-octet AS Number Space 9 draft-ietf-idr-rfc4893bis-04.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 January 12, 2012. 34 Copyright Notice 36 Copyright (c) 2011 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. 55 1. Introduction 57 In the base BGP specification [RFC4271] the Autonomous System number 58 is encoded as a two-octet entity. To prepare for the anticipated 59 exhaustion of the two-octet AS numbers, this document describes 60 extensions to BGP to carry the Autonomous System numbers as four- 61 octet entities. 63 More specifically, this document defines a BGP capability, "support 64 for 4-octet AS number capability", to be used by a BGP speaker to 65 indicate its support for the four-octet AS numbers. Two attributes, 66 AS4_PATH and AS4_AGGREGATOR, are introduced that can be used to 67 propagate four-octet based AS path information across BGP speakers 68 that do not support the four-octet AS numbers. This document also 69 specifies mechanisms for constructing the AS path information from 70 the AS_PATH attribute and the AS4_PATH attribute. 72 The extensions specified in this document allow a gradual transition 73 from 2-octet AS numbers to 4-octet AS numbers. 75 2. Specification of Requirements 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 3. Protocol Extensions 83 For the purpose of this document we define a BGP speaker that does 84 not support the new 4-octet AS number extensions as an OLD BGP 85 speaker, and a BGP speaker that supports the new 4-octet AS number 86 extensions as a NEW BGP speaker. 88 BGP carries the Autonomous System numbers in the "My Autonomous 89 System" field of the OPEN message, in the AS_PATH attribute of the 90 UPDATE message, and in the AGGREGATOR attribute of the UPDATE 91 message. BGP also carries the Autonomous System numbers in the BGP 92 Communities attribute. 94 A NEW BGP speaker uses BGP Capability Advertisements [RFC5492] to 95 advertise to its neighbors (either internal or external) that it 96 supports 4-octet AS number extensions, as specified in this document. 98 The Capability that is used by a BGP speaker to convey to its BGP 99 peer the 4-octet Autonomous System number capability, also carries 100 the Autonomous System number (encoded as a 4-octet entity) of the 101 speaker in the Capability Value field of the Capability Optional 102 Parameter. The Capability Length field of the Capability is set to 103 4. 105 The AS path information exchanged between NEW BGP speakers are 106 carried in the existing AS_PATH attribute, except that each AS number 107 in the attribute is encoded as a 4-octet entity (instead of a 2-octet 108 entity). The same applies to the AGGREGATOR attribute - the same 109 attribute is used between NEW BGP speakers, except that the AS number 110 carried in the attribute is encoded as a 4-octet entity. 112 The AS_PATH attribute and the AGGREGATOR attribute carried between a 113 NEW BGP speaker and an OLD BGP speaker will continue to contain 2- 114 octet AS numbers. 116 To preserve the AS path information with 4-octet AS numbers across 117 OLD BGP speakers, this document defines a new AS path attribute, 118 called AS4_PATH. This is an optional transitive attribute that 119 contains the AS path encoded with 4-octet AS numbers. The AS4_PATH 120 attribute has the same semantics as the AS_PATH attribute, except 121 that it is optional transitive, and it carries 4-octet AS numbers. 123 To prevent the possible propagation of confederation path segments 124 outside of a confederation, the path segment types AS_CONFED_SEQUENCE 125 and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH 126 attribute, and MUST NOT be included in the AS4_PATH attribute of an 127 UPDATE message. 129 Similarly, this document defines a new aggregator attribute called 130 AS4_AGGREGATOR, which is optional transitive. The AS4_AGGREGATOR 131 attribute has the same semantics as the AGGREGATOR attribute, except 132 that it carries a 4-octet AS number. 134 Currently assigned 2-octet Autonomous System numbers are converted 135 into 4-octet Autonomous System numbers by setting the two high-order 136 octets of the 4-octet field to zero. Such a 4-octet AS number is 137 said to be mappable to a 2-octet AS number. 139 To represent 4-octet AS numbers (which are not mapped from 2-octets) 140 as 2-octet AS numbers in the AS path information encoded with 2-octet 141 AS numbers, this document reserves a 2-octet AS number. We denote 142 this special AS number as AS_TRANS for ease of description in the 143 rest of this specification. This AS number is also placed in the "My 144 Autonomous System" field of the OPEN message originated by a NEW BGP 145 speaker, if the speaker does not have a (globally unique) 2-octet AS 146 number. 148 4. Operations 150 4.1. Interaction Between NEW BGP Speakers 152 A BGP speaker that supports 4-octet Autonomous System numbers SHALL 153 advertise this to its peers using the BGP Capability Advertisements. 154 The Autonomous System number of the BGP speaker MUST be carried in 155 the capability value field of the "support for 4-octet AS number 156 capability". 158 When a NEW BGP speaker processes an OPEN message from another NEW BGP 159 speaker, it MUST use the Autonomous System number encoded in the 160 Capability Value field of the Capability in lieu of the "My 161 Autonomous System" field of the OPEN message. 163 A BGP speaker that advertises such capability to a particular peer, 164 and receives from that peer the advertisement of such capability MUST 165 encode Autonomous System numbers as 4-octet entities in both the 166 AS_PATH and the AGGREGATOR attributes in the updates it sends to the 167 peer, and MUST assume that these attributes in the updates received 168 from the peer encode Autonomous System numbers as 4-octet entities. 170 The new attributes, AS4_PATH and AS4_AGGREGATOR MUST NOT be carried 171 in an UPDATE message between NEW BGP speakers. A NEW BGP speaker 172 that receives the AS4_PATH attribute or the AS4_AGGREGATOR attribute 173 in an UPDATE message from another NEW BGP speaker MUST discard the 174 path attribute and continue processing the UPDATE message. 176 4.2. Interaction Between NEW and OLD BGP Speakers 178 4.2.1. BGP Peering 180 Note that peering between a NEW BGP speaker and an OLD one is 181 possible only if the NEW BGP speaker has a 2-octet AS number. 182 However, this document does not assume that an Autonomous System with 183 NEW speakers has to have a globally unique 2-octet AS number -- 184 AS_TRANS could be used instead (even if a multiple Autonomous System 185 would use it). 187 4.2.2. Generating Updates 189 When communicating with an OLD BGP speaker, a NEW speaker MUST send 190 the AS path information in the AS_PATH attribute encoded with 2-octet 191 AS numbers. The NEW speaker MUST also send the AS path information 192 in the AS4_PATH attribute (encoded with 4-octet AS numbers), except 193 for the case where the entire AS path information is composed of 2- 194 octet AS numbers only. In this case, the NEW speaker MUST NOT send 195 the AS4_PATH attribute. 197 In the AS_PATH attribute encoded with 2-octet AS numbers, non- 198 mappable 4-octet AS numbers are represented by the well-known 2-octet 199 AS number, AS_TRANS. This will preserve the path length property of 200 the AS path information and also help in updating the AS path 201 information received on a NEW BGP speaker from an OLD speaker, as 202 explained in the next section. 204 The NEW speaker constructs the AS4_PATH attribute from the AS path 205 information. Whenever the AS path information contains the 206 AS_CONFED_SEQUENCE or AS_CONFED_SET path segment, the NEW BGP speaker 207 MUST exclude such path segments from the AS4_PATH attribute being 208 constructed. 210 The AS4_PATH attribute, being optional transitive, will be carried 211 across a series of OLD BGP speakers without modification and will 212 help preserve the non-mappable 4-octet AS numbers in the AS path 213 information. 215 Similarly, if the NEW speaker has to send the AGGREGATOR attribute, 216 and if the aggregating Autonomous System's AS number is a non- 217 mappable 4-octet AS number, then the speaker MUST use the 218 AS4_AGGREGATOR attribute, and set the AS number field in the existing 219 AGGREGATOR attribute to the reserved AS number, AS_TRANS. Note that 220 if the AS number is 2-octets only, then the AS4_AGGREGATOR attribute 221 MUST NOT be sent. 223 4.2.3. Processing Received Updates 225 When a NEW BGP speaker receives an update from an OLD one, it MUST be 226 prepared to receive the AS4_PATH attribute along with the existing 227 AS_PATH attribute. If the AS4_PATH attribute is also received, both 228 the attributes will be used to construct the exact AS path 229 information, and therefore the information carried by both the 230 attributes will be considered for AS path loop detection. 232 Note that a route may have traversed a series of autonomous systems 233 with 2-octet AS numbers and OLD BGP speakers only. In that case, if 234 the route carries the AS4_PATH attribute, this attribute must have 235 remained unmodified since the route left the last NEW BGP speaker. 236 The trailing AS path information (representing autonomous systems 237 with 2-octet AS numbers and OLD BGP speakers only) is contained only 238 in the current AS_PATH attribute (encoded in the leading part of the 239 AS_PATH attribute). 241 Under certain conditions, it may not be possible to reconstruct the 242 entire AS path information from the AS_PATH and the AS4_PATH 243 attributes of a route. This occurs, for example, when two or more 244 routes that carry the AS4_PATH attribute are aggregated by an OLD BGP 245 speaker, and the AS4_PATH attribute of at least one of these routes 246 carries at least one 4-octet AS number (as oppose to a 2-octet AS 247 number that is encoded in 4 octets). Depending on the 248 implementation, either the AS4_PATH attribute would be lost during 249 route aggregation, or both the AS_PATH attribute and the AS4_PATH 250 attribute would contain valid, partial information that cannot be 251 combined seamlessly, resulting in incomplete AS path information in 252 these cases. 254 A NEW BGP speaker MUST also be prepared to receive the AS4_AGGREGATOR 255 attribute along with the AGGREGATOR attribute from an OLD BGP 256 speaker. When both the attributes are received, if the AS number in 257 the AGGREGATOR attribute is not AS_TRANS, then: 259 - the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL 260 be ignored, 262 - the AGGREGATOR attribute SHALL be taken as the information 263 about the aggregating node, and 265 - the AS_PATH attribute SHALL be taken as the AS path 266 information. 268 Otherwise, 270 - the AGGREGATOR attribute SHALL be ignored, 272 - the AS4_AGGREGATOR attribute SHALL be taken as the information 273 about the aggregating node, and 275 - the AS path information would need to be constructed, as in all 276 other cases. 278 In order to construct the AS path information, it would be necessary 279 to first calculate the number of AS numbers in the AS_PATH and 280 AS4_PATH attributes using the method specified in Section 9.1.2.2 282 [RFC4271] and [RFC5065] for route selection. 284 If the number of AS numbers in the AS_PATH attribute is less than the 285 number of AS numbers in the AS4_PATH attribute, then the AS4_PATH 286 attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken 287 as the AS path information. 289 If the number of AS numbers in the AS_PATH attribute is larger than 290 or equal to the number of AS numbers in the AS4_PATH attribute, then 291 the AS path information SHALL be constructed by taking as many AS 292 numbers and path segments as necessary from the leading part of the 293 AS_PATH attribute, and then prepending them to the AS4_PATH attribute 294 so that the AS path information has an identical number of AS numbers 295 as the AS_PATH attribute. Note that a valid AS_CONFED_SEQUENCE or 296 AS_CONFED_SET path segment SHALL be prepended if it is either the 297 leading path segment or adjacent to a path segment that is prepended. 299 5. Handling BGP Communities 301 As specified in [RFC1997], when the high-order two-octets of the 302 community attribute is neither 0x0000 nor 0xffff, these two octets 303 encode the Autonomous System number. Quite clearly this would not 304 work for a NEW BGP speaker with a non-mappable 4-octet AS number. 305 Such BGP speakers should use the Four-octet AS Specific Extended 306 Communities [RFC5668] instead. 308 6. Error Handling 310 Given that the two-octet AS numbers dominate during the transition, 311 and are carried in the AS_PATH attribute by an OLD BGP speaker, in 312 this document the "attribute discard" approach is chosen to handle a 313 malformed AS4_PATH attribute. 315 Similarly, as the AS4_AGGREGATOR is just informational, the 316 "attribute discard" approach is chosen to handle a malformed 317 AS4_AGGREGATOR attribute. 319 The AS4_PATH attribute and AS4_AGGREGATOR attribute MUST NOT be 320 carried in an UPDATE message between NEW BGP speakers. A NEW BGP 321 speaker that receives the AS4_PATH attribute or the AS4_AGGREGATOR 322 attribute in an UPDATE message from another NEW BGP speaker MUST 323 discard the path attribute and continue processing the UPDATE 324 message. This case SHOULD be logged locally for analysis. 326 In addition, the path segment types AS_CONFED_SEQUENCE and 327 AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute 328 of an UPDATE message. A NEW BGP speaker that receives these path 329 segment types in the AS4_PATH attribute of an UPDATE message from an 330 OLD BGP speaker MUST discard these path segments, adjust the relevant 331 attribute fields accordingly, and continue processing the UPDATE 332 message. This case SHOULD be logged locally for analysis. 334 The AS4_PATH attribute in an UPDATE message SHALL be considered 335 malformed under the following conditions: 337 - the attribute length is not a multiple of two, or is too small 338 (i.e., less than 6) for the attribute to carry at least one 339 AS number, or 341 - the path segment length in the attribute is either zero, or 342 is inconsistent with the attribute length, or 344 - the path segment type in the attribute is not one of the 345 types defined: AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE 346 and AS_CONFED_SET. 348 A NEW BGP speaker that receives a malformed AS4_PATH attribute in an 349 UPDATE message from an OLD BGP speaker MUST discard the attribute, 350 and continue processing the UPDATE message. The error SHOULD be 351 logged locally for analysis. 353 The AS4_AGGREGATOR attribute in an UPDATE message SHALL be considered 354 malformed if the attribute length is not 8. 356 A NEW BGP speaker that receives a malformed AS4_AGGREGATOR attribute 357 in an UPDATE message from an OLD BGP speaker MUST discard the 358 attribute, and continue processing the UPDATE message. The error 359 SHOULD be logged locally for analysis. 361 7. Transition 363 The scheme described in this document allows a gradual transition 364 from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one 365 Autonomous System or one BGP speaker at a time. 367 To simplify transition, this document assumes that an Autonomous 368 System could start using a 4-octet AS number only after all the BGP 369 speakers within that Autonomous System have been upgraded to support 370 4-octet AS numbers. 372 A non-mappable 4-octet AS number cannot be used as a "Member AS 373 Number" of a BGP Confederation until all the BGP speakers within the 374 Confederation have transitioned to support 4-octet AS numbers. 376 In an environment where an Autonomous System that has OLD BGP 377 speakers peers with two or more Autonomous Systems that have NEW BGP 378 speakers and use AS_TRANS (rather than having a globally unique AS 379 number), use of Multi-Exit Discriminators by the Autonomous System 380 with the OLD speakers may result in a situation where Multi-Exit 381 Discriminator will influence route selection among the routes that 382 were received from different neighboring Autonomous Systems. 384 Under certain conditions, it may not be possible to reconstruct the 385 entire AS path information from the AS_PATH and the AS4_PATH 386 attributes of a route. This occurs when two or more routes that 387 carry the AS4_PATH attribute are aggregated by an OLD BGP speaker, 388 and the AS4_PATH attribute of at least one of these routes carries at 389 least one 4-octet AS number (as oppose to a 2-octet AS number that is 390 encoded in 4 octets). When such aggregation results in creating a 391 route that is less specific than any of the component routes (route 392 whose Network Layer Reachability Information (NLRI) covers NLRI of 393 all the component routes), loss of the AS path information does not 394 create a risk of a routing loop. In all other cases, loss of the AS 395 path information does create a risk of a routing loop. 397 8. IANA Considerations 399 This document expands the pool for AS numbers from 0 - 65535 to 0 - 400 4294967295. The AS numbers are managed by the IANA "Autonomous 401 System Numbers" registry. Other than expanding the AS number pool, 402 this document does not propose any modifications to the existing 403 policies and procedures pertaining to the AS number allocation. 405 This document uses a BGP Capability code to indicate that a BGP 406 speaker supports the 4-octet AS numbers. The Capability Code 65 has 407 been assigned by IANA per [RFC5492]. 409 In addition, this document introduces two BGP optional transitive 410 attributes, and their type codes have been assigned by the IANA. The 411 first one is the AS4_PATH attribute, value 17, which preserves the AS 412 path information with 4-octet AS numbers across old BGP speakers. 413 The second one is the AS4_AGGREGATOR attribute, value 18, which is 414 similar in use to the current AGGREGATOR attribute, but it carries a 415 4-octet AS number. 417 Finally, this document introduces a reserved 2-octet AS number -- 418 AS_TRANS. The AS number 23456 has been assigned by the IANA for 419 AS_TRANS. 421 9. Security Considerations 423 This extension to BGP does not change the underlying security issues 424 inherent in the existing BGP, except for the following: 426 The inconsistency between the AS_PATH attribute and the AS4_PATH 427 attribute can create loss of the AS path information, and potential 428 routing loops in certain cases as discussed in the document. This 429 could be exploited by an attacker. 431 It is a misconfiguration to assign a non-mappable 4-octet AS number 432 as the "Member AS Number" in a BGP confederation before all the BGP 433 speakers within the confederation have transitioned to support 4- 434 octet AS numbers. Such a misconfiguration would weaken the AS path 435 loop detection within a confederation. 437 10. Acknowledgments 439 The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina, 440 and Jeffrey Haas for the numerous discussions that went into the 441 making of this document. 443 The authors would also like to thank members of the IDR Working Group 444 for their review and comments. 446 11. Normative References 448 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 449 Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 450 2006. 452 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 453 Attribute", RFC 1997, August 1996. 455 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 456 with BGP-4", RFC 5492, February 2009. 458 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 459 System Confederations for BGP", RFC 5065, August 2007. 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, March 1997. 464 [RFC5668] Rekhter, Y., Ramachandra, S., and D. Tappan, "4-Octet AS 465 Specific BGP Extended Community", RFC 5668, October 2009. 467 Appendix A. Comparison with RFC 4893 469 This document includes several editorial changes, and specifies the 470 error handling for the new attributes. 472 12. Authors' Addresses 474 Quaizar Vohra 475 Juniper Networks 476 1194 N. Mathilda Ave. 477 Sunnyvale, CA 94089 478 USA 480 EMail: quaizar.vohra@gmail.com 482 Enke Chen 483 Cisco Systems, Inc. 484 170 W. Tasman Dr. 485 San Jose, CA 95134 486 USA 488 EMail: enkechen@cisco.com