draft-ietf-bfd-v4v6-1hop-08.txt | draft-ietf-bfd-v4v6-1hop-09.txt | |||
---|---|---|---|---|
Network Working Group D. Katz | Network Working Group D. Katz | |||
Internet Draft Juniper Networks | Internet Draft Juniper Networks | |||
D. Ward | Intended status: Proposed Standard D. Ward | |||
Cisco Systems | Cisco Systems | |||
Expires: September, 2008 March, 2008 | Expires: August, 2009 February 5, 2009 | |||
BFD for IPv4 and IPv6 (Single Hop) | BFD for IPv4 and IPv6 (Single Hop) | |||
draft-ietf-bfd-v4v6-1hop-08.txt | draft-ietf-bfd-v4v6-1hop-09.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | This Internet-Draft is submitted to IETF in full conformance with the | |||
applicable patent or other IPR claims of which he or she is aware | provisions of BCP 78 and BCP 79. | |||
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. | ||||
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/1id-abstracts.html | 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 (c) 2009 IETF Trust and the persons identified as the | ||||
document authors. All rights reserved. | ||||
This document is subject to BCP 78 and the IETF Trust's Legal | ||||
Provisions Relating to IETF Documents | ||||
(http://trustee.ietf.org/license-info) in effect on the date of | ||||
publication of this document. Please review these documents | ||||
carefully, as they describe your rights and restrictions with respect | ||||
to this document. | ||||
Abstract | Abstract | |||
This document describes the use of the Bidirectional Forwarding | This document describes the use of the Bidirectional Forwarding | |||
Detection protocol over IPv4 and IPv6 for single IP hops. Comments | Detection protocol over IPv4 and IPv6 for single IP hops. | |||
on this draft should be directed to rtg-bfd@ietf.org. | ||||
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 | |||
skipping to change at page 2, line 31 | skipping to change at page 2, line 36 | |||
[BFD-GENERIC]. | [BFD-GENERIC]. | |||
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 is | communicating via IPv4 and/or IPv6 across a single IP hop that is | |||
associated with an incoming interface. This includes, but is not | associated with an incoming interface. This includes, but is not | |||
limited to, physical media, virtual circuits, and tunnels. | limited to, physical media, virtual circuits, and tunnels. | |||
Each BFD session between a pair of systems MUST traverse a separate | Each BFD session between a pair of systems MUST traverse a separate | |||
path in both directions. | network-layer path in both directions. This is necessary for | |||
demultiplexing to work properly, and also because (by definition) | ||||
multiple sessions would otherwise be protecting the same path. | ||||
If BFD is to be used in conjunction with both IPv4 and IPv6 on a | If BFD is to be used in conjunction with both IPv4 and IPv6 on a | |||
particular link, a separate BFD session MUST be established for each | particular path, a separate BFD session MUST be established for each | |||
protocol (and thus encapsulated by that protocol) over that link. | protocol (and thus encapsulated by that protocol) over that link. | |||
If the BFD Echo function is used, transmitted packets are immediately | ||||
routed back towards the sender on the interface over which they were | ||||
sent. This may interact with other mechanisms that are used on the | ||||
two systems that employ BFD. In particular, ingress filtering [BCP38] | ||||
is incompatible with the way Echo packets need to be sent. | ||||
Implementations that support the Echo function MUST either ensure | ||||
that ingress filtering is not used on an interface that employs the | ||||
Echo function, or need make an exception for ingress filtering Echo | ||||
packets. | ||||
An implementation of the Echo function also requires Application | ||||
Programming Interfaces (APIs) that may not exist on all systems. A | ||||
system implementing the Echo function MUST be capable of sending | ||||
packets to its own address, which will typically require bypassing | ||||
the normal forwarding lookup. This typically requires access to APIs | ||||
that bypass IP layer functionality. | ||||
3. Initialization and Demultiplexing | 3. Initialization and Demultiplexing | |||
In this application, there will be only a single BFD session between | In this application, there will be only a single BFD session between | |||
two systems over a given interface (logical or physical) for a | two systems over a given interface (logical or physical) for a | |||
particular protocol. The BFD session must be bound to this | particular protocol. The BFD session must be bound to this | |||
interface. As such, both sides of a session MUST take the "Active" | interface. As such, both sides of a session MUST take the "Active" | |||
role (sending initial BFD Control packets with a zero value of Your | role (sending initial BFD Control packets with a zero value of Your | |||
Discriminator) and any BFD packet from the remote machine with a zero | Discriminator) and any BFD packet from the remote machine with a zero | |||
value of Your Discriminator MUST be associated with the session bound | value of Your Discriminator MUST be associated with the session bound | |||
to the remote system, interface, and protocol. | to the remote system, interface, and protocol. | |||
skipping to change at page 4, line 39 | skipping to change at page 4, line 48 | |||
If BFD authentication is not in use on a session, all BFD Control | If BFD authentication is not in use on a session, all BFD Control | |||
packets for the session MUST be sent with a TTL or Hop Limit value of | packets for the session MUST be sent with a TTL or Hop Limit value of | |||
255. All received BFD Control packets that are demultiplexed to the | 255. All received BFD Control packets that are demultiplexed to the | |||
session MUST be discarded if the received TTL or Hop Limit is not | session MUST be discarded if the received TTL or Hop Limit is not | |||
equal to 255. A discussion of this mechanism can be found in [GTSM]. | equal to 255. A discussion of this mechanism can be found in [GTSM]. | |||
If BFD authentication is in use on a session, all BFD Control packets | If BFD authentication is in use on a session, all BFD Control packets | |||
MUST be sent with a TTL or Hop Limit value of 255. All received BFD | MUST be sent with a TTL or Hop Limit value of 255. All received BFD | |||
Control packets that are demultiplexed the session MAY be discarded | Control packets that are demultiplexed the session MAY be discarded | |||
if the received TTL or Hop Limit is not equal to 255. | if the received TTL or Hop Limit is not equal to 255. If the TTL/Hop | |||
Limit check is made, it MAY be done before any cryptographic | ||||
authentication takes place if this will avoid unnecessary calculation | ||||
that would be detrimental to the receiving system. | ||||
In the context of this section, "authentication in use" means that | In the context of this section, "authentication in use" means that | |||
the system is sending BFD control packets with the Authentication bit | the system is sending BFD control packets with the Authentication bit | |||
set and with the Authentication Section included, and that all | set and with the Authentication Section included, and that all | |||
unauthenticated packets demultiplexed to the session are discarded, | unauthenticated packets demultiplexed to the session are discarded, | |||
per the BFD base specification. | per the BFD base specification. | |||
6. Addressing Issues | 6. Addressing Issues | |||
Implementations MUST ensure that all BFD Control packets are | Implementations MUST ensure that all BFD Control packets are | |||
skipping to change at page 6, line 5 | skipping to change at page 6, line 14 | |||
7. BFD for use with Tunnels | 7. BFD for use with Tunnels | |||
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 Limit of the network protocol carried within, the | TTL or Hop Limit 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 | 8. IANA Considerations | |||
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", | ||||
draft-ietf-bfd-base-07.txt, January, 2008. | ||||
[BFD-GENERIC] Katz, D., and Ward, D., "Generic Application of BFD", | ||||
draft-ietf-bfd-generic-04.txt, January, 2008. | ||||
[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism | ||||
(GTSM)", RFC 5082, October, 2007. | ||||
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate | This document has no actions for IANA. | |||
Requirement Levels", RFC 2119, March 1997. | ||||
Security Considerations | 9. Security Considerations | |||
In this application, the use of TTL=255 on transmit and receive, | In this application, the use of TTL=255 on transmit and receive, | |||
coupled with an association to an incoming interface, is viewed as | coupled with an association to an incoming interface, is viewed as | |||
supplying equivalent security characteristics to other protocols used | supplying equivalent security characteristics to other protocols used | |||
in the infrastructure, as it is not trivially spoofable. The | in the infrastructure, as it is not trivially spoofable. The | |||
security implications of this mechanism are further discussed in | security implications of this mechanism are further discussed in | |||
[GTSM]. | [GTSM]. | |||
The security implications of the use of BFD Authentication are | The security implications of the use of BFD Authentication are | |||
discussed in [BFD]. | discussed in [BFD]. | |||
The use of the TTL=255 check simultaneously with BFD Authentication | The use of the TTL=255 check simultaneously with BFD Authentication | |||
provides a low overhead mechanism for discarding a class of | provides a low overhead mechanism for discarding a class of | |||
unauthorized packets and may be useful in implementations in which | unauthorized packets and may be useful in implementations in which | |||
cryptographic checksum use is susceptable to denial of service | cryptographic checksum use is susceptible to denial of service | |||
attacks. The use or non-use of this mechanism does not impact | attacks. The use or non-use of this mechanism does not impact | |||
interoperability. | interoperability. | |||
IANA Considerations | 10. References | |||
This document has no actions for IANA. | 10.1. Normative References | |||
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", | ||||
draft-ietf-bfd-base-09.txt, February, 2009. | ||||
[BFD-GENERIC] Katz, D., and Ward, D., "Generic Application of BFD", | ||||
draft-ietf-bfd-generic-05.txt, February, 2009. | ||||
[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism | ||||
(GTSM)", RFC 5082, October, 2007. | ||||
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate | ||||
Requirement Levels", RFC 2119, March 1997. | ||||
10.2. Informative References | ||||
[BCP38] Ferguson, P, and Senie, D., "Network Ingress Filtering: | ||||
Defeating Denial of Service Attacks which employ IP Source Address | ||||
Spoofing", RFC 2827, May 2000. | ||||
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 | |||
Section 6 was changed to lump all point-to-point link types together. | Only minor editorial changes were made. | |||
Otherwise, only minor editorial changes were made. | ||||
IPR Disclaimer | ||||
The IETF takes no position regarding the validity or scope of any | ||||
Intellectual Property Rights or other rights that might be claimed to | ||||
pertain to the implementation or use of the technology described in | ||||
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 | ||||
made any independent effort to identify any such rights. Information | ||||
on the procedures with respect to rights in RFC documents can be | ||||
found in BCP 78 and BCP 79. | ||||
Copies of IPR disclosures made to the IETF Secretariat and any | ||||
assurances of licenses to be made available, or the result of an | ||||
attempt made to obtain a general license or permission for the use of | ||||
such proprietary rights by implementers or users of this | ||||
specification can be obtained from the IETF on-line IPR repository at | ||||
http://www.ietf.org/ipr. | ||||
The IETF invites any interested party to bring to its attention any | ||||
copyrights, patents or patent applications, or other proprietary | ||||
rights that may cover technology that may be required to implement | ||||
this standard. Please address the information to the IETF at ietf- | ||||
ipr@ietf.org. | ||||
Full Copyright Notice | ||||
Copyright (C) The IETF Trust (2008). | ||||
This document is subject 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 are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | ||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. | ||||
Acknowledgement | ||||
Funding for the RFC Editor function is currently provided by the | ||||
Internet Society. | ||||
This document expires in September, 2008. | This document expires in August, 2009. | |||
End of changes. 18 change blocks. | ||||
75 lines changed or deleted | 68 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |