<?xml version="1.0"?> version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8654" category="std" docName="draft-ietf-idr-bgp-extended-messages-36"
     consensus="true" ipr="trust200902" updates="4271">

<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?> docName="draft-ietf-idr-bgp-extended-messages-36"
     updates="4271" obsoletes="" submissionType="IETF" xml:lang="en"
     sortRefs="true" symRefs="true" tocInclude="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.27.0 -->
  <front>
    <title abbrev="Extended Message support Support for BGP">
           Extended Message support Support for BGP</title>

    <seriesInfo name="RFC" value="8654"/>

    <author fullname="Randy Bush" initials="R." surname="Bush">
      <organization>Arrcus &amp; IIJ</organization>
      <address>
        <postal>
          <street>5147 Crystal Springs</street>
          <city>Bainbridge Island</city>
	  <region>Washington</region>
          <region>WA</region>
          <code>98110</code>
	  <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>randy@psg.com</email>
      </address>
    </author>
    <author fullname="Keyur Patel" initials="K" surname="Patel">
      <organization>Arrcus, Inc.</organization>
      <address>
        <email>keyur@arrcus.com</email>
      </address>
    </author>
    <author fullname="Dave Ward" initials="D." surname="Ward">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>170 W. Tasman Drive</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>dward@cisco.com</email>
      </address>
    </author>

    <date/>

    <date month="October" year="2019" />

    <abstract>
      <t>The BGP specification (RFC 4271) mandates a maximum BGP message size of 4,096
    octets.  As BGP is extended to support newer AFI/SAFIs new Address Family Identifiers
    (AFIs), Subsequent AFIs (SAFIs), and other
    features, there is a need to extend the maximum message size beyond
    4,096 octets.  This document updates the BGP specification RFC4271 by
    extending the maximum message size from 4,096 octets to 65,535 octets
    for all messages except the for OPEN and KEEPALIVE messages.</t>
    </abstract>

  <note title="Requirements Language">

    <t>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 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t>

    </note>

  </front>

  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The BGP specification <xref target="RFC4271"/> target="RFC4271" format="default"/> mandates a maximum
    BGP message size of 4,096 octets.  As BGP is extended to support
    newer AFI/SAFIs
    new AFIs, SAFIs, and newer other capabilities (e.g., BGPsec <xref
    target="RFC8205"/>
    target="RFC8205" format="default"/> and BGP-LS BGP - Link
    State (BGP-LS) <xref target="RFC7752"/>), target="RFC7752" format="default"/>), there is a
    need to extend the maximum message size beyond 4,096 octets. This
    draft
    document provides an extension to BGP to extend its the message size limit
    from 4,096 octets to 65,535 octets for all messages except the for OPEN and
    KEEPALIVE messages.</t>

    <section anchor="sec-term" numbered="true" toc="default">
      <name>Requirements Language</name>

        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

    </section>

    </section>
    <section anchor="extmsg" title="BGP numbered="true" toc="default">
      <name>BGP Extended Message"> Message</name>
      <t>A BGP message over 4,096 octets in length is a BGP Extended
    Message.</t>
      <t>BGP Extended Messages have a maximum message size of 65,535
    octets.  The smallest message that may be sent consists of is a BGP
    KEEPALIVE
    KEEPALIVE, which consists of 19 octets.</t>
    </section>
    <section title="Extended numbered="true" toc="default">
      <name>BGP Extended Message Capability for BGP"> Capability</name>
      <t>The BGP Extended Message Capability is a new BGP Capability capability <xref
    target="RFC5492"/>
      target="RFC5492" format="default"/> defined with Capability code Code 6 and
      Capability
    length Length 0.</t>
      <t>To advertise the BGP Extended Message Capability to a peer, a BGP
      speaker uses BGP Capabilities Advertisement <xref
    target="RFC5492"/>. target="RFC5492"
      format="default"/>.  By advertising the BGP Extended Message Capability
      to a peer, a BGP speaker conveys that it is able to receive and properly handle, see <xref target="opns"/>,
      handle BGP Extended Messages.</t> Messages (see <xref target="opns"
      format="default"/>).</t>
      <t>Peers that wish to use the BGP Extended Message capability MUST Capability <bcp14>MUST</bcp14>
    support Error Handling error handling for BGP UPDATE Messages messages per <xref
    target="RFC7606"/>.</t> target="RFC7606"
    format="default"/>.</t>

    </section>
    <section anchor="opns" title="Operation"> numbered="true" toc="default">
      <name>Operation</name>

      <t>The BGP Extended Message Capability applies to all messages except
    for the OPEN and KEEPALIVE messages.  The former exception is to  These exceptions
    reduce the complexity of providing backward compatibility.</t>
      <t>A BGP speaker that is capable of receiving BGP
    Extended Messages SHOULD <bcp14>SHOULD</bcp14> advertise the BGP Extended Message
    Capability to its peers using BGP Capabilities Advertisement <xref
    target="RFC5492"/>.
    target="RFC5492" format="default"/>.  A BGP speaker MAY <bcp14>MAY</bcp14>
    send BGP Extended Messages to a
    peer only if the BGP Extended Message Capability was received from that
    peer.</t>

      <t>An implementation that advertises the BGP Extended Message
    capability MUST
    Capability <bcp14>MUST</bcp14> be capable of receiving a message with a Length length up
    to and including 65,535 octets.</t>

      <t>Applications generating information which that might be encapsulated
    within BGP messages MUST <bcp14>MUST</bcp14> limit the size of their payload to take the
    maximum message size into account.</t>

    <t>During the years of incremental deployment, speakers that are
    capable of Extended Messages should not simply pack as many NLRI in
    a message as they can, or otherwise unnecessarily generate UPDATES
    above the 4,096 octet pre- Extended Message limit, so as not to
    require downstream routers to decompose for peers that do not
    support Extended Messages.  See <xref target="Security"/>.</t>

      <t>If a BGP message with a Length length greater than 4,096 octets is
    received by a BGP listener who has not advertised the BGP Extended
    Message Capability, the listener will generate a NOTIFICATION with
    the Error Subcode set to Bad Message Length (<xref
    target="RFC4271"/> Sec 6.1).</t> target="RFC4271"
    sectionFormat="comma" section="6.1"/>).</t>

      <t>A BGP UPDATE will (policy, (if allowed by policy, best path, etc., allowing) etc.) typically
    propagate throughout the BGP speaking Internet; BGP-speaking Internet and hence to BGP
    speakers which that may not support BGP Extended Messages.  Therefore, an
    announcement in an a BGP Extended Message where the size of the attribute
    set plus the NLRI is larger than 4,096 octets may cause lack of
    reachability.</t>
      <t>A BGP speaker that has advertised the BGP Extended Message
    capability
    Capability to its peers, peers may receive an UPDATE from one of its peers
    that produces an ongoing announcement that is larger than 4,096
    octets.  When propagating that UPDATE onward to a neighbor which that has
    not advertised the BGP Extended Message capability, Capability, the speaker
    SHOULD
    <bcp14>SHOULD</bcp14> try to reduce the outgoing message size by removing
    attributes eligible under the "attribute discard" approach of <xref
    target="RFC7606"/>. target="RFC7606" format="default"/>.  If the message is still too big, then it must
    not be sent to the neighbor (<xref target="RFC4271"/>, Section 9.2). target="RFC4271" sectionFormat="comma"
    section="9.2"/>).

    Additionally, if the NLRI was previously advertised to that peer, it
    must be withdrawn from service (<xref target="RFC4271"/>, Section
    9.1.3).</t> target="RFC4271"
    sectionFormat="comma" section="9.1.3"/>).
    </t>

      <t>If an Autonomous System (AS) has multiple internal BGP speakers
    and also has multiple external BGP neighbors, to present a
    consistent external view care must be taken to ensure a consistent view within the AS.
    AS in order to present a consistent
    external view. In the context of BGP Extended Messages, a
    consistent view can only be guaranteed if all the iBGP Internal BGP (iBGP) speakers
    advertise the BGP Extended Message capability. Capability.  If that is not the
    case, then the operator should consider whether or not the BGP Extended
    Message capability Capability should be advertised to external peers or
    not.</t> peers.
    </t>

      <t>During the incremental deployment of BGP Extended Messages and
    use of the "attribute discard" approach of <xref target="RFC7606"/> target="RFC7606"
    format="default"/> in an iBGP mesh, mesh or with eBGP
    External BGP (eBGP) peers, the
    operator should monitor any routes dropped and any discarded
    attributes.</t>
    </section>
    <section title="Error Handling" anchor="error"> anchor="error" numbered="true" toc="default">
      <name>Error Handling</name>

      <t>A BGP speaker that has the ability to use BGP Extended Messages but
    has not advertised the BGP Extended Messages capability, Message Capability, presumably
    due to configuration, MUST NOT <bcp14>MUST NOT</bcp14> accept an a BGP Extended Message.  A
    speaker MUST NOT <bcp14>MUST NOT</bcp14> implement a more liberal policy accepting BGP
    Extended Messages.</t>

      <t>A BGP speaker that does not advertise the BGP Extended Messages
    capability Message
    Capability might also genuinely not support BGP Extended Messages.  Such
    a speaker will follow the error handling error-handling procedures of <xref
    target="RFC4271"/>
    target="RFC4271" format="default"/> if it receives an a BGP Extended Message.  Similarly,
    any speaker that treats an improper BGP Extended Message as a fatal
    error, MUST
    error <bcp14>MUST</bcp14> follow the error handling error-handling procedures of <xref
    target="RFC4271"/>.</t>

    <t> The
    target="RFC4271" format="default"/>.
      </t>

      <t>Error handling for UPDATE Message Error Handling, messages, as specified in Section 6.3
    of
    <xref target="RFC4271"/>, target="RFC4271" sectionFormat="of" section="6.3"/>, is unchanged.  However, if a
    NOTIFICATION is to be sent to a BGP speaker that has not advertised
    the BGP Extended Message Capability, the size of the message MUST
    NOT <bcp14>MUST
    NOT</bcp14> exceed 4,096 octets.</t>
      <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that BGP protocol developers and implementers
    are conservative in their application and use of BGP Extended Messages.
    Future protocol specifications MUST <bcp14>MUST</bcp14> describe how to handle peers
    which
    that can only accommodate 4,096 octet messages.</t>
    </section>

    <section anchor="rfc4171" title="Changes numbered="true" toc="default">
      <name>Changes to RFC4271"> RFC 4271</name>
      <t><xref target="RFC4271"/> target="RFC4271" format="default"/> states "The value of the Length field
    MUST
    <bcp14>MUST</bcp14> always be at least 19 and no greater than 4,096.” 4096."  This document
    changes the latter number to 65,535 for all messages except the for OPEN and
    KEEPALIVE messages.</t>

      <t><xref target="RFC4271"/> Sec 6.1, target="RFC4271" sectionFormat="of" section="6.1"/> specifies
      raising an error if the length of a message is over 4,096 octets.  For
      all messages except the for OPEN message, and KEEPALIVE messages, if the receiver has advertised the
      BGP Extended Messages Message Capability, this document raises that limit to
      65,535.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">

    <t>The IANA numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has made an early the following allocation for this new BGP Extended
    Message Capability referring to this document.</t>
    <figure>
      <artwork>
