idnits 2.17.1 draft-scudder-idr-rfc3392-bis-00.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 252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 276. 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 (April 29, 2008) is 5838 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 2434 (Obsoleted by RFC 5226) 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: October 31, 2008 Sonoa Systems 6 April 29, 2008 8 Capabilities Advertisement with BGP-4 9 draft-scudder-idr-rfc3392-bis-00 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 October 31, 2008. 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 BGP peering. This 49 complicates 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 89 to Error Handling" for more details). The Error Subcode in the 90 message is set to Unsupported Capability. The message SHOULD contain 91 the capability (capabilities) that causes the speaker to send the 92 message. The decision to send the message and terminate peering is 93 local to the speaker. If terminated, such peering SHOULD NOT be re- 94 established automatically. An example of when this procedure might 95 be followed is if a BGP speaker is attempting to establish an IPv6 96 peering but determines that its peer does not support Multiprotocol 97 Extensions for BGP-4 [RFC4760]. 99 If a BGP speaker receives from its peer a capability which it does 100 not itself support, it SHOULD ignore that capability. In particular, 101 the Unsupported Capability NOTIFICATION message MUST NOT be generated 102 in response to reception of a capability which is not supported by 103 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 +------------------------------+ 122 Figure 1 124 The use and meaning of these fields are as follows: 126 Capability Code: 128 Capability Code is a one octet field that unambiguously 129 identifies individual capabilities. 131 Capability Length: 133 Capability Length is a one octet field that contains the length 134 of the Capability Value field in octets. 136 Capability Value: 138 Capability Value is a variable length field that is interpreted 139 according to the value of the Capability Code field. 141 BGP speakers SHOULD NOT include more than one instance of a 142 capability with the same Capability Code, Capability Length, and 143 Capability Value. Note however, that processing of multiple 144 instances of such capability does not require special handling, as 145 additional instances do not change the meaning of the announced 146 capability. 148 BGP speakers MAY include more than one instance of a capability (as 149 identified by the Capability Code) with non-zero Capability Length 150 field, but with different Capability Value, and either the same or 151 different Capability Length. Processing of these capability 152 instances is specific to the Capability Code and MUST be described in 153 the document introducing the new capability. 155 5. Extensions to Error Handling 157 This document defines new Error Subcode - Unsupported Capability. 158 The value of this Subcode is 7. The Data field in the NOTIFICATION 159 message SHOULD list the set of capabilities that cause the speaker to 160 send the message. Each such capability is encoded the same way as it 161 would be encoded in the OPEN message. 163 As the Overview of Operations section notes, the Unsupported 164 Capability NOTIFICATION is a way for a BGP speaker to complain that 165 its peer does not support a required capability, without which the 166 peering cannot proceed. It MUST NOT be used when a BGP speaker 167 receives a capability which it does not understand; such capabilities 168 SHOULD be ignored. 170 6. IANA Considerations 172 This document defines a Capability Optional Parameter along with a 173 Capability Code field. IANA maintains the registry for Capability 174 Code values. Capability Code value 0 is reserved. Capability Code 175 values 1 through 63 are to be assigned by IANA using the "IETF 176 Consensus" policy defined in [RFC2434]. Capability Code values 64 177 through 127 are to be assigned by IANA, using the "First Come First 178 Served" policy defined in [RFC2434]. Capability Code values 128 179 through 255 are for "Private Use" as defined in [RFC2434]. 181 7. Security Considerations 183 This extension to BGP does not change the underlying security issues 184 inherent in the existing BGP [RFC4272]. 186 8. Acknowledgements 188 The authors would like to thank members of the IDR Working Group for 189 their review and comments. 191 9. References 193 9.1. Normative References 195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 196 Requirement Levels", BCP 14, RFC 2119, March 1997. 198 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 199 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 200 October 1998. 202 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 203 Protocol 4 (BGP-4)", RFC 4271, January 2006. 205 9.2. Informative References 207 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 208 RFC 4272, January 2006. 210 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 211 "Multiprotocol Extensions for BGP-4", RFC 4760, 212 January 2007. 214 Appendix A. Comparison with RFC 2842 216 In addition to several minor editorial changes, this document also 217 clarifies how to handle multiple instances of the same capability. 219 Appendix B. Comparison with RFC 3392 221 In addition to minor editorial changes, this document also clarifies 222 the use of the Unsupported Optional Parameter NOTIFICATION message, 223 and updates references to the base BGP-4 specification [RFC4271] and 224 security analysis [RFC4272]. 226 Authors' Addresses 228 John G. Scudder 229 Juniper Networks 231 Email: jgs@juniper.net 233 Ravi Chandra 234 Sonoa Systems 236 Email: rchandra@sonoasystems.com 238 Full Copyright Statement 240 Copyright (C) The IETF Trust (2008). 242 This document is subject to the rights, licenses and restrictions 243 contained in BCP 78, and except as set forth therein, the authors 244 retain all their rights. 246 This document and the information contained herein are provided on an 247 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 248 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 249 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 250 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 251 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 252 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 254 Intellectual Property 256 The IETF takes no position regarding the validity or scope of any 257 Intellectual Property Rights or other rights that might be claimed to 258 pertain to the implementation or use of the technology described in 259 this document or the extent to which any license under such rights 260 might or might not be available; nor does it represent that it has 261 made any independent effort to identify any such rights. Information 262 on the procedures with respect to rights in RFC documents can be 263 found in BCP 78 and BCP 79. 265 Copies of IPR disclosures made to the IETF Secretariat and any 266 assurances of licenses to be made available, or the result of an 267 attempt made to obtain a general license or permission for the use of 268 such proprietary rights by implementers or users of this 269 specification can be obtained from the IETF on-line IPR repository at 270 http://www.ietf.org/ipr. 272 The IETF invites any interested party to bring to its attention any 273 copyrights, patents or patent applications, or other proprietary 274 rights that may cover technology that may be required to implement 275 this standard. Please address the information to the IETF at 276 ietf-ipr@ietf.org.