idnits 2.17.1 draft-nordmark-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 7, 2011) is 4670 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) == Unused Reference: 'RFC4443' is defined on line 225, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 245, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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 Expires: January 8, 2012 I. Gashinsky 5 Yahoo! 6 July 7, 2011 8 Neighbor Unreachability Detection is too impatient 9 draft-nordmark-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. However, if there are no alternatives, this is 18 far too impatient. This document proposes an approach where an 19 implementation can choose the timeout behavior to be different based 20 on whether or not there are alternatives. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 8, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Proposed Remedy . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 63 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 IPv6 Neighbor Discovery [RFC4861] includes Neighbor Unreachability 69 Detection, which detects when a neighbor is no longer reachable. The 70 timeouts specified are very short (three transmissions spaced one 71 second apart). That can be appropriate when there are alternative 72 paths the packet can be sent. For example, if a host has multiple 73 default routers in its Default Router List, or if the host has a 74 Neigbor Cache Entry (NCE) created by a Redirect message. The effect 75 of NUD reporting a failure in those cases is that the host will try 76 the alternative; the next router in the Default Router List, or 77 discard the NCE which will also send using a different router. 79 For that reason the timeouts where chosen to be short; this ensures 80 that if a default router fails the host can use the next router in 81 less than 45 seconds. 83 However, where there is no alternative there are several benefits in 84 making NUD try probing for a longer time. One of those benefits is 85 to be more robust against transient failures, such as spanning tree 86 recovergence and other layer 2 issues that can take many seconds to 87 resolve. Marking the NCE as unreachable in that case causes 88 additional multicast on the network. Assuming there are IP packets 89 to send, the lack of an NCE will result in multicast Neighbor 90 Solicitations every second instead of the unicast Neighbor 91 Solicitations that NUD sends. 93 As a result IPv6 is operationally more brittle than IPv4. For IPv4 94 there is no mandatory time limit on the retransmission behavior for 95 ARP [RFC0826] which allows implementors to pick more robust schemes. 97 The following constant values in [RFC4861] seem to have been made 98 part of IPv6 conformance testing: MAX_MULTICAST_SOLICIT, 99 MAX_UNICAST_SOLICIT, RETRANS_TIMER. While such strict conformance 100 testing seems consistent with the the specificiation, it means that 101 we need to update the standard if we want to allow IPv6 Neighbor 102 Discovery to be as operationally robust as ARP. 104 Additional motivations for making IPv6 Neighbor Discovery as robust 105 as ARP are covered in [I-D.gashinsky-v6nd-enhance]. 107 2. Proposed Remedy 109 We can clarify that the giving up after three packets spaced one 110 second apart is only REQUIRED when there is an alternative, such as 111 an additional default route or a redirect. 113 If implementations transmit more than MAX_*CAST_SOLICIT packets they 114 MAY use binary exponential backoff of the retransmit timer. This is 115 so that if we end up with implementations that try for a very long 116 time we don't end up with a steady background level of 117 retransmissions. 119 However, even if there is no alternative, we still need to be able to 120 handle the case when the link-layer address of the destination has 121 changed. Thus at some point in time we need to switch to multicast 122 Neighbor Solicitations. 124 A possible way to describe a node behavior which captures all the 125 cases is to introduce a new, optional, UNREACHABLE state in the 126 conceptual model described in [RFC4861]. A NCE in the UNREACHABLE 127 state retains the link-layer address, and IPv6 packets continue to be 128 sent to that link-layer address. But the Neighbor Soliciations are 129 multicast, using a timeout that follows a binary exponential backoff. 131 In the places where RFC4861 says to to discard/delete the NCE after N 132 probes (Section 7.3, 7.3.3 and Appendix C) we will instead transition 133 to the UNREACHABLE state. 135 If the Neighbor Cache Entry was created by a redirect, a node MAY 136 delete the NCE instead of changing its state to UNREACHABLE. In any 137 case, the node SHOULD NOT use an NCE created by a Redirect to send 138 packets if that NCE is in unreachable state. Packets should be sent 139 following the next-hop selection algorithm in section XXX which 140 disregards NCEs that are not reachable. 142 The default router selection in section 6.3.6 says to prefer default 143 routers that are "known to be reachable". For the purposes of that 144 section, if the NCE for the router is in UNREACHABLE state, it is not 145 known to be reachable. Thus the particular text in section 6.3.6 146 which says "in any state other than INCOMPLETE" needs to be extended 147 to say "in any state other than INCOMPLETE or UNREACHABLE". 149 Apart from the use of multicast NS instead of unicast NS, and the 150 binary exponential backoff of the timer, the UNREACHABLE state works 151 the same as the current PROBE state. 153 A node MAY garbage collect a Neighbor Cache Entry as any time as 154 specified in RFC 4861. This does not change with the introduction of 155 the UNREACHABLE state in the coneptual model. 157 The UNREACHABLE state is conceptual and not a required part of this 158 specification. A node merely needs to satisfy the externally 159 observable behavior of this specificiation. 161 There is a non-obvious extension to the state machine description in 162 Appendix C in RFC 4861 in the case for "NA, Solicited=1, Override=0. 163 Different link-layer address than cached". There we need to add 164 "UNREACHABLE" to the current list of "STALE, PROBE, Or DELAY". That 165 is, the NCE would be unchanged. Note that there is no corresponding 166 change necessary to the text in section 7.2.5 since it is phrased 167 using "Otherwise" instead of explicitly listing the three states. 169 The other state transitions described in Appendix C handle the 170 introduction of the UNREACHABLE state without any change, since they 171 are described using "not INCOMPLETE". 173 There is also the more obvious change already described above. RFC 174 4861 has this: 176 PROBE Retransmit timeout, Discard entry - 177 N or more 178 retransmissions. 180 That needs to be replaced by: 182 PROBE Retransmit timeout, Double timeout UNREACHABLE 183 N or more Send multicast NS 184 retransmissions. 186 UNREACHABLE Retransmit timeout Double timeout UNREACHABLE 187 Send multicast NS 189 The binary exponential backoff SHOULD be clamped at some reasonable 190 maximum retransmit timeout, such as 60 seconds. And if there is no 191 IPv6 packets sent using the UNREACHABLE NCE, then it makes sense to 192 stop the retransmits of the multicast NS until either the NCE is 193 garbage collected, or there are IPv6 packets sent using the NCE. In 194 essence the multicast NS and associated binary exponential backoff 195 can be conditioned on the continued use of the NCE to send IPv6 196 packets to the recorded link-layer address. 198 A node MAY unicast the first few Neighbor Soliciation messages while 199 in UNREACHABLE state, but it MUST switch to multicast Neighbor 200 Soliciations. Otherwise it would not detect a link-layer address 201 change for the target. 203 3. Acknowledgements 205 The comments from Thomas Narten and Philip Homburg have helped 206 improve this draft. 208 4. Security Considerations 210 Relaxing the retransmission behavior for NUD has no impact on 211 security. In particular, it doesn't impact applying Secure Neighbor 212 Discovery [RFC3971]. 214 5. IANA Considerations 216 This are no IANA considerations for this document. 218 6. References 220 6.1. Normative References 222 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 223 Neighbor Discovery (SEND)", RFC 3971, March 2005. 225 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 226 Message Protocol (ICMPv6) for the Internet Protocol 227 Version 6 (IPv6) Specification", RFC 4443, March 2006. 229 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 230 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 231 September 2007. 233 6.2. Informative References 235 [I-D.gashinsky-v6nd-enhance] 236 Kumari, W., "Operational Neighbor Discovery Problems and 237 Enhancements.", draft-gashinsky-v6nd-enhance-00 (work in 238 progress), June 2011. 240 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 241 converting network protocol addresses to 48.bit Ethernet 242 address for transmission on Ethernet hardware", STD 37, 243 RFC 826, November 1982. 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, March 1997. 248 Authors' Addresses 250 Erik Nordmark 251 Cisco Systems, Inc. 252 510 McCarthy Blvd. 253 Milpitas, CA, 95035 254 USA 256 Phone: +1 408 527 6625 257 Email: nordmark@cisco.com 259 Igor Gashinsky 260 Yahoo! 261 45 W 18th St 262 New York, NY 263 USA 265 Email: igor@yahoo-inc.com