idnits 2.17.1 draft-ietf-6man-impatient-nud-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4861, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 12, 2012) is 4420 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN WG E. Nordmark 3 Internet-Draft Cisco Systems, Inc. 4 Updates: 4861 (if approved) I. Gashinsky 5 Expires: September 13, 2012 Yahoo! 6 March 12, 2012 8 Neighbor Unreachability Detection is too impatient 9 draft-ietf-6man-impatient-nud-01.txt 11 Abstract 13 IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. 14 That function is very useful when a host has an alternative, for 15 instance multiple default routers, since it allows the host to switch 16 to the alternative in short time. This time is 3 seconds after the 17 node starts probing by default. However, if there are no 18 alternatives, this is far too impatient. This document specifies 19 relaxed rules for Neighbor Discovery retransmissions that allows an 20 implementation to choose different timeout behavior based on whether 21 or not there are alternatives. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 13, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Protocol Updates . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Example Algorithm . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 IPv6 Neighbor Discovery [RFC4861] includes Neighbor Unreachability 72 Detection (NUD), which detects when a neighbor is no longer 73 reachable.The timeouts specified are very short (by default three 74 transmissions spaced one second apart). That can be appropriate when 75 there are alternative paths over which the packets can be sent. For 76 example, if a host has multiple default routers in its Default Router 77 List, or if the host has a Neighbor Cache Entry (NCE) created by a 78 Redirect message. The effect of NUD reporting a failure in those 79 cases is that the host will try the alternative; the next router in 80 the Default Router List, or discard the NCE which will also send 81 using a different router. 83 For that reason the timeouts in [RFC4861] were chosen to be short; 84 this ensures that if a default router fails the host can use the next 85 router in less than 45 seconds (taking into account a default 86 ReachableTime of 30 seconds and the time spent in the DELAY state). 88 However, when there is no alternative there are several benefits in 89 making NUD try probing for a longer time. One of those benefits is 90 to be more robust against transient failures, such as spanning tree 91 reconvergence and other layer 2 issues that can take many seconds to 92 resolve. Marking the NCE as unreachable in that case causes 93 additional multicast on the network. Assuming there are IP packets 94 to send, the lack of an NCE will result in multicast Neighbor 95 Solicitations every second instead of the unicast Neighbor 96 Solicitations that NUD sends. 98 As a result IPv6 is operationally more brittle than IPv4. For IPv4 99 there is no mandatory time limit on the retransmission behavior for 100 ARP [RFC0826] which allows implementors to pick more robust schemes. 102 The following constant values in [RFC4861] seem to have been made 103 part of IPv6 conformance testing: MAX_MULTICAST_SOLICIT, 104 MAX_UNICAST_SOLICIT, and RETRANS_TIMER. While such strict 105 conformance testing seems consistent with [RFC4861], it means that we 106 need to update the standard if we want to allow IPv6 Neighbor 107 Discovery to be as operationally robust as ARP. 109 This document updates RFC 4861 to relax the retransmission rules. 111 Additional motivations for making IPv6 Neighbor Discovery as robust 112 as ARP are covered in [I-D.gashinsky-v6nd-enhance]. 114 2. Definition Of Terms 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 3. Protocol Updates 122 Giving up after three packets spaced one second apart is only 123 REQUIRED when there is an alternative, such as an additional default 124 route or a redirect. 126 If implementations transmit more than MAX_*CAST_SOLICIT packets it 127 SHOULD use (binary) exponential backoff of the retransmit timer. 128 This is to avoid any significant load due to a steady background 129 level of retransmissions from implementations that try for a long 130 time. 132 However, even if there is no alternative, the protocol needs to be 133 able to handle the case when the link-layer address of the 134 destination has changed by switching to multicast Neighbor 135 Solicitations at some point in time. 137 In order to capture all the cases above this document introduces a 138 new UNREACHABLE state in the conceptual model described in [RFC4861]. 139 A NCE in the UNREACHABLE state retains the link-layer address, and 140 IPv6 packets continue to be sent to that link-layer address. But in 141 the UNREACHABLE state the NUD Neighbor Solicitations are multicast, 142 using a timeout that follows a (binary) exponential backoff. 144 In the places where RFC4861 says to to discard/delete the NCE after N 145 probes (Section 7.3, 7.3.3 and Appendix C) we will instead transition 146 to the UNREACHABLE state. 148 If the Neighbor Cache Entry was created by a redirect, a node MAY 149 delete the NCE instead of changing its state to UNREACHABLE. In any 150 case, the node SHOULD NOT use an NCE created by a Redirect to send 151 packets if that NCE is in unreachable state. Packets should be sent 152 following the next-hop selection algorithm in section 5.2 in 153 [RFC4861] which disregards NCEs that are not reachable. 155 The default router selection in section 6.3.6 says to prefer default 156 routers that are "known to be reachable". For the purposes of that 157 section, if the NCE for the router is in UNREACHABLE state, it is not 158 known to be reachable. Thus the particular text in section 6.3.6 159 which says "in any state other than INCOMPLETE" needs to be extended 160 to say "in any state other than INCOMPLETE or UNREACHABLE". 162 Apart from the use of multicast NS instead of unicast NS, and the 163 (binary) exponential backoff of the timer, the UNREACHABLE state 164 works the same as the current PROBE state. 166 A node MAY garbage collect a Neighbor Cache Entry as any time as 167 specified in RFC 4861. This does not change with the introduction of 168 the UNREACHABLE state in the conceptual model. 170 The UNREACHABLE state is conceptual and not a required part of this 171 specification. A node merely needs to satisfy the externally 172 observable behavior of this specification. 174 There is a non-obvious extension to the state machine description in 175 Appendix C in RFC 4861 in the case for "NA, Solicited=1, Override=0. 176 Different link-layer address than cached". There we need to add 177 "UNREACHABLE" to the current list of "STALE, PROBE, Or DELAY". That 178 is, the NCE would be unchanged. Note that there is no corresponding 179 change necessary to the text in section 7.2.5 since it is phrased 180 using "Otherwise" instead of explicitly listing the three states. 182 The other state transitions described in Appendix C handle the 183 introduction of the UNREACHABLE state without any change, since they 184 are described using "not INCOMPLETE". 186 There is also the more obvious change already described above. RFC 187 4861 has this: 189 PROBE Retransmit timeout, Discard entry - 190 N or more 191 retransmissions. 193 That needs to be replaced by: 195 PROBE Retransmit timeout, Double timeout UNREACHABLE 196 N or more Send multicast NS 197 retransmissions. 199 UNREACHABLE Retransmit timeout Double timeout UNREACHABLE 200 Send multicast NS 202 The binary exponential backoff SHOULD be clamped at some reasonable 203 maximum retransmit timeout, such as 60 seconds. And if there is no 204 IPv6 packets sent using the UNREACHABLE NCE, then it makes sense to 205 stop the retransmits of the multicast NS until either the NCE is 206 garbage collected, or there are IPv6 packets sent using the NCE. In 207 essence the multicast NS and associated binary exponential backoff 208 can be conditioned on the continued use of the NCE to send IPv6 209 packets to the recorded link-layer address. 211 A node MAY unicast the first few Neighbor Solicitation messages while 212 in UNREACHABLE state, but it MUST switch to multicast Neighbor 213 Solicitations. Otherwise it would not detect a link-layer address 214 change for the target. 216 4. Example Algorithm 218 This section is NOT normative, but specifies a simple implementation 219 which conforms with this document. The implementation is described 220 using operator configurable values that allows it to be configured in 221 a way to be compatible with the retransmission behavior in [RFC4861]. 222 The operator can configure the values for MAX_*CAST_SOLICIT, 223 RETRANS_TIMER, and the new BACKOFF_MULTIPLE and MARK_UNREACHABLE. 224 This allows the implementation to be as simple as: 226 next_retrans = ($BACKOFF_MULTIPLE^$solicit_attempt_num)*$RetransTimer 227 + jittered value. 229 After MARK_UNREACHABLE retransmissions the implementation would mark 230 the NCE UNREACHABLE and switch to multicast NUD probes. 232 The recommended behavior is to have 5 attempts, with timing spacing 233 of 0 (initial request), 1 second later, 3 seconds later, then 9, and 234 then 27, and switch to UNREACHABLE after 3 transmissions, which 235 represents: 237 MAX_UNICAST_SOLICIT=5 239 RETRANS_TIMER=1 (default) 241 BACKOFF_MULTIPLE=3 243 MARK_UNREACHABLE=3 245 After 3 retransmissions the implementation would mark the NCE 246 UNREACHABLE and switch to multicast NUD probes. Thus we enter 247 UNREACHABLE, and try any available alternative, after 4 seconds 248 compared to the current 2 seconds. That additional delay is small 249 compared to the default 30 seconds ReachableTime. 251 If BACKOFF_MULTIPLE=1, MARK_UNREACHABLE=3 and MAX_UNICAST_SOLICIT=3, 252 you would get the same behavior as in [RFC4861]. 254 An Implementation following this algorithm would, if the request was 255 not answered at first due for example to a transitory condition, 256 retry immediately, and then back off for progressively longer 257 periods. This would allow for a reasonably fast resolution time when 258 the transitory condition clears. 260 Note that RetransTimer and ReachableTime are by default set from the 261 protocol constants RETRANS_TIMER and REACHABLE_TIME, but are 262 overridden by values advertised in Router Advertisements as specified 263 in [RFC4861]. That remains the case even with the protocol updates 264 specified in this document. The key values that the operator would 265 configure are BACKOFF_MULTIPLE, MAX_UNICAST_SOLICIT and 266 MAX_MULTICAST_SOLICIT. 268 It would be useful to have a maximum value for 269 ($BACKOFF_MULTIPLE^$solicit_attempt_num)*$RetransTimer so that the 270 retransmissions are not too far apart. A value 60 seconds is 271 consistent with DHCP. 273 5. Acknowledgements 275 The comments from Thomas Narten and Philip Homburg have helped 276 improve this draft. 278 6. Security Considerations 280 Relaxing the retransmission behavior for NUD has no impact on 281 security. In particular, it doesn't impact applying Secure Neighbor 282 Discovery [RFC3971]. 284 7. IANA Considerations 286 This are no IANA considerations for this document. 288 8. References 290 8.1. Normative References 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 296 Neighbor Discovery (SEND)", RFC 3971, March 2005. 298 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 299 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 300 September 2007. 302 8.2. Informative References 304 [I-D.gashinsky-v6nd-enhance] 305 Kumari, W., "Operational Neighbor Discovery Problems and 306 Enhancements.", draft-gashinsky-v6nd-enhance-00 (work in 307 progress), June 2011. 309 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 310 converting network protocol addresses to 48.bit Ethernet 311 address for transmission on Ethernet hardware", STD 37, 312 RFC 826, November 1982. 314 Authors' Addresses 316 Erik Nordmark 317 Cisco Systems, Inc. 318 510 McCarthy Blvd. 319 Milpitas, CA, 95035 320 USA 322 Phone: +1 408 527 6625 323 Email: nordmark@cisco.com 325 Igor Gashinsky 326 Yahoo! 327 45 W 18th St 328 New York, NY 329 USA 331 Email: igor@yahoo-inc.com