Neighbor Unreachability Detection is too impatient
draft-ietf-6man-impatient-nud-04
The information below is for an old version of the document |
Document |
Type |
|
Active Internet-Draft (6man WG)
|
|
Authors |
|
Erik Nordmark
,
Igor Gashinsky
|
|
Last updated |
|
2012-10-22
|
|
Stream |
|
Internent Engineering Task Force (IETF)
|
|
Formats |
|
pdf
htmlized (tools)
htmlized
bibtex
|
|
Reviews |
|
|
Stream |
WG state
|
|
Waiting for WG Chair Go-Ahead
Revised I-D Needed - Issue raised by WGLC
|
|
Document shepherd |
|
None
|
IESG |
IESG state |
|
I-D Exists
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
6MAN WG E. Nordmark
Internet-Draft Cisco Systems, Inc.
Updates: 4861 (if approved) I. Gashinsky
Intended status: Standards Track Yahoo!
Expires: April 4, 2013 Oct 2012
Neighbor Unreachability Detection is too impatient
draft-ietf-6man-impatient-nud-04.txt
Abstract
IPv6 Neighbor Discovery includes Neighbor Unreachability Detection.
That function is very useful when a host has an alternative, for
instance multiple default routers, since it allows the host to switch
to the alternative in short time. This time is 3 seconds after the
node starts probing by default. However, if there are no
alternatives, this is far too impatient. This document specifies
relaxed rules for Neighbor Discovery retransmissions that allows an
implementation to choose different timeout behavior based on whether
or not there are alternatives. This document updates RFC 4861.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 4, 2013.
Copyright Notice
Copyright (c) 2012 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
Nordmark & Gashinsky Expires April 4, 2013 [Page 1]
Internet-Draft NUD is too impatient Oct 2012
carefully, as they describe your rights and restrictions with respect
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 Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Updates . . . . . . . . . . . . . . . . . . . . . . . 4
4. Example Algorithm . . . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Nordmark & Gashinsky Expires April 4, 2013 [Page 2]
Internet-Draft NUD is too impatient Oct 2012
1. Introduction
IPv6 Neighbor Discovery [RFC4861] includes Neighbor Unreachability
Detection (NUD), which detects when a neighbor is no longer
reachable. The timeouts specified are very short (by default three
transmissions spaced one second apart). That can be appropriate when
there are alternative paths over which the packets can be sent. For
example, if a host has multiple default routers in its Default Router
List, or if the host has a Neighbor Cache Entry (NCE) created by a
Redirect message. The effect of NUD reporting a failure in those
cases is that the host will try the alternative; the next router in
the Default Router List, or discard the NCE which will also send
using a different router.
For that reason the timeouts in [RFC4861] were chosen to be short;
this ensures that if a default router fails the host can use the next
router in less than 45 seconds (taking into account a default
ReachableTime of 30 seconds and the time spent in the DELAY state).
However, when there is no alternative there are several benefits in
making NUD try probing for a longer time. One of those benefits is
to be more robust against transient failures, such as spanning tree
reconvergence and other layer 2 issues that can take many seconds to
Show full document text