rfc9747xml2.original.xml   rfc9747.xml 
<?xml version="1.0" encoding="iso-8859-1"?> <?xml version='1.0' encoding='UTF-8'?>
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-bfd-unaffiliated-echo- <!DOCTYPE rfc [
14" updates="5880" consensus="true" submissionType="IETF"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"
<title abbrev="Unaffiliated BFD Echo"> Unaffiliated Bidirectional Forwarding docName="draft-ietf-bfd-unaffiliated-echo-14" number="9747" obsoletes="" update
Detection (BFD) Echo </title> s="5880" consensus="true" submissionType="IETF" tocInclude="true" symRefs="true"
sortRefs="true" version="3" xml:lang="en">
<front>
<title abbrev="Unaffiliated BFD Echo"> Unaffiliated Bidirectional Forwarding
Detection (BFD) Echo </title>
<seriesInfo name="RFC" value="9747"/>
<author fullname="Weiqiang Cheng" initials="W" surname="Cheng"> <author fullname="Weiqiang Cheng" initials="W" surname="Cheng">
<organization>China Mobile</organization> <organization>China Mobile</organization>
<address> <address>
<postal> <postal>
<street></street> <city>Beijing</city>
<!-- Reorder these if your country does things differently --> <country>China</country>
<city>Beijing</city>
<region></region>
<code></code>
<country>China</country>
</postal> </postal>
<phone></phone>
<email>chengweiqiang@chinamobile.com</email> <email>chengweiqiang@chinamobile.com</email>
<!-- uri and facsimile elements may also be added --> </address>
</address>
</author> </author>
<author fullname="Ruixue Wang" initials="R" surname="Wang"> <author fullname="Ruixue Wang" initials="R" surname="Wang">
<organization>China Mobile</organization> <organization>China Mobile</organization>
<address> <address>
<postal> <postal>
<street></street> <city>Beijing</city>
<!-- Reorder these if your country does things differently --> <country>China</country>
<city>Beijing</city>
<region></region>
<code></code>
<country>China</country>
</postal> </postal>
<phone></phone>
<email>wangruixue@chinamobile.com</email> <email>wangruixue@chinamobile.com</email>
<!-- uri and facsimile elements may also be added --> </address>
</address>
</author> </author>
<author fullname="Xiao Min" initials="X" surname="Min" role="editor"> <author fullname="Xiao Min" initials="X" surname="Min" role="editor">
<organization>ZTE Corp.</organization> <organization>ZTE Corp.</organization>
<address> <address>
<postal> <postal>
<street></street> <city>Nanjing</city>
<!-- Reorder these if your country does things differently --> <country>China</country>
<city>Nanjing</city>
<region></region>
<code></code>
<country>China</country>
</postal> </postal>
<phone></phone>
<email>xiao.min2@zte.com.cn</email> <email>xiao.min2@zte.com.cn</email>
<!-- uri and facsimile elements may also be added --> </address>
</address>
</author> </author>
<author fullname="Reshad Rahman" initials="R" surname="Rahman"> <author fullname="Reshad Rahman" initials="R" surname="Rahman">
<organization>Equinix</organization> <organization>Equinix</organization>
<address> <address>
<postal> <postal>
<street></street> <city>Ottawa</city>
<!-- Reorder these if your country does things differently --> <country>Canada</country>
<city>Ottawa</city>
<region></region>
<code></code>
<country>Canada</country>
</postal> </postal>
<phone></phone>
<email>reshad@yahoo.com</email> <email>reshad@yahoo.com</email>
<!-- uri and facsimile elements may also be added --> </address>
</address>
</author> </author>
<author fullname="Raj Chetan Boddireddy" initials="R" surname="Boddireddy"> <author fullname="Raj Chetan Boddireddy" initials="R" surname="Boddireddy">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>rchetan@juniper.net</email> <email>rchetan@juniper.net</email>
<!-- uri and facsimile elements may also be added --> </address>
</address>
</author> </author>
<date year="2025" month="March"/>
<area>RTG</area>
<workgroup>bfd</workgroup>
<date year="2024"/> <keyword>single-ended BFD</keyword>
<area>Routing</area>
<workgroup>BFD Working Group</workgroup>
<keyword>Request for Comments</keyword>
<keyword>RFC</keyword>
<keyword>Internet Draft</keyword>
<keyword>I-D</keyword>
<abstract> <abstract>
<t>
<t>
This document specifies an extension to the Bidirectional Forwarding Dete ction (BFD) This document specifies an extension to the Bidirectional Forwarding Dete ction (BFD)
protocol that enables the use of the BFD Echo function without the need f or an associated protocol that enables the use of the BFD Echo function without the need f or an associated
BFD control session. This "Unaffiliated BFD Echo" mechanism allows rapid detection of BFD control session. This "Unaffiliated BFD Echo" mechanism allows rapid detection of
forwarding path failures in networks where establishing BFD control sessi ons is impractical forwarding path failures in networks where establishing BFD control sessi ons is impractical
or undesirable. By decoupling the Echo function from the control plane, n etwork devices can or undesirable. By decoupling the Echo function from the control plane, n etwork devices can
utilize BFD's fast failure detection capabilities in a simplified manner, enhancing network utilize BFD's fast failure detection capabilities in a simplified manner, enhancing network
resiliency and operational efficiency. resiliency and operational efficiency.
</t> </t>
<t> <t>
This document updates RFC 5880 by defining a new Unaffiliated BFD Echo me chanism. This document updates RFC 5880 by defining a new Unaffiliated BFD Echo me chanism.
</t> </t>
</abstract> </abstract>
</front>
</front> <middle>
<section>
<middle> <name>Introduction</name>
<t>
<section title="Introduction">
<t>
To minimize the impact of device and link faults on services and to impro ve network availability To minimize the impact of device and link faults on services and to impro ve network availability
in single-hop scenarios, a network device needs the capability to quickly detect communication in single-hop scenarios, a network device needs the capability to quickly detect communication
faults with adjacent devices. Prompt detection allows for timely remedial actions to ensure faults with adjacent devices. Prompt detection allows for timely remedial actions to ensure
service continuity. service continuity.
</t> </t>
<t>
<t>
BFD <xref target="RFC5880"/> provides a low-overhead, short-interval meth od for detecting faults BFD <xref target="RFC5880"/> provides a low-overhead, short-interval meth od for detecting faults
on the communication path between adjacent forwarding engines, which may include interfaces, data on the communication path between adjacent forwarding engines, which may include interfaces, data
links, and the forwarding engines themselves. BFD offers a unified mechan ism to monitor any media links, and the forwarding engines themselves. BFD offers a unified mechan ism to monitor any media
and protocol layers in real time. and protocol layers in real time.
</t> </t>
<t>
<t> BFD defines two primary modes -- Asynchronous mode and Demand mode -- to
BFD defines two primary modes-Asynchronous mode and Demand mode-to accomm accommodate various deployment
odate various deployment
scenarios. Additionally, it supports an Echo function that reduces the le vel of BFD support required scenarios. Additionally, it supports an Echo function that reduces the le vel of BFD support required
in device implementations, as described in Section 3.2 of <xref target="R FC5880"/>. When the Echo in device implementations, as described in <xref section="3.2" sectionFor mat="of" target="RFC5880"/>. When the Echo
function is activated, the local system sends BFD Echo packets, and the r emote system loops back the function is activated, the local system sends BFD Echo packets, and the r emote system loops back the
received Echo packets through the forwarding path, as described in Sectio received Echo packets through the forwarding path, as described in <xref
n 5 of <xref target="RFC5880"/> section="5" sectionFormat="of" target="RFC5880"/>
and Section 4 of <xref target="RFC5881"/>. If several consecutive BFD Ech and <xref section="4" sectionFormat="of" target="RFC5881"/>. If several c
o packets are not received onsecutive BFD Echo packets are not received
by the local system, the BFD session is declared Down. by the local system, the BFD session is declared Down.
</t> </t>
<t>
<t>
There are two typical scenarios when using the BFD Echo function: There are two typical scenarios when using the BFD Echo function:
<list style="symbols"> </t>
<t> <ul spacing="normal">
<li>
<t>
Full BFD protocol capability with adjunct Echo function (Affiliated BFD E cho): This scenario requires Full BFD protocol capability with adjunct Echo function (Affiliated BFD E cho): This scenario requires
both the local device and the adjacent device to support the full BFD pro tocol. This operation remains both the local device and the adjacent device to support the full BFD pro tocol. This operation remains
unchanged from <xref target="RFC5880"/>. unchanged from <xref target="RFC5880"/>.
</t> </t>
<t> </li>
<li>
<t>
BFD Echo-Only method without full BFD protocol capability (Unaffiliated B FD Echo): This scenario requires BFD Echo-Only method without full BFD protocol capability (Unaffiliated B FD Echo): This scenario requires
only the local device to support sending and demultiplexing BFD Control p ackets. In this case, BFD only the local device to support sending and demultiplexing BFD Control p ackets. In this case, BFD
Control packets are sent over the BFD Echo port, and the processing proce dures for Asynchronous mode Control packets are sent over the BFD Echo port, and the processing proce dures for Asynchronous mode
are used with the modifications specified in this document. Note that thi s method requires the local device are used with the modifications specified in this document. Note that thi s method requires the local device
to send packets with one of its own IP addresses as the destination addre ss, upon receipt of which the adjacent to send packets with one of its own IP addresses as the destination addre ss, upon receipt of which the adjacent
device loops them back to the local device. Also note that this method mo nitors the connectivity to a device device loops them back to the local device. Also note that this method mo nitors the connectivity to a device
over a specific interface and does not verify the availability of a speci fic IP address at that device. over a specific interface and does not verify the availability of a speci fic IP address at that device.
</t> </t>
</list> </li>
</ul>
<t>
This document specifies the Unaffiliated BFD Echo scenario. This document specifies the Unaffiliated BFD Echo scenario.
</t> </t>
<t>
<t> <xref section="5" sectionFormat="of" target="RFC5880"/> indicates that th
Section 5 of <xref target="RFC5880"/> indicates that the payload of an Af e payload of an Affiliated BFD Echo packet is a local
filiated BFD Echo packet is a local matter; therefore, its contents are outside the scope of that specificati
matter and, therefore, its contents are outside the scope of that specifi on. This document, however,
cation. This document, however,
specifies the contents of the Unaffiliated BFD Echo packet and the proced ures for handling them. While this specifies the contents of the Unaffiliated BFD Echo packet and the proced ures for handling them. While this
may appear to contravene Section 5 of <xref target="RFC5880"/>, the core behavior in that RFC states that the may appear to contravene <xref section="5" sectionFormat="of" target="RFC 5880"/>, the core behavior in that RFC states that the
contents of BFD Echo packets are a local matter; this document is definin g that "local matter". Regarding the contents of BFD Echo packets are a local matter; this document is definin g that "local matter". Regarding the
selection of IP addresses, the rules stated in Section 4 of <xref target= "RFC5881"/> are applicable to the selection of IP addresses, the rules stated in <xref section="4" sectionF ormat="of" target="RFC5881"/> are applicable to the
encapsulation of an Unaffiliated BFD Echo packet. encapsulation of an Unaffiliated BFD Echo packet.
</t> </t>
<t>
<t>
Section 6.2.2 of <xref target="BBF-TR-146"/> describes a use case for the Unaffiliated BFD Echo. Section 6.2.2 of <xref target="BBF-TR-146"/> describes a use case for the Unaffiliated BFD Echo.
</t> </t>
<t>
<t>
This document updates <xref target="RFC5880"/> by defining a new method o f BFD Echo-only operation which only This document updates <xref target="RFC5880"/> by defining a new method o f BFD Echo-only operation which only
impacts the BFD Echo packets sender without requiring an implementation t impacts the sender of BFD Echo packets without requiring an implementatio
o support the BFD protocol at the n to support the BFD protocol at the
loop-back device, such that any IP forwarder can loop-back the BFD Echo p loopback device, such that any IP forwarder can loop back the BFD Echo pa
ackets. It specifies the use of the ckets. It specifies the use of the
Unaffiliated BFD Echo over IPv4 and IPv6 for a single IP hop. The reason why it cannot be used for multihop Unaffiliated BFD Echo over IPv4 and IPv6 for a single IP hop. The reason why it cannot be used for multihop
paths is that the Unaffiliated BFD Echo packets would be looped back by t he first hop. A full description of paths is that the Unaffiliated BFD Echo packets would be looped back by t he first hop. A full description of
the updates to <xref target="RFC5880"/> is provided in Section 3. the updates to <xref target="RFC5880"/> is provided in <xref target="upda
</t> tes-to-rfc-5880"/>.
</t>
<section title="Conventions Used in This Document"> <section>
<name>Conventions Used in This Document</name>
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this documen "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
t are to be interpreted ",
as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
when, and only when, they "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
</section> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
</section> shown here.
</t>
<section title="Unaffiliated BFD Echo Procedures"> </section>
</section>
<t> <section anchor="unaffiliated-bfd-echo-procedures">
<name>Unaffiliated BFD Echo Procedures</name>
<t>
This section specifies the Unaffiliated BFD Echo procedures. This section specifies the Unaffiliated BFD Echo procedures.
</t> </t>
<figure anchor="Figure_1">
<figure anchor="Figure_1" title="Unaffiliated BFD Echo diagram"> <name>Unaffiliated BFD Echo</name>
<artset> <artset>
<artwork type="svg"> <artwork type="svg">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="272" width=" 512" viewBox="0 0 512 272" class="diagram" text-anchor="middle" font-family="mon ospace" font-size="13px" stroke-linecap="round"> <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="272" width=" 512" viewBox="0 0 512 272" class="diagram" text-anchor="middle" font-family="mon ospace" font-size="13px" stroke-linecap="round">
<path d="M 8,32 L 8,240" fill="none" stroke="black"/> <path d="M 8,32 L 8,240" fill="none" stroke="black"/>
<path d="M 40,64 L 40,192" fill="none" stroke="black"/> <path d="M 40,64 L 40,192" fill="none" stroke="black"/>
<path d="M 144,32 L 144,88" fill="none" stroke="black"/> <path d="M 144,32 L 144,88" fill="none" stroke="black"/>
<path d="M 144,104 L 144,136" fill="none" stroke="black"/> <path d="M 144,104 L 144,136" fill="none" stroke="black"/>
<path d="M 144,184 L 144,240" fill="none" stroke="black"/> <path d="M 144,184 L 144,240" fill="none" stroke="black"/>
<path d="M 368,32 L 368,136" fill="none" stroke="black"/> <path d="M 368,32 L 368,136" fill="none" stroke="black"/>
<path d="M 368,184 L 368,240" fill="none" stroke="black"/> <path d="M 368,184 L 368,240" fill="none" stroke="black"/>
<path d="M 384,144 L 384,176" fill="none" stroke="black"/> <path d="M 384,144 L 384,176" fill="none" stroke="black"/>
<path d="M 504,32 L 504,240" fill="none" stroke="black"/> <path d="M 504,32 L 504,240" fill="none" stroke="black"/>
<path d="M 8,32 L 144,32" fill="none" stroke="black"/> <path d="M 8,32 L 144,32" fill="none" stroke="black"/>
<path d="M 368,32 L 504,32" fill="none" stroke="black"/> <path d="M 368,32 L 504,32" fill="none" stroke="black"/>
<path d="M 48,64 L 136,64" fill="none" stroke="black"/> <path d="M 48,64 L 136,64" fill="none" stroke="black"/>
<path d="M 136,96 L 160,96" fill="none" stroke="black"/> <path d="M 136,96 L 160,96" fill="none" stroke="black"/>
<path d="M 136,144 L 376,144" fill="none" stroke="black"/> <path d="M 136,144 L 376,144" fill="none" stroke="black"/>
<path d="M 128,176 L 376,176" fill="none" stroke="black"/> <path d="M 128,176 L 376,176" fill="none" stroke="black"/>
<path d="M 48,192 L 136,192" fill="none" stroke="black"/> <path d="M 48,192 L 136,192" fill="none" stroke="black"/>
<path d="M 8,240 L 144,240" fill="none" stroke="black"/> <path d="M 8,240 L 144,240" fill="none" stroke="black"/>
<path d="M 368,240 L 504,240" fill="none" stroke="black"/> <path d="M 368,240 L 504,240" fill="none" stroke="black"/>
<polygon class="arrowhead" points="168,96 156,90.4 156,101.6" fill="black" <polygon class="arrowhead" points="168,96 156,90.4 156,101.6" fill
transform="rotate(0,160,96)"/> ="black" transform="rotate(0,160,96)"/>
<polygon class="arrowhead" points="136,176 124,170.4 124,181.6" fill="blac <polygon class="arrowhead" points="136,176 124,170.4 124,181.6" fi
k" transform="rotate(180,128,176)"/> ll="black" transform="rotate(180,128,176)"/>
<g class="text"> <g class="text">
<text x="76" y="20">Device A</text> <text x="76" y="20">Device A</text>
<text x="436" y="20">Device B</text> <text x="436" y="20">Device B</text>
<text x="92" y="84">Unaffiliated</text> <text x="92" y="84">Unaffiliated</text>
<text x="84" y="100">BFD Echo</text> <text x="84" y="100">BFD Echo</text>
<text x="80" y="116">Session</text> <text x="80" y="116">Session</text>
<text x="256" y="132">Unaffiliated BFD Echo</text> <text x="256" y="132">Unaffiliated BFD Echo</text>
<text x="408" y="148">BFD</text> <text x="408" y="148">BFD</text>
<text x="144" y="164">|</text> <text x="144" y="164">|</text>
<text x="424" y="164">packets</text> <text x="424" y="164">packets</text>
<text x="420" y="180">looped</text> <text x="420" y="180">looped</text>
<text x="72" y="260">BFD supported</text> <text x="72" y="260">BFD supported</text>
<text x="440" y="260">BFD not supported</text> <text x="440" y="260">BFD not supported</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="left"><![CDATA[ <artwork type="ascii-art" align="left"><![CDATA[
Device A Device B Device A Device B
+----------------+ +----------------+ +----------------+ +----------------+
| | | | | | | |
| |------------| | | | |------------| | |
| |Unaffiliated| | | | |Unaffiliated| | |
| | BFD Echo ---> | | | | BFD Echo ---> | |
| | Session | | | | | Session | | |
| | | Unaffiliated BFD Echo | | | | | Unaffiliated BFD Echo | |
| | -------------------------------| BFD | | | -------------------------------| BFD |
| | | | packets | | | | | packets |
| | <-------------------------------| looped | | | <-------------------------------| looped |
| |------------| | | | |------------| | |
| | | | | | | |
| | | | | | | |
+----------------+ +----------------+ +----------------+ +----------------+
BFD supported BFD not supported BFD supported BFD not supported
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>
<t> As shown in <xref target="Figure_1"/>, device A supports BFD, whereas device
As shown in Figure 1, device A supports BFD, whereas device B is a regular I B is a regular IP forwarder that does not support
P forwarder that does not support
BFD. Device A would send Unaffiliated BFD Echo packets, and after receivi ng the Unaffiliated BFD Echo packets BFD. Device A would send Unaffiliated BFD Echo packets, and after receivi ng the Unaffiliated BFD Echo packets
sent from device A, the one-hop-away BFD peer device B immediately loops them back by normal IP forwarding, this sent from device A, the one-hop-away BFD peer device B immediately loops them back by normal IP forwarding. This
allows device A to rapidly detect a connectivity loss to device B. Note t hat device B would not intercept any allows device A to rapidly detect a connectivity loss to device B. Note t hat device B would not intercept any
received Unaffiliated BFD Echo packet or parse any BFD protocol field wit hin the Unaffiliated BFD Echo packet. received Unaffiliated BFD Echo packet or parse any BFD protocol field wit hin the Unaffiliated BFD Echo packet.
</t> </t>
<t> <t>
An Unaffiliated BFD Echo session is not actually a BFD session because there is no coordination of BFD protocol An Unaffiliated BFD Echo session is not actually a BFD session because there is no coordination of BFD protocol
state between the two link ends: the remote end does not support BFD and state between the two link ends: the remote end does not support BFD and
so cannot engage in a BFD session. The so cannot engage in a BFD session.
local end as an initiator may regard the Unaffiliated BFD Echo session as
a BFD session from its own standpoint. From the standpoint of the local end (as an initiator),
</t> the Unaffiliated BFD Echo session may be regarded as a BFD session.
<t> </t>
<t>
For the Unaffiliated Echo procedure, an Unaffiliated BFD Echo session is established on device A. The session For the Unaffiliated Echo procedure, an Unaffiliated BFD Echo session is established on device A. The session
MUST adhere to the BFD state machine specified in Section 6.2 of <xref ta rget="RFC5880"/>, with the exception <bcp14>MUST</bcp14> adhere to the BFD state machine specified in <xref se ction="6.2" sectionFormat="of" target="RFC5880"/>, with the exception
that the received state is not derived from BFD Control packets originati ng from the remote system, but rather that the received state is not derived from BFD Control packets originati ng from the remote system, but rather
from packets that are generated by the local system and looped back from the remote system. Consequently, the from packets that are generated by the local system and looped back from the remote system. Consequently, the
AdminDown state is not utilized in Unaffiliated BFD Echo. AdminDown state is not utilized in Unaffiliated BFD Echo.
</t> </t>
<t> <t>
BFD Control packets are transmitted and received as Unaffiliated BFD Echo packets, using UDP destination port BFD Control packets are transmitted and received as Unaffiliated BFD Echo packets, using UDP destination port
3785, as defined in <xref target="RFC5881"/>. The standard procedures for BFD Asynchronous sessions are applied 3785, as defined in <xref target="RFC5881"/>. The standard procedures for BFD Asynchronous sessions are applied
to the looped BFD Control packets, including packet validation and authen tication, in accordance with <xref target="RFC5880"/>. to the looped BFD Control packets, including packet validation and authen tication, in accordance with <xref target="RFC5880"/>.
</t> </t>
<t> <t>
Once an Unaffiliated BFD Echo session is created on device A, it starts s ending Unaffiliated BFD Echo packets. Once an Unaffiliated BFD Echo session is created on device A, it starts s ending Unaffiliated BFD Echo packets.
Unaffiliated BFD Echo packets with zeroed "Your Discriminator" field are Unaffiliated BFD Echo
demultiplexed to the proper session based on packets with zeroed "Your Discriminator" field are demultiplexed to
the source IP address or UDP source port, once the remote system loops ba the proper session based on the source IP address or UDP source port.
ck the local discriminator, all further After the remote system loops back the local discriminator, all
received packets are demultiplexed based on the "Your Discriminator" fiel further received packets are demultiplexed based on the "Your
d only, which is conformed to the procedure Discriminator" field only, which conforms to the procedure
specified in Section 6.3 of <xref target="RFC5880"/>. An Unaffiliated BFD specified in
Echo packet follows the same encapsulation <xref section="6.3" sectionFormat="of" target="RFC5880"/>. An Unaffiliated BFD E
rules as for a BFD Echo packet as specified in Section 4 of <xref target= cho packet follows the same encapsulation
"RFC5881"/>. All Unaffiliated BFD Echo packets rules as for a BFD Echo packet as specified in <xref section="4" sectionF
for the session MUST be sent with a TTL or Hop Limit value of 255. Receiv ormat="of" target="RFC5881"/>. All Unaffiliated BFD Echo packets
ed packets MUST have a TTL or Hop Limit for the session <bcp14>MUST</bcp14> be sent with a TTL or Hop Limit value
value of 254 (similar to Appendix A of <xref target="RFC5082"/> to verify of 255. Received packets <bcp14>MUST</bcp14> have a TTL or Hop Limit
against a configured number of hops); otherwise, value of 254 (similar to <xref section="A" sectionFormat="of" target="RFC
the received packets MUST be dropped. 5082"/> to verify against a configured number of hops); otherwise,
</t> the received packets <bcp14>MUST</bcp14> be dropped.
<t> </t>
<t>
In the context of an Unaffiliated BFD Echo packet, the "Desired Min TX In terval" and "Required Min RX Interval" fields, In the context of an Unaffiliated BFD Echo packet, the "Desired Min TX In terval" and "Required Min RX Interval" fields,
as defined in <xref target="RFC5880"/>, MUST be populated with a specific as defined in <xref target="RFC5880"/>, <bcp14>MUST</bcp14> be populated
value to prevent the potential exposure of with a specific value to prevent the potential exposure of
uninitialized memory. It is RECOMMENDED that these fields be set to a val uninitialized memory. It is <bcp14>RECOMMENDED</bcp14> that these fields
ue of 1 second (1,000,000 microseconds). However, be set to a value of 1 second (1,000,000 microseconds). However,
upon receipt, these values MUST be ignored and MUST NOT be used in the ca upon receipt, these values <bcp14>MUST</bcp14> be ignored and <bcp14>MUST
lculation of the Detection Time. NOT</bcp14> be used in the calculation of the Detection Time.
</t> </t>
<t> <t>
The "Required Min Echo RX Interval" field, as defined in <xref target="RF The "Required Min Echo RX Interval" field, as defined in <xref target="RF
C5880"/>, MUST be populated with a specific value C5880"/>, <bcp14>MUST</bcp14> be populated with a specific value
to prevent the potential exposure of uninitialized memory. It is RECOMMEN to prevent the potential exposure of uninitialized memory. It is <bcp14>R
DED that this field be set to 0. However, this value ECOMMENDED</bcp14> that this field be set to 0. However, this value
MUST be ignored upon receipt. The transmission interval for Unaffiliated <bcp14>MUST</bcp14> be ignored upon receipt. The transmission interval fo
BFD Echo packets when in the Up state MUST be r Unaffiliated BFD Echo packets when in the Up state <bcp14>MUST</bcp14> be
provisioned on device A. provisioned on device A.
</t> </t>
<t> <t>
The functionality of the Unaffiliated BFD Echo feature is dependent on de vice B performing IP forwarding. While this capability The functionality of the Unaffiliated BFD Echo feature is dependent on de vice B performing IP forwarding. While this capability
is typically expected to be supported on routers, it may not be enabled b y default on hosts. The method for provisioning device is typically expected to be supported on routers, it may not be enabled b y default on hosts. The method for provisioning device
B to loop back Unaffiliated BFD Echo packets is outside the scope of this document. B to loop back Unaffiliated BFD Echo packets is outside the scope of this document.
</t> </t>
<t> <t>
Similar to what's specified in <xref target="RFC5880"/>, the Unaffiliated BFD Echo session begins with the Similar to what's specified in <xref target="RFC5880"/>, the Unaffiliated BFD Echo session begins with the
periodic, slow transmission of Unaffiliated BFD Echo packets. The slow tr ansmission rate should be no greater than periodic, slow transmission of Unaffiliated BFD Echo packets. The slow tr ansmission rate should be no greater than
one packet per second, until the session on device A is Up. After the ses sion is Up, the provisioned transmission interval is one packet per second, until the session on device A is Up. After the ses sion is Up, the provisioned transmission interval is
used. When the Unaffiliated BFD Echo session on device A goes Down, the s used. When the Unaffiliated BFD Echo session on device A goes Down, the s
low transmission rate is resumed. The "Detect Mult" low transmission rate is resumed. The "Detect Mult" field
defined in <xref target="RFC5880"/> MUST be set to a value provisioned on defined in <xref target="RFC5880"/> <bcp14>MUST</bcp14> be set to a value
device A. When the bfd.SessionState is provisioned on device A. When the bfd.SessionState is
Up and a "Detect Mult" number of Unaffiliated BFD Echo packets have not a rrived at device A as they should, the device Up and a "Detect Mult" number of Unaffiliated BFD Echo packets have not a rrived at device A as they should, the device
A "MUST set bfd.SessionState to Down and bfd.LocalDiag to 2 (Echo Functio A "<bcp14>MUST</bcp14> set bfd.SessionState to Down and bfd.LocalDiag to
n Failed)", as specified in Section 6.8.5 2 (Echo Function Failed)", as specified in
of <xref target="RFC5880"/>. <xref section="6.8.5" sectionFormat="of" target="RFC5880"/>.
</t> </t>
<t> <t>
In summary, the Unaffiliated BFD Echo packet reuses the format of the BFD Control packet defined in <xref target="RFC5880"/>, In summary, the Unaffiliated BFD Echo packet reuses the format of the BFD Control packet defined in <xref target="RFC5880"/>,
and the fields within the Unaffiliated BFD Echo packet are populated as f ollows: and the fields within the Unaffiliated BFD Echo packet are populated as f ollows:
<list style='symbols'> </t>
<t>My Discriminator: MUST be set to the provisioned local discrimina <ul spacing="normal">
tor.</t> <li>
<t>Your Discriminator: MUST initially be set to 0, and then MUST be <t>My Discriminator: <bcp14>MUST</bcp14> be set to the provisioned loc
set to the value of "My Discriminator" looped back al discriminator.</t>
</li>
<li>
<t>Your Discriminator: <bcp14>MUST</bcp14> initially be set to 0, and
then <bcp14>MUST</bcp14> be set to the value of "My Discriminator" looped back
from the remote system.</t> from the remote system.</t>
<t>Desired Min TX Interval: MUST be set to a specific value, with a </li>
suggested value of 1 second (1,000,000 microseconds).</t> <li>
<t>Required Min RX Interval: MUST be set to a specific value, with a <t>Desired Min TX Interval: <bcp14>MUST</bcp14> be set to a specific v
suggested value of 1 second (1,000,000 microseconds).</t> alue, with a suggested value of 1 second (1,000,000 microseconds).</t>
<t>Required Min Echo RX Interval: MUST be set to a specific value, w </li>
ith a suggested value of 0.</t> <li>
<t>Detect Mult: MUST be set to the provisioned maximum allowable num <t>Required Min RX Interval: <bcp14>MUST</bcp14> be set to a specific
ber of consecutively lost Unaffiliated BFD Echo packets.</t> value, with a suggested value of 1 second (1,000,000 microseconds).</t>
</list> </li>
</t> <li>
<t>Required Min Echo RX Interval: <bcp14>MUST</bcp14> be set to a spec
ific value, with a suggested value of 0.</t>
</li>
<li>
<t>Detect Mult: <bcp14>MUST</bcp14> be set to the provisioned maximum
allowable number of consecutively lost Unaffiliated BFD Echo packets.</t>
</li>
</ul>
</section> </section>
<section anchor="updates-to-rfc-5880">
<name>Updates to RFC 5880</name>
<t>
The Unaffiliated BFD Echo described in this document reuses the BFD
Echo function as described in <xref target="RFC5880"/> and <xref
target="RFC5881"/>, but does not require BFD Asynchronous or Demand
mode. In the Unaffiliated BFD Echo operation, only the local system
has the BFD protocol enabled, while the remote system simply loops
back the received BFD Echo packets as ordinary data packets, without
engaging in the BFD protocol.
</t>
<t>
This document updates <xref target="RFC5880"/> with respect to its
descriptions on the BFD Echo function as follows.
</t>
<t>
The 4th paragraph of <xref section="3.2" sectionFormat="of" target="RFC58
80"/> is
updated as below:
</t>
<section title="Updates to RFC 5880"> <t>OLD TEXT</t>
<blockquote>An adjunct to both modes is the Echo function.</blockquote>
<t> <t>NEW TEXT</t>
The Unaffiliated BFD Echo described in this document reuses the BFD Echo <blockquote>An adjunct to both modes is the Echo function, which can also
function as described in <xref target="RFC5880"/> and be running independently.</blockquote>
<xref target="RFC5881"/>, but does not require BFD Asynchronous or Demand
mode. In the Unaffiliated BFD Echo operation, only the
local system has the BFD protocol enabled, while the remote system simply
loops back the received BFD Echo packets as ordinary
data packets, without engaging in the BFD protocol.
</t>
<t> <t>OLD TEXT</t>
This document updates <xref target="RFC5880"/> with respect to its descri <blockquote>Since the Echo function is handling the task of detection,
ptions on the BFD Echo the rate of periodic transmission of Control packets may be reduced (in
function as follows. the case of Asynchronous mode) or eliminated completely (in the case of
</t> Demand mode).</blockquote>
<t> <t>NEW TEXT</t>
The 4th paragraph of Section 3.2 of <xref target="RFC5880"/> is updated a <blockquote>Since the Echo function is handling the task of detection,
s below: the rate of periodic transmission of Control packets may be reduced (in
</t> the case of Asynchronous mode) or eliminated completely (in the case of
Demand mode). The Echo function may also be used independently, with
neither Asynchronous nor Demand mode.</blockquote>
<t> <t>
<list> The 3rd and 9th paragraphs of <xref section="6.1" sectionFormat="of" targ
<t> et="RFC5880"/> are updated as below:
OLD TEXT<br/>An adjunct to both modes is the Echo function. </t>
</t>
<t>
NEW TEXT<br/>An adjunct to both modes is the Echo function, which can als
o be running independently.
</t>
<t>
OLD TEXT<br/>Since the Echo function is handling the task of detection, t
he rate of
periodic transmission of Control packets may be reduced (in the case
of Asynchronous mode) or eliminated completely (in the case of Demand mode).
</t>
<t>
NEW TEXT<br/>Since the Echo function is handling the task of detection, t
he rate of
periodic transmission of Control packets may be reduced (in the case
of Asynchronous mode) or eliminated completely (in the case of Demand mode).
The Echo function may also be used independently, with neither Asynchrono
us nor Demand mode.
</t>
</list>
</t>
<t> <t>OLD TEXT</t>
The 3rd and 9th paragraphs of Section 6.1 of <xref target="RFC5880"/> are <blockquote>Once the BFD session is Up, a system can choose to start the
updated as below: Echo function if it desires and the other system signals that it will
</t> allow it. The rate of transmission of Control packets is typically kept
low when the Echo function is active.</blockquote>
<t> <t>NEW TEXT</t>
<list> <blockquote>When a system is running with Asynchronous or Demand mode,
<t> once the BFD session is Up, it can choose to start the Echo function if
OLD TEXT<br/>Once the BFD session is Up, a system can choose to start the it desires and the other system signals that it will allow it. The rate
Echo of transmission of Control packets is typically kept low for
function if it desires and the other system signals that it will Asynchronous mode or eliminated completely for Demand mode when the Echo
allow it. The rate of transmission of Control packets is typically function is active.</blockquote>
kept low when the Echo function is active.
</t>
<t>
NEW TEXT<br/>When a system is running with Asynchronous or Demand mode,
once the BFD session is Up, it can choose to start the Echo
function if it desires and the other system signals that it will
allow it. The rate of transmission of Control packets is typically
kept low for Asynchronous mode or eliminated completely for Demand mode
when the Echo function is active.
</t>
<t>
OLD TEXT<br/>If the session goes Down, the transmission of Echo packets (
if any)
ceases, and the transmission of Control packets goes back to the slow
rate.
</t>
<t>
NEW TEXT<br/>In Asynchronous mode or Demand mode, if the session goes Dow
n, the transmission
of Echo packets (if any) ceases, and the transmission of Control packets
goes back to the slow rate.
</t>
</list>
</t>
<t> <t>OLD TEXT</t>
The 2nd paragraph of Section 6.4 of <xref target="RFC5880"/> is updated a <blockquote>If the session goes Down, the transmission of Echo packets
s below: (if any) ceases, and the transmission of Control packets goes back to
</t> the slow rate.</blockquote>
<t> <t>NEW TEXT</t>
<list> <blockquote>In Asynchronous mode or Demand mode, if the session goes
<t> Down, the transmission of Echo packets (if any) ceases, and the
OLD TEXT<br/>When a system is using the Echo function, it is advantageous transmission of Control packets goes back to the slow rate.</blockquote>
to
choose a sedate reception rate for Control packets, since liveness
detection is being handled by the Echo packets. This can be controlled
by manipulating the Required Min RX Interval field (see section 6.8.3).
</t>
<t>
NEW TEXT<br/>When a system is using the Echo function with Asynchronous m
ode, it is advantageous to
choose a sedate reception rate for Control packets, since liveness
detection is being handled by the Echo packets. This can be controlled
by manipulating the Required Min RX Interval field (see section 6.8.3).
Note that a system operating in Demand mode would direct the remote syste
m to cease
the periodic transmission of BFD Control packets, by setting the Demand (
D) bit in its
BFD Control packets.
</t>
</list>
</t>
<t> <t>
The 2nd paragraph of Section 6.8 of <xref target="RFC5880"/> is updated a The 2nd paragraph of <xref section="6.4" sectionFormat="of" target="RFC58
s below: 80"/> is updated as below:
</t> </t>
<t> <t>OLD TEXT</t>
<list> <blockquote>When a system is using the Echo function, it is advantageous
<t> to choose a sedate reception rate for Control packets, since liveness
OLD TEXT<br/>When a system is said to have "the Echo function active" it detection is being handled by the Echo packets. This can be controlled
means by manipulating the Required Min RX Interval field (see section 6.8.3).</b
that the system is sending BFD Echo packets, implying that the lockquote>
session is Up and the other system has signaled its willingness to
loop back Echo packets.
</t>
<t>
NEW TEXT<br/>When a system in Asynchronous or Demand mode is said to have
"the Echo function active" it means
that the system is sending BFD Echo packets, implying that the
session is Up and the other system has signaled its willingness to
loop back Echo packets.
</t>
</list>
</t>
<t> <t>NEW TEXT</t>
The 7th paragraph of Section 6.8.3 of <xref target="RFC5880"/> is updated <blockquote>When a system is using the Echo function with Asynchronous
as below: mode, it is advantageous to choose a sedate reception rate for Control
</t> packets, since liveness detection is being handled by the Echo
packets. This can be controlled by manipulating the Required Min RX
Interval field (see section <xref target="RFC5880" section="6.8.3" section
Format="bare"/>). Note that a system operating in
Demand mode would direct the remote system to cease the periodic
transmission of BFD Control packets, by setting the Demand (D) bit in
its BFD Control packets.</blockquote>
<t> <t>
<list> The 2nd paragraph of <xref section="6.8" sectionFormat="of" target="RFC58
<t> 80"/> is updated as below:
OLD TEXT<br/>When the Echo function is active, a system SHOULD set </t>
bfd.RequiredMinRxInterval to a value of not less than one second
(1,000,000 microseconds). This is intended to keep received BFD
Control traffic at a negligible level, since the actual detection
function is being performed using BFD Echo packets.
</t>
<t>
NEW TEXT<br/>When the Echo function is active with Asynchronous mode, a s
ystem SHOULD set
bfd.RequiredMinRxInterval to a value of not less than one second
(1,000,000 microseconds). This is intended to keep received BFD
Control traffic at a negligible level, since the actual detection
function is being performed using BFD Echo packets. A system operating in
Demand mode would not receive BFD Control traffic.
</t>
</list>
</t>
<t> <t>OLD TEXT</t>
The 1st and 2nd paragraphs of Section 6.8.9 of <xref target="RFC5880"/> a <blockquote>When a system is said to have "the Echo function active" it
re updated as below: means that the system is sending BFD Echo packets, implying that the
</t> session is Up and the other system has signaled its willingness to loop
back Echo packets.</blockquote>
<t> <t>NEW TEXT</t>
<list> <blockquote>When a system in Asynchronous or Demand mode is said to have
<t> "the Echo function active" it means that the system is sending BFD Echo
OLD TEXT<br/>BFD Echo packets MUST NOT be transmitted when bfd.SessionSta packets, implying that the session is Up and the other system has
te is not signaled its willingness to loop back Echo packets.</blockquote>
Up. BFD Echo packets MUST NOT be transmitted unless the last BFD
Control packet received from the remote system contains a nonzero
value in Required Min Echo RX Interval.
</t>
<t>
NEW TEXT<br/>When a system is using the Echo function with either Asynchr
onous or Demand mode,
BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not
Up, and BFD Echo packets MUST NOT be transmitted unless the last BFD
Control packet received from the remote system contains a nonzero
value in Required Min Echo RX Interval.
</t>
<t>
OLD TEXT<br/>BFD Echo packets MAY be transmitted when bfd.SessionState is
Up. The
interval between transmitted BFD Echo packets MUST NOT be less than
the value advertised by the remote system in Required Min Echo RX
Interval...
</t>
<t>
NEW TEXT<br/>When a system is using the Echo function with either Asynchr
onous or Demand mode,
BFD Echo packets MAY be transmitted when bfd.SessionState is Up, and the
interval between transmitted BFD Echo packets MUST NOT be less than
the value advertised by the remote system in Required Min Echo RX
Interval...
</t>
</list>
</t>
</section> <t>
The 7th paragraph of <xref section="6.8.3" sectionFormat="of" target="RFC
5880"/> is updated as below:
</t>
<section title="Operational Considerations"> <t>OLD TEXT</t>
<blockquote>When the Echo function is active, a system
<bcp14>SHOULD</bcp14> set bfd.RequiredMinRxInterval to a value of not
less than one second (1,000,000 microseconds). This is intended to keep
received BFD Control traffic at a negligible level, since the actual
detection function is being performed using BFD Echo
packets.</blockquote>
<t> <t>NEW TEXT</t>
All Operational Considerations from <xref target="RFC5880"/> apply. Since th <blockquote>When the Echo function is active with Asynchronous mode, a
is mechanism leverages existing BFD machinery, system <bcp14>SHOULD</bcp14> set bfd.RequiredMinRxInterval to a value of
particularly periodic pacing of traffic based on configuration, there's n not less than one second (1,000,000 microseconds). This is intended to
o real possibility to create congestion. Moreover, keep received BFD Control traffic at a negligible level, since the
creating congestion would be counter productive to check the bidirectiona actual detection function is being performed using BFD Echo packets. A
l connectivity. system operating in Demand mode would not receive BFD Control traffic.</bl
ockquote>
<t>
The 1st and 2nd paragraphs of <xref section="6.8.9" sectionFormat="of" ta
rget="RFC5880"/> are updated as below:
</t>
<t>OLD TEXT</t>
<blockquote>
<t>BFD Echo packets <bcp14>MUST NOT</bcp14> be transmitted when
bfd.SessionState is not Up. BFD Echo packets <bcp14>MUST NOT</bcp14> be
transmitted unless the last BFD Control packet received from the remote
system contains a nonzero value in Required Min Echo RX Interval.</t>
<t>BFD Echo packets <bcp14>MAY</bcp14> be transmitted when
bfd.SessionState is Up. The interval between transmitted BFD Echo
packets <bcp14>MUST NOT</bcp14> be less than the value advertised by the
remote system in Required Min Echo RX Interval, except as follows: [...]
</t> </t>
<t> </blockquote>
<t>NEW TEXT</t>
<blockquote>
<t>When a system is using the Echo function with either
Asynchronous or Demand mode, BFD Echo packets <bcp14>MUST NOT</bcp14> be
transmitted when bfd.SessionState is not Up, and BFD Echo packets
<bcp14>MUST NOT</bcp14> be transmitted unless the last BFD Control
packet received from the remote system contains a nonzero value in
Required Min Echo RX Interval.</t>
<t>When a system is using the Echo function with either
Asynchronous or Demand mode, BFD Echo packets <bcp14>MAY</bcp14> be
transmitted when bfd.SessionState is Up, and the interval between
transmitted BFD Echo packets <bcp14>MUST NOT</bcp14> be less than the
value advertised by the remote system in Required Min Echo RX
Interval, except as follows: [...]</t>
</blockquote>
</section>
<section>
<name>Operational Considerations</name>
<t>
All operational considerations from <xref target="RFC5880"/> apply. Since th
is mechanism leverages existing BFD machinery,
particularly periodic pacing of traffic based on configuration, there's n
o real possibility to create congestion.
Moreover, creating congestion would be
counterproductive to checking the bidirectional connectivity.
</t>
<t>
Some devices that would benefit from the use of BFD may be unable to support the full BFD protocol. Examples of such Some devices that would benefit from the use of BFD may be unable to support the full BFD protocol. Examples of such
devices include servers running virtual machines, or Internet of Things ( IoT) devices. By using Unaffiliated BFD devices include servers running virtual machines, or Internet of Things ( IoT) devices. By using Unaffiliated BFD
Echo, these devices only need to support a basic loopback function. Echo, these devices only need to support a basic loopback function.
</t> </t>
<t> <t>
As specified in Section 2 of this document, some configuration is needed to As specified in <xref target="unaffiliated-bfd-echo-procedures"/> of this do
make the Unaffiliated BFD Echo work, cument, some configuration is needed to make the Unaffiliated BFD Echo work,
although the configuration won't go beyond the scope of <xref target="RFC although the configuration won't go beyond the scope of <xref target="RFC
5880"/>. At a BFD-enabled local system, the 5880"/>.
Unaffiliated BFD Echo session can coexist with other type of BFD session, At a BFD-enabled local system, the
in which scenario the remote system for the Unaffiliated BFD Echo session can coexist with other types of BFD session
Unaffiliated BFD Echo session must be different from the remote system fo s. In that scenario, the remote system for the
r other type of BFD session, and the local Unaffiliated BFD Echo session must be different from the remote system fo
system's discriminators for different BFD sessions must be different, at r any other type of BFD session, and the local
the same time it's not necessary for the local system's discriminators for different BFD sessions must be different. At
system to differentiate the Unaffiliated BFD Echo session from other type the same time, it's not necessary for the local
of BFD session. system to differentiate the Unaffiliated BFD Echo session from the other
</t> types of BFD sessions.
</t>
</section> </section>
<section>
<section title="Security Considerations"> <name>Security Considerations</name>
<t>
<t> All security considerations from <xref target="RFC5880"/> and <xref targe
All Security Considerations from <xref target="RFC5880"/> and <xref targe t="RFC5881"/> apply.
t="RFC5881"/> apply. </t>
</t> <t>
<t>
Unaffiliated BFD Echo requires the remote device to loop Unaffiliated BFD Echo packets. In order to provide this Unaffiliated BFD Echo requires the remote device to loop Unaffiliated BFD Echo packets. In order to provide this
service, the remote device cannot make use of Unicast Strict Reverse Path Forwarding (RPF) <xref target="RFC3704"/>, service, the remote device cannot make use of Unicast Strict Reverse Path Forwarding (RPF) <xref target="RFC3704"/>,
otherwise the Unaffiliated BFD Echo packets might not pass the RPF check at the remote device. otherwise the Unaffiliated BFD Echo packets might not pass the RPF check at the remote device.
</t> </t>
<t> <t>
As described in Section 5 of <xref target="RFC5880"/>, BFD Echo packets m As described in <xref section="5" sectionFormat="of" target="RFC5880"/>,
ay be spoofed. Specifically for Unaffiliated BFD Echo packets may be spoofed. Specifically for Unaffiliated
BFD Echo, a DoS attacker may send spoofed Unaffiliated BFD Echo packets t BFD Echo, a DoS attacker may send spoofed Unaffiliated BFD Echo packets t
o the loop-back device, so some form of o the loopback device, so some form of
authentication SHOULD be included. Considering the Unaffiliated BFD Echo authentication <bcp14>SHOULD</bcp14> be included. Considering the Unaffil
packets in this document are also BFD iated BFD Echo packets in this document are also BFD
Control packets, the "Authentication Section" as defined in <xref target= Control packets, the "Authentication Section" as defined in <xref target=
"RFC5880"/> for BFD Control packet is "RFC5880"/> for a BFD Control packet is
RECOMMENDED to be included within the Unaffiliated BFD Echo packet. <bcp14>RECOMMENDED</bcp14> to be included within the Unaffiliated BFD Ech
</t> o packet.
<t> </t>
As stated in Section 2, in order to avoid unset values being a potential <t>
vector for disclosure of uninitialized As stated in <xref target="unaffiliated-bfd-echo-procedures"/>, in order
memory, all fields of the Unaffiliated BFD Echo packet MUST be populated to avoid unset values being a potential vector for disclosure of uninitialized
with a certain value, even if some of the memory, all fields of the Unaffiliated BFD Echo packet <bcp14>MUST</bcp14
> be populated with a certain value, even if some of the
fields are ignored on receipt. fields are ignored on receipt.
</t> </t>
</section>
<section title="IANA Considerations">
<t> This document has no IANA action requested.</t>
</section> </section>
<section>
<section title="Acknowledgements"> <name>IANA Considerations</name>
<t> The authors would like to acknowledge Ketan Talaulikar, Greg Mirsky, San <t> This document has no IANA actions.</t>
tosh Pallagatti, Aijun Wang, Eric Vyncke,
Adrian Farrel, Tim Wicinski, Dhruv Dhody, Stephen Farrell, Gunter Van de
Velde, Gyan Mishra, Brian Trammell, Gorry Fairhurst,
Mahesh Jethanandani, John Scudder, Murray Kucherawy, and Zaheduzzaman Sar
ker for their careful review and very helpful comments.</t>
<t> The authors would like to acknowledge Jeff Haas for his guidance, insigh
tful review, and very helpful comments.</t>
<t> The authors would like to acknowledge Erik Auerswald for his insightful
comments during the discussion of this document.</t>
<t> The authors would like to acknowledge Detao Zhao for the very helpful di
scussion.</t>
</section> </section>
<section title="Contributors"> </middle>
<t>Liu Aihua<br/>ZTE<br/>Email: liu.aihua@zte.com.cn</t> <back>
<t>Qian Xin<br/>ZTE<br/>Email: qian.xin2@zte.com.cn</t>
<t>Zhao Yanhua<br/>ZTE<br/>Email: zhao.yanhua3@zte.com.cn</t>
</section>
</middle> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
880.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
881.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
704.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
082.xml"/>
<back> <reference anchor="BBF-TR-146" target="https://www.broadband-forum.org/p
dfs/tr-146-1-0-0.pdf">
<front>
<title>TR-146: Subscriber Sessions</title>
<author>
<organization>Broadband Forum</organization>
</author>
<date month="May" year="2013"/>
</front>
<refcontent>Broadband Forum Technical Report, TR-146, Issue 1</refconte
nt>
</reference>
<references title="Normative References"> </references>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.8174"?>
<?rfc include="reference.RFC.5880"?>
<?rfc include="reference.RFC.5881"?>
</references> </references>
<references title="Informative References"> <section numbered="false">
<?rfc include="reference.RFC.3704"?> <name>Acknowledgements</name>
<?rfc include="reference.RFC.5082"?>
<reference anchor="BBF-TR-146"
target="https://www.broadband-forum.org/technical/download/TR-1
46.pdf">
<front>
<title>BBF Technical Report - Subscriber Sessions Issue 1</title>
<author> <t> The authors would like to acknowledge <contact fullname="Ketan
<organization>Broadband Forum</organization> Talaulikar"/>, <contact fullname="Greg Mirsky"/>, <contact
</author> fullname="Santosh Pallagatti"/>, <contact fullname="Aijun Wang"/>,
<contact fullname="Éric Vyncke"/>, <contact fullname="Adrian Farrel"/>,
<contact fullname="Tim Wicinski"/>, <contact fullname="Dhruv Dhody"/>,
<contact fullname="Stephen Farrell"/>, <contact fullname="Gunter Van de Ve
lde"/>, <contact fullname="Gyan Mishra"/>, <contact fullname="Brian Trammell"/>,
<contact fullname="Gorry Fairhurst"/>, <contact
fullname="Mahesh Jethanandani"/>, <contact fullname="John Scudder"/>,
<contact fullname="Murray Kucherawy"/>, and <contact
fullname="Zaheduzzaman Sarker"/> for their careful reviews and very
helpful comments.</t>
<t> The authors would like to acknowledge <contact fullname="Jeff Haas"/>
for his guidance, insightful review, and very helpful
comments.</t>
<t> The authors would like to acknowledge <contact fullname="Erik Auerswal
d"/> for his insightful comments during the discussion of this
document.</t>
<t> The authors would like to acknowledge <contact fullname="Detao Zhao"/>
for the very helpful discussion.</t>
</section>
<date year="2013"/> <section numbered="false">
</front> <name>Contributors</name>
</reference> <contact fullname="Liu Aihua">
</references> <organization>ZTE</organization>
<address>
<email>liu.aihua@zte.com.cn</email>
</address>
</contact>
<contact fullname="Qian Xin">
<organization>ZTE</organization>
<address>
<email>qian.xin2@zte.com.cn</email>
</address>
</contact>
<contact fullname="Zhao Yanhua">
<organization>ZTE</organization>
<address>
<email>zhao.yanhua3@zte.com.cn</email>
</address>
</contact>
</section>
</back>
</back>
</rfc> </rfc>
 End of changes. 97 change blocks. 
569 lines changed or deleted 539 lines changed or added

This html diff was produced by rfcdiff 1.48.