idnits 2.17.1 draft-ietf-6man-maxra-04.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 issues found here. 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 (November 28, 2017) is 2312 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 (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance S. Krishnan 3 Internet-Draft Kaloom 4 Updates: 4861 (if approved) J. Korhonen 5 Intended status: Standards Track Broadcom 6 Expires: June 1, 2018 S. Chakrabarti 7 Ericsson 8 E. Nordmark 9 Arista Networks 10 A. Yourtchenko 11 cisco 12 November 28, 2017 14 Support for adjustable maximum router lifetimes per-link 15 draft-ietf-6man-maxra-04 17 Abstract 19 The IPv6 Neighbor Discovery protocol specifies the maximum time 20 allowed between sending unsolicited multicast Router Advertisements 21 from a router interface as well as the maximum router lifetime. It 22 also allows the limits to be overridden by link-layer specific 23 documents. This document allows for overriding these values on a 24 per-link basis. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 1, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Relationship between AdvDefaultLifetime and MaxRtrAdvInterval 3 63 4. Updates to RFC4861 . . . . . . . . . . . . . . . . . . . . . 4 64 5. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 9.2. Informative References . . . . . . . . . . . . . . . . . 5 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 73 1. Introduction 75 IPv6 Neighbor Discovery relies on IP multicast based on the 76 expectation that multicast makes efficient use of available bandwidth 77 and avoids generating interrupts in the network nodes. On some 78 datalink layers multicast may not be natively supported. On such 79 links, any possible reduction of multicast traffic will be highly 80 beneficial. Unfortunately, due to the fixed protocol constants 81 specified in [RFC4861], it is difficult to relax the multicast timers 82 for neighbor discovery. There are already link technology specific 83 clarifications describing how to tune the Neighbor Discovery Protocol 84 (NDP) constants for certain systems with in order to reduce excess 85 NDP traffic. e.g. [RFC6459][RFC7066] contain such clarifications for 86 3GPP cellular links. 88 This document specifies updates to the IPv6 Neighbor Discovery 89 Protocol [RFC4861] for increasing the the maximum time allowed 90 between sending unsolicited multicast Router Advertisements (RA) from 91 a router interface as well as for the maximum router lifetime. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Relationship between AdvDefaultLifetime and MaxRtrAdvInterval 101 MaxRtrAdvInterval is an upper bound on the time between which two 102 successive Router Advertisement messages are sent. Therefore one 103 might reason about the relationship between these two values in terms 104 of a ratio K=AdvDefaultLifetime/MaxRtrAdvInterval, which expresses 105 how many Router Advertisements will be guaranteed to be sent before 106 the router lifetime expires. 108 Assuming unicast Solicited Router Advertisements or a perfectly 109 stable network, on a theoretically perfect link with no losses, it 110 would have been sufficient to have K just above 1 - so that the sent 111 Router Advertisement refreshes the router entry just before it 112 expires. On the real links which allow for some loss, one would need 113 to use K>2 in order to minimize the chances of a single router 114 advertisement loss causing a loss of the router entry. 116 The exact calculation will depend on the packet loss probability. An 117 example: if we take a ballpark value of 1% probability of a packet 118 loss, then K=2 will give 0.01% percent chance of an outage due to a 119 packet loss, K=3 will give 0.0001% chance of an outage, and so forth. 120 To reverse the numbers, with these parameters, K~=1 gives 99% 121 reliability, K~=2 gives 99.99% reliability, and K~=3 gives 99.9999% 122 reliability - the latter should be good enough for a lot of 123 scenarios. 125 In a network with higher packet loss probabilities or if the higher 126 reliability is desired, the K might be chosen to be even higher. On 127 the other hand, some of the data link layers provide reliable 128 delivery at layer 2 - so there one might even consider using the 129 "theoretical" value of K just above 1. Since the choice of these two 130 parameters does not impact interoperability per se, this document 131 does not impose any specific constraints on their values other than 132 providing the guidelines in this section, therefore each individual 133 link can optimize accordingly to its use case. 135 Also AdvDefaultLifetime MUST be set to a value greater than or equal 136 to the selected MaxRtrAdvInterval. Otherwise, a router lifetime is 137 guaranteed to expire before the new Router Advertisement has a chance 138 to be sent, thereby creating an outage. 140 4. Updates to RFC4861 142 This document updates Section 4.2 and Section 6.2.1. of [RFC4861] to 143 update the following router configuration variables. 145 In Section 4.2, inside the paragraph that defines Router Lifetime, 146 change 9000 to 65535 seconds. 148 In Section 6.2.1, inside the paragraph that defines 149 MaxRtrAdvInterval, change 1800 to 65535 seconds. 151 In Section 6.2.1, inside the paragraph that defines 152 AdvDefaultLifetime, change 9000 to 65535 seconds. 154 As explained in Section 3, the relationship between MaxRtrAdvInterval 155 and AdvDefaultLifetime must be chosen to take into account the 156 probability of packet loss. 158 5. Host Behavior 160 Legacy hosts on a link with updated routers may have issues with a 161 Router Lifetime of more than 9000 seconds. In the few 162 implementations we have tested with general purpose operating 163 systems, there does not seem to be any issues with setting this field 164 to more than 9000, but there might be implementations that 165 incorrectly (since RFC4861 requires receivers to handle any value) 166 reject such RAs. 168 6. Security Considerations 170 On a link where router advertisements are few and far between, the 171 detrimental effects of a rogue router that sends an unsolicited RA 172 are greatly increased. These rogue RAs can be prevented by using 173 approaches like RA-Guard [RFC6105] and SeND [RFC3971] 175 7. IANA Considerations 177 This document does not require any IANA action. 179 8. Acknowledgements 181 The authors would like to thank the members of the 6man efficient ND 182 design team for their comments that led to the creation of this 183 draft. The authors would also like to thank Lorenzo Colitti, Erik 184 Kline, Jeena Rachel John, Brian Carpenter, Tim Chown, Fernando Gont, 185 Warren Kumari and Adam Roach for their comments and suggestions that 186 improved this document. 188 9. References 190 9.1. Normative References 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, 194 DOI 10.17487/RFC2119, March 1997, 195 . 197 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 198 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 199 DOI 10.17487/RFC4861, September 2007, 200 . 202 9.2. Informative References 204 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 205 "SEcure Neighbor Discovery (SEND)", RFC 3971, 206 DOI 10.17487/RFC3971, March 2005, 207 . 209 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 210 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 211 DOI 10.17487/RFC6105, February 2011, 212 . 214 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 215 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 216 Partnership Project (3GPP) Evolved Packet System (EPS)", 217 RFC 6459, DOI 10.17487/RFC6459, January 2012, 218 . 220 [RFC7066] Korhonen, J., Ed., Arkko, J., Ed., Savolainen, T., and S. 221 Krishnan, "IPv6 for Third Generation Partnership Project 222 (3GPP) Cellular Hosts", RFC 7066, DOI 10.17487/RFC7066, 223 November 2013, . 225 Authors' Addresses 227 Suresh Krishnan 228 Kaloom 229 335 Rue Peel 230 Montreal, QC 231 Canada 233 Email: suresh@kaloom.com 234 Jouni Korhonen 235 Broadcom 236 Porkkalankatu 24 237 FIN-00180 Helsinki 238 Finland 240 Email: jouni.nospam@gmail.com 242 Samita Chakrabarti 243 Ericsson 244 USA 246 Email: samita.chakrabarti@ericsson.com 248 Erik Nordmark 249 Arista Networks 250 Santa Clara, CA 251 USA 253 Email: nordmark@acm.org 255 Andrew Yourtchenko 256 cisco 257 6b de Kleetlaan 258 Diegem 1831 259 Belgium 261 Email: ayourtch@cisco.com