idnits 2.17.1 draft-ietf-idr-rfc4893bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 17, 2009) is 5486 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: 1 error (**), 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 18, 2009 April 17, 2009 8 BGP Support for Four-octet AS Number Space 9 draft-ietf-idr-rfc4893bis-00.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 18, 2009. 34 Copyright Notice 36 Copyright (c) 2009 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 in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Currently the Autonomous System (AS) number is encoded as a two-octet 48 entity in BGP. This document describes extensions to BGP to carry the 49 Autonomous System number as a four-octet entity. 51 1. Introduction 53 Currently the Autonomous System number is encoded as a two-octet 54 entity in BGP [BGP]. To prepare for the anticipated exhaustion of 55 the two-octet AS numbers, this document describes extensions to BGP 56 to carry the Autonomous System number as a four-octet entity. 58 More specifically, this document defines a new BGP capability, Four- 59 octet AS Number Capability, that can be used by a BGP speaker to 60 indicate its support for the four-octet AS numbers. Two new 61 attributes, AS4_PATH and AS4_AGGREGATOR, are introduced that can be 62 used to propagate four-octet based AS path information across BGP 63 speakers that do not support the four-octet AS numbers. This 64 document also specifies mechanisms for constructing the AS path 65 information from the AS_PATH attribute and the AS4_PATH attribute. 67 The extensions proposed in this document allow a gradual transition 68 from 2-octet AS numbers to 4-octet AS numbers. 70 2. Specification of Requirements 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 3. Protocol Extensions 78 For the purpose of this document we define a BGP speaker that does 79 not support the new 4-octet AS number extensions as an OLD BGP 80 speaker, and a BGP speaker that supports the new 4-octet AS number 81 extensions as a NEW BGP speaker. 83 BGP carries the Autonomous System number in the "My Autonomous 84 System" field of the OPEN message, in the AS_PATH attribute of the 85 UPDATE message, and in the AGGREGATOR attribute of the UPDATE 86 message. BGP also carries the Autonomous System number in the BGP 87 Communities attribute. 89 A NEW BGP speaker uses BGP Capability Advertisements [RFC5492] to 90 advertise to its neighbors (either internal or external) that it 91 supports 4-octet AS number extensions, as specified in this document. 93 The Capability that is used by a BGP speaker to convey to its BGP 94 peer the 4-octet Autonomous System number capability, also carries 95 the Autonomous System number (encoded as a 4-octet entity) of the 96 speaker in the Capability Value field of the Capability Optional 97 Parameter. The Capability Length field of the Capability is set to 98 4. 100 NEW BGP speakers carry AS path information expressed in terms of 4- 101 octet Autonomous Systems numbers by using the existing AS_PATH 102 attribute, except that each AS number in this attribute is encoded 103 not as a 2-octet, but as a 4-octet entity. The same applies to the 104 AGGREGATOR attribute - NEW BGP speakers use the same attribute, 105 except that the AS carried in this attribute is encoded as a 4-octet 106 entity. 108 To preserve AS path information with 4-octet AS numbers across OLD 109 BGP speakers, this document defines a new AS path attribute, called 110 AS4_PATH. This is an optional transitive attribute that contains the 111 AS path encoded with 4-octet AS numbers. The AS4_PATH attribute has 112 the same semantics as the AS_PATH attribute, except that it is 113 optional transitive, and it carries 4-octet AS numbers. 115 To prevent the possible propagation of confederation path segments 116 outside of a confederation, the path segment types AS_CONFED_SEQUENCE 117 and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH 118 attribute, and MUST NOT be carried in an UPDATE message. 120 Similarly, this document defines a new aggregator attribute called 121 AS4_AGGREGATOR, which is optional transitive. The AS4_AGGREGATOR 122 attribute has the same semantics as the AGGREGATOR attribute, except 123 that it carries a 4-octet AS number. 125 Currently assigned 2-octet Autonomous System numbers are converted 126 into 4-octet Autonomous System numbers by setting the two high-order 127 octets of the 4-octet field to zero. Such a 4-octet AS number is 128 said to be mappable to a 2-octet AS number. 130 To represent 4-octet AS numbers (which are not mapped from 2-octets) 131 as 2-octet AS numbers in the AS path information encoded with 2-octet 132 AS numbers, this document reserves a 2-octet AS number. We denote 133 this special AS number as AS_TRANS for ease of description in the 134 rest of this specification. This AS number is also placed in the "My 135 Autonomous System" field of the OPEN message originated by a NEW BGP 136 speaker, if the speaker does not have a (globally unique) 2-octet AS 137 number. 139 4. Operations 141 4.1. Interaction Between NEW BGP Speakers 143 A BGP speaker that supports 4-octet Autonomous System numbers SHOULD 144 advertise this to its peers using the BGP Capability Advertisements. 145 The Autonomous System number of the BGP speaker MUST be carried in 146 the capability value field of the advertised capability. 148 When a NEW BGP speaker processes an OPEN message from another NEW BGP 149 speaker, it MUST use the Autonomous System number encoded in the 150 Capability Value field of the Capability in lieu of the "My 151 Autonomous System" field of the OPEN message. 153 A BGP speaker that advertises such capability to a particular peer, 154 and receives from that peer the advertisement of such capability MUST 155 encode Autonomous System numbers as 4-octet entities in both the 156 AS_PATH and the AGGREGATOR attributes in the updates it sends to the 157 peer, and MUST assume that these attributes in the updates received 158 from the peer encode Autonomous System numbers as 4-octet entities. 160 The new attributes, AS4_PATH and AS4_AGGREGATOR MUST NOT be carried 161 in an UPDATE message between NEW BGP speakers. A NEW BGP speaker 162 that receives the AS4_PATH attribute or the AS4_AGGREGATOR attribute 163 in an UPDATE message from another NEW BGP speaker MUST discard the 164 path attribute and continue processing the UPDATE message. 166 4.2. Interaction Between NEW and OLD BGP Speakers 168 4.2.1. BGP Peering 170 Note that peering between a NEW BGP speaker and an OLD one is 171 possible only if the NEW BGP speaker has a 2-octet AS number. 172 However, this document does not assume that an Autonomous System with 173 NEW speakers has to have a globally unique 2-octet AS number -- 174 AS_TRANS could be used instead (even if a multiple Autonomous System 175 would use it). 177 4.2.2. Generating Updates 179 When communicating with an OLD BGP speaker, a NEW speaker MUST send 180 the AS path information in the AS_PATH attribute encoded with 2-octet 181 AS numbers. The NEW speaker MUST also send the AS path information 182 in the AS4_PATH attribute (encoded with 4-octet AS numbers), except 183 for the case where the entire AS path information is composed of 2- 184 octet AS numbers only. In this case, the NEW speaker MUST NOT send 185 the AS4_PATH attribute. 187 In the AS_PATH attribute encoded with 2-octet AS numbers, non- 188 mappable 4-octet AS numbers are represented by the well-known 2-octet 189 AS number, AS_TRANS. This will preserve the path length property of 190 the AS path information and also help in updating the AS path 191 information received on a NEW BGP speaker from an OLD speaker, as 192 explained in the next section. 194 The NEW speaker constructs the AS4_PATH attribute from the 195 information carried in the AS_PATH attribute. In the case where the 196 AS_PATH attribute contains either AS_CONFED_SEQUENCE or AS_CONFED_SET 197 path segments, the NEW speaker, when constructing the AS4_PATH 198 attribute from the AS_PATH attribute, MUST exclude such path 199 segments. The AS4_PATH attribute will be carried across a series of 200 OLD BGP speakers without modification and will help preserve the 201 non-mappable 4-octet AS numbers in the AS path information. 203 Similarly, if the NEW speaker has to send the AGGREGATOR attribute, 204 and if the aggregating Autonomous System's AS number is a non- 205 mappable 4-octet AS number, then the speaker MUST use the 206 AS4_AGGREGATOR attribute, and set the AS number field in the existing 207 AGGREGATOR attribute to the reserved AS number, AS_TRANS. Note that 208 if the AS number is 2-octets only, then the AS4_AGGREGATOR attribute 209 MUST NOT be sent. 211 4.2.3. Processing Received Updates 213 When a NEW BGP speaker receives an update from an OLD one, it should 214 be prepared to receive the AS4_PATH attribute along with the existing 215 AS_PATH attribute. If the AS4_PATH attribute is also received, both 216 the attributes will be used to construct the exact AS path 217 information, and therefore the information carried by both the 218 attributes will be considered for AS path loop detection. 220 Note that a route may have traversed a series of autonomous systems 221 with 2-octet AS numbers and OLD BGP speakers only. In that case, if 222 the route carries the AS4_PATH attribute, this attribute must have 223 remained unmodified since the route left the last NEW BGP speaker. 224 The trailing AS path information (representing autonomous systems 225 with 2-octet AS numbers and OLD BGP speakers only) is contained only 226 in the current AS_PATH attribute (encoded in the leading part of the 227 AS_PATH attribute). 229 Under certain conditions, it may not be possible to reconstruct the 230 entire AS path information from the AS_PATH and the AS4_PATH 231 attributes of a route. This occurs when two or more routes that 232 carry the AS4_PATH attribute are aggregated by an OLD BGP speaker, 233 and the AS4_PATH attribute of at least one of these routes carries at 234 least one 4-octet AS number (as oppose to a 2-octet AS number that is 235 encoded in 4 octets). Depending on the implementation, either the 236 AS4_PATH attribute would be lost during route aggregation, or both 237 the AS_PATH attribute and the AS4_PATH attribute would contain valid, 238 partial information that cannot be combined seamlessly, resulting in 239 incomplete AS path information in these cases. 241 A NEW BGP speaker should also be prepared to receive the 242 AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an 243 OLD BGP speaker. When both the attributes are received, if the AS 244 number in the AGGREGATOR attribute is not AS_TRANS, then: 246 - the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL 247 be ignored, 249 - the AGGREGATOR attribute SHALL be taken as the information 250 about the aggregating node, and 252 - the AS_PATH attribute SHALL be taken as the AS path 253 information. 255 Otherwise, 257 - the AGGREGATOR attribute SHALL be ignored, 259 - the AS4_AGGREGATOR attribute SHALL be taken as the information 260 about the aggregating node, and 262 - the AS path information would need to be constructed, as in all 263 other cases. 265 In order to construct the AS path information, it would be necessary 266 to first calculate the number of AS numbers in the AS_PATH and 267 AS4_PATH attributes using the method specified in Section 9.1.2.2 268 [BGP] and [RFC5065] for route selection. 270 If the number of AS numbers in the AS_PATH attribute is less than the 271 number of AS numbers in the AS4_PATH attribute, then the AS4_PATH 272 attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken 273 as the AS path information. 275 If the number of AS numbers in the AS_PATH attribute is larger than 276 or equal to the number of AS numbers in the AS4_PATH attribute, then 277 the AS path information SHALL be constructed by taking as many AS 278 numbers and path segments as necessary from the leading part of the 279 AS_PATH attribute, and then prepending them to the AS4_PATH attribute 280 so that the AS path information has an identical number of AS numbers 281 as the AS_PATH attribute. Note that a valid AS_CONFED_SEQUENCE or 282 AS_CONFED_SET path segment SHALL be prepended if it is either the 283 leading path segment or adjacent to a path segment that is prepended. 285 5. Handling BGP Communities 287 As specified in [RFC1997], when the high-order two-octets of the 288 community attribute is neither 0x0000 nor 0xffff, these two octets 289 encode the Autonomous System number. Quite clearly this would not 290 work for a NEW BGP speaker with a non-mappable 4-octet AS number. 291 Such BGP speakers should use the Four-octet AS Specific Extended 292 Communities [AS-EXT-COM] instead. 294 6. Error Handling 296 The general guidelines presented in [OPT-ATTR-E] apply to the error 297 handling of the AS4_PATH and AS4_AGGREGATOR attributes introduced in 298 this document. In this section we also take into consideration the 299 fact that these new attributes are neither sourced nor validated by 300 an OLD BGP speaker. 302 The AS4_PATH attribute and AS4_AGGREGATOR attribute MUST NOT be 303 carried in an UPDATE message between NEW BGP speakers. A NEW BGP 304 speaker that receives the AS4_PATH attribute or the AS4_AGGREGATOR 305 attribute in an UPDATE message from another NEW BGP speaker MUST 306 discard the path attribute and continue processing the UPDATE 307 message. This case SHOULD be logged locally for analysis. 309 In addition, the path segment types AS_CONFED_SEQUENCE and 310 AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute 311 of an UPDATE message. A NEW BGP speaker that receives these path 312 segment types in the AS4_PATH attribute of an UPDATE message from an 313 OLD BGP speaker MUST discard these path segments, adjust the relevant 314 attribute fields accordingly, and continue processing the UPDATE 315 message. This case SHOULD be logged locally for analysis. 317 The AS4_PATH attribute in an UPDATE message SHALL be considered 318 malformed under the following conditions: 320 - the attribute length is not a multiple of two, or is 321 inconsistent with the "Total Path Attribute Length" in the 322 UPDATE message, or 324 - the path segment length in the attribute is either zero, or 325 is inconsistent with the attribute length, or 327 - the path segment type in the attribute is not one of the 328 types defined: AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE 329 and AS_CONFED_SET. 331 A NEW BGP speaker that receives a malformed AS4_PATH attribute in an 332 UPDATE message from an OLD BGP speaker MUST discard the attribute, 333 and continue processing the UPDATE message. The error SHOULD be 334 logged locally for analysis. 336 The AS4_AGGREGATOR attribute in an UPDATE message SHALL be considered 337 malformed if the attribute length is not 8. 339 A NEW BGP speaker that receives a malformed AS4_AGGREGATOR attribute 340 in an UPDATE message from an OLD BGP speaker MUST discard the 341 attribute, and continue processing the UPDATE message. The error 342 SHOULD be logged locally for analysis. 344 7. Transition 346 The scheme described in this document allows a gradual transition 347 from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one 348 Autonomous System or one BGP speaker at a time. 350 To simplify transition, this document assumes that an Autonomous 351 System could start using a 4-octet AS number only after all the BGP 352 speakers within that Autonomous System have been upgraded to support 353 4-octet AS numbers. 355 An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System 356 number. 358 A non-mappable 4-octet AS number cannot be used as a "Member AS 359 Number" of a BGP Confederation until all the BGP speakers within the 360 Confederation have transitioned to support 4-octet AS numbers. 362 In an environment where an Autonomous System that has OLD BGP 363 speakers peers with two or more Autonomous Systems that have NEW BGP 364 speakers and use AS_TRANS (rather than having a globally unique AS 365 number), use of Multi-Exit Discriminators by the Autonomous System 366 with the OLD speakers may result in a situation where Multi-Exit 367 Discriminator will influence route selection among the routes that 368 were received from different neighboring Autonomous Systems. 370 Under certain conditions, it may not be possible to reconstruct the 371 entire AS path information from the AS_PATH and the AS4_PATH 372 attributes of a route. This occurs when two or more routes that 373 carry the AS4_PATH attribute are aggregated by an OLD BGP speaker, 374 and the AS4_PATH attribute of at least one of these routes carries at 375 least one 4-octet AS number (as oppose to a 2-octet AS number that is 376 encoded in 4 octets). When such aggregation results in creating a 377 route that is less specific than any of the component routes (route 378 whose Network Layer Reachability Information (NLRI) covers NLRI of 379 all the component routes), loss of the AS path information does not 380 create a risk of a routing loop. In all other cases, loss of the AS 381 path information does create a risk of a routing loop. 383 8. IANA Considerations 385 This document expands the pool for AS numbers from 0 - 65535 to 0 - 386 4294967295. The AS numbers are managed by the IANA "Autonomous 387 System Numbers" registry. Other than expanding the AS number pool, 388 this document does not propose any modifications to the existing 389 policies and procedures pertaining to the AS number allocation. 391 This document uses a BGP Capability code to indicate that a BGP 392 speaker supports the 4-octet AS numbers. The Capability Code 65 has 393 been assigned by IANA per [RFC5492]. 395 In addition, this document introduces two new BGP optional transitive 396 attributes, and their type codes have been assigned by the IANA. The 397 first one is the AS4_PATH attribute, value 17, which preserves the AS 398 path information with 4-octet AS numbers across old BGP speakers. 399 The second one is the AS4_AGGREGATOR attribute, value 18, which is 400 similar in use to the current AGGREGATOR attribute, but it carries a 401 4-octet AS number. 403 Finally, this document introduces a reserved 2-octet AS number -- 404 AS_TRANS. The AS number 23456 has been assigned by the IANA for 405 AS_TRANS. 407 9. Security Considerations 409 This extension to BGP does not change the underlying security issues 410 inherent in the existing BGP, except for the following: 412 The inconsistency between the AS_PATH attribute and the AS4_PATH 413 attribute can create loss of the AS path information, and potential 414 routing loops in certain cases as discussed in the document. This 415 could be exploited by an attacker. 417 It is a misconfiguration to assign a non-mappable 4-octet AS number 418 as the "Member AS Number" in a BGP confederation before all the BGP 419 speakers within the confederation have transitioned to support 4- 420 octet AS numbers. Such a misconfiguration would weaken the AS path 421 loop detection within a confederation. 423 10. Acknowledgments 425 The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina, 426 and Jeffrey Haas for the numerous discussions that went into the 427 making of this document. 429 11. References 431 11.1. Normative References 433 [BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 434 Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 435 2006. 437 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 438 Attribute", RFC 1997, August 1996. 440 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 441 with BGP-4", RFC 5492, February 2009. 443 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 444 System Confederations for BGP", RFC 5065, August 2007. 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, March 1997. 449 11.2. Informative References 451 [AS-EXT-COM] Rekhter, Y., Ramachandra, S., and D. Tappan, "Four-octet 452 AS Specific BGP Extended Community", Work in Progress, 453 November 2008. 455 [OPT-ATTR-E] Scudder, J. and E. Chen, "Error Handling for Optional 456 Transitive BGP Attributes", Work in Progress, April 457 2009. 459 Appendix A. Comparison with RFC 4893 461 This document includes several minor editorial changes, and specifies 462 the error handling for the new attributes. 464 12. Authors' Addresses 466 Quaizar Vohra 467 Juniper Networks 468 1194 N. Mathilda Ave. 469 Sunnyvale, CA 94089 471 EMail: quaizar.vohra@gmail.com 473 Enke Chen 474 Cisco Systems, Inc. 475 170 W. Tasman Dr. 476 San Jose, CA 95134 478 EMail: enkechen@cisco.com