draft-ietf-bfd-v4v6-1hop-03.txt   draft-ietf-bfd-v4v6-1hop-04.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, 2006 July, 2005 Expires: April, 2006 October, 2005
BFD for IPv4 and IPv6 (Single Hop) BFD for IPv4 and IPv6 (Single Hop)
draft-ietf-bfd-v4v6-1hop-03.txt draft-ietf-bfd-v4v6-1hop-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 22 skipping to change at page 2, line 22
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEYWORDS]. document are to be interpreted as described in RFC-2119 [KEYWORDS].
1. Introduction 1. Introduction
One very desirable application for BFD [BFD] is to track IPv4 and One very desirable application for BFD [BFD] is to track IPv4 and
IPv6 connectivity between directly-connected systems. This could be IPv6 connectivity between directly-connected systems. This could be
used to supplant the detection mechanisms in IS-IS and OSPF, or to used to supplement the detection mechanisms in IS-IS and OSPF, or to
monitor router-host connectivity, among other applications. monitor router-host connectivity, among other applications.
This document describes the particulars necessary to use BFD in this This document describes the particulars necessary to use BFD in this
environment, and describes how BFD can be used in conjunction OSPFv2 environment, and describes how BFD can be used in conjunction OSPFv2
[OSPFv2], OSPFv3 [OSPFv3], and IS-IS [ISIS]. [OSPFv2], OSPFv3 [OSPFv3], and IS-IS [ISIS].
2. Applications and Limitations 2. Applications and Limitations
This application of BFD can be used by any pair of systems 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 communicating via IPv4 and/or IPv6 across a single IP hop that can be
skipping to change at page 3, line 40 skipping to change at page 3, line 40
demultiplexing incoming BFD Control packets, but ultimately the demultiplexing incoming BFD Control packets, but ultimately the
mechanisms in [BFD] MUST be used to demultiplex incoming packets to mechanisms in [BFD] MUST be used to demultiplex incoming packets to
the proper session. the proper session.
BFD Echo packets MUST be transmitted in UDP packets with destination BFD Echo packets MUST be transmitted in UDP packets with destination
UDP port 3785 in an IPv4 packet. The setting of the UDP source port UDP port 3785 in an IPv4 packet. The setting of the UDP source port
is outside the scope of this specification. The destination address 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 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 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 chosen in such a way as to preclude the remote system from generating
ICMP Redirect messages (in particular, the source address MUST NOT be ICMP Redirect messages. In particular, the source address MUST NOT
part of the subnet bound to the interface over which the BFD Echo be part of the subnet bound to the interface over which the BFD Echo
packet is being transmitted.) packet is being transmitted.
4.2. BFD for IPv6 4.2. BFD for IPv6
In the case of IPv6, BFD Control packets MUST be transmitted in UDP In the case of IPv6, BFD Control packets MUST be transmitted in UDP
packets with destination port 3784, within an IPv6 packet. The 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 MUST be in the range 49152 through 65535. The same UDP
source port number MUST be used for all BFD Control packets source port number MUST be used for all BFD Control packets
associated with a particular session. The source port number SHOULD associated with a particular session. The source port number SHOULD
be unique among all BFD sessions on the system. If more than 16384 be unique among all BFD sessions on the system. If more than 16384
BFD sessions are simultaneously active, UDP source port numbers MAY BFD sessions are simultaneously active, UDP source port numbers MAY
skipping to change at page 5, line 35 skipping to change at page 5, line 35
changed, so that the application might choose to change the changed, so that the application might choose to change the
destination address or take some other action. Note that the TTL/Hop destination address or take some other action. Note that the TTL/Hop
Count check described in section 5 (or the use of authentication) Count check described in section 5 (or the use of authentication)
precludes the BFD packets from having come from any source other than precludes the BFD packets from having come from any source other than
the immediate neighbor. the immediate neighbor.
7. BFD for use with OSPFv2, OSPFv3, and IS-IS 7. BFD for use with OSPFv2, OSPFv3, and IS-IS
The two versions of OSPF, as well as IS-IS, all suffer from an The two versions of OSPF, as well as IS-IS, all suffer from an
architectural limitation, namely that their Hello protocols are architectural limitation, namely that their Hello protocols are
limited in the granularity of failure their detection times. In limited in the granularity of their failure detection times. In
particular, OSPF has a minimum detection time of two seconds, and IS- particular, OSPF has a minimum detection time of two seconds, and IS-
IS has a minimum detection time of one second. IS has a minimum detection time of one second.
BFD MAY be used to achieve arbitrarily small detection times for BFD MAY be used to achieve arbitrarily small detection times for
these protocols by supplanting the Hello protocols used in each case. these protocols by supplementing the Hello protocols used in each
case.
It should be noted that the purpose of using BFD in this context is It should be noted that the purpose of using BFD in this context is
not to replace the adjacency timeout mechanism, nor is it to not to replace the adjacency timeout mechanism, nor is it to
demonstrate that the network is fully functional for the use of the demonstrate that the network is fully functional for the use of the
routing protocol, but is simply to advise the routing protocol that routing protocol, but is simply to advise the routing protocol that
there are problems forwarding the data protocol for which the routing there are problems forwarding the data protocol for which the routing
protocol is calculating routes. protocol is calculating routes.
7.1. Session Establishment 7.1. Session Establishment
skipping to change at page 7, line 26 skipping to change at page 7, line 26
be established, and, more particularly, data cannot be forwarded. To be established, and, more particularly, data cannot be forwarded. To
avoid this situation, it would be beneficial to not allow the IGP to avoid this situation, it would be beneficial to not allow the IGP to
establish a neighbor/adjacency. However, this would preclude the establish a neighbor/adjacency. However, this would preclude the
operation of the IGP in an environment in which not all systems operation of the IGP in an environment in which not all systems
support BFD. support BFD.
Therefore, if a BFD session is not in Up state (possibly because the Therefore, if a BFD session is not in Up state (possibly because the
remote system does not support BFD), it is OPTIONAL to preclude the remote system does not support BFD), it is OPTIONAL to preclude the
establishment of an OSPF neighbor or an IS-IS adjacency. The choice establishment of an OSPF neighbor or an IS-IS adjacency. The choice
of whether to do so SHOULD be controlled by means outside the scope of whether to do so SHOULD be controlled by means outside the scope
of this specification, such as configuration or other mechanisms. of this specification, such as configuration or other mechanisms. If
an OSPF neighbor or IS-IS adjacency is established but the
corresponding BFD session is not in Up state (implying that the
neighbor does not support BFD) implementations MAY raise the BFD
transmit interval beyond the minimum of one second in order to
minimize extraneous traffic.
7.4. Interactions with OSPF and IS-IS with Graceful Restart 7.4. Interactions with OSPF and IS-IS with Graceful Restart
The Graceful Restart functions in OSPF [OSPF-GRACE] and IS-IS [ISIS- The Graceful Restart functions in OSPF [OSPF-GRACE] and IS-IS [ISIS-
GRACE] are predicated on the existence of a separate forwarding plane GRACE] are predicated on the existence of a separate forwarding plane
that does not necessarily share fate with the control plane in which that does not necessarily share fate with the control plane in which
the routing protocols operate. In particular, the assumption is that the routing protocols operate. In particular, the assumption is that
the forwarding plane can continue to function while the protocols the forwarding plane can continue to function while the protocols
restart and sort things out. restart and sort things out.
skipping to change at page 9, line 33 skipping to change at page 9, line 38
A number of mechanisms are available to tunnel IPv4 and IPv6 over A number of mechanisms are available to tunnel IPv4 and IPv6 over
arbitrary topologies. If the tunnel mechanism does not decrement the arbitrary topologies. If the tunnel mechanism does not decrement the
TTL or hop count of the network protocol carried within, the TTL or hop count of the network protocol carried within, the
mechanism described in this document may be used to provide liveness mechanism described in this document may be used to provide liveness
detection for the tunnel. The BFD Authentication mechanism SHOULD be detection for the tunnel. The BFD Authentication mechanism SHOULD be
used and is strongly encouraged. used and is strongly encouraged.
Normative References Normative References
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-03.txt, July, 2005. draft-ietf-bfd-base-04.txt, October, 2005.
[BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft- [BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft-
ietf-bfd-multihop-03.txt, July, 2005. ietf-bfd-multihop-03.txt, July, 2005.
[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.
[ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual [ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
environments", RFC 1195, December 1990. environments", RFC 1195, December 1990.
skipping to change at page 11, line 23 skipping to change at page 11, line 23
Dave Ward Dave Ward
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 USA San Jose, CA 95134 USA
Phone: +1-408-526-4000 Phone: +1-408-526-4000
Email: dward@cisco.com Email: dward@cisco.com
Changes from the previous draft Changes from the previous draft
All changes are editorial in nature. Text was added to point out that implementations may raise the BFD
transmit interval above the minimum if it appears that the neighbor
does not support BFD. All other changes are editorial in nature.
IPR Disclaimer IPR Disclaimer
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 12, line 26 skipping to change at page 12, line 27
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 January, 2006. This document expires in April, 2006.
 End of changes. 10 change blocks. 
11 lines changed or deleted 19 lines changed or added

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