< draft-ietf-bfd-vxlan-09.txt | draft-ietf-bfd-vxlan-10.txt > | |||
---|---|---|---|---|
BFD S. Pallagatti, Ed. | BFD S. Pallagatti, Ed. | |||
Internet-Draft VMware | Internet-Draft VMware | |||
Intended status: Standards Track S. Paragiri | Intended status: Standards Track S. Paragiri | |||
Expires: June 1, 2020 Individual Contributor | Expires: June 27, 2020 Individual Contributor | |||
V. Govindan | V. Govindan | |||
M. Mudigonda | M. Mudigonda | |||
Cisco | Cisco | |||
G. Mirsky | G. Mirsky | |||
ZTE Corp. | ZTE Corp. | |||
November 29, 2019 | December 25, 2019 | |||
BFD for VXLAN | BFD for VXLAN | |||
draft-ietf-bfd-vxlan-09 | draft-ietf-bfd-vxlan-10 | |||
Abstract | Abstract | |||
This document describes the use of the Bidirectional Forwarding | This document describes the use of the Bidirectional Forwarding | |||
Detection (BFD) protocol in point-to-point Virtual eXtensible Local | Detection (BFD) protocol in point-to-point Virtual eXtensible Local | |||
Area Network (VXLAN) tunnels forming up an overlay network. | Area Network (VXLAN) tunnels used to form an overlay network. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on June 1, 2020. | This Internet-Draft will expire on June 27, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 16 ¶ | skipping to change at page 2, line 16 ¶ | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Conventions used in this document . . . . . . . . . . . . . . 3 | 2. Conventions used in this document . . . . . . . . . . . . . . 3 | |||
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. BFD Packet Transmission over VXLAN Tunnel . . . . . . . . . . 5 | 4. BFD Packet Transmission over VXLAN Tunnel . . . . . . . . . . 6 | |||
5. Reception of BFD Packet from VXLAN Tunnel . . . . . . . . . . 7 | 5. Reception of BFD Packet from VXLAN Tunnel . . . . . . . . . . 8 | |||
5.1. Demultiplexing of the BFD Packet . . . . . . . . . . . . 8 | 5.1. Demultiplexing of the BFD Packet . . . . . . . . . . . . 9 | |||
6. Use of the Specific VNI . . . . . . . . . . . . . . . . . . . 8 | 6. Use of the Specific VNI . . . . . . . . . . . . . . . . . . . 9 | |||
7. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 7. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 | 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 9 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 | |||
12.2. Informational References . . . . . . . . . . . . . . . . 10 | 12.2. Informational References . . . . . . . . . . . . . . . . 11 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
1. Introduction | 1. Introduction | |||
"Virtual eXtensible Local Area Network" (VXLAN) [RFC7348] provides an | "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348] provides an | |||
encapsulation scheme that allows building an overlay network by | encapsulation scheme that allows building an overlay network by | |||
decoupling the address space of the attached virtual hosts from that | decoupling the address space of the attached virtual hosts from that | |||
of the network. | of the network. | |||
One use of VXLAN is in data centers interconnecting virtual machines | One use of VXLAN is in data centers interconnecting virtual machines | |||
(VMs) of a tenant. VXLAN addresses requirements of the Layer 2 and | (VMs) of a tenant. VXLAN addresses requirements of the Layer 2 and | |||
skipping to change at page 3, line 8 ¶ | skipping to change at page 3, line 8 ¶ | |||
hypervisors. However, the concepts are equally applicable to non- | hypervisors. However, the concepts are equally applicable to non- | |||
virtualized hosts attached to VTEPs in switches. | virtualized hosts attached to VTEPs in switches. | |||
In the absence of a router in the overlay, a VM can communicate with | 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 | another VM only if they are on the same VXLAN segment. VMs are | |||
unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a VTEP. | unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a VTEP. | |||
VTEPs are responsible for encapsulating and decapsulating frames | VTEPs are responsible for encapsulating and decapsulating frames | |||
exchanged among VMs. | exchanged among VMs. | |||
Ability to monitor path continuity, i.e., perform proactive | The ability to monitor path continuity, i.e., perform proactive | |||
continuity check (CC) for point-to-point (p2p) VXLAN tunnels, is | continuity check (CC) for point-to-point (p2p) VXLAN tunnels, is | |||
important. The asynchronous mode of BFD, as defined in [RFC5880], is | important. The asynchronous mode of BFD, as defined in [RFC5880], is | |||
used to monitor a p2p VXLAN tunnel. | used to monitor a p2p VXLAN tunnel. | |||
In the case where a Multicast Service Node (MSN) (as described in | In the case where a Multicast Service Node (MSN) (as described in | |||
Section 3.3 of [RFC8293]) resides behind a Network Virtualization | Section 3.3 of [RFC8293]) resides behind a Network Virtualization | |||
Endpoint (NVE), the mechanisms described in this document apply and | Endpoint (NVE), the mechanisms described in this document apply and | |||
can, therefore, be used to test the connectivity from the source NVE | can, therefore, be used to test the connectivity from the source NVE | |||
to the MSN. | to the MSN. | |||
skipping to change at page 4, line 14 ¶ | skipping to change at page 4, line 14 ¶ | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
3. Deployment | 3. Deployment | |||
Figure 1 illustrates the scenario with two servers, each of them | Figure 1 illustrates the scenario with two servers, each of them | |||
hosting two VMs. The servers host VTEPs that terminate two VXLAN | hosting two VMs. The servers host VTEPs that terminate two VXLAN | |||
tunnels with VXLAN Network Identifier (VNI) number 100 and 200 | tunnels with VXLAN Network Identifier (VNI) number 100 and 200 | |||
respectively. Separate BFD sessions can be established between the | respectively. Separate BFD sessions can be established between the | |||
VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100 | VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100 | |||
and 200). An implementation that supports this specification MUST be | and 200). Using a BFD session to monitor a set of VXLAN VNIs between | |||
able to control the number of BFD sessions that can be created | the same pair of VTEPs might help to detect and localize problems | |||
between the same pair of VTEPs. BFD packets intended for a VTEP MUST | caused by misconfiguration. An implementation that supports this | |||
NOT be forwarded to a VM as a VM may drop BFD packets leading to a | specification MUST be able to control the number of BFD sessions that | |||
false negative. This method is applicable whether the VTEP is a | can be created between the same pair of VTEPs. BFD packets intended | |||
virtual or physical device. | for a VTEP MUST NOT be forwarded to a VM, as a VM may drop BFD | |||
packets, leading to a false negative. This method is applicable | ||||
whether the VTEP is a virtual or physical device. | ||||
+------------+-------------+ | +------------+-------------+ | |||
| Server 1 | | | Server 1 | | |||
| +----+----+ +----+----+ | | | +----+----+ +----+----+ | | |||
| |VM1-1 | |VM1-2 | | | | |VM1-1 | |VM1-2 | | | |||
| |VNI 100 | |VNI 200 | | | | |VNI 100 | |VNI 200 | | | |||
| | | | | | | | | | | | | | |||
| +---------+ +---------+ | | | +---------+ +---------+ | | |||
| VTEP (IP1) | | | VTEP (IP1) | | |||
+--------------------------+ | +--------------------------+ | |||
skipping to change at page 5, line 6 ¶ | skipping to change at page 5, line 35 ¶ | |||
| |VM2-1 | |VM2-2 | | | | |VM2-1 | |VM2-2 | | | |||
| |VNI 100 | |VNI 200 | | | | |VNI 100 | |VNI 200 | | | |||
| | | | | | | | | | | | | | |||
| +---------+ +---------+ | | | +---------+ +---------+ | | |||
| Server 2 | | | Server 2 | | |||
+--------------------------+ | +--------------------------+ | |||
Figure 1: Reference VXLAN Domain | Figure 1: Reference VXLAN Domain | |||
At the same time, a service layer BFD session may be used between the | At the same time, a service layer BFD session may be used between the | |||
tenants of VTEPs IP1 and IP2 to provide end-to-end fault management. | tenants of VTEPs IP1 and IP2 to provide end-to-end fault management | |||
In such case, for VTEPs BFD Control packets of that session are | (this use case is outside the scope of this document). In such case, | |||
indistinguishable from data packets. | for VTEPs BFD Control packets of that session are indistinguishable | |||
from data packets. | ||||
As per Section 4, the inner destination IP address SHOULD be set to | For BFD Control packets encapsulated in VXLAN (Figure 2), the inner | |||
one of the loopback addresses (127/8 range for IPv4 and | destination IP address SHOULD be set to one of the loopback addresses | |||
0:0:0:0:0:FFFF:7F00:0/104 range for IPv6). There could be a firewall | from 127/8 range for IPv4 or to one of IPv4-mapped IPv4 loopback | |||
configured on VTEP to block loopback addresses if set as the | addresses from ::ffff:127.0.0.0/104 range for IPv6. There could be a | |||
firewall configured on VTEP to block loopback addresses if set as the | ||||
destination IP in the inner IP header. It is RECOMMENDED to allow | destination IP in the inner IP header. It is RECOMMENDED to allow | |||
addresses from the loopback range through a firewall only if it is | addresses from the loopback range through a firewall only if they are | |||
used as the destination IP address in the inner IP header, and the | used as the destination IP addresses in the inner IP header and the | |||
destination UDP port is set to 3784 [RFC5881]. | destination UDP port is set to 3784 [RFC5881]. | |||
4. BFD Packet Transmission over VXLAN Tunnel | 4. BFD Packet Transmission over VXLAN Tunnel | |||
BFD packet MUST be encapsulated and sent to a remote VTEP as | BFD packets MUST be encapsulated and sent to a remote VTEPs as | |||
explained in this section. Implementations SHOULD ensure that the | explained in this section. Implementations SHOULD ensure that the | |||
BFD packets follow the same lookup path as VXLAN data packets within | BFD packets follow the same forwarding path as VXLAN data packets | |||
the sender system. | within the sender system. | |||
BFD packets are encapsulated in VXLAN as described below. The VXLAN | BFD packets are encapsulated in VXLAN as described below. The VXLAN | |||
packet format is defined in Section 5 of [RFC7348]. The Outer IP/UDP | packet format is defined in Section 5 of [RFC7348]. The Outer IP/UDP | |||
and VXLAN headers MUST be encoded by the sender as defined in | and VXLAN headers MUST be encoded by the sender as defined in | |||
[RFC7348]. | [RFC7348]. | |||
0 1 2 3 | 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 | 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
skipping to change at page 6, line 40 ¶ | skipping to change at page 7, line 40 ¶ | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
~ Inner UDP Header ~ | ~ Inner UDP Header ~ | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
~ BFD Control Packet ~ | ~ BFD Control Packet ~ | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| FCS | | | Outer FCS | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2: VXLAN Encapsulation of BFD Control Packet | Figure 2: VXLAN Encapsulation of BFD Control Packet | |||
The BFD packet MUST be carried inside the inner Ethernet frame of the | The BFD packet MUST be carried inside the inner Ethernet frame of the | |||
VXLAN packet. The choice of Destination MAC and Destination IP | VXLAN packet. The choice of Destination MAC and Destination IP | |||
addresses for the inner Ethernet frame MUST ensure that the BFD | addresses for the inner Ethernet frame MUST ensure that the BFD | |||
Control packet is not forwarded to a tenant but is processed locally | Control packet is not forwarded to a tenant but is processed locally | |||
at the remote VTEP. The inner Ethernet frame carrying the BFD | at the remote VTEP. The inner Ethernet frame carrying the BFD | |||
Control packet- has the following format: | Control packet- has the following format: | |||
Ethernet Header: | Ethernet Header: | |||
Destination MAC: This MUST NOT be of one of tenant's MAC | Destination MAC: This MUST NOT be of one of tenant's MAC | |||
addresses. The destination MAC address MAY be the address | addresses. The destination MAC address MAY be the address | |||
associated with the destination VTEP. The MAC address MAY be | associated with the destination VTEP. The MAC address may be | |||
configured, or it MAY be learned via a control plane protocol. | either configured or learned via a control plane protocol. The | |||
The details of how the MAC address is obtained are outside the | details of how the MAC address is obtained are outside the | |||
scope of this document. | scope of this document. | |||
Source MAC: MAC address associated with the originating VTEP | Source MAC: MAC address associated with the originating VTEP | |||
IP header: | IP header: | |||
Destination IP: IP address MUST NOT be of one of tenant's IP | Destination IP: IP address MUST NOT be of one of tenant's IP | |||
addresses. The IP address SHOULD be selected from the range | addresses. The IP address SHOULD be selected from the range | |||
127/8 for IPv4, for IPv6 - from the range | 127/8 for IPv4, for IPv6 - from the range ::ffff:127.0.0.0/104. | |||
0:0:0:0:0:FFFF:7F00:0/104. Alternatively, the destination IP | Alternatively, the destination IP address MAY be set to VTEP's | |||
address MAY be set to VTEP's IP address. | IP address. | |||
Source IP: IP address of the originating VTEP. | Source IP: IP address of the originating VTEP. | |||
TTL or Hop Limit: MUST be set to 1 to ensure that the BFD | TTL or Hop Limit: MUST be set to 1 to ensure that the BFD | |||
packet is not routed within the Layer 3 underlay network. This | packet is not routed within the Layer 3 underlay network. This | |||
addresses the scenario when the inner IP destination address is | addresses the scenario when the inner IP destination address is | |||
of VXLAN gateway and there is a router in underlay which | of the VXLAN gateway and there is a router in the underlay | |||
removes the VXLAN header, then it is possible to route the | which removes the VXLAN header, then it is possible to route | |||
packet as VXLAN gateway address is routable address. | the packet as VXLAN gateway address is routable address. | |||
The fields of the UDP header and the BFD Control packet are | The fields of the UDP header and the BFD Control packet are | |||
encoded as specified in [RFC5881]. | encoded as specified in [RFC5881]. | |||
5. Reception of BFD Packet from VXLAN Tunnel | 5. Reception of BFD Packet from VXLAN Tunnel | |||
Once a packet is received, VTEP MUST validate the packet. If the | Once a packet is received, the VTEP MUST validate the packet. If the | |||
Destination MAC of the inner Ethernet frame matches one of the MAC | Destination MAC of the inner Ethernet frame matches one of the MAC | |||
addresses associated with the VTEP the packet MUST be processed | addresses associated with the VTEP the packet MUST be processed | |||
further. If the Destination MAC of the inner Ethernet frame doesn't | further. If the Destination MAC of the inner Ethernet frame doesn't | |||
match any of VTEP's MAC addresses, then the processing of the | match any of VTEP's MAC addresses, then the processing of the | |||
received VXLAN packet MUST follow the procedures described in | received VXLAN packet MUST follow the procedures described in | |||
Section 4.1 [RFC7348]. If the BFD session is using the Management | Section 4.1 of [RFC7348]. If the BFD session is using the Management | |||
VNI (Section 6), BFD Control packets with unknown MAC address MUST | VNI (Section 6), BFD Control packets with unknown MAC address MUST | |||
NOT be forwarded to VMs. | NOT be forwarded to VMs. | |||
The UDP destination port and the TTL of the inner IP packet MUST be | The UDP destination port and the TTL or Hop Limit of the inner IP | |||
validated to determine if the received packet can be processed by | packet MUST be validated to determine if the received packet can be | |||
BFD. | processed by BFD. | |||
5.1. Demultiplexing of the BFD Packet | 5.1. Demultiplexing of the BFD Packet | |||
Demultiplexing of IP BFD packet has been defined in Section 3 of | Demultiplexing of IP BFD packet has been defined in Section 3 of | |||
[RFC5881]. Since multiple BFD sessions may be running between two | [RFC5881]. Since multiple BFD sessions may be running between two | |||
VTEPs, there needs to be a mechanism for demultiplexing received BFD | VTEPs, there needs to be a mechanism for demultiplexing received BFD | |||
packets to the proper session. For demultiplexing packets with Your | packets to the proper session. For demultiplexing packets with Your | |||
Discriminator equal to 0, a BFD session MUST be identified using the | Discriminator equal to 0, a BFD session MUST be identified using the | |||
logical link over which the BFD Control packet is received. In 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 | case of VXLAN, the VNI number identifies that logical link. If BFD | |||
packet is received with non-zero Your Discriminator, then BFD session | packet is received with non-zero Your Discriminator, then the BFD | |||
MUST be demultiplexed only with Your Discriminator as the key. | session MUST be demultiplexed only with Your Discriminator as the | |||
key. | ||||
6. Use of the Specific VNI | 6. Use of the Specific VNI | |||
In most cases, a single BFD session is sufficient for the given VTEP | In most cases, a single BFD session is sufficient for the given VTEP | |||
to monitor the reachability of a remote VTEP, regardless of the | to monitor the reachability of a remote VTEP, regardless of the | |||
number of VNIs. When the single BFD session is used to monitor the | number of VNIs. When the single BFD session is used to monitor the | |||
reachability of the remote VTEP, an implementation SHOULD choose any | reachability of the remote VTEP, an implementation SHOULD choose any | |||
of the VNIs. An implementation MAY support the use of the Management | of the VNIs. An implementation MAY support the use of the Management | |||
VNI as control and management channel between VTEPs. The selection | VNI as control and management channel between VTEPs. The selection | |||
of the VNI number of the Management VNI MUST be controlled through | of the VNI number of the Management VNI MUST be controlled through | |||
skipping to change at page 8, line 42 ¶ | skipping to change at page 9, line 43 ¶ | |||
Support for echo BFD is outside the scope of this document. | Support for echo BFD is outside the scope of this document. | |||
8. IANA Considerations | 8. IANA Considerations | |||
This specification has no IANA action requested. This section may be | This specification has no IANA action requested. This section may be | |||
deleted before the publication. | deleted before the publication. | |||
9. Security Considerations | 9. Security Considerations | |||
The document requires setting the inner IP TTL to 1, which could be | The document requires setting the inner IP TTL or Hop Limit to 1, | |||
used as a DDoS attack vector. Thus the implementation MUST have | which could be used as a DDoS attack vector. Thus the implementation | |||
throttling in place to control the rate of BFD Control packets sent | MUST have throttling in place to control the rate of BFD Control | |||
to the control plane. On the other hand, over-aggressive throttling | packets sent to the control plane. On the other hand, over- | |||
of BFD Control packets may become the cause of the inability to form | aggressive throttling of BFD Control packets may become the cause of | |||
and maintain BFD session at scale. Hence, throttling of BFD Control | the inability to form and maintain BFD session at scale. Hence, | |||
packets SHOULD be adjusted to permit BFD to work according to its | throttling of BFD Control packets SHOULD be adjusted to permit BFD to | |||
procedures. | work according to its procedures. | |||
This document recommends using an address from the Internal host | This document recommends using an address from the Internal host | |||
loopback addresses (127/8 range for IPv4 and | loopback addresses 127/8 range for IPv4 or an IP4-mapped IPv4 | |||
0:0:0:0:0:FFFF:7F00:0/104 range for IPv6) as the destination IP | loopback address from ::ffff:127.0.0.0/104 range for IPv6 as the | |||
address in the inner IP header. Using such address prevents the | destination IP address in the inner IP header. Using such an address | |||
forwarding of the encapsulated BFD control message by a transient | prevents the forwarding of the encapsulated BFD control message by a | |||
node in case the VXLAN tunnel is broken as according to [RFC1812]: | transient node in case the VXLAN tunnel is broken as according to | |||
[RFC1812]: | ||||
A router SHOULD NOT forward, except over a loopback interface, any | A router SHOULD NOT forward, except over a loopback interface, any | |||
packet that has a destination address on network 127. A router | packet that has a destination address on network 127. A router | |||
MAY have a switch that allows the network manager to disable these | MAY have a switch that allows the network manager to disable these | |||
checks. If such a switch is provided, it MUST default to | checks. If such a switch is provided, it MUST default to | |||
performing the checks. | performing the checks. | |||
If the implementation supports establishing multiple BFD sessions | If the implementation supports establishing multiple BFD sessions | |||
between the same pair of VTEPs, there SHOULD be a mechanism to | between the same pair of VTEPs, there SHOULD be a mechanism to | |||
control the maximum number of such sessions that can be active at the | control the maximum number of such sessions that can be active at the | |||
same time. | same time. | |||
Other than inner IP TTL set to 1 and limit the number of BFD sessions | Other than setting the value of inner IP TTL or Hop Limit to 1 and | |||
between the same pair of VTEPs, this specification does not raise any | limit the number of BFD sessions between the same pair of VTEPs, this | |||
additional security issues beyond those of the specifications | specification does not raise any additional security issues beyond | |||
referred to in the list of normative references. | those discussed in [RFC5880], [RFC5881], and [RFC7348]. | |||
10. Contributors | 10. Contributors | |||
Reshad Rahman | Reshad Rahman | |||
rrahman@cisco.com | rrahman@cisco.com | |||
Cisco | Cisco | |||
11. Acknowledgments | 11. Acknowledgments | |||
Authors would like to thank Jeff Haas of Juniper Networks for his | Authors would like to thank Jeff Haas of Juniper Networks for his | |||
End of changes. 24 change blocks. | ||||
71 lines changed or deleted | 77 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |