idnits 2.17.1 draft-ietf-idr-as4bytes-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 420. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 404. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 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 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'AS-EXT-COMM' is mentioned on line 262, but not defined == Unused Reference: 'AS-EXT-COM' is defined on line 362, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2842 (Obsoleted by RFC 3392) ** Obsolete normative reference: RFC 3065 (Obsoleted by RFC 5065) == Outdated reference: A later version (-03) exists of draft-rekhter-as4octet-ext-community-00 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Quaizar Vohra 3 Internet Draft Nuova Systems 4 Expiration Date: July 2007 Enke Chen 5 Cisco Systems 7 BGP Support for Four-octet AS Number Space 9 draft-ietf-idr-as4bytes-13.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 Currently the Autonomous System number is encoded as a two-octet 37 entity in BGP. This document describes extensions to BGP to carry the 38 Autonomous System number as a four-octet entity. 40 1. Introduction 42 Currently the Autonomous System number is encoded as a two-octet 43 entity in BGP [BGP]. To prepare for the anticipated exhaustion of 44 the two-octet AS numbers, this document describes extensions to BGP 45 to carry the Autonomous System number as a four-octet entity. 47 More specifically, this document defines a new BGP capability, Four- 48 octet AS Number Capability, that can be used by a BGP speaker to 49 indicate its support for the four-octet AS numbers. Two new 50 attributes, AS4_PATH and AS4_AGGREGATOR, are introduced that can be 51 used to propagate four-octet based AS path information across BGP 52 speakers that do not support the four-octet AS numbers. This document 53 also specifies mechanisms for constructing the AS path information 54 from the AS_PATH attribute and the AS4_PATH attribute. 56 The extensions proposed in this document allow a gradual transition 57 from 2-octet AS numbers to 4-octet AS numbers. 59 2. Specification of Requirements 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 3. Protocol Extensions 67 For the purpose of this document we define a BGP speaker which does 68 not support the new 4-octet AS number extensions as an OLD BGP 69 speaker, and a BGP speaker which supports the new 4-octet AS number 70 extensions as a NEW BGP speaker. 72 BGP carries the Autonomous System number in the "My Autonomous 73 System" field of the OPEN message, in the AS_PATH attribute of the 74 UPDATE message, and in the AGGREGATOR attribute of the UPDATE 75 message. BGP also carries the Autonomous System number in the BGP 76 Communities attribute. 78 A NEW BGP speaker uses BGP Capability Advertisements [RFC2842] to 79 advertise to its neighbors (either internal or external) that it 80 supports 4-octet AS number extensions, as specified in this document. 82 The Capability that is used by a BGP speaker to convey to its BGP 83 peer the 4-octet Autonomous System number capability, also carries 84 the 4-octet Autonomous System number of the speaker in the Capability 85 Value field of the Capability Optional Parameter. The Capability 86 Length field of the Capability is set to 4. 88 NEW BGP speakers carry AS path information expressed in terms of 89 4-octet Autonomous Systems numbers by using the existing AS_PATH 90 attribute, except that each AS number in this attribute is encoded 91 not as a 2-octet, but as a 4-octet entity. The same applies to the 92 AGGREGATOR attribute - NEW BGP speakers use the same attribute, 93 except that the AS carried in this attribute is encoded as a 4-octet 94 entity. 96 To preserve AS path information with 4-octet AS numbers across OLD 97 BGP speakers, this document defines a new AS path attribute, called 98 AS4_PATH. This is an optional transitive attribute that contains the 99 AS path encoded with 4-octet AS numbers. The AS4_PATH attribute has 100 the same semantics as the AS_PATH attribute, except that it is 101 optional transitive, and it carries 4-octet AS numbers. 103 To prevent the possible propagation of confederation path segments 104 outside of a confederation, the path segment types AS_CONFED_SEQUENCE 105 and AS_CONFED_SET [RFC3065] are declared invalid for the AS4_PATH 106 attribute. 108 Similarly, this document defines a new aggregator attribute called 109 AS4_AGGREGATOR, which is optional transitive. The AS4_AGGREGATOR 110 attribute has the same semantics as the AGGREGATOR attribute, except 111 that it carries a 4-octet AS number. 113 Currently assigned 2-octet Autonomous System numbers are converted 114 into 4-octet Autonomous System numbers by setting the two high-order 115 octets of the 4-octet field to zero. Such a 4-octet AS number is said 116 to be mappable to a 2-octet AS number. 118 To represent 4-octet AS numbers (which are not mapped from 2-octets) 119 as 2-octet AS numbers in the AS path information encoded with 2-octet 120 AS numbers, this document reserves a 2-octet AS number. We denote 121 this special AS number as AS_TRANS for ease of description in the 122 rest of this specification. This AS number is also placed in the "My 123 Autonomous System" field of the OPEN message originated by a NEW BGP 124 speaker if the speaker does not have a (globally unique) 2-octet AS 125 number. 127 4. Operations 129 4.1. Interaction Between NEW BGP Speakers 131 A BGP speaker that supports 4-octet Autonomous System numbers SHOULD 132 advertise this to its peers using the BGP Capability Advertisements. 133 A BGP speaker that advertises such capability to a particular peer, 134 and receives from that peer the advertisement of such capability MUST 135 encode Autonomous System numbers as 4-octet entities in both the 136 AS_PATH and the AGGREGATOR attributes in the updates it sends to the 137 peer, and MUST assume that these attributes in the updates received 138 from the peer encode Autonomous System numbers as 4-octet entities. 140 The new attributes, AS4_PATH and AS4_AGGREGATOR SHOULD NOT be carried 141 in the UPDATE messages between NEW BGP peers. A NEW BGP speaker that 142 receives the AS4_PATH and AS4_AGGREGATOR path attributes in an UPDATE 143 message from a NEW BGP speaker SHOULD discard these path attributes 144 and continue processing the UPDATE message. 146 4.2. Interaction Between NEW and OLD BGP Speakers 148 4.2.1. BGP Peering 150 Note that peering between a NEW BGP speaker and an OLD one is 151 possible only if the NEW BGP speaker has a 2-octet AS number. 152 However, this document does not assume that an Autonomous System with 153 NEW speakers has to have a globally unique 2-octet AS number - 154 AS_TRANS could be used instead (even if multiple Autonomous System 155 would use it). 157 4.2.2. Generating Updates 159 When communicating with an OLD BGP speaker, a NEW speaker MUST send 160 the AS path information in the AS_PATH attribute encoded with 2-octet 161 AS numbers. The NEW speaker also MUST send the AS path information in 162 the AS4_PATH attribute (encoded with 4-octet AS numbers), except for 163 the case where the entire AS path information is composed of 2-octet 164 AS numbers only. In this case the NEW speaker SHOULD NOT send the 165 AS4_PATH attribute. 167 In the AS_PATH attribute encoded with 2-octet AS numbers, non- 168 mappable 4-octet AS numbers are represented by the well known 2-octet 169 AS number, AS_TRANS. This will preserve the path length property of 170 the AS path information; and will also help in updating the AS path 171 information received on a NEW BGP speaker from an OLD speaker, as 172 explained in the next section. 174 The NEW speaker constructs the AS4_PATH attribute from the 175 information carried in the AS_PATH attribute. In the case where the 176 AS_PATH attribute contains either AS_CONFED_SEQUENCE or AS_CONFED_SET 177 path segments, the NEW speaker, when constructing the AS4_PATH 178 attribute from the AS_PATH attribute, MUST exclude such path 179 segments. The AS4_PATH attribute will be carried across a series of 180 OLD BGP speakers without modification and will help preserve the 181 truly 4-octet AS numbers in the AS path information. 183 Similarly, if the NEW speaker has to send the AGGREGATOR attribute, 184 and if the aggregating Autonomous System's AS number is truly 185 4-octets, the speaker constructs the AS4_AGGREGATOR attributes by 186 taking the attribute length and attribute value from the AGGREGATOR 187 attribute and placing them into the attribute length and attribute 188 value of the AS4_AGGREGATOR attribute, and sets the AS number field 189 in the existing AGGREGATOR attribute to the reserved AS number, 190 AS_TRANS. Note that if the AS number is 2-octets only, then the 191 AS4_AGGREGATOR attribute SHOULD NOT be sent. 193 4.2.3. Processing Received Updates 195 When a NEW BGP speaker receives an update from an OLD one, it should 196 be prepared to receive the AS4_PATH attribute along with the existing 197 AS_PATH attribute. If the AS4_PATH attribute is also received, both 198 the attributes will be used to construct the exact AS path 199 information, and therefore the information carried by both the 200 attributes will be considered for AS path loop detection. 202 Note that a route may have traversed a series of autonomous systems 203 with 2-octet AS numbers and OLD BGP speakers only. In that case, if 204 the route carries the AS4_PATH attribute, this attribute must have 205 remained unmodified since the route left the last NEW BGP speaker. 206 The trailing AS path information (representing autonomous systems 207 with 2-octet AS numbers and OLD BGP speakers only) is contained only 208 in the current AS_PATH attribute (encoded in the leading part of the 209 AS_PATH attribute). 211 Under certain conditions it may not be possible to reconstruct the 212 entire AS path information from the AS_PATH and the AS4_PATH 213 attributes of a route. This occurs when two or more routes that carry 214 the AS4_PATH attribute are aggregated by an OLD BGP speaker, and the 215 AS4_PATH attribute of at least one of these routes carries at least 216 one 4-octet AS number (as oppose to a 2-octet AS number that is 217 encoded in 4 octets). Depending on the implementation, either the 218 AS4_PATH attribute would be lost during route aggregation, or both 219 the AS_PATH attribute and the AS4_PATH attribute would contain valid, 220 partial information that can not be combined seamlessly, resulting in 221 incomplete AS path information in these cases. 223 A NEW BGP speaker should also be prepared to receive the 224 AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an 225 OLD BGP speaker. When both the attributes are received, if the AS 226 number in the AGGREGATOR attribute is not AS_TRANS, then the 227 AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL be ignored, 228 and the AGGREGATOR attribute SHALL be taken as the information about 229 the aggregating node, and the AS_PATH attribute SHALL be taken as the 230 AS path information; otherwise the AGGREGATOR attribute SHALL be 231 ignored, and the AS4_AGGREGATOR attribute SHALL be taken as the 232 information about the aggregating node, and the AS path information 233 would need to be constructed, as in all other cases. 235 In order to construct the AS path information, it would be necessary 236 to first calculate the number of AS numbers in the AS_PATH attribute 237 and in the AS4_PATH attribute using the method specified in Sect. 238 9.1.2.2 [BGP] and [RFC3065] for route selection. 240 If the number of AS numbers in the AS_PATH attribute is less than the 241 number of AS numbers in the AS4_PATH attribute, then the AS4_PATH 242 attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken 243 as the AS path information. 245 If the number of AS numbers in the AS_PATH attribute is larger than 246 or equal to the number of AS numbers in the AS4_PATH attribute, then 247 the AS path information SHALL be constructed by taking as many AS 248 numbers and path segments as necessary from the leading part of the 249 AS_PATH attribute, and then prepending them to the AS4_PATH attribute 250 so that the AS path information has an identical number of AS numbers 251 as the AS_PATH attribute. Note that a valid AS_CONFED_SEQUENCE or 252 AS_CONFED_SET path segment SHALL be prepended if it is either the 253 leading path segment or adjacent to a path segment that is prepended. 255 5. Handling BGP Communities 257 As specified in [RFC1997], when the high-order two-octets of the 258 community attribute is neither 0x0000 nor 0xffff, these two octets 259 encode the Autonomous System number. Quite clearly this would not 260 work for BGP speakers that use 4-octets Autonomous System numbers. 261 Such BGP speakers should use the Four-octet AS Specific Extended 262 Communities [AS-EXT-COMM] instead. 264 6. Transition 266 The scheme described in this document allows a gradual transition 267 from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one 268 Autonomous System or one BGP speaker at a time. 270 To simplify transition this document assumes that an Autonomous 271 System could start using a 4-octet AS number only after all the BGP 272 speakers within that Autonomous System have been upgraded to support 273 4-octet AS numbers. 275 An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System 276 number. 278 A non-mappable 4-octet AS number can not be used as a "Member AS 279 Number" of a BGP Confederation until all the BGP speakers within the 280 Confederation have transitioned to support 4-octet AS numbers. 282 In an environment where an Autonomous System that has OLD BGP 283 speakers peers with two or more Autonomous Systems that have NEW BGP 284 speakers and use AS_TRANS (rather than having a globally unique AS 285 number), use of Multi-Exit Discriminators by the Autonomous System 286 with the OLD speakers may result in a situation where Multi-Exit 287 Discriminator will influence route selection among the routes that 288 were received from different neighboring Autonomous Systems. 290 Under certain conditions it may not be possible to reconstruct the 291 entire AS path information from the AS_PATH and the AS4_PATH 292 attributes of a route. This occurs when two or more routes that carry 293 the AS4_PATH attribute are aggregated by an OLD BGP speaker, and the 294 AS4_PATH attribute of at least one of these routes carries at least 295 one 4-octet AS number (as oppose to a 2-octet AS number that is 296 encoded in 4 octets). When such aggregation results in creating a 297 route that is less specific than any of the component routes, (route 298 whose NLRI covers NLRI of all the component routes), loss of the AS 299 path information does not create a risk of a routing loop. In all 300 other cases loss of the AS path information does create a risk of a 301 routing loop. 303 7. IANA Considerations 305 This document expands the pool for AS numbers from 0 - 65535 to 0 - 306 4294967295. The AS numbers are managed by the IANA "Autonomous 307 System Numbers" registry. Other than expanding the AS number pool, 308 this document does not propose any modifications to the existing 309 policies and procedures pertaining to the AS number allocation. 311 This document uses a BGP Capability code to indicate that a BGP 312 speaker supports the 4-octet AS numbers. The Capability Code 65 has 313 been assigned by IANA per RFC 2842. 315 In addition, this document introduces two new BGP optional transitive 316 attributes, and their type codes have been assigned by the IANA. The 317 first one is the AS4_PATH attribute, value 17, which preserves the AS 318 path information with 4-octet AS numbers across old BGP speakers. The 319 second one is the AS4_AGGREGATOR attribute, value 18, which is 320 similar in use to the current AGGREGATOR attribute but it carries a 321 4-octet AS number. 323 Finally, this document introduces a reserved 2-octet AS number - 324 AS_TRANS. The AS number 23456 has been assigned by the IANA for 325 AS_TRANS. 327 8. Security Considerations 329 This extension to BGP does not change the underlying security issues 330 inherent in the existing BGP, except for the following: 332 The inconsistency between the AS_PATH attribute and the AS4_PATH 333 attribute can create loss of the AS path information, and potential 334 routing loops in certain cases as discussed in the document. This 335 could be exploited by an attacker. 337 9. Acknowledgments 339 The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina, 340 and Jeffrey Haas for the numerous discussions which went into the 341 making of this document. 343 10. Normative References 345 [BGP] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway Protocol 346 4 (BGP-4)", RFC 4271, January 2006. 348 [RFC1997] Chandra, R., Traina, P. and Li, T., "BGP Communities 349 Attribute", RFC 1997, August 1996. 351 [RFC2842] Chandra, R., and Scudder, J., "Capabilities Advertisement 352 with BGP-4", RFC 2842, May 2000. 354 [RFC3065] Traina, P., McPherson, D., Scudder, J., "Autonomous System 355 Confederations for BGP", RFC 3065, February 2001. 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 11. Non-normative References 362 [AS-EXT-COM] Rekhter, Y., Ramachandra, S., and Tappan, D. "Four- 363 octet AS Specific BGP Extended Community", draft-rekhter-as4octet- 364 ext-community-00.txt, October 2005. 366 12. Authors' Information 368 Quaizar Vohra 369 Nuova Systems 370 2600 San Tomas Expressway 371 Santa Clara, CA 95051 373 Email: qv@nuovasystems.com 375 Enke Chen 376 Cisco Systems, Inc. 377 170 W. Tasman Dr. 378 San Jose, CA 95134 380 Email: enkechen@cisco.com 382 13. Intellectual Property Considerations 384 The IETF takes no position regarding the validity or scope of any 385 Intellectual Property Rights or other rights that might be claimed to 386 pertain to the implementation or use of the technology described in 387 this document or the extent to which any license under such rights 388 might or might not be available; nor does it represent that it has 389 made any independent effort to identify any such rights. Information 390 on the procedures with respect to rights in RFC documents can be 391 found in BCP 78 and BCP 79. 393 Copies of IPR disclosures made to the IETF Secretariat and any 394 assurances of licenses to be made available, or the result of an 395 attempt made to obtain a general license or permission for the use of 396 such proprietary rights by implementers or users of this 397 specification can be obtained from the IETF on-line IPR repository at 398 http://www.ietf.org/ipr. 400 The IETF invites any interested party to bring to its attention any 401 copyrights, patents or patent applications, or other proprietary 402 rights that may cover technology that may be required to implement 403 this standard. Please address the information to the IETF at ietf- 404 ipr@ietf.org. 406 14. Full Copyright Notice 408 Copyright (C) The IETF Trust (2007). 410 This document is subject to the rights, licenses and restrictions 411 contained in BCP 78, and except as set forth therein, the authors 412 retain all their rights. 414 This document and the information contained herein are provided on an 415 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 416 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 417 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 418 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 419 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 420 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.