idnits 2.17.1 draft-ietf-6man-impatient-nud-00.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 date (November 14, 2011) is 4539 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 (==), 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: May 17, 2012 I. Gashinsky 5 Yahoo! 6 November 14, 2011 8 Neighbor Unreachability Detection is too impatient 9 draft-ietf-6man-impatient-nud-00.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 May 17, 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. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Proposed Remedy . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 IPv6 Neighbor Discovery [RFC4861] includes Neighbor Unreachability 70 Detection, which detects when a neighbor is no longer reachable. The 71 timeouts specified are very short (three transmissions spaced one 72 second apart). That can be appropriate when there are alternative 73 paths the packet can be sent. For example, if a host has multiple 74 default routers in its Default Router List, or if the host has a 75 Neigbor Cache Entry (NCE) created by a Redirect message. The effect 76 of NUD reporting a failure in those cases is that the host will try 77 the alternative; the next router in the Default Router List, or 78 discard the NCE which will also send using a different router. 80 For that reason the timeouts where chosen to be short; this ensures 81 that if a default router fails the host can use the next router in 82 less than 45 seconds. 84 However, where there is no alternative there are several benefits in 85 making NUD try probing for a longer time. One of those benefits is 86 to be more robust against transient failures, such as spanning tree 87 recovergence and other layer 2 issues that can take many seconds to 88 resolve. Marking the NCE as unreachable in that case causes 89 additional multicast on the network. Assuming there are IP packets 90 to send, the lack of an NCE will result in multicast Neighbor 91 Solicitations every second instead of the unicast Neighbor 92 Solicitations that NUD sends. 94 As a result IPv6 is operationally more brittle than IPv4. For IPv4 95 there is no mandatory time limit on the retransmission behavior for 96 ARP [RFC0826] which allows implementors to pick more robust schemes. 98 The following constant values in [RFC4861] seem to have been made 99 part of IPv6 conformance testing: MAX_MULTICAST_SOLICIT, 100 MAX_UNICAST_SOLICIT, RETRANS_TIMER. While such strict conformance 101 testing seems consistent with the the specificiation, it means that 102 we need to update the standard if we want to allow IPv6 Neighbor 103 Discovery to be as operationally robust as ARP. 105 Additional motivations for making IPv6 Neighbor Discovery as robust 106 as ARP are covered in [I-D.gashinsky-v6nd-enhance]. 108 2. Definition Of Terms 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 3. Proposed Remedy 116 We can clarify that the giving up after three packets spaced one 117 second apart is only REQUIRED when there is an alternative, such as 118 an additional default route or a redirect. 120 If implementations transmit more than MAX_*CAST_SOLICIT packets they 121 MAY use binary exponential backoff of the retransmit timer. This is 122 so that if we end up with implementations that try for a very long 123 time we don't end up with a steady background level of 124 retransmissions. 126 However, even if there is no alternative, we still need to be able to 127 handle the case when the link-layer address of the destination has 128 changed. Thus at some point in time we need to switch to multicast 129 Neighbor Solicitations. 131 A possible way to describe a node behavior which captures all the 132 cases is to introduce a new, optional, UNREACHABLE state in the 133 conceptual model described in [RFC4861]. A NCE in the UNREACHABLE 134 state retains the link-layer address, and IPv6 packets continue to be 135 sent to that link-layer address. But the Neighbor Soliciations are 136 multicast, using a timeout that follows a binary exponential backoff. 138 In the places where RFC4861 says to to discard/delete the NCE after N 139 probes (Section 7.3, 7.3.3 and Appendix C) we will instead transition 140 to the UNREACHABLE state. 142 If the Neighbor Cache Entry was created by a redirect, a node MAY 143 delete the NCE instead of changing its state to UNREACHABLE. In any 144 case, the node SHOULD NOT use an NCE created by a Redirect to send 145 packets if that NCE is in unreachable state. Packets should be sent 146 following the next-hop selection algorithm in section XXX which 147 disregards NCEs that are not reachable. 149 The default router selection in section 6.3.6 says to prefer default 150 routers that are "known to be reachable". For the purposes of that 151 section, if the NCE for the router is in UNREACHABLE state, it is not 152 known to be reachable. Thus the particular text in section 6.3.6 153 which says "in any state other than INCOMPLETE" needs to be extended 154 to say "in any state other than INCOMPLETE or UNREACHABLE". 156 Apart from the use of multicast NS instead of unicast NS, and the 157 binary exponential backoff of the timer, the UNREACHABLE state works 158 the same as the current PROBE state. 160 A node MAY garbage collect a Neighbor Cache Entry as any time as 161 specified in RFC 4861. This does not change with the introduction of 162 the UNREACHABLE state in the coneptual model. 164 The UNREACHABLE state is conceptual and not a required part of this 165 specification. A node merely needs to satisfy the externally 166 observable behavior of this specificiation. 168 There is a non-obvious extension to the state machine description in 169 Appendix C in RFC 4861 in the case for "NA, Solicited=1, Override=0. 170 Different link-layer address than cached". There we need to add 171 "UNREACHABLE" to the current list of "STALE, PROBE, Or DELAY". That 172 is, the NCE would be unchanged. Note that there is no corresponding 173 change necessary to the text in section 7.2.5 since it is phrased 174 using "Otherwise" instead of explicitly listing the three states. 176 The other state transitions described in Appendix C handle the 177 introduction of the UNREACHABLE state without any change, since they 178 are described using "not INCOMPLETE". 180 There is also the more obvious change already described above. RFC 181 4861 has this: 183 PROBE Retransmit timeout, Discard entry - 184 N or more 185 retransmissions. 187 That needs to be replaced by: 189 PROBE Retransmit timeout, Double timeout UNREACHABLE 190 N or more Send multicast NS 191 retransmissions. 193 UNREACHABLE Retransmit timeout Double timeout UNREACHABLE 194 Send multicast NS 196 The binary exponential backoff SHOULD be clamped at some reasonable 197 maximum retransmit timeout, such as 60 seconds. And if there is no 198 IPv6 packets sent using the UNREACHABLE NCE, then it makes sense to 199 stop the retransmits of the multicast NS until either the NCE is 200 garbage collected, or there are IPv6 packets sent using the NCE. In 201 essence the multicast NS and associated binary exponential backoff 202 can be conditioned on the continued use of the NCE to send IPv6 203 packets to the recorded link-layer address. 205 A node MAY unicast the first few Neighbor Soliciation messages while 206 in UNREACHABLE state, but it MUST switch to multicast Neighbor 207 Soliciations. Otherwise it would not detect a link-layer address 208 change for the target. 210 4. Acknowledgements 212 The comments from Thomas Narten and Philip Homburg have helped 213 improve this draft. 215 5. Security Considerations 217 Relaxing the retransmission behavior for NUD has no impact on 218 security. In particular, it doesn't impact applying Secure Neighbor 219 Discovery [RFC3971]. 221 6. IANA Considerations 223 This are no IANA considerations for this document. 225 7. References 227 7.1. Normative References 229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, March 1997. 232 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 233 Neighbor Discovery (SEND)", RFC 3971, March 2005. 235 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 236 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 237 September 2007. 239 7.2. Informative References 241 [I-D.gashinsky-v6nd-enhance] 242 Kumari, W., "Operational Neighbor Discovery Problems and 243 Enhancements.", draft-gashinsky-v6nd-enhance-00 (work in 244 progress), June 2011. 246 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 247 converting network protocol addresses to 48.bit Ethernet 248 address for transmission on Ethernet hardware", STD 37, 249 RFC 826, November 1982. 251 Authors' Addresses 253 Erik Nordmark 254 Cisco Systems, Inc. 255 510 McCarthy Blvd. 256 Milpitas, CA, 95035 257 USA 259 Phone: +1 408 527 6625 260 Email: nordmark@cisco.com 262 Igor Gashinsky 263 Yahoo! 264 45 W 18th St 265 New York, NY 266 USA 268 Email: igor@yahoo-inc.com