idnits 2.17.1 draft-ietf-idr-bgp-extended-messages-16.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 updates RFC4271, but the abstract doesn't seem to directly say this. It does mention RFC4271 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC4271, updated by this document, for RFC5378 checks: 2006-01-13) -- 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 (February 11, 2017) is 2603 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) == Missing Reference: 'RFC4724' is mentioned on line 161, but not defined == Missing Reference: 'RFC7543' is mentioned on line 163, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-sidr-bgpsec-overview-02 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-07 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft Internet Initiative Japan 4 Updates: 4271 (if approved) K. Patel 5 Intended status: Standards Track Arrcus, Inc. 6 Expires: August 15, 2017 D. Ward 7 Cisco Systems 8 February 11, 2017 10 Extended Message support for BGP 11 draft-ietf-idr-bgp-extended-messages-16 13 Abstract 15 The BGP specification mandates a maximum BGP message size of 4096 16 octets. As BGP is extended to support newer AFI/SAFIs, there is a 17 need to extend the maximum message size beyond 4096 octets. This 18 document updates the BGP specification RFC 4271 by providing an 19 extension to BGP to extend its current message size from 4096 octets 20 to 65535 octets. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 26 be interpreted as described in RFC 2119 [RFC2119] only when they 27 appear in all upper case. They may also appear in lower or mixed 28 case as English words, without normative meaning. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 15, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. BGP Extended Message . . . . . . . . . . . . . . . . . . . . 2 66 3. Extended message Capability for BGP . . . . . . . . . . . . . 3 67 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 3 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 4 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 74 9.2. Informative References . . . . . . . . . . . . . . . . . 4 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 77 1. Introduction 79 The BGP specification RFC4271 [RFC4271] mandates a maximum BGP 80 message size of 4096 octets. As BGP is extended to support newer 81 AFI/SAFIs and newer capabilities (e.g., 82 [I-D.ietf-sidr-bgpsec-overview]), there is a need to extend the 83 maximum message size beyond 4096 octets. This draft provides an 84 extension to BGP to extend its current message size limit from 4096 85 octets to 65535 octets. 87 2. BGP Extended Message 89 A BGP message over 4096 octets in length is a BGP Extended Message. 91 BGP Extended Messages have maximum message size of 65535 octets. The 92 smallest message that may be sent consists of a BGP header without a 93 data portion (19 octets). 95 Multi-octet fields MUST be in network byte order. 97 3. Extended message Capability for BGP 99 To advertise the BGP Extended Message Capability to a peer, a BGP 100 speaker uses BGP Capabilities Advertisement [RFC5492]. By 101 advertising the BGP Extended Message Capability to a peer, a BGP 102 speaker conveys that it is able to send, receive, and properly handle 103 BGP Extended Messages. 105 A peer which does not advertise this capability MUST NOT send BGP 106 Extended Messages, and BGP Extended Messages MUST NOT be sent to it. 108 The BGP Extended Message Capability is a new BGP Capability [RFC5492] 109 defined with Capability code TBD and Capability length 0. 111 4. Operation 113 A BGP speaker that is willing to send and receive BGP Extended 114 Messages from its peer should advertise the BGP Extended Message 115 Capability to its peer using BGP Capabilities Advertisement 116 [RFC5492]. A BGP speaker may send extended messages to its peer only 117 if it has received the Extended Message Capability from its peer. 119 An implementation that supports the BGP Extended Messages MUST be 120 prepared to receive an OPEN message that is larger than 4096 bytes. 122 Applications generating messages which might be encapsulated within 123 BGP messages MUST limit the size of their payload to take into 124 account the maximum message size and all encapsulation overheads on 125 the path the encapsulated data are expected to traverse. 127 5. Error Handling 129 A BGP speaker that has the ability to use extended messages but has 130 not advertised the BGP Extended Messages capability, presumably due 131 to configuration, SHOULD NOT accept an extended message. A speaker 132 MAY implement a more liberal policy and accept extended messages even 133 from a peer that has not advertised the capability. 135 However, a BGP speaker that does not advertise the BGP Extended 136 Messages capability might also genuinely not support extended 137 messages. Such a speaker would be expected to follow the error 138 handling procedures of [RFC4271], Section 6.1, and reset the session 139 with a Bad Message Length NOTIFICATION if it receives an extended 140 message. A speaker that treats an improper extended message as a 141 fatal error, as described in the preceding paragraph, MUST do 142 likewise. 144 The inconsistency between the local and remote BGP speakers MUST be 145 reported via syslog and/or SNMP. 147 6. Acknowledgements 149 The authors thank Enke Chen, Susan Hares, John Scudder, John Levine, 150 and Job Snijders for their input. 152 7. IANA Considerations 154 The IANA is requested to register a new BGP Capability Code to be 155 named BGP Extended Message Capability and referring to this document. 157 Registry: BGP Capability Code 159 Value Description Document 160 ----- ----------------------------------- ------------- 161 64 Graceful Restart Capability [RFC4724] 162 .... 163 72 CP-ORF Capability [RFC7543] 164 ... 165 TBD BGP-Extended Message [this draft] 167 8. Security Considerations 169 This extension to BGP does not change BGP's underlying security 170 issues. It does enable large BGPsec BGPSEC_PATHs, see 171 [I-D.ietf-sidr-bgpsec-protocol] 173 9. References 175 9.1. Normative References 177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 178 Requirement Levels", BCP 14, RFC 2119, March 1997. 180 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 181 Protocol 4 (BGP-4)", RFC 4271, January 2006. 183 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 184 with BGP-4", RFC 5492, February 2009. 186 9.2. Informative References 188 [I-D.ietf-sidr-bgpsec-overview] 189 Lepinski, M. and S. Turner, "An Overview of BGPSEC", 190 draft-ietf-sidr-bgpsec-overview-02 (work in progress), May 191 2012. 193 [I-D.ietf-sidr-bgpsec-protocol] 194 Lepinski, M., "BGPSEC Protocol Specification", draft-ietf- 195 sidr-bgpsec-protocol-07 (work in progress), February 2013. 197 Authors' Addresses 199 Randy Bush 200 Internet Initiative Japan 201 5147 Crystal Springs 202 Bainbridge Island, Washington 98110 203 US 205 Email: randy@psg.com 207 Keyur Patel 208 Arrcus, Inc. 210 Email: keyur@arrcus.com 212 Dave Ward 213 Cisco Systems 214 170 W. Tasman Drive 215 San Jose, CA 95134 216 USA 218 Email: dward@cisco.com