draft-ietf-bfd-base-00.txt   draft-ietf-bfd-base-01.txt 
Network Working Group D. Katz Network Working Group D. Katz
Internet Draft Juniper Networks Internet Draft Juniper Networks
D. Ward D. Ward
Cisco Systems Cisco Systems
Expires: January, 2005 July, 2004 Expires: August 2005 February, 2005
Bidirectional Forwarding Detection Bidirectional Forwarding Detection
draft-ietf-bfd-base-00.txt draft-ietf-bfd-base-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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/ietf/1id-abstracts.txt 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 Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
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. Comments on this draft should be directed to rtg-bfd@ietf.org.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . 5
3.2 Operating Modes . . . . . . . . . . . . . . . . . . . . . 5 3.2 Operating Modes . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . 11
4.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 4.3 Keyed MD5 and Meticulous Keyed MD5 Authentication
Section Format . . . . . . . . . . . . . . . . . . . . . 12 Section Format . . . . . . . . . . . . . . . . . . . . . 12
5. BFD Echo Packet Format . . . . . . . . . . . . . . . . . . . 13 4.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication
6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 13 Section Format . . . . . . . . . . . . . . . . . . . . . 13
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 5. BFD Echo Packet Format . . . . . . . . . . . . . . . . . . . 14
6.2 Demultiplexing and the Discriminator Fields . . . . . . 15 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 15
6.3 The Echo Function and Asymmetry . . . . . . . . . . . . 15 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 16 6.2 BFD State Machine . . . . . . . . . . . . . . . . . . . 16
6.5 Authentication . . . . . . . . . . . . . . . . . . . . . 17 6.3 Demultiplexing and the Discriminator Fields . . . . . . 17
6.5.1 Simple Password Authentication . . . . . . . . . . 17 6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 18
6.5.2 Keyed MD5 and Meticulous Keyed MD5 Authentication 18 6.5 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 18
6.6 Functional Specifics . . . . . . . . . . . . . . . . . . 20 6.6 Authentication . . . . . . . . . . . . . . . . . . . . . 19
6.6.1 State Variables . . . . . . . . . . . . . . . . . 20 6.6.1 Enabling and Disabling Authentication . . . . . . 20
6.6.2 Timer Negotiation . . . . . . . . . . . . . . . . 23 6.6.2 Simple Password Authentication . . . . . . . . . . 20
6.6.3 Timer Manipulation . . . . . . . . . . . . . . . . 24 6.6.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 21
6.6.4 Calculating the Detection Time . . . . . . . . . . 25 6.6.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 23
6.6.5 Detecting Failures with the Echo Function . . . . 26 6.7 Functional Specifics . . . . . . . . . . . . . . . . . . 24
6.6.6 Reception of BFD Control Packets . . . . . . . . . 26 6.7.1 State Variables . . . . . . . . . . . . . . . . . 25
6.6.7 Transmitting BFD Control Packets . . . . . . . . . 28 6.7.2 Timer Negotiation . . . . . . . . . . . . . . . . 27
6.6.8 Initiation of a Poll Sequence . . . . . . . . . . 31 6.7.3 Timer Manipulation . . . . . . . . . . . . . . . . 28
6.6.9 Reception of BFD Echo Packets . . . . . . . . . . 31 6.7.4 Calculating the Detection Time . . . . . . . . . . 29
6.6.10 Transmission of BFD Echo Packets . . . . . . . . 31 6.7.5 Detecting Failures with the Echo Function . . . . 30
6.6.11 Min Rx Interval Change . . . . . . . . . . . . . 32 6.7.6 Reception of BFD Control Packets . . . . . . . . . 30
6.6.12 Min Tx Interval Change . . . . . . . . . . . . . 32 6.7.7 Transmitting BFD Control Packets . . . . . . . . . 33
6.6.13 Detect Multiplier Change . . . . . . . . . . . . 32 6.7.8 Initiation of a Poll Sequence . . . . . . . . . . 35
6.6.14 Enabling or Disabling the Echo Function . . . . . 32 6.7.9 Reception of BFD Echo Packets . . . . . . . . . . 36
6.6.15 Enabling or Disabling Demand Mode . . . . . . . . 33 6.7.10 Transmission of BFD Echo Packets . . . . . . . . 36
6.6.16 Forwarding Plane Reset . . . . . . . . . . . . . 33 6.7.11 Min Rx Interval Change . . . . . . . . . . . . . 37
6.6.17 Administrative Control . . . . . . . . . . . . . 33 6.7.12 Min Tx Interval Change . . . . . . . . . . . . . 37
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.7.13 Detect Multiplier Change . . . . . . . . . . . . 37
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 6.7.14 Enabling or Disabling the Echo Function . . . . . 37
Security Considerations . . . . . . . . . . . . . . . . . . . . 34 6.7.15 Enabling or Disabling Demand Mode . . . . . . . . 37
Normative References . . . . . . . . . . . . . . . . . . . . . 35 6.7.16 Forwarding Plane Reset . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35 6.7.17 Administrative Control . . . . . . . . . . . . . 38
Changes from the previous draft . . . . . . . . . . . . . . . . 36 6.7.18 Concatenated Paths . . . . . . . . . . . . . . . 38
IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
Security Considerations . . . . . . . . . . . . . . . . . . . . 39
Normative References . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41
Changes from the previous draft . . . . . . . . . . . . . . . . 41
IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 42
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. Currently, in order to more quickly establish alternative paths. Currently,
detection can come fairly quickly in certain circumstances when data detection can come fairly quickly in certain circumstances when data
link hardware comes into play (such as SONET alarms.) However, there link hardware comes into play (such as SONET alarms.) However, there
are media that do not provide this kind of signaling (such as are media that do not provide this kind of signaling (such as
Ethernet), and some media may not detect certain kinds of failures in Ethernet), and some media may not detect certain kinds of failures in
skipping to change at page 6, line 47 skipping to change at page 6, line 47
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 also may not be used when the path round trip time is greater mode also may not be used when the path round trip time is greater
than the desired detection time. See section 6.4 for more details. than the desired detection time. See section 6.5 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, which is outside of the scope of this document. See the environment, which is outside of the scope of this document. See the
appropriate application document for encapsulation details. appropriate application document for encapsulation details.
The BFD Control packet has a Mandatory Section and an optional The BFD Control packet has a Mandatory Section and an optional
skipping to change at page 8, line 8 skipping to change at page 8, line 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (Vers) Version (Vers)
The version number of the protocol. This document defines The version number of the protocol. This document defines
protocol version 0. protocol version 0.
Diagnostic (Diag) Diagnostic (Diag)
A diagnostic code specifying the local system's reason for the A diagnostic code specifying the local system's reason for the
last transition of the session from Up to some other state. last session state change. Values are:
Values are:
0 -- No Diagnostic 0 -- No Diagnostic
1 -- Control Detection Time Expired 1 -- Control Detection Time Expired
2 -- Echo Function Failed 2 -- Echo Function Failed
3 -- Neighbor Signaled Session Down 3 -- Neighbor Signaled Session Down
4 -- Forwarding Plane Reset 4 -- Forwarding Plane Reset
5 -- Path Down 5 -- Path Down
6 -- Concatenated Path Down 6 -- Concatenated Path Down
7 -- Administratively Down 7 -- Administratively Down
8-31 -- Reserved for future use 8 -- Reverse Concatenated Path Down
9-31 -- Reserved for future use
This field allows remote systems to determine the reason that the This field allows remote systems to determine the reason that the
previous session failed, for example. previous session failed, for example.
I Hear You (H) I Hear You (H)
This bit is set to 0 if the transmitting system either is not This bit is set to 0 if the transmitting system either is not
receiving BFD packets from the remote system, or is in the process receiving BFD packets from the remote system, or is in the process
of tearing down the BFD session for some reason. This bit is set of tearing down the BFD session for some reason. This bit is set
to 1 if the transmitting system believes it is communicating with to 1 if the transmitting system believes it is communicating with
skipping to change at page 10, line 37 skipping to change at page 10, line 37
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
3 - Meticulous Keyed MD5 3 - Meticulous Keyed MD5
4-255 - Reserved for future use 4 - Keyed SHA1
5 - Meticulous Keyed SHA1
6-255 - Reserved for future use
Auth Len Auth Len
The length, in bytes, of the authentication section, including the The length, in bytes, of the authentication section, including the
Auth Type and Auth Len fields. Auth Type and Auth Len fields.
4.2. Simple Password Authentication Section Format 4.2. Simple Password Authentication Section Format
If the Autentication Present (A) bit is set in the header, and the If the Autentication Present (A) bit is set in the header, and the
Authentication Type field contains 1 (Simple Password), the Authentication Type field contains 1 (Simple Password), the
skipping to change at page 13, line 10 skipping to change at page 13, line 10
The Sequence Number for this packet. For Keyed MD5 The Sequence Number for this packet. For Keyed MD5
Authentication, this value is incremented periodically. For Authentication, this value is incremented periodically. 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/Checksum
This field carries the 16 byte MD5 checksum for the packet. When This field carries the 16 byte MD5 checksum for the packet. When
the checksum is calculated, the shared MD5 key is stored in this the checksum is calculated, the shared MD5 key is stored in this
field. (See section 6.5.2 for details.) field. (See section 6.6.3 for details.)
4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format
If the Authentication Present (A) bit is set in the header, and the
Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous
Keyed SHA1), the Authentication Section has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key/Checksum... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type
The Authentication Type, which in this case is 4 (Keyed SHA1) or 5
(Meticulous Keyed SHA1).
Auth Len
The length of the Authentication Section, in bytes. For Keyed
SHA1 and Meticulous Keyed SHA1 authentication, the length is 28.
Auth Key ID
The authentication key ID in use for this packet. This allows
multiple keys to be active simultaneously.
Reserved
This byte must be set to zero on transmit, and ignored on receipt.
Sequence Number
The Sequence Number for this packet. For Keyed SHA1
Authentication, this value is incremented periodically. For
Meticulous Keyed SHA1 Authentication, this value is incremented
for each successive packet transmitted for a session. This
provides protection against replay attacks.
Auth Key/Checksum
This field carries the 20 byte SHA1 checksum for the packet. When
the checksum is calculated, the shared SHA1 key is stored in this
field. (See section 6.6.4 for details.)
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 document for the environment. See the appropriate application document 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
skipping to change at page 13, line 34 skipping to change at page 15, line 14
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.6.1), whereas all references to state variables (defined in section 6.7.1), whereas all references to
"the Xxx field" refer to fields in the protocol packets themselves "the Xxx field" refer to fields in the protocol packets themselves
(defined in section 4). (defined in section 4).
6.1. Overview 6.1. Overview
A system may take either an Active role or a Passive role in session A system may take either an Active role or a Passive role in session
initialization. A system taking the Active role MUST send BFD initialization. A system taking the Active role MUST send BFD
Control packets for a particular session, regardless of whether it Control packets for a particular session, regardless of whether it
has received any BFD packets for that session. A system taking the has received any BFD packets for that session. A system taking the
Passive role MUST NOT begin sending BFD packets for a particular Passive role MUST NOT begin sending BFD packets for a particular
skipping to change at page 14, line 31 skipping to change at page 16, line 6
detection time requirements for the session. detection time requirements for the session.
If both systems signal that they want to use Demand mode, the If both systems signal that they want to use Demand mode, the
transmission of BFD Control packets ceases once the session is Up. transmission of BFD Control packets ceases once the session is Up.
Other means of implying connectivity are used to keep the session Other means of implying connectivity are used to keep the session
alive. If one of the systems wishes to verify connectivity, it can alive. If one of the systems wishes to verify connectivity, it can
initiate a short exchange (a "Poll Sequence") of BFD Control packets initiate a short exchange (a "Poll Sequence") of BFD Control packets
to verify this. to verify this.
If Demand mode is not active, and no Control packets are received in If Demand mode is not active, and no Control packets are received in
the calculated detection time (see section 6.6.4), the session is the calculated detection time (see section 6.7.4), the session is
declared down, and signalled to the remote end by sending a zero declared down, and signalled to the remote end by sending a zero
value in the I Hear You field in outgoing packets. value in the I Hear You field in outgoing packets.
If sufficient Echo packets are lost, the session is declared down in If sufficient Echo packets are lost, the session is declared down in
the same manner. the same manner.
If Demand mode is active and no appropriate Control packets are If Demand mode is active and no appropriate Control packets are
received in response to a Poll Sequence, the session is declared down received in response to a Poll Sequence, the session is declared down
in the same manner. in the same manner.
skipping to change at page 15, line 6 skipping to change at page 16, line 29
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 setting its outgoing the remote end first signals that it is down (by setting its outgoing
I Hear You field to zero), thus implementing a three-way handshake. I Hear You field to zero), thus implementing a three-way handshake.
A session may be kept administratively down by always setting its A session may be kept administratively down by always setting its
outgoing I Hear You field to zero, and sending an explanatory outgoing I Hear You field to zero, and sending an explanatory
diagnostic code in the Diagnostic field. diagnostic code in the Diagnostic field.
6.2. Demultiplexing and the Discriminator Fields 6.2. BFD State Machine
The BFD state machine is quite straightforward. There are four
states through which a session normally proceeds, two for
establishing a session (Init and Up) and two for tearing down a
session (Failing and Down.) This allows a three-way handshake for
both session establishment and session teardown (assuring that both
systems are aware of all session state changes.) A fifth state
(AdminDown) exists so that a session can be administratively put down
indefinitely.
Failing state indicates that the session has just failed (or has just
been created.) A session remains in Failing state until the remote
system indicates that it agrees that the session is down by sending a
BFD Control packet with I Hear You = 0. When this occurs, the
session advances to the Down state.
Down state means that the session is down and both systems know as
much. A session will remain in Down state only until the next BFD
Control packet is received from the remote system. If that packet
signals I Hear You = 0, the session advances to Init state; if that
packet signals I Hear You = 1, the session advances to Up state.
Init state means that the remote system is communicating, and the
local system desires to bring the session up, but the remote system
does not yet realize it. A session will remain in Init state until
either a BFD Control Packet is received that is signalling I Hear You
= 1 (in which case the session advances to Up state) or until the
detection time expires, meaning that communication with the remote
system has been lost (in which case the session advances to Failing
state.)
Up state means that the BFD session has successfully been
established, and implies that connectivity between the systems is
working. The session will remain in the Up state until either
connectivity fails, or the session is taken down administratively.
If either the remote system signals I Hear You = 0, or the detection
time expires, the session advances to Failing state.
6.3. Demultiplexing and the Discriminator Fields
Since multiple BFD sessions may be running between two systems, there Since multiple BFD sessions may be running between two systems, there
needs to be a mechanism for demultiplexing received BFD packets to needs to be a mechanism for demultiplexing received BFD packets to
the proper session. the proper session.
Each system MUST choose an opaque discriminator value that identifies Each system MUST choose an opaque discriminator value that identifies
each session, and which MUST be unique among all BFD sessions on the each session, and which MUST be unique among all BFD sessions on the
system. The local discriminator is sent in the My Discriminator system. The local discriminator is sent in the My Discriminator
field in the BFD Control packet, and is echoed back in the Your field in the BFD Control packet, and is echoed back in the Your
Discriminator field of packets sent from the remote end. Discriminator field of packets sent from the remote end.
skipping to change at page 15, line 36 skipping to change at page 18, line 5
Discriminator is zero) is application-dependent, and is thus outside Discriminator is zero) is application-dependent, and is thus outside
the scope of this specification. the scope of this specification.
Note that it is permissible for a system to change its discriminator Note that it is permissible for a system to change its discriminator
during a session (without affecting the session state), since only during a session (without affecting the session state), since only
that system uses its discriminator for demultiplexing purposes (by that system uses its discriminator for demultiplexing purposes (by
having the other system reflect it back.) The implications on an having the other system reflect it back.) The implications on an
implementation for changing the discriminator value is outside the implementation for changing the discriminator value is outside the
scope of this specification. scope of this specification.
6.3. The Echo Function and Asymmetry 6.4. The Echo Function and Asymmetry
The Echo function can be run independently in each direction between The Echo function can be run independently in each direction between
a pair of systems. For whatever reason, a system may advertise that a pair of systems. For whatever reason, a system may advertise that
it is willing to receive (and loop back) Echo packets, but may not it is willing to receive (and loop back) Echo packets, but may not
wish to ever send any. The fact that a system is sending Echo wish to ever send any. The fact that a system is sending Echo
packets is not directly signalled to the system looping them back. packets is not directly signalled to the system looping them back.
When a system is using the Echo function, it is advantageous to When a system is using the Echo function, it is advantageous to
choose a sedate transmission rate for Control packets, since liveness choose a sedate transmission rate for Control packets, since liveness
detection is being handled by the Echo packets. This can be detection is being handled by the Echo packets. This can be
controlled by manipulating the Desired Min TX Interval field (see controlled by manipulating the Desired Min TX Interval field (see
section 6.6.3.) section 6.7.3.)
If the Echo function is only being run in one direction, the system If the Echo function is only being run in one direction, the system
not running the Echo function will more likely wish to send fairly not running the Echo function will more likely wish to send fairly
rapid Control packets in order to achieve its desired detection time. rapid Control packets in order to achieve its desired detection time.
Since BFD allows independent transmission rates in each direction, Since BFD allows independent transmission rates in each direction,
this is easily accomplished. this is easily accomplished.
A system SHOULD always advertise the lowest value of Required Min RX A system SHOULD always advertise the lowest value of Required Min RX
Interval and Required Min Echo RX Interval that it can under the Interval and Required Min Echo RX Interval that it can under the
circumstances, to give the other system more freedom in choosing its circumstances, to give the other system more freedom in choosing its
transmission rate. Note that a system is committing to be able to transmission rate. Note that a system is committing to be able to
receive both streams of packets at the rate it advertises, so this receive both streams of packets at the rate it advertises, so this
should be taken into account when choosing the values to advertise. should be taken into account when choosing the values to advertise.
6.4. Demand Mode 6.5. Demand Mode
Demand mode is negotiated by virtue of both systems setting the Demand mode is negotiated by virtue of both systems setting the
Demand (D) bit in its BFD Control packets. Both systems must request Demand (D) bit in its BFD Control packets. Both systems must request
Demand mode for it to become active. Demand mode for it to become active.
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
skipping to change at page 16, line 48 skipping to change at page 19, line 15
Control packet of its own, with the Poll (P) bit clear, and the Final Control packet of its own, with the Poll (P) bit clear, and the Final
(F) bit set. The receipt of a reply to a Poll terminates the Poll (F) bit set. The receipt of a reply to a Poll terminates the Poll
Sequence. If no response is received to a Poll, the Poll is repeated Sequence. If no response is received to a Poll, the Poll is repeated
until the detection time expires, at which point the session is until the detection time expires, at which point the session is
declared to be down. declared to be down.
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.6.8 for more details. 6.7.8 for more details.
Note that this mechanism requires that the detection time negotiated Note that this mechanism requires that the detection time negotiated
is greater than the round trip time between the two systems, or the is greater than the round trip time between the two systems, or the
Poll mechanism will always fail. Enforcement of this requirement is Poll mechanism will always fail. Enforcement of this requirement is
outside the scope of this specification. outside the scope of this specification.
Demand mode MAY be enabled or disabled at any time by setting or Demand mode MAY be enabled or disabled at any time by setting or
clearing the Demand (D) bit in the BFD Control packet, without clearing the Demand (D) bit in the BFD Control packet, without
affecting the BFD session state. affecting the BFD session state.
Because the underlying detection mechanism is unspecified, and may Because the underlying detection mechanism is unspecified, and may
differ between the two systems, the overall detection time differ between the two systems, the overall detection time
characteristics of the path will not be fully known to either system. characteristics of the path will not be fully known to either system.
The total detection time for a particular system is the sum of the The total detection time for a particular system is the sum of the
time prior to the initiation of the Poll Sequence, plus the time prior to the initiation of the Poll Sequence, plus the
calculated detection time. calculated detection time.
6.5. Authentication 6.6. 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.
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.6.6. reception rules described in section 6.7.6.
6.5.1. Simple Password Authentication Implementations MUST support SHA1 authentication. Other froms of
authentication are optional.
6.6.1. Enabling and Disabling Authentication
It may be desirable to enable or disable authentication on a session
without disturbing the session state. The exact mechanism for doing
so is outside the scope of this specification. However, it is useful
to point out some issues in supporting this mechanism.
In a simple implementation, a BFD session will fail when
authentication is either turned on or turned off, because the packet
acceptance rules essentially require the local and remote machines to
do so in a more or less synchronized fashion (within the detect
time)--a packet with authentication will only be accepted if
authentication is "in use" (and likewise packets without
authentication.
One possible approach is to build an implementation such that
authentication is configured, but not considered "in use" until the
first packet containing a matching authentication section is received
(providing the necessary synchronization.) Likewise, authentication
could be configured off, but still considered "in use" until the
receipt of the first packet without the authentication section.
In order to avoid security risks, implementations using this method
should only allow the authentication state to be changed once without
some form of intervention (so that authentication cannot be turned on
and off repeatedly simply based on the receipt of BFD Control packets
from remote systems.)
6.6.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.
Transmission Using Simple Password Authentication Transmission Using Simple Password Authentication
skipping to change at page 18, line 30 skipping to change at page 21, line 25
password, the received packet MUST be discarded. password, the received packet MUST be discarded.
If the Auth Len field is not equal to the length of the password If the Auth Len field is not equal to the length of the password
selected by the Key ID, plus three, the packet MUST be discarded. selected by the Key ID, plus three, the packet MUST be discarded.
If the Password field does not match the password selected by the If the Password field does not match the password selected by the
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.5.2. Keyed MD5 and Meticulous Keyed MD5 Authentication 6.6.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
checksum calculated over the outgoing BFD Control packet, but the Key [MD5] checksum calculated over the outgoing BFD Control packet, but
itself is not carried in the packet. To help avoid replay attacks, a the Key itself is not carried in the packet. To help avoid replay
sequence number is also carried in each packet. For Keyed MD5, the attacks, a sequence number is also carried in each packet. For Keyed
sequence number is occasionally incremented. For Meticulous Keyed MD5, the sequence number is occasionally incremented. For Meticulous
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 checksum including the selected key
matches that carried in the packet, and if the sequence number is matches that carried in the packet, and if the sequence number is
greater than or equal to the last sequence number received (for Keyed greater than or equal to the last sequence number received (for Keyed
MD5), or strictly greater than the last sequence number received (for MD5), 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.XmitMD5Seq.
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/Checksum field. An MD5 checksum MUST be calculated over the
entire BFD control packet. The resulting checksum MUST be stored entire BFD control packet. The resulting checksum MUST be stored
in the Auth Key/Checksum field prior to transmission (replacing in the Auth Key/Checksum field prior to transmission (replacing
the secret key, which MUST NOT be carried in the packet.) the secret key, which MUST NOT be carried in the packet.)
For Keyed MD5, bfd.XmitMD5Seq 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.XmitMD5Seq 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.XmitMD5Seq 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.
For Meticulous Keyed MD5, bfd.XmitMD5Seq MUST be incremented in a For Meticulous Keyed MD5, bfd.XmitAuthSeq MUST be incremented in a
circular fashion (when treated as an unsigned 32 bit value.) circular fashion (when treated as an unsigned 32 bit value.)
Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication
If the received BFD Control packet does not contain an If the received BFD Control packet does not contain an
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
skipping to change at page 19, line 48 skipping to change at page 22, line 44
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 Replace the contents of the Auth Key/Checksum field with the
authentication key selected by the received Auth Key ID field. If 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 MD5 checksum of the entire BFD Control packet is not equal to
the received value of the Auth Key/Checksum field, the received the received value of the Auth Key/Checksum field, the received
packet MUST be discarded. packet MUST be discarded.
If bfd.MD5SeqKnown 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.RcvMD5Seq to bfd.RcvMD5Seq+(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.RcvMD5Seq+1 to Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to
bfd.RcvMD5Seq+(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.MD5SeqKnown is 0), bfd.MD5SeqKnown MUST be set to Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to
1, bfd.RcvMD5Seq MUST be set to the value of the received Sequence 1, bfd.RcvAuthSeq MUST be set to the value of the received
Number field, and the received packet MUST be accepted. Sequence Number field, and the received packet MUST be accepted.
6.6. Functional Specifics 6.6.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication
The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms
are very similar to those used in other protocols. In these methods
of authentication, one or more secret keys (with corresponding Key
IDs) are configured in each system. One of the Keys is included in a
SHA1 [SHA1] checksum calculated over the outgoing BFD Control packet,
but the Key itself is not carried in the packet. To help avoid
replay attacks, a sequence number is also carried in each packet.
For Keyed SHA1, the sequence number is occasionally incremented. For
Meticulous Keyed SHA1, the sequence number is incremented on every
packet.
The receiving system accepts the packet if the Key ID matches one of
the configured Keys, a SHA1 checksum including the selected key
matches that carried in the packet, and if the sequence number is
greater than or equal to the last sequence number received (for Keyed
SHA1), or strictly greater than the last sequence number received
(for Meticulous Keyed SHA1.)
Transmission Using Keyed SHA1 and Meticulous Keyed SHA1
Authentication
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
ID field MUST be set to the ID of the current authentication key.
The Sequence Number field MUST be set to bfd.XmitAuthSeq.
The current authentication key value MUST be placed into the Auth
Key/Checksum field. A SHA1 checksum MUST be calculated over the
entire BFD control packet. The resulting checksum MUST be stored
in the Auth Key/Checksum field prior to transmission (replacing
the secret key, which MUST NOT be carried in the packet.)
For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular
fashion (when treated as an unsigned 32 bit value.)
bfd.XmitAuthSeq SHOULD be incremented when the session state
changes, or when the transmitted BFD Control packet carries
different contents than the previously transmitted packet. The
decision as to when to increment bfd.XmitAuthSeq is outside the
scope of this specification. See the section entitled "Security
Considerations" below for a discussion.
For Meticulous Keyed SHA1, bfd.XmitAuthSeq MUST be incremented in
a circular fashion (when treated as an unsigned 32 bit value.)
Receipt Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication
If the received BFD Control packet does not contain an
Authentication Section, or the Auth Type is not correct (4 for
Keyed SHA1, or 5 for Meticulous Keyed SHA1), then the received
packet MUST be discarded.
If the Auth Key ID field does not match the ID of a configured
authentication key, the received packet MUST be discarded.
If the Auth Len field is not equal to 28, the packet MUST be
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
Keyed SHA1, if the Sequence Number lies outside of the range of
bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when
treated as an unsigned 32 bit circular number space), the received
packet MUST be discarded. For Meticulous Keyed SHA1, if the
Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to
bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an
unsigned 32 bit circular number space, the received packet MUST be
discarded.
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to
1, bfd.RcvAuthSeq MUST be set to the value of the received
Sequence Number field, and the received packet MUST be accepted.
6.7. 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 signalled its willingness to session is Up and the other system has signalled its willingness to
loop back Echo packets. loop back Echo packets.
When a system is said to have "Demand mode active," it means that When a system is said to have "Demand mode active," it means that
bfd.DemandModeDesired is 1 in the local system (see State Variables bfd.DemandModeDesired is 1 in the local system (see State Variables
below), the remote system is signalling with the Demand (D) bit set, below), the remote system is signalling with the Demand (D) bit set,
and that the session is Up. and that the session is Up.
6.6.1. State Variables 6.7.1. State Variables
A minimum amount of information about a session needs to be tracked A minimum amount of information about a session needs to be tracked
in order to achieve the elements of procedure described here. The in order to achieve the elements of procedure described here. The
following is a set of state variables that are helpful in describing following is a set of state variables that are helpful in describing
the mechanisms of BFD. Any means of tracking this state may be used the mechanisms of BFD. Any means of tracking this state may be used
so long as the protocol behaves as described. so long as the protocol behaves as described.
All state variables in this specification are of the form "bfd.Xx" All state variables in this specification are of the form "bfd.Xx"
and should not be confused with fields carried in the protocol and should not be confused with fields carried in the protocol
packets, which are always spelled out to match the names in section packets, which are always spelled out to match the names in section
skipping to change at page 21, line 11 skipping to change at page 25, line 38
The perceived state of the session (Init, Up, Failing, Down, or The perceived state of the session (Init, Up, Failing, Down, or
AdminDown.) The exact action taken when the session state AdminDown.) The exact action taken when the session state
changes is outside the scope of this specification, though it changes is outside the scope of this specification, though it
is expected that this state change (particularly to and from Up is expected that this state change (particularly to and from Up
state) is reported to other components of the system. This state) is reported to other components of the system. This
variable MUST be initialized to Failing. variable MUST be initialized to Failing.
bfd.LocalDiscr bfd.LocalDiscr
The local discriminator for this BFD session, used to uniquely The local discriminator for this BFD session, used to uniquely
identify it. It MUST be unique on this system, and nonzero. identify it. It MUST be unique across all BFD sessions on this
It MAY be set to a random (but still unique) value to improve system, and nonzero. It SHOULD be set to a random (but still
security. The value is otherwise outside the scope of this unique) value to improve security. The value is otherwise
specification. outside the scope of this specification.
bfd.RemoteDiscr bfd.RemoteDiscr
The remote discriminator for this BFD session. This is the The remote discriminator for this BFD session. This is the
discriminator chosen by the remote system, and is totally discriminator chosen by the remote system, and is totally
opaque to the local system. This MUST be initialized to zero. opaque to the local system. This MUST be initialized to zero.
bfd.RemoteHeard bfd.RemoteHeard
This variable is set to 1 if the local system is actively This variable is set to 1 if the local system is actively
receiving BFD packets from the remote system, and is set to 0 receiving BFD packets from the remote system, and is set to 0
if the local system has not received BFD packets recently if the local system has not received BFD packets recently
(within the detection time) or if the local system is (within the detection time) or if the local system is
attempting to tear down the BFD session. This MUST be attempting to tear down the BFD session. This MUST be
initialized to zero. initialized to zero.
bfd.LocalDiag bfd.LocalDiag
The diagnostic code specifying the reason the local session The diagnostic code specifying the reason for the most recent
state most recently transitioned from Up to some other state. local session state chage. This MUST be initialized to zero
This MUST be initialized to zero (No Diagnostic.) (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. The actual interval is negotiated between the
two systems. This MUST be initialized to a value of at least two systems. This MUST be initialized to a value of at least
one second (1,000,000 microseconds) according to the rules one second (1,000,000 microseconds) according to the rules
described in section 6.6.3. The setting of this variable is described in section 6.7.3. The setting of this variable is
otherwise outside the scope of this specification. 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. The setting of this
variable is outside the scope of this specification. variable is outside the scope of this specification.
bfd.DemandModeDesired bfd.DemandModeDesired
Set to 1 if the local system wishes to use Demand mode, or 0 if Set to 1 if the local system wishes to use Demand mode, or 0 if
not. not.
bfd.DetectMult bfd.DetectMult
The desired detect time multiplier for BFD Control packets. The desired detect time multiplier for BFD Control packets.
The negotiated Control packet transmission interval, multiplied The negotiated Control packet transmission interval, multiplied
by this variable, will be the detection time for this session by this variable, will be the detection time for this session
(as seen by the remote system.) This variable MUST be a (as seen by the remote system.) This variable MUST be a
nonzero integer, and is otherwise outside the scope of this nonzero integer, and is otherwise outside the scope of this
specification. See section 6.6.4 for further information. specification. See section 6.7.4 for further information.
bfd.AuthType bfd.AuthType
The authentication type in use for this session, as defined in The authentication type in use for this session, as defined in
section 4.1, or zero if no authentication is in use. section 4.1, or zero if no authentication is in use.
bfd.RcvMD5Seq bfd.RcvAuthSeq
A 32 bit unsigned integer containing the next sequence number A 32 bit unsigned integer containing the next sequence number
for keyed MD5 authentication expected to be received. The for keyed MD5 or SHA1 authentication expected to be received.
initial value is unimportant. The initial value is unimportant.
bfd.XmitMD5Seq bfd.XmitAuthSeq
A 32 bit unsigned integer containing the next sequence number A 32 bit unsigned integer containing the next sequence number
for keyed MD5 authentication to be transmitted. This variable for keyed MD5 or SHA1 authentication to be transmitted. This
MUST be initialized to a random 32 bit value. variable MUST be initialized to a random 32 bit value.
bfd.MD5SeqKnown bfd.AuthSeqKnown
Set to 1 if the next sequence number for keyed MD5 Set to 1 if the next sequence number for keyed MD5 or SHA1
authentication expected to be received is known, or 0 if it is authentication expected to be received is known, or 0 if it is
not known. This variable MUST be initialized to zero. not known. This variable MUST be initialized to zero.
This variable MUST be set to zero after no packets have been This variable MUST be set to zero after no packets have been
received on this session for at least twice the Detection Time. received on this session for at least twice the Detection Time.
This ensures that the MD5 sequence number can be resynchronized This ensures that the sequence number can be resynchronized if
if the remote system restarts. the remote system restarts.
6.6.2. Timer Negotiation 6.7.2. Timer Negotiation
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 are continuously negotiated, and thus and the session detection time are continuously negotiated, and thus
may be changed at any time. The negotiation and time values are may be changed at any time. The negotiation and time values are
independent in each direction for each session. Packets are always independent in each direction for each session. Packets are always
periodically transmitted in Asynchronous mode, and are periodically periodically transmitted in Asynchronous mode, and are periodically
transmitted during Poll Sequences when in Demand mode. transmitted during Poll Sequences when in Demand mode.
Each system reports in the BFD Control packet how rapidly it would Each system reports in the BFD Control packet how rapidly it would
like to transmit BFD packets, as well as how rapidly it is prepared like to transmit BFD packets, as well as how rapidly it is prepared
skipping to change at page 24, line 8 skipping to change at page 28, line 37
next paragraph, once such an extra packet has been transmitted, a next paragraph, once such an extra packet has been transmitted, a
system MUST NOT send another BFD Control packet until the next system MUST NOT send another BFD Control packet until the next
scheduled transmission. scheduled transmission.
If a BFD Control packet is received with the Poll (P) bit set to 1, If a BFD Control packet is received with the Poll (P) bit set to 1,
the receiving system MUST transmit a BFD Control packet with the Poll the receiving system MUST transmit a BFD Control packet with the Poll
(P) bit clear and the Final (F) bit set as soon as practicable, (P) bit clear and the Final (F) bit set as soon as practicable,
without respect to the transmission timer or any other transmission without respect to the transmission timer or any other transmission
limitations, and without respect to whether Demand mode is active. limitations, and without respect to whether Demand mode is active.
6.6.3. Timer Manipulation 6.7.3. Timer Manipulation
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 Demand mode is active, and either bfd.DesiredMinTxInterval is If Demand mode is active, and either bfd.DesiredMinTxInterval is
changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST
be initiated (see section 6.6.8). be initiated (see section 6.7.8).
If Demand mode is not active, and either bfd.DesiredMinTxInterval is If Demand mode is not active, and either bfd.DesiredMinTxInterval is
changed or bfd.RequiredMinRxInterval is changed, all subsequent changed or bfd.RequiredMinRxInterval is changed, all subsequent
transmitted Control packets MUST be sent with the Poll (P) bit set transmitted Control packets MUST be sent with the Poll (P) bit set
until a packet is received with the Final (F) bit set. until a packet is received with the Final (F) bit set (except for
those packets sent in response to received Polls.)
If bfd.DesiredMinTxInterval is increased, the actual transmission If bfd.DesiredMinTxInterval is increased, the actual transmission
interval used MUST NOT change until a Control packet is received with interval used MUST NOT change until a Control packet is received with
the Final (F) bit set. This is to ensure that the remote system the Final (F) bit set. This is to ensure that the remote system
updates its Detect Time before the transmission interval increases. updates its Detect Time before the transmission interval increases.
If bfd.RequiredMinRxInterval is reduced, the calculated detection If bfd.RequiredMinRxInterval is reduced, the calculated detection
time for the remote system MUST NOT change until a Control packet is time for the remote system MUST NOT change until a Control packet is
received with the Final (F) bit set. This is to ensure that the received with the Final (F) bit set. This is to ensure that the
remote system is transmitting packets at the higher rate (and those remote system is transmitting packets at the higher rate (and those
skipping to change at page 25, line 5 skipping to change at page 29, line 31
(1,000,000 microseconds.) This is intended to ensure that the (1,000,000 microseconds.) This is intended to ensure that the
bandwidth consumed by BFD sessions that are not Up is negligible, bandwidth consumed by BFD sessions that are not Up is negligible,
particularly in the case where a neighbor may not be running BFD. particularly in the case where a neighbor may not be running BFD.
When the Echo function is active, a system SHOULD set When the Echo function is active, a system SHOULD set
bfd.DesiredMinTxInterval to a value of not less than one second bfd.DesiredMinTxInterval to a value of not less than one second
(1,000,000 microseconds.) This is intended to keep BFD Control (1,000,000 microseconds.) This is intended to keep BFD Control
traffic at a negligible level, since the actual detection function is traffic at a negligible level, since the actual detection function is
being performed using BFD Echo packets. being performed using BFD Echo packets.
6.6.4. Calculating the Detection Time 6.7.4. Calculating the Detection Time
The Detection Time (the period of time without receiving BFD packets The Detection Time (the period of time without receiving BFD packets
after which the session is determined to have failed) is not carried after which the session is determined to have failed) is not carried
explicitly in the protocol. Rather, it is calculated independently explicitly in the protocol. Rather, it is calculated independently
in each direction by the receiving system based on the negotiated in each direction by the receiving system based on the negotiated
transmit interval and the detection multiplier. Note that, in transmit interval and the detection multiplier. Note that, in
Asynchronous mode, there may be different detection times in each Asynchronous mode, there may be different detection times in each
direction. direction.
The calculation of the Detection Time is slightly different when in The calculation of the Detection Time is slightly different when in
skipping to change at page 25, line 52 skipping to change at page 30, line 31
If Demand mode is active, and a period of time equal to the Detection If Demand mode is active, and a period of time equal to the Detection
Time passes after the initiation of a Poll Sequence (the transmission Time passes after the initiation of a Poll Sequence (the transmission
of the first BFD Control packet with the Poll bit set), the session of the first BFD Control packet with the Poll bit set), the session
has gone down--the local system MUST set bfd.SessionState to Failing, has gone down--the local system MUST set bfd.SessionState to Failing,
bfd.RemoteHeard to zero, and bfd.LocalDiag to 1 (Control Detection bfd.RemoteHeard to zero, and bfd.LocalDiag to 1 (Control Detection
Time Expired.) Time Expired.)
(Note that a packet is considered to have been received, for the (Note that a packet is considered to have been received, for the
purposes of Detection Time expiration, only if it has not been purposes of Detection Time expiration, only if it has not been
"discarded" according to the rules of section 6.6.6.) "discarded" according to the rules of section 6.7.6.)
6.6.5. Detecting Failures with the Echo Function 6.7.5. Detecting Failures with the Echo Function
When the Echo function is active and a sufficient number of Echo When the Echo function is active and a sufficient number of Echo
packets have not arrived as they should, the session has gone packets have not arrived as they should, the session has gone
down--the local system MUST set bfd.SessionState to Failing, down--the local system MUST set bfd.SessionState to Failing,
bfd.RemoteHeard to zero, and bfd.LocalDiag to 2 (The Echo Function bfd.RemoteHeard to zero, and bfd.LocalDiag to 2 (The Echo Function
Failed.) Failed.)
The means by which the Echo function failures are detected is outside The means by which the Echo function failures are detected is outside
of the scope of this specification. Any means which will detect a of the scope of this specification. Any means which will detect a
communication failure is acceptable. communication failure is acceptable.
6.6.6. Reception of BFD Control Packets 6.7.6. Reception of BFD Control Packets
When a BFD Control packet is received, the following procedure MUST When a BFD Control packet is received, the following procedure MUST
be followed, in the order specified. If the packet is discarded be followed, in the order specified. If the packet is discarded
according to these rules, processing of the packet MUST cease at that according to these rules, processing of the packet MUST cease at that
point. point.
If the version number is not correct (0), the packet MUST be If the version number is not correct (0), the packet MUST be
discarded. discarded.
If the Length field is less than the minimum correct value (24 if If the Length field is less than the minimum correct value (24 if
skipping to change at page 27, line 15 skipping to change at page 31, line 44
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
rules of section 6.5, based on the authentication type in use rules of section 6.6, based on the authentication type in use
(bfd.AuthType.) This may cause the packet to be discarded. (bfd.AuthType.) This may cause the packet to be discarded.
Set bfd.RemoteDiscr to the value of My Discriminator. Set bfd.RemoteDiscr to the value of My Discriminator.
If the Required Min Echo RX Interval field is zero, the If the Required Min Echo RX Interval field is zero, the
transmission of Echo packets, if any, MUST cease. transmission of Echo packets, if any, MUST cease.
If Demand mode is active, a Poll Sequence is being transmitted by If Demand mode is active, a Poll Sequence is being transmitted by
the local system, and the Final (F) bit in the received packet is the local system, and the Final (F) bit in the received packet is
set, the Poll Sequence MUST be terminated. set, the Poll Sequence MUST be terminated.
If Demand mode is not active, the Final (F) bit in the received If Demand mode is not active, the Final (F) bit in the received
packet is set, and the local system has been transmitting packets packet is set, and the local system has been transmitting packets
with the Poll (P) bit set, the Poll (P) bit MUST be set to zero in with the Poll (P) bit set, the Poll (P) bit MUST be set to zero in
subsequent transmitted packets. subsequent transmitted packets.
Update the Detection Time as described in section 6.6.4. Update the Detection Time as described in section 6.7.4.
If bfd.SessionState is Down If bfd.SessionState is Down
Set bfd.RemoteHeard to 1 Set bfd.RemoteHeard to 1
If I Hear You is zero If I Hear You is zero
Set bfd.SessionState to Init Set bfd.SessionState to Init
Else Else
Set bfd.SessionState to Up Set bfd.SessionState to Up
Else if bfd.SessionState is AdminDown Else if bfd.SessionState is AdminDown
Discard the packet Discard the packet
skipping to change at page 28, line 11 skipping to change at page 32, line 39
Else if bfd.SessionState is Up Else if bfd.SessionState is Up
If I Hear You is zero If I Hear You is zero
Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.LocalDiag to 3 (Neighbor signaled session down)
Set bfd.SessionState to Failing Set bfd.SessionState to Failing
Set bfd.RemoteHeard to 0 Set bfd.RemoteHeard to 0
Else if bfd.SessionState is Failing Else if bfd.SessionState is Failing
If I Hear You is zero, set bfd.SessionState to Down If I Hear You is zero, set bfd.SessionState to Down
Update the transmit interval as described in section 6.6.2. Update the transmit interval as described in section 6.7.2.
If the Demand (D) bit is set and bfd.DemandModeDesired is 1, If the Demand (D) bit is set and bfd.DemandModeDesired is 1,
and bfd.SessionState is Up, Demand mode is active. and bfd.SessionState is Up, Demand mode is active.
If the Demand (D) bit is clear or bfd.DemandModeDesired is 0, If the Demand (D) bit is clear or bfd.DemandModeDesired is 0,
or bfd.SessionState is not Up, Demand mode is not or bfd.SessionState is not Up, Demand mode is not
active. active.
If the Poll (P) bit is set, send a BFD Control packet to the If the Poll (P) bit is set, send a BFD Control packet to the
remote system with the Poll (P) bit clear, and the Final (F) bit remote system with the Poll (P) bit clear, and the Final (F) bit
set. set.
If the packet was not discarded, it has been received for purposes of If the packet was not discarded, it has been received for purposes of
the Detection Time expiration rules in section 6.6.4. the Detection Time expiration rules in section 6.7.4.
6.6.7. Transmitting BFD Control Packets 6.7.7. Transmitting BFD Control Packets
BFD Control packets MUST be transmitted periodically at the rate BFD Control packets MUST be transmitted periodically at the rate
determined according to section 6.6.2, except as specified in this determined according to section 6.7.2, except as specified in this
section. section.
The transmit interval MUST be recalculated whenever The transmit interval MUST be recalculated whenever
bfd.DesiredMinTxInterval changes, or whenever the received Required bfd.DesiredMinTxInterval changes, or whenever the received Required
Min RX Interval changes, and is equal to the greater of those two Min RX Interval changes, and is equal to the greater of those two
values. See sections 6.6.2 and 6.6.3 for details on transmit timers. values. See sections 6.7.2 and 6.7.3 for details on transmit timers.
A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is
zero and the system is taking the Passive role. zero and the system is taking the Passive role.
A system MUST NOT periodically transmit BFD Control packets if Demand A system MUST NOT periodically transmit BFD Control packets if Demand
mode is active and a Poll Sequence is not being transmitted. mode is active and a Poll Sequence is not being transmitted.
A system MUST send a BFD Control packet in response to a received BFD A system MUST send a BFD Control packet in response to a received BFD
Control Packet with the Poll (P) bit set. The packet sent in Control Packet with the Poll (P) bit set. The packet sent in
response MUST NOT have the Poll (P) bit set, and MUST have the Final response MUST NOT have the Poll (P) bit set, and MUST have the Final
(F) bit set. (F) bit set. A system MAY limit the rate at which such packets are
transmitted. If rate limiting is in effect, the advertised value of
Desired Min TX Interval must be greater than or equal to the interval
between transmitted packets imposed by the rate limiting function.
A single BFD Control packet SHOULD be transmitted between normally A single BFD Control packet SHOULD be transmitted between normally
scheduled transmissions when the contents of that packet would differ scheduled transmissions when the contents of that packet would differ
from those in the previously transmitted packet (other than the Poll from those in the previously transmitted packet (other than the Poll
and Final bits) in order to more rapidly communicate a change in and Final bits) in order to more rapidly communicate a change in
state. state.
The contents of transmitted BFD Control packets MUST be set as The contents of transmitted BFD Control packets MUST be set as
follows: follows:
skipping to change at page 29, line 30 skipping to change at page 34, line 16
Set to bfd.RemoteHeard. Set to bfd.RemoteHeard.
Demand (D) Demand (D)
Set to bfd.DemandModeDesired. Set to bfd.DemandModeDesired.
Poll (P) Poll (P)
Set to 1 if the local system is sending a Poll Sequence or is Set to 1 if the local system is sending a Poll Sequence or is
required to do so according to the requirements of section 6.6.3, required to do so according to the requirements of section 6.7.3,
or 0 if not. or 0 if not.
Final (F) Final (F)
Set to 1 if the local system is responding to a Control packet Set to 1 if the local system is responding to a Control packet
received with the Poll (P) bit set, or 0 if not. received with the Poll (P) bit set, or 0 if not.
Control Plane Independent (C) Control Plane Independent (C)
Set to 1 if the local system's BFD implementation is independent Set to 1 if the local system's BFD implementation is independent
skipping to change at page 31, line 7 skipping to change at page 35, line 35
Required Min Echo RX Interval Required Min Echo RX Interval
Set to the minimum required Echo packet receive interval for this Set to the minimum required Echo packet receive interval for this
session. If this field is set to zero, the local system is session. If this field is set to zero, the local system is
unwilling or unable to loop back BFD Echo packets to the remote unwilling or unable to loop back BFD Echo packets to the remote
system, and the remote system will not send Echo packets. system, and the remote system will not send Echo packets.
Authentication Section Authentication Section
Included and set according to the rules in section 6.5 if Included and set according to the rules in section 6.6 if
authentication is in use (bfd.AuthType is nonzero.) Otherwise authentication is in use (bfd.AuthType is nonzero.) Otherwise
this section is not present. this section is not present.
6.6.8. Initiation of a Poll Sequence 6.7.8. Initiation of a Poll Sequence
If Demand mode is active, a Poll Sequence MUST be initiated whenever If Demand mode is active, a Poll Sequence MUST be initiated whenever
the contents of the next BFD Control packet to be sent would be the contents of the next BFD Control packet to be sent would be
different than the contents of the previous packet, with the different than the contents of the previous packet, with the
exception of the Poll (P) and Final (F) bits. This ensures that exception of the Poll (P) and Final (F) bits. This ensures that
parameter changes are transmitted to the remote system. Note that if parameter changes are transmitted to the remote system. Note that if
the I Hear You (H) bit is changing to zero, the session is going down the I Hear You (H) bit is changing to zero, the session is going down
and Demand mode will no longer be active. and Demand mode will no longer be active.
If Demand mode is active, a Poll Sequence SHOULD be initiated If Demand mode is active, a Poll Sequence SHOULD be initiated
whenever the system feels the need to verify connectivity with the whenever the system feels the need to verify connectivity with the
remote system. The conditions under which this is desirable are remote system. The conditions under which this is desirable are
outside the scope of this specification. outside the scope of this specification.
If a Poll Sequence is being sent, and a new Poll Sequence is If a Poll Sequence is being sent, and a new Poll Sequence is
initiated due to one of the above conditions, the detection interval initiated due to one of the above conditions, the detection interval
MUST be restarted in order to ensure that a full Poll Sequence is MUST be restarted in order to ensure that a full Poll Sequence is
transmitted under the new conditions. transmitted under the new conditions.
6.6.9. Reception of BFD Echo Packets 6.7.9. Reception of BFD Echo Packets
A received BFD Echo packet MUST be demultiplexed to the appropriate A received BFD Echo packet MUST be demultiplexed to the appropriate
session for processing. A means of detecting missing Echo packets session for processing. A means of detecting missing Echo packets
MUST be implemented, which most likely involves processing of the MUST be implemented, which most likely involves processing of the
Echo packets that are received. The processing of received Echo Echo packets that are received. The processing of received Echo
packets is otherwise outside the scope of this specification. packets is otherwise outside the scope of this specification.
6.6.10. Transmission of BFD Echo Packets 6.7.10. Transmission of BFD Echo Packets
BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not
Up. BFD Echo packets MUST NOT be transmitted unless the last BFD Up. BFD Echo packets MUST NOT be transmitted unless the last BFD
Control packet received from the remote system contains a nonzero Control packet received from the remote system contains a nonzero
value in Required Min Echo RX Interval. value in Required Min Echo RX Interval.
BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The
interval between transmitted BFD Echo packets MUST NOT be less than interval between transmitted BFD Echo packets MUST NOT be less than
the value advertised by the remote system in Required Min Echo RX the value advertised by the remote system in Required Min Echo RX
Interval, except as follows: Interval, except as follows:
A 25% jitter MAY be applied to the rate of transmission, such that A 25% jitter MAY be applied to the rate of transmission, such that
the actual interval MAY be between 75% and 100% of the advertised the actual interval MAY be between 75% and 100% of the advertised
value. A single BFD Echo packet MAY be transmitted between value. A single BFD Echo packet MAY be transmitted between
normally scheduled Echo transmission intervals. normally scheduled Echo transmission intervals.
The transmission of BFD Echo packets is otherwise outside the scope The transmission of BFD Echo packets is otherwise outside the scope
of this specification. of this specification.
6.6.11. Min Rx Interval Change 6.7.11. Min Rx Interval Change
When it is desired to change the rate at which BFD Control packets When it is desired to change the rate at which BFD Control packets
arrive from the remote system, bfd.RequiredMinRxInterval can be arrive from the remote system, bfd.RequiredMinRxInterval can be
changed at any time to any value. The new value will be transmitted changed at any time to any value. The new value will be transmitted
in the next outgoing Control packet, and the remote system will in the next outgoing Control packet, and the remote system will
adjust accordingly. See sections 6.6.3 and 6.6.8 for further adjust accordingly. See sections 6.7.3 and 6.7.8 for further
requirements. requirements.
6.6.12. Min Tx Interval Change 6.7.12. Min Tx Interval Change
When it is desired to change the rate at which BFD Control packets When it is desired to change the rate at which BFD Control packets
are transmitted to the remote system (subject to the requirements of are transmitted to the remote system (subject to the requirements of
the neighboring system), bfd.DesiredMinTxInterval can be changed at the neighboring system), bfd.DesiredMinTxInterval can be changed at
any time to any value. The rules in sections 6.6.3 and 6.6.8 apply. any time to any value. The rules in sections 6.7.3 and 6.7.8 apply.
6.6.13. Detect Multiplier Change 6.7.13. Detect Multiplier Change
When it is desired to change the detect multiplier, the value of When it is desired to change the detect multiplier, the value of
bfd.DetectMult can be changed to any nonzero value. The new value bfd.DetectMult can be changed to any nonzero value. The new value
will be transmitted with the next BFD Control packet. See section will be transmitted with the next BFD Control packet. See section
6.6.8 for additional requirements. 6.7.8 for additional requirements.
6.6.14. Enabling or Disabling The Echo Function 6.7.14. Enabling or Disabling The Echo Function
If it is desired to start or stop the transmission of BFD Echo If it is desired to start or stop the transmission of BFD Echo
packets, this MAY be done at any time (subject to the transmission packets, this MAY be done at any time (subject to the transmission
requirements detailed in section 6.6.10.) requirements detailed in section 6.7.10.)
If it is desired to enable or disable the looping back of received If it is desired to enable or disable the looping back of received
BFD Echo packets, this MAY be done at any time by changing the value BFD Echo packets, this MAY be done at any time by changing the value
of Required Min RX Interval to zero or nonzero in outgoing BFD of Required Min RX Interval to zero or nonzero in outgoing BFD
Control packets. Control packets.
6.6.15. Enabling or Disabling Demand Mode 6.7.15. Enabling or Disabling Demand Mode
If it is desired to start or stop Demand mode, this MAY be done at If it is desired to start or stop Demand mode, this MAY be done at
any time by setting bfd.DemandModeDesired to the proper value. If any time by setting bfd.DemandModeDesired to the proper value. If
Demand mode is no longer active, the system MUST begin transmitting Demand mode is no longer active, the system MUST begin transmitting
periodic BFD Control packets as described in section 6.6.7. periodic BFD Control packets as described in section 6.7.7.
6.6.16. Forwarding Plane Reset 6.7.16. Forwarding Plane Reset
When the forwarding plane in the local system is reset for some When the forwarding plane in the local system is reset for some
reason, such that the remote system can no longer rely on the local reason, such that the remote system can no longer rely on the local
forwarding state, the local system MUST set bfd.LocalDiag to 4 forwarding state, the local system MUST set bfd.LocalDiag to 4
(Forwarding Plane Reset), set bfd.SessionState to Failing, and set (Forwarding Plane Reset), set bfd.SessionState to Failing, and set
bfd.RemoteHeard to zero. bfd.RemoteHeard to zero.
6.6.17. Administrative Control 6.7.17. Administrative Control
There may be circumstances where it is desirable to administratively There may be circumstances where it is desirable to administratively
enable or disable a BFD session. When this is desired, the following enable or disable a BFD session. When this is desired, the following
procedure MUST be followed: procedure MUST be followed:
If enabling session If enabling session
Set bfd.SessionState to Failing Set bfd.SessionState to Failing
Set bfd.RemoteHeard to zero Set bfd.RemoteHeard to zero
Else Else
Set bfd.SessionState to AdminDown Set bfd.SessionState to AdminDown
Set bfd.RemoteHeard to zero Set bfd.RemoteHeard to zero
Set bfd.LocalDiag to an appropriate value Set bfd.LocalDiag to an appropriate value
Cease the transmission of BFD Echo packets Cease the transmission of BFD Echo packets
Specific diagnostic codes are provided for two scenarios.
If signalling is received from outside BFD that the underlying path If signalling is received from outside BFD that the underlying path
has failed, an implementation MAY adminstratively disable the session has failed, an implementation MAY adminstratively disable the session
with the diagnostic Path Down. with the diagnostic Path Down.
Other scenarios MAY use the diagnostic Administratively Down.
6.7.18. Concatenated Paths
If the path being monitored by BFD is concatenated with other paths, If the path being monitored by BFD is concatenated with other paths,
it may be desirable to administratively bring down the BFD session it may be desirable to propagate the indication of a failure of one
when a concatenated path fails (as a way of propagating the of those paths across the BFD session (providing an interworking
failure indication.) In this case, an implementation MAY function for liveness monitoring between BFD and other technologies.)
administratively disable the BFD session with the diagnostic
Concatenated Path Down.
Other scenarios MAY use the diagnostic Administratively Down. Two diagnostic codes are defined for this purpose: Concatenated Path
Down and Reverse Concatenated Path Down. The first propagates
forward path failures (in which the concatenated path fails in the
direction toward the interworking system), and the second propagates
reverse path failures (in which the concatenated path fails in the
direction away from the interworking system, assuming a bidirectional
link.)
A system MAY signal one of these failure states by simply setting
bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD
session is not taken down. If Demand Mode is not active, no other
action is necessary, as the diagnostic code will be carried via the
periodic transmission of BFD Control packets. If Demand Mode is
active, a Poll Sequence MUST be initiated to ensure that the
diagnostic code is transmitted. Note that if the BFD session
subsequently fails, the diagnostic code will be overwritten with a
code detailing the cause of the failure, so it is up to the
interworking agent to perform this procedure again, once the BFD
session reaches Up state, if the propagation of the concatenated path
failure is to resume.
Contributors Contributors
Kireeti Kompella and Yakov Rekhter of Juniper Networks were also Kireeti Kompella and Yakov Rekhter of Juniper Networks were also
significant contributors to this document. significant contributors to this document.
Acknowledgments Acknowledgments
This document was inspired by (and is intended to replace) the This document was inspired by (and is intended to replace) the
Protocol Liveness Protocol draft, written by Kireeti Kompella. Protocol Liveness Protocol draft, written by Kireeti Kompella.
Demand Mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang Demand Mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang
et al. et al.
The authors would also like to thank Mike Shand, John Scudder, The authors would also like to thank Mike Shand, John Scudder,
Stewart Bryant, and Pekka Savola for their substantive input. Stewart Bryant, and Pekka Savola for their substantive input.
Security Considerations Security Considerations
As BFD may be tied into the stability of the infrastructure (such as As BFD may be tied into the stability of the network infrastructure
routing protocols), the effects of an attack on a BFD session may be (such as routing protocols), the effects of an attack on a BFD
very serious. This ultimately has denial-of-service effects, as session may be very serious. This ultimately has denial-of-service
links may be declared to be down (or falsely declared to be up.) effects, as links may be declared to be down (or falsely declared to
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
(physical, or a secure tunnel such as IPsec), the TTL or Hop Count (physical, or a secure tunnel such as IPsec), the TTL or Hop Count
MUST be set to the maximum on transmit, and checked to be equal to MUST be set to the maximum on transmit, and checked to be equal to
the maximum value on reception (and the packet dropped if this is not the maximum value on reception (and the packet dropped if this is not
the case.) See [GTSM] for mor information on this technique. If BFD the case.) See [GTSM] for more information on this technique. If
is run across multiple hops or an insecure tunnel (such as GRE), the BFD is run across multiple hops or an insecure tunnel (such as GRE),
Authentication Section should be utilized. the Authentication Section SHOULD be utilized.
The level of security provided by the Authentication Section varies The level of security provided by the Authentication Section varies
based on the authentication type used. Simple Password based on the authentication type used. Simple Password
authentication is obviously only as secure as the secrecy of the authentication is obviously only as secure as the secrecy of the
passwords used, and should be considered only if the BFD session is passwords used, and should be considered only if the BFD session is
guaranteed to be run over an infrastructure not subject to packet guaranteed to be run over an infrastructure not subject to packet
interception. Its chief advantage is that it minimizes the interception. Its chief advantage is that it minimizes the
computational effort required for authentication. computational effort required for authentication.
Keyed MD5 authentication is much stronger than Simple Password Keyed MD5 authentication is much stronger than Simple Password
skipping to change at page 35, line 18 skipping to change at page 40, line 33
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
properties. All comments about MD5 in this section also apply to
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.
Normative References Normative References
[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism
(GTSM)", RFC 3682, February 2004. (GTSM)", RFC 3682, February 2004.
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORD] 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.
[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
Institute of Science and Technology, Federal Information
Processing Standard (FIPS) 180-1, April 1993.
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
The primary technical change in this draft from the previous version The primary technical change in this draft from the previous version
is the addition of authentication. is the addition of SHA1 authentication, the addition of a method for
enabling and disabling authentication without disturbing BFD session
state, and the modification of the procedures for handling
concatenated paths.
Otherwise, the changes in this draft from the previous version are Otherwise, the changes in this draft from the previous version are
cosmetic and/or editorial. cosmetic and/or editorial.
IPR Notice IPR Notice
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
skipping to change at page 37, line 7 skipping to change at page 42, line 34
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Notice Full Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
This document and translations of it may be copied and furnished to except as set forth therein, the authors retain all their rights.
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
This document expires in August, 2005.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/