Registry: Capability Codes

Value    Description                               Document
-----    -----------------------------------       -------------
6        BGP Extended Message                      [this draft]
        </artwork>
      </figure> in the "Capability Codes"
      registry:</t>

<table anchor="ianaregistry" align="left">
<name>Addition to "Capability Codes" Registry</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>6</td>
      <td>BGP Extended Message</td>
      <td>RFC 8654</td>
    </tr>
  </tbody>
</table>

    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This extension to BGP does not change BGP's underlying security
    issues;
    issues <xref target="RFC4272"/>.</t> target="RFC4272" format="default"/>.</t>
      <t>Due to increased memory requirements for buffering, there may be
    increased exposure to resource exhaustion, intentional or
    unintentional.</t>

      <t>If a remote speaker is able to craft a large BGP Extended Message
    to send on a path where one or more peers do not support BGP
    Extended Messages, peers which that support BGP Extended Messages may act may:
    </t>

<ul spacing="normal">

    <li>act to reduce the outgoing message, see message (see <xref target="opns"/>, and target="opns"
    format="default"/>) and, in doing so so, cause an attack by discarding
    attributes one or more of its peer peers may be expecting.  The attributes eligible under the
    "attribute discard” discard" approach must have no effect on route selection or
    installation <xref
    target="RFC7606"/>.</t>

    <t>If a remote speaker is able to craft a large BGP Extended
    Message to send on a path where one or more peers do not support BGP
    Extended Messages, peers which support BGP Extended Messages may act target="RFC7606" format="default"/>.</li>

      <li>act to reduce the outgoing message, see message (see <xref target="opns"/>, and target="opns"
      format="default"/>) and, in doing so so, allow a downgrade attack.  This
      would only affect the attacker's message, where 'downgrade' has
      questionable meaning.</t>

    <t>If a remote speaker is able to craft a large BGP Extended
    Message to send on a path where one or more peers do not support BGP
    Extended Messages, peers which support BGP Extended Messages may
    incur meaning.</li>

      <li>incur resource load (processing, message resizing, etc.)
    when reformatting the large messages.</t> messages.</li>
</ul>

    </section>

  </middle>
  <back>

    <references>
      <name>References</name>

      <references>
        <name>Normative References</name>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5492.xml"/>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7606.xml"/>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      </references>

      <references>
        <name>Informative References</name>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4272.xml"/>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml"/>

<xi:include
    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8205.xml"/>

      </references>
    </references>
    <section anchor="Acknowledgments" title="Acknowledgments"> anchor="acknowledgements" numbered="false" toc="default">
     <name>Acknowledgments</name>

     <t>The authors thank Alvaro Retana for an amazing review, review; Enke Chen,
     Susan Hares, John Scudder, John Levine, and Job Snijders for their
     input; and Oliver Borchert and Kyehwan Lee for their implementations
     and testing.</t>
    </section>

  </middle>

<back>

  <references title="Normative References">
    <?rfc include="reference.RFC.2119"?>
    <?rfc include="reference.RFC.4271"?>
    <?rfc include="reference.RFC.5492"?>
    <?rfc include="reference.RFC.7606"?>
    <?rfc include="reference.RFC.8174"?>
    </references>
  <references title="Informative References">
    <?rfc include="reference.RFC.4272"?>
    <?rfc include="reference.RFC.7752"?>
    <?rfc include="reference.RFC.8205"?>
    </references>

  </back>
</rfc>