RFC 9072

Extended Optional Parameters Length for BGP OPEN Message

📅 published July 2021, from ietf

Extended Optional Parameters Length for BGP OPEN Message 🦋

Okay bestie, this one is RFC 9072 💖 from the Internet Engineering Task Force (IETF), a Standards Track doc published in July 2021. It was written by Enke Chen (Palo Alto Networks) and John Scudder (Juniper Networks), and it updates RFC 4271, which is the base BGP-4 spec. The ISSN is 2070-1721 🌈

Abstract

okay so the Optional Parameters in a BGP OPEN message are capped at 255 octets because of a one-octet length field 😭 BGP capabilities ride in that field, and they could totally outgrow 255 octets someday, which is the whole worry.

This doc updates RFC 4271 by stretching the length of the Optional Parameters in a BGP OPEN message in a backward-compatible way ✨ The Parameter Length field of each individual Optional Parameter gets stretched too.

Status of This Memo

This is an Internet Standards Track document 🎀

It's a product of the IETF and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841.

Info about its current status, any errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc9072 🔗

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes.

1.  Introduction
  1.1.  Requirements Language
2.  Update to RFC 4271
3.  Backward Compatibility
4.  IANA Considerations
5.  Security Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

okay so the Optional Parameters Length field in a BGP OPEN message is defined in the base BGP spec [RFC4271] as one octet, which caps the Optional Parameters field in the OPEN message at 255 octets. BGP capabilities [RFC5492] live in the Optional Parameters field, and new BGP capabilities keep showing up, so this limit is a real concern for BGP development 🌸

This document updates [RFC4271] by extending the length of the Optional Parameters in BGP OPEN in a backward-compatible way. It does this by using Optional Parameter type code 255 as a special marker. That marker says an extended Optional Parameters Length field follows, and that the parsing of the BGP OPEN should follow these new procedures. The Parameter Length field of each individual Optional Parameter in the BGP OPEN message gets extended as well 🦋

1.1. Requirements Language 💖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Update to RFC 4271 🎀

This document reserves Optional Parameter type code 255 as the "Extended Length" 🌷

If the length of the Optional Parameters in the BGP OPEN message does not exceed 255, the encodings of the base BGP spec [RFC4271] SHOULD be used without alteration. Configuration MAY override this to force the extended format to be used in all cases. That could be handy, for example, to test whether a peer supports this spec. (Either way, an implementation MUST accept an OPEN message that uses this spec's encoding even when the length of the Optional Parameters is 255 or less.)

But if the length of the Optional Parameters in the BGP OPEN message does exceed 255, the OPEN message MUST be encoded according to the procedure below 🫶

     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+
    |    Version    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     My Autonomous System      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Hold Time           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         BGP Identifier                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Non-Ext OP Len.|Non-Ext OP Type|  Extended Opt. Parm. Length   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |             Optional Parameters (variable)                    |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Extended Encoding OPEN Format

The Non-Extended Optional Parameters Length field (Non-Ext OP Len.) SHOULD be set to 255 on transmission and, in any event, MUST NOT be set to 0. It MUST be ignored on receipt once the use of the extended format is positively determined by inspecting the Non-Extended Optional Parameters Type (Non-Ext OP Type) field 👀

The subsequent one-octet field (which would be the first Optional Parameter Type field in the non-extended format and is called "Non-Ext OP Type" in the figure above) MUST be set to 255 on transmission. On receipt, a value of 255 in this field is the sign that the extended format is in use 🍓

In this extended encoding, the subsequent two-octet field, called the "Extended Optional Parameters Length field", is an unsigned integer. It gives the total length of the Optional Parameters field in octets. If the value of this field is zero, no Optional Parameters are present 🧚

Likewise, in that situation, the Optional Parameters encoding gets modified to look like this:

     0                   1                   2
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Parm. Type   |        Parameter Length       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~            Parameter Value (variable)         ~
    |                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Extended Parameters Format

The rules for encoding Optional Parameters are unchanged from those in [RFC4271], except that the Parameter Length field is extended to be a two-octet unsigned integer 💜

When parsing an OPEN message, if the one-octet Optional Parameters Length field (labeled "Non-Ext OP Len." in Figure 1) is non-zero, a BGP speaker MUST use the value of the octet following the one-octet Optional Parameters Length field (labeled "Non-Ext OP Type" in Figure 1) to figure out both the encoding of the Optional Parameters length and the size of the Parameter Length field of each individual Optional Parameter. If the value of the "Non-Ext OP Type" field is 255, the encoding described above is used for the Optional Parameters length. Otherwise, the encoding defined in [RFC4271] is used 🔥

3. Backward Compatibility 🌈

If a BGP speaker supporting this spec (a "new speaker") peers with one that doesn't (an "old speaker"), no interoperability issues come up unless the new speaker needs to encode Optional Parameters whose length exceeds 255. In that case, it will send an OPEN message that the old speaker reads as containing an Optional Parameter with type code 255. Since the old speaker won't recognize that type code by definition, the old speaker is expected to close the connection with a NOTIFICATION with an error code of "OPEN Message Error" and an error subcode of "Unsupported Optional Parameters", according to Section 6.2 of [RFC4271] 😬

Although Optional Parameter type code 255 is used in this specification as the indication that the extended encoding is in use, it is not a bona fide Optional Parameter type code in the usual sense, and it MUST NOT be used other than as described above. If it's encountered anywhere other than as the Non-Ext OP Type, it MUST be treated as an unrecognized Optional Parameter and handled according to [RFC4271], Section 6.2 🙈

It is not considered an error to receive an OPEN message whose Extended Optional Parameters Length value is less than or equal to 255. It is also not considered a fatal error to receive an OPEN message whose (non-extended) Optional Parameters Length value is not 255 and whose first Optional Parameter type code is 255. In that case, the encoding of this specification MUST be used for decoding the message 🧠

4. IANA Considerations 📋

IANA has assigned value 255 as the Extended Length type code in the "BGP OPEN Optional Parameter Types" registry 🌟

5. Security Considerations 🚨

This extension to BGP does not change the underlying security or confidentiality issues inherent in the existing BGP [RFC4272]. Read up on those before you ship anything 🔒

6. References 📚

6.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
           Border Gateway Protocol 4 (BGP-4)", RFC 4271,
           DOI 10.17487/RFC4271, January 2006,
           <https://www.rfc-editor.org/info/rfc4271>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

6.2. Informative References

[RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis",
           RFC 4272, DOI 10.17487/RFC4272, January 2006,
           <https://www.rfc-editor.org/info/rfc4272>.

[RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement
           with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
           2009, <https://www.rfc-editor.org/info/rfc5492>.

Acknowledgements 💌

The authors want to thank Yakov Rekhter and Srihari Sangli for talking through the different options for enlarging the Optional Parameters field. They also want to thank Matthew Bocci, Bruno Decraene, John Heasley, Jakob Heitz, Christer Holmberg, Pradosh Mohapatra, Keyur Patel, and Hannes Gredler for their valuable comments 🙌

Authors' Addresses 🦋

Enke Chen Palo Alto Networks Email: enchen@paloaltonetworks.com

John Scudder Juniper Networks Email: jgs@juniper.net

That's the whole spec, bestie! 🌈💖

📦 where this page comes from

ietf: rfc9072 2021-07
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms