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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2545 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2545.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC4659 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4659.xml">
<!ENTITY RFC4684 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4684.xml">
<!ENTITY RFC4760 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4760.xml">
<!ENTITY RFC4272 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4272.xml">
<!ENTITY RFC4798 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4798.xml">
<!ENTITY RFC4925 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4925.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC5492 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5492.xml">
<!ENTITY RFC5549 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5549.xml">
<!ENTITY RFC5565 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5565.xml">
<!ENTITY RFC6074 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6074.xml">
<!ENTITY RFC6513 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6513.xml">
<!ENTITY RFC6514 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6514.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8277 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8277.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC): -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references: -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space:
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of popular PIs --> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
     docName="draft-ietf-bess-rfc5549revision-06" number="8950" ipr="trust200902" obsoletes="RFC5549">
     obsoletes="5549" updates="" submissionType="IETF" xml:lang="en"
     tocInclude="true" tocDepth="3" consensus="true" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="rfc5549revision">Advertising abbrev="Advertising IPv4 Reachability with IPv6">Advertising IPv4
    Network Layer Reachability Information (NLRI) with an IPv6 Next Hop</title>
    <seriesInfo name="RFC" value="8950"/>
    <author fullname="Stephane Litkowski" initials="S" initials="S." surname="Litkowski">
      <organization>Cisco</organization>
      <address>
        <email>slitkows@cisco.com</email>
        <!-- <uri/> -->
      </address>
    </author>
    <author fullname="Swadesh Agrawal" initials="S" initials="S." surname="Agrawal">
      <organization>Cisco</organization>
      <address>
        <email>swaagraw@cisco.com</email>
        <!-- <uri/> -->

      </address>
    </author>
    <author fullname="Krishna Muddenahally Ananthamurthy" initials="K" initials="K." surname="Ananthamurthy">
      <organization>Cisco</organization>
      <address>
        <email>kriswamy@cisco.com</email>
        <!-- <uri/> -->

      </address>
    </author>
    <author fullname="Keyur Patel" initials="K" initials="K." surname="Patel">
      <organization>Arrcus</organization>
      <address>
        <email>keyur@arrcus.com</email>
        <!-- <uri/> -->

      </address>
    </author>
    <date year="2020"/> year="2020" month="November"/>
    <area/>
    <workgroup>BESS Working Group</workgroup>
    <!-- <keyword/> -->

<keyword>bgp</keyword>
<keyword>mvpn</keyword>
<keyword>vpnv4</keyword>
<keyword>vpnv6</keyword>

    <abstract>
      <t>
	   Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families
   is determined by the Address Family Identifier (AFI) and the
   Subsequent Address Family Identifier (SAFI).  The AFI/SAFI
   definitions for the IPv4 address family only have provisions for
   advertising a Next Hop next-hop address that belongs to the IPv4 protocol when
   advertising IPv4 Network Layer Reachability Information (NLRI) or
   VPN-IPv4 NLRI.
      </t>
      <t>
   This document specifies the extensions necessary to
   allow the advertising of IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop 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 next hop for
   IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the
   encoding of the Next Hop next hop to determine which of the protocols
   the address actually belongs to, and a BGP Capability allowing
   MP-BGP Peers peers to dynamically discover whether they can exchange IPv4
   NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. next hop. This document obsoletes RFC5549. RFC 5549.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
   <t>
	Multiprotocol BGP (MP-BGP) <xref target="RFC4760"/> target="RFC4760" format="default"/> specifies that the set of
   network-layer protocols to which the address carried in the Next Hop
   Address field may belong is determined by the Address Family Identifier (AFI)
   and the Subsequent Address Family Identifier (SAFI).  A number of
   existing AFI/SAFIs AFIs/SAFIs allow the Next Hop next-hop address to belong to a
   different address family than the Network Layer Reachability
   Information (NLRI).  For example, the AFI/SAFI &lt;25/65&gt; used (as per
   <xref target="RFC6074"/>) target="RFC6074" format="default"/>) to perform L2VPN auto-discovery, Layer 2 Virtual
   Private Network (L2VPN) auto-discovery allows advertising NLRI that contains the identifier of a Virtual Private
   LAN Service (VPLS) instance or that identifies a particular pool of
   attachment circuits at a given Provider Edge (PE), while the Next Hop
   Address field contains the loopback address of a PE.  Similarly, the AFI/SAFI
   &lt;1/132&gt; (defined in <xref target="RFC4684"/>) target="RFC4684" format="default"/>) to advertise Route Target
   (RT) membership information, information allows advertising NLRI that contains
   such RT membership information, while the Next Hop Address field contains the
   address of the advertising router.
      </t>
      <t>
   Furthermore, a number of these existing AFI/SAFIs AFIs/SAFIs allow the Next Hop next hop
   to belong to either the IPv4 protocol or the IPv6
   protocol,
   protocol and specify the encoding of the Next Hop next-hop
   information to determine which of the protocols the address
   actually belongs to.

   For example, <xref target="RFC4684"/> target="RFC4684" format="default"/> allows the Next Hop next-hop
   address to be either an IPv4 or IPv6 address and states that the
   Next Hop Address field
   address shall be interpreted as an IPv4 address whenever the length
   of Next Hop the next-hop address is 4 octets, octets and as an IPv6 address whenever the
   length of the Next Hop next-hop address is 16 octets.
      </t>
      <t>
   There are situations such as those described in <xref target="RFC4925"/> target="RFC4925"
   format="default"/> and in <xref target="RFC5565"/> target="RFC5565" format="default"/> where carriers (or large
   enterprise networks acting as a
   carrier for their internal resources) may be required to establish
   connectivity between 'islands' of networks of one address family type
   across a transit core of a differing address family type.  This
   includes both the case of IPv6 islands across an IPv4 core and the
   case of IPv4 islands across an IPv6 core.  Where Multiprotocol BGP
   (MP-BGP) is used to advertise the corresponding reachability
   information, this translates into the requirement for a BGP speaker
   to advertise Network Layer Reachability Information (NLRI) the NLRI of a given
   address family via a Next Hop next hop of a different address family (i.e.,
   IPv6 NLRI with an IPv4 Next Hop next hop and IPv4 NLRI with an IPv6 Next Hop). next hop).
      </t>
      <t>
   The AFI/SAFI definitions for the IPv6 address family assume
   that the Next Hop next-hop address belongs to the IPv6 address family type.
   Specifically, as per <xref target="RFC2545"/> target="RFC2545" format="default"/> and <xref target="RFC8277"/>, target="RFC8277" format="default"/>, when the &lt;AFI/SAFI&gt; is
   &lt;2/1&gt;, &lt;2/2&gt;, or &lt;2/4&gt;, the Next Hop next-hop address is assumed
   to be of an IPv6
   type.  As per <xref target="RFC4659"/>, target="RFC4659" format="default"/>, when the &lt;AFI/SAFI&gt; is &lt;2/128&gt;, the Next Hop next-hop
   address is assumed to be of a VPN-IPv6 type.
      </t>
      <t>
   However, <xref target="RFC4798"/> target="RFC4798" format="default"/> and <xref target="RFC4659"/> target="RFC4659" format="default"/>
   specify how an IPv4 address can be
   encoded inside the Next Hop next-hop IPv6 address field when IPv6 NLRI needs
   to be advertised with an IPv4 Next Hop. next hop.  <xref target="RFC4798"/> target="RFC4798" format="default"/> defines how the
   IPv4-mapped IPv6 address format specified in the IPv6 addressing
   architecture (<xref target="RFC4291"/>) target="RFC4291" format="default"/>) can be
   used for that purpose when the &lt;AFI/
   SAFI&gt; &lt;AFI/SAFI&gt; is &lt;2/1&gt;,
   &lt;2/2&gt;, or &lt;2/4&gt;.  <xref target="RFC4659"/> target="RFC4659"
   format="default"/> defines how the IPv4-
   mapped IPv4-mapped IPv6 address format
   as well as a null Route Distinguisher (RD) can
   be used for that purpose when the &lt;AFI/SAFI&gt; is &lt;2/128&gt;.  Thus, there
   are existing solutions for the advertisement of IPv6 NLRI with an
   IPv4 Next Hop. next hop.
      </t>
      <t>
   Similarly, the AFI/SAFI definitions for the advertisement of IPv4
   NLRI or VPN-IPv4 NLRI assume that the Next Hop next-hop address belongs to the
   IPv4 address family type.  Specifically, as per <xref target="RFC4760"/> target="RFC4760" format="default"/> and
   <xref target="RFC8277"/>, target="RFC8277" format="default"/>, when the &lt;AFI/SAFI&gt; is &lt;1/1&gt;, &lt;1/2&gt;, or &lt;1/4&gt;, the Next
   Hop next-hop address is assumed to be of an IPv4 type.  As per <xref target="RFC4364"/>, target="RFC4364" format="default"/>, when
   the &lt;AFI/SAFI&gt; is &lt;1/128&gt;, the Next Hop next-hop address is assumed to
   be of a VPN-IPv4 type.  As per <xref target="RFC6513"/> target="RFC6513" format="default"/> and <xref target="RFC6514"/>, target="RFC6514" format="default"/>, when
   the &lt;AFI/SAFI&gt; is &lt;1/129&gt;, the Next Hop next-hop address is assumed to
   be of a VPN-IPv4 type. There is clearly no generally applicable method for
   encoding an IPv6 address inside the IPv4 address field of the Next
   Hop. next
   hop.  Hence, there is currently no specified solution for advertising
   IPv4 or VPN-IPv4 NLRI with an IPv6 Next Hop. next hop.
      </t>
      <t>
   This document specifies the extensions necessary to
   allow advertising advertisement of IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop 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 next hop for IPv4 NLRI or VPN-IPv4 NLRI to belong to
   either the IPv4 or the IPv6 protocol, the encoding of the Next Hop next-hop
   information to determine which of the protocols the address
   actually belongs to, and a BGP Capability allowing MP-BGP peers
   to dynamically discover whether they can exchange IPv4 NLRI and VPN-
   IPv4 VPN-IPv4 NLRI with an IPv6 Next Hop. next hop.  The BGP Capability allows
   gradual deployment of the functionality of advertising IPv4
   reachability via an IPv6 Next Hop, next hop without any flag day nor any risk
   of traffic black-holing.
      </t>
      <t>This document obsoletes <xref target="RFC5549"/>.</t> target="RFC5549" format="default"/>.</t>

    <section anchor="requirements" 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="diff" title="Changes compared numbered="true" toc="default">
      <name>Changes Compared to RFC5549"> RFC 5549</name>
      <t>This document introduces two significant changes compared to <xref target="RFC5549"/>:
	<list>
	<t>In target="RFC5549" format="default"/>:
      </t>
      <ul empty="false" spacing="normal">

        <li>In <xref target="RFC5549"/>, target="RFC5549" format="default"/>, when AFI/SAFI 1/128 &lt;1/128&gt;
	is used, the nexthop next-hop address is encoded as an IPv6 address with a
	length of 16 or 32 bytes. To accomodate accommodate all existing implementations
	and bring consistency with VPNv4oIPv4 and VPNv6oIPv6, this document
	modifies how the nexthop next-hop address is encoded. The nexthop next-hop address is
	now encoded as an a VPN-IPv6 address with a length of 24 or 48 bytes. (See bytes
	(see Sections <xref target="extension"/> target="extension" format="counter"/> and <xref target="example-vpnv4unoipv6"/>).
	target="example-vpnv4unoipv6" format="counter"/>). This change
	addresses the errata 5253. Erratum ID 5253 (<xref target="Err5253"/>).
	As all known and deployed implementations are interoperable today and are using use the new proposed encoding, the change does not break existing interoperability.</t>
	<t>This interoperability.</li>
        <li>This document allows AFI/SAFI 1/129 &lt;1/129&gt; (IPv4 multicast) to use an
	IPv6 underlay using a similar encoding and procedures as for to AFI/SAFI 1/128. (See <xref target="extension"/> and
	&lt;1/128&gt; (see Sections <xref target="example-vpnv4multoipv6"/>)</t>
	</list>
	</t>
	</section>
	<section anchor="requirements" title="Requirements Language">

      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", target="extension" format="counter"/> 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> target="example-vpnv4multoipv6" format="counter"/>).</li>
      </ul>
    </section>
    <section anchor="extension" title="Extension numbered="true" toc="default">
      <name>Extension of AFI/SAFI Definitions for the IPv4 Address Family"> Family</name>
      <t>
	As mentioned earlier, MP-BGP specifies that the set of usable next-hop address families
	is determined by the Address Family Identifier (AFI) AFI and the
   Subsequent Address Family Identifier (SAFI). SAFI.  The following
   AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 NLRI (&lt;1/1&gt;,
   &lt;1/2&gt;, &lt;1/4&gt;, &lt;1/128&gt; &lt;1/128&gt;, and &lt;1/129&gt;) only have provisions for advertising a
   Next Hop
   next-hop address that belongs to the IPv4 protocol.

   This document
   extends the definition of the AFI/SAFI for advertisement of IPv4 NLRI
   and VPN-IPv4 NLRI to extend the set of usable next-hop address families to include IPv6 in addition to
   IPv4.
   IPv4 when advertising an IPv4 or VPN-IPv4 NLRI.
      </t>
      <t>
	Specifically, this document allows advertising the MP_REACH_NLRI attribute <xref target="RFC4760"/> target="RFC4760" format="default"/> with this content:
   <list style="symbols">

   <t>AFI
      </t>
      <ul spacing="normal">
        <li>AFI = 1</t>

   <t>SAFI 1</li>
        <li>SAFI = 1, 2, or 4</t>

   <t>Length 4</li>
        <li>Length of Next Hop Address = 16 or 32</t>

   <t>Next 32</li>
        <li>Next Hop Address = IPv6 address of a next hop (potentially followed
      by the link-local IPv6 address of the next hop).  This field is to
      be constructed as per Section 3 of <xref target="RFC2545"/>.</t>

   <t>NLRI= target="RFC2545" sectionFormat="of" section="3"/>.</li>
        <li>NLRI = NLRI as per the AFI/SAFI definition</t>
	</list>
	</t> definition</li>
      </ul>
      <t>
	 It also allows advertising the MP_REACH_NLRI attribute <xref target="RFC4760"/> target="RFC4760" format="default"/> with this content:
	<list style="symbols">

   <t>AFI
      </t>
      <ul spacing="normal">
        <li>AFI = 1</t>

   <t>SAFI 1</li>
        <li>SAFI = 128 or 129</t>

   <t>Length 129</li>
        <li>Length of Next Hop Address = 24 or 48</t>

   <t>Next 48</li>

        <li>Next Hop Address = VPN-IPv6 address of a next hop with an 8-octet RD set to zero (potentially followed
      by the link-local VPN-IPv6 address of the next hop with an 8-octet RD set to zero).</t>

   <t>NLRI= zero).</li>
        <li>NLRI = NLRI as per the AFI/SAFI definition</t>
	</list>
	</t> definition</li>
      </ul>
      <t>
   This is in addition to the existing mode of operation allowing
   advertisement of NLRI for &lt;AFI/SAFI&gt; of &lt;1/1&gt;, &lt;1/2&gt; &lt;1/2&gt;, and &lt;1/4&gt; with a
   next hop
   next-hop address of an IPv4 type and advertisement of NLRI for &lt;AFI/
   SAFI&gt; an
   &lt;AFI/SAFI&gt; of &lt;1/128&gt; and &lt;1/129&gt; with a next hop next-hop address
   of a VPN-IPv4 type.
      </t>
      <t>
   The BGP speaker receiving the advertisement MUST <bcp14>MUST</bcp14> use the Length of
   Next Hop Address field to determine which network-layer protocol the
   next hop
   next-hop address belongs to. </t>
	<t>
	<list style="symbols">
	<t>When
      <ul spacing="normal">
        <li>When the AFI/SAFI is &lt;1/1&gt;, &lt;1/2&gt; &lt;1/2&gt;, or &lt;1/4&gt;
   and when the Length of Next Hop Address
   field is equal to 16 or 32, the next hop next-hop address is of type IPv6.
	</t>
	<t>When
	</li>
        <li>When the AFI/SAFI is &lt;1/128&gt;, &lt;1/128&gt; or &lt;1/129&gt;
   and when the Length of Next Hop Address
   field is equal to 24 or 48, the next hop next-hop address is of type VPN-IPv6.
	</t>
	</list>
	</t>
	</li>
      </ul>
      <t>
   Note that this method of using the Length of the Next Hop Address
   field to determine which network-layer protocol the next hop next-hop address
   belongs to (out of the set of protocols allowed by the AFI/SAFI
   definition) is the same as that used in <xref target="RFC4684"/> target="RFC4684" format="default"/> and <xref target="RFC6074"/>. target="RFC6074" format="default"/>.
      </t>
    </section>
    <section anchor="bgp-cap" title="Use numbered="true" toc="default">
      <name>Use of BGP Capability Advertisement"> Advertisement</name>
      <t>
	<xref target="RFC5492"/> target="RFC5492" format="default"/> defines a mechanism to allow two BGP speakers to discover
   if a particular capability is supported by their BGP peer and thus and, thus, whether it can be used with that peer.  This document defines a
   capability that can be advertised using <xref target="RFC5492"/> and that is target="RFC5492"
   format="default"/>, referred to as the Extended "Extended Next Hop Encoding capability. capability".  This
   capability allows BGP speakers to discover whether, for a given NLRI
   &lt;AFI/SAFI&gt;, a peer supports advertisement with a next hop whose
   network protocol is determined by the value of the Length of Next Hop
   Address field, as specified in <xref target="extension"/>. target="extension" format="default"/>.
      </t>
      <t>
	A BGP speaker that wishes to advertise to a BGP peer an IPv6 Next Hop next hop for IPv4 NLRI
	or for VPN-IPv4 NLRI to a BGP peer as per this specification MUST <bcp14>MUST</bcp14> use
   the Capability Advertisement procedures defined in <xref target="RFC5492"/> target="RFC5492" format="default"/> with the
   Extended Next Hop Encoding Capability capability to determine whether its peer
   supports this for the NLRI AFI/SAFI pair(s) of interest.  The fields
   in the Capabilities Optional Parameter MUST <bcp14>MUST</bcp14> be set as follows:
   <list style="symbols">

   <t>The
      </t>
      <ul spacing="normal">
        <li>The Capability Code field MUST <bcp14>MUST</bcp14> be set to 5 (which indicates the
      Extended Next Hop Encoding capability).</t>

   <t>The capability).</li>
        <li>The Capability Length field is set to a variable value that is the
      length of the Capability Value field (which follows).</t> follows).</li>
        <li>
          <t>The Capability Value field has the following format:
   <figure>
   <artwork>
          </t>

          <artwork name="" type="" align="left" alt=""><![CDATA[

         +-----------------------------------------------------+
         | NLRI AFI - 1 (2 octets)                             |
         +-----------------------------------------------------+
         | NLRI SAFI - 1 (2 octets)                            |
         +-----------------------------------------------------+
         | Nexthop AFI - 1 (2 octets)                          |
         +-----------------------------------------------------+
         | .....                                               |
         +-----------------------------------------------------+
         | NLRI AFI - N (2 octets)                             |
         +-----------------------------------------------------+
         | NLRI SAFI - N (2 octets)                            |
         +-----------------------------------------------------+
         | Nexthop AFI - N (2 octets)                          |
         +-----------------------------------------------------+

   </artwork>
   </figure>

]]></artwork>
          <t>
    where:
		<list style="symbols">

      <t>each
          </t>
          <ul spacing="normal">
            <li>each triple &lt;NLRI AFI, NLRI SAFI, Nexthop AFI&gt; indicates
	    that the NLRI of &lt;NLRI AFI / NLRI SAFI&gt; may be advertised with a Next
         Hop next-hop address belonging to the network-layer protocol of Nexthop
         AFI.</t>

      <t>the
            AFI.</li>
            <li>the AFI and SAFI values are defined in the Address "Address
	    Family
         Identifier Numbers"
         and Subsequent "Subsequent Address Family Identifier (SAFI) Parameters" registries
         maintained by IANA.</t>
		</list>
   </t>

   </list>
    </t>
         (see <xref target="IANA-AFI"/> and <xref
	 target="IANA-SAFI"/>, respectively).</li>
          </ul>
        </li>
      </ul>
      <t>
   Since this document only concerns itself with the advertisement of
   IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop, next hop, this specification
   only allows the following values in the Capability Value field of the
   Extended Next Hop Encoding capability:
   <list style="symbols">

   <t>NLRI
      </t>
      <ul spacing="normal">
        <li>NLRI AFI = 1 (IPv4)</t>

   <t>NLRI (IPv4)</li>
        <li>NLRI SAFI = 1, 2, 4, 128 128, or 129</t>

   <t>Nexthop 129</li>
        <li>Nexthop AFI = 2 (IPv6)</t>
	</list>
	</t> (IPv6)</li>
      </ul>
      <t>
   This document does not specify the use of the Extended Next Hop Encoding capability with any other combinations of &lt;NLRI AFI,
   NLRI SAFI, Nexthop AFI&gt;. For example, the Next Hop Encoding capability specified in this document is not intended to be used for
   NLRI AFI/SAFIs AFIs/SAFIs whose definition already allows use of both IPv4 and
   IPv6 next hops (e.g., AFI/SAFI = &lt;1/132&gt; as defined in <xref target="RFC4684"/>). target="RFC4684" format="default"/>).
   Similarly, it is not intended that the Extended Next Hop Encoding capability be used for NLRI AFI/SAFIs AFIs/SAFIs for which there is already a solution for advertising a next hop of a different address family
   (e.g., AFI/SAFI = &lt;2/1&gt;, &lt;2/2&gt;, or &lt;2/4&gt; with an IPv4 Next Hop next hop as per
   <xref target="RFC4798"/> target="RFC4798" format="default"/> and AFI/SAFI = &lt;2/128&gt; with
   an IPv4 Next Hop next hop as per
   <xref target="RFC4659"/>).</t> target="RFC4659" format="default"/>).</t>
      <t>
   It is expected that if new AFI/SAFIs AFIs/SAFIs are defined in the future, their
   definition
   definitions will have provisions (where appropriate) for both IPv4 and
   IPv6 Next Hops next hops from the beginning, with the determination based on the Length of
   Next Hop Address field.  Thus, new AFI/SAFIs AFIs/SAFIs are not expected to make
   use of the Extended Next Hop Encoding capability.
      </t>
      <t>
   A BGP speaker MUST <bcp14>MUST</bcp14> only advertise to a BGP peer the IPv4 or VPN-IPv4
   NLRI with an IPv6 Next Hop next hop to a BGP peer if the BGP speaker has first ascertained
   via the BGP Capability Advertisement that the BGP peer supports the
   Extended Next Hop Encoding capability for the relevant AFI/SAFI pair.
      </t>
      <t>
   The Extended Next Hop Encoding capability provides information about
   next hop
   next-hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is
   allowed.  It does not influence whether that AFI/SAFI is indeed
   allowed.  Whether a an AFI/SAFI can be used between the BGP peers is
   purely determined through the Multiprotocol Extensions capability
   defined in <xref target="RFC4760"/>. target="RFC4760" format="default"/>.
      </t>
    </section>
    <section anchor="operations" title="Operations"> numbered="true" toc="default">
      <name>Operations</name>
      <t>
	By default, if a particular BGP session is running over IPvx (where
   IPvx is IPv4 or IPv6), IPv6) and if the BGP speaker sending an update is
   putting its own address in as the next hop, then the next hop next-hop address
   SHOULD
   <bcp14>SHOULD</bcp14> be specified as an IPvx address, using the encoding rules
   specified in the AFI/SAFI definition of the NLRI being updated.  This
   default behavior may be overridden by policy.
      </t>
      <t>
   When a next hop next-hop address needs to be passed along unchanged (e.g., as
   a Route Reflector (RR) would do), its encoding MUST NOT <bcp14>MUST NOT</bcp14> be changed.
   If a particular RR client cannot handle that encoding (as determined
   by the BGP Capability Advertisement), then the NLRI in question
   cannot be distributed to that client.  For sound routing in certain
   scenarios, this will require that all the RR clients be able to
   handle whatever encodings any of them may generate.
      </t>
    </section>
    <section anchor="examples" title="Usage Examples"> numbered="true" toc="default">
      <name>Usage Examples</name>
      <section anchor="example-ipv4oipv6" title="IPv4 numbered="true" toc="default">
        <name>IPv4 over IPv6 Core"> Core</name>
        <t>
	The extensions defined in this document may be used as discussed in
   <xref target="RFC5565"/> target="RFC5565" format="default"/> for the interconnection of IPv4 islands over an IPv6
   backbone.  In this application, Address Family Border Routers (AFBRs;
   as defined in <xref target="RFC4925"/>) target="RFC4925" format="default"/>) advertise IPv4 NLRI in the MP_REACH_NLRI
   along with an IPv6 Next Hop.</t> next hop.</t>
        <t>
   The MP_REACH_NLRI is encoded with:
	<list style="symbols">

   <t>AFI
        </t>
        <ul spacing="normal">
          <li>AFI = 1</t>

   <t>SAFI 1</li>
          <li>SAFI = 1</t>

   <t>Length 1</li>
          <li>Length of Next Hop Network Address field = 16 (or 32)</t>

   <t>Network Address of Next 32)</li>
          <li>Next Hop Address = IPv6 address of Next Hop</t>

   <t>NLRI the next hop</li>
          <li>NLRI = IPv4 routes</t>
	</list>
	</t> routes</li>
        </ul>
        <t>
   During BGP Capability Advertisement, the PE routers would include the following fields in the Capabilities Optional Parameter:
   <list style="symbols">

   <t>Capability
        </t>
        <ul spacing="normal">
          <li>Capability Code set to "Extended Next Hop Encoding"</t>

   <t>Capability Encoding"</li>
          <li>Capability Value containing &lt;NLRI AFI=1, NLRI SAFI=1, Nexthop
      AFI=2&gt;</t>
	</list>
	</t>
      AFI=2&gt;</li>
        </ul>
      </section>
      <section anchor="example-vpnv4unoipv6" title="IPv4 numbered="true" toc="default">
        <name>IPv4 VPN unicast Unicast over IPv6 Core"> Core</name>
        <t>
		  The extensions defined in this document may be used for support of
   IPv4 VPNs over an IPv6 backbone.  In this application, PE routers
would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6
   Next Hop.
   next hop.
        </t>
        <t>
   The MP_REACH_NLRI is encoded with:
	<list style="symbols">

	<t>AFI
        </t>
        <ul spacing="normal">
          <li>AFI = 1</t>

	<t>SAFI 1</li>
          <li>SAFI = 128</t>

	<t>Length 128</li>
          <li>Length of Next Hop Network Address field = 24 (or 48)</t>

	<t>Network Address of Next 48)</li>
          <li>Next Hop Address = VPN-IPv6 address of Next Hop a next hop whose RD is set to zero</t>

	<t>NLRI zero</li>
          <li>NLRI = IPv4-VPN routes</t>
	</list>
	</t> routes</li>
        </ul>
        <t>

   During BGP Capability Advertisement, the PE routers would include the
   following fields in the Capabilities Optional Parameter:
	<list style="symbols">
	<t>Capability
        </t>
        <ul spacing="normal">
          <li>Capability Code set to "Extended Next Hop Encoding"</t>

	<t>Capability Encoding"</li>
          <li>Capability Value containing &lt;NLRI AFI=1, NLRI SAFI=128, Nexthop
      AFI=2&gt;</t>
	</list>
		</t>
      AFI=2&gt;</li>
        </ul>
      </section>
      <section anchor="example-vpnv4multoipv6" title="IPv4 numbered="true" toc="default">
        <name>IPv4 VPN multicast Multicast over IPv6 Core"> Core</name>
        <t>
		  The extensions defined in this document may be used for support of
   IPv4 multicast VPNs over an IPv6 backbone.  In this application, PE routers
would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6
   Next Hop.
   next hop.
        </t>
        <t>
   The MP_REACH_NLRI is encoded with:
	<list style="symbols">

	<t>AFI
        </t>
        <ul spacing="normal">
          <li>AFI = 1</t>

	<t>SAFI 1</li>
          <li>SAFI = 129</t>

	<t>Length 129</li>
          <li>Length of Next Hop Network Address field = 24 (or 48)</t>

	<t>Network Address of Next 48)</li>
          <li>Next Hop Address = VPN-IPv6 address of Next Hop a next hop whose RD is set to zero</t>

	<t>NLRI zero</li>
          <li>NLRI = IPv4-VPN routes</t>
	</list>
	</t> routes</li>
        </ul>
        <t>

   During BGP Capability Advertisement, the PE routers would include the
   following fields in the Capabilities Optional Parameter:
	<list style="symbols">
	<t>Capability
        </t>
        <ul spacing="normal">
          <li>Capability Code set to "Extended Next Hop Encoding"</t>

	<t>Capability Encoding"</li>
          <li>Capability Value containing &lt;NLRI AFI=1, NLRI SAFI=129, Nexthop
      AFI=2&gt;</t>
	</list>
		</t>
      AFI=2&gt;</li>
        </ul>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document does not define any new code point compared to points from those
      included in <xref target="RFC5549"/>. target="RFC5549" format="default"/>. </t>
      <t><xref target="RFC5549"/> target="RFC5549" format="default"/> added "Extended
      Next Hop Encoding" to the Capability Codes registry, "Capability Codes" registry (<xref target="IANA-CAP-CODE"/>), which was created by <xref target="RFC5492"/>. target="RFC5492" format="default"/>.
	IANA is requested to update has updated the definition registration of that entry to refer instead to this document.  The value allocated for this Capability
   Code is 5.</t>
    </section>
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
	   This document does not raise any additional security issues beyond
   those of BGP-4 and the Multiprotocol extensions Extensions for BGP-4.  The same
   security mechanisms are applicable.</t>
      <t>
   However, as <xref target="RFC4272"/> target="RFC4272" format="default"/> discusses, BGP is vulnerable to traffic diversion attacks.
   The ability to advertise an IPv6 Next Hop next hop adds a new means by which an
   attacker could cause traffic to be diverted from its normal path.  Such an
   attack differs from pre-existing preexisting vulnerabilities in that traffic could be
   forwarded to a distant target across an intervening network infrastructure
   (e.g.
   (e.g., an IPv6 core), allowing an attack to potentially succeed more
   easily,
   easily since less infrastructure would have to be subverted.  Potential
   consequences include "hijacking" of traffic or denial of service.
      </t>
      <t>
   Although not expected to be the typical case, the IPv6 address used
   as the BGP Next Hop Address next-hop address could be an IPv4-mapped IPv6 address (as
   defined in <xref target="RFC4291"/>). target="RFC4291" format="default"/>).  Configuration of the security mechanisms
   potentially deployed by the network operator (such as security checks
   on next hop a next-hop address) also need to keep this case in mind also. mind.
      </t>
    </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.2545.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4760.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.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8277.xml"/>
      </references>
      <references>
        <name>Informative References</name>

<reference anchor="IANA-AFI"
           target="https://www.iana.org/assignments/address-family-numbers/">
  <front>
    <title>Address Family Numbers</title>
    <author><organization>IANA</organization></author>
  </front>
</reference>

<reference anchor="IANA-CAP-CODE"
           target="https://www.iana.org/assignments/capability-codes/">
  <front>
    <title>Capability Codes</title>
    <author><organization>IANA</organization></author>
  </front>
</reference>

<reference anchor="IANA-SAFI"
           target="https://www.iana.org/assignments/safi-namespace/">
  <front>
    <title>Subsequent Address Family Identifiers (SAFI) Parameters</title>
    <author><organization>IANA</organization></author>
  </front>
</reference>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4659.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4684.xml"/>
        <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.4798.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4925.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5549.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5565.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6074.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6513.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6514.xml"/>

<reference anchor="Err5253" quote-title="false"
	   target="https://www.rfc-editor.org/errata/eid5253">
<front>
<title>Erratum ID 5253</title>
<author><organization>RFC Errata</organization></author>
</front>
<refcontent>RFC 5549</refcontent>
</reference>
      </references>
    </references>
    <section anchor="ack" title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank Francois <contact fullname="Francois Le Faucheur Faucheur"/> and Eric Rosen <contact fullname="Eric Rosen"/> for the edition and their work on <xref target="RFC5549"/>.</t> target="RFC5549" format="default"/>.</t>
      <t>
	The authors would like to thank Yakov Rekhter, Pranav Mehta, and John
   Scudder <contact fullname="Yakov Rekhter"/>, <contact fullname="Pranav Mehta"/>, and <contact fullname="John
   Scudder"/> for their contributions to the approach defined in <xref target="RFC5549"/>. target="RFC5549" format="default"/>.
      </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      &RFC2119;
	  &RFC2545;
	  &RFC4291;
	  &RFC4364;
	  &RFC4760;
	  &RFC5492;
	  &RFC8174;
	  &RFC8277;
    </references>
	<references title="Informative References">
	&RFC4659;
	&RFC4684;
	&RFC4272;
	&RFC4798;
	&RFC4925;
	&RFC8126;
	&RFC5549;
	&RFC5565;
	&RFC6074;
	&RFC6513;
	&RFC6514;

    </references>
    <!-- references title="Informative References">
    </references -->
  </back>
</rfc>