draft-ietf-bfd-v4v6-1hop-09.txt   draft-ietf-bfd-v4v6-1hop-10.txt 
Network Working Group D. Katz Network Working Group D. Katz
Internet Draft Juniper Networks Internet Draft Juniper Networks
Intended status: Proposed Standard D. Ward Intended status: Proposed Standard D. Ward
Cisco Systems Cisco Systems
Expires: August, 2009 February 5, 2009 Expires: April, 2010 October 16, 2009
BFD for IPv4 and IPv6 (Single Hop) BFD for IPv4 and IPv6 (Single Hop)
draft-ietf-bfd-v4v6-1hop-09.txt draft-ietf-bfd-v4v6-1hop-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
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. Detection protocol over IPv4 and IPv6 for single IP hops.
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
skipping to change at page 3, line 31 skipping to change at page 3, line 31
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.
4. Encapsulation 4. Encapsulation
4.1. BFD for IPv4 BFD Control packets MUST be transmitted in UDP packets with
destination port 3784, within an IPv4 or IPv6 packet. The source
In the case of IPv4, BFD Control packets MUST be transmitted in UDP port MUST be in the range 49152 through 65535. The same UDP source
packets with destination port 3784, within an IPv4 packet. The port number MUST be used for all BFD Control packets associated with
source port MUST be in the range 49152 through 65535. The same UDP a particular session. The source port number SHOULD be unique among
source port number MUST be used for all BFD Control packets all BFD sessions on the system. If more than 16384 BFD sessions are
associated with a particular session. The source port number SHOULD simultaneously active, UDP source port numbers MAY be reused on
be unique among all BFD sessions on the system. If more than 16384 multiple sessions, but the number of distinct uses of the same UDP
BFD sessions are simultaneously active, UDP source port numbers MAY source port number SHOULD be minimized. An implementation MAY use
be reused on multiple sessions, but the number of distinct uses of the UDP port source number to aid in demultiplexing incoming BFD
the same UDP source port number SHOULD be minimized. An Control packets, but ultimately the mechanisms in [BFD] MUST be used
implementation MAY use the UDP port source number to aid in to demultiplex incoming packets to the proper session.
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 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 or IPv6 packet. The setting of the UDP
is outside the scope of this specification. The destination address source port is outside the scope of this specification. The
MUST be chosen in such a way as to cause the remote system to forward destination address MUST be chosen in such a way as to cause the
the packet back to the local system. The source address MUST be remote system to forward the packet back to the local system. The
chosen in such a way as to preclude the remote system from generating source address MUST be chosen in such a way as to preclude the remote
ICMP Redirect messages. In particular, the source address SHOULD NOT system from generating ICMP or Neighbor Discovery Redirect messages.
be part of the subnet bound to the interface over which the BFD Echo In particular, the source address SHOULD NOT be part of the subnet
packet is being transmitted, unless it is known by other means that bound to the interface over which the BFD Echo packet is being
the remote system will not send Redirects. transmitted, and it SHOULD NOT be an IPv6 link-local address, unless
it is known by other means that the remote system will not send
4.2. BFD for IPv6 Redirects.
In the case of IPv6, BFD Control packets MUST be transmitted in UDP BFD Echo packets MUST be transmitted in such a way as to ensure that
packets with destination port 3784, within an IPv6 packet. The they are received by the remote system. On multiaccess media, for
source port MUST be in the range 49152 through 65535. The same UDP example, this requires that the destination datalink address
source port number MUST be used for all BFD Control packets corresponds to the remote system.
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 MUST be transmitted in UDP packets with destination The above requirements may require the bypassing of some common IP
UDP port 3785 in an IPv6 packet. The setting of the UDP source port layer functionality, particularly in host implementations.
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/Hop Limit Issues 5. TTL/Hop Limit Issues
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
skipping to change at page 6, line 16 skipping to change at page 6, line 7
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.
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. Ports 3784 and 3875 were assigned by IANA for use with this protocol.
9. 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].
skipping to change at page 7, line 10 skipping to change at page 6, line 33
unauthorized packets and may be useful in implementations in which unauthorized packets and may be useful in implementations in which
cryptographic checksum use is susceptible 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.
10. References 10. References
10.1. Normative References 10.1. Normative References
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-09.txt, February, 2009. draft-ietf-bfd-base-10.txt, October, 2009.
[BFD-GENERIC] Katz, D., and Ward, D., "Generic Application of BFD", [BFD-GENERIC] Katz, D., and Ward, D., "Generic Application of BFD",
draft-ietf-bfd-generic-05.txt, February, 2009. draft-ietf-bfd-generic-05.txt, February, 2009.
[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October, 2007. (GTSM)", RFC 5082, October, 2007.
[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.
skipping to change at page 8, line 7 skipping to change at page 7, line 29
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
Only minor editorial changes were made. The Encapsulation section was reorganized, and the details of Echo
packet encapsulation and transmission were expanded. The IANA
Considerations section was updated to include the port number
assignments.
This document expires in August, 2009. This document expires in April, 2010.
 End of changes. 11 change blocks. 
51 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/