idnits 2.17.00 (12 Aug 2021) /tmp/idnits1034/draft-nordmark-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 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 (May 23, 2011) is 4016 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 130, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 145, 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: November 24, 2011 May 23, 2011 6 Neighbor Unreachability Detection is too impatient 7 draft-nordmark-6man-impatient-nud-00.txt 9 Abstract 11 IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. 12 That function is very useful when a host has an alternative, for 13 instance multiple default routers, since it allows the host to switch 14 to the alternative in short time. This time is 3 seconds after the 15 node starts probing. However, if there are no alternatives, this is 16 far too impatient. This document proposes an approach where an 17 implementation can choose the timeout behavior to be different based 18 on whether or not there are alternatives. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 24, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Proposed Remedy . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5.1. Normative References . . . . . . . . . . . . . . . . . . . 4 60 5.2. Informative References . . . . . . . . . . . . . . . . . . 4 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1. Introduction 65 IPv6 Neighbor Discovery [RFC4861] includes Neighbor Unreachability 66 Detection, which detects when a neighbor is no longer reachable. The 67 timeouts specified are very short (three transmissions spaced one 68 second apart). That can be appropriate when there are alternative 69 paths the packet can be sent. For example, if a host has multiple 70 default routers in its Default Router List, or if the host has a 71 Neigbor Cache Entry (NCE) created by a Redirect message. The effect 72 of NUD reporting a failure in those cases is that the host will try 73 the alternative; the next router in the Default Router List, or 74 discard the NCE which will also send using a different router. 76 For that reason the timeouts where chosen to be short; this ensures 77 that if a default router fails the host can use the next router in 78 less than 45 seconds. 80 However, where there is no alternative there are several benefits in 81 making NUD try probing for a longer time. One of those benefits is 82 to be more robust against transient failures, such as spanning tree 83 recovergence and other layer 2 issues that can take many seconds to 84 resolve. Marking the NCE as unreachable in that case causes 85 additional multicast on the network. Assuming there are IP packets 86 to send, the lack of an NCE will result in multicast Neighbor 87 Solicitations every second instead of the unicast Neighbor 88 Solicitations that NUD sends. 90 As a result IPv6 is operationally more brittle than IPv4. For IPv4 91 there is no mandatory time limit on the retransmission behavior for 92 ARP [RFC0826] which allows implementors to pick more robust schemes. 94 The following constant values in [RFC4861] seem to have been made 95 part of IPv6 conformance testing: MAX_MULTICAST_SOLICIT, 96 MAX_UNICAST_SOLICIT, RETRANS_TIMER. While such strict conformance 97 testing seems consistent with the the specificiation, it means that 98 we need to update the standard if we want to allow IPv6 Neighbor 99 Discovery to be as operationally robust as ARP. 101 2. Proposed Remedy 103 We can clarify that the giving up after three packets spaced one 104 second apart is only REQUIRED when there is an alternative, such as 105 an additional default route or a redirect. 107 If implementations transmit more than MAX_*CAST_SOLICIT packets they 108 MAY use binary exponential backoff of the retransmit timer. This is 109 so that if we end up with implementations that try for a very long 110 time we don't end up with a steady background level of 111 retransmissions. 113 3. Security Considerations 115 Relaxing the retransmission behavior for NUD has no impact on 116 security. In particular, it doesn't impact applying Secure Neighbor 117 Discovery [RFC3971]. 119 4. IANA Considerations 121 This are no IANA considerations for this document. 123 5. References 125 5.1. Normative References 127 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 128 Neighbor Discovery (SEND)", RFC 3971, March 2005. 130 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 131 Message Protocol (ICMPv6) for the Internet Protocol 132 Version 6 (IPv6) Specification", RFC 4443, March 2006. 134 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 135 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 136 September 2007. 138 5.2. Informative References 140 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 141 converting network protocol addresses to 48.bit Ethernet 142 address for transmission on Ethernet hardware", STD 37, 143 RFC 826, November 1982. 145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 146 Requirement Levels", BCP 14, RFC 2119, March 1997. 148 Author's Address 150 Erik Nordmark 151 Cisco Systems, Inc. 152 510 McCarthy Blvd. 153 Milpitas, CA, 95035 154 USA 156 Phone: +1 408 527 6625 157 Email: nordmark@cisco.com