<?xml version="1.0"encoding="US-ASCII"?>encoding="UTF-8"?> <!--This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org.updated by Chris 10/29/20 --> <!DOCTYPE rfc SYSTEM"rfc2629.dtd"> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!-- used by XSLT processors --> <!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. --> <!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use. (Here they are set differently than their defaults in xml2rfc v1.32) --> <?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="4"?> <!-- 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 list of popular I-D processing instructions -->"rfc2629-xhtml.ent"> <rfccategory="info"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-bfd-vxlan-16"ipr="trust200902"> <!-- category values: std, bcp, info, exp, and historic ipr values: full3667, noModification3667, noDerivatives3667 you can add the attributes updates="NNNN" and obsoletes="NNNN" they will automatically be output with "(if approved)" -->number="8971" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="info" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <!--***** FRONT MATTER *****xml2rfc v2v3 conversion 3.3.0 --> <front> <title abbrev="BFD for VXLAN">BFDBidirectional Forwarding Detection (BFD) forVXLANVirtual eXtensible Local Area Network (VXLAN) </title><!-- add 'role="editor"' below for the editors if appropriate --> <!-- Another author who claims to be an editor --><seriesInfo name="RFC" value="8971"/> <author fullname="Santosh Pallagatti" role="editor" initials="S." surname="Pallagatti"> <organization>VMware</organization> <address> <email>santosh.pallagatti@gmail.com</email> </address> </author> <author fullname="Greg Mirsky" role="editor" initials="G." surname="Mirsky"> <organization>ZTE Corp.</organization> <address> <email>gregimirsky@gmail.com</email> </address> </author><!-- <author fullname="Basil Saji" initials="B." surname="Saji"> <organization>Juniper Networks</organization> <address> <postal> <street>Embassy Business Park</street> <city>Bangalore</city> <region>KA</region> <code>560093</code> <country>India</country> </postal> <email>sbasil@juniper.net</email> </address> </author> --><author fullname="Sudarsan Paragiri " initials="S." surname="Paragiri"> <organization>Individual Contributor</organization> <address> <email>sudarsan.225@gmail.com</email> </address> </author> <author fullname="Vengada Prasad Govindan" initials="V." surname="Govindan"> <organization>Cisco</organization> <address> <email>venggovi@cisco.com</email> </address> </author> <author fullname="Mallik Mudigonda" initials="M." surname="Mudigonda"> <organization>Cisco</organization> <address> <email>mmudigon@cisco.com</email> </address> </author> <dateyear="2020"/>year="2020" month="December" /> <area>Routing</area> <workgroup>BFD</workgroup><!-- WG name at the upperleft corner of the doc, IETF is fine for individual submissions. If this element is not present, the default is "Network Working Group", which is used by the RFC Editor as a nod to the history of the IETF. --><keyword>BFD</keyword> <keyword>BFD for VXLAN</keyword><!-- Keywords will be incorporated into HTML output files in a meta tag but they have no effect on text or nroff output. If you submit your draft to the RFC Editor, the keywords will be used for the search engine. --><abstract> <t>This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Virtual eXtensible Local Area Network (VXLAN) tunnels used to form an overlay network.</t> </abstract> </front> <middle> <sectiontitle="Introduction" anchor="Intro">anchor="Intro" numbered="true" toc="default"> <name>Introduction</name> <t> "Virtual eXtensible Local AreaNetwork" (VXLAN)Network (VXLAN)" <xreftarget="RFC7348"/>target="RFC7348" format="default"/> provides an encapsulation scheme that allows the building of an overlay network by decoupling the address space of the attached virtual hosts from that of the network. </t> <t> One use of VXLAN is in data centers interconnecting virtual machines (VMs) of a tenant. VXLAN addresses the requirements of the Layer 2 and Layer 3data centerdata-center network infrastructure in the presence of VMs in a multi-tenant environment by providing a Layer 2 overlay scheme on a Layer 3 network <xreftarget="RFC7348"/>.target="RFC7348" format="default"/>. Another use is as an encapsulation for Ethernet VPN <xreftarget="RFC8365"/>.target="RFC8365" format="default"/>. </t> <t> This document is written assuming the use of VXLAN for virtualized hosts and refers to VMs and VXLAN Tunnel End Points (VTEPs) in hypervisors. However, the concepts are equally applicable to non-virtualized hosts attached to VTEPs in switches. </t> <t>In the absence of a router in the overlay, a VM can communicate with another VM only if they are on the same VXLAN segment. VMs are unaware of VXLANtunnels astunnels, because a VXLAN tunnel is terminated on a VTEP. VTEPs are responsible for encapsulating and decapsulating frames exchanged among VMs. </t> <t> The ability to monitor pathcontinuity,continuity -- i.e., perform proactive continuity check (CC) for point-to-point (p2p) VXLANtunnels,tunnels -- is important. The asynchronous mode of BFD, as defined in <xreftarget="RFC5880"/>,target="RFC5880" format="default"/>, is used to monitor a p2p VXLAN tunnel. </t> <t> In the case where a Multicast Service Node (MSN) (as described inSection 3.3 of<xreftarget="RFC8293"/>)target="RFC8293" sectionFormat="of" section="3.3"/>) participates in VXLAN, the mechanisms described in this document apply and can, therefore, be used to test the continuity of the path between the sourceNVENetwork Virtualization Endpoint (NVE) and the MSN. </t> <t> This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol to enable monitoring continuity of the path between VXLAN VTEPs that are performing asNetwork Virtualization Endpoints,VNEs, and/or between the source NVE and a replicator MSN using a ManagementVNIVXLAN Network Identifier (VNI) (<xreftarget="management-vni-sec"/>).target="management-vni-sec" format="default"/>). All other uses of the specification to test toward other VXLAN endpoints are out ofthescope. </t> </section> <sectiontitle="Conventionsnumbered="true" toc="default"> <name>Conventions Used inthis Document">This Document</name> <sectiontitle="Acronyms"> <t>BFD Bidirectionalnumbered="true" toc="default"> <name>Abbreviations</name> <dl indent="9"> <dt>BFD:</dt><dd>Bidirectional ForwardingDetection </t> <t>CC Continuity Check</t> <!--<t>GTSM Generalized TTL Security Mechanism</t>--> <t>p2p Point-to-point</t> <t>MSN MulticastDetection</dd> <dt>CC:</dt><dd>Continuity Check</dd> <dt>FCS:</dt><dd>Frame Check Sequence</dd> <dt>MSN:</dt><dd>Multicast ServiceNode</t> <t>NVE NetworkNode</dd> <dt>NVE:</dt><dd>Network VirtualizationEndpoint</t> <t>VFI VirtualEndpoint</dd> <dt>p2p:</dt><dd>Point-to-point</dd> <dt>VFI:</dt><dd>Virtual ForwardingInstance</t> <t>VM Virtual Machine</t> <t>VNI VXLANInstance</dd> <dt>VM:</dt><dd>Virtual Machine</dd> <dt>VNI:</dt><dd>VXLAN Network Identifier (or VXLAN SegmentID)</t> <t>VTEP VXLANID)</dd> <dt>VTEP:</dt><dd>VXLAN Tunnel EndPoint</t> <t>VXLAN VirtualPoint</dd> <dt>VXLAN:</dt><dd>Virtual eXtensible Local AreaNetwork</t>Network</dd> </dl> </section> <sectiontitle="Requirements Language">numbered="true" toc="default"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> </section> <sectiontitle="Deployment">numbered="true" toc="default"> <name>Deployment</name> <t> <xreftarget="ref-vxlan-fig"/>target="ref-vxlan-fig" format="default"/> illustratesthea scenario with twoservers,servers: eachof themhosting two VMs. The servers host VTEPs that terminate two VXLAN tunnels withVXLAN Network Identifier (VNI)VNI number 100 and200200, respectively. Separate BFD sessions can be established between the VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100 and 200). Using a BFD session to monitor a set of VXLAN VNIs between the same pair of VTEPs might help to detect and localize problems caused by misconfiguration. An implementation that supports this specificationMUST<bcp14>MUST</bcp14> be able to control the number of BFD sessions that can be created between the same pair of VTEPs. This method is applicable whether the VTEP is a virtual or physical device. </t> <t keepWithNext="true"/> <figureanchor="ref-vxlan-fig" align="left" title="Referenceanchor="ref-vxlan-fig"> <name>Reference VXLANDomain"> <preamble/>Domain</name> <artworkalign="left"> <![CDATA[align="left" name="" type="" alt=""><![CDATA[ +------------+-------------+ | Server 1 | | +----+----+ +----+----+ | | |VM1-1 | |VM1-2 | | | |VNI 100 | |VNI 200 | | | | | | | | | +---------+ +---------+ | | VTEP (IP1) | +--------------------------+ | | +-------------+ | | Layer 3 | +---| Network | +-------------+ | +-----------+ | +------------+-------------+ | VTEP (IP2) | | +----+----+ +----+----+ | | |VM2-1 | |VM2-2 | | | |VNI 100 | |VNI 200 | | | | | | | | | +---------+ +---------+ | | Server 2 | +--------------------------+]]> </artwork>]]></artwork> </figure> <t> At the same time, aservice layerservice-layer BFD session may be used between the tenants of VTEPs IP1 and IP2 to provide end-to-end faultmanagement (thismanagement; this use case is outside the scope of thisdocument).document. In such a case, for VTEPs, the BFD Control packets of that session are indistinguishable from data packets. </t> <t> For BFD Control packets encapsulated in VXLAN (<xreftarget="vxlan-bfd-encap-fig"/>),target="vxlan-bfd-encap-fig" format="default"/>), the inner destination IP addressSHOULD<bcp14>SHOULD</bcp14> be set to one of the loopback addresses from 127/8 range for IPv4 or to one of IPv4-mapped IPv6 loopback addresses from ::ffff:127.0.0.0/104 range for IPv6. </t> </section> <section anchor="management-vni-sec"title="Usenumbered="true" toc="default"> <name>Use of the ManagementVNI">VNI</name> <t> In most cases, a single BFD session is sufficient for the given VTEP to monitor the reachability of a remote VTEP, regardless of the number of VNIs. BFD control messagesMUST<bcp14>MUST</bcp14> be sent using the ManagementVNIVNI, which acts as theascontrol and management channel between VTEPs. An implementationMAY<bcp14>MAY</bcp14> support operating BFD on another (non-Management)VNIVNI, although the implications of this are outside the scope of this document. The selection of the VNI number of the Management VNIMUST<bcp14>MUST</bcp14> be controlled through a management plane. An implementationMAY<bcp14>MAY</bcp14> use VNI number 1 as the default value for the Management VNI. All VXLAN packets received on the Management VNIMUST<bcp14>MUST</bcp14> be processed locally andMUST NOT<bcp14>MUST NOT</bcp14> be forwarded to a tenant. </t> </section> <section anchor="bfd-transmit-vxlan-sec"title="BFDnumbered="true" toc="default"> <name>BFD Packet Transmission over VXLANTunnel">Tunnel</name> <t> BFD packetsMUST<bcp14>MUST</bcp14> be encapsulated and sent to a remote VTEP as explained in this section. ImplementationsSHOULD<bcp14>SHOULD</bcp14> ensure that the BFD packets follow the same forwarding path as VXLAN data packets within the sender system. </t><!-- <section title="BFD Packet Encapsulation in VXLAN" anchor="encap"> --><t> BFD packets are encapsulated in VXLAN as described below. The VXLAN packet format is defined inSection 5 of<xreftarget="RFC7348"/>.target="RFC7348" sectionFormat="of" section="5"/>. The value in the VNI field of the VXLAN headerMUST<bcp14>MUST</bcp14> be set to the value selected as the Management VNI. TheOuterouter IP/UDP and VXLAN headersMUST<bcp14>MUST</bcp14> be encoded by thesendersender, as defined in <xreftarget="RFC7348"/>.</t> <t>target="RFC7348" format="default"/>.</t> <figurealign="left" anchor="vxlan-bfd-encap-fig" title="VXLANanchor="vxlan-bfd-encap-fig"> <name>VXLAN Encapsulation of BFD ControlPacket"> <artwork><![CDATA[Packet</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Outer Ethernet Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Outer IPvX Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Outer UDP Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ VXLAN Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Inner Ethernet Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Inner IPvX Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Inner UDP Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ BFD Control Packet ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Ethernet FCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure></t><t> The BFD packetMUST<bcp14>MUST</bcp14> be carried inside the inner Ethernet frame of the VXLAN packet. The choice ofDestination MACdestination Media Access Control (MAC) andDestinationdestination IP addresses for the inner Ethernet frameMUST<bcp14>MUST</bcp14> ensure that the BFD Control packet is not forwarded to a tenant but is processed locally at the remote VTEP. The inner Ethernet frame carrying the BFD Controlpacket-packet has the following format:<list> <t> Ethernet Header: <list style="hanging"> <t>Destination MAC: A</t> <dl newline="true"> <dt>Ethernet Header:</dt> <dd> <dl newline="false" spacing="normal"> <dt>Destination MAC:</dt><dd>A Management VNI, which does not have any tenants, will have no dedicated MAC address for decapsulatedtraffic. traffic. The value(TBD1) SHOULD00-52-02 <bcp14>SHOULD</bcp14> be used in thisfield.</t> <t>Source MAC: MACfield.</dd> <dt>Source MAC:</dt><dd>MAC address associated with the originatingVTEP.</t> <t>Ethertype:VTEP.</dd> <dt>Ethertype:</dt><dd>This is set to 0x0800 if the inner IP header isIPv4,IPv4 andisset to 0x86DD if the inner IP header isIPv6.</t> </list> </t> <t>IP header: <list style="hanging"> <t>Destination IP:IPv6.</dd> </dl> </dd> <dt>IP header:</dt> <dd> <dl newline="false" spacing="normal"> <dt>Destination IP:</dt><dd>This IP addressMUST NOT<bcp14>MUST NOT</bcp14> be of one of tenant's IP addresses. The IP addressSHOULD<bcp14>SHOULD</bcp14> be selected from the range 127/8 forIPv4, for IPv6 -IPv4 and from the range::ffff:127.0.0.0/104.::ffff:127.0.0.0/104 for IPv6. Alternatively, the destination IP addressMAY<bcp14>MAY</bcp14> be set to VTEP's IPaddress.</t> <t>Source IP: IPaddress.</dd> <dt>Source IP:</dt><dd>IP address of the originatingVTEP.</t> <t>TTLVTEP.</dd> <dt>TTL or HopLimit: MUSTLimit:</dt><dd><bcp14>MUST</bcp14> be set to255255, in accordance with <xreftarget="RFC5881"/>. </t> <!-- <t>[Ed.Note]:Use of inner source and destination IP addresses needs more discussion by the WG.</t> --> </list> </t>target="RFC5881" format="default"/>.</dd> </dl> </dd> </dl> <t> Thefields of thedestination UDPheaderport is set to 3784 and the fields of the BFD Control packet are encoded as specified in <xreftarget="RFC5881"/>. </t> </list></t> <!--target="RFC5881" format="default"/>.</t> </section>--> <!--<sectiontitle="BFD Packet Encapsulation in VXLAN-GPE" anchor="encap-gpe"> <t> If VTEP suppors Generic Protocol Extension (GPE) header capabilities then VXLAN-GPE MAY be used. The VXLAN-GPE header MUST be encoded as per Section 3.3 of <xref target="I-D.ietf-nvo3-vxlan-gpe"/>. Next Protocol Field in VXLAN-GPE header MAY be set to indicate IPv4or IPv6 payload. Then BFD control packet MUST be encapsulated using IP/UDP format per <xref target="RFC5881"/>. Next Protocol Field in VXLAN-GPE header MAY be set to indicate that payload is OAM packet. Then OOAM Common Header <xref target="I-D.ooamdt-rtgwg-ooam-header"/> immediately follows the VXLAN-GPE header and defines encapsulation of the BFD control packet. Theencapsulation MAY use IP/UDP form or PW-ACH encapsulation <xref target="RFC5885"/>.</t> <t>Details of how the VTEP is instructed to choose VXLAN or GPE header are outside the scope of this document.</t> </section> --> </section> <section title="Receptionnumbered="true" toc="default"> <name>Reception of BFD Packet from VXLANTunnel">Tunnel</name> <t> Once a packet is received, the VTEPMUST<bcp14>MUST</bcp14> validate the packet. If the packet is received on themanagementManagement VNI and is identified as a BFDcontrolControl packet addressed to the VTEP,andthen the packet can be processed further. Processing of BFDcontrolControl packets received onnon-managementa non-Management VNI is outside the scope of this specification. </t> <t> The received packet's inner IP payload is then validated according to Sections4 and 5 in<xreftarget="RFC5881"/>. </t> <!-- <t> To ensure that the BFD session monitors the intended VXLAN Network Identifier (VNI) in a remote VTEP, a lookup SHOULD be performed with the MAC-DAtarget="RFC5881" sectionFormat="bare" section="4" /> andVNI as key in the Virtual Forwarding Instance (VFI) table of the originating/terminating VTEP to exercise the VFI associated with the VNI.</t> --> <!-- <section title="Demultiplexing of the BFD Packet"> <t>Demultiplexing of IP BFD packet has been defined<xref target="RFC5881" sectionFormat="bare" section="5"/> inSection 3 of<xreftarget="RFC5881"/>. Since multiple BFD sessions may be running between two VTEPs, there needs to be a mechanism for demultiplexing received BFD packets to the proper session. For demultiplexing packets with Your Discriminator equal to 0, a BFD session MUST be identified using the logical link over which the BFD Control packet is received. In the case of VXLAN, the VNI number identifies that logical link. If BFD packet is received with non-zero Your Discriminator, then the BFD session MUST be demultiplexed only with Your Discriminator as the key.</t> </section> --> </section> <!-- <section title="Reception of BFD packet from VXLAN-GPE Tunnel"> <t>TBD</t> <section title="Demultiplexing of the BFD packet"> <t>TBD</t> </section>target="RFC5881" format="default"/>. </t> </section>--><sectiontitle="Echo BFD">numbered="true" toc="default"> <name>Echo BFD</name> <t>Support for echo BFD is outside the scope of this document.</t> </section> <section anchor="iana-consideration"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t> IANAis requested to assignhas assigned a single MAC addresstoof the valueTBD100-52-02 from the "Unassigned (small allocations)" block of the "IANA Unicast 48-bit MACAddress"Addresses" registryfromas follows: the"Unassigned (small allocations)" block. The Usage"Usage" fieldwill beis "BFD forVXLAN" with a Reference field ofVXLAN". The "Reference" is this document. </t> </section> <sectiontitle="Security Considerations"> <!-- <t> The document requires setting the inner IP TTL or Hop Limit to 1, which could be used as a DDoS attack vector. Thus the implementation MUST have throttling in place to control the rate of BFD Control packets sent to the control plane. On the other hand, over-aggressive throttling of BFD Control packets may become the cause of the inability to form and maintain BFD session at scale. Hence, throttling of BFD Control packets SHOULD be adjusted to permit BFD to work according to its procedures. </t> -->numbered="true" toc="default"> <name>Security Considerations</name> <t> Security issues discussed in <xreftarget="RFC5880"/>,target="RFC5880" format="default"/>, <xreftarget="RFC5881"/>,target="RFC5881" format="default"/>, and <xreftarget="RFC7348"/>target="RFC7348" format="default"/> apply to this document. </t> <t> This document recommends using an address from theInternalinternal host loopback addresses 127/8 range forIPv4IPv4, or an IP4-mapped IPv6 loopback address from the ::ffff:127.0.0.0/104 range forIPv6IPv6, as the destination IP address in the inner IP header. Using such an address prevents the forwarding of the encapsulated BFD control message by a transientnodenode, in case the VXLAN tunnel isbroken as according tobroken, in accordance with <xreftarget="RFC1812"/>. <list>target="RFC1812" format="default"/>. </t> <aside> <t> A routerSHOULD NOT<bcp14>SHOULD NOT</bcp14> forward, except over a loopback interface, any packet that has a destination address on network 127. A routerMAY<bcp14>MAY</bcp14> have a switch that allows the network manager to disable these checks. If such a switch is provided, itMUST<bcp14>MUST</bcp14> default to performing thechecks. </t> </list>checks.</t> </aside> <t> The use of IPv4-mapped IPv6 addresses has the same property as using the IPv4 network127/8, moreover,127/8. Moreover, the IPv4-mapped IPv6addressesaddresses' prefix is not advertised in any routing protocol.</t> <t> If the implementation supports establishing multiple BFD sessions between the same pair of VTEPs, thereSHOULD<bcp14>SHOULD</bcp14> be a mechanism to control the maximum number of such sessions that can be active at the same time. </t> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5881.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1812.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8293.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8365.xml"/> </references> </references> <sectiontitle="Contributors"> <t> <figure> <artwork> <![CDATA[ Reshad Rahman rrahman@cisco.com Cisco ]]> </artwork> </figure> </t> </section> <section title="Acknowledgments"> <t>Authorsnumbered="false" toc="default"> <name>Acknowledgments</name> <t>The authors would like to thankJeff Haas<contact fullname="Jeff Haas"/> of Juniper Networks for his reviews and feedback on this material.</t><t>Authors<t>The authors would also like to thankNobo Akiya, Marc Binderberger, Shahram Davari, Donald<contact fullname="Nobo Akiya"/>, <contact fullname="Marc Binderberger"/>, <contact fullname="Shahram Davari"/>, <contact fullname="Donald E. Eastlake3rd, Anoop Ghanwani, Dinesh Dutt, Joel Halpern, and Carlos Pignataro3rd"/>, <contact fullname="Anoop Ghanwani"/>, <contact fullname="Dinesh Dutt"/>, <contact fullname="Joel Halpern"/>, and <contact fullname="Carlos Pignataro"/> for the extensive reviews and the most detailed and constructive comments.</t> </section></middle> <!-- *****BACK MATTER ***** --> <back> <!-- References split into informative and normative --> <references title="Normative References"> <?rfc include="reference.RFC.5880"?> <?rfc include="reference.RFC.5881"?> <?rfc include="reference.RFC.7348"?> <?rfc include="reference.RFC.2119"?> <?rfc include="reference.RFC.8174"?> <?rfc include="reference.RFC.1812"?> <!-- <?rfc include="reference.RFC.5082"?> --> <!-- <?rfc include="reference.I-D.ietf-bfd-seamless-base"?> --> <!-- <?rfc include="reference.I-D.ashwood-nvo3-operational-requirement"?> --> <!-- <?rfc include="reference.I-D.ietf-nvo3-vxlan-gpe"?> --> <!-- <?rfc include="reference.I-D.ietf-bfd-multipoint"?> --> <!-- <?rfc include="reference.I-D.ooamdt-rtgwg-ooam-header"?> --> </references> <references title="Informational References"> <?rfc include="reference.RFC.8293"?> <?rfc include="reference.RFC.8365"?> </references><section numbered="false" toc="default"> <name>Contributors</name> <contact fullname="Reshad Rahman"> <organization>Cisco</organization> <address> <email>rrahman@cisco.com</email> </address> </contact> </section> </back> </rfc>