idnits 2.17.1 draft-ietf-idr-as4bytes-12.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 on line 413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 397. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 263, but not defined == Unused Reference: 'AS-EXT-COM' is defined on line 355, 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: 6 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 Juniper Networks 4 Expiration Date: May 2006 Enke Chen 5 Cisco Systems 7 BGP Support for Four-octet AS Number Space 9 draft-ietf-idr-as4bytes-12.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, NEW_AS_PATH and NEW_AGGREGATOR, are introduced that can 51 be 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 NEW_AS_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 NEW_AS_PATH. This is an optional transitive attribute that contains 99 the AS path encoded with 4-octet AS numbers. The NEW_AS_PATH 100 attribute has the same semantics as the AS_PATH attribute, except 101 that it is 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 NEW_AS_PATH 106 attribute. 108 Similarly, this document defines a new aggregator attribute called 109 NEW_AGGREGATOR, which is optional transitive. The NEW_AGGREGATOR 110 attribute has the same semantics as the AGGREGATOR attribute, except 111 that it carries 4-octet AS numbers. 113 Currently assigned 2-octet Autonomous System numbers are converted 114 into 4-octet Autonomous System numbers by setting the high-order 2 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 MAY 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, NEW_AS_PATH and NEW_AGGREGATOR SHOULD NOT be 141 carried in the UPDATE messages between NEW BGP peers. A NEW BGP 142 speaker that receives the NEW_AS_PATH and NEW_AGGREGATOR path 143 attributes in an UPDATE message from a NEW BGP speaker SHOULD discard 144 these path attributes 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 NEW_AS_PATH attribute (encoded with 4-octet AS numbers), except 163 for the case where the entire AS path information is composed of 164 2-octet AS numbers only. In this case the NEW speaker SHOULD NOT send 165 the NEW_AS_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 NEW_AS_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 NEW_AS_PATH 178 attribute from the AS_PATH attribute, MUST exclude such path 179 segments. The NEW_AS_PATH attribute will be carried across a series 180 of 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 NEW_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 NEW_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 NEW_AGGREGATE 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 NEW_AS_PATH attribute along with the 197 existing AS_PATH attribute. If the NEW_AS_PATH attribute is also 198 received, both the attributes will be used to construct the exact AS 199 path 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 NEW_AS_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 NEW_AS_PATH 213 attributes of a route. This occurs when two or more routes that carry 214 the NEW_AS_PATH attribute are aggregated by an OLD BGP speaker, and 215 the NEW_AS_PATH attribute of at least one of these routes carries at 216 least 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 NEW_AS_PATH attribute would be lost during route aggregation, or both 219 the AS_PATH attribute and the NEW_AS_PATH attribute would contain 220 valid, partial information that can not be combined seamlessly, 221 resulting in incomplete AS path information in these cases. 223 A NEW BGP speaker should also be prepared to receive the 224 NEW_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_TRAN, then the 227 NEW_AGGREGATOR attribute and the NEW_AS_PATH attribute SHALL be 228 ignored, and the AGGREGATOR attribute SHALL be taken as the 229 information about the aggregating node, and the AS_PATH attribute 230 SHALL be taken as the AS path information; otherwise the AGGREGATOR 231 attribute SHALL be ignored, and the NEW_AGGREGATOR attribute SHALL be 232 taken as the information about the aggregating node, and the AS path 233 information 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 NEW_AS_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 NEW_AS_PATH attribute, then the 242 NEW_AS_PATH attribute SHALL be ignored, and the AS_PATH attribute 243 SHALL be taken 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 NEW_AS_PATH attribute, 247 then the AS path information SHALL be constructed by taking as many 248 AS numbers and path segments as necessary from the leading part of 249 the AS_PATH attribute, and then prepending them to the NEW_AS_PATH 250 attribute so that the AS path information has an identical number of 251 AS numbers as the AS_PATH attribute. Note that a valid 252 AS_CONFED_SEQUENCE or AS_CONFED_SET path segment SHALL be prepended 253 if it is either the leading path segment or adjacent to a path 254 segment that is prepended. 256 5. Handling BGP Communities 258 As specified in [RFC1997], when the high-order two-octets of the 259 community attribute is neither 0x0000 nor 0xffff, these two octets 260 encode the Autonomous System number. Quite clearly this would not 261 work for BGP speakers that use 4-octets Autonomous System numbers. 262 Such BGP speakers should use the Four-octet AS Specific Extended 263 Communities [AS-EXT-COMM] instead. 265 6. Transition 267 The scheme described in this document allows a gradual transition 268 from 2-octet AS numbers to 4-octet AS numbers. One can upgrade one 269 Autonomous System or one BGP speaker at a time. 271 To simplify transition this document assumes that an Autonomous 272 System could start using a 4-octet AS number only after all the BGP 273 speakers within that Autonomous System have been upgraded to support 274 4-octet AS numbers. 276 An OLD BGP speaker SHOULD NOT use AS_TRANS as its Autonomous System 277 number. 279 A non-mappable 4-octet AS number can not be used as a "Member AS 280 Number" of a BGP Confederation until all the BGP speakers within the 281 Confederation have transitioned to support 4-octet AS numbers. 283 In an environment where an Autonomous System that has OLD BGP 284 speakers peers with two or more Autonomous Systems that have NEW BGP 285 speakers and use AS_TRANS (rather than having a globally unique AS 286 number), use of Multi-Exit Discriminators by the Autonomous System 287 with the OLD speakers may result in a situation where Multi-Exit 288 Discriminator will influence route selection among the routes that 289 were received from different neighboring Autonomous Systems. 291 Under certain conditions it may not be possible to reconstruct the 292 entire AS path information from the AS_PATH and the NEW_AS_PATH 293 attributes of a route. This occurs when two or more routes that carry 294 the NEW_AS_PATH attribute are aggregated by an OLD BGP speaker, and 295 the NEW_AS_PATH attribute of at least one of these routes carries at 296 least one 4-octet AS number (as oppose to a 2-octet AS number that is 297 encoded in 4 octets). When such aggregation results in creating a 298 route that is less specific than any of the component routes, (route 299 whose NLRI covers NLRI of all the component routes), loss of the AS 300 path information does not create a risk of a routing loop. In all 301 other cases loss of the AS path information does create a risk of a 302 routing loop. 304 7. IANA Considerations 306 This document makes the four-octet, unsigned integers larger than 307 65535 available for allocation as AS numbers. These AS numbers need 308 to be managed by the IANA "Autonomous System Numbers" registry. 310 This document uses a BGP Capability code to indicate that a BGP 311 speaker supports the 4-octet AS numbers. The Capability code has 312 been assigned by IANA per RFC 2842. 314 In addition, this document introduces two new BGP optional transitive 315 attributes. The first is the NEW_AS_PATH attribute, which preserves 316 the AS path information with 4-octet AS numbers across old BGP 317 speakers. The second is the NEW_AGGREGATOR attribute, which is 318 similar in use to the current AGGREGATOR attribute but it carries 319 4-octet AS numbers. The Type Codes for these attributes have been 320 assigned by IANA. 322 Finally, this document introduces a reserved 2-octet AS number - 323 AS_TRANS. The AS number for AS_TRANS has been assigned by the IANA. 325 8. Security Considerations 327 This extension to BGP does not change the underlying security issues 328 inherent in the existing BGP. 330 9. Acknowledgments 332 The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina, 333 and Jeffrey Haas for the numerous discussions which went into the 334 making of this draft. 336 10. Normative References 338 [BGP] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway Protocol 339 4 (BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004. 341 [RFC1997] Chandra, R., Traina, P. and Li, T., "BGP Communities 342 Attribute", RFC 1997, August 1996. 344 [RFC2842] Chandra, R., and Scudder, J., "Capabilities Advertisement 345 with BGP-4", RFC 2842, May 2000. 347 [RFC3065] Traina, P., McPherson, D., Scudder, J., "Autonomous System 348 Confederations for BGP", RFC 3065, February 2001. 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, March 1997. 353 11. Non-normative References 355 [AS-EXT-COM] Rekhter, Y., Ramachandra, S., and Tappan, D. "Four- 356 octet AS Specific BGP Extended Community", draft-rekhter-as4octet- 357 ext-community-00.txt, October 2005. 359 12. Authors' Information 361 Quaizar Vohra 362 Juniper Networks 363 1194 N. Mathilda Ave 364 Sunnyvale, CA 94089 366 Email: qv@juniper.net 368 Enke Chen 369 Cisco Systems, Inc. 370 170 W. Tasman Dr. 371 San Jose, CA 95134 373 Email: enkechen@cisco.com 375 13. Intellectual Property Considerations 377 The IETF takes no position regarding the validity or scope of any 378 Intellectual Property Rights or other rights that might be claimed to 379 pertain to the implementation or use of the technology described in 380 this document or the extent to which any license under such rights 381 might or might not be available; nor does it represent that it has 382 made any independent effort to identify any such rights. Information 383 on the procedures with respect to rights in RFC documents can be 384 found in BCP 78 and BCP 79. 386 Copies of IPR disclosures made to the IETF Secretariat and any 387 assurances of licenses to be made available, or the result of an 388 attempt made to obtain a general license or permission for the use of 389 such proprietary rights by implementers or users of this 390 specification can be obtained from the IETF on-line IPR repository at 391 http://www.ietf.org/ipr. 393 The IETF invites any interested party to bring to its attention any 394 copyrights, patents or patent applications, or other proprietary 395 rights that may cover technology that may be required to implement 396 this standard. Please address the information to the IETF at ietf- 397 ipr@ietf.org. 399 14. Full Copyright Notice 401 Copyright (C) The Internet Society (2005). 403 This document is subject to the rights, licenses and restrictions 404 contained in BCP 78, and except as set forth therein, the authors 405 retain all their rights. 407 This document and the information contained herein are provided on an 408 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 409 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 410 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 411 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 412 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 413 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.