idnits 2.17.1 draft-ietf-idr-bgp4-multiprotocol-v2-02.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: ---------------------------------------------------------------------------- ** 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 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 9 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 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 an Authors' Addresses Section. ** 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) == Outdated reference: A later version (-05) exists of draft-ietf-idr-bgp4-cap-neg-03 ** Obsolete normative reference: RFC 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv4' ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tony Bates 3 Internet Draft Cisco Systems 4 Expiration Date: August 1999 Ravi Chandra 5 Cisco Systems 6 Dave Katz 7 Juniper Networks 8 Yakov Rekhter 9 Cisco Systems 11 Multiprotocol Extensions for BGP-4 13 draft-ietf-idr-bgp4-multiprotocol-v2-02.txt 15 1. Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 2. Abstract 38 Currently BGP-4 [BGP-4] is capable of carrying routing information 39 only for IPv4 [IPv4]. This document defines extensions to BGP-4 to 40 enable it to carry routing information for multiple Network Layer 41 protocols (e.g., IPv6, IPX, etc...). The extensions are backward 42 compatible - a router that supports the extensions can interoperate 43 with a router that doesn't support the extensions. 45 3. Overview 47 The only three pieces of information carried by BGP-4 that are IPv4 48 specific are (a) the NEXT_HOP attribute (expressed as an IPv4 49 address), (b) AGGREGATOR (contains an IPv4 address), and (c) NLRI 50 (expressed as IPv4 address prefixes). This document assumes that any 51 BGP speaker (including the one that supports multiprotocol 52 capabilities defined in this document) has to have an IPv4 address 53 (which will be used, among other things, in the AGGREGATOR 54 attribute). Therefore, to enable BGP-4 to support routing for 55 multiple Network Layer protocols the only two things that have to be 56 added to BGP-4 are (a) the ability to associate a particular Network 57 Layer protocol with the next hop information, and (b) the ability to 58 associated a particular Network Layer protocol with NLRI. To identify 59 individual Network Layer protocols this document uses Address Family, 60 as defined in [RFC1700]. 62 One could further observe that the next hop information (the 63 information provided by the NEXT_HOP attribute) is meaningful (and 64 necessary) only in conjunction with the advertisements of reachable 65 destinations - in conjunction with the advertisements of unreachable 66 destinations (withdrawing routes from service) the next hop 67 information is meaningless. This suggests that the advertisement of 68 reachable destinations should be grouped with the advertisement of 69 the next hop to be used for these destinations, and that the 70 advertisement of reachable destinations should be segregated from the 71 advertisement of unreachable destinations. 73 To provide backward compatibility, as well as to simplify 74 introduction of the multiprotocol capabilities into BGP-4 this 75 document uses two new attributes, Multiprotocol Reachable NLRI 76 (MP_REACH_NLRI), and Multiprotocol Unreachable NLRI 77 (MP_UNREACH_NLRI). The first one (MP_REACH_NLRI) is used to carry the 78 set of reachable destinations together with the next hop information 79 to be used for forwarding to these destinations. The second one 80 (MP_UNREACH_NLRI) is used to carry the set of unreachable 81 destinations. Both of these attributes are optional and non- 82 transitive. This way a BGP speaker that doesn't support the 83 multiprotocol capabilities will just ignore the information carried 84 in these attributes, and will not pass it to other BGP speakers. 86 4. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14): 88 This is an optional non-transitive attribute that can be used for the 89 following purposes: 91 (a) to advertise a feasible route to a peer 93 (b) to permit a router to advertise the Network Layer address of 94 the router that should be used as the next hop to the destinations 95 listed in the Network Layer Reachability Information field of the 96 MP_NLRI attribute. 98 (c) to allow a given router to report some or all of the 99 Subnetwork Points of Attachment (SNPAs) that exist within the 100 local system 102 The attribute is encoded as shown below: 104 +---------------------------------------------------------+ 105 | Address Family Identifier (2 octets) | 106 +---------------------------------------------------------+ 107 | Subsequent Address Family Identifier (1 octet) | 108 +---------------------------------------------------------+ 109 | Length of Next Hop Network Address (1 octet) | 110 +---------------------------------------------------------+ 111 | Network Address of Next Hop (variable) | 112 +---------------------------------------------------------+ 113 | Number of SNPAs (1 octet) | 114 +---------------------------------------------------------+ 115 | Length of first SNPA(1 octet) | 116 +---------------------------------------------------------+ 117 | First SNPA (variable) | 118 +---------------------------------------------------------+ 119 | Length of second SNPA (1 octet) | 120 +---------------------------------------------------------+ 121 | Second SNPA (variable) | 122 +---------------------------------------------------------+ 123 | ... | 124 +---------------------------------------------------------+ 125 | Length of Last SNPA (1 octet) | 126 +---------------------------------------------------------+ 127 | Last SNPA (variable) | 128 +---------------------------------------------------------+ 129 | Network Layer Reachability Information (variable) | 130 +---------------------------------------------------------+ 132 The use and meaning of these fields are as follows: 134 Address Family Identifier: 136 This field carries the identity of the Network Layer protocol 137 associated with the Network Address that follows. Presently 138 defined values for this field are specified in RFC1700 (see the 139 Address Family Numbers section). 141 Subsequent Address Family Identifier: 143 This field provides additional information about the type of 144 the Network Layer Reachability Information carried in the 145 attribute. 147 Length of Next Hop Network Address: 149 A 1 octet field whose value expresses the length of the 150 "Network Address of Next Hop" field as measured in octets 152 Network Address of Next Hop: 154 A variable length field that contains the Network Address of 155 the next router on the path to the destination system 157 Number of SNPAs: 159 A 1 octet field which contains the number of distinct SNPAs to 160 be listed in the following fields. The value 0 may be used to 161 indicate that no SNPAs are listed in this attribute. 163 Length of Nth SNPA: 165 A 1 octet field whose value expresses the length of the "Nth 166 SNPA of Next Hop" field as measured in semi-octets 168 Nth SNPA of Next Hop: 170 A variable length field that contains an SNPA of the router 171 whose Network Address is contained in the "Network Address of 172 Next Hop" field. The field length is an integral number of 173 octets in length, namely the rounded-up integer value of one 174 half the SNPA length expressed in semi-octets; if the SNPA 175 contains an odd number of semi-octets, a value in this field 176 will be padded with a trailing all-zero semi-octet. 178 Network Layer Reachability Information: 180 A variable length field that lists NLRI for the feasible routes 181 that are being advertised in this attribute. When the 182 Subsequent Address Family Identifier field is set to one of the 183 values defined in this document, each NLRI is encoded as 184 specified in the "NLRI encoding" section of this document. 186 The next hop information carried in the MP_REACH_NLRI path attribute 187 defines the Network Layer address of the border router that should be 188 used as the next hop to the destinations listed in the MP_NLRI 189 attribute in the UPDATE message. When advertising a MP_REACH_NLRI 190 attribute to an external peer, a router may use one of its own 191 interface addresses in the next hop component of the attribute, 192 provided the external peer to which the route is being advertised 193 shares a common subnet with the next hop address. This is known as a 194 "first party" next hop. A BGP speaker can advertise to an external 195 peer an interface of any internal peer router in the next hop 196 component, provided the external peer to which the route is being 197 advertised shares a common subnet with the next hop address. This is 198 known as a "third party" next hop information. A BGP speaker can 199 advertise any external peer router in the next hop component, 200 provided that the Network Layer address of this border router was 201 learned from an external peer, and the external peer to which the 202 route is being advertised shares a common subnet with the next hop 203 address. This is a second form of "third party" next hop 204 information. 206 Normally the next hop information is chosen such that the shortest 207 available path will be taken. A BGP speaker must be able to support 208 disabling advertisement of third party next hop information to handle 209 imperfectly bridged media or for reasons of policy. 211 A BGP speaker must never advertise an address of a peer to that peer 212 as a next hop, for a route that the speaker is originating. A BGP 213 speaker must never install a route with itself as the next hop. 215 When a BGP speaker advertises the route to an internal peer, the 216 advertising speaker should not modify the next hop information 217 associated with the route. When a BGP speaker receives the route via 218 an internal link, it may forward packets to the next hop address if 219 the address contained in the attribute is on a common subnet with the 220 local and remote BGP speakers. 222 An UPDATE message that carries the MP_REACH_NLRI must also carry the 223 ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP 224 exchanges). Moreover, in IBGP exchanges such a message must also 225 carry the LOCAL_PREF attribute. If such a message is received from an 226 external peer, the local system shall check whether the leftmost AS 227 in the AS_PATH attribute is equal to the autonomous system number of 228 the peer than sent the message. If that is not the case, the local 229 system shall send the NOTIFICATION message with Error Code UPDATE 230 Message Error, and the Error Subcode set to Malformed AS_PATH. 232 An UPDATE message that carries no NLRI, other than the one encoded in 233 the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute. 234 If such a message contains the NEXT_HOP attribute, the BGP speaker 235 that receives the message should ignore this attribute. 237 5. Multiprotocol Unreachable NLRI - MP_UNREACH_NLRI (Type Code 15): 239 This is an optional non-transitive attribute that can be used for the 240 purpose of withdrawing multiple unfeasible routes from service. 242 The attribute is encoded as shown below: 244 +---------------------------------------------------------+ 245 | Address Family Identifier (2 octets) | 246 +---------------------------------------------------------+ 247 | Subsequent Address Family Identifier (1 octet) | 248 +---------------------------------------------------------+ 249 | Withdrawn Routes (variable) | 250 +---------------------------------------------------------+ 252 The use and the meaning of these fields are as follows: 254 Address Family Identifier: 256 This field carries the identity of the Network Layer protocol 257 associated with the NLRI that follows. Presently defined values 258 for this field are specified in RFC1700 (see the Address Family 259 Numbers section). 261 Subsequent Address Family Identifier: 263 This field provides additional information about the type of 264 the Network Layer Reachability Information carried in the 265 attribute. 267 Withdrawn Routes: 269 A variable length field that lists NLRI for the routes that are 270 being withdrawn from service. When the Subsequent Address 271 Family Identifier field is set to one of the values defined in 272 this document, each NLRI is encoded as specified in the "NLRI 273 encoding" section of this document. 275 An UPDATE message that contains the MP_UNREACH_NLRI is not required 276 to carry any other path attributes. 278 6. NLRI encoding 280 The Network Layer Reachability information is encoded as one or more 281 2-tuples of the form , whose fields are described 282 below: 284 +---------------------------+ 285 | Length (1 octet) | 286 +---------------------------+ 287 | Prefix (variable) | 288 +---------------------------+ 290 The use and the meaning of these fields are as follows: 292 a) Length: 294 The Length field indicates the length in bits of the address 295 prefix. A length of zero indicates a prefix that matches all 296 (as specified by the address family) addresses (with prefix, 297 itself, of zero octets). 299 b) Prefix: 301 The Prefix field contains an address prefix followed by enough 302 trailing bits to make the end of the field fall on an octet 303 boundary. Note that the value of trailing bits is irrelevant. 305 7. Subsequent Address Family Identifier 307 This document defines the following values for the Subsequent Address 308 Family Identifier field carried in the MP_REACH_NLRI and 309 MP_UNREACH_NLRI attributes: 311 1 - Network Layer Reachability Information used for unicast 312 forwarding 314 2 - Network Layer Reachability Information used for multicast 315 forwarding 317 3 - Network Layer Reachability Information used for both unicast 318 and multicast forwarding 320 This document reserves values 128-255 for vendor-specific 321 applications. 323 This document reserves value 0. 325 Subsequent Address Family Identifiers (other than those reserved for 326 vendor specific use) are assigned only by the IETF consensus process 327 and IESG approval. 329 8. Use of BGP Capability Negotiation 331 A BGP speaker that uses Multiprotocol Extensions should use the 332 Capability Negotiation procedures [BGP-CAP] to determine whether the 333 speaker could use Multiprotocol Extensions with a particular peer. 335 The fields in the Capabilities Optional Parameter are set as follows. 336 The Capability Code field is set to 1 (which indicates Multiprotocol 337 Extensions capabilities). The Capability Length field is set to 4. 338 The Capability Value field is defined as: 340 0 7 15 23 31 341 +-------+-------+-------+-------+ 342 | AFI | Res. | SAFI | 343 +-------+-------+-------+-------+ 345 The use and meaning of this field is as follow: 347 AFI - Address Family Identifier (16 bit), encoded the same way 348 as in the Multiprotocol Extensions 350 Res. - Reserved (8 bit) field. Should be set to 0 by the sender 351 and ignored by the receiver. 353 SAFI - Subsequent Address Family Identifier (8 bit), encoded 354 the same way as in the Multiprotocol Extensions. 356 A speaker that supports multiple tuples includes them as 357 multiple Capabilities in the Capabilities Optional Parameter. 359 To have a bi-directional exchange of routing information for a 360 particular between a pair of BGP speakers, each such 361 speaker must advertise to the other (via the Capability Negotiation 362 mechanism) the capability to support that particular 363 routes. 365 9. Security Considerations 367 This extension to BGP does not change the underlying security issues. 369 10. Acknowledgements 371 The authors would like to thank members of the IDR Working Group for 372 their review and comments. 374 11. References 376 [BGP-CAP] "Capabilities Negotiation with BGP-4", R. Chandra, J. 377 Scudder, draft-ietf-idr-bgp4-cap-neg-03.txt, February 1999 379 [BGP-4] "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter & T. Li, 380 RFC1771, March 1995 382 [IPv4] "Internet Protocol", J. Postel, September 1981 384 [RFC1700] "Assigned Numbers", J. Reynolds, J. Postel, RFC1700, 385 October 1994 (see also http://www.iana.org/iana/assignments.html) 386 12. Author Information 388 Tony Bates 389 Cisco Systems, Inc. 390 170 West Tasman Drive 391 San Jose, CA 95134 392 email: tbates@cisco.com 394 Ravi Chandra 395 Cisco Systems, Inc. 396 170 West Tasman Drive 397 San Jose, CA 95134 398 email: rchandra@cisco.com 400 Dave Katz 401 Juniper Networks, Inc. 402 3260 Jay St. 403 Santa Clara, CA 95054 404 email: dkatz@jnx.com 406 Yakov Rekhter 407 Cisco Systems, Inc. 408 170 West Tasman Drive 409 San Jose, CA 95134 410 email: yakov@cisco.com