idnits 2.17.1 draft-ietf-idr-rfc3392bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 287. 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 abstract seems to indicate that this document obsoletes RFC3392, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- The document date (December 10, 2008) is 5615 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 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Scudder 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track R. Chandra 5 Expires: June 13, 2009 Sonoa Systems 6 December 10, 2008 8 Capabilities Advertisement with BGP-4 9 draft-ietf-idr-rfc3392bis-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 13, 2009. 36 Abstract 38 This document defines an Optional Parameter, called Capabilities, 39 that is expected to facilitate the introduction of new capabilities 40 in the Border Gateway Protocol (BGP) by providing graceful capability 41 advertisement without requiring that BGP peering be terminated. This 42 document obsoletes RFC 3392. 44 1. Introduction 46 The base BGP-4 specification [RFC4271] requires that when a BGP 47 speaker receives an OPEN message with one or more unrecognized 48 Optional Parameters, the speaker must terminate the BGP peering. 49 This complicates the introduction of new capabilities in BGP. 51 2. Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [RFC2119]. 57 3. Overview of Operations 59 When a BGP speaker [RFC4271] that supports capabilities advertisement 60 sends an OPEN message to its BGP peer, the message MAY include an 61 Optional Parameter, called Capabilities. The parameter lists the 62 capabilities supported by the speaker. 64 A BGP speaker determines the capabilities supported by its peer by 65 examining the list of capabilities present in the Capabilities 66 Optional Parameter carried by the OPEN message that the speaker 67 receives from the peer. 69 A BGP speaker that supports a particular capability may use this 70 capability with its peer after the speaker determines (as described 71 above) that the peer supports this capability. Simply put, a given 72 capability can be used on a peering if that capability has been 73 advertised by both peers. If either peer has not advertised it, the 74 capability cannot be used. 76 A BGP speaker determines that its peer doesn't support capabilities 77 advertisement, if in response to an OPEN message that carries the 78 Capabilities Optional Parameter, the speaker receives a NOTIFICATION 79 message with the Error Subcode set to Unsupported Optional Parameter. 80 (This is a consequence of the base BGP-4 specification [RFC4271] and 81 not a new requirement.) In this case the speaker SHOULD attempt to 82 re-establish a BGP connection with the peer without sending to the 83 peer the Capabilities Optional Parameter. 85 If a BGP speaker that supports a certain capability requires that 86 this capability be used on a peering but determines that its peer 87 doesn't support this capability, the speaker MAY send a NOTIFICATION 88 message to the peer and terminate peering (see Section "Extensions to 89 Error Handling" for more details). The Error Subcode in the message 90 is set to Unsupported Capability. The message SHOULD contain the 91 capability (capabilities) that causes the speaker to send the 92 message. The decision to send the message and terminate the peering 93 is local to the speaker. If terminated, such peering SHOULD NOT be 94 re-established automatically. An example of when this procedure 95 might be followed is if a BGP speaker is attempting to establish an 96 IPv6 peering but determines that its peer does not support 97 Multiprotocol Extensions for BGP-4 [RFC4760]. 99 If a BGP speaker receives from its peer a capability which it does 100 not itself support or recognize, it SHOULD ignore that capability. 101 In particular, the Unsupported Capability NOTIFICATION message MUST 102 NOT be generated in response to reception of a capability which is 103 not supported by the local speaker. 105 4. Capabilities Optional Parameter (Parameter Type 2): 107 This is an Optional Parameter that is used by a BGP speaker to convey 108 to its BGP peer the list of capabilities supported by the speaker. 110 The parameter contains one or more triples , where each triple is encoded as 112 shown below: 114 +------------------------------+ 115 | Capability Code (1 octet) | 116 +------------------------------+ 117 | Capability Length (1 octet) | 118 +------------------------------+ 119 | Capability Value (variable) | 120 ~ ~ 121 +------------------------------+ 123 The use and meaning of these fields are as follows: 125 Capability Code: 127 Capability Code is a one octet field that unambiguously 128 identifies individual capabilities. 130 Capability Length: 132 Capability Length is a one octet field that contains the length 133 of the Capability Value field in octets. 135 Capability Value: 137 Capability Value is a variable length field that is interpreted 138 according to the value of the Capability Code field. 140 BGP speakers SHOULD NOT include more than one instance of a 141 capability with the same Capability Code, Capability Length, and 142 Capability Value. Note however, that processing of multiple 143 instances of such capability does not require special handling, as 144 additional instances do not change the meaning of the announced 145 capability. 147 BGP speakers MAY include more than one instance of a capability (as 148 identified by the Capability Code) with non-zero Capability Length 149 field, but with different Capability Value, and either the same or 150 different Capability Length. Processing of these capability 151 instances is specific to the Capability Code and MUST be described in 152 the document introducing the new capability. 154 The Capabilities Optional Parameter (OPEN Optional Parameter Type 2) 155 SHOULD only be included in the OPEN message once. If the BGP speaker 156 wishes to include multiple capabilities in the OPEN message, it 157 SHOULD do so as discussed above, by listing all those capabilities as 158 TLVs within a single Capabilities Optional Parameter. However, for 159 backward compatibility a BGP speaker MUST be prepared to receive an 160 OPEN message which contains multiple Capabilities Optional 161 Parameters, each of which contains one or more capabilities TLVs. 162 The set of capabilities should be processed in the same way in either 163 case, whether it is enumerated within a single Capabilities Optional 164 Parameter of the OPEN message, or split across multiple. 166 5. Extensions to Error Handling 168 This document defines a new Error Subcode, Unsupported Capability. 169 The value of this Subcode is 7. The Data field in the NOTIFICATION 170 message SHOULD list the set of capabilities that cause the speaker to 171 send the message. Each such capability is encoded in the same way as 172 it would be encoded in the OPEN message. 174 As explained in the Overview of Operations section, the Unsupported 175 Capability NOTIFICATION is a way for a BGP speaker to complain that 176 its peer does not support a required capability, without which the 177 peering cannot proceed. It MUST NOT be used when a BGP speaker 178 receives a capability which it does not understand; such capabilities 179 SHOULD be ignored. 181 6. IANA Considerations 183 This document defines a Capability Optional Parameter along with a 184 Capability Code field. IANA maintains the registry for Capability 185 Code values. Capability Code value 0 is reserved. Capability Code 186 values 1 through 63 are to be assigned by IANA using the "IETF 187 Consensus" policy defined in [RFC5226]. Capability Code values 64 188 through 127 are to be assigned by IANA, using the "First Come First 189 Served" policy defined in [RFC5226]. Capability Code values 128 190 through 255 are for "Private Use" as defined in [RFC5226]. 192 7. Security Considerations 194 This extension to BGP does not change the underlying security issues 195 inherent in the existing BGP [RFC4272]. 197 8. Acknowledgements 199 The authors would like to thank members of the IDR Working Group for 200 their review and comments. 202 9. References 204 9.1. Normative References 206 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 207 Requirement Levels", BCP 14, RFC 2119, March 1997. 209 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 210 Protocol 4 (BGP-4)", RFC 4271, January 2006. 212 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 213 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 214 May 2008. 216 9.2. Informative References 218 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 219 RFC 4272, January 2006. 221 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 222 "Multiprotocol Extensions for BGP-4", RFC 4760, 223 January 2007. 225 Appendix A. Comparison with RFC 2842 227 In addition to several minor editorial changes, RFC 3392 also 228 clarified how to handle multiple instances of the same capability. 230 Appendix B. Comparison with RFC 3392 232 In addition to minor editorial changes and updated references, this 233 document also clarifies the use of the Unsupported Optional Parameter 234 NOTIFICATION message and clarifies behavior when the Capabilities 235 parameter is included in the OPEN message multiple times. 237 Authors' Addresses 239 John G. Scudder 240 Juniper Networks 242 Email: jgs@juniper.net 244 Ravi Chandra 245 Sonoa Systems 247 Email: rchandra@sonoasystems.com 249 Full Copyright Statement 251 Copyright (C) The IETF Trust (2008). 253 This document is subject to the rights, licenses and restrictions 254 contained in BCP 78, and except as set forth therein, the authors 255 retain all their rights. 257 This document and the information contained herein are provided on an 258 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 259 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 260 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 261 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 262 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 263 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 265 Intellectual Property 267 The IETF takes no position regarding the validity or scope of any 268 Intellectual Property Rights or other rights that might be claimed to 269 pertain to the implementation or use of the technology described in 270 this document or the extent to which any license under such rights 271 might or might not be available; nor does it represent that it has 272 made any independent effort to identify any such rights. Information 273 on the procedures with respect to rights in RFC documents can be 274 found in BCP 78 and BCP 79. 276 Copies of IPR disclosures made to the IETF Secretariat and any 277 assurances of licenses to be made available, or the result of an 278 attempt made to obtain a general license or permission for the use of 279 such proprietary rights by implementers or users of this 280 specification can be obtained from the IETF on-line IPR repository at 281 http://www.ietf.org/ipr. 283 The IETF invites any interested party to bring to its attention any 284 copyrights, patents or patent applications, or other proprietary 285 rights that may cover technology that may be required to implement 286 this standard. Please address the information to the IETF at 287 ietf-ipr@ietf.org.