draft-white-linklocal-capability.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml2rfc.tools.ietf.org. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-white-linklocal-capability-02" ipr="trust200902" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.8 -->
  <front>
    <title>Link-Local Next Hop Capability for BGP</title>
    <author fullname="Russ White" initials="R.W." surname="White">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street/>
        </postal>
        <email>russ@riw.us</email>
      </address>
    </author>
    <author fullname="Jeff Tantsura" initials="J.T." surname="Tantsura">
      <organization>Microsoft</organization>
      <address>
        <postal>
          <street/>
        </postal>
        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Donatas Abraitis" initials="D.A." surname="Abraitis">
      <organization>Hostinger</organization>
      <address>
        <postal>
          <street/>
        </postal>
        <email>donatas.abraitis@gmail.com</email>
      </address>
    </author>
    <date year="2022"/>
    <area>Routing</area>
    <workgroup>Interdomain Routing</workgroup>
    <abstract>
      <t>BGP, described in <xref target="RFC4271" format="default"/>, was originally designed
to provide reachability between domains and between the edges of a domain.
As such, BGP assumes the next hop towards any reachable destination may
not reside on the advertising speaker, but rather may either be through
a router connected to the same subnet as the speaker, or through a router
only reachable by traversing multiple hops through the network. Because
of this, BGP does not recognize the use of IPv6 link-local addresses, as
described in <xref target="RFC4291" format="default"/>, as a valid next hop for forwarding
purposes.</t>
      <t>However, BGP speakers are now often deployed on point-to-point links
in networks where multihop reachability of any kind is not assumed or
desired (all next hops are assumed to be the speaker reachable through
a directly connected point-to-point link). This is common, for instance,
in data center fabrics. In these situations, a global IPv6 address is
not required for the advertisement of reachability information; in fact,
providing global IPv6 addresses in these kinds of networks can be
detrimental to Zero Touch Provisioning (ZTP).</t>
      <t>This draft standardizes the operation of BGP over a point-to-point
link using link-local IPv6 addressing only.</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>BGP, described in <xref target="RFC4271" format="default"/>, was originally designed to
provide reachability between domains and between the edges of a domain.
As such, BGP assumes the next hop towards any reachable destination may not
reside on the advertising speaker, but rather may either be through a router
connected to the same subnet as the speaker, or through a router only
reachable by traversing multiple hops through the network. Because of this,
BGP does not recognize the use of IPv6 link-local addresses, as described
in <xref target="RFC4271" format="default"/>, as a valid next hop for forwarding purposes.</t>
      <t>However, BGP speakers are now often deployed on point-to-point links in
networks where multihop reachability of any kind is not assumed or desired
(all next hops are assumed to be the speaker reachable through a directly
connected point-to-point link). This is common, for instance, in data center
fabrics. In these situations, a global IPv6 address is not required for the
advertisement of reachability information; in fact, providing global IPv6
addresses in these kinds of networks can be detrimental to
Zero Touch Provisioning (ZTP).</t>
      <t>Such BGP deployment models require BGP to run on each
link, and any ease or simplification of BGP configuration can result
in simplifying orchestration and configuration management. This
proposal is a step in that direction.</t>
      <t>With the requirement of any global interface address being removed by
this new capability, BGP neighbor configuration can be further
simplified by making it (look) address-family independent. E.g. BGP
can just take the interface name for the peer config and link-local IPv6
address of the peer can be learned via a discovery protocol running
on the link or by an out-of-band tool. In essence, link-local next
hop in combination with <xref target="RFC5549" format="default"/> makes it possible to
achieve an unnumbered interface-like solution <xref target="RFC5309" format="default"/>
in BGP.</t>
    </section>
    <!-- end of Introduction section -->

<section numbered="true" toc="default">
      <name>Link-Local Next Hop Capability</name>
      <t>The Link-Local Next Hop capability is a new BGP capability. A
BGP speaker that supports capabilities advertisement <xref target="RFC5492" format="default"/>
in an OPEN message should send this capability only when:
      </t>
      <ol spacing="normal" type="1"><li>It is capable of sending link-local IPv6 address as the only next
              hop address for a route.</li>
        <li>The implementation is capable of processing link-local address
               next hops with the help of peer interface binding to come up with
               interface-specific next hops for its routing table.</li>
      </ol>
      <t>
The presence of this capability does not affect the support of global
IPv6 only (16 bytes next hop) and global IPv6 combined with link-local
IPv6 (32 bytes next hop), which should continue to be supported as before.

The Capability Code for this capability is TBA (based on the procedure described
in the IANA Considerations section of this document). The Capability Length field
of this capability is 0.</t>
      <t>The advantage of using this capability is that it can let two conforming
implementations interoperate <xref target="correctly" format="default"/> without additional
configuration, in contrast to the current situation. Existing implementations
of using a BGP next hop over an IPv6 link-local address are
<xref target="inconsistent" format="default"/>, and can't readily change their behavior
without negative side effects.</t>
      <t>A BGP speaker that is willing to use (send and receive) only link-local
addresses as next hops with a peer SHOULD advertise the Link-Local Next Hop
Capability to the peer using BGP Capabilities advertisement.</t>
      <t>The peers have the flexibility to include both link-local and global
next hops or link-local only next hop.</t>
    </section>
    <!-- end of Link-Local Next Hop Capability section -->

<section numbered="true" toc="default">
      <name>Changes to BGP Next Hop Attribute to Support Link-Local on Point-to-Point</name>
      <t><xref target="RFC2545" format="default"/>, section 2, notes link-local IPv6 addresses are
not generally suitable for use in the Next Hop field of the MP_REACH_NLRI.
In order to support the many uses of link-local addresses,
however, <xref target="RFC2545" format="default"/> constructs the Next Hop field in IPv6
route advertisements by setting the length of the field to 32, and including
both a link-local and global IPv6 address in the resulting enlarged field.
In this way, the receiving BGP speaker can use the global IPv6 address to
build local forwarding information, and the link-local address for ICMPv6
redirects, etc. <xref target="RFC2545" format="default"/> does not, however, provide an
explanation for situations where there is only a link-local IPv6 address
in the Next Hop field of the MP_REACH_NLRI. The result is each implementation
that supports link-local peering along with forwarding to a link-local address
has implemented the construction of the Next Hop field in the MP_REACH_NLRI
when there is only a link-local address available in slightly different
ways.</t>
      <t>If an implementation intends to send a single link-local forwarding address
in the Next Hop field of the MP_REACH_NLRI, it MUST set the length of the
Next Hop field to 16 and include only the IPv6 link-local address in the
Next Hop field.</t>
      <t>If an implementation intends to send both a link-local and global IPv6
forwarding address in the Next Hop field of the MP_REACH_NLRI, it MUST set
the length of the Next Hop field to 32 and include both the IPv6 link-local
and global IPv6 forwarding addresses in the Next Hop field. If both link
local and global IPv6 forwarding addresses are carried in the Next Hop Field,
the speaker SHOULD provide a local configuration option to determine which
address is preferred for forwarding.</t>
      <t>For internal BGP peers configured as a route-reflector, when route-reflector
isn't configured to be in the data-path, the proposed link-local (only)
next hops MUST NOT be reflected.</t>
      <t>A single (only) link-local next hop address needs to always be reset as
next hop self when passed to another link.</t>
    </section>
    <!-- end of Changes to BGP Next Hop Attribute to Support Link-Local on Point-to-Point section -->

<section numbered="true" toc="default">
      <name>Receiver Processing of IPv6 Link-Local Forwarding Addresses</name>
      <t>On receiving an MP_REACH_NLRI with a Next Hop length of 16, implementations
SHOULD form the forwarding information using the IPv6 next hop contained in
the Next Hop field, regardless of whether it is a link-local or globally
reachable IPv6 address.</t>
      <t>Implementations MAY check the validity of any IPv6 link-local address used
to calculate forwarding information by insuring the address is in the local
neighbor table for the interface on which the BGP update was received
(or through which the BGP speaker from which the update was received is
reachable). There MUST be a configuration option to enable/disable
this check.</t>
      <t>Note: It is possible that checking the IPv6 neighbor table for the
existence or validity of a link-local next hop may make instances where a link
is being overwhelmed through some form of Denial of Service (DoS) attack
worse than they would otherwise be. If the IPv6 neighbor cache is overrun
in a way that causes the link-local address being used for BGP peering to
be removed from the table, which is possible through an on-link DoS attack,
any fresh BGP update will cause the entire peering session to fail if the
implementation is checking the validity of link-local next hops as
described above. Operators should carefully assess the use of validation
against the local IPv6 neighbor table to determine if it is appropriate
for any particular peering session.</t>
    </section>
    <!-- end of Receiver Processing of IPv6 Link-Local Forwarding Addresses section -->

<section numbered="true" toc="default">
      <name>Error handling</name>
      <t>A BGP speaker receiving an MP_REACH_NLRI with the length of the
Next Hop Field set to 32, where the update contains anything other than
a link-local IPv6 address and a global IPv6 address, SHOULD consider
this a malformed UPDATE message, and proceed as described in the following
paragraphs. In order to support backward compatibility with existing
implementations, an implementation MAY ignore a second link-local IPv6 address
or 0::0/0 included with an IPv6 link-local address when the length of
the Next Hop Field is set to 32; in this case, the implementation SHOULD
report the existence of this additional information so the operator can
correct the sending BGP implementation.</t>
      <t>If the Next Hop field is malformed, the implementation MUST handle the
malformed UPDATE message using the approach of "treat-as-withdraw", as
described in section 7.3 of <xref target="RFC7606" format="default"/>. It MAY send a
NOTIFICATION message as described in section 4 of <xref target="RFC4271" format="default"/>,
using the UPDATE error message code (8 - Invalid NEXT_HOP Attribute) indicating
there is an invalid NEXT_HOP field</t>
      <t>If the Next Hop field is properly formed, but the link-local next hop is not
reachable (as determined by an examination of the IPv6 neighbor table), the
implementation MAY handle the malformed UPDATE message using the approach
of "treat-as-withdraw", as described in section 7.3 of <xref target="RFC7606" format="default"/>
(see the note above on checking the local neighbor table for the correctness of
the next hop). The implementation MAY send a NOTIFICATION message as described
in section 4 of <xref target="RFC4271" format="default"/> using
the UPDATE error message code (TBA), indicating a link-local address was
included in the MP_REACH_NLRI, but the link-local address included
cannot be reached. As this could indicate a security breach of some type
(see the security considerations section below), the operator SHOULD have
a local configuration option to terminate the peering session until manual
intervention is initiated.</t>
    </section>
    <!-- end of Error handling section -->

<section numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Vipin Kumar, Dinesh Dutt, Jeff Haas, and
for their contributions to this draft.</t>
    </section>
    <!-- end of Acknowledgements section -->

<section numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This memo requests IANA assign a number from the "Error Subcodes"
registry defined in the IANA Considerations section in
<xref target="RFC4271" format="default"/>. This allocation will be for a new UPDATE
error subcode, code (TBA), with a value of
"Unreachable Link-Local Address."</t>
      <t>Also, IANA is requested to assign a capability number to the same.</t>
    </section>
    <!-- end of IANA Considerations section -->

<section numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The mechanism described in this draft can be used as a component of ZTP for
building BGP adjacencies across point-to-point links. This method, then, can be
used by an attacker to form a peering session with a BGP speaker, ultimately
advertising incorrect routing information into a routing domain in order to
misdirect traffic or cause a denial of service. By using link-local IPv6
addresses, the attacker would be able to forego the use of a valid IPv6
address within the domain, making such an attack easier.</t>
      <t>Operators SHOULD carefully consider security when deploying link-local
addresses for BGP peering. Operators SHOULD filter traffic on links where
BGP peering is not intended to occur to prevent speakers from accepting
BGP session requests, as well as other mechanisms described in
<xref target="RFC7454" format="default"/>.</t>
      <t>Operators MAY also use some form of cryptographic validation on links
