< draft-ietf-bfd-vxlan-10.txt   draft-ietf-bfd-vxlan-11.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: July 11, 2020 Individual Contributor Expires: July 25, 2020 Individual Contributor
V. Govindan V. Govindan
M. Mudigonda M. Mudigonda
Cisco Cisco
G. Mirsky G. Mirsky
ZTE Corp. ZTE Corp.
January 8, 2020 January 22, 2020
BFD for VXLAN BFD for VXLAN
draft-ietf-bfd-vxlan-10 draft-ietf-bfd-vxlan-11
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 used to form 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
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 July 11, 2020. This Internet-Draft will expire on July 25, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 14 skipping to change at page 2, line 14
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . 4
3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. BFD Packet Transmission over VXLAN Tunnel . . . . . . . . . . 6 4. BFD Packet Transmission over VXLAN Tunnel . . . . . . . . . . 6
5. Reception of BFD Packet from VXLAN Tunnel . . . . . . . . . . 8 5. Reception of BFD Packet from VXLAN Tunnel . . . . . . . . . . 8
5.1. Demultiplexing of the BFD Packet . . . . . . . . . . . . 9 5.1. Demultiplexing of the BFD Packet . . . . . . . . . . . . 8
6. Use of the Specific VNI . . . . . . . . . . . . . . . . . . . 9 6. Use of the Specific VNI . . . . . . . . . . . . . . . . . . . 9
7. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informational References . . . . . . . . . . . . . . . . 11 12.2. Informational References . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
skipping to change at page 3, line 32 skipping to change at page 3, line 32
availability of a replicator multicast service node. availability of a replicator multicast service node.
2. Conventions used in this document 2. Conventions used in this document
2.1. Terminology 2.1. Terminology
BFD Bidirectional Forwarding Detection BFD Bidirectional Forwarding Detection
CC Continuity Check CC Continuity Check
GTSM Generalized TTL Security Mechanism
p2p Point-to-point p2p Point-to-point
MSN Multicast Service Node MSN Multicast Service Node
NVE Network Virtualization Endpoint NVE Network Virtualization Endpoint
VFI Virtual Forwarding Instance VFI Virtual Forwarding Instance
VM Virtual Machine VM Virtual Machine
skipping to change at page 8, line 24 skipping to change at page 8, line 24
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 ::ffff:127.0.0.0/104. 127/8 for IPv4, for IPv6 - from the range ::ffff:127.0.0.0/104.
Alternatively, the destination IP address MAY be set to VTEP's Alternatively, the destination IP 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 255 in accordance with the
packet is not routed within the Layer 3 underlay network. This Generalized TTL Security Mechanism (GTSM) [RFC5082].
addresses the scenario when the inner IP destination address is
of the VXLAN gateway and there is a router in the underlay
which removes the VXLAN header, then it is possible to route
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, the 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 of [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 or Hop Limit of the inner IP The UDP destination port and the TTL or Hop Limit of the inner IP
packet MUST be validated to determine if the received packet can be packet MUST be validated to determine if the received packet can be
processed by BFD. processed by BFD. Validation of TTL or Hop Limit of the inner IP
packet is performed as described in Section 5 [RFC5881].
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
skipping to change at page 9, line 43 skipping to change at page 9, line 36
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 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.
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 or an IP4-mapped IPv4 loopback addresses 127/8 range for IPv4 or an IP4-mapped IPv4
loopback address from ::ffff:127.0.0.0/104 range for IPv6 as the loopback address from ::ffff:127.0.0.0/104 range for IPv6 as the
destination IP address in the inner IP header. Using such an address destination IP address in the inner IP header. Using such an address
prevents the forwarding of the encapsulated BFD control message by a prevents the forwarding of the encapsulated BFD control message by a
transient node in case the VXLAN tunnel is broken as according to transient node in case the VXLAN tunnel is broken as according to
[RFC1812]: [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 setting the value of inner IP TTL or Hop Limit to 1 and Other than requiring control of the number of BFD sessions between
limit the number of BFD sessions between the same pair of VTEPs, this the same pair of VTEPs, this specification does not raise any
specification does not raise any additional security issues beyond additional security issues beyond those discussed in [RFC5880],
those discussed in [RFC5880], [RFC5881], and [RFC7348]. [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
skipping to change at page 11, line 10 skipping to change at page 10, line 40
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
DOI 10.17487/RFC5881, June 2010, DOI 10.17487/RFC5881, June 2010,
<https://www.rfc-editor.org/info/rfc5881>. <https://www.rfc-editor.org/info/rfc5881>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
 End of changes. 12 change blocks. 
26 lines changed or deleted 21 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/