rfc8950xml2.original.xml   rfc8950.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
.2119.xml">
<!ENTITY RFC2545 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
.2545.xml"> docName="draft-ietf-bess-rfc5549revision-06" number="8950" ipr="trust200902
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC "
.4291.xml"> obsoletes="5549" updates="" submissionType="IETF" xml:lang="en"
<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC tocInclude="true" tocDepth="3" consensus="true" symRefs="true" sortRefs="tr
.4364.xml"> ue" version="3">
<!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 -->
<rfc category="std" docName="draft-ietf-bess-rfc5549revision-06" ipr="trust20090
2" obsoletes="RFC5549">
<front> <front>
<title abbrev="rfc5549revision">Advertising IPv4 Network Layer Reachability <title abbrev="Advertising IPv4 Reachability with IPv6">Advertising IPv4
Information with an IPv6 Next Hop</title> Network Layer Reachability Information (NLRI) with an IPv6 Next Hop</title>
<author fullname="Stephane Litkowski" initials="S" surname="Litkowski"> <seriesInfo name="RFC" value="8950"/>
<author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<email>slitkows@cisco.com</email> <email>slitkows@cisco.com</email>
<!-- <uri/> -->
</address> </address>
</author> </author>
<author fullname="Swadesh Agrawal" initials="S" surname="Agrawal"> <author fullname="Swadesh Agrawal" initials="S." surname="Agrawal">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<email>swaagraw@cisco.com</email> <email>swaagraw@cisco.com</email>
<!-- <uri/> -->
</address> </address>
</author> </author>
<author fullname="Krishna Muddenahally Ananthamurthy" initials="K" surnam e="Ananthamurthy"> <author fullname="Krishna Muddenahally Ananthamurthy" initials="K." surname= "Ananthamurthy">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<email>kriswamy@cisco.com</email> <email>kriswamy@cisco.com</email>
<!-- <uri/> -->
</address> </address>
</author> </author>
<author fullname="Keyur Patel" initials="K" surname="Patel"> <author fullname="Keyur Patel" initials="K." surname="Patel">
<organization>Arrcus</organization> <organization>Arrcus</organization>
<address> <address>
<email>keyur@arrcus.com</email> <email>keyur@arrcus.com</email>
<!-- <uri/> -->
</address> </address>
</author> </author>
<date year="2020"/> <date year="2020" month="November"/>
<area/> <area/>
<workgroup>BESS Working Group</workgroup> <workgroup>BESS Working Group</workgroup>
<!-- <keyword/> -->
<keyword>bgp</keyword>
<keyword>mvpn</keyword>
<keyword>vpnv4</keyword>
<keyword>vpnv6</keyword>
<abstract> <abstract>
<t> <t>
Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop a ddress families Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop a ddress families
is determined by the Address Family Identifier (AFI) and the is determined by the Address Family Identifier (AFI) and the
Subsequent Address Family Identifier (SAFI). The AFI/SAFI Subsequent Address Family Identifier (SAFI). The AFI/SAFI
definitions for the IPv4 address family only have provisions for definitions for the IPv4 address family only have provisions for
advertising a Next Hop address that belongs to the IPv4 protocol when advertising a next-hop address that belongs to the IPv4 protocol when
advertising IPv4 Network Layer Reachability Information (NLRI) or advertising IPv4 Network Layer Reachability Information (NLRI) or
VPN-IPv4 NLRI. VPN-IPv4 NLRI.
</t> </t>
<t> <t>
This document specifies the extensions necessary to This document specifies the extensions necessary to
allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address allow the advertising of IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address
that belongs to the IPv6 protocol. This comprises an extension of that belongs to the IPv6 protocol. This comprises an extension of
the AFI/SAFI definitions to allow the address of the Next Hop for 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 IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the
encoding of the Next Hop to determine which of the protocols encoding of the next hop to determine which of the protocols
the address actually belongs to, and a BGP Capability allowing the address actually belongs to, and a BGP Capability allowing
MP-BGP Peers to dynamically discover whether they can exchange IPv4 MP-BGP peers to dynamically discover whether they can exchange IPv4
NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. This document obsoletes RFC5549 NLRI and VPN-IPv4 NLRI with an IPv6 next hop. This document obsoletes RFC 554
. 9.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<t> <t>
Multiprotocol BGP (MP-BGP) <xref target="RFC4760"/> specifies that the se Multiprotocol BGP (MP-BGP) <xref target="RFC4760" format="default"/> spec
t of ifies that the set of
network-layer protocols to which the address carried in the Next Hop network-layer protocols to which the address carried in the Next Hop
field may belong is determined by the Address Family Identifier (AFI) Address field may belong is determined by the Address Family Identifier (AFI)
and the Subsequent Address Family Identifier (SAFI). A number of and the Subsequent Address Family Identifier (SAFI). A number of
existing AFI/SAFIs allow the Next Hop address to belong to a existing AFIs/SAFIs allow the next-hop address to belong to a
different address family than the Network Layer Reachability different address family than the Network Layer Reachability
Information (NLRI). For example, the AFI/SAFI &lt;25/65&gt; used (as per Information (NLRI). For example, the AFI/SAFI &lt;25/65&gt; used (as per
<xref target="RFC6074"/>) to perform L2VPN auto-discovery, allows <xref target="RFC6074" format="default"/>) to perform Layer 2 Virtual
advertising NLRI that contains the identifier of a Virtual Private 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 LAN Service (VPLS) instance or that identifies a particular pool of
attachment circuits at a given Provider Edge (PE), while the Next Hop attachment circuits at a given Provider Edge (PE), while the Next Hop
field contains the loopback address of a PE. Similarly, the AFI/SAFI Address field contains the loopback address of a PE. Similarly, the AFI/SAFI
&lt;1/132&gt; (defined in <xref target="RFC4684"/>) to advertise Route Target &lt;1/132&gt; (defined in <xref target="RFC4684" format="default"/>) to adver
(RT) membership information, allows advertising NLRI that contains tise Route Target
such RT membership information, while the Next Hop field contains the (RT) membership information allows advertising NLRI that contains
such RT membership information, while the Next Hop Address field contains the
address of the advertising router. address of the advertising router.
</t> </t>
<t> <t>
Furthermore, a number of these existing AFI/SAFIs allow the Next Hop Furthermore, a number of these existing AFIs/SAFIs allow the next hop
to belong to either the IPv4 protocol or the IPv6 to belong to either the IPv4 protocol or the IPv6
protocol, and specify the encoding of the Next Hop protocol and specify the encoding of the next-hop
information to determine which of the protocols the address information to determine which of the protocols the address
actually belongs to. For example, <xref target="RFC4684"/> allows the Next H actually belongs to.
op
address to be either an IPv4 or IPv6 address and states that the Next Hop fie For example, <xref target="RFC4684" format="default"/> allows the next-hop
ld address to be either an IPv4 or IPv6 address and states that the
address shall be interpreted as an IPv4 address whenever the length Next Hop Address field shall be interpreted as an IPv4 address whenever the l
of Next Hop address is 4 octets, and as an IPv6 address whenever the ength
length of the Next Hop address is 16 octets. of the next-hop address is 4 octets and as an IPv6 address whenever the
</t> length of the next-hop address is 16 octets.
<t> </t>
There are situations such as those described in <xref target="RFC4925"/> and <t>
in There are situations such as those described in <xref target="RFC4925"
<xref target="RFC5565"/> where carriers (or large enterprise networks acting format="default"/> and <xref target="RFC5565" format="default"/> where carrie
as rs (or large
enterprise networks acting as a
carrier for their internal resources) may be required to establish carrier for their internal resources) may be required to establish
connectivity between 'islands' of networks of one address family type connectivity between 'islands' of networks of one address family type
across a transit core of a differing address family type. This across a transit core of a differing address family type. This
includes both the case of IPv6 islands across an IPv4 core and the includes both the case of IPv6 islands across an IPv4 core and the
case of IPv4 islands across an IPv6 core. Where Multiprotocol BGP case of IPv4 islands across an IPv6 core. Where Multiprotocol BGP
(MP-BGP) is used to advertise the corresponding reachability (MP-BGP) is used to advertise the corresponding reachability
information, this translates into the requirement for a BGP speaker information, this translates into the requirement for a BGP speaker
to advertise Network Layer Reachability Information (NLRI) of a given to advertise the NLRI of a given
address family via a Next Hop of a different address family (i.e., address family via a next hop of a different address family (i.e.,
IPv6 NLRI with IPv4 Next Hop and IPv4 NLRI with IPv6 Next Hop). IPv6 NLRI with an IPv4 next hop and IPv4 NLRI with an IPv6 next hop).
</t> </t>
<t> <t>
The AFI/SAFI definitions for the IPv6 address family assume The AFI/SAFI definitions for the IPv6 address family assume
that the Next Hop address belongs to the IPv6 address family type. that the next-hop address belongs to the IPv6 address family type.
Specifically, as per <xref target="RFC2545"/> and <xref target="RFC8277"/>, w Specifically, as per <xref target="RFC2545" format="default"/> and <xref targ
hen the &lt;AFI/SAFI&gt; is et="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 address is assumed to &lt;2/1&gt;, &lt;2/2&gt;, or &lt;2/4&gt;, the next-hop address is assumed
be of IPv6 to be of an IPv6
type. As per <xref target="RFC4659"/>, when the &lt;AFI/SAFI&gt; is &lt;2/12 type. As per <xref target="RFC4659" format="default"/>, when the &lt;AFI/SAF
8&gt;, the Next Hop I&gt; is &lt;2/128&gt;, the next-hop
address is assumed to be of VPN-IPv6 type. address is assumed to be of a VPN-IPv6 type.
</t> </t>
<t> <t>
However, <xref target="RFC4798"/> and <xref target="RFC4659"/> However, <xref target="RFC4798" format="default"/> and <xref target="RFC4659"
format="default"/>
specify how an IPv4 address can be specify how an IPv4 address can be
encoded inside the Next Hop IPv6 address field when IPv6 NLRI needs encoded inside the next-hop IPv6 address field when IPv6 NLRI needs
to be advertised with an IPv4 Next Hop. <xref target="RFC4798"/> defines how to be advertised with an IPv4 next hop. <xref target="RFC4798" format="defau
the lt"/> defines how the
IPv4-mapped IPv6 address format specified in the IPv6 addressing IPv4-mapped IPv6 address format specified in the IPv6 addressing
architecture (<xref target="RFC4291"/>) can be used for that purpose when the architecture (<xref target="RFC4291" format="default"/>) can be
&lt;AFI/ used for that purpose when the &lt;AFI/SAFI&gt; is &lt;2/1&gt;,
SAFI&gt; is &lt;2/1&gt;, &lt;2/2&gt;, or &lt;2/4&gt;. <xref target="RFC4659" &lt;2/2&gt;, or &lt;2/4&gt;. <xref target="RFC4659"
/> defines how the IPv4- format="default"/> defines how the IPv4-mapped IPv6 address format
mapped IPv6 address format as well as a null Route Distinguisher can 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, t here be used for that purpose when the &lt;AFI/SAFI&gt; is &lt;2/128&gt;. Thus, t here
are existing solutions for the advertisement of IPv6 NLRI with an are existing solutions for the advertisement of IPv6 NLRI with an
IPv4 Next Hop. IPv4 next hop.
</t> </t>
<t>
<t> Similarly, the AFI/SAFI definitions for the advertisement of IPv4
Similarly, the AFI/SAFI definitions for advertisement of IPv4 NLRI or VPN-IPv4 NLRI assume that the next-hop address belongs to the
NLRI or VPN-IPv4 NLRI assume that the Next Hop address belongs to the IPv4 address family type. Specifically, as per <xref target="RFC4760" format
IPv4 address family type. Specifically, as per <xref target="RFC4760"/> and ="default"/> and
<xref target="RFC8277"/>, when the &lt;AFI/SAFI&gt; is &lt;1/1&gt;, &lt;1/2&g <xref target="RFC8277" format="default"/>, when the &lt;AFI/SAFI&gt; is &lt;1
t;, or &lt;1/4&gt;, the Next /1&gt;, &lt;1/2&gt;, or &lt;1/4&gt;, the next-hop address is assumed to be of an
Hop address is assumed to be of IPv4 type. As per <xref target="RFC4364"/>, IPv4 type. As per <xref target="RFC4364" format="default"/>, when
when the &lt;AFI/SAFI&gt; is &lt;1/128&gt;, the next-hop address is assumed to
the &lt;AFI/SAFI&gt; is &lt;1/128&gt;, the Next Hop address is assumed to be be of a VPN-IPv4 type. As per <xref target="RFC6513" format="default"/> and
of <xref target="RFC6514" format="default"/>, when
VPN-IPv4 type. As per <xref target="RFC6513"/> and <xref target="RFC6514"/>, the &lt;AFI/SAFI&gt; is &lt;1/129&gt;, the next-hop address is assumed to
when be of a VPN-IPv4 type. There is clearly no generally applicable method for
the &lt;AFI/SAFI&gt; is &lt;1/129&gt;, the Next Hop address is assumed to be encoding an IPv6 address inside the IPv4 address field of the next
of hop. Hence, there is currently no specified solution for advertising
VPN-IPv4 type. There is clearly no generally applicable method for IPv4 or VPN-IPv4 NLRI with an IPv6 next hop.
encoding an IPv6 address inside the IPv4 address field of the Next </t>
Hop. Hence, there is currently no specified solution for advertising <t>
IPv4 or VPN-IPv4 NLRI with an IPv6 Next Hop.
</t>
<t>
This document specifies the extensions necessary to This document specifies the extensions necessary to
allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address allow advertisement of IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address
that belongs to the IPv6 protocol. This that belongs to the IPv6 protocol. This
comprises an extension of the AFI/SAFI definitions to allow the comprises an extension of the AFI/SAFI definitions to allow the
address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to belong to address of the 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 either the IPv4 or the IPv6 protocol, the encoding of the next-hop
information to determine which of the protocols the address information to determine which of the protocols the address
actually belongs to, and a BGP Capability allowing MP-BGP peers actually belongs to, and a BGP Capability allowing MP-BGP peers
to dynamically discover whether they can exchange IPv4 NLRI and VPN- to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI
IPv4 NLRI with an IPv6 Next Hop. The BGP Capability allows with an IPv6 next hop. The BGP Capability allows
gradual deployment of the functionality of advertising IPv4 gradual deployment of the functionality of advertising IPv4
reachability via an IPv6 Next Hop, without any flag day nor any risk reachability via an IPv6 next hop without any flag day nor any risk
of traffic black-holing. of traffic black-holing.
</t> </t>
<t>This document obsoletes <xref target="RFC5549"/>.</t> <t>This document obsoletes <xref target="RFC5549" format="default"/>.</t>
</section>
<section anchor="diff" title="Changes compared to RFC5549">
<t>This document introduces two significant changes compared to <xref tar
get="RFC5549"/>:
<list>
<t>In <xref target="RFC5549"/>, when AFI/SAFI 1/128 is used, the nexthop
address is encoded as an IPv6 address with a length of 16 or 32 bytes. To accomo
date all existing implementations and bring consistency with VPNv4oIPv4 and VPNv
6oIPv6, this document modifies how the nexthop address is encoded. The nexthop a
ddress is now encoded as an VPN-IPv6 address with a length of 24 or 48 bytes. (S
ee <xref target="extension"/> and <xref target="example-vpnv4unoipv6"/>). This c
hange addresses the errata 5253.
As all known and deployed implementations are interoperable today and are
using the new proposed encoding, the change does not break existing interoperab
ility.</t>
<t>This document allows AFI/SAFI 1/129 (IPv4 multicast) to use an IPv6 un
derlay using a similar encoding and procedures as for AFI/SAFI 1/128. (See <xref
target="extension"/> and <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", <section anchor="requirements" numbered="true" toc="default">
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <name>Requirements Language</name>
"OPTIONAL" in this document are to be interpreted as described in <t>
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
they appear in all IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
capitals, as shown here.</t> 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" numbered="true" toc="default">
<name>Changes Compared to RFC 5549</name>
<t>This document introduces two significant changes compared to <xref targ
et="RFC5549" format="default"/>:
</t>
<ul empty="false" spacing="normal">
</section> <li>In <xref target="RFC5549" format="default"/>, when AFI/SAFI &lt;1/12
<section anchor="extension" title="Extension of AFI/SAFI Definitions for 8&gt;
the IPv4 Address Family"> is used, the next-hop address is encoded as an IPv6 address with a
<t> length of 16 or 32 bytes. To accommodate all existing implementations
and bring consistency with VPNv4oIPv4 and VPNv6oIPv6, this document
modifies how the next-hop address is encoded. The next-hop address is
now encoded as a VPN-IPv6 address with a length of 24 or 48 bytes
(see Sections <xref target="extension" format="counter"/> and <xref
target="example-vpnv4unoipv6" format="counter"/>). This change
addresses Erratum ID 5253 (<xref target="Err5253"/>).
As all known and deployed implementations are interoperable today and use
the new proposed encoding, the change does not break existing interoperability.
</li>
<li>This document allows AFI/SAFI &lt;1/129&gt; (IPv4 multicast) to use
an
IPv6 underlay using similar encoding and procedures to AFI/SAFI
&lt;1/128&gt; (see Sections <xref target="extension" format="counter"/> a
nd <xref target="example-vpnv4multoipv6" format="counter"/>).</li>
</ul>
</section>
<section anchor="extension" numbered="true" toc="default">
<name>Extension of AFI/SAFI Definitions for the IPv4 Address Family</name>
<t>
As mentioned earlier, MP-BGP specifies that the set of usable next-hop ad dress families As mentioned earlier, MP-BGP specifies that the set of usable next-hop ad dress families
is determined by the Address Family Identifier (AFI) and the is determined by the AFI and the SAFI. The following
Subsequent Address Family Identifier (SAFI). The following
AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 NLRI (&lt;1/1&gt;, 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; and &lt;1/129&gt;) only have provisio &lt;1/2&gt;, &lt;1/4&gt;, &lt;1/128&gt;, and &lt;1/129&gt;) only have provisi
ns for advertising a ons for advertising a
Next Hop address that belongs to the IPv4 protocol. This document next-hop address that belongs to the IPv4 protocol.
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 in
clude IPv6 in addition to
IPv4.
</t>
<t>
Specifically, this document allows advertising the MP_REACH_NLRI attribut
e <xref target="RFC4760"/> with this content:
<list style="symbols">
<t>AFI = 1</t>
<t>SAFI = 1, 2, or 4</t>
<t>Length of Next Hop Address = 16 or 32</t>
<t>Next Hop Address = IPv6 address of next hop (potentially followed This document
extends the set of usable next-hop address families to include IPv6 in additi
on to
IPv4 when advertising an IPv4 or VPN-IPv4 NLRI.
</t>
<t>
Specifically, this document allows advertising the MP_REACH_NLRI attribut
e <xref target="RFC4760" format="default"/> with this content:
</t>
<ul spacing="normal">
<li>AFI = 1</li>
<li>SAFI = 1, 2, or 4</li>
<li>Length of Next Hop Address = 16 or 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 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> be constructed as per <xref target="RFC2545" sectionFormat="of" section="3
"/>.</li>
<t>NLRI= NLRI as per AFI/SAFI definition</t> <li>NLRI = NLRI as per the AFI/SAFI definition</li>
</list> </ul>
</t> <t>
<t> It also allows advertising the MP_REACH_NLRI attribute <xref target="RFC
It also allows advertising the MP_REACH_NLRI attribute <xref target="RFC 4760" format="default"/> with this content:
4760"/> with this content: </t>
<list style="symbols"> <ul spacing="normal">
<li>AFI = 1</li>
<t>AFI = 1</t> <li>SAFI = 128 or 129</li>
<li>Length of Next Hop Address = 24 or 48</li>
<t>SAFI = 128 or 129</t>
<t>Length of Next Hop Address = 24 or 48</t>
<t>Next Hop Address = VPN-IPv6 address of 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= NLRI as per AFI/SAFI definition</t> <li>Next Hop Address = VPN-IPv6 address of a next hop with an 8-octet RD
</list> set to zero (potentially followed
</t> by the link-local VPN-IPv6 address of the next hop with an 8-octet RD set
<t> to zero).</li>
<li>NLRI = NLRI as per the AFI/SAFI definition</li>
</ul>
<t>
This is in addition to the existing mode of operation allowing 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; and &l advertisement of NLRI for &lt;AFI/SAFI&gt; of &lt;1/1&gt;, &lt;1/2&gt;, and &
t;1/4&gt; with a lt;1/4&gt; with a
next hop address of IPv4 type and advertisement of NLRI for &lt;AFI/ next-hop address of an IPv4 type and advertisement of NLRI for an
SAFI&gt; of &lt;1/128&gt; and &lt;1/129&gt; with a next hop address of VPN-IP &lt;AFI/SAFI&gt; of &lt;1/128&gt; and &lt;1/129&gt; with a next-hop address
v4 type. of a VPN-IPv4 type.
</t> </t>
<t> <t>
The BGP speaker receiving the advertisement MUST use the Length of The BGP speaker receiving the advertisement <bcp14>MUST</bcp14> use the Lengt
h of
Next Hop Address field to determine which network-layer protocol the Next Hop Address field to determine which network-layer protocol the
next hop address belongs to. </t> next-hop address belongs to. </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>When the AFI/SAFI is &lt;1/1&gt;, &lt;1/2&gt;, or &lt;1/4&gt;
<t>When the AFI/SAFI is &lt;1/1&gt;, &lt;1/2&gt; or &lt;1/4&gt;
and when the Length of Next Hop Address and when the Length of Next Hop Address
field is equal to 16 or 32, the next hop address is of type IPv6. field is equal to 16 or 32, the next-hop address is of type IPv6.
</t> </li>
<t>When the AFI/SAFI is &lt;1/128&gt;, or &lt;1/129&gt; <li>When the AFI/SAFI is &lt;1/128&gt; or &lt;1/129&gt;
and when the Length of Next Hop Address and when the Length of Next Hop Address
field is equal to 24 or 48, the next hop address is of type VPN-IPv6. field is equal to 24 or 48, the next-hop address is of type VPN-IPv6.
</t> </li>
</list> </ul>
</t> <t>
<t> Note that this method of using the Length of Next Hop Address
Note that this method of using the Length of the Next Hop Address field to determine which network-layer protocol the next-hop address
field to determine which network-layer protocol the next hop address
belongs to (out of the set of protocols allowed by the AFI/SAFI belongs to (out of the set of protocols allowed by the AFI/SAFI
definition) is the same as used in <xref target="RFC4684"/> and <xref target= definition) is the same as that used in <xref target="RFC4684" format="defaul
"RFC6074"/>. t"/> and <xref target="RFC6074" format="default"/>.
</t> </t>
</section> </section>
<section anchor="bgp-cap" title="Use of BGP Capability Advertisement"> <section anchor="bgp-cap" numbered="true" toc="default">
<t> <name>Use of BGP Capability Advertisement</name>
<xref target="RFC5492"/> defines a mechanism to allow two BGP speakers to <t>
discover <xref target="RFC5492" format="default"/> defines a mechanism to allow tw
if a particular capability is supported by their BGP peer and thus o BGP speakers to discover
whether it can be used with that peer. This document defines a if a particular capability is supported by their BGP peer and, thus, whether
capability that can be advertised using <xref target="RFC5492"/> and that is it can be used with that peer. This document defines a
referred to as the Extended Next Hop Encoding capability. This capability that can be advertised using <xref target="RFC5492"
format="default"/>, referred to as the "Extended Next Hop Encoding capability
". This
capability allows BGP speakers to discover whether, for a given NLRI capability allows BGP speakers to discover whether, for a given NLRI
&lt;AFI/SAFI&gt;, a peer supports advertisement with a next hop whose &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 network protocol is determined by the value of the Length of Next Hop
Address field, as specified in <xref target="extension"/>. Address field, as specified in <xref target="extension" format="default"/>.
</t> </t>
<t> <t>
A BGP speaker that wishes to advertise to a BGP peer an IPv6 Next Hop A BGP speaker that wishes to advertise an IPv6 next hop for IPv4 NLRI
for IPv4 NLRI or for VPN-IPv4 NLRI as per this specification MUST use or for VPN-IPv4 NLRI to a BGP peer as per this specification <bcp14>MUST<
the Capability Advertisement procedures defined in <xref target="RFC5492"/> w /bcp14> use
ith the the Capability Advertisement procedures defined in <xref target="RFC5492" for
Extended Next Hop Encoding Capability to determine whether its peer mat="default"/> with the
Extended Next Hop Encoding capability to determine whether its peer
supports this for the NLRI AFI/SAFI pair(s) of interest. The fields supports this for the NLRI AFI/SAFI pair(s) of interest. The fields
in the Capabilities Optional Parameter MUST be set as follows: in the Capabilities Optional Parameter <bcp14>MUST</bcp14> be set as follows:
<list style="symbols"> </t>
<ul spacing="normal">
<t>The Capability Code field MUST be set to 5 (which indicates the <li>The Capability Code field <bcp14>MUST</bcp14> be set to 5 (which ind
Extended Next Hop Encoding capability).</t> icates the
Extended Next Hop Encoding capability).</li>
<t>The Capability Length field is set to a variable value that is the <li>The Capability Length field is set to a variable value that is the
length of the Capability Value field (which follows).</t> length of the Capability Value field (which follows).</li>
<li>
<t>The Capability Value field has the following format:
</t>
<t>The Capability Value field has the following format: <artwork name="" type="" align="left" alt=""><![CDATA[
<figure>
<artwork>
+-----------------------------------------------------+ +-----------------------------------------------------+
| NLRI AFI - 1 (2 octets) | | NLRI AFI - 1 (2 octets) |
+-----------------------------------------------------+ +-----------------------------------------------------+
| NLRI SAFI - 1 (2 octets) | | NLRI SAFI - 1 (2 octets) |
+-----------------------------------------------------+ +-----------------------------------------------------+
| Nexthop AFI - 1 (2 octets) | | Nexthop AFI - 1 (2 octets) |
+-----------------------------------------------------+ +-----------------------------------------------------+
| ..... | | ..... |
+-----------------------------------------------------+ +-----------------------------------------------------+
| NLRI AFI - N (2 octets) | | NLRI AFI - N (2 octets) |
+-----------------------------------------------------+ +-----------------------------------------------------+
| NLRI SAFI - N (2 octets) | | NLRI SAFI - N (2 octets) |
+-----------------------------------------------------+ +-----------------------------------------------------+
| Nexthop AFI - N (2 octets) | | Nexthop AFI - N (2 octets) |
+-----------------------------------------------------+ +-----------------------------------------------------+
</artwork> ]]></artwork>
</figure> <t>
where: where:
<list style="symbols"> </t>
<ul spacing="normal">
<t>each triple &lt;NLRI AFI, NLRI SAFI, Nexthop AFI&gt; indicates that <li>each triple &lt;NLRI AFI, NLRI SAFI, Nexthop AFI&gt; indicates
NLRI of &lt;NLRI AFI / NLRI SAFI&gt; may be advertised with a Next that the NLRI of &lt;NLRI AFI / NLRI SAFI&gt; may be advertised with
Hop address belonging to the network-layer protocol of Nexthop a next-hop address belonging to the network-layer protocol of Nexthop
AFI.</t> AFI.</li>
<li>the AFI and SAFI values are defined in the "Address
<t>the AFI and SAFI values are defined in the Address Family Family Numbers"
Identifier and Subsequent Address Family Identifier registries and "Subsequent Address Family Identifier (SAFI) Parameters" registries
maintained by IANA.</t> (see <xref target="IANA-AFI"/> and <xref
</list> target="IANA-SAFI"/>, respectively).</li>
</t> </ul>
</li>
</list> </ul>
</t> <t>
<t>
Since this document only concerns itself with the advertisement of Since this document only concerns itself with the advertisement of
IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop, this specification IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 next hop, this specification
only allows the following values in the Capability Value field of the only allows the following values in the Capability Value field of the
Extended Next Hop Encoding capability: Extended Next Hop Encoding capability:
<list style="symbols"> </t>
<ul spacing="normal">
<t>NLRI AFI = 1 (IPv4)</t> <li>NLRI AFI = 1 (IPv4)</li>
<li>NLRI SAFI = 1, 2, 4, 128, or 129</li>
<t>NLRI SAFI = 1, 2, 4, 128 or 129</t> <li>Nexthop AFI = 2 (IPv6)</li>
</ul>
<t>Nexthop AFI = 2 (IPv6)</t> <t>
</list>
</t>
<t>
This document does not specify the use of the Extended Next Hop Encoding capa bility with any other combinations of &lt;NLRI AFI, This document does not specify the use of the Extended Next Hop Encoding capa bility with any other combinations of &lt;NLRI AFI,
NLRI SAFI, Nexthop AFI&gt;. For example, the Next Hop Encoding capability spe cified in this document is not intended to be used for NLRI SAFI, Nexthop AFI&gt;. For example, the Next Hop Encoding capability spe cified in this document is not intended to be used for
NLRI AFI/SAFIs whose definition already allows use of both IPv4 and NLRI 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="RF IPv6 next hops (e.g., AFI/SAFI = &lt;1/132&gt; as defined in <xref target="RF
C4684"/>). C4684" format="default"/>).
Similarly, it is not intended that the Extended Next Hop Encoding capability Similarly, it is not intended that the Extended Next Hop Encoding capability
be used for NLRI AFI/SAFIs for which there is already a solution for advertising be used for NLRI AFIs/SAFIs for which there is already a solution for advertisin
a next hop of a different address family g 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 IPv4 Next Hop (e.g., AFI/SAFI = &lt;2/1&gt;, &lt;2/2&gt;, or &lt;2/4&gt; with an IPv4 next
as per hop as per
<xref target="RFC4798"/> and AFI/SAFI = &lt;2/128&gt; with IPv4 Next Hop as p <xref target="RFC4798" format="default"/> and AFI/SAFI = &lt;2/128&gt; with
er an IPv4 next hop as per
<xref target="RFC4659"/>).</t> <xref target="RFC4659" format="default"/>).</t>
<t>
<t> It is expected that if new AFIs/SAFIs are defined in the future, their
It is expected that if new AFI/SAFIs are defined in the future, their definitions will have provisions (where appropriate) for both IPv4 and
definition will have provisions (where appropriate) for both IPv4 and IPv6 next hops from the beginning, with the determination based on the Length
IPv6 Next Hops from the beginning, with determination based on Length of of
Next Hop Address field. Thus, new AFI/SAFIs are not expected to make Next Hop Address field. Thus, new AFIs/SAFIs are not expected to make
use of the Extended Next Hop Encoding capability. use of the Extended Next Hop Encoding capability.
</t> </t>
<t>
<t> A BGP speaker <bcp14>MUST</bcp14> only advertise the IPv4 or VPN-IPv4
A BGP speaker MUST only advertise to a BGP peer the IPv4 or VPN-IPv4 NLRI with an IPv6 next hop to a BGP peer if the BGP speaker has first ascerta
NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained ined
via BGP Capability Advertisement that the BGP peer supports the via the BGP Capability Advertisement that the BGP peer supports the
Extended Next Hop Encoding capability for the relevant AFI/SAFI pair. Extended Next Hop Encoding capability for the relevant AFI/SAFI pair.
</t> </t>
<t>
<t>
The Extended Next Hop Encoding capability provides information about The Extended Next Hop Encoding capability provides information about
next hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is 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. It does not influence whether that AFI/SAFI is indeed
allowed. Whether a AFI/SAFI can be used between the BGP peers is allowed. Whether an AFI/SAFI can be used between the BGP peers is
purely determined through the Multiprotocol Extensions capability purely determined through the Multiprotocol Extensions capability
defined in <xref target="RFC4760"/>. defined in <xref target="RFC4760" format="default"/>.
</t> </t>
</section>
</section> <section anchor="operations" numbered="true" toc="default">
<section anchor="operations" title="Operations"> <name>Operations</name>
<t> <t>
By default, if a particular BGP session is running over IPvx (where By default, if a particular BGP session is running over IPvx (where
IPvx is IPv4 or IPv6), and if the BGP speaker sending an update is IPvx is IPv4 or IPv6) and if the BGP speaker sending an update is
putting its own address in as the next hop, then the next hop address putting its own address in as the next hop, then the next-hop address
SHOULD be specified as an IPvx address, using the encoding rules <bcp14>SHOULD</bcp14> be specified as an IPvx address, using the encoding rul
es
specified in the AFI/SAFI definition of the NLRI being updated. This specified in the AFI/SAFI definition of the NLRI being updated. This
default behavior may be overridden by policy. default behavior may be overridden by policy.
</t> </t>
<t> <t>
When a next hop address needs to be passed along unchanged (e.g., as When a next-hop address needs to be passed along unchanged (e.g., as
a Route Reflector (RR) would do), its encoding MUST NOT be changed. a Route Reflector (RR) would do), its encoding <bcp14>MUST NOT</bcp14> be cha
nged.
If a particular RR client cannot handle that encoding (as determined If a particular RR client cannot handle that encoding (as determined
by the BGP Capability Advertisement), then the NLRI in question by the BGP Capability Advertisement), then the NLRI in question
cannot be distributed to that client. For sound routing in certain cannot be distributed to that client. For sound routing in certain
scenarios, this will require that all the RR clients be able to scenarios, this will require that all the RR clients be able to
handle whatever encodings any of them may generate. handle whatever encodings any of them may generate.
</t> </t>
</section>
</section> <section anchor="examples" numbered="true" toc="default">
<section anchor="examples" title="Usage Examples"> <name>Usage Examples</name>
<section anchor="example-ipv4oipv6" title="IPv4 over IPv6 Core"> <section anchor="example-ipv4oipv6" numbered="true" toc="default">
<t> <name>IPv4 over IPv6 Core</name>
<t>
The extensions defined in this document may be used as discussed in The extensions defined in this document may be used as discussed in
<xref target="RFC5565"/> for the interconnection of IPv4 islands over an IPv6 <xref target="RFC5565" format="default"/> for the interconnection of IPv4 isl ands over an IPv6
backbone. In this application, Address Family Border Routers (AFBRs; backbone. In this application, Address Family Border Routers (AFBRs;
as defined in <xref target="RFC4925"/>) advertise IPv4 NLRI in the MP_REACH_N as defined in <xref target="RFC4925" format="default"/>) advertise IPv4 NLRI
LRI in the MP_REACH_NLRI
along with an IPv6 Next Hop.</t> along with an IPv6 next hop.</t>
<t> <t>
The MP_REACH_NLRI is encoded with: The MP_REACH_NLRI is encoded with:
<list style="symbols"> </t>
<ul spacing="normal">
<t>AFI = 1</t> <li>AFI = 1</li>
<li>SAFI = 1</li>
<t>SAFI = 1</t> <li>Length of Next Hop Address field = 16 (or 32)</li>
<li>Next Hop Address = IPv6 address of the next hop</li>
<t>Length of Next Hop Network Address = 16 (or 32)</t> <li>NLRI = IPv4 routes</li>
</ul>
<t>Network Address of Next Hop = IPv6 address of Next Hop</t> <t>
During BGP Capability Advertisement, the PE routers would include the followi
<t>NLRI = IPv4 routes</t> ng fields in the Capabilities Optional Parameter:
</list> </t>
</t> <ul spacing="normal">
<t> <li>Capability Code set to "Extended Next Hop Encoding"</li>
During BGP Capability Advertisement, the PE routers would include the <li>Capability Value containing &lt;NLRI AFI=1, NLRI SAFI=1, Nexthop
following fields in the Capabilities Optional Parameter: AFI=2&gt;</li>
<list style="symbols"> </ul>
</section>
<t>Capability Code set to "Extended Next Hop Encoding"</t> <section anchor="example-vpnv4unoipv6" numbered="true" toc="default">
<name>IPv4 VPN Unicast over IPv6 Core</name>
<t>Capability Value containing &lt;NLRI AFI=1, NLRI SAFI=1, Nexthop <t>
AFI=2&gt;</t>
</list>
</t>
</section>
<section anchor="example-vpnv4unoipv6" title="IPv4 VPN unicast ov
er IPv6 Core">
<t>
The extensions defined in this document may be used for support of The extensions defined in this document may be used for support of
IPv4 VPNs over an IPv6 backbone. In this application, PE routers 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 would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6
Next Hop. next hop.
</t> </t>
<t> <t>
The MP_REACH_NLRI is encoded with: The MP_REACH_NLRI is encoded with:
<list style="symbols"> </t>
<ul spacing="normal">
<t>AFI = 1</t> <li>AFI = 1</li>
<li>SAFI = 128</li>
<t>SAFI = 128</t> <li>Length of Next Hop Address field = 24 (or 48)</li>
<li>Next Hop Address = VPN-IPv6 address of a next hop whose RD is set
<t>Length of Next Hop Network Address = 24 (or 48)</t> to zero</li>
<li>NLRI = IPv4-VPN routes</li>
<t>Network Address of Next Hop = VPN-IPv6 address of Next Hop whose RD is </ul>
set to zero</t> <t>
<t>NLRI = IPv4-VPN routes</t>
</list>
</t>
<t>
During BGP Capability Advertisement, the PE routers would include the During BGP Capability Advertisement, the PE routers would include the
following fields in the Capabilities Optional Parameter: following fields in the Capabilities Optional Parameter:
<list style="symbols"> </t>
<t>Capability Code set to "Extended Next Hop Encoding"</t> <ul spacing="normal">
<li>Capability Code set to "Extended Next Hop Encoding"</li>
<t>Capability Value containing &lt;NLRI AFI=1, NLRI SAFI=128, Nexthop <li>Capability Value containing &lt;NLRI AFI=1, NLRI SAFI=128, Nexthop
AFI=2&gt;</t> AFI=2&gt;</li>
</list> </ul>
</t> </section>
</section> <section anchor="example-vpnv4multoipv6" numbered="true" toc="default">
<section anchor="example-vpnv4multoipv6" title="IPv4 VPN multicas <name>IPv4 VPN Multicast over IPv6 Core</name>
t over IPv6 Core"> <t>
<t>
The extensions defined in this document may be used for support of The extensions defined in this document may be used for support of
IPv4 multicast VPNs over an IPv6 backbone. In this application, PE routers 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 would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6
Next Hop. next hop.
</t> </t>
<t> <t>
The MP_REACH_NLRI is encoded with: The MP_REACH_NLRI is encoded with:
<list style="symbols"> </t>
<ul spacing="normal">
<t>AFI = 1</t> <li>AFI = 1</li>
<li>SAFI = 129</li>
<t>SAFI = 129</t> <li>Length of Next Hop Address field = 24 (or 48)</li>
<li>Next Hop Address = VPN-IPv6 address of a next hop whose RD is set
<t>Length of Next Hop Network Address = 24 (or 48)</t> to zero</li>
<li>NLRI = IPv4-VPN routes</li>
<t>Network Address of Next Hop = VPN-IPv6 address of Next Hop whose RD is </ul>
set to zero</t> <t>
<t>NLRI = IPv4-VPN routes</t>
</list>
</t>
<t>
During BGP Capability Advertisement, the PE routers would include the During BGP Capability Advertisement, the PE routers would include the
following fields in the Capabilities Optional Parameter: following fields in the Capabilities Optional Parameter:
<list style="symbols"> </t>
<t>Capability Code set to "Extended Next Hop Encoding"</t> <ul spacing="normal">
<li>Capability Code set to "Extended Next Hop Encoding"</li>
<t>Capability Value containing &lt;NLRI AFI=1, NLRI SAFI=129, Nexthop <li>Capability Value containing &lt;NLRI AFI=1, NLRI SAFI=129, Nexthop
AFI=2&gt;</t> AFI=2&gt;</li>
</list> </ul>
</t> </section>
</section> </section>
</section> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="IANA" title="IANA Considerations"> <t>This document does not define any new code points from those
<t>This document does not define any new code point compared to <xref tar included in <xref target="RFC5549" format="default"/>. </t>
get="RFC5549"/>. </t> <t><xref target="RFC5549" format="default"/> added "Extended
<t><xref target="RFC5549"/> added "Extended Next Hop Encoding" to the Capabi Next Hop Encoding" to the "Capability Codes" registry (<xref target="IANA-
lity Codes registry, which was created by <xref target="RFC5492"/>. CAP-CODE"/>), which was created by <xref target="RFC5492" format="default"/>.
IANA is requested to update the definition of that entry to refer instead IANA has updated the registration of that entry to refer to this document
to this document. The value allocated for this Capability . The value allocated for this Capability
Code is 5.</t> Code is 5.</t>
</section> </section>
<section anchor="security" title="Security Considerations"> <section anchor="security" numbered="true" toc="default">
<t> <name>Security Considerations</name>
<t>
This document does not raise any additional security issues beyond This document does not raise any additional security issues beyond
those of BGP-4 and the Multiprotocol extensions for BGP-4. The same those of BGP-4 and the Multiprotocol Extensions for BGP-4. The same
security mechanisms are applicable.</t> security mechanisms are applicable.</t>
<t> <t>
However, as <xref target="RFC4272"/> discusses, BGP is vulnerable to traffic However, as <xref target="RFC4272" format="default"/> discusses, BGP is vulne
diversion attacks. rable to traffic diversion attacks.
The ability to advertise an IPv6 Next Hop adds a new means by which an The ability to advertise an IPv6 next hop adds a new means by which an
attacker could cause traffic to be diverted from its normal path. Such an attacker could cause traffic to be diverted from its normal path. Such an
attack differs from pre-existing vulnerabilities in that traffic could be attack differs from preexisting vulnerabilities in that traffic could be
forwarded to a distant target across an intervening network infrastructure forwarded to a distant target across an intervening network infrastructure
(e.g. an IPv6 core), allowing an attack to potentially succeed more (e.g., an IPv6 core), allowing an attack to potentially succeed more
easily, since less infrastructure would have to be subverted. Potential easily since less infrastructure would have to be subverted. Potential
consequences include "hijacking" of traffic or denial of service. consequences include "hijacking" of traffic or denial of service.
</t> </t>
<t> <t>
Although not expected to be the typical case, the IPv6 address used Although not expected to be the typical case, the IPv6 address used
as the BGP Next Hop Address could be an IPv4-mapped IPv6 address (as as the BGP next-hop address could be an IPv4-mapped IPv6 address (as
defined in <xref target="RFC4291"/>). Configuration of the security mechanis defined in <xref target="RFC4291" format="default"/>). Configuration of the
ms security mechanisms
potentially deployed by the network operator (such as security checks potentially deployed by the network operator (such as security checks
on next hop address) need to keep this case in mind also. on a next-hop address) also need to keep this case in mind.
</t> </t>
</section> </section>
<section anchor="ack" title="Acknowledgments">
<t>The authors would like to thank Francois Le Faucheur and Eric Rosen fo
r the edition and their work on <xref target="RFC5549"/>.</t>
<t>
The authors would like to thank Yakov Rekhter, Pranav Mehta, and John
Scudder for their contributions to the approach defined in <xref target="RFC5
549"/>.
</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
&RFC2119; <name>References</name>
&RFC2545; <references>
&RFC4291; <name>Normative References</name>
&RFC4364; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC4760; FC.2119.xml"/>
&RFC5492; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC8174; FC.2545.xml"/>
&RFC8277; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</references> FC.4291.xml"/>
<references title="Informative References"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC4659; FC.4364.xml"/>
&RFC4684; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC4272; FC.4760.xml"/>
&RFC4798; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC4925; FC.5492.xml"/>
&RFC8126; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC5549; FC.8174.xml"/>
&RFC5565; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC6074; FC.8277.xml"/>
&RFC6513; </references>
&RFC6514; <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.R
FC.4659.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4684.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4272.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4798.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4925.x
ml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5549.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5565.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6074.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6513.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6514.x
ml"/>
<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> </references>
<!-- references title="Informative References"> <section anchor="ack" numbered="false" toc="default">
</references --> <name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Francois Le Faucheur
"/> and <contact fullname="Eric Rosen"/> for their work on <xref target="RFC5549
" format="default"/>.</t>
<t>
The authors would like to thank <contact fullname="Yakov Rekhter"/>, <con
tact fullname="Pranav Mehta"/>, and <contact fullname="John
Scudder"/> for their contributions to the approach defined in <xref target="R
FC5549" format="default"/>.
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 84 change blocks. 
532 lines changed or deleted 524 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/