within the network to prevent unauthorized devices from forming BGP
peering sessions. Authentication, such as the TCP authentication described
in <xref target="RFC5925" format="default"/>, may provide some relief if it is present
and correctly configured. However, the distribution and management of
keys in an environment where global addresses are not present on BGP speakers
may be challenging.</t>
      <t>Operators also MAY instruct a BGP peer which has received an UPDATE
with an unreachable NEXT_HOP to disable the peering session over which
the invalid NEXT_HOP was received pending manual intervention.</t>
    </section>
    <!-- end of Security Considerations section -->

</middle>
  <back>
    <!-- References split into informative and normative -->

<references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2545" target="https://www.rfc-editor.org/info/rfc2545" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2545.xml">
          <front>
            <title>Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing</title>
            <author initials="P." surname="Marques" fullname="P. Marques">
              <organization/>
            </author>
            <author initials="F." surname="Dupont" fullname="F. Dupont">
              <organization/>
            </author>
            <date year="1999" month="March"/>
            <abstract>
              <t>BGP-4 Multiprotocol Extensions (BGP-MP) defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2545"/>
          <seriesInfo name="DOI" value="10.17487/RFC2545"/>
        </reference>
        <reference anchor="RFC4271" target="https://www.rfc-editor.org/info/rfc4271" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml">
          <front>
            <title>A Border Gateway Protocol 4 (BGP-4)</title>
            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor">
              <organization/>
            </author>
            <author initials="T." surname="Li" fullname="T. Li" role="editor">
              <organization/>
            </author>
            <author initials="S." surname="Hares" fullname="S. Hares" role="editor">
              <organization/>
            </author>
            <date year="2006" month="January"/>
            <abstract>
              <t>This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t>
              <t>The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems.  This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t>
              <t>BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR).  These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP.  BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t>
              <t>This document obsoletes RFC 1771.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4271"/>
          <seriesInfo name="DOI" value="10.17487/RFC4271"/>
        </reference>
        <reference anchor="RFC4291" target="https://www.rfc-editor.org/info/rfc4291" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml">
          <front>
            <title>IP Version 6 Addressing Architecture</title>
            <author initials="R." surname="Hinden" fullname="R. Hinden">
              <organization/>
            </author>
            <author initials="S." surname="Deering" fullname="S. Deering">
              <organization/>
            </author>
            <date year="2006" month="February"/>
            <abstract>
              <t>This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol.  The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t>
              <t>This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture".   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4291"/>
          <seriesInfo name="DOI" value="10.17487/RFC4291"/>
        </reference>
        <reference anchor="RFC5309" target="https://www.rfc-editor.org/info/rfc5309" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5309.xml">
          <front>
            <title>Point-to-Point Operation over LAN in Link State Routing Protocols</title>
            <author initials="N." surname="Shen" fullname="N. Shen" role="editor">
              <organization/>
            </author>
            <author initials="A." surname="Zinin" fullname="A. Zinin" role="editor">
              <organization/>
            </author>
            <date year="2008" month="October"/>
            <abstract>
              <t>The two predominant circuit types used by link state routing protocols are point-to-point and broadcast.  It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically.  This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing.  This memo provides information for the  Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5309"/>
          <seriesInfo name="DOI" value="10.17487/RFC5309"/>
        </reference>
        <reference anchor="RFC5492" target="https://www.rfc-editor.org/info/rfc5492" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5492.xml">
          <front>
            <title>Capabilities Advertisement with BGP-4</title>
            <author initials="J." surname="Scudder" fullname="J. Scudder">
              <organization/>
            </author>
            <author initials="R." surname="Chandra" fullname="R. Chandra">
              <organization/>
            </author>
            <date year="2009" month="February"/>
            <abstract>
              <t>This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.</t>
              <t>This document obsoletes RFC 3392.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5492"/>
          <seriesInfo name="DOI" value="10.17487/RFC5492"/>
        </reference>
        <reference anchor="RFC5549" target="https://www.rfc-editor.org/info/rfc5549" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5549.xml">
          <front>
            <title>Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop</title>
            <author initials="F." surname="Le Faucheur" fullname="F. Le Faucheur">
              <organization/>
            </author>
            <author initials="E." surname="Rosen" fullname="E. Rosen">
              <organization/>
            </author>
            <date year="2009" month="May"/>
            <abstract>
              <t>Multiprotocol BGP (MP-BGP) specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI).  The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI.  This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol.  This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5549"/>
          <seriesInfo name="DOI" value="10.17487/RFC5549"/>
        </reference>
        <reference anchor="RFC5925" target="https://www.rfc-editor.org/info/rfc5925" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml">
          <front>
            <title>The TCP Authentication Option</title>
            <author initials="J." surname="Touch" fullname="J. Touch">
              <organization/>
            </author>
            <author initials="A." surname="Mankin" fullname="A. Mankin">
              <organization/>
            </author>
            <author initials="R." surname="Bonica" fullname="R. Bonica">
              <organization/>
            </author>
            <date year="2010" month="June"/>
            <abstract>
              <t>This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5).  TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5.  TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints.  The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes.  TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously.  TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5925"/>
          <seriesInfo name="DOI" value="10.17487/RFC5925"/>
        </reference>
        <reference anchor="RFC7454" target="https://www.rfc-editor.org/info/rfc7454" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7454.xml">
          <front>
            <title>BGP Operations and Security</title>
            <author initials="J." surname="Durand" fullname="J. Durand">
              <organization/>
            </author>
            <author initials="I." surname="Pepelnjak" fullname="I. Pepelnjak">
              <organization/>
            </author>
            <author initials="G." surname="Doering" fullname="G. Doering">
              <organization/>
            </author>
            <date year="2015" month="February"/>
            <abstract>
              <t>The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains.  Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances.</t>
              <t>This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering.  It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System (AS) path filtering, route flap dampening, and BGP community scrubbing.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="194"/>
          <seriesInfo name="RFC" value="7454"/>
          <seriesInfo name="DOI" value="10.17487/RFC7454"/>
        </reference>
        <reference anchor="RFC7606" target="https://www.rfc-editor.org/info/rfc7606" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7606.xml">
          <front>
            <title>Revised Error Handling for BGP UPDATE Messages</title>
            <author initials="E." surname="Chen" fullname="E. Chen" role="editor">
              <organization/>
            </author>
            <author initials="J." surname="Scudder" fullname="J. Scudder" role="editor">
              <organization/>
            </author>
            <author initials="P." surname="Mohapatra" fullname="P. Mohapatra">
              <organization/>
            </author>
            <author initials="K." surname="Patel" fullname="K. Patel">
              <organization/>
            </author>
            <date year="2015" month="August"/>
            <abstract>
              <t>According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session.  This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes.  Finally, it revises the error handling procedures for a number of existing attributes.</t>
              <t>This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7606"/>
          <seriesInfo name="DOI" value="10.17487/RFC7606"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="correctly" target="https://github.com/frrouting/frr/commit/606fdbb1fab98bac305dca3d19eb38b140b7c3e6">
          <front>
            <title>FRRouting - An example of inconsistent interoperational implementation</title>
            <author initials="D.A." surname="Abraitis" fullname="Donatas Abraitis">
              <organization abbrev="Hostinger">Hostinger</organization>
            </author>
            <date year="2020"/>
          </front>
        </reference>
        <reference anchor="inconsistent" target="https://gitlab.nic.cz/labs/bird/-/commit/17de3a023f7bde293892b41bfafe5740c8553fc8">
          <front>
            <title>Bird - An example of inconsistent interoperational implementation</title>
            <author initials="O.Z." surname="Zajicek" fullname="Ondrej Zajicek">
              <organization abbrev="CZ.NIC Labs Projects">CZ.NIC Labs Projects</organization>
            </author>
            <date year="2020"/>
          </front>
        </reference>
      </references>
    </references>
  </back>
</rfc>