draft-ietf-6man-impatient-nud-05.txt   draft-ietf-6man-impatient-nud-06.txt 
6MAN WG E. Nordmark 6MAN WG E. Nordmark
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Updates: 4861 (if approved) I. Gashinsky Updates: 4861 (if approved) I. Gashinsky
Intended status: Standards Track Yahoo! Intended status: Standards Track Yahoo!
Expires: April 4, 2013 Oct 2012 Expires: October 26, 2013 April 24, 2013
Neighbor Unreachability Detection is too impatient Neighbor Unreachability Detection is too impatient
draft-ietf-6man-impatient-nud-05.txt draft-ietf-6man-impatient-nud-06.txt
Abstract Abstract
IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. IPv6 Neighbor Discovery includes Neighbor Unreachability Detection.
That function is very useful when a host has an alternative, for That function is very useful when a host has an alternative neighbor,
instance multiple default routers, since it allows the host to switch for instance when there are multiple default routers, since it allows
to the alternative in short time. This time is 3 seconds after the the host to switch to the alternative neighbor in short time. This
node starts probing by default. However, if there are no time is 3 seconds after the node starts probing by default. However,
alternatives, this is far too impatient. This document specifies if there are no alternative neighbors, this is far too impatient.
relaxed rules for Neighbor Discovery retransmissions that allows an This document specifies relaxed rules for Neighbor Discovery
implementation to choose different timeout behavior based on whether retransmissions that allow an implementation to choose different
or not there are alternatives. This document updates RFC 4861. timeout behavior based on whether or not there are alternative
neighbors. This document updates RFC 4861.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 4, 2013. This Internet-Draft will expire on October 26, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . . 4 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Updates . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Updates . . . . . . . . . . . . . . . . . . . . . . . 4
4. Example Algorithm . . . . . . . . . . . . . . . . . . . . . . . 6 4. Example Algorithm . . . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
IPv6 Neighbor Discovery [RFC4861] includes Neighbor Unreachability IPv6 Neighbor Discovery [RFC4861] includes Neighbor Unreachability
Detection (NUD), which detects when a neighbor is no longer Detection (NUD), which detects when a neighbor is no longer
reachable. The timeouts specified are very short (by default three reachable. The timeouts specified for NUD are very short (by default
transmissions spaced one second apart). That can be appropriate when three transmissions spaced one second apart). These short can be
there are alternative paths over which the packets can be sent. For appropriate when there are alternative neighbors to which the packets
example, if a host has multiple default routers in its Default Router can be sent. For example, if a host has multiple default routers in
List, or if the host has a Neighbor Cache Entry (NCE) created by a its Default Router List, or if the host has a Neighbor Cache Entry
Redirect message. The effect of NUD reporting a failure in those (NCE) created by a Redirect message. In these cases, when NUD fails,
cases is that the host will try the alternative; the next router in the host will try the alternative neighbor; the next router in the
the Default Router List, or discard the NCE which will also send Default Router List, or discard the NCE which will also send using a
using a different router. different router.
For that reason the timeouts in [RFC4861] were chosen to be short; The timeouts specified in [RFC4861] were chosen to be short in order
this ensures that if a default router fails the host can use the next to optimize for the scenarios where alternative neighbors are
router in less than 45 seconds (taking into account a default available.
ReachableTime of 30 seconds and the time spent in the DELAY state).
However, when there is no alternative there are several benefits in However, when there is no alternative neighbor there are several
making NUD try probing for a longer time. One of those benefits is benefits in making NUD try probing for a longer time. One of those
to be more robust against transient failures, such as spanning tree benefits is to make NUD more robust against transient failures, such
reconvergence and other layer 2 issues that can take many seconds to as spanning tree reconvergence and other layer 2 issues that can take
resolve. Marking the NCE as unreachable in that case causes many seconds to resolve. Marking the NCE as unreachable in that case
additional multicast on the network. Assuming there are IP packets causes additional multicast on the network. Assuming there are IP
to send, the lack of an NCE will result in multicast Neighbor packets to send, the lack of an NCE will result in multicast Neighbor
Solicitations every second instead of the unicast Neighbor Solicitations being sent (to the solicited-node multicast address)
Solicitations that NUD sends. every second instead of the unicast Neighbor Solicitations that NUD
sends.
As a result IPv6 Neighbor Discovery is operationally more brittle As a result IPv6 Neighbor Discovery is operationally more brittle
than IPv4 ARP. For IPv4 there is no mandatory time limit on the than IPv4 ARP. For IPv4 there is no mandatory time limit on the
retransmission behavior for ARP [RFC0826] which allows implementors retransmission behavior for ARP [RFC0826] which allows implementors
to pick more robust schemes. to pick more robust schemes.
The following constant values in [RFC4861] seem to have been made The following constant values in [RFC4861] seem to have been made
part of IPv6 conformance testing: MAX_MULTICAST_SOLICIT, part of IPv6 conformance testing: MAX_MULTICAST_SOLICIT,
MAX_UNICAST_SOLICIT, and RETRANS_TIMER. While such strict MAX_UNICAST_SOLICIT, and RETRANS_TIMER. While such strict
conformance testing seems consistent with [RFC4861], it means that we conformance testing seems consistent with [RFC4861], it means that
need to update the standard if we want to allow IPv6 Neighbor the standard needs to be updated to allow IPv6 Neighbor Discovery to
Discovery to be as robust as ARP. be as robust as ARP.
This document updates RFC 4861 to relax the retransmission rules. This document updates RFC 4861 to relax the retransmission rules.
Additional motivations for making IPv6 Neighbor Discovery more robust Additional motivations for making IPv6 Neighbor Discovery more robust
in the face of degenerate conditions are covered in [RFC6583]. in the face of degenerate conditions are covered in [RFC6583].
2. Definition Of Terms 2. Definition Of Terms
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Protocol Updates 3. Protocol Updates
Giving up after three packets spaced one second apart is only Giving up after three packets spaced one second apart is only needed
REQUIRED when there is an alternative, such as an additional default when an alternative neighbor is available, such as an additional
router or a redirect. default router or a redirect.
If implementations transmit more than MAX_*CAST_SOLICIT packets it If implementations transmit more than MAX_UNICAST_SOLICIT/
SHOULD use (binary) exponential backoff of the retransmit timer. MAX_MULTICAST_SOLICIT packets it SHOULD use exponential backoff of
This is to avoid any significant load due to a steady background the retransmit timer. This is to avoid any significant load due to a
level of retransmissions from implementations that try for a long steady background level of retransmissions from implementations that
time. try for a long time.
Even if there is no alternative, the protocol needs to be able to Even if there is no alternative neighbor, the protocol needs to be
handle the case when the link-layer address of the destination has able to handle the case when the link-layer address of the
changed by switching to multicast Neighbor Solicitations at some destination has changed by switching to multicast Neighbor
point in time. Solicitations at some point in time.
In order to capture all the cases above this document introduces a In order to capture all the cases above this document introduces a
new UNREACHABLE state in the conceptual model described in [RFC4861]. new UNREACHABLE state in the conceptual model described in [RFC4861].
A NCE in the UNREACHABLE state retains the link-layer address, and A NCE in the UNREACHABLE state retains the link-layer address, and
IPv6 packets continue to be sent to that link-layer address. But in IPv6 packets continue to be sent to that link-layer address. But in
the UNREACHABLE state the NUD Neighbor Solicitations are multicast, the UNREACHABLE state the NUD Neighbor Solicitations are multicast
using a timeout that follows a (binary) exponential backoff. (to the solicited-node multicast address), using a timeout that
follows an exponential backoff.
In the places where RFC4861 says to to discard/delete the NCE after N In the places where RFC4861 says to to discard/delete the NCE after N
probes (Section 7.3, 7.3.3 and Appendix C) we will instead transition probes (Section 7.3, 7.3.3 and Appendix C) we will instead transition
to the UNREACHABLE state. to the UNREACHABLE state.
If the Neighbor Cache Entry was created by a redirect, a node MAY If the Neighbor Cache Entry was created by a redirect, a node MAY
delete the NCE instead of changing its state to UNREACHABLE. In any delete the NCE instead of changing its state to UNREACHABLE. In any
case, the node SHOULD NOT use an NCE created by a Redirect to send case, the node SHOULD NOT use an NCE created by a Redirect to send
packets if that NCE is in UNREACHABLE state. Packets should be sent packets if that NCE is in UNREACHABLE state. Packets should be sent
following the next-hop selection algorithm in section 5.2 in following the next-hop selection algorithm in section 5.2 in
[RFC4861] which disregards NCEs that are not reachable. [RFC4861] which disregards NCEs that are not reachable.
The default router selection in section 6.3.6 says to prefer default The default router selection in section 6.3.6 says to prefer default
routers that are "known to be reachable". For the purposes of that routers that are "known to be reachable". For the purposes of that
section, if the NCE for the router is in UNREACHABLE state, it is not section, if the NCE for the router is in UNREACHABLE state, it is not
known to be reachable. Thus the particular text in section 6.3.6 known to be reachable. Thus the particular text in section 6.3.6
which says "in any state other than INCOMPLETE" needs to be extended which says "in any state other than INCOMPLETE" needs to be extended
to say "in any state other than INCOMPLETE or UNREACHABLE". to say "in any state other than INCOMPLETE or UNREACHABLE".
Apart from the use of multicast NS instead of unicast NS, and the Apart from the use of multicast NS instead of unicast NS, and the
(binary) exponential backoff of the timer, the UNREACHABLE state exponential backoff of the timer, the UNREACHABLE state works the
works the same as the current PROBE state. same as the current PROBE state.
A node MAY garbage collect a Neighbor Cache Entry at any time as A node MAY garbage collect a Neighbor Cache Entry at any time as
specified in RFC 4861. This does not change with the introduction of specified in RFC 4861. This does not change with the introduction of
the UNREACHABLE state in the conceptual model. the UNREACHABLE state in the conceptual model.
The UNREACHABLE state is conceptual and not a required part of this
specification. Just as for [RFC4861] a node merely needs to satisfy
the externally observable behavior of this specification.
There is a non-obvious extension to the state machine description in There is a non-obvious extension to the state machine description in
Appendix C in RFC 4861 in the case for "NA, Solicited=1, Override=0. Appendix C in RFC 4861 in the case for "NA, Solicited=1, Override=0.
Different link-layer address than cached". There we need to add Different link-layer address than cached". There we need to add
"UNREACHABLE" to the current list of "STALE, PROBE, Or DELAY". That "UNREACHABLE" to the current list of "STALE, PROBE, Or DELAY". That
is, the NCE would be unchanged. Note that there is no corresponding is, the NCE would be unchanged. Note that there is no corresponding
change necessary to the text in section 7.2.5 since it is phrased change necessary to the text in section 7.2.5 since it is phrased
using "Otherwise" instead of explicitly listing the three states. using "Otherwise" instead of explicitly listing the three states.
The other state transitions described in Appendix C handle the The other state transitions described in Appendix C handle the
introduction of the UNREACHABLE state without any change, since they introduction of the UNREACHABLE state without any change, since they
are described using "not INCOMPLETE". are described using "not INCOMPLETE".
There is also the more obvious change already described above. RFC There is also the more obvious change already described above. RFC
4861 has this: 4861 has this:
State Event Action New state
PROBE Retransmit timeout, Discard entry - PROBE Retransmit timeout, Discard entry -
N or more N or more
retransmissions. retransmissions.
That needs to be replaced by: That needs to be replaced by:
State Event Action New state
PROBE Retransmit timeout, Increase timeout UNREACHABLE PROBE Retransmit timeout, Increase timeout UNREACHABLE
N or more Send multicast NS N or more Send multicast NS
retransmissions. retransmissions.
UNREACHABLE Retransmit timeout Increase timeout UNREACHABLE UNREACHABLE Retransmit timeout Increase timeout UNREACHABLE
Send multicast NS Send multicast NS
The (binary) exponential backoff SHOULD be clamped at some reasonable The exponential backoff SHOULD be clamped at some reasonable maximum
maximum retransmit timeout, such as 60 seconds (see MAX_RETRANS_TIMER retransmit timeout, such as 60 seconds (see MAX_RETRANS_TIMER below).
below). If there is no IPv6 packet sent using the UNREACHABLE NCE, If there is no IPv6 packet sent using the UNREACHABLE NCE, then it
then it makes sense to stop the retransmits of the multicast NS until makes sense to stop the retransmits of the multicast NS until either
either the NCE is garbage collected or there are IPv6 packets sent the NCE is garbage collected or there are IPv6 packets sent using the
using the NCE. The multicast NS and associated binary exponential NCE. The multicast NS and associated exponential backoff can be
backoff can be applied on the condition of the continued use of the applied on the condition of the continued use of the NCE to send IPv6
NCE to send IPv6 packets to the recorded link-layer address. packets to the recorded link-layer address.
A node MAY unicast the first few Neighbor Solicitation messages even A node MAY unicast the first few Neighbor Solicitation messages even
while in UNREACHABLE state, but it MUST switch to multicast Neighbor while in UNREACHABLE state, but it MUST switch to multicast Neighbor
Solicitations sooner or later. Otherwise it would not detect a link- Solicitations sooner or later. Otherwise it would not detect a link-
layer address change for the target. The example below shows such layer address change for the target. The example below shows such
behavior. behavior.
4. Example Algorithm 4. Example Algorithm
This section is NOT normative, but specifies a simple implementation This section is NOT normative, but specifies a simple implementation
which conforms with this document. The implementation is described which conforms with this document. The implementation is described
using operator configurable values that allows it to be configured in using operator configurable values that allows it to be configured in
a way to be compatible with the retransmission behavior in [RFC4861]. a way to be compatible with the retransmission behavior in [RFC4861].
The operator can configure the values for MAX_*CAST_SOLICIT, The operator can configure the values for MAX_UNICAST_SOLICIT,
RETRANS_TIMER, and the new BACKOFF_MULTIPLE, MAX_RETRANS_TIMER and MAX_MULTICAST_SOLICIT, RETRANS_TIMER, and the new BACKOFF_MULTIPLE,
MARK_UNREACHABLE. This allows the implementation to be as simple as: MAX_RETRANS_TIMER and MARK_UNREACHABLE. This allows the
implementation to be as simple as:
next_retrans = ($BACKOFF_MULTIPLE^$solicit_attempt_num)*$RetransTimer next_retrans = ($BACKOFF_MULTIPLE ^ $solicit_retrans_num) *
+ jittered value. $RetransTimer * $JitterFactor where solicit_retrans_num is zero for
the first transmission, and JitterFactor is a random value between
MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR [RFC4861] to avoid any
synchronization of transmissions from different hosts.
After MARK_UNREACHABLE transmissions the implementation would mark After MARK_UNREACHABLE transmissions the implementation would mark
the NCE UNREACHABLE and as result explore alternate next hops. After the NCE UNREACHABLE and as result explore alternate next hops. After
MAX_UNICAST_SOLICIT the implementation would switch to multicast NUD MAX_UNICAST_SOLICIT the implementation would switch to multicast NUD
probes. probes.
The recommended behavior is to have 5 attempts, with timing spacing The recommended behavior is to have 5 attempts, with timing spacing
of 0 (initial request), 1 second later, 3 seconds after the first of 0 (initial request), 1 second later, 3 seconds after the first
retransmission, then 9, then 27, and switch to UNREACHABLE after the retransmission, then 9, then 27, and switch to UNREACHABLE after the
first three transmissions. Thus relative to the time of the first first three transmissions. Thus relative to the time of the first
skipping to change at page 6, line 43 skipping to change at page 7, line 4
transmissions the retransmissions would occur at 1 second, 4 seconds, transmissions the retransmissions would occur at 1 second, 4 seconds,
13 seconds, and finally 40 seconds. At 4 seconds from the first 13 seconds, and finally 40 seconds. At 4 seconds from the first
transmission the NCE would be marked UNREACHABLE. That recommended transmission the NCE would be marked UNREACHABLE. That recommended
behavior corresponds to: behavior corresponds to:
MAX_UNICAST_SOLICIT=5 MAX_UNICAST_SOLICIT=5
RETRANS_TIMER=1 (default) RETRANS_TIMER=1 (default)
MAX_RETRANS_TIMER=60 MAX_RETRANS_TIMER=60
BACKOFF_MULTIPLE=3 BACKOFF_MULTIPLE=3
MARK_UNREACHABLE=3 MARK_UNREACHABLE=3
After 3 retransmissions the implementation would mark the NCE After 3 retransmissions the implementation would mark the NCE
UNREACHABLE. That results in trying an alternative, such as another UNREACHABLE. That results in trying an alternative neighbor, such as
default router or ignoring a redirect as specified in [RFC4861]. another default router or ignoring a redirect as specified in
With the above recommended values that would occur after 4 seconds [RFC4861]. With the above recommended values that would occur after
after the first transmission compared to the 2 seconds using the 4 seconds after the first transmission compared to the 2 seconds
fixed scheme in [RFC4861]. That additional delay is small compared using the fixed scheme in [RFC4861]. That additional delay is small
to the default 30 seconds ReachableTime. compared to the default 30,000 milliseconds ReachableTime.
After 5 transmissions, i.e., 40 seconds after the initial After 5 transmissions, i.e., 40 seconds after the initial
transmission, the recommended behavior is to switch to multicast NUD transmission, the recommended behavior is to switch to multicast NUD
probes. In the language of the state machine in [RFC4861] says that probes. In the language of the state machine in [RFC4861] that
a node MAY send unsolicited NS to handle that case, which is rather corresponds to the action "Discard entry". Thus any attempts to send
infrequent in operational networks. future packets would result in sending multicast NS packets. An
implementation MAY retain the backoff value as it switches to
multicast NUD probes. The potential downside of deferring switching
to multicast is that it would take longer for NUD to handle a change
in a link-layer address i.e., the case when a host or a router
changes their link-layer address while keeping the same IPv6 address.
However, [RFC4861] says that a node MAY send unsolicited NS to handle
that case, which is rather infrequent in operational networks.
If BACKOFF_MULTIPLE=1, MARK_UNREACHABLE=3 and MAX_UNICAST_SOLICIT=3, If BACKOFF_MULTIPLE=1, MARK_UNREACHABLE=3 and MAX_UNICAST_SOLICIT=3,
you would get the same behavior as in [RFC4861]. you would get the same behavior as in [RFC4861].
An implementation following this algorithm would, if the request was An implementation following this algorithm would, if the request was
not answered at first due for example to a transitory condition, not answered at first due for example to a transitory condition,
retry immediately, and then back off for progressively longer retry immediately, and then back off for progressively longer
periods. This would allow for a reasonably fast resolution time when periods. This would allow for a reasonably fast resolution time when
the transitory condition clears. the transitory condition clears.
skipping to change at page 7, line 39 skipping to change at page 8, line 8
MAX_UNICAST_SOLICIT and MAX_MULTICAST_SOLICIT. MAX_UNICAST_SOLICIT and MAX_MULTICAST_SOLICIT.
It is be useful to have a maximum value for It is be useful to have a maximum value for
($BACKOFF_MULTIPLE^$solicit_attempt_num)*$RetransTimer so that the ($BACKOFF_MULTIPLE^$solicit_attempt_num)*$RetransTimer so that the
retransmissions are not too far apart. The recommended value of 60 retransmissions are not too far apart. The recommended value of 60
seconds for this MAX_RETRANS_TIMER is consistent with DHCPv6. seconds for this MAX_RETRANS_TIMER is consistent with DHCPv6.
5. Acknowledgements 5. Acknowledgements
The comments from Thomas Narten, Philip Homburg, Joel Jaeggli, Hemant The comments from Thomas Narten, Philip Homburg, Joel Jaeggli, Hemant
Singh, and Tina Tsou have helped improve this draft. Singh, Tina Tsou, and Suresh Krishnan have helped improve this draft.
6. Security Considerations 6. Security Considerations
Relaxing the retransmission behavior for NUD is believed to have no Relaxing the retransmission behavior for NUD is believed to have no
impact on security. In particular, it doesn't impact the application impact on security. In particular, it doesn't impact the application
Secure Neighbor Discovery [RFC3971]. Secure Neighbor Discovery [RFC3971].
7. IANA Considerations 7. IANA Considerations
This are no IANA considerations for this document. This are no IANA considerations for this document.
 End of changes. 25 change blocks. 
83 lines changed or deleted 95 lines changed or added

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