idnits 2.17.1 draft-ietf-idr-rfc4760bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 11, 2011) is 4854 days in the past. Is this intentional? 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 3392 (ref. 'BGP-CAP') (Obsoleted by RFC 5492) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AF' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4020 (Obsoleted by RFC 7120) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tony Bates (Skype) 3 Internet Draft Ravi Chandra (Cisco Systems) 4 Expiration Date: July 2011 Dave Katz (Juniper Networks) 5 Yakov Rekhter (Juniper Networks) 6 January 11, 2011 8 Multiprotocol Extensions for BGP-4 10 draft-ietf-idr-rfc4760bis-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (c) 2010 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Abstract 49 This document defines extensions to BGP-4 to enable it to carry 50 routing information for multiple Network Layer protocols (e.g., IPv6, 51 IPX, L3VPN, etc...). The extensions are backward compatible - a 52 router that supports the extensions can interoperate with a router 53 that doesn't support the extensions. 55 1. Specification of Requirements 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119 [RFC2119]. 61 2. Overview 63 The only three pieces of information carried by BGP-4 [BGP-4] that 64 are IPv4 specific are (a) the NEXT_HOP attribute (expressed as an 65 IPv4 address), (b) AGGREGATOR (contains an IPv4 address), and (c) 66 NLRI (expressed as IPv4 address prefixes). This document assumes that 67 any BGP speaker (including the one that supports multiprotocol 68 capabilities defined in this document) has to have an IPv4 address 69 (which will be used, among other things, in the AGGREGATOR 70 attribute). Therefore, to enable BGP-4 to support routing for 71 multiple Network Layer protocols, the only two things that have to be 72 added to BGP-4 are (a) the ability to associate a particular Network 73 Layer protocol with the next hop information, and (b) the ability to 74 associate a particular Network Layer protocol with NLRI. To identify 75 individual Network Layer protocols associated with the next hop 76 information and semantics of NLRI, this document uses a combination 77 of Address Family, as defined in [IANA-AF], and Subsequent Address 78 Family (as described in this document). 80 One could further observe that the next hop information (the 81 information provided by the NEXT_HOP attribute) is meaningful (and 82 necessary) only in conjunction with the advertisements of reachable 83 destinations - in conjunction with the advertisements of unreachable 84 destinations (withdrawing routes from service), the next hop 85 information is meaningless. This suggests that the advertisement of 86 reachable destinations should be grouped with the advertisement of 87 the next hop to be used for these destinations, and that the 88 advertisement of reachable destinations should be segregated from the 89 advertisement of unreachable destinations. 91 To provide backward compatibility, as well as to simplify 92 introduction of the multiprotocol capabilities into BGP-4, this 93 document uses two new attributes, Multiprotocol Reachable NLRI 94 (MP_REACH_NLRI) and Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI). 95 The first one (MP_REACH_NLRI) is used to carry the set of reachable 96 destinations together with the next hop information to be used for 97 forwarding to these destinations. The second one (MP_UNREACH_NLRI) is 98 used to carry the set of unreachable destinations. Both of these 99 attributes are optional and non-transitive. This way, a BGP speaker 100 that doesn't support the multiprotocol capabilities will just ignore 101 the information carried in these attributes and will not pass it to 102 other BGP speakers. 104 3. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14): 106 This is an optional non-transitive attribute that can be used for the 107 following purposes: 109 (a) to advertise a feasible route to a peer 111 (b) to permit a router to advertise the Network Layer address of 112 the router that should be used as the next hop to the destinations 113 listed in the Network Layer Reachability Information field of the 114 MP_NLRI attribute. 116 The attribute is encoded as shown below: 118 +---------------------------------------------------------+ 119 | Address Family Identifier (2 octets) | 120 +---------------------------------------------------------+ 121 | Subsequent Address Family Identifier (1 octet) | 122 +---------------------------------------------------------+ 123 | Length of Next Hop Network Address (1 octet) | 124 +---------------------------------------------------------+ 125 | Network Address of Next Hop (variable) | 126 +---------------------------------------------------------+ 127 | Reserved (1 octet) | 128 +---------------------------------------------------------+ 129 | Network Layer Reachability Information (variable) | 130 +---------------------------------------------------------+ 132 The use and meaning of these fields are as follows: 134 Address Family Identifier (AFI): 136 This field in combination with the Subsequent Address Family 137 Identifier field identifies the set of Network Layer protocols 138 to which the address carried in the Next Hop field must belong, 139 the way in which the address of the next hop is encoded, and 140 the semantics of the Network Layer Reachability Information 141 that follows. If the Next Hop is allowed to be from more than 142 one Network Layer protocol, the encoding of the Next Hop MUST 143 provide a way to determine its Network Layer protocol. 145 Presently defined values for the Address Family Identifier 146 field are specified in the IANA's Address Family Numbers 147 registry [IANA-AF]. 149 Subsequent Address Family Identifier (SAFI): 151 This field in combination with the Address Family Identifier 152 field identifies the set of Network Layer protocols to which 153 the address carried in the Next Hop must belong, the way in 154 which the address of the next hop is encoded, and the semantics 155 of the Network Layer Reachability Information that follows. If 156 the Next Hop is allowed to be from more than one Network Layer 157 protocol, the encoding of the Next Hop MUST provide a way to 158 determine its Network Layer protocol. 160 Length of Next Hop Network Address: 162 A 1-octet field whose value expresses the length of the 163 "Network Address of Next Hop" field, measured in octets. 165 Network Address of Next Hop: 167 A variable-length field that contains the Network Address of 168 the next router on the path to the destination system. The 169 Network Layer protocol associated with the Network Address of 170 the Next Hop is identified by a combination of 171 carried in the attribute. 173 Reserved: 175 A 1 octet field that MUST be set to 0, and SHOULD be ignored 176 upon receipt. 178 Network Layer Reachability Information (NLRI): 180 A variable length field that lists NLRI for the feasible routes 181 that are being advertised in this attribute. The semantics of 182 NLRI is identified by a combination of carried in 183 the attribute. 185 When the Subsequent Address Family Identifier field is set to 186 one of the values defined in this document, each NLRI is 187 encoded as specified in the "NLRI encoding" section of this 188 document. 190 The next hop information carried in the MP_REACH_NLRI path attribute 191 defines the Network Layer address of the router that SHOULD be used 192 as the next hop to the destinations listed in the MP_NLRI attribute 193 in the UPDATE message. 195 The rules for the next hop information are the same as the rules for 196 the information carried in the NEXT_HOP BGP attribute (see Section 197 5.1.3 of [BGP-4]). 199 An UPDATE message that carries the MP_REACH_NLRI MUST also carry the 200 ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP 201 exchanges). Moreover, in IBGP exchanges such a message MUST also 202 carry the LOCAL_PREF attribute. 204 An UPDATE message that carries no NLRI, other than the one encoded in 205 the MP_REACH_NLRI attribute, SHOULD NOT carry the NEXT_HOP attribute. 206 If such a message contains the NEXT_HOP attribute, the BGP speaker 207 that receives the message SHOULD ignore this attribute. 209 An UPDATE message SHOULD NOT include the same address prefix (of the 210 same ) in more than one of the following fields: WITHDRAWN 211 ROUTES field, Network Reachability Information fields, MP_REACH_NLRI 212 field, and MP_UNREACH_NLRI field. The processing of an UPDATE message 213 in this form is undefined. 215 This document RECOMMENDS that the MP_REACH_NLRI attribute be placed 216 as the very first path attribute in an UPDATE message. 218 4. Multiprotocol Unreachable NLRI - MP_UNREACH_NLRI (Type Code 15): 220 This is an optional non-transitive attribute that can be used for the 221 purpose of withdrawing multiple unfeasible routes from service. 223 The attribute is encoded as shown below: 225 +---------------------------------------------------------+ 226 | Address Family Identifier (2 octets) | 227 +---------------------------------------------------------+ 228 | Subsequent Address Family Identifier (1 octet) | 229 +---------------------------------------------------------+ 230 | Withdrawn Routes (variable) | 231 +---------------------------------------------------------+ 233 The use and the meaning of these fields are as follows: 235 Address Family Identifier (AFI): 237 This field in combination with the Subsequent Address Family 238 Identifier field identifies the set of Network Layer protocols 239 to which the address carried in the Next Hop field must belong, 240 the way in which the address of the next hop is encoded, and 241 the semantics of the Network Layer Reachability Information 242 that follows. If the Next Hop is allowed to be from more than 243 one Network Layer protocol, the encoding of the Next Hop MUST 244 provide a way to determine its Network Layer protocol. 246 Presently defined values for the Address Family Identifier 247 field are specified in the IANA's Address Family Numbers 248 registry [IANA-AF]. 250 Subsequent Address Family Identifier (SAFI): 252 This field in combination with the Address Family Identifier 253 field identifies the set of Network Layer protocols to which 254 the address carried in the Next Hop must belong, the way in 255 which the address of the next hop is encoded, and the semantics 256 of the Network Layer Reachability Information that follows. If 257 the Next Hop is allowed to be from more than one Network Layer 258 protocol, the encoding of the Next Hop MUST provide a way to 259 determine its Network Layer protocol. 261 Withdrawn Routes Network Layer Reachability Information: 263 A variable-length field that lists NLRI for the routes that are 264 being withdrawn from service. The semantics of NLRI is 265 identified by a combination of carried in the 266 attribute. 268 When the Subsequent Address Family Identifier field is set to 269 one of the values defined in this document, each NLRI is 270 encoded as specified in the "NLRI encoding" section of this 271 document. 273 An UPDATE message that contains the MP_UNREACH_NLRI is not required 274 to carry any other path attributes. 276 This document RECOMMENDS that the MP_UNREACH_NLRI attribute be placed 277 as the very first path attribute in an UPDATE message, unless the 278 UPDATE message also carries the MP_REACH_NLRI attribute, in which 279 case it is RECOMMENDED to place the MP_UNREACH_NLRI right after the 280 MP_REACH_NLRI attribute. 282 5. NLRI encoding 284 The optional Network Layer Reachability information is encoded as one 285 or more 2-tuples of the form , whose fields are 286 described below: 288 +---------------------------+ 289 | Length (1 octet) | 290 +---------------------------+ 291 | Prefix (variable) | 292 +---------------------------+ 294 The use and the meaning of these fields are as follows: 296 a) Length: 298 The Length field indicates the length, in bits, of the address 299 prefix. A length of zero indicates a prefix that matches all 300 (as specified by the address family) addresses (with prefix, 301 itself, of zero octets). 303 b) Prefix: 305 The Prefix field contains an address prefix followed by enough 306 trailing bits to make the end of the field fall on an octet 307 boundary. Note that the value of trailing bits is irrelevant. 309 6. Subsequent Address Family Identifier 311 This document defines the following values for the Subsequent Address 312 Family Identifier field carried in the MP_REACH_NLRI and 313 MP_UNREACH_NLRI attributes: 315 1 - Network Layer Reachability Information used for unicast 316 forwarding 318 2 - Network Layer Reachability Information used for multicast 319 forwarding 321 An implementation MAY support all, some, or none of the Subsequent 322 Address Family Identifier values defined in this document. 324 7. Error Handling 326 If a BGP speaker receives from a neighbor an UPDATE message that 327 contains the MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and if the 328 speaker determines that the attribute is incorrect, the speaker MUST 329 delete all the BGP routes received from that neighbor whose AFI/SAFI 330 is the same as the one carried in the incorrect MP_REACH_NLRI or 331 MP_UNREACH_NLRI attribute. For the duration of the BGP session over 332 which the UPDATE message was received, the speaker then SHOULD ignore 333 all the subsequent routes with that AFI/SAFI received over that 334 session. 336 In addition, the speaker MAY terminate the BGP session over which the 337 UPDATE message was received. The session SHOULD be terminated with 338 the Notification message code/subcode indicating "UPDATE Message 339 Error"/"Optional Attribute Error". 341 If a BGP speaker receives from a neighbor an UPDATE message that 342 contains a valid MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and if 343 the speaker determines that the attribute has no NLRI, the speaker 344 MUST NOT treat this UPDATE message as a BGP error, and specifically 345 MUST NOT terminate the BGP session over which the UPDATE was 346 received, and MUST NOT ignore all the subsequent routes received over 347 that session with the AFI/SAFI carried in the attribute. This is 348 irrespective of whether the received message contains any non-empty 349 Withdrawn Routes, and/or non-empty Network Layer Reachability 350 Information fields. 352 8. Use of BGP Capability Advertisement 354 A BGP speaker that uses Multiprotocol Extensions SHOULD use the 355 Capability Advertisement procedures [BGP-CAP] to determine whether 356 the speaker could use Multiprotocol Extensions with a particular 357 peer. 359 The fields in the Capabilities Optional Parameter are set as follows. 360 The Capability Code field is set to 1 (which indicates Multiprotocol 361 Extensions capabilities). The Capability Length field is set to 4. 362 The Capability Value field is defined as: 364 The use and meaning of this field is as follow: 366 0 7 15 23 31 367 +-------+-------+-------+-------+ 368 | AFI | Res. | SAFI | 369 +-------+-------+-------+-------+ 371 AFI - Address Family Identifier (16 bit), encoded the same way 372 as in the Multiprotocol Extensions 374 Res. - Reserved (8 bit) field. MUST be set to 0 by the sender 375 and MUST be ignored by the receiver. 377 SAFI - Subsequent Address Family Identifier (8 bit), encoded 378 the same way as in the Multiprotocol Extensions. 380 A speaker that supports multiple tuples includes them as 381 multiple Capabilities in the Capabilities Optional Parameter. 383 To have a bi-directional exchange of routing information for a 384 particular between a pair of BGP speakers, each such 385 speaker MUST advertise to the other (via the Capability Advertisement 386 mechanism) the capability to support that particular 387 routes. 389 9. IANA Considerations 391 As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI 392 attributes contain the Subsequence Address Family Identifier (SAFI) 393 field. The SAFI name space is defined in this document. The IANA 394 registered and maintains values for the SAFI namespace as follows: 396 - SAFI values 1 and 2 are assigned in this document. 398 - SAFI value 3 is reserved. It was assigned by RFC 2858 for a use 399 that was never fully implemented, so it is deprecated by this 400 document. 402 - SAFI values 5 through 63 are to be assigned by IANA using either 403 the Standards Action process, defined in [RFC2434], or the Early 404 IANA Allocation process, defined in [RFC4020]. 406 - SAFI values 67 through 127 are to be assigned by IANA, using the 407 "First Come First Served" policy, defined in RFC 2434. 409 - SAFI values 0 and 255 are reserved. 411 - SAFI values 128 through 240 are part of the previous "private 412 use" range. At the time of approval of this document, the unused 413 values were provided to IANA by the Routing Area Director. These 414 unused values, namely, 130, 131, 135 through 139, and 141 through 415 240, are considered reserved in order to avoid conflicts. 417 - SAFI values 241 through 254 are for "private use", and values in 418 this range are not to be assigned by IANA. 420 10. Comparison with RFC4760 422 This document explicitly spells out that receiving an UPDATE message 423 that carried MP_REACH_NLRI or MP_UNREACH_NLRI attribute, with the 424 attribute carrying no NLRI, must not be treated as an error. 426 This document also recommends that that the MP_REACH_NLRI and 427 MP_UNREACH_NLRI attributes be placed as the very first path 428 attributes in an UPDATE in this case. 430 11. Comparison with RFC2858 432 This document makes the use of the next hop information consistent 433 with the information carried in the NEXT_HOP BGP path attribute. 435 This document removes the definition of SAFI 3, and deprecates SAFI 436 3. 438 This document changes partitioning of the SAFI space. Specifically, 439 in RFC 2858 SAFI values 128 through 240 were part of the "private 440 use" range. This document specifies that of this range, allocations 441 that are currently in use are to be recognized by IANA, and that 442 unused values, namely 130, 131, 135 through 139, and 141 through 240, 443 should be considered reserved. 445 This document renames the Number of SNPAs field to Reserved, and 446 removes the rest of the SNPA-related information from the 447 MP_REACH_NLRI attribute. 449 12. Comparison with RFC 2283 451 This document restricts the MP_REACH_NLRI attribute to carry only a 452 single instance of . 454 This document restricts the MP_UNREACH_NLRI attribute to carry only a 455 single instance of . 457 This document clarifies handling of an UPDATE message that carries no 458 NLRI, other than the one encoded in the MP_REACH_NLRI attribute. 460 This document clarifies error handling in the presence of 461 MP_REACH_NLRI or MP_UNREACH_NLRI attributes. 463 This document specifies the use of BGP Capabilities Advertisements in 464 conjunction with multi-protocol extensions. 466 Finally, this document includes the "IANA Consideration" section. 468 13. Security Considerations 470 This extension to BGP does not change the underlying security issues 471 inherent in the existing BGP. 473 14. Acknowledgements 475 The authors would like to thank members of the IDR Working Group for 476 their review and comments. We also acknowledge comments from Keyur 477 Patel. 479 15. Normative References 481 [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement 482 with BGP-4", RFC 3392, November 2002. 484 [BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 485 Protocol 4 (BGP-4)", RFC 4271, January 2006. 487 [IANA-AF] "Address Family Numbers", Reachable from 488 http://www.iana.org/numbers.html 490 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 491 Requirement Levels", BCP 14, RFC 2119, March 1997. 493 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 494 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 496 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 497 Standards Track Code Points", BCP 100, RFC 4020, February 2005. 499 16. Authors' Addresses 501 Tony Bates 502 Skype 504 Ravi Chandra 505 Cisco Systems 506 EMail: rchandra@cisco.com 508 Dave Katz 509 Juniper Networks, Inc. 510 EMail: dkatz@juniper.net 512 Yakov Rekhter 513 Juniper Networks, Inc. 514 EMail: yakov@juniper.net