idnits 2.17.1 draft-ietf-idr-bgp4-multiprotocol-v2-04.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([IPv4], [BGP-4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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) ** Obsolete normative reference: RFC 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2385 (ref. 'Heffernan') (Obsoleted by RFC 5925) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv4' ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tony Bates 2 Internet Draft Cisco Systems 3 Expiration Date: August 2000 Ravi Chandra 4 Siara Systems 5 Dave Katz 6 Juniper Networks 7 Yakov Rekhter 8 Cisco Systems 10 Multiprotocol Extensions for BGP-4 12 draft-ietf-idr-bgp4-multiprotocol-v2-04.txt 14 1. Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 2. Abstract 37 Currently BGP-4 [BGP-4] is capable of carrying routing information 38 only for IPv4 [IPv4]. This document defines extensions to BGP-4 to 39 enable it to carry routing information for multiple Network Layer 40 protocols (e.g., IPv6, IPX, etc...). The extensions are backward 41 compatible - a router that supports the extensions can interoperate 42 with a router that doesn't support the extensions. 44 3. Overview 46 The only three pieces of information carried by BGP-4 that are IPv4 47 specific are (a) the NEXT_HOP attribute (expressed as an IPv4 48 address), (b) AGGREGATOR (contains an IPv4 address), and (c) NLRI 49 (expressed as IPv4 address prefixes). This document assumes that any 50 BGP speaker (including the one that supports multiprotocol 51 capabilities defined in this document) has to have an IPv4 address 52 (which will be used, among other things, in the AGGREGATOR 53 attribute). Therefore, to enable BGP-4 to support routing for 54 multiple Network Layer protocols the only two things that have to be 55 added to BGP-4 are (a) the ability to associate a particular Network 56 Layer protocol with the next hop information, and (b) the ability to 57 associated a particular Network Layer protocol with NLRI. To identify 58 individual Network Layer protocols this document uses Address Family, 59 as defined in [RFC1700]. 61 One could further observe that the next hop information (the 62 information provided by the NEXT_HOP attribute) is meaningful (and 63 necessary) only in conjunction with the advertisements of reachable 64 destinations - in conjunction with the advertisements of unreachable 65 destinations (withdrawing routes from service) the next hop 66 information is meaningless. This suggests that the advertisement of 67 reachable destinations should be grouped with the advertisement of 68 the next hop to be used for these destinations, and that the 69 advertisement of reachable destinations should be segregated from the 70 advertisement of unreachable destinations. 72 To provide backward compatibility, as well as to simplify 73 introduction of the multiprotocol capabilities into BGP-4 this 74 document uses two new attributes, Multiprotocol Reachable NLRI 75 (MP_REACH_NLRI), and Multiprotocol Unreachable NLRI 76 (MP_UNREACH_NLRI). The first one (MP_REACH_NLRI) is used to carry the 77 set of reachable destinations together with the next hop information 78 to be used for forwarding to these destinations. The second one 79 (MP_UNREACH_NLRI) is used to carry the set of unreachable 80 destinations. Both of these attributes are optional and non- 81 transitive. This way a BGP speaker that doesn't support the 82 multiprotocol capabilities will just ignore the information carried 83 in these attributes, and will not pass it to other BGP speakers. 85 4. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14): 87 This is an optional non-transitive attribute that can be used for the 88 following purposes: 90 (a) to advertise a feasible route to a peer 92 (b) to permit a router to advertise the Network Layer address of 93 the router that should be used as the next hop to the destinations 94 listed in the Network Layer Reachability Information field of the 95 MP_NLRI attribute. 97 (c) to allow a given router to report some or all of the 98 Subnetwork Points of Attachment (SNPAs) that exist within the 99 local system 101 The attribute is encoded as shown below: 103 +---------------------------------------------------------+ 104 | Address Family Identifier (2 octets) | 105 +---------------------------------------------------------+ 106 | Subsequent Address Family Identifier (1 octet) | 107 +---------------------------------------------------------+ 108 | Length of Next Hop Network Address (1 octet) | 109 +---------------------------------------------------------+ 110 | Network Address of Next Hop (variable) | 111 +---------------------------------------------------------+ 112 | Number of SNPAs (1 octet) | 113 +---------------------------------------------------------+ 114 | Length of first SNPA(1 octet) | 115 +---------------------------------------------------------+ 116 | First SNPA (variable) | 117 +---------------------------------------------------------+ 118 | Length of second SNPA (1 octet) | 119 +---------------------------------------------------------+ 120 | Second SNPA (variable) | 121 +---------------------------------------------------------+ 122 | ... | 123 +---------------------------------------------------------+ 124 | Length of Last SNPA (1 octet) | 125 +---------------------------------------------------------+ 126 | Last SNPA (variable) | 127 +---------------------------------------------------------+ 128 | Network Layer Reachability Information (variable) | 129 +---------------------------------------------------------+ 131 The use and meaning of these fields are as follows: 133 Address Family Identifier: 135 This field carries the identity of the Network Layer protocol 136 associated with the Network Address that follows. Presently 137 defined values for this field are specified in RFC1700 (see the 138 Address Family Numbers section). 140 Subsequent Address Family Identifier: 142 This field provides additional information about the type of 143 the Network Layer Reachability Information carried in the 144 attribute. 146 Length of Next Hop Network Address: 148 A 1 octet field whose value expresses the length of the 149 "Network Address of Next Hop" field as measured in octets 151 Network Address of Next Hop: 153 A variable length field that contains the Network Address of 154 the next router on the path to the destination system 156 Number of SNPAs: 158 A 1 octet field which contains the number of distinct SNPAs to 159 be listed in the following fields. The value 0 may be used to 160 indicate that no SNPAs are listed in this attribute. 162 Length of Nth SNPA: 164 A 1 octet field whose value expresses the length of the "Nth 165 SNPA of Next Hop" field as measured in semi-octets 167 Nth SNPA of Next Hop: 169 A variable length field that contains an SNPA of the router 170 whose Network Address is contained in the "Network Address of 171 Next Hop" field. The field length is an integral number of 172 octets in length, namely the rounded-up integer value of one 173 half the SNPA length expressed in semi-octets; if the SNPA 174 contains an odd number of semi-octets, a value in this field 175 will be padded with a trailing all-zero semi-octet. 177 Network Layer Reachability Information: 179 A variable length field that lists NLRI for the feasible routes 180 that are being advertised in this attribute. When the 181 Subsequent Address Family Identifier field is set to one of the 182 values defined in this document, each NLRI is encoded as 183 specified in the "NLRI encoding" section of this document. 185 The next hop information carried in the MP_REACH_NLRI path attribute 186 defines the Network Layer address of the border router that should be 187 used as the next hop to the destinations listed in the MP_NLRI 188 attribute in the UPDATE message. When advertising a MP_REACH_NLRI 189 attribute to an external peer, a router may use one of its own 190 interface addresses in the next hop component of the attribute, 191 provided the external peer to which the route is being advertised 192 shares a common subnet with the next hop address. This is known as a 193 "first party" next hop. A BGP speaker can advertise to an external 194 peer an interface of any internal peer router in the next hop 195 component, provided the external peer to which the route is being 196 advertised shares a common subnet with the next hop address. This is 197 known as a "third party" next hop information. A BGP speaker can 198 advertise any external peer router in the next hop component, 199 provided that the Network Layer address of this border router was 200 learned from an external peer, and the external peer to which the 201 route is being advertised shares a common subnet with the next hop 202 address. This is a second form of "third party" next hop 203 information. 205 Normally the next hop information is chosen such that the shortest 206 available path will be taken. A BGP speaker must be able to support 207 disabling advertisement of third party next hop information to handle 208 imperfectly bridged media or for reasons of policy. 210 A BGP speaker must never advertise an address of a peer to that peer 211 as a next hop, for a route that the speaker is originating. A BGP 212 speaker must never install a route with itself as the next hop. 214 When a BGP speaker advertises the route to an internal peer, the 215 advertising speaker should not modify the next hop information 216 associated with the route. When a BGP speaker receives the route via 217 an internal link, it may forward packets to the next hop address if 218 the address contained in the attribute is on a common subnet with the 219 local and remote BGP speakers. 221 An UPDATE message that carries the MP_REACH_NLRI must also carry the 222 ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP 223 exchanges). Moreover, in IBGP exchanges such a message must also 224 carry the LOCAL_PREF attribute. If such a message is received from an 225 external peer, the local system shall check whether the leftmost AS 226 in the AS_PATH attribute is equal to the autonomous system number of 227 the peer than sent the message. If that is not the case, the local 228 system shall send the NOTIFICATION message with Error Code UPDATE 229 Message Error, and the Error Subcode set to Malformed AS_PATH. 231 An UPDATE message that carries no NLRI, other than the one encoded in 232 the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. 233 If such a message contains the NEXT_HOP attribute, the BGP speaker 234 that receives the message should ignore this attribute. 236 5. Multiprotocol Unreachable NLRI - MP_UNREACH_NLRI (Type Code 15): 238 This is an optional non-transitive attribute that can be used for the 239 purpose of withdrawing multiple unfeasible routes from service. 241 The attribute is encoded as shown below: 243 +---------------------------------------------------------+ 244 | Address Family Identifier (2 octets) | 245 +---------------------------------------------------------+ 246 | Subsequent Address Family Identifier (1 octet) | 247 +---------------------------------------------------------+ 248 | Withdrawn Routes (variable) | 249 +---------------------------------------------------------+ 251 The use and the meaning of these fields are as follows: 253 Address Family Identifier: 255 This field carries the identity of the Network Layer protocol 256 associated with the NLRI that follows. Presently defined values 257 for this field are specified in RFC1700 (see the Address Family 258 Numbers section). 260 Subsequent Address Family Identifier: 262 This field provides additional information about the type of 263 the Network Layer Reachability Information carried in the 264 attribute. 266 Withdrawn Routes: 268 A variable length field that lists NLRI for the routes that are 269 being withdrawn from service. When the Subsequent Address 270 Family Identifier field is set to one of the values defined in 271 this document, each NLRI is encoded as specified in the "NLRI 272 encoding" section of this document. 274 An UPDATE message that contains the MP_UNREACH_NLRI is not required 275 to carry any other path attributes. 277 6. NLRI encoding 279 The Network Layer Reachability information is encoded as one or more 280 2-tuples of the form , whose fields are described 281 below: 283 +---------------------------+ 284 | Length (1 octet) | 285 +---------------------------+ 286 | Prefix (variable) | 287 +---------------------------+ 289 The use and the meaning of these fields are as follows: 291 a) Length: 293 The Length field indicates the length in bits of the address 294 prefix. A length of zero indicates a prefix that matches all 295 (as specified by the address family) addresses (with prefix, 296 itself, of zero octets). 298 b) Prefix: 300 The Prefix field contains an address prefix followed by enough 301 trailing bits to make the end of the field fall on an octet 302 boundary. Note that the value of trailing bits is irrelevant. 304 7. Subsequent Address Family Identifier 306 This document defines the following values for the Subsequent Address 307 Family Identifier field carried in the MP_REACH_NLRI and 308 MP_UNREACH_NLRI attributes: 310 1 - Network Layer Reachability Information used for unicast 311 forwarding 313 2 - Network Layer Reachability Information used for multicast 314 forwarding 316 3 - Network Layer Reachability Information used for both unicast 317 and multicast forwarding 319 8. Error Handling 321 If a BGP speaker receives from a neighbor an Update message that 322 contains the MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and the 323 speaker determines that the attribute is incorrect, the speaker must 324 delete all the BGP routes received from that neighbor whose AFI/SAFI 325 is the same as the one carried in the incorrect MP_REACH_NLRI or 326 MP_UNREACH_NLRI attribute. For the duration of the BGP session over 327 which the Update message was received, the speaker then should ignore 328 all the subsequent routes with that AFI/SAFI received over that 329 session. 331 In addition, the speaker may terminate the BGP session over which the 332 Update message was received. The session should be terminated with 333 the Notification message code/subcode indicating "Update Message 334 Error"/"Optional Attribute Error". 336 9. Use of BGP Capability Negotiation 338 A BGP speaker that uses Multiprotocol Extensions should use the 339 Capability Negotiation procedures [BGP-CAP] to determine whether the 340 speaker could use Multiprotocol Extensions with a particular peer. 342 The fields in the Capabilities Optional Parameter are set as follows. 343 The Capability Code field is set to 1 (which indicates Multiprotocol 344 Extensions capabilities). The Capability Length field is set to 4. 345 The Capability Value field is defined as: 347 The use and meaning of this field is as follow: 349 0 7 15 23 31 350 +-------+-------+-------+-------+ 351 | AFI | Res. | SAFI | 352 +-------+-------+-------+-------+ 354 AFI - Address Family Identifier (16 bit), encoded the same way 355 as in the Multiprotocol Extensions 357 Res. - Reserved (8 bit) field. Should be set to 0 by the sender 358 and ignored by the receiver. 360 SAFI - Subsequent Address Family Identifier (8 bit), encoded 361 the same way as in the Multiprotocol Extensions. 363 A speaker that supports multiple tuples includes them as 364 multiple Capabilities in the Capabilities Optional Parameter. 366 To have a bi-directional exchange of routing information for a 367 particular between a pair of BGP speakers, each such 368 speaker must advertise to the other (via the Capability Negotiation 369 mechanism) the capability to support that particular 370 routes. 372 10. IANA Considerations 374 As specified in this document, the MPL_REACH_NLRI and MP_UNREACH_NLRI 375 attributes contain the Subsequence Address Family Identifier (SAFI) 376 field. SAFI value 0 is reserved. SAFI values 1, 2, and 3 are 377 assigned in this document. SAFI values 4 through 63 are to be 378 assigned by IANA using the "IETF Consensus" policy defined in 379 RFC2434. SAFI values 64 through 127 are to be assigned by IANA, using 380 the "First Come First Served" policy defined in RFC2434. SAFI values 381 128 through 255 are vendor-specific, and values in this range are not 382 to be assigned by IANA. 384 11. Security Considerations 386 This extension to BGP does not change the underlying security issues 387 inherent in the existing BGP [Heffernan]. 389 12. Acknowledgements 391 The authors would like to thank members of the IDR Working Group for 392 their review and comments. 394 13. References 396 [BGP-CAP] "Capabilities Negotiation with BGP-4", R. Chandra, J. 397 Scudder, draft-ietf-idr-bgp4-cap-neg-05.txt, February 1999 399 [BGP-4] "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter & T. Li, 400 RFC1771, March 1995 402 [Heffernan] Heffernan, A., "Protection of BGP Sessions via the TCP 403 MD5 Signature Option", RFC2385, August 1998. 405 [IPv4] "Internet Protocol", J. Postel, September 1981 407 [RFC1700] "Assigned Numbers", J. Reynolds, J. Postel, RFC1700, 408 October 1994 (see also http://www.iana.org/iana/assignments.html) 410 14. Author Information 412 Tony Bates 413 Cisco Systems, Inc. 414 170 West Tasman Drive 415 San Jose, CA 95134 416 email: tbates@cisco.com 418 Ravi Chandra 419 Siara Systems Incorporated 420 1195 Borregas Avenue 421 Sunnyvale, CA 94089 422 e-mail: rchandra@siara.com 424 Dave Katz 425 Juniper Networks, Inc. 426 3260 Jay St. 427 Santa Clara, CA 95054 428 email: dkatz@jnx.com 429 Yakov Rekhter 430 Cisco Systems, Inc. 431 170 West Tasman Drive 432 San Jose, CA 95134 433 email: yakov@cisco.com