idnits 2.17.1 draft-ietf-idr-rfc4760bis-03.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC4760, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 16, 2011) is 4637 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AF' ** Obsolete normative reference: RFC 5226 (ref. 'RFC2434') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 4020 (Obsoleted by RFC 7120) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 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: February 2012 Dave Katz (Juniper Networks) 5 Intended Status: Proposed Standard Yakov Rekhter (Juniper Networks) 6 Obsoletes: 4760 August 16, 2011 8 Multiprotocol Extensions for BGP-4 10 draft-ietf-idr-rfc4760bis-03.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) 2011 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. Redistribution from one to another 354 A router SHALL NOT redistribute routing information received over one 355 particular combination of into another unless 356 explicitly configured. The implications of doing such redistribution 357 are numerous and serious, but outside the scope of this document. 359 If a router is explicitly configured to redistribute routing 360 information received over one particular combination of 361 over another , then when redistributing the information 362 the router MUST set NEXT_HOP to self. 364 9. Use of BGP Capability Advertisement 366 A BGP speaker that uses Multiprotocol Extensions SHOULD use the 367 Capability Advertisement procedures [BGP-CAP] to determine whether 368 the speaker could use Multiprotocol Extensions with a particular 369 peer. 371 The fields in the Capabilities Optional Parameter are set as follows. 372 The Capability Code field is set to 1 (which indicates Multiprotocol 373 Extensions capabilities). The Capability Length field is set to 4. 374 The Capability Value field is defined as: 376 0 7 15 23 31 377 +-------+-------+-------+-------+ 378 | AFI | Res. | SAFI | 379 +-------+-------+-------+-------+ 381 The use and meaning of this field is as follow: 383 AFI - Address Family Identifier (16 bit), encoded the same way 384 as in the Multiprotocol Extensions 386 Res. - Reserved (8 bit) field. MUST be set to 0 by the sender 387 and MUST be ignored by the receiver. 389 SAFI - Subsequent Address Family Identifier (8 bit), encoded 390 the same way as in the Multiprotocol Extensions. 392 A speaker that supports multiple tuples includes them as 393 multiple Capabilities in the Capabilities Optional Parameter. 395 To have a bi-directional exchange of routing information for a 396 particular between a pair of BGP speakers, each such 397 speaker MUST advertise to the other (via the Capability Advertisement 398 mechanism) the capability to support that particular 399 routes. 401 10. IANA Considerations 403 As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI 404 attributes contain the Subsequence Address Family Identifier (SAFI) 405 field. The SAFI name space is defined in this document. The IANA 406 registered and maintains values for the SAFI namespace as follows: 408 - SAFI values 1 and 2 are assigned in this document. 410 - SAFI value 3 is reserved. It was assigned by RFC 2858 for a use 411 that was never fully implemented, so it is deprecated by this 412 document. 414 - SAFI values 5 through 63 are to be assigned by IANA using either 415 the Standards Action process, defined in [RFC2434], or the Early 416 IANA Allocation process, defined in [RFC4020]. 418 - SAFI values 67 through 127 are to be assigned by IANA, using the 419 "First Come First Served" policy, defined in RFC 2434. 421 - SAFI values 0 and 255 are reserved. 423 - SAFI values 128 through 240 are part of the previous "private 424 use" range. At the time of approval of this document, the unused 425 values were provided to IANA by the Routing Area Director. These 426 unused values, namely, 130, 131, 135 through 139, and 141 through 427 240, are considered reserved in order to avoid conflicts. 429 - SAFI values 241 through 254 are for "private use", and values in 430 this range are not to be assigned by IANA. 432 11. Comparison with RFC4760 434 This document explicitly spells out that receiving an UPDATE message 435 that carried MP_REACH_NLRI or MP_UNREACH_NLRI attribute, with the 436 attribute carrying no NLRI, must not be treated as an error. 438 This document also recommends that that the MP_REACH_NLRI and 439 MP_UNREACH_NLRI attributes be placed as the very first path 440 attributes in an UPDATE in this case. 442 This document adds rules for redistribution from one to 443 another. 445 12. Comparison with RFC2858 447 This document makes the use of the next hop information consistent 448 with the information carried in the NEXT_HOP BGP path attribute. 450 This document removes the definition of SAFI 3, and deprecates SAFI 451 3. 453 This document changes partitioning of the SAFI space. Specifically, 454 in RFC 2858 SAFI values 128 through 240 were part of the "private 455 use" range. This document specifies that of this range, allocations 456 that are currently in use are to be recognized by IANA, and that 457 unused values, namely 130, 131, 135 through 139, and 141 through 240, 458 should be considered reserved. 460 This document renames the Number of SNPAs field to Reserved, and 461 removes the rest of the SNPA-related information from the 462 MP_REACH_NLRI attribute. 464 13. Comparison with RFC 2283 466 This document restricts the MP_REACH_NLRI attribute to carry only a 467 single instance of . 469 This document restricts the MP_UNREACH_NLRI attribute to carry only a 470 single instance of . 472 This document clarifies handling of an UPDATE message that carries no 473 NLRI, other than the one encoded in the MP_REACH_NLRI attribute. 475 This document clarifies error handling in the presence of 476 MP_REACH_NLRI or MP_UNREACH_NLRI attributes. 478 This document specifies the use of BGP Capabilities Advertisements in 479 conjunction with multi-protocol extensions. 481 Finally, this document includes the "IANA Consideration" section. 483 14. Security Considerations 485 This extension to BGP does not change the underlying security issues 486 inherent in the existing BGP. 488 15. Acknowledgements 490 The authors would like to thank members of the IDR Working Group for 491 their review and comments. We also acknowledge comments from Keyur 492 Patel. 494 16. Normative References 496 [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement 497 with BGP-4", RFC 5492, February 2009. 499 [BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 500 Protocol 4 (BGP-4)", RFC 4271, January 2006. 502 [IANA-AF] "Address Family Numbers", Reachable from 503 http://www.iana.org/numbers.html 505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 506 Requirement Levels", BCP 14, RFC 2119, March 1997. 508 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 509 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 511 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 512 Standards Track Code Points", BCP 100, RFC 4020, February 2005. 514 17. Authors' Addresses 516 Tony Bates 517 Skype 519 Ravi Chandra 520 Cisco Systems 521 EMail: rchandra@cisco.com 523 Dave Katz 524 Juniper Networks, Inc. 525 EMail: dkatz@juniper.net 526 Yakov Rekhter 527 Juniper Networks, Inc. 528 EMail: yakov@juniper.net