doc: Add RFC documents

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]
+