idnits 2.17.1 draft-ietf-idr-rfc4893bis-02.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 (April 5, 2010) is 5135 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: October 6, 2010 April 5, 2010 8 BGP Support for Four-octet AS Number Space 9 draft-ietf-idr-rfc4893bis-02.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 6, 2010. 34 Copyright Notice 36 Copyright (c) 2010 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 Currently the Autonomous System (AS) number is encoded as a two-octet 52 entity in BGP. This document describes extensions to BGP to carry the 53 Autonomous System number as a four-octet entity. 55 1. Introduction 57 Currently the Autonomous System number is encoded as a two-octet 58 entity in BGP [RFC4271]. To prepare for the anticipated exhaustion 59 of the two-octet AS numbers, this document describes extensions to 60 BGP to carry the Autonomous System number as a four-octet entity. 62 More specifically, this document defines a new BGP capability, Four- 63 octet AS Number Capability, that can be used by a BGP speaker to 64 indicate its support for the four-octet AS numbers. Two new 65 attributes, AS4_PATH and AS4_AGGREGATOR, are introduced that can be 66 used to propagate four-octet based AS path information across BGP 67 speakers that do not support the four-octet AS numbers. This 68 document also specifies mechanisms for constructing the AS path 69 information from the AS_PATH attribute and the AS4_PATH attribute. 71 The extensions specified in this document allow a gradual transition 72 from 2-octet AS numbers to 4-octet AS numbers. 74 2. Specification of Requirements 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 3. Protocol Extensions 82 For the purpose of this document we define a BGP speaker that does 83 not support the new 4-octet AS number extensions as an OLD BGP 84 speaker, and a BGP speaker that supports the new 4-octet AS number 85 extensions as a NEW BGP speaker. 87 BGP carries the Autonomous System number in the "My Autonomous 88 System" field of the OPEN message, in the AS_PATH attribute of the 89 UPDATE message, and in the AGGREGATOR attribute of the UPDATE 90 message. BGP also carries the Autonomous System number in the BGP 91 Communities attribute. 93 A NEW BGP speaker uses BGP Capability Advertisements [RFC5492] to 94 advertise to its neighbors (either internal or external) that it 95 supports 4-octet AS number extensions, as specified in this document. 97 The Capability that is used by a BGP speaker to convey to its BGP 98 peer the 4-octet Autonomous System number capability, also carries 99 the Autonomous System number (encoded as a 4-octet entity) of the 100 speaker in the Capability Value field of the Capability Optional 101 Parameter. The Capability Length field of the Capability is set to 102 4. 104 NEW BGP speakers carry AS path information expressed in terms of 4- 105 octet Autonomous Systems numbers by using the existing AS_PATH 106 attribute, except that each AS number in this attribute is encoded 107 not as a 2-octet, but as a 4-octet entity. The same applies to the 108 AGGREGATOR attribute - NEW BGP speakers use the same attribute, 109 except that the AS carried in this attribute is encoded as a 4-octet 110 entity. 112 To preserve AS path information with 4-octet AS numbers across OLD 113 BGP speakers, this document defines a new AS path attribute, called 114 AS4_PATH. This is an optional transitive attribute that contains the 115 AS path encoded with 4-octet AS numbers. The AS4_PATH attribute has 116 the same semantics as the AS_PATH attribute, except that it is 117 optional transitive, and it carries 4-octet AS numbers. 119 To prevent the possible propagation of confederation path segments 120 outside of a confederation, the path segment types AS_CONFED_SEQUENCE 121 and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH 122 attribute, and MUST NOT be carried in an UPDATE message. 124 Similarly, this document defines a new aggregator attribute called 125 AS4_AGGREGATOR, which is optional transitive. The AS4_AGGREGATOR 126 attribute has the same semantics as the AGGREGATOR attribute, except 127 that it carries a 4-octet AS number. 129 Currently assigned 2-octet Autonomous System numbers are converted 130 into 4-octet Autonomous System numbers by setting the two high-order 131 octets of the 4-octet field to zero. Such a 4-octet AS number is 132 said to be mappable to a 2-octet AS number. 134 To represent 4-octet AS numbers (which are not mapped from 2-octets) 135 as 2-octet AS numbers in the AS path information encoded with 2-octet 136 AS numbers, this document reserves a 2-octet AS number. We denote 137 this special AS number as AS_TRANS for ease of description in the 138 rest of this specification. This AS number is also placed in the "My 139 Autonomous System" field of the OPEN message originated by a NEW BGP 140 speaker, if the speaker does not have a (globally unique) 2-octet AS 141 number. 143 4. Operations 145 4.1. Interaction Between NEW BGP Speakers 147 A BGP speaker that supports 4-octet Autonomous System numbers SHOULD 148 advertise this to its peers using the BGP Capability Advertisements. 149 The Autonomous System number of the BGP speaker MUST be carried in 150 the capability value field of the advertised capability. 152 When a NEW BGP speaker processes an OPEN message from another NEW BGP 153 speaker, it MUST use the Autonomous System number encoded in the 154 Capability Value field of the Capability in lieu of the "My 155 Autonomous System" field of the OPEN message. 157 A BGP speaker that advertises such capability to a particular peer, 158 and receives from that peer the advertisement of such capability MUST 159 encode Autonomous System numbers as 4-octet entities in both the 160 AS_PATH and the AGGREGATOR attributes in the updates it sends to the 161 peer, and MUST assume that these attributes in the updates received 162 from the peer encode Autonomous System numbers as 4-octet entities. 164 The new attributes, AS4_PATH and AS4_AGGREGATOR MUST NOT be carried 165 in an UPDATE message between NEW BGP speakers. A NEW BGP speaker 166 that receives the AS4_PATH attribute or the AS4_AGGREGATOR attribute 167 in an UPDATE message from another NEW BGP speaker MUST discard the 168 path attribute and continue processing the UPDATE message. 170 4.2. Interaction Between NEW and OLD BGP Speakers 172 4.2.1. BGP Peering 174 Note that peering between a NEW BGP speaker and an OLD one is 175 possible only if the NEW BGP speaker has a 2-octet AS number. 176 However, this document does not assume that an Autonomous System with 177 NEW speakers has to have a globally unique 2-octet AS number -- 178 AS_TRANS could be used instead (even if a multiple Autonomous System 179 would use it). 181 4.2.2. Generating Updates 183 When communicating with an OLD BGP speaker, a NEW speaker MUST send 184 the AS path information in the AS_PATH attribute encoded with 2-octet 185 AS numbers. The NEW speaker MUST also send the AS path information 186 in the AS4_PATH attribute (encoded with 4-octet AS numbers), except 187 for the case where the entire AS path information is composed of 2- 188 octet AS numbers only. In this case, the NEW speaker MUST NOT send 189 the AS4_PATH attribute. 191 In the AS_PATH attribute encoded with 2-octet AS numbers, non- 192 mappable 4-octet AS numbers are represented by the well-known 2-octet 193 AS number, AS_TRANS. This will preserve the path length property of 194 the AS path information and also help in updating the AS path 195 information received on a NEW BGP speaker from an OLD speaker, as 196 explained in the next section. 198 The NEW speaker constructs the AS4_PATH attribute from the AS path 199 information. In the case where the AS path information contains 200 either AS_CONFED_SEQUENCE or AS_CONFED_SET path segments, the NEW 201 speaker, when constructing the AS4_PATH attribute from the AS path 202 information, MUST exclude such path segments. The AS4_PATH attribute 203 will be carried across a series of OLD BGP speakers without 204 modification and will help preserve the non-mappable 4-octet AS 205 numbers in the AS path information. 207 Similarly, if the NEW speaker has to send the AGGREGATOR attribute, 208 and if the aggregating Autonomous System's AS number is a non- 209 mappable 4-octet AS number, then the speaker MUST use the 210 AS4_AGGREGATOR attribute, and set the AS number field in the existing 211 AGGREGATOR attribute to the reserved AS number, AS_TRANS. Note that 212 if the AS number is 2-octets only, then the AS4_AGGREGATOR attribute 213 MUST NOT be sent. 215 4.2.3. Processing Received Updates 217 When a NEW BGP speaker receives an update from an OLD one, it should 218 be prepared to receive the AS4_PATH attribute along with the existing 219 AS_PATH attribute. If the AS4_PATH attribute is also received, both 220 the attributes will be used to construct the exact AS path 221 information, and therefore the information carried by both the 222 attributes will be considered for AS path loop detection. 224 Note that a route may have traversed a series of autonomous systems 225 with 2-octet AS numbers and OLD BGP speakers only. In that case, if 226 the route carries the AS4_PATH attribute, this attribute must have 227 remained unmodified since the route left the last NEW BGP speaker. 228 The trailing AS path information (representing autonomous systems 229 with 2-octet AS numbers and OLD BGP speakers only) is contained only 230 in the current AS_PATH attribute (encoded in the leading part of the 231 AS_PATH attribute). 233 Under certain conditions, it may not be possible to reconstruct the 234 entire AS path information from the AS_PATH and the AS4_PATH 235 attributes of a route. This occurs when two or more routes that 236 carry the AS4_PATH attribute are aggregated by an OLD BGP speaker, 237 and the AS4_PATH attribute of at least one of these routes carries at 238 least one 4-octet AS number (as oppose to a 2-octet AS number that is 239 encoded in 4 octets). Depending on the implementation, either the 240 AS4_PATH attribute would be lost during route aggregation, or both 241 the AS_PATH attribute and the AS4_PATH attribute would contain valid, 242 partial information that cannot be combined seamlessly, resulting in 243 incomplete AS path information in these cases. 245 A NEW BGP speaker should also be prepared to receive the 246 AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an 247 OLD BGP speaker. When both the attributes are received, if the AS 248 number in the AGGREGATOR attribute is not AS_TRANS, then: 250 - the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL 251 be ignored, 253 - the AGGREGATOR attribute SHALL be taken as the information 254 about the aggregating node, and 256 - the AS_PATH attribute SHALL be taken as the AS path 257 information. 259 Otherwise, 261 - the AGGREGATOR attribute SHALL be ignored, 263 - the AS4_AGGREGATOR attribute SHALL be taken as the information 264 about the aggregating node, and 266 - the AS path information would need to be constructed, as in all 267 other cases. 269 In order to construct the AS path information, it would be necessary 270 to first calculate the number of AS numbers in the AS_PATH and 271 AS4_PATH attributes using the method specified in Section 9.1.2.2 272 [RFC4271] and [RFC5065] for route selection. 274 If the number of AS numbers in the AS_PATH attribute is less than the 275 number of AS numbers in the AS4_PATH attribute, then the AS4_PATH 276 attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken 277 as the AS path information. 279 If the number of AS numbers in the AS_PATH attribute is larger than 280 or equal to the number of AS numbers in the AS4_PATH attribute, then 281 the AS path information SHALL be constructed by taking as many AS 282 numbers and path segments as necessary from the leading part of the 283 AS_PATH attribute, and then prepending them to the AS4_PATH attribute 284 so that the AS path information has an identical number of AS numbers 285 as the AS_PATH attribute. Note that a valid AS_CONFED_SEQUENCE or 286 AS_CONFED_SET path segment SHALL be prepended if it is either the 287 leading path segment or adjacent to a path segment that is prepended. 289 5. Handling BGP Communities 291 As specified in [RFC1997], when the high-order two-octets of the 292 community attribute is neither 0x0000 nor 0xffff, these two octets 293 encode the Autonomous System number. Quite clearly this would not 294 work for a NEW BGP speaker with a non-mappable 4-octet AS number. 295 Such BGP speakers should use the Four-octet AS Specific Extended 296 Communities [RFC5668] instead. 298 6. Error Handling 300 The general guidelines presented in [OPT-TRANS] apply to the error 301 handling of the AS4_PATH and AS4_AGGREGATOR attributes introduced in 302 this document. It is noted, however, that the nature (i.e., NEW 303 speaker or OLD speaker) of a direct neighbor based on the 304 announcement of the 4-octet AS Capability allows a local speaker to 305 determine unequivocally whether the direct neighbor recognizes these 306 new attributes. Thus there is no need to examine the the attribute 307 flags (somewhat weaker indicator in this case) for that 308 determination. 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 An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System 373 number. 375 A non-mappable 4-octet AS number cannot be used as a "Member AS 376 Number" of a BGP Confederation until all the BGP speakers within the 377 Confederation have transitioned to support 4-octet AS numbers. 379 In an environment where an Autonomous System that has OLD BGP 380 speakers peers with two or more Autonomous Systems that have NEW BGP 381 speakers and use AS_TRANS (rather than having a globally unique AS 382 number), use of Multi-Exit Discriminators by the Autonomous System 383 with the OLD speakers may result in a situation where Multi-Exit 384 Discriminator will influence route selection among the routes that 385 were received from different neighboring Autonomous Systems. 387 Under certain conditions, it may not be possible to reconstruct the 388 entire AS path information from the AS_PATH and the AS4_PATH 389 attributes of a route. This occurs when two or more routes that 390 carry the AS4_PATH attribute are aggregated by an OLD BGP speaker, 391 and the AS4_PATH attribute of at least one of these routes carries at 392 least one 4-octet AS number (as oppose to a 2-octet AS number that is 393 encoded in 4 octets). When such aggregation results in creating a 394 route that is less specific than any of the component routes (route 395 whose Network Layer Reachability Information (NLRI) covers NLRI of 396 all the component routes), loss of the AS path information does not 397 create a risk of a routing loop. In all other cases, loss of the AS 398 path information does create a risk of a routing loop. 400 8. IANA Considerations 402 This document expands the pool for AS numbers from 0 - 65535 to 0 - 403 4294967295. The AS numbers are managed by the IANA "Autonomous 404 System Numbers" registry. Other than expanding the AS number pool, 405 this document does not propose any modifications to the existing 406 policies and procedures pertaining to the AS number allocation. 408 This document uses a BGP Capability code to indicate that a BGP 409 speaker supports the 4-octet AS numbers. The Capability Code 65 has 410 been assigned by IANA per [RFC5492]. 412 In addition, this document introduces two new BGP optional transitive 413 attributes, and their type codes have been assigned by the IANA. The 414 first one is the AS4_PATH attribute, value 17, which preserves the AS 415 path information with 4-octet AS numbers across old BGP speakers. 416 The second one is the AS4_AGGREGATOR attribute, value 18, which is 417 similar in use to the current AGGREGATOR attribute, but it carries a 418 4-octet AS number. 420 Finally, this document introduces a reserved 2-octet AS number -- 421 AS_TRANS. The AS number 23456 has been assigned by the IANA for 422 AS_TRANS. 424 9. Security Considerations 426 This extension to BGP does not change the underlying security issues 427 inherent in the existing BGP, except for the following: 429 The inconsistency between the AS_PATH attribute and the AS4_PATH 430 attribute can create loss of the AS path information, and potential 431 routing loops in certain cases as discussed in the document. This 432 could be exploited by an attacker. 434 It is a misconfiguration to assign a non-mappable 4-octet AS number 435 as the "Member AS Number" in a BGP confederation before all the BGP 436 speakers within the confederation have transitioned to support 4- 437 octet AS numbers. Such a misconfiguration would weaken the AS path 438 loop detection within a confederation. 440 10. Acknowledgments 442 The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina, 443 and Jeffrey Haas for the numerous discussions that went into the 444 making of this document. 446 The authors would also like to thank members of the IDR Working Group 447 for their review and comments. 449 11. References 451 11.1. Normative References 453 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 454 Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 455 2006. 457 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 458 Attribute", RFC 1997, August 1996. 460 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 461 with BGP-4", RFC 5492, February 2009. 463 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 464 System Confederations for BGP", RFC 5065, August 2007. 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, March 1997. 469 11.2. Informative References 471 [RFC5668] Rekhter, Y., Ramachandra, S., and D. Tappan, "4-Octet AS 472 Specific BGP Extended Community", RFC 5668, October 2009. 474 [OPT-TRANS] Scudder, J. and E. Chen, "Error Handling for Optional 475 Transitive BGP Attributes", Work in Progress, March 2010. 477 Appendix A. Comparison with RFC 4893 479 This document includes several minor editorial changes, and specifies 480 the error handling for the new attributes. 482 12. Authors' Addresses 484 Quaizar Vohra 485 Juniper Networks 486 1194 N. Mathilda Ave. 487 Sunnyvale, CA 94089 489 EMail: quaizar.vohra@gmail.com 491 Enke Chen 492 Cisco Systems, Inc. 493 170 W. Tasman Dr. 494 San Jose, CA 95134 496 EMail: enkechen@cisco.com