idnits 2.17.1 draft-ietf-idr-ext-opt-param-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 : ---------------------------------------------------------------------------- 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 13, 2015) is 3389 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Chen 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track J. Scudder 5 Expires: July 17, 2015 Juniper Networks 6 January 13, 2015 8 Extended Optional Parameters Length for BGP OPEN Message 9 draft-ietf-idr-ext-opt-param-03 11 Abstract 13 The Optional Parameters in the BGP OPEN message as defined in the 14 base BGP specification are limited to 255 octets due to a one-octet 15 length field. BGP Capabilities are carried in this field and may 16 foreseeably exceed 255 octets in the future, leading to concern about 17 this limitation. 19 In this document we extend the BGP OPEN length field in a backward- 20 compatible manner. The Parameter Length field of individual Optional 21 Parameters is similarly extended. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 17, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 1. Introduction 57 The Optional Parameters Length field in the BGP OPEN message is 58 defined in the base BGP specification [RFC4271] as one octet, thus 59 limiting the Optional Parameters field in the OPEN message to 255 60 octets. As BGP Capabilities [RFC5492] are carried in the Optional 61 Parameters field, and new BGP capabilities continue to be introduced, 62 the limitation is becoming a concern for BGP development. 64 In this document we extend the BGP OPEN length field in a backward- 65 compatible manner. The Parameter Length field of individual Optional 66 Parameters is similarly extended. This is done by using Optional 67 Parameters Length of 255 combined with Optional Parameter Type 255 as 68 a distinguished value pair, which indicates that an extended Optional 69 Parameters Length field follows. In this case the Parameter Length 70 field of the Optional Parameters in the BGP OPEN message is also 71 extended. 73 1.1. Requirements Language 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 [RFC2119]. 79 2. Protocol Extensions 81 This document reserves Optional Parameter Type code 255 as the 82 "Extended Length" type code. 84 In the event that the length of Optional Parameters in the BGP OPEN 85 message does not exceed 255, the encodings of the base BGP 86 specification [RFC4271] MUST be used without alteration. 88 However, if the length of Optional Parameters is greater than 255, 89 four octets are used for the length field. Each of the first two 90 octets is set to 255, and the remaining two octets carry the actual 91 length. In addition, the "Parameter Length" field of each Optional 92 Parameter is enlarged to two octets. Other than the larger sizes of 93 the given fields, there is no change to the BGP OPEN message defined 94 in [RFC4271]. 96 Accordingly, when the length of Optional Parameters in the BGP OPEN 97 message is greater than 255, the OPEN message format is modified to 98 be the following: 100 0 1 2 3 101 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 102 +-+-+-+-+-+-+-+-+ 103 | Version | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | My Autonomous System | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Hold Time | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | BGP Identifier | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | 0xFF | 0xFF | Extended Opt. Parm. Length | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | | 114 | Optional Parameters (variable) | 115 | | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 Likewise, in that situation the Optional Parameters encoding is 119 modified to be the following: 121 0 1 2 122 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Parm. Type | Parameter Length | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 ~ Parameter Value (variable) ~ 127 | | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 In parsing an OPEN message, a BGP speaker MUST use the value of the 131 one-octet "Optional Parameters Length" field and the value of the 132 octet following it to determine the encoding of the Optional 133 Parameters length, as well as the size of the "Parameter Length" 134 field of the Optional Parameters. If both values are 255, then the 135 four-octet encoding described above is used for the Optional 136 Parameters length. Otherwise the encoding defined in [RFC4271] is 137 used. 139 This encoding is chosen for backward compatibility reasons -- a BGP 140 speaker which has not been upgraded to support this specification may 141 legitimately send Optional Parameters whose length equals exactly 142 255, thus the Optional Parameters Length field alone is insufficient 143 as an indicator. However, such a speaker would never legitimately 144 send an Optional Parameter whose type code is 255, since that value 145 has been reserved by this specification. 147 3. Errors 149 If a BGP speaker supporting this specification (a "new speaker") is 150 peering with one which does not (an "old speaker") no 151 interoperability issues arise unless the new speaker needs to encode 152 Optional Parameters whose length exceeds 255. In that case, it will 153 transmit an OPEN message which the old speaker will interpret as 154 containing an Optional Parameter with type code 255. Since by 155 definition the old speaker will not recognize that type code, the old 156 speaker may be expected to close the connection with a NOTIFICATION 157 with an Error Code of OPEN Message Error and an Error Subcode of 158 Unsupported Optional Parameters, according to Section 6.2 of 159 [RFC4271]. 161 Although the above is the most likely error to be sent, it is not 162 impossible that the old speaker might detect some other error first, 163 such as a length error, depending on the details of the 164 implementation. In no case would the peering be expected to 165 establish successfully; the only question is which NOTIFICATION would 166 be generated. 168 We note that in any case, such a peering could not succeed, since by 169 definition the extended length encoding would not be used by the new 170 speaker unless the basic encoding was insufficient. 172 4. IANA Considerations 174 IANA is requested to designate BGP OPEN Optional Parameter Type code 175 255 as the Extended Length type code. 177 5. Security Considerations 179 This extension to BGP does not change the underlying security issues. 181 6. Acknowledgements 183 The authors would like to thank Yakov Rekhter and Srihari Sangli for 184 discussing various options to enlarge the Optional Parameters field. 185 We would also like to thank Pradosh Mohapatra, Keyur Patel and Hannes 186 Gredler for their valuable comments. 188 7. References 190 7.1. Normative References 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, March 1997. 195 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 196 Protocol 4 (BGP-4)", RFC 4271, January 2006. 198 7.2. Informative References 200 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 201 with BGP-4", RFC 5492, February 2009. 203 Authors' Addresses 205 Enke Chen 206 Cisco Systems 208 Email: enkechen@cisco.com 210 John Scudder 211 Juniper Networks 213 Email: jgs@juniper.net