idnits 2.17.1 draft-stewart-bgp-multiprotocol-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 371 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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: 'TBA' is mentioned on line 326, but not defined == Unused Reference: 'ASSIGNED-NUMBERS-RFC' is defined on line 332, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP4-RFC') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 1700 (ref. 'ASSIGNED-NUMBERS-RFC') (Obsoleted by RFC 3232) Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dimitry Haskin 2 Internet-Draft Bay Networks 3 Expires June 1997 John W. Stewart, III 4 ISI 6 Multiprotocol Extensions for BGP 8 draft-stewart-bgp-multiprotocol-00.txt 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 2. Abstract 30 This document outlines a proposal for a BGP Version 5 (BGP5) 31 which has the ability to carry routing information for a variety 32 of network protocols. The proposed BGP modifications are 33 intended to be simple enough to be easily added to the existing 34 BGP implementations and, at the same time, provide for a longer 35 than 16-bit AS number space. 37 This document only describes BGP5 support for IPv4 and IPv6 networks. 39 3. Overview 41 BGP [BGP4-RFC] is widely deployed as an inter-domain routing 42 protocol for IPv4 and there is a large operational experience 43 with it. Though currently BGP can only carry routing information 44 for IPv4, the existence of the mature BGP implementation base 45 provides a strong motivation for extending it to support the Internet 46 Protocol version 6 (IPv6) and possibly other network protocols. 48 This document outlines a proposal for creating a BGP Version 5 (BGP5) 49 which has the ability to carry routing information for a variety 50 of network protocols. Adding this multi-protocol support to BGP 51 significantly increases its lifetime, so care should be taken for 52 BGP5 to not be under-engineered. For this reason, BGP5 supports 53 longer than 2-byte ASs. At the same time, in the authors' view, 54 the proposed modifications are simple enough to be easily added 55 to the existing BGP implementations as not to impede BGP5 deployment. 56 As a matter of fact no changes to the BGP4 data structures are required 57 to support IPv4 routing in BGP5. 59 To ensure a smooth transition from BGP4 to BGP5 on IPv4 networks 60 it is recommended that upgraded BGP implementations continue 61 BGP4 support at least until BGP5 is universally deployed. The BGP5 62 proposal ensures that IPv4 routing information that is advertised 63 with BGP5 is fully re-advertisable via BGP4 and vice versa. In this 64 sense BGP4 and BGP5 are fully compatible as far as IPv4 routing is 65 concerned. 67 This paper presents an overview of the protocol messages used by 68 BGP5. Where details of the protocol (e.g., the state machine and 69 fields of protocol messages) have the same meaning as BGP4, those 70 details are left out of this outline for the sake of brevity. 72 4. Autonomous System Number Space 74 This document proposes to adopt a 32-bit Autonomous System number 75 space for IPv6 to accommodate for the aggressive Internet growth. 76 The 32-bit number space is large enough to ensure that no future 77 IPv6 transition to a larger number space will be necessary. 79 In order to minimize implementation changes that are needed to 80 support IPv4 routing, 16-bit AS number space will continue to 81 be supported with BGP5. 83 In addition BGP5 will provide a mechanism to gradually introduce 84 the 32-bit AS number space to IPv4 routing. 86 5. Message Formats 88 This section describes message formats used by BGP. 90 5.1 Message Header Format 92 The fixed header for BGP5 is the same as BGP4, namely: 94 0 1 2 3 95 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | | 98 + + 99 | | 100 + + 101 | Marker | 102 + + 103 | | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Length | Type | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 This is as described in BGP4. 110 5.2 OPEN Message Format 112 The OPEN message has the following format: 114 +---------------------------------------+ 115 | Version (1 octet) | 116 +---------------------------------------+ 117 | Len of My Autonomous System (1 octet) | 118 +---------------------------------------+ 119 | My Autonomous System (variable) | 120 +---------------------------------------+ 121 | Hold Time (2 octets) | 122 +---------------------------------------+ 123 | Router ID (4 octets) | 124 +---------------------------------------+ 125 | Opt Parm Len (1 octet) | 126 +---------------------------------------+ 127 | Optional Parameters (variable) | 128 +---------------------------------------+ 130 "Version" is a one-octet unsigned integer specifying the 131 protocol version. This paper describes BGP version 5. 133 "Len of My Autonomous System" is a one-octet unsigned integer 134 specifying the length in octets of the "My Autonomous System" 135 field. To carry IPv4 ASs this field should be 2; to carry IPv6 ASs this 136 field should be 4. The presence of this field permits routing 137 domain identifiers of any length, though this paper only discusses 138 the use of 2-byte ASs and 4-byte [fixed-length] ASs. 140 "My Autonomous System" identifies the AS of which the sender 141 is a member. 143 "Hold Time" is as described in BGP4. 145 "Router ID" is a 32-bit unsigned integer identifying the 146 sender. Because the size of the Router ID is smaller than an IPv6 147 address, it cannot be set to one of the router's IPv6 addresses (as 148 is commonly done for IPv4). Possible Router ID assignment procedures 149 for IPv6 include: a) assign the IPv6 Router ID as one of the router's 150 IPv4 addresses or b) assign IPv6 Router IDs through some local 151 administrative procedure (similar to procedures used by manufacturers 152 to assign product serial numbers). The Router ID of 0.0.0.0 is 153 reserved, and should not be used. 155 "Opt Parm Len" and "Optional Parameters" are as described in BGP4. 157 5.3 UPDATE Message Format 159 The UPDATE message always includes the fixed-size BGP header that 160 is followed by one-octet Format Type field which indicates the 161 format and content of the rest of the UPDATE message. 163 The following UPDATE Format Type values are defined in this document: 165 1 - BGP4 compatible update with IPv4 routing information 166 2 - IPv6 routing update 167 3 - IPv4 routing update with the 4-octet AS numbers 169 Implementations are not required to support all possible 170 update formats. To allow for future enhancements, implementations 171 are required to ignore UPDATES with format types that they do not 172 support. 174 5.3.1 BGP4 Compatible Update 176 This type of UPDATE message has the following format: 178 +-----------------------------------------------------+ 179 | Format Type (1 octet) == 1 | 180 +-----------------------------------------------------+ 181 | Withdrawn Routes Length (2 octets) | 182 +-----------------------------------------------------+ 183 | Withdrawn Routes (variable) | 184 +-----------------------------------------------------+ 185 | Total Path Attribute Length (2 octets) | 186 +-----------------------------------------------------+ 187 | Path Attributes (variable) | 188 +-----------------------------------------------------+ 189 | Network Layer Reachability Information (variable) | 190 +-----------------------------------------------------+ 192 "Format Type" is a value indicating the format of 193 the UPDATE message. It is 1 for the BGP4 compatible format type. 195 All other fields are as described in BGP4. 197 5.3.2 IPv6 Routing Update 199 This type of UPDATE message has the following format: 201 +-----------------------------------------------------+ 202 | Format Type (1 octet) == 2 | 203 +-----------------------------------------------------+ 204 | Withdrawn Routes Length (2 octets) | 205 +-----------------------------------------------------+ 206 | Withdrawn Routes (variable) | 207 +-----------------------------------------------------+ 208 | Total Path Attribute Length (2 octets) | 209 +-----------------------------------------------------+ 210 | Path Attributes (variable) | 211 +-----------------------------------------------------+ 212 | Network Layer Reachability Information (variable) | 213 +-----------------------------------------------------+ 215 "Format Type" is a value indicating the format of 216 the UPDATE message. It is 2 for UPDATE messages that carry 217 IPv6 routes. 219 "Withdrawn Routes Length" is a two-octet unsigned integer 220 specifying the length in octets of the "Withdrawn Routes" field. 222 "Withdrawn Routes" is a variable-length field containing a list 223 of address prefixes being withdrawn from service. 224 Each address prefix is encoded as described in BGP4, except that 225 the "Length" component of the tuple isn't limited to what would 226 make sense for IPv4 addresses. 228 "Total Path Attribute Length" is as described in BGP4. 230 "Path Attributes" field is as described in BGP4 except: 232 - The NEXT-HOP attribute is interpreted as a 16-byte 233 IPv6 global or site scope address. 235 - The AGGREGATOR attribute contains the AS number that formed 236 the aggregate route (encoded as 4 octets), followed by the 237 16-byte IPv6 global or site scope address of the BGP speaker that 238 formed the aggregate route. 240 - The AS-PATH attribute contains four-byte ASs. Two-byte ASs 241 can be mapped to four-byte ASs with zero-padding to the left. 243 - A new LINK-LOCAL-NEXT-HOP attribute. 245 LINK-LOCAL-NEXT-HOP is a well-known discretionary attribute 246 that contains the link-local address of the router interface 247 associated with the global-scope IPv6 address specified in 248 the NEXT-HOP attribute of the same UPDATE message. 250 LINK-LOCAL-NEXT-HOP shall be included in all IPv6 UPDATE 251 messages that a given BGP speaker sends to other BGP speakers 252 located in a neighboring autonomous system. Such a link local 253 address should be used as the immediate next hop for forwarding 254 packets to the destinations listed in the UPDATE message. 256 A BGP speaker shall not include this attribute in IPv6 UPDATE 257 messages that it sends to BGP speakers located in its own 258 autonomous system. If it is contained in an UPDATE message that 259 is received from a BGP speaker which is located in the same AS 260 as the receiving speaker, then this attribute shall be ignored 261 by the receiving speaker. For the routes received from a BGP 262 speaker in the same AS as the receiving speaker, the link-local 263 address of the immediate next hop should be based on the IGP 264 route to the global-scope address provided in the NEXT-HOP 265 attribute. 267 "Network Layer Reachability Information" is as described in 268 BGP4, except that the "Length" component of the tuple isn't 269 limited to what would make sense for IPv4 addresses. 271 5.3.3 IPv4 Routing Update With the 32-bit AS Numbers 273 This type of UPDATE message provides support for 274 a larger than 16-bit AS number space that is currently 275 supported in BGP4. Introducing this type of UPDATE 276 well in advance of the 16-bit AS number space exhaustion 277 will allow for smoother IPv4 transition to a larger 278 AS number space. 280 16-bit AS numbers can be mapped into 32-bit AS numbers by with 281 zero-padding to the left. Therefore it is expected that 282 for an extended period, until BGP5 which supports this type of 283 UPDATE message is universally deployed, bacwards compatibility 284 will be achieved by simply mapping 16-bit AS numbers to zero- 285 extended 32-bit AS numbers and vice versa. 287 This type of UPDATE message has the following format: 289 +-----------------------------------------------------+ 290 | Format Type (1 octet) == 3 | 291 +-----------------------------------------------------+ 292 | Withdrawn Routes Length (2 octets) | 293 +-----------------------------------------------------+ 294 | Withdrawn Routes (variable) | 295 +-----------------------------------------------------+ 296 | Total Path Attribute Length (2 octets) | 297 +-----------------------------------------------------+ 298 | Path Attributes (variable) | 299 +-----------------------------------------------------+ 300 | Network Layer Reachability Information (variable) | 301 +-----------------------------------------------------+ 303 "Format Type" is a value indicating the format of 304 the UPDATE message. It is 3 for this format type. 306 "Withdrawn Routes Length" is as described in BGP4. 308 "Withdrawn Routes" is as described in BGP4 310 "Total Path Attribute Length" is as described in BGP4. 312 "Path Attributes" field is as described in BGP4 except: 314 - The AGGREGATOR attribute contains the 32-bit AS number that formed 315 the aggregate route (encoded as 4 octets), followed by the 316 IPv4 address of the BGP speaker that formed the aggregate route. 318 - The AS-PATH attribute contains 32-bit ASs. 320 6. Acknowledgements 322 [TBA] 324 7. Security Considerations 326 [TBA] 328 8. References 330 [BGP4-RFC] -- RFC1771 332 [ASSIGNED-NUMBERS-RFC] -- RFC1700 334 9. Authors' Addresses 336 John W. Stewart, III 337 USC/ISI 338 4350 North Fairfax Drive 339 Suite 620 340 Arlington, VA 22203 341 +1 703 812 3704 342 email: jstewart@isi.edu 344 Dimitry Haskin 345 Bay Networks 346 2 Federal St. 347 Billerica, MA 348 +1 508 916 8124 349 email: dhaskin@baynetworks.com