draft-ietf-bfd-base-08.txt   draft-ietf-bfd-base-09.txt 
Network Working Group D. Katz Network Working Group D. Katz
Internet Draft Juniper Networks Internet Draft Juniper Networks
D. Ward Intended status: Proposed Standard D. Ward
Cisco Systems Cisco Systems
Expires: September, 2008 March, 2008 Expires: August, 2009 February 5, 2009
Bidirectional Forwarding Detection Bidirectional Forwarding Detection
draft-ietf-bfd-base-08.txt draft-ietf-bfd-base-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document describes a protocol intended to detect faults in the This document describes a protocol intended to detect faults in the
bidirectional path between two forwarding engines, including bidirectional path between two forwarding engines, including
interfaces, data link(s), and to the extent possible the forwarding interfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency. It operates engines themselves, with potentially very low latency. It operates
independently of media, data protocols, and routing protocols. independently of media, data protocols, and routing protocols.
Comments on this draft should be directed to rtg-bfd@ietf.org.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEYWORDS]. document are to be interpreted as described in RFC-2119 [KEYWORDS].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Addressing and Session Establishment . . . . . . . . . . . 5 3.1 Addressing and Session Establishment . . . . . . . . . . . 6
3.2 Operating Modes . . . . . . . . . . . . . . . . . . . . . 5 3.2 Operating Modes . . . . . . . . . . . . . . . . . . . . . 6
4. BFD Control Packet Format . . . . . . . . . . . . . . . . . . 7 4. BFD Control Packet Format . . . . . . . . . . . . . . . . . . 7
4.1 Generic BFD Control Packet Format . . . . . . . . . . . . 7 4.1 Generic BFD Control Packet Format . . . . . . . . . . . . 7
4.2 Simple Password Authentication Section Format . . . . . 11 4.2 Simple Password Authentication Section Format . . . . . 12
4.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 4.3 Keyed MD5 and Meticulous Keyed MD5 Authentication
Section Format . . . . . . . . . . . . . . . . . . . . . 12
4.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication
Section Format . . . . . . . . . . . . . . . . . . . . . 13 Section Format . . . . . . . . . . . . . . . . . . . . . 13
5. BFD Echo Packet Format . . . . . . . . . . . . . . . . . . . 14 4.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication
6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 15 Section Format . . . . . . . . . . . . . . . . . . . . . 14
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 5. BFD Echo Packet Format . . . . . . . . . . . . . . . . . . . 15
6.2 BFD State Machine . . . . . . . . . . . . . . . . . . . 16 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 16
6.3 Demultiplexing and the Discriminator Fields . . . . . . 18 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 16
6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 19 6.2 BFD State Machine . . . . . . . . . . . . . . . . . . . 17
6.5 The Poll Sequence . . . . . . . . . . . . . . . . . . . 19 6.3 Demultiplexing and the Discriminator Fields . . . . . . 19
6.6 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 20 6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 20
6.7 Authentication . . . . . . . . . . . . . . . . . . . . . 21 6.5 The Poll Sequence . . . . . . . . . . . . . . . . . . . 20
6.7.1 Enabling and Disabling Authentication . . . . . . 22 6.6 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 21
6.7.2 Simple Password Authentication . . . . . . . . . . 22 6.7 Authentication . . . . . . . . . . . . . . . . . . . . . 22
6.7.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 23 6.7.1 Enabling and Disabling Authentication . . . . . . 23
6.7.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 25 6.7.2 Simple Password Authentication . . . . . . . . . . 24
6.8 Functional Specifics . . . . . . . . . . . . . . . . . . 27 6.7.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 24
6.8.1 State Variables . . . . . . . . . . . . . . . . . 27 6.7.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 26
6.8.2 Timer Negotiation . . . . . . . . . . . . . . . . 30 6.8 Functional Specifics . . . . . . . . . . . . . . . . . . 28
6.8.3 Timer Manipulation . . . . . . . . . . . . . . . . 31 6.8.1 State Variables . . . . . . . . . . . . . . . . . 28
6.8.4 Calculating the Detection Time . . . . . . . . . . 32 6.8.2 Timer Negotiation . . . . . . . . . . . . . . . . 32
6.8.5 Detecting Failures with the Echo Function . . . . 33 6.8.3 Timer Manipulation . . . . . . . . . . . . . . . . 32
6.8.6 Reception of BFD Control Packets . . . . . . . . . 34 6.8.4 Calculating the Detection Time . . . . . . . . . . 34
6.8.7 Transmitting BFD Control Packets . . . . . . . . . 36 6.8.5 Detecting Failures with the Echo Function . . . . 35
6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 39 6.8.6 Reception of BFD Control Packets . . . . . . . . . 35
6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 39 6.8.7 Transmitting BFD Control Packets . . . . . . . . . 37
6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 40 6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 40
6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 40 6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 41
6.8.12 Detect Multiplier Change . . . . . . . . . . . . 40 6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 41
6.8.13 Enabling or Disabling the Echo Function . . . . . 40 6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 41
6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 41 6.8.12 Detect Multiplier Change . . . . . . . . . . . . 41
6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 41 6.8.13 Enabling or Disabling the Echo Function . . . . . 42
6.8.16 Administrative Control . . . . . . . . . . . . . 41 6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 42
6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 42 6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 42
6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 42 6.8.16 Administrative Control . . . . . . . . . . . . . 42
Backward Compatibility (Non-Normative) . . . . . . . . . . . . 43 6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 43
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44 6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 43
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 7. Operational Considerations . . . . . . . . . . . . . . . . . 44
Security Considerations . . . . . . . . . . . . . . . . . . . . 44 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 45
IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 45 9. Security Considerations . . . . . . . . . . . . . . . . . . 46
Normative References . . . . . . . . . . . . . . . . . . . . . 45 10. References . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46 10.1 Normative References . . . . . . . . . . . . . . . . . 47
Changes from the previous draft . . . . . . . . . . . . . . . . 46 10.2 Informative References . . . . . . . . . . . . . . . . 47
IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Backward Compatibility (Non-Normative) . . . . . . . . . . . . 47
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49
Changes from the previous draft . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
An increasingly important feature of networking equipment is the An increasingly important feature of networking equipment is the
rapid detection of communication failures between adjacent systems, rapid detection of communication failures between adjacent systems,
in order to more quickly establish alternative paths. Detection can in order to more quickly establish alternative paths. Detection can
come fairly quickly in certain circumstances when data link hardware come fairly quickly in certain circumstances when data link hardware
comes into play (such as SONET alarms.) However, there are media comes into play (such as SONET alarms.) However, there are media
that do not provide this kind of signaling (such as Ethernet), and that do not provide this kind of signaling (such as Ethernet), and
some media may not detect certain kinds of failures in the path, for some media may not detect certain kinds of failures in the path, for
skipping to change at page 4, line 25 skipping to change at page 4, line 36
BFD is designed to detect failures in communication with a forwarding BFD is designed to detect failures in communication with a forwarding
plane next hop. It is intended to be implemented in some component plane next hop. It is intended to be implemented in some component
of the forwarding engine of a system, in cases where the forwarding of the forwarding engine of a system, in cases where the forwarding
and control engines are separated. This not only binds the protocol and control engines are separated. This not only binds the protocol
more to the forwarding plane, but decouples the protocol from the more to the forwarding plane, but decouples the protocol from the
fate of the routing protocol engine, making it useful in concert with fate of the routing protocol engine, making it useful in concert with
various "graceful restart" mechanisms for those protocols. BFD may various "graceful restart" mechanisms for those protocols. BFD may
also be implemented in the control engine, though doing so may also be implemented in the control engine, though doing so may
preclude the detection of some kinds of failures. preclude the detection of some kinds of failures.
BFD operates on top of any data protocol being forwarded between two BFD operates on top of any data protocol (network layer, link layer,
systems. It is always run in a unicast, point-to-point mode. BFD tunnels, etc.) being forwarded between two systems. It is always
packets are carried as the payload of whatever encapsulating protocol run in a unicast, point-to-point mode. BFD packets are carried as
is appropriate for the medium and network. BFD may be running at the payload of whatever encapsulating protocol is appropriate for the
multiple layers in a system. The context of the operation of any medium and network. BFD may be running at multiple layers in a
particular BFD session is bound to its encapsulation. system. The context of the operation of any particular BFD session
is bound to its encapsulation.
BFD can provide failure detection on any kind of path between BFD can provide failure detection on any kind of path between
systems, including direct physical links, virtual circuits, tunnels, systems, including direct physical links, virtual circuits, tunnels,
MPLS LSPs, multihop routed paths, and unidirectional links (so long MPLS LSPs, multihop routed paths, and unidirectional links (so long
as there is some return path, of course.) Multiple BFD sessions can as there is some return path, of course.) Multiple BFD sessions can
be established between the same pair of systems when multiple paths be established between the same pair of systems when multiple paths
between them are present in at least one direction, even if a lesser between them are present in at least one direction, even if a lesser
number of paths are available in the other direction (multiple number of paths are available in the other direction (multiple
parallel unidirectional links or MPLS LSPs, for example.) parallel unidirectional links or MPLS LSPs, for example.)
skipping to change at page 5, line 32 skipping to change at page 5, line 44
Each system estimates how quickly it can send and receive BFD packets Each system estimates how quickly it can send and receive BFD packets
in order to come to an agreement with its neighbor about how rapidly in order to come to an agreement with its neighbor about how rapidly
detection of failure will take place. These estimates can be detection of failure will take place. These estimates can be
modified in real time in order to adapt to unusual situations. This modified in real time in order to adapt to unusual situations. This
design also allows for fast systems on a shared medium with a slow design also allows for fast systems on a shared medium with a slow
system to be able to more rapidly detect failures between the fast system to be able to more rapidly detect failures between the fast
systems while allowing the slow system to participate to the best of systems while allowing the slow system to participate to the best of
its ability. its ability.
The ability of each system to control the BFD packet transmission
rate in both directions provides a mechanism for congestion control,
particularly when BFD is used across multiple network hops. The
exact algorithm can be independent in each system without affecting
interoperability, and is outside the scope of this specification.
3.1. Addressing and Session Establishment 3.1. Addressing and Session Establishment
A BFD session is established based on the needs of the application A BFD session is established based on the needs of the application
that will be making use of it. It is up to the application to that will be making use of it. It is up to the application to
determine the need for BFD, and the addresses to use--there is no determine the need for BFD, and the addresses to use--there is no
discovery mechanism in BFD. For example, an OSPF [OSPF] discovery mechanism in BFD. For example, an OSPF [OSPF]
implementation may request a BFD session to be established to a implementation may request a BFD session to be established to a
neighbor discovered using the OSPF Hello protocol. neighbor discovered using the OSPF Hello protocol.
3.2. Operating Modes 3.2. Operating Modes
skipping to change at page 6, line 48 skipping to change at page 7, line 20
the Echo packets back signals that it will allow it, and when the the Echo packets back signals that it will allow it, and when the
system that sends the Echo packets decides it wishes to. system that sends the Echo packets decides it wishes to.
Demand mode is useful in situations where the overhead of a periodic Demand mode is useful in situations where the overhead of a periodic
protocol might prove onerous, such as a system with a very large protocol might prove onerous, such as a system with a very large
number of BFD sessions. It is also useful when the Echo function is number of BFD sessions. It is also useful when the Echo function is
being used symmetrically. Demand mode has the disadvantage that being used symmetrically. Demand mode has the disadvantage that
Detection Times are essentially driven by the heuristics of the Detection Times are essentially driven by the heuristics of the
system implementation and are not known to the BFD protocol. Demand system implementation and are not known to the BFD protocol. Demand
mode may not be used when the path round trip time is greater than mode may not be used when the path round trip time is greater than
the desired Detection Time. See section 6.6 for more details. the desired Detection Time, or the protocol will fail to work
properly. See section 6.6 for more details.
4. BFD Control Packet Format 4. BFD Control Packet Format
4.1. Generic BFD Control Packet Format 4.1. Generic BFD Control Packet Format
BFD Control packets are sent in an encapsulation appropriate to the BFD Control packets are sent in an encapsulation appropriate to the
environment. The specific encapsulation is outside of the scope of environment. The specific encapsulation is outside of the scope of
this specification. See the appropriate application document for this specification. See the appropriate application document for
encapsulation details. encapsulation details.
skipping to change at page 7, line 37 skipping to change at page 8, line 24
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Your Discriminator | | Your Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Desired Min TX Interval | | Desired Min TX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min RX Interval | | Required Min RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min Echo RX Interval | | Required Min Echo RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An optional Authentication Section may be present: An optional Authentication Section MAY be present:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Authentication Data... | | Auth Type | Auth Len | Authentication Data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (Vers) Version (Vers)
The version number of the protocol. This document defines The version number of the protocol. This document defines
skipping to change at page 9, line 21 skipping to change at page 10, line 21
transmitting system's BFD implementation shares fate with its transmitting system's BFD implementation shares fate with its
control plane. control plane.
The use of this bit is application dependent and is outside the The use of this bit is application dependent and is outside the
scope of this specification. See specific application scope of this specification. See specific application
specifications for details. specifications for details.
Authentication Present (A) Authentication Present (A)
If set, the Authentication Section is present and the session is If set, the Authentication Section is present and the session is
to be authenticated. to be authenticated (see section 6.7 for details).
Demand (D) Demand (D)
If set, Demand mode is active in the transmitting system (the If set, Demand mode is active in the transmitting system (the
system wishes to operate in Demand mode, knows that the session is system wishes to operate in Demand mode, knows that the session is
up in both directions, and is directing the remote system to cease up in both directions, and is directing the remote system to cease
the periodic transmission of BFD Control packets.) If clear, the periodic transmission of BFD Control packets.) If clear,
Demand mode is not active in the transmitting system. Demand mode is not active in the transmitting system.
Multipoint (M) Multipoint (M)
This bit is reserved for future point-to-multipoint extensions to This bit is reserved for future point-to-multipoint extensions to
BFD. It must be zero on both transmit and receipt. BFD. It MUST be zero on both transmit and receipt.
Detect Mult Detect Mult
Detection time multiplier. The negotiated transmit interval, Detection time multiplier. The negotiated transmit interval,
multiplied by this value, provides the Detection Time for the multiplied by this value, provides the Detection Time for the
transmitting system in Asynchronous mode. transmitting system in Asynchronous mode.
Length Length
Length of the BFD Control packet, in bytes. Length of the BFD Control packet, in bytes.
skipping to change at page 10, line 20 skipping to change at page 11, line 20
Your Discriminator Your Discriminator
The discriminator received from the corresponding remote system. The discriminator received from the corresponding remote system.
This field reflects back the received value of My Discriminator, This field reflects back the received value of My Discriminator,
or is zero if that value is unknown. or is zero if that value is unknown.
Desired Min TX Interval Desired Min TX Interval
This is the minimum interval, in microseconds, that the local This is the minimum interval, in microseconds, that the local
system would like to use when transmitting BFD Control packets. system would like to use when transmitting BFD Control packets,
The value zero is reserved. less any jitter applied (see section 6.8.2). The value zero is
reserved.
Required Min RX Interval Required Min RX Interval
This is the minimum interval, in microseconds, between received This is the minimum interval, in microseconds, between received
BFD Control packets that this system is capable of supporting. If BFD Control packets that this system is capable of supporting,
less any jitter applied by the sender (see section 6.8.2). If
this value is zero, the transmitting system does not want the this value is zero, the transmitting system does not want the
remote system to send any periodic BFD Control packets. remote system to send any periodic BFD Control packets.
Required Min Echo RX Interval Required Min Echo RX Interval
This is the minimum interval, in microseconds, between received This is the minimum interval, in microseconds, between received
BFD Echo packets that this system is capable of supporting. If BFD Echo packets that this system is capable of supporting, less
this value is zero, the transmitting system does not support the any jitter applied by the sender (see section 6.8.9). If this
value is zero, the transmitting system does not support the
receipt of BFD Echo packets. receipt of BFD Echo packets.
Auth Type Auth Type
The authentication type in use, if the Authentication Present (A) The authentication type in use, if the Authentication Present (A)
bit is set. bit is set.
0 - Reserved 0 - Reserved
1 - Simple Password 1 - Simple Password
2 - Keyed MD5 2 - Keyed MD5
skipping to change at page 12, line 7 skipping to change at page 13, line 12
The authentication key ID in use for this packet. This allows The authentication key ID in use for this packet. This allows
multiple keys to be active simultaneously. multiple keys to be active simultaneously.
Password Password
The simple password in use on this session. The password MUST be The simple password in use on this session. The password MUST be
from 1 to 16 bytes in length. from 1 to 16 bytes in length.
4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format 4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format
The use of MD5-based authentication is strongly discouraged.
However, it is documented here for compatibility with existing
implementations.
If the Authentication Present (A) bit is set in the header, and the If the Authentication Present (A) bit is set in the header, and the
Authentication Type field contains 2 (Keyed MD5) or 3 (Meticulous Authentication Type field contains 2 (Keyed MD5) or 3 (Meticulous
Keyed MD5), the Authentication Section has the following format: Keyed MD5), the Authentication Section has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved | | Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key/Checksum... | | Auth Key/Digest... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type Auth Type
The Authentication Type, which in this case is 2 (Keyed MD5) or 3 The Authentication Type, which in this case is 2 (Keyed MD5) or 3
(Meticulous Keyed MD5). (Meticulous Keyed MD5).
Auth Len Auth Len
skipping to change at page 12, line 40 skipping to change at page 14, line 7
The length of the Authentication Section, in bytes. For Keyed MD5 The length of the Authentication Section, in bytes. For Keyed MD5
and Meticulous Keyed MD5 authentication, the length is 24. and Meticulous Keyed MD5 authentication, the length is 24.
Auth Key ID Auth Key ID
The authentication key ID in use for this packet. This allows The authentication key ID in use for this packet. This allows
multiple keys to be active simultaneously. multiple keys to be active simultaneously.
Reserved Reserved
This byte must be set to zero on transmit, and ignored on receipt. This byte MUST be set to zero on transmit, and ignored on receipt.
Sequence Number Sequence Number
The Sequence Number for this packet. For Keyed MD5 The Sequence Number for this packet. For Keyed MD5
Authentication, this value is incremented occasionally. For Authentication, this value is incremented occasionally. For
Meticulous Keyed MD5 Authentication, this value is incremented for Meticulous Keyed MD5 Authentication, this value is incremented for
each successive packet transmitted for a session. This provides each successive packet transmitted for a session. This provides
protection against replay attacks. protection against replay attacks.
Auth Key/Checksum Auth Key/Digest
This field carries the 16 byte MD5 checksum for the packet. When This field carries the 16 byte MD5 digest for the packet. When
the checksum is calculated, the shared MD5 key is stored in this the digest is calculated, the shared MD5 key is stored in this
field. (See section 6.7.3 for details.) field. (See section 6.7.3 for details.) The shared key MUST be
16 bytes in length.
4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format 4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format
If the Authentication Present (A) bit is set in the header, and the If the Authentication Present (A) bit is set in the header, and the
Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous
Keyed SHA1), the Authentication Section has the following format: Keyed SHA1), the Authentication Section has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved | | Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key/Checksum... | | Auth Key/Hash... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type Auth Type
The Authentication Type, which in this case is 4 (Keyed SHA1) or 5 The Authentication Type, which in this case is 4 (Keyed SHA1) or 5
(Meticulous Keyed SHA1). (Meticulous Keyed SHA1).
Auth Len Auth Len
skipping to change at page 14, line 7 skipping to change at page 15, line 17
The length of the Authentication Section, in bytes. For Keyed The length of the Authentication Section, in bytes. For Keyed
SHA1 and Meticulous Keyed SHA1 authentication, the length is 28. SHA1 and Meticulous Keyed SHA1 authentication, the length is 28.
Auth Key ID Auth Key ID
The authentication key ID in use for this packet. This allows The authentication key ID in use for this packet. This allows
multiple keys to be active simultaneously. multiple keys to be active simultaneously.
Reserved Reserved
This byte must be set to zero on transmit, and ignored on receipt. This byte MUST be set to zero on transmit, and ignored on receipt.
Sequence Number Sequence Number
The Sequence Number for this packet. For Keyed SHA1 The Sequence Number for this packet. For Keyed SHA1
Authentication, this value is incremented occasionally. For Authentication, this value is incremented occasionally. For
Meticulous Keyed SHA1 Authentication, this value is incremented Meticulous Keyed SHA1 Authentication, this value is incremented
for each successive packet transmitted for a session. This for each successive packet transmitted for a session. This
provides protection against replay attacks. provides protection against replay attacks.
Auth Key/Checksum Auth Key/Hash
This field carries the 20 byte SHA1 checksum for the packet. When This field carries the 20 byte SHA1 hash for the packet. When the
the checksum is calculated, the shared SHA1 key is stored in this hash is calculated, the shared SHA1 key is stored in this field.
field. (See section 6.7.4 for details.) (See section 6.7.4 for details.) The shared key MUST be 20 bytes
in length.
5. BFD Echo Packet Format 5. BFD Echo Packet Format
BFD Echo packets are sent in an encapsulation appropriate to the BFD Echo packets are sent in an encapsulation appropriate to the
environment. See the appropriate application documents for the environment. See the appropriate application documents for the
specifics of particular environments. specifics of particular environments.
The payload of a BFD Echo packet is a local matter, since only the The payload of a BFD Echo packet is a local matter, since only the
sending system ever processes the content. The only requirement is sending system ever processes the content. The only requirement is
that sufficient information is included to demultiplex the received that sufficient information is included to demultiplex the received
packet to the correct BFD session after it is looped back to the packet to the correct BFD session after it is looped back to the
sender. The contents are otherwise outside the scope of this sender. The contents are otherwise outside the scope of this
specification. specification.
Some form of authentication SHOULD be included, since Echo packets
may be spoofed.
6. Elements of Procedure 6. Elements of Procedure
This section discusses the normative requirements of the protocol in This section discusses the normative requirements of the protocol in
order to achieve interoperability. It is important for implementors order to achieve interoperability. It is important for implementors
to enforce only the requirements specified in this section, as to enforce only the requirements specified in this section, as
misguided pedantry has been proven by experience to adversely affect misguided pedantry has been proven by experience to adversely affect
interoperability. interoperability.
Remember that all references of the form "bfd.Xx" refer to internal Remember that all references of the form "bfd.Xx" refer to internal
state variables (defined in section 6.8.1), whereas all references to state variables (defined in section 6.8.1), whereas all references to
skipping to change at page 16, line 23 skipping to change at page 17, line 28
in the same manner. See section 6.6. in the same manner. See section 6.6.
If the session goes down, the transmission of Echo packets (if any) If the session goes down, the transmission of Echo packets (if any)
ceases, and the transmission of Control packets goes back to the slow ceases, and the transmission of Control packets goes back to the slow
rate. rate.
Once a session has been declared down, it cannot come back up until Once a session has been declared down, it cannot come back up until
the remote end first signals that it is down (by leaving the Up the remote end first signals that it is down (by leaving the Up
state), thus implementing a three-way handshake. state), thus implementing a three-way handshake.
A session may be kept administratively down by entering the AdminDown A session MAY be kept administratively down by entering the AdminDown
state and sending an explanatory diagnostic code in the Diagnostic state and sending an explanatory diagnostic code in the Diagnostic
field. field.
6.2. BFD State Machine 6.2. BFD State Machine
The BFD state machine is quite straightforward. There are three The BFD state machine is quite straightforward. There are three
states through which a session normally proceeds, two for states through which a session normally proceeds, two for
establishing a session (Init and Up) and one for tearing down a establishing a session (Init and Up) and one for tearing down a
session (Down.) This allows a three-way handshake for both session session (Down.) This allows a three-way handshake for both session
establishment and session teardown (assuring that both systems are establishment and session teardown (assuring that both systems are
skipping to change at page 20, line 21 skipping to change at page 21, line 21
Typically, the entire sequence consists of a single packet in each Typically, the entire sequence consists of a single packet in each
direction, though packet losses or relatively long packet latencies direction, though packet losses or relatively long packet latencies
may result in multiple Poll packets to be sent before the sequence may result in multiple Poll packets to be sent before the sequence
terminates. terminates.
6.6. Demand Mode 6.6. Demand Mode
Demand mode is requested independently in each direction by virtue of Demand mode is requested independently in each direction by virtue of
a system setting the Demand (D) bit in its BFD Control packets. The a system setting the Demand (D) bit in its BFD Control packets. The
Demand bit can only be set if both systems think the session is up. system receiving the Demand bit ceases the periodic transmission of
The system receiving the Demand bit ceases the periodic transmission BFD Control packets. If both systems are operating in Demand mode,
of BFD Control packets. If both systems are operating in Demand no periodic BFD Control packets will flow in either direction.
mode, no periodic BFD Control packets will flow in either direction.
Demand mode requires that some other mechanism is used to imply Demand mode requires that some other mechanism is used to imply
continuing connectivity between the two systems. The mechanism used continuing connectivity between the two systems. The mechanism used
does not have to be the same in both directions, and is outside of does not have to be the same in both directions, and is outside of
the scope of this specification. One possible mechanism is the the scope of this specification. One possible mechanism is the
receipt of traffic from the remote system; another is the use of the receipt of traffic from the remote system; another is the use of the
Echo function. Echo function.
When a system in Demand mode wishes to verify bidirectional When a system in Demand mode wishes to verify bidirectional
connectivity, it initiates a Poll Sequence (see section 6.5). If no connectivity, it initiates a Poll Sequence (see section 6.5). If no
skipping to change at page 20, line 48 skipping to change at page 21, line 47
system, the Poll Sequence is performed by simply setting the Poll (P) system, the Poll Sequence is performed by simply setting the Poll (P)
bit in regular periodic BFD Control packets, as required by section bit in regular periodic BFD Control packets, as required by section
6.6. 6.6.
The Detection Time in Demand mode is calculated differently than in The Detection Time in Demand mode is calculated differently than in
Asynchronous mode; it is based on the transmit rate of the local Asynchronous mode; it is based on the transmit rate of the local
system, rather than the transmit rate of the remote system. This system, rather than the transmit rate of the remote system. This
ensures that the Poll Sequence mechanism works properly. See section ensures that the Poll Sequence mechanism works properly. See section
6.8.4 for more details. 6.8.4 for more details.
Note that this mechanism requires that the Detection Time negotiated Note that the Poll mechanism will always fail unless the negotiated
is greater than the round trip time between the two systems, or the Detection Time is greater than the round trip time between the two
Poll mechanism will always fail. Enforcement of this requirement is systems. Enforcement of this constraint is outside the scope of this
outside the scope of this specification. specification.
Demand mode MAY be enabled or disabled at any time, independently in Demand mode MAY be enabled or disabled at any time, independently in
each direction, by setting or clearing the Demand (D) bit in the BFD each direction, by setting or clearing the Demand (D) bit in the BFD
Control packet, without affecting the BFD session state. Note that Control packet, without affecting the BFD session state. Note that
the Demand bit MUST NOT be set unless both systems perceive the the Demand bit MUST NOT be set unless both systems perceive the
session to be Up (the local system thinks the session is Up, and the session to be Up (the local system thinks the session is Up, and the
remote system last reported Up state in the State (Sta) field of the remote system last reported Up state in the State (Sta) field of the
BFD Control packet.) BFD Control packet.)
When the transmitted value of the Demand (D) bit is to be changed, When the transmitted value of the Demand (D) bit is to be changed,
skipping to change at page 21, line 42 skipping to change at page 22, line 41
Note that if Demand mode is enabled in only one direction, continuous Note that if Demand mode is enabled in only one direction, continuous
bidirectional connectivity verification is lost (only connectivity in bidirectional connectivity verification is lost (only connectivity in
the direction from the system in Demand mode to the other system will the direction from the system in Demand mode to the other system will
be verified.) Resolving the issue of one system requesting Demand be verified.) Resolving the issue of one system requesting Demand
mode while the other requires continuous bidirectional connectivity mode while the other requires continuous bidirectional connectivity
verification is outside the scope of this specification. verification is outside the scope of this specification.
6.7. Authentication 6.7. Authentication
An optional Authentication Section may be present in the BFD Control An optional Authentication Section MAY be present in the BFD Control
packet. In its generic form, the purpose of the Authentication packet. In its generic form, the purpose of the Authentication
Section is to carry all necessary information, based on the Section is to carry all necessary information, based on the
authentication type in use, to allow the receiving system to authentication type in use, to allow the receiving system to
determine the validity of the received packet. The exact mechanism determine the validity of the received packet. The exact mechanism
depends on the authentication type in use, but in general the depends on the authentication type in use, but in general the
transmitting system will put information in the Authentication transmitting system will put information in the Authentication
Section that vouches for the packet's validity, and the receiving Section that vouches for the packet's validity, and the receiving
system will examine the Authentication Section and either accept the system will examine the Authentication Section and either accept the
packet for further processing, or discard it. packet for further processing, or discard it.
The same authentication type, and any keys or other necessary
information, obviously must be in use by the two systems. The
negotiation of authentication type, key exchange, etc. are all
outside the scope of this specification and are expected to be
performed by means outside of the protocol.
Note that in the subsections below, to "accept" a packet means only Note that in the subsections below, to "accept" a packet means only
that the packet has passed authentication; it may in fact be that the packet has passed authentication; it may in fact be
discarded for other reasons as described in the general packet discarded for other reasons as described in the general packet
reception rules described in section 6.8.6. reception rules described in section 6.8.6.
Implementations supporting authentication MUST support SHA1 Implementations supporting authentication MUST support SHA1
authentication. Other forms of authentication are optional. authentication. Other forms of authentication are optional.
6.7.1. Enabling and Disabling Authentication 6.7.1. Enabling and Disabling Authentication
skipping to change at page 22, line 37 skipping to change at page 23, line 42
authentication. authentication.
One possible approach is to build an implementation such that One possible approach is to build an implementation such that
authentication is configured, but not considered "in use" until the authentication is configured, but not considered "in use" until the
first packet containing a matching authentication section is received first packet containing a matching authentication section is received
(providing the necessary synchronization.) Likewise, authentication (providing the necessary synchronization.) Likewise, authentication
could be configured off, but still considered "in use" until the could be configured off, but still considered "in use" until the
receipt of the first packet without the authentication section. receipt of the first packet without the authentication section.
In order to avoid security risks, implementations using this method In order to avoid security risks, implementations using this method
should only allow the authentication state to be changed once without SHOULD only allow the authentication state to be changed at most once
some form of intervention (so that authentication cannot be turned on without some form of intervention (so that authentication cannot be
and off repeatedly simply based on the receipt of BFD Control packets turned on and off repeatedly simply based on the receipt of BFD
from remote systems.) Control packets from remote systems.) Unless it is desired to enable
or disable authentication, an implementation SHOULD NOT allow the
authentication state to change based on the receipt of BFD Control
packets.
6.7.2. Simple Password Authentication 6.7.2. Simple Password Authentication
The most straightforward (and weakest) form of authentication is The most straightforward (and weakest) form of authentication is
Simple Password Authentication. In this method of authentication, Simple Password Authentication. In this method of authentication,
one or more Passwords (with corresponding Key IDs) are configured in one or more Passwords (with corresponding Key IDs) are configured in
each system and one of these Password/ID pairs is carried in each BFD each system and one of these Password/ID pairs is carried in each BFD
Control packet. The receiving system accepts the packet if the Control packet. The receiving system accepts the packet if the
Password and Key ID matches one of the Password/ID pairs configured Password and Key ID matches one of the Password/ID pairs configured
in that system. in that system.
skipping to change at page 23, line 37 skipping to change at page 24, line 46
Key ID, the packet MUST be discarded. Key ID, the packet MUST be discarded.
Otherwise, the packet MUST be accepted. Otherwise, the packet MUST be accepted.
6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication 6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication
The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are
very similar to those used in other protocols. In these methods of very similar to those used in other protocols. In these methods of
authentication, one or more secret keys (with corresponding Key IDs) authentication, one or more secret keys (with corresponding Key IDs)
are configured in each system. One of the Keys is included in an MD5 are configured in each system. One of the Keys is included in an MD5
[MD5] checksum calculated over the outgoing BFD Control packet, but [MD5] digest calculated over the outgoing BFD Control packet, but the
the Key itself is not carried in the packet. To help avoid replay Key itself is not carried in the packet. To help avoid replay
attacks, a sequence number is also carried in each packet. For Keyed attacks, a sequence number is also carried in each packet. For Keyed
MD5, the sequence number is occasionally incremented. For Meticulous MD5, the sequence number is occasionally incremented. For Meticulous
Keyed MD5, the sequence number is incremented on every packet. Keyed MD5, the sequence number is incremented on every packet.
The receiving system accepts the packet if the Key ID matches one of The receiving system accepts the packet if the Key ID matches one of
the configured Keys, an MD5 checksum including the selected key the configured Keys, an MD5 digest including the selected key matches
matches that carried in the packet, and if the sequence number is that carried in the packet, and if the sequence number is greater
greater than or equal to the last sequence number received (for Keyed than or equal to the last sequence number received (for Keyed MD5),
MD5), or strictly greater than the last sequence number received (for or strictly greater than the last sequence number received (for
Meticulous Keyed MD5.) Meticulous Keyed MD5.)
Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication
The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous
Keyed MD5.) The Auth Len field MUST be set to 24. The Auth Key Keyed MD5.) The Auth Len field MUST be set to 24. The Auth Key
ID field MUST be set to the ID of the current authentication key. ID field MUST be set to the ID of the current authentication key.
The Sequence Number field MUST be set to bfd.XmitAuthSeq. The Sequence Number field MUST be set to bfd.XmitAuthSeq.
The current authentication key value MUST be placed into the Auth The current authentication key value MUST be placed into the Auth
Key/Checksum field. An MD5 checksum MUST be calculated over the Key/Digest field. An MD5 digest MUST be calculated over the
entire BFD control packet. The resulting checksum MUST be stored entire BFD control packet. The resulting digest MUST be stored in
in the Auth Key/Checksum field prior to transmission (replacing the Auth Key/Digest field prior to transmission (replacing the
the secret key, which MUST NOT be carried in the packet.) secret key, which MUST NOT be carried in the packet.)
For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular
fashion (when treated as an unsigned 32 bit value.) fashion (when treated as an unsigned 32 bit value.)
bfd.XmitAuthSeq SHOULD be incremented when the session state bfd.XmitAuthSeq SHOULD be incremented when the session state
changes, or when the transmitted BFD Control packet carries changes, or when the transmitted BFD Control packet carries
different contents than the previously transmitted packet. The different contents than the previously transmitted packet. The
decision as to when to increment bfd.XmitAuthSeq is outside the decision as to when to increment bfd.XmitAuthSeq is outside the
scope of this specification. See the section entitled "Security scope of this specification. See the section entitled "Security
Considerations" below for a discussion. Considerations" below for a discussion.
skipping to change at page 24, line 42 skipping to change at page 26, line 5
Authentication Section, or the Auth Type is not correct (2 for Authentication Section, or the Auth Type is not correct (2 for
Keyed MD5, or 3 for Meticulous Keyed MD5), then the received Keyed MD5, or 3 for Meticulous Keyed MD5), then the received
packet MUST be discarded. packet MUST be discarded.
If the Auth Key ID field does not match the ID of a configured If the Auth Key ID field does not match the ID of a configured
authentication key, the received packet MUST be discarded. authentication key, the received packet MUST be discarded.
If the Auth Len field is not equal to 24, the packet MUST be If the Auth Len field is not equal to 24, the packet MUST be
discarded. discarded.
Replace the contents of the Auth Key/Checksum field with the
authentication key selected by the received Auth Key ID field. If
the MD5 checksum of the entire BFD Control packet is not equal to
the received value of the Auth Key/Checksum field, the received
packet MUST be discarded.
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For
Keyed MD5, if the Sequence Number lies outside of the range of Keyed MD5, if the Sequence Number lies outside of the range of
bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when
treated as an unsigned 32 bit circular number space), the received treated as an unsigned 32 bit circular number space), the received
packet MUST be discarded. For Meticulous Keyed MD5, if the packet MUST be discarded. For Meticulous Keyed MD5, if the
Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to
bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an
unsigned 32 bit circular number space, the received packet MUST be unsigned 32 bit circular number space, the received packet MUST be
discarded. discarded.
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to
1, bfd.RcvAuthSeq MUST be set to the value of the received 1, bfd.RcvAuthSeq MUST be set to the value of the received
Sequence Number field, and the received packet MUST be accepted. Sequence Number field.
Replace the contents of the Auth Key/Digest field with the
authentication key selected by the received Auth Key ID field. If
the MD5 digest of the entire BFD Control packet is equal to the
received value of the Auth Key/Digest field, the received packet
MUST be accepted. Otherwise (the digest does not match the Auth
Key/Digest field) the received packet MUST be discarded.
6.7.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication 6.7.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication
The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms
are very similar to those used in other protocols. In these methods are very similar to those used in other protocols. In these methods
of authentication, one or more secret keys (with corresponding Key of authentication, one or more secret keys (with corresponding Key
IDs) are configured in each system. One of the Keys is included in a IDs) are configured in each system. One of the Keys is included in a
SHA1 [SHA1] checksum calculated over the outgoing BFD Control packet, SHA1 [SHA1] hash calculated over the outgoing BFD Control packet, but
but the Key itself is not carried in the packet. To help avoid the Key itself is not carried in the packet. To help avoid replay
replay attacks, a sequence number is also carried in each packet. attacks, a sequence number is also carried in each packet. For Keyed
For Keyed SHA1, the sequence number is occasionally incremented. For SHA1, the sequence number is occasionally incremented. For
Meticulous Keyed SHA1, the sequence number is incremented on every Meticulous Keyed SHA1, the sequence number is incremented on every
packet. packet.
The receiving system accepts the packet if the Key ID matches one of The receiving system accepts the packet if the Key ID matches one of
the configured Keys, a SHA1 checksum including the selected key the configured Keys, a SHA1 hash including the selected key matches
matches that carried in the packet, and if the sequence number is that carried in the packet, and if the sequence number is greater
greater than or equal to the last sequence number received (for Keyed than or equal to the last sequence number received (for Keyed SHA1),
SHA1), or strictly greater than the last sequence number received or strictly greater than the last sequence number received (for
(for Meticulous Keyed SHA1.) Meticulous Keyed SHA1.)
Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 Transmission Using Keyed SHA1 and Meticulous Keyed SHA1
Authentication Authentication
The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous
Keyed SHA1.) The Auth Len field MUST be set to 28. The Auth Key Keyed SHA1.) The Auth Len field MUST be set to 28. The Auth Key
ID field MUST be set to the ID of the current authentication key. ID field MUST be set to the ID of the current authentication key.
The Sequence Number field MUST be set to bfd.XmitAuthSeq. The Sequence Number field MUST be set to bfd.XmitAuthSeq.
The current authentication key value MUST be placed into the Auth The current authentication key value MUST be placed into the Auth
Key/Checksum field. A SHA1 checksum MUST be calculated over the Key/Hash field. A SHA1 hash MUST be calculated over the entire
entire BFD control packet. The resulting checksum MUST be stored BFD control packet. The resulting hash MUST be stored in the Auth
in the Auth Key/Checksum field prior to transmission (replacing Key/Hash field prior to transmission (replacing the secret key,
the secret key, which MUST NOT be carried in the packet.) which MUST NOT be carried in the packet.)
For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular
fashion (when treated as an unsigned 32 bit value.) fashion (when treated as an unsigned 32 bit value.)
bfd.XmitAuthSeq SHOULD be incremented when the session state bfd.XmitAuthSeq SHOULD be incremented when the session state
changes, or when the transmitted BFD Control packet carries changes, or when the transmitted BFD Control packet carries
different contents than the previously transmitted packet. The different contents than the previously transmitted packet. The
decision as to when to increment bfd.XmitAuthSeq is outside the decision as to when to increment bfd.XmitAuthSeq is outside the
scope of this specification. See the section entitled "Security scope of this specification. See the section entitled "Security
Considerations" below for a discussion. Considerations" below for a discussion.
skipping to change at page 26, line 28 skipping to change at page 27, line 38
Authentication Section, or the Auth Type is not correct (4 for Authentication Section, or the Auth Type is not correct (4 for
Keyed SHA1, or 5 for Meticulous Keyed SHA1), then the received Keyed SHA1, or 5 for Meticulous Keyed SHA1), then the received
packet MUST be discarded. packet MUST be discarded.
If the Auth Key ID field does not match the ID of a configured If the Auth Key ID field does not match the ID of a configured
authentication key, the received packet MUST be discarded. authentication key, the received packet MUST be discarded.
If the Auth Len field is not equal to 28, the packet MUST be If the Auth Len field is not equal to 28, the packet MUST be
discarded. discarded.
Replace the contents of the Auth Key/Checksum field with the
authentication key selected by the received Auth Key ID field. If
the SHA1 checksum of the entire BFD Control packet is not equal to
the received value of the Auth Key/Checksum field, the received
packet MUST be discarded.
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For
Keyed SHA1, if the Sequence Number lies outside of the range of Keyed SHA1, if the Sequence Number lies outside of the range of
bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when
treated as an unsigned 32 bit circular number space), the received treated as an unsigned 32 bit circular number space), the received
packet MUST be discarded. For Meticulous Keyed SHA1, if the packet MUST be discarded. For Meticulous Keyed SHA1, if the
Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to
bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an
unsigned 32 bit circular number space, the received packet MUST be unsigned 32 bit circular number space, the received packet MUST be
discarded. discarded.
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to
1, bfd.RcvAuthSeq MUST be set to the value of the received 1, bfd.RcvAuthSeq MUST be set to the value of the received
Sequence Number field, and the received packet MUST be accepted. Sequence Number field, and the received packet MUST be accepted.
Replace the contents of the Auth Key/Hash field with the
authentication key selected by the received Auth Key ID field. If
the SHA1 hash of the entire BFD Control packet is equal to the
received value of the Auth Key/Hash field, the received packet
MUST be accepted. Otherwise (the hash does not match the Auth
Key/Hash field) the received packet MUST be discarded.
6.8. Functional Specifics 6.8. Functional Specifics
The following section of this specification is normative. The means The following section of this specification is normative. The means
by which this specification is achieved is outside the scope of this by which this specification is achieved is outside the scope of this
specification. specification.
When a system is said to have "the Echo function active," it means When a system is said to have "the Echo function active," it means
that the system is sending BFD Echo packets, implying that the that the system is sending BFD Echo packets, implying that the
session is Up and the other system has signaled its willingness to session is Up and the other system has signaled its willingness to
loop back Echo packets. loop back Echo packets.
skipping to change at page 29, line 4 skipping to change at page 30, line 10
opaque to the local system. This MUST be initialized to zero. opaque to the local system. This MUST be initialized to zero.
If a period of a Detection Time passes without the receipt of a If a period of a Detection Time passes without the receipt of a
valid, authenticated BFD packet from the remote system, this valid, authenticated BFD packet from the remote system, this
variable MUST be set to zero. variable MUST be set to zero.
bfd.LocalDiag bfd.LocalDiag
The diagnostic code specifying the reason for the most recent The diagnostic code specifying the reason for the most recent
change in the local session state. This MUST be initialized to change in the local session state. This MUST be initialized to
zero (No Diagnostic.) zero (No Diagnostic.)
bfd.DesiredMinTxInterval bfd.DesiredMinTxInterval
The minimum interval, in microseconds, between transmitted BFD The minimum interval, in microseconds, between transmitted BFD
Control packets that this system would like to use at the Control packets that this system would like to use at the
current time. The actual interval is negotiated between the current time, less any jitter applied (see section 6.8.2). The
two systems. This MUST be initialized to a value of at least actual interval is negotiated between the two systems. This
one second (1,000,000 microseconds) according to the rules MUST be initialized to a value of at least one second
described in section 6.8.3. The setting of this variable is (1,000,000 microseconds) according to the rules described in
otherwise outside the scope of this specification. section 6.8.3. The setting of this variable is otherwise
outside the scope of this specification.
bfd.RequiredMinRxInterval bfd.RequiredMinRxInterval
The minimum interval, in microseconds, between received BFD The minimum interval, in microseconds, between received BFD
Control packets that this system requires. The setting of this Control packets that this system requires, less any jitter
applied by the sender (see section 6.8.2). The setting of this
variable is outside the scope of this specification. A value variable is outside the scope of this specification. A value
of zero means that this system does not want to receive any of zero means that this system does not want to receive any
periodic BFD Control packets. See section 6.8.18 for details. periodic BFD Control packets. See section 6.8.18 for details.
bfd.RemoteMinRxInterval bfd.RemoteMinRxInterval
The last value of Required Min RX Interval received from the The last value of Required Min RX Interval received from the
remote system in a BFD Control packet. This variable MUST be remote system in a BFD Control packet. This variable MUST be
initialized to 1. initialized to 1.
skipping to change at page 31, line 31 skipping to change at page 32, line 44
The time values used to determine BFD packet transmission intervals The time values used to determine BFD packet transmission intervals
and the session Detection Time may be modified at any time without and the session Detection Time may be modified at any time without
affecting the state of the session. When the timer parameters are affecting the state of the session. When the timer parameters are
changed for any reason, the requirements of this section apply. changed for any reason, the requirements of this section apply.
If either bfd.DesiredMinTxInterval is changed or If either bfd.DesiredMinTxInterval is changed or
bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be
initiated (see section 6.5). If the timing is such that a system initiated (see section 6.5). If the timing is such that a system
receiving a Poll Sequence wishes to change the parameters described receiving a Poll Sequence wishes to change the parameters described
in this paragraph, the new parameter values may be carried in packets in this paragraph, the new parameter values MAY be carried in packets
with the Final (F) bit set, even if the Poll Sequence has not yet with the Final (F) bit set, even if the Poll Sequence has not yet
been sent. been sent.
If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up, If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up,
the actual transmission interval used MUST NOT change until the Poll the actual transmission interval used MUST NOT change until the Poll
Sequence described above has terminated. This is to ensure that the Sequence described above has terminated. This is to ensure that the
remote system updates its Detection Time before the transmission remote system updates its Detection Time before the transmission
interval increases. interval increases.
If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up, If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up,
skipping to change at page 34, line 43 skipping to change at page 36, line 6
If the Your Discriminator field is zero and the State field is not If the Your Discriminator field is zero and the State field is not
Down or AdminDown, the packet MUST be discarded. Down or AdminDown, the packet MUST be discarded.
If the Your Discriminator field is zero, the session MUST be If the Your Discriminator field is zero, the session MUST be
selected based on some combination of other fields, possibly selected based on some combination of other fields, possibly
including source addressing information, the My Discriminator including source addressing information, the My Discriminator
field, and the interface over which the packet was received. The field, and the interface over which the packet was received. The
exact method of selection is application-specific and is thus exact method of selection is application-specific and is thus
outside the scope of this specification. If a matching session is outside the scope of this specification. If a matching session is
not found, a new session may be created, or the packet may be not found, a new session MAY be created, or the packet MAY be
discarded. This choice is outside the scope of this discarded. This choice is outside the scope of this
specification. specification.
If the A bit is set and no authentication is in use (bfd.AuthType If the A bit is set and no authentication is in use (bfd.AuthType
is zero), the packet MUST be discarded. is zero), the packet MUST be discarded.
If the A bit is clear and authentication is in use (bfd.AuthType If the A bit is clear and authentication is in use (bfd.AuthType
is nonzero), the packet MUST be discarded. is nonzero), the packet MUST be discarded.
If the A bit is set, the packet MUST be authenticated under the If the A bit is set, the packet MUST be authenticated under the
skipping to change at page 35, line 34 skipping to change at page 36, line 45
Update the transmit interval as described in section 6.8.2. Update the transmit interval as described in section 6.8.2.
Update the Detection Time as described in section 6.8.4. Update the Detection Time as described in section 6.8.4.
If bfd.SessionState is AdminDown If bfd.SessionState is AdminDown
Discard the packet Discard the packet
If received state is AdminDown If received state is AdminDown
If bfd.SessionState is not Down If bfd.SessionState is not Down
Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.LocalDiag to 3 (Neighbor signaled
session down)
Set bfd.SessionState to Down Set bfd.SessionState to Down
Else Else
If bfd.SessionState is Down If bfd.SessionState is Down
If received State is Down If received State is Down
Set bfd.SessionState to Init Set bfd.SessionState to Init
Else if received State is Init Else if received State is Init
Set bfd.SessionState to Up Set bfd.SessionState to Up
skipping to change at page 42, line 36 skipping to change at page 43, line 46
not transmitting periodic BFD Control packets), a Poll Sequence MUST not transmitting periodic BFD Control packets), a Poll Sequence MUST
be initiated to ensure that the diagnostic code is transmitted. Note be initiated to ensure that the diagnostic code is transmitted. Note
that if the BFD session subsequently fails, the diagnostic code will that if the BFD session subsequently fails, the diagnostic code will
be overwritten with a code detailing the cause of the failure. It is be overwritten with a code detailing the cause of the failure. It is
up to the interworking agent to perform the above procedure again, up to the interworking agent to perform the above procedure again,
once the BFD session reaches Up state, if the propagation of the once the BFD session reaches Up state, if the propagation of the
concatenated path failure is to resume. concatenated path failure is to resume.
6.8.18. Holding Down Sessions 6.8.18. Holding Down Sessions
A system may choose to prevent a BFD session from being established. A system MAY choose to prevent a BFD session from being established.
One possible reason might be to manage the rate at which sessions are One possible reason might be to manage the rate at which sessions are
established. This can be done by holding the session in Down or established. This can be done by holding the session in Down or
AdminDown state, as appropriate. AdminDown state, as appropriate.
There are two related mechanisms that are available to help with this There are two related mechanisms that are available to help with this
task. First, a system is required to maintain session state task. First, a system is REQUIRED to maintain session state
(including timing parameters), even when a session is down, until a (including timing parameters), even when a session is down, until a
Detection Time has passed without the receipt of any BFD Control Detection Time has passed without the receipt of any BFD Control
packets. This means that a system may take down a session and packets. This means that a system may take down a session and
transmit an arbitrarily large value in the Required Min RX Interval transmit an arbitrarily large value in the Required Min RX Interval
field to control the rate at which it receives packets. field to control the rate at which it receives packets.
Additionally, a system may transmit a value of zero for Required Min Additionally, a system MAY transmit a value of zero for Required Min
RX Interval to indicate that the remote system should send no packets RX Interval to indicate that the remote system should send no packets
whatsoever. whatsoever.
So long as the local system continues to transmit BFD Control So long as the local system continues to transmit BFD Control
packets, the remote system is obligated to obey the value carried in packets, the remote system is obligated to obey the value carried in
Required Min RX Interval. If the remote system does not receive any Required Min RX Interval. If the remote system does not receive any
BFD Control packets for a Detection Time, it resets BFD Control packets for a Detection Time, it resets
bfd.RemoteMinRxIvl to a small value and then can transmit at its own bfd.RemoteMinRxIvl to a small value and then can transmit at its own
rate. rate.
Backward Compatibility (Non-Normative) 7. Operational Considerations
Although Version 0 of this document is unlikely to have been deployed
widely, some implementors may wish to have a backward compatibility
mechanism. Note that any mechanism may be potentially used that does
not alter the protocol definition, so interoperability should not be
an issue.
The suggested mechanism described here has the property that it will
converge on version 1 if both systems implement it, even if one
system is upgraded from version 0 within a Detection Time. It will
interoperate with a system that implements only one version (or is
configured to support only one version.) A system should obviously
not perform this function if it is configured to or is only capable
of using a single version.
A BFD session will enter a "negotiation holddown" if it is configured
for automatic versioning and either has just started up, or the
session has been manually cleared. The session is set to AdminDown
state and Version 1. During the holddown period, which lasts for one
Detection Time, the system sends BFD Control packets as usual, but
ignores received packets. After the holddown time is complete, the
state transitions to Down and normal operation resumes.
When a system is not in holddown, if it doing automatic versioning
and is currently using Version 1, if any Version 0 packet is received
for the session, it switches immediately to Version 0. If it is
currently using Version 0 and a Version 1 packet is received that
indicates that the neighbor is in state AdminDown, it switches to
Version 1. If using Version 0 and a Version 1 packet is received
indicating a state other than AdminDown, the packet is ignored (per
spec.)
If the version being used is changed, the session goes down as BFD is likely to be deployed as a critical part of network
appropriate for the new version (Down state for Version 1 or Failing infrastructure. As such, care should be taken to avoid disruption.
state for Version 0.)
Contributors Obviously, any mechanism that blocks BFD packets, such as firewalls
or other policy processes, will cause BFD to fail.
Kireeti Kompella and Yakov Rekhter of Juniper Networks were also Mechanisms that control packet scheduling, such as policers, traffic
significant contributors to this document. shapers, priority queueing, etc., have the potential of impacting BFD
operations if the Detection Time is similar in scale to the scheduled
packet transmit or receive rate. The delivery of BFD packets is
time-critical, relative to the magnitude of the Detection Time, so
this may need to be taken into account in implementation and
deployment, particularly when very short Detection Times are to be
used.
Acknowledgments 8. IANA Considerations
This document was inspired by (and is intended to replace) the This document defines two registries to be administered by IANA. The
Protocol Liveness Protocol draft, written by Kireeti Kompella. first is entitled "BFD Diagnostic Codes" (see section 4.1). Initial
values for the BFD Diagnostic Code registry are given below. Further
assignments are to be made through Expert Review [IANA-
CONSIDERATIONS]. Assignments consist of a BFD Diagnostic Code name
and its associated value.
Demand mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang Value BFD Diagnostic Code Name
et al. ----- ------------------------
0 No Diagnostic
1 Control Detection Time Expired
2 Echo Function Failed
3 Neighbor Signaled Session Down
4 Forwarding Plane Reset
5 Path Down
6 Concatenated Path Down
7 Administratively Down
8 Reverse Concatenated Path Down
9-31 Reserved
The authors would also like to thank Mike Shand, John Scudder, The second registry is entitled "BFD Authentication Types" (see section
Stewart Bryant, Pekka Savola, and Richard Spencer for their 4.1). Initial values for the BFD Authentication Type registry are given
substantive input. below. Further assignments are to be made through Expert Review
[IANA-CONSIDERATIONS]. Assignments consist of a BFD Authentication Type
Code name and its associated value.
The authors would also like to thank Owen Wheeler for hosting Value BFD Diagnostic Code Name
teleconferences between the authors of this specification and ----- ------------------------
multiple vendors in order address implementation and clarity issues. 0 Reserved
1 Simple Password
2 Keyed MD5
3 Meticulous Keyed MD5
4 Keyed SHA1
5 Meticulous Keyed SHA1
6-255 Reserved
Security Considerations 9. Security Considerations
As BFD may be tied into the stability of the network infrastructure As BFD may be tied into the stability of the network infrastructure
(such as routing protocols), the effects of an attack on a BFD (such as routing protocols), the effects of an attack on a BFD
session may be very serious. This ultimately has denial-of-service session may be very serious. This ultimately has denial-of-service
effects, as links may be declared to be down (or falsely declared to effects, as links may be declared to be down (or falsely declared to
be up.) be up.)
When BFD is run over network layer protocols, a significant denial- When BFD is run over network layer protocols, a significant denial-
of-service risk is created, as BFD packets may be trivial to spoof. of-service risk is created, as BFD packets may be trivial to spoof.
When the session is directly connected across a single link When the session is directly connected across a single link
skipping to change at page 45, line 24 skipping to change at page 46, line 48
Meticulous Keyed MD5 authentication is stronger yet, as it requires Meticulous Keyed MD5 authentication is stronger yet, as it requires
the sequence number to be incremented for every packet. Replay the sequence number to be incremented for every packet. Replay
attack vulnerability is reduced due to the requirement that the attack vulnerability is reduced due to the requirement that the
sequence number must be incremented on every packet, the window size sequence number must be incremented on every packet, the window size
of acceptable packets is small, and the initial sequence number is of acceptable packets is small, and the initial sequence number is
randomized. There is still a window of attack at the beginning of randomized. There is still a window of attack at the beginning of
the session while the sequence number is being determined. This the session while the sequence number is being determined. This
authentication scheme requires an MD5 calculation on every packet authentication scheme requires an MD5 calculation on every packet
transmitted and received. transmitted and received.
Using SHA1 rather than MD5 is believed to have stronger security Using SHA1 is believed to have stronger security properties than MD5.
properties. All comments about MD5 in this section also apply to All comments about MD5 in this section also apply to SHA1.
SHA1.
If both systems randomize their Local Discriminator values at the If both systems randomize their Local Discriminator values at the
beginning of a session, replay attacks may be further mitigated, beginning of a session, replay attacks may be further mitigated,
regardless of the authentication type in use. Since the Local regardless of the authentication type in use. Since the Local
Discriminator may be changed at any time during a session, this Discriminator may be changed at any time during a session, this
mechanism may also help mitigate attacks. mechanism may also help mitigate attacks.
IANA Considerations 10. References
This document has no actions for IANA.
Normative References 10.1. Normative References
[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007. (GTSM)", RFC 5082, October 2007.
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992. 1992.
[SHA1] Eastlake, D., "US Secure Hash Algorithm 1 (SHA1)", RFC 3174,
September 2001.
10.2. Informative References
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[SHA1] "Secure Hash Standard", United States of America, National Backward Compatibility (Non-Normative)
Institute of Science and Technology, Federal Information
Processing Standard (FIPS) 180-1, April 1993. Although Version 0 of this document is unlikely to have been deployed
widely, some implementors may wish to have a backward compatibility
mechanism. Note that any mechanism may be potentially used that does
not alter the protocol definition, so interoperability should not be
an issue.
The suggested mechanism described here has the property that it will
converge on version 1 if both systems implement it, even if one
system is upgraded from version 0 within a Detection Time. It will
interoperate with a system that implements only one version (or is
configured to support only one version.) A system should obviously
not perform this function if it is configured to or is only capable
of using a single version.
A BFD session will enter a "negotiation holddown" if it is configured
for automatic versioning and either has just started up, or the
session has been manually cleared. The session is set to AdminDown
state and Version 1. During the holddown period, which lasts for one
Detection Time, the system sends BFD Control packets as usual, but
ignores received packets. After the holddown time is complete, the
state transitions to Down and normal operation resumes.
When a system is not in holddown, if it doing automatic versioning
and is currently using Version 1, if any Version 0 packet is received
for the session, it switches immediately to Version 0. If it is
currently using Version 0 and a Version 1 packet is received that
indicates that the neighbor is in state AdminDown, it switches to
Version 1. If using Version 0 and a Version 1 packet is received
indicating a state other than AdminDown, the packet is ignored (per
spec.)
If the version being used is changed, the session goes down as
appropriate for the new version (Down state for Version 1 or Failing
state for Version 0.)
Contributors
Kireeti Kompella and Yakov Rekhter of Juniper Networks were also
significant contributors to this document.
Acknowledgments
This document was inspired by (and is intended to replace) the
Protocol Liveness Protocol draft, written by Kireeti Kompella.
Demand mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang
et al.
The authors would also like to thank Mike Shand, John Scudder,
Stewart Bryant, Pekka Savola, and Richard Spencer for their
substantive input.
The authors would also like to thank Owen Wheeler for hosting
teleconferences between the authors of this specification and
multiple vendors in order address implementation and clarity issues.
Authors' Addresses Authors' Addresses
Dave Katz Dave Katz
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, California 94089-1206 USA Sunnyvale, California 94089-1206 USA
Phone: +1-408-745-2000 Phone: +1-408-745-2000
Email: dkatz@juniper.net Email: dkatz@juniper.net
Dave Ward Dave Ward
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 USA San Jose, CA 95134 USA
Phone: +1-408-526-4000 Phone: +1-408-526-4000
Email: dward@cisco.com Email: dward@cisco.com
Changes from the Previous Draft Changes from the Previous Draft
All changes are purely editorial in nature. A note was added about the availability of the timer mechanism for
congestion control. Text was added about the need for out-of-band
IPR Notice negotiation of authentication parameters. The sequence number check
was moved before the digest/hash calculation (this is a backward
The IETF has been notified of intellectual property rights claimed in compatible change.) An Operational Considerations section was added.
regard to some or all of the specification contained in this All other changes are purely editorial in nature.
document. For more information consult the online list of claimed
rights.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Full Copyright Notice
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
This document expires in September, 2008. This document expires in August, 2009.
 End of changes. 73 change blocks. 
255 lines changed or deleted 313 lines changed or added

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