draft-ietf-bfd-multihop-00.txt   draft-ietf-bfd-multihop-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
BFD for Multihop Paths BFD for Multihop Paths
draft-ietf-bfd-multihop-00.txt draft-ietf-bfd-multihop-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 (2004). All Rights Reserved.
Abstract Abstract
This document describes the use of the Bidirectional Forwarding This document describes the use of the Bidirectional Forwarding
Detection protocol (BFD) over multihop paths, including Detection protocol (BFD) over multihop paths, including
unidirectional links. unidirectional links.
skipping to change at page 4, line 16 skipping to change at page 4, line 16
Unidirectional links are classified as multihop paths because the Unidirectional links are classified as multihop paths because the
return path (which must exist at some level in order to make the link return path (which must exist at some level in order to make the link
useful) may be arbitrary, and the return paths for BFD sessions useful) may be arbitrary, and the return paths for BFD sessions
protecting parallel unidirectional links may overlap or even be protecting parallel unidirectional links may overlap or even be
identical. (If two unidirection links, one in each direction, are to identical. (If two unidirection links, one in each direction, are to
carry a single BFD session, this can be done using the single-hop carry a single BFD session, this can be done using the single-hop
approach.) approach.)
Either of the two methods outlined earlier may be used in the Either of the two methods outlined earlier may be used in the
Unidirectional link case (as an MPLS LSP is in fact a unidirectional Unidirectional link case, but a more general solution can be done
link), but a more general solution can be done strictly within BFD strictly within BFD and without addressing limitations.
and without addressing limitations.
The approach is similar to the one-hop specification, since the The approach is similar to the one-hop specification, since the
unidirectional link is a single hop. Let's define the two systems as unidirectional link is a single hop. Let's define the two systems as
the Unidirectional Sender and the Unidirectional Receiver. In this the Unidirectional Sender and the Unidirectional Receiver. In this
approach the Unidirectional Sender MUST operate in the Active role approach the Unidirectional Sender MUST operate in the Active role
(as defined in the base BFD specification), and the Unidirectional (as defined in the base BFD specification), and the Unidirectional
Receiver MUST operate in the Passive role. Receiver MUST operate in the Passive role.
In the Passive role, by definition, the Unidirectional Receiver does In the Passive role, by definition, the Unidirectional Receiver does
not transmit any BFD Control packets until it learns the not transmit any BFD Control packets until it learns the
skipping to change at page 5, line 8 skipping to change at page 5, line 8
4. Authentication 4. Authentication
By their nature, multihop paths expose BFD to spoofing. By their nature, multihop paths expose BFD to spoofing.
Implementations of BFD SHOULD utilize authentication over multihop Implementations of BFD SHOULD utilize authentication over multihop
paths to help mitigate denial-of-service attacks. paths to help mitigate denial-of-service attacks.
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-00.txt, July, 2004. draft-ietf-bfd-base-01.txt, February, 2005.
[BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single [BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single
Hop)", draft-ietf-bfd-v4v6-1hop-00.txt, July, 2004. Hop)", draft-ietf-bfd-v4v6-1hop-01.txt, February, 2005.
[BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs", [BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs",
draft-ietf-bfd-mpls-00.txt, July, 2004. draft-ietf-bfd-mpls-01.txt, February, 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.
[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.
[OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[OSPFv3] Coltun, R., et al, "OSPF for IPv6", RFC 2740, December 1999. [OSPFv3] Coltun, R., et al, "OSPF for IPv6", RFC 2740, December 1999.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
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
Full Copyright Notice Changes from the previous draft
Copyright (C) The Internet Society (2004). All Rights Reserved. No changes were made other than updating references and boilerplate
language.
This document and translations of it may be copied and furnished to Full Copyright Notice
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 Copyright (C) The Internet Society (2004). This document is subject
revoked by the Internet Society or its successors or assigns. to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein 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/