Network Working Group D. Katz
Internet Draft Juniper Networks
D. Ward
Cisco Systems
Category: Informational August, 2003
Expires: February, 2004
BFD for IPv4 and IPv6 (Single Hop)
draft-katz-ward-bfd-v4v6-1hop-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Katz, Ward Informational [Page 1]
Internet Draft BFD for IPv4 and IPv6 (Single Hop) August, 2003
Abstract
This document describes the use of the Bidirectional Forwarding
Detection protocol [BFD] over IPv4 and IPv6 for single IP hops. It
further describes the use of BFD with OSPFv2 [OSPFv2], OSPFv3
[OSPFv3], and ISIS [ISIS].
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEYWORDS].
1. Introduction
One very desirable application for BFD is to track IPv4 and IPv6
connectivity between directly-connected systems. This could be used
to supplant the detection mechanisms in ISIS and OSPF, or to monitor
router-host connectivity, among other applications.
This document describes the particulars necessary to use BFD in this
environment, and describes how BFD can be used in conjunction OSPFv2,
OSPFv3, and ISIS.
2. Applications and Limitations
This application of BFD can be used by any pair of systems
communicating via IPv4 and/or IPv6 across a single IP hop that can be
associated with an incoming interface. This includes, but is not
limited to, physical media, virtual circuits, and tunnels.
Each BFD session between a pair of systems must traverse a separate
path in both directions.
Katz, Ward Informational [Page 2]
Internet Draft BFD for IPv4 and IPv6 (Single Hop) August, 2003
3. Initialization and Demultiplexing
In this application, there will be only a single BFD session between
two systems over a given interface (logical or physical.) The BFD
session must be bound to this interface. As such, both sides of a
session MUST use "Active" mode (sending BFD Control packets with a
zero value of Your Discriminator) and any BFD packet from the remote
machine with a zero value of Your Discriminator MUST be associated
with the session bound to the remote system and interface.
4. Encapsulation
4.1. BFD for IPv4
In the case of IPv4, BFD Control packets MUST be transmitted in UDP
packets with destination port 3784, within an IPv4 packet. The
source port MUST be in the range 49152 through 65535. The same UDP
source port number MUST be used for all BFD Control packets
associated with a particular session. The source port number SHOULD
be unique among all BFD sessions on the system. If more than 16384
BFD sessions are simultaneously active, UDP source port numbers MAY
be reused on multiple sessions, but the number of distinct uses of
the same UDP source port number SHOULD be minimized. An
implementation MAY use the UDP port source number to aid in
demultiplexing incoming BFD Control packets, but ultimately the
mechanisms in [BFD] MUST be used to demultiplex incoming packets to
the proper session.
BFD Echo packets are transmitted in UDP packets with destination UDP
port 3785 in an IPv4 packet. The setting of the UDP source port is
outside the scope of this specification. The destination address
MUST be chosen in such a way as to cause the remote system to forward
the packet back to the local system. The source address MUST be
chosen in such a way as to preclude the remote system from generating
ICMP Redirect messages (in particular, the source address MUST NOT be
part of the subnet bound to the interface over which the BFD Echo
packet is being transmitted.)
4.2. BFD for IPv6
In the case of IPv6, BFD Control packets MUST be transmitted in UDP
packets with destination port 3784, within an IPv6 packet. The
source port MUST be in the range 49152 through 65535. The same UDP
source port number MUST be used for all BFD Control packets
associated with a particular session. The source port number SHOULD
Katz, Ward Informational [Page 3]
Internet Draft BFD for IPv4 and IPv6 (Single Hop) August, 2003
be unique among all BFD sessions on the system. If more than 16384
BFD sessions are simultaneously active, UDP source port numbers MAY
be reused on multiple sessions, but the number of distinct uses of
the same UDP source port number SHOULD be minimized. An
implementation MAY use the UDP port source number to aid in
demultiplexing incoming BFD Control packets, but ultimately the
mechanisms in [BFD] MUST be used to demultiplex incoming packets to
the proper session.
BFD Echo packets are transmitted in UDP packets with destination UDP
port 3785 in an IPv6 packet. The setting of the UDP source port is
outside the scope of this specification. The source and destination
addresses MUST both be associated with the local system. The
destination address MUST be chosen in such a way as to cause the
remote system to forward the packet back to the local system.
5. TTL Issues
All BFD packets for sessions operating in this mode MUST be sent with
a TTL value of 255. All received BFD packets that are demultiplexed
to sessions operating in this mode MUST be discarded if the received
TTL is not equal to 255.
6. Addressing Issues
On a subnetted network, BFD Control packets MUST be transmitted with
source and destination addresses that are part of the subnet
(addressed from and to interfaces on the subnet.)
On an addressed but unsubnetted point-to-point link, BFD Control
packets MUST be transmitted with source and destination addresses
that match the addresses configured on that link.
On an unnumbered point-to-point link, the source address of a BFD
Control packet MUST NOT be used to identify the session. This means
that the initial BFD packet MUST be accepted with any source address,
and that subsequent BFD packets MUST be demultiplexed solely by the
My Discriminator field (as is always the case.) This allows the
source address to change if necessary.
Katz, Ward Informational [Page 4]
Internet Draft BFD for IPv4 and IPv6 (Single Hop) August, 2003
7. BFD for use with OSPFv2, OSPFv3, and ISIS
The two versions of OSPF, as well as ISIS, all suffer from an
architectural limitation, namely that their Hello protocols are
limited in the granularity of failure their detection times. In
particular, OSPF has a minimum detection time of two seconds, and
ISIS has a minimum detection time of one second.
BFD MAY be used to achieve arbitrarily small detection times for
these protocols by supplanting the Hello protocols used in each case.
7.1. Session Establishment
The mechanism by which a BFD session is established in this
environment is outside the scope of this specification. An obvious
choice would be to use the discovery mechanism inherent in the Hello
protocols in OSPF and ISIS to bootstrap the establishment of a BFD
session.
Any BFD sessions established to support OSPF and ISIS MUST operate in
accordance with the rest of this document.
If multiple protocols wish to establish BFD sessions with the same
remote system, all MUST share a single BFD session.
7.2. Session Parameters
The setting of the various timing parameters and modes in this
application are outside the scope of this specification.
Note that all protocols sharing a session will operate using the same
parameters. The mechanism for choosing the parameters among those
desired by the various protocols are outside the scope of this
specification.
7.3. Interactions with OSPF and ISIS
When a BFD session transitions from Up to Failing, a Hello protocol
timeout SHOULD be emulated for the associated OSPF neighbors and/or
ISIS adjacencies.
An OSPF neighbor or an ISIS adjacency MUST be allowed to come up,
according to the appropriate specification, regardless of the state
of the associated BFD session.
Katz, Ward Informational [Page 5]
Internet Draft BFD for IPv4 and IPv6 (Single Hop) August, 2003
7.4. OSPF Virtual Links
The use of BFD to support failure detection of OSPF Virtual Links is
for further study and is not yet supported, pending the full
specification of multihop BFD.
Authors' Addresses
Dave Katz
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, California 94089-1206 USA
Phone: +1-408-745-2000
Email: dkatz@juniper.net
Dave Ward
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134 USA
Phone: +1-408-526-4000
Email: dward@cisco.com
Normative References
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
draft-katz-ward-bfd-01.txt, August 2003.
[ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
environments", RFC 1195, December 1990.
[OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[OSPFv3] Coltun, R., et al, "OSPF for IPv6", RFC 2740, December 1999.
Katz, Ward Informational [Page 6]
Internet Draft BFD for IPv4 and IPv6 (Single Hop) August, 2003
Security Considerations
In this application, the use of TTL=255 on transmit and receive is
viewed as supplying equivalent security characteristics to other
protocols used in the infrastructure, as it is not trivially
spoofable. Other security mechanisms are for further study.
Full Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
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
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Katz, Ward Informational [Page 7]
Internet Draft BFD for IPv4 and IPv6 (Single Hop) August, 2003
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Katz, Ward Informational [Page 8]