summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8319.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8319.txt')
-rw-r--r--doc/rfc/rfc8319.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc8319.txt b/doc/rfc/rfc8319.txt
new file mode 100644
index 0000000..5db1883
--- /dev/null
+++ b/doc/rfc/rfc8319.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Krishnan
+Request for Comments: 8319 Kaloom
+Updates: 4861 J. Korhonen
+Category: Standards Track Nordic Semiconductor ASA
+ISSN: 2070-1721 S. Chakrabarti
+ Verizon
+ E. Nordmark
+ Zededa
+ A. Yourtchenko
+ Cisco
+ February 2018
+
+
+ Support for Adjustable Maximum Router Lifetimes per Link
+
+Abstract
+
+ The IPv6 Neighbor Discovery protocol specifies the maximum time
+ allowed between sending unsolicited multicast Router Advertisements
+ (RAs) from a router interface as well as the maximum router lifetime.
+ It also allows the limits to be overridden by documents that are
+ specific to the link layer. This document allows for overriding
+ these values on a per-link basis.
+
+ This document specifies updates to the IPv6 Neighbor Discovery
+ Protocol (RFC 4861) to increase the maximum time allowed between
+ sending unsolicited multicast RAs from a router interface as well as
+ to increase the maximum router lifetime.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8319.
+
+
+
+
+
+
+
+
+
+Krishnan, et al. Standards Track [Page 1]
+
+RFC 8319 Adjustable Router Lifetimes February 2018
+
+
+Copyright Notice
+
+ Copyright (c) 2018 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Relationship between AdvDefaultLifetime and MaxRtrAdvInterval 3
+ 4. Updates to RFC 4861 . . . . . . . . . . . . . . . . . . . . . 4
+ 5. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 5
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 6
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krishnan, et al. Standards Track [Page 2]
+
+RFC 8319 Adjustable Router Lifetimes February 2018
+
+
+1. Introduction
+
+ IPv6 Neighbor Discovery relies on IP multicast based on the
+ expectation that multicast makes efficient use of available bandwidth
+ and avoids generating interrupts in the network nodes. On some data
+ link layers, multicast may not be natively supported. On such links,
+ any possible reduction of multicast traffic will be highly
+ beneficial. Unfortunately, due to the fixed protocol constants
+ specified in [RFC4861], it is difficult to relax the multicast timers
+ for Neighbor Discovery. There are already clarifications specific to
+ the link technology about how to tune the Neighbor Discovery Protocol
+ (NDP) constants for certain systems in order to reduce excess NDP
+ traffic. For example, [RFC6459] and [RFC7066] contain such
+ clarifications for 3GPP cellular links.
+
+ This document specifies updates to the IPv6 Neighbor Discovery
+ Protocol [RFC4861] to increase the maximum time allowed between
+ sending unsolicited multicast RAs from a router interface as well as
+ to increase the maximum router lifetime.
+
+2. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+3. Relationship between AdvDefaultLifetime and MaxRtrAdvInterval
+
+ MaxRtrAdvInterval is an upper bound on the time between which two
+ successive Router Advertisement messages are sent. Therefore, one
+ might reason about the relationship between these two values in terms
+ of a ratio K = AdvDefaultLifetime / MaxRtrAdvInterval, which
+ expresses how many Router Advertisements are guaranteed to be sent
+ before the router lifetime expires.
+
+ Assuming unicast Solicited Router Advertisements or a perfectly
+ stable network, on a theoretically perfect link with no losses, it
+ would be sufficient to have K just above 1, so that the sent Router
+ Advertisement refreshes the router entry just before it expires. On
+ the real links that allow for some loss, one would need to use K > 2
+ in order to minimize the chances of a single Router Advertisement
+ loss causing a loss of the router entry.
+
+
+
+
+
+
+
+Krishnan, et al. Standards Track [Page 3]
+
+RFC 8319 Adjustable Router Lifetimes February 2018
+
+
+ The exact calculation will depend on the packet loss probability. An
+ example: if we take a ballpark value of 1% probability of a packet
+ loss, then K = 2 will give 0.01% chance of an outage due to a packet
+ loss, K = 3 will give 0.0001% chance of an outage, and so forth. To
+ reverse the numbers, with these parameters, K ~= 1 gives 99%
+ reliability, K ~= 2 gives 99.99% reliability, and K ~= 3 gives
+ 99.9999% reliability -- which should be good enough for a lot of
+ scenarios.
+
+ In a network with higher packet loss probabilities or if higher
+ reliability is desired, the K might be chosen to be even higher. On
+ the other hand, some of the data link layers provide reliable
+ delivery at Layer 2, so there one might even consider using the
+ "theoretical" value of K just above 1. Since the choice of these two
+ parameters does not impact interoperability per se, this document
+ does not impose any specific constraints on their values other than
+ providing the guidelines in this section. Therefore, each individual
+ link can optimize according to its use case.
+
+ Also, AdvDefaultLifetime MUST be set to a value greater than or equal
+ to the selected MaxRtrAdvInterval. Otherwise, a router lifetime is
+ guaranteed to expire before the new Router Advertisement has a chance
+ to be sent, thereby creating an outage.
+
+4. Updates to RFC 4861
+
+ This document updates Sections 4.2 and 6.2.1 of [RFC4861] to change
+ the following router configuration variables.
+
+ In Section 4.2, inside the paragraph that defines Router Lifetime,
+ change 9000 to 65535 seconds.
+
+ In Section 6.2.1, inside the paragraph that defines
+ MaxRtrAdvInterval, change 1800 to 65535 seconds.
+
+ In Section 6.2.1, inside the paragraph that defines
+ AdvDefaultLifetime, change 9000 to 65535 seconds.
+
+ As explained in Section 3, the probability of packet loss must be
+ considered when choosing the relationship between MaxRtrAdvInterval
+ and AdvDefaultLifetime.
+
+
+
+
+
+
+
+
+
+
+Krishnan, et al. Standards Track [Page 4]
+
+RFC 8319 Adjustable Router Lifetimes February 2018
+
+
+5. Host Behavior
+
+ Legacy hosts on a link with updated routers may have issues with a
+ Router Lifetime of more than 9000 seconds. In the few
+ implementations we have tested with general-purpose operating
+ systems, there does not seem to be any issue with setting this field
+ to more than 9000, but there might be implementations that
+ incorrectly reject such RAs (since RFC 4861 requires receivers to
+ handle any value).
+
+6. Security Considerations
+
+ On a link where Router Advertisements are few and far between, the
+ detrimental effects of a rogue router that sends an unsolicited RA
+ are greatly increased. These rogue RAs can be prevented by using
+ approaches like RA-Guard [RFC6105] and SEcure Neighbor Discovery
+ (SEND) [RFC3971].
+
+7. IANA Considerations
+
+ This document has no IANA actions.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+ "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+ DOI 10.17487/RFC4861, September 2007,
+ <https://www.rfc-editor.org/info/rfc4861>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
+ RFC 2119 Key Words", BCP 14, RFC 8174,
+ DOI 10.17487/RFC8174, May 2017,
+ <https://www.rfc-editor.org/info/rfc8174>.
+
+
+
+
+
+
+
+
+
+
+
+Krishnan, et al. Standards Track [Page 5]
+
+RFC 8319 Adjustable Router Lifetimes February 2018
+
+
+8.2. Informative References
+
+ [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
+ "SEcure Neighbor Discovery (SEND)", RFC 3971,
+ DOI 10.17487/RFC3971, March 2005,
+ <https://www.rfc-editor.org/info/rfc3971>.
+
+ [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
+ Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
+ DOI 10.17487/RFC6105, February 2011,
+ <https://www.rfc-editor.org/info/rfc6105>.
+
+ [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
+ T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
+ Partnership Project (3GPP) Evolved Packet System (EPS)",
+ RFC 6459, DOI 10.17487/RFC6459, January 2012,
+ <https://www.rfc-editor.org/info/rfc6459>.
+
+ [RFC7066] Korhonen, J., Ed., Arkko, J., Ed., Savolainen, T., and S.
+ Krishnan, "IPv6 for Third Generation Partnership Project
+ (3GPP) Cellular Hosts", RFC 7066, DOI 10.17487/RFC7066,
+ November 2013, <https://www.rfc-editor.org/info/rfc7066>.
+
+Acknowledgements
+
+ The authors would like to thank the members of the 6MAN efficient ND
+ design team for their comments that led to the creation of this
+ document. The authors would also like to thank Lorenzo Colitti, Erik
+ Kline, Jeena Rachel John, Brian Carpenter, Tim Chown, Fernando Gont,
+ Warren Kumari, and Adam Roach for their comments and suggestions that
+ improved this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krishnan, et al. Standards Track [Page 6]
+
+RFC 8319 Adjustable Router Lifetimes February 2018
+
+
+Authors' Addresses
+
+ Suresh Krishnan
+ Kaloom
+ 335 Rue Peel
+ Montreal, QC
+ Canada
+
+ Email: suresh@kaloom.com
+
+
+ Jouni Korhonen
+ Nordic Semiconductor ASA
+ Metsanneidonkuja 10
+ 02130 Espoo
+ Finland
+
+ Email: jouni.nospam@gmail.com
+
+
+ Samita Chakrabarti
+ Verizon
+ United States of America
+
+ Email: samita.chakrabarti@verizon.com
+
+
+ Erik Nordmark
+ Zededa
+ Santa Clara, CA
+ United States of America
+
+ Email: nordmark@acm.org
+
+
+ Andrew Yourtchenko
+ Cisco
+ 6b de Kleetlaan
+ Diegem 1831
+ Belgium
+
+ Email: ayourtch@cisco.com
+
+
+
+
+
+
+
+
+
+Krishnan, et al. Standards Track [Page 7]
+