draft-ietf-bfd-v4v6-1hop-01.txt   draft-ietf-bfd-v4v6-1hop-02.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: August, 2005 February, 2005 Expires: September, 2005 March, 2005
BFD for IPv4 and IPv6 (Single Hop) BFD for IPv4 and IPv6 (Single Hop)
draft-ietf-bfd-v4v6-1hop-01.txt draft-ietf-bfd-v4v6-1hop-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, 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 or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668. 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
skipping to change at page 4, line 23 skipping to change at page 4, line 23
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 IPv6 packet. The setting of the UDP source port UDP port 3785 in an IPv6 packet. The setting of the UDP source port
is outside the scope of this specification. The source and is outside the scope of this specification. The source and
destination addresses MUST both be associated with the local system. destination addresses MUST both be associated with the local system.
The destination address MUST be chosen in such a way as to cause the 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. remote system to forward the packet back to the local system.
5. TTL/Hop Count Issues 5. TTL/Hop Count Issues
If BFD authentication is not in use, all BFD Control packets for If BFD authentication is not in use on a session, all BFD Control
sessions operating according to this specification MUST be sent with packets for the session MUST be sent with a TTL or Hop Count value of
a TTL or Hop Count value of 255. All received BFD Control packets 255. All received BFD Control packets that are demultiplexed to the
that are demultiplexed to sessions operating according to this session MUST be discarded if the received TTL or Hop Count is not
specification MUST be discarded if the received TTL or Hop Count is equal to 255. A discussion of this mechanism can be found in [GTSM].
not equal to 255. A discussion of this mechanism can be found in
[GTSM].
If BFD authentication is in use, any value of TTL/Hop Count MAY be If BFD authentication is in use on a session, all BFD Control packets
used in transmitted packets, and received packets MUST NOT be MUST be sent with a TTL or Hop Count value of 255. All received BFD
discarded based on the received TTL/Hop Count. Control packets that are demultiplexed the session MAY be discarded
if the received TTL or Hop Count is not equal to 255.
In the context of this section, "authentication in use" means that
the system is sending BFD control packets with the Authentication bit
set and with the Authentication Section included, and that all
unauthenticated packets demultiplexed to the session are discarded,
per the BFD base specification.
6. Addressing Issues 6. Addressing Issues
On a subnetted network, BFD Control packets MUST be transmitted with On a subnetted network, BFD Control packets MUST be transmitted with
source and destination addresses that are part of the subnet source and destination addresses that are part of the subnet
(addressed from and to interfaces on the subnet.) (addressed from and to interfaces on the subnet.)
On an addressed but unsubnetted point-to-point link, BFD Control On an addressed but unsubnetted point-to-point link, BFD Control
packets MUST be transmitted with source and destination addresses packets MUST be transmitted with source and destination addresses
that match the addresses configured on that link. that match the addresses configured on that link.
On an unnumbered point-to-point link, the source address of a BFD 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 Control packet MUST NOT be used to identify the session. This means
that the initial BFD packet MUST be accepted with any source address, that the initial BFD packet MUST be accepted with any source address,
and that subsequent BFD packets MUST be demultiplexed solely by the and that subsequent BFD packets MUST be demultiplexed solely by the
My Discriminator field (as is always the case.) This allows the My Discriminator field (as is always the case.) This allows the
source address to change if necessary. Note that the TTL/Hop Count source address to change if necessary. If the received source
check described in section 5 precludes the BFD packets from having address changes, the local system MUST NOT use that address as the
come from any source other than the immediate neighbor. destination in outgoing BFD Control packets; rather it MUST continue
to use the address configured at session creation. An implementation
MAY notify the application that the neighbor's source address has
changed, so that the application might choose to change the
destination address or take some other action. Note that the TTL/Hop
Count check described in section 5 (or the use of authentication)
precludes the BFD packets from having come from any source other than
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 failure their 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
skipping to change at page 6, line 17 skipping to change at page 6, line 33
The setting of the various timing parameters and modes in this The setting of the various timing parameters and modes in this
application are outside the scope of this specification. application are outside the scope of this specification.
Note that all protocols sharing a session will operate using the same Note that all protocols sharing a session will operate using the same
parameters. The mechanism for choosing the parameters among those parameters. The mechanism for choosing the parameters among those
desired by the various protocols are outside the scope of this desired by the various protocols are outside the scope of this
specification. specification.
7.3. Interactions with OSPF and IS-IS without Graceful Restart 7.3. Interactions with OSPF and IS-IS without Graceful Restart
When a BFD session transitions from Up to Failing, action SHOULD be Slightly different mechanisms are used if the routing protocol
taken in the routing protocol to signal the lack of connectivity for supports the routing of multiple data protocols, depending on whether
the data protocol (IPv4 or IPv6) over which BFD is running. If only the routing protocol supports separate topologies for each data
one data protocol is being advertised in the routing protocol Hello, protocol. With a shared topology, if one of the data protocols fails
or if multiple protocols are being advertised but the protocols must (as signalled by the associated BFD session), it is necessary to
share a common topology, a Hello protocol timeout SHOULD be emulated consider the path to have failed for all data protocols, since there
for the associated OSPF neighbors and/or IS-IS adjacencies. is otherwise no way for the routing protocol to turn away traffic for
the failed protocol (and such traffic would be black holed
indefinitely.)
With individual routing topologies for each data protocol, only the
failed data protocol needs to be rerouted around the failed path.
Therefore, when a BFD session transitions from Up to Down, action
SHOULD be taken in the routing protocol to signal the lack of
connectivity for the data protocol (IPv4 or IPv6) over which BFD is
running. If only one data protocol is being advertised in the
routing protocol Hello, or if multiple protocols are being advertised
but the protocols must share a common topology, a Hello protocol
timeout SHOULD be emulated for the associated OSPF neighbors and/or
IS-IS adjacencies.
If multiple data protocols are advertised in the routing protocol If multiple data protocols are advertised in the routing protocol
Hello, and the routing protocol supports different topologies for Hello, and the routing protocol supports different topologies for
each data protocol, the failing data protocol SHOULD no longer be each data protocol, the failing data protocol SHOULD no longer be
advertised in Hello packets in order to signal a lack of connectivity advertised in Hello packets in order to signal a lack of connectivity
for that protocol. for that protocol.
Note that it is possible in some failure scenarios for the network to Note that it is possible in some failure scenarios for the network to
be in a state such that the IGP comes up, but the BFD session cannot be in a state such that the IGP comes up, but the BFD session cannot
be established, and, more particularly, data cannot be forwarded. To be established, and, more particularly, data cannot be forwarded. To
skipping to change at page 9, line 17 skipping to change at page 9, line 33
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-01.txt, February, 2005. draft-ietf-bfd-base-02.txt, March, 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-01.txt, February, 2005. ietf-bfd-multihop-02.txt, March, 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.
[ISIS-GRACE] Shand, M., and Ginsberg, L., "Restart signaling for IS- [ISIS-GRACE] Shand, M., and Ginsberg, L., "Restart signaling for IS-
IS", RFC 3847, July 2004. IS", RFC 3847, July 2004.
skipping to change at page 10, line 11 skipping to change at page 10, line 19
[OSPF-GRACE] Moy, J., et al, "Graceful OSPF Restart", RFC 3623, [OSPF-GRACE] Moy, J., et al, "Graceful OSPF Restart", RFC 3623,
November 2003. November 2003.
Security Considerations Security Considerations
In this application, the use of TTL=255 on transmit and receive is In this application, the use of TTL=255 on transmit and receive is
viewed as supplying equivalent security characteristics to other viewed as supplying equivalent security characteristics to other
protocols used in the infrastructure, as it is not trivially protocols used in the infrastructure, as it is not trivially
spoofable. The security implications of this mechanism are further spoofable. The security implications of this mechanism are further
discussed in the GTSM specification. discussed in [GTSM].
The security implications of the use of BFD Authentication are The security implications of the use of BFD Authentication are
discussed in the base BFD specification. discussed in [BFD].
The use of the TTL=255 check simultaneously with BFD Authentication
provides a low overhead mechanism for discarding a class of
unauthorized packets and may be useful in implementations in which
cryptographic checksum use is susceptable to denial of service
attacks. The use or non-use of this mechanism does not impact
interoperability.
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 only significant changes to this version are the option of not The only substantive changes are to allow the TTL=255 check to be
using the TTL=255 hack when authentication is in use, the option of optional when authentication is in use, and to specify that the
suppressing ISIS and OSPF neighbors while the BFD session is down, destination address in BFD Control packets does not change even if
and further explication of the interactions with Graceful Restart. the source address of the neighbor's packets changes (which is
All other changes are editorial in nature. allowed on unnumbered links.)
Explicatory language on the issues of interaction with multiprotocol
routing protocols was added.
All other changes are editorial.
Full Copyright Notice Full Copyright Notice
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
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 August, 2005. This document expires in September, 2005.
 End of changes. 

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