[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-gont-v6ops-cpe-slaac-renum) 00 01 02 03 04 05 Draft is active
In: IESG_Evaluation
IPv6 Operations Working Group (v6ops)                            F. Gont
Internet-Draft                                              SI6 Networks
Updates: 7084 (if approved)                                      J. Zorz
Intended status: Informational                                  6connect
Expires: April 1, 2021                                      R. Patterson
                                                                  Sky UK
                                                                 B. Volz
                                                                   Cisco
                                                      September 28, 2020


 Improving the Reaction of Customer Edge Routers to Renumbering Events
                  draft-ietf-v6ops-cpe-slaac-renum-05

Abstract

   In scenarios where network configuration information becomes invalid
   without any explicit signaling of that condition (such as when a
   Customer Edge Router crashes and reboots without knowledge of the
   previously-employed configuration information), hosts on the local
   network will continue using stale network configuration information
   for an unacceptably long period of time, thus resulting in
   connectivity problems.  This document specifies improvements to
   Customer Edge Routers that help mitigate the aforementioned problem
   for typical residential and small office scenarios.  This document
   updates RFC7084.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 1, 2021.








Gont, et al.              Expires April 1, 2021                 [Page 1]


Internet-Draft       Reaction to Renumbering Events       September 2020


Copyright Notice

   Copyright (c) 2020 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Improved Customer Edge Router Behavior  . . . . . . . . . . .   3
     3.1.  Interface Between WAN-side and LAN-side . . . . . . . . .   4
     3.2.  LAN-side Option Lifetimes . . . . . . . . . . . . . . . .   5
     3.3.  Signaling Stale Configuration Information . . . . . . . .   6
   4.  Recommended Option Lifetimes Configuration Values . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   In scenarios where network configuration information becomes invalid
   without any explicit signaling of that condition, nodes on the local
   network will continue using stale information for an unacceptably
   long period of time, thus resulting in connectivity problems.  This
   problem is documented in detail in [I-D.ietf-v6ops-slaac-renum].

   This document specifies improvements to Customer Edge (CE) Routers
   that help mitigate the aforementioned problem for residential and
   small office scenarios.  It specifies recommendations for the default
   behavior of CE Routers, and does not preclude the availability of
   configuration knobs that might allow an operator or user to manually-
   configure the CE Router to deviate from these recommendations.  This
   document updates RFC7084.




Gont, et al.              Expires April 1, 2021                 [Page 2]


Internet-Draft       Reaction to Renumbering Events       September 2020


2.  Requirements Language

   Take careful note: Unlike other IETF documents, the key words "MUST",
   "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as
   described in [RFC2119].  This document uses these keywords not
   strictly for the purpose of interoperability, but rather for the
   purpose of establishing industry-common baseline functionality.  As
   such, the document points to several other specifications (preferable
   in RFC or stable form) to provide additional guidance to implementers
   regarding any protocol implementation required to produce a
   successful CE router that interoperates successfully with a
   particular subset of currently deploying and planned common IPv6
   access networks.

   Note: the aforementioned terms are used in exactly the same way as in
   [RFC7084], with the above explanation copied verbatim from
   Section 1.1 of [RFC7084].

3.  Improved Customer Edge Router Behavior

   This section specifies and clarifies requirements for Customer Edge
   Routers that can help mitigate the problem discussed in Section 1,
   particularly when they employ prefixes learned via DHCPv6-Prefix
   Delegation (DHCPv6-PD) [RFC8415] on the WAN-side with Stateless
   Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6 [RFC8415] on
   the LAN-side.  The recommendations in this document help improve
   robustness at the Customer Edge Router (on which the user or ISP may
   have no control), and do not preclude implementation of host-side
   improvements such as those specified in [I-D.ietf-6man-slaac-renum].

   This document specifies additional LAN-side requirements to
   requirements L-1 through L-14 specified in [RFC7084]:

   o  L-15: CE routers MUST NOT advertise prefixes via SLAAC or assign
      addresses or delegate prefixes via DHCPv6 on the LAN-side,
      employing lifetimes that exceed the remaining lifetimes of the
      corresponding prefixes learned from the WAN-side via DHCPv6-PD.
      For more details, see Section 3.1.

   o  L-16: CE routers SHOULD advertise capped SLAAC option lifetimes
      and capped DHCPv6 IA Address Option and IA Prefix Option
      lifetimes, as specified in Section 3.2.

   o  L-17: CE routers MUST signal stale configuration information as
      specified in Section 3.3.





Gont, et al.              Expires April 1, 2021                 [Page 3]


Internet-Draft       Reaction to Renumbering Events       September 2020


   o  L-18: CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE
      messages upon reboot events.

3.1.  Interface Between WAN-side and LAN-side

   The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information
   Options (PIOs) [RFC4861] corresponding to prefixes learned via
   DHCPv6-PD MUST NOT span past the remaining preferred and valid
   lifetimes of the corresponding DHCPv6-PD prefixes.  This means that
   the advertised "Preferred Lifetime" and "Valid Lifetime" MUST be
   dynamically adjusted such that they never span past the remaining
   preferred and valid lifetimes of the corresponding prefixes delegated
   via DHCPv6-PD on the WAN-side.

   Similarly, the "preferred-lifetime" and "valid-lifetime" of DHCPv6 IA
   Address Options and DHCPv6 IA Prefix Options employed with DHCPv6 on
   the LAN-side MUST NOT span past the remaining preferred and valid
   lifetimes of the corresponding prefixes leased via DHCPv6-PD on the
   WAN-side.  This means that the advertised "Preferred Lifetime" and
   "Valid Lifetime" MUST be dynamically adjusted such that the
   advertised lifetimes never span past the remaining preferred and
   valid lifetimes of the corresponding prefixes delegated to the CE
   Router on the WAN-side via DHCPv6-PD.

   CE Routers providing stateful address configuration via DHCPv6 SHOULD
   set the DHCPv6 IA Address Option preferred-lifetime to the lesser of
   the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the
   valid-lifetime of the same option to the lesser of the remaining
   valid lifetime and ND_VALID_LIMIT.

   CE Routers providing DHCPv6-PD on the LAN-side SHOULD set the DHCPv6
   IA Prefix Option preferred-lifetime to the lesser of the remaining
   preferred lifetime and ND_PREFERRED_LIMIT, and the valid-lifetime of
   the same option to the lesser of the remaining valid lifetime and
   ND_VALID_LIMIT.

   RATIONALE:

      *  The lifetime values employed for the "Preferred Lifetime"
         (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime)
         of SLAAC Prefix Information Options must never be larger than
         the remaining lifetimes for the corresponding prefix (as
         learned via DHCPv6-PD on the WAN-side).  This is in line with
         the requirement from Section 6.3 of [RFC8415], which states
         that "if the delegated prefix or a prefix derived from it is
         advertised for stateless address autoconfiguration [RFC4862],
         the advertised preferred and valid lifetimes MUST NOT exceed
         the corresponding remaining lifetimes of the delegated prefix."



Gont, et al.              Expires April 1, 2021                 [Page 4]


Internet-Draft       Reaction to Renumbering Events       September 2020


      *  The lifetime values of prefixes advertised on the LAN-side via
         SLAAC must be dynamically updated (rather than static values),
         otherwise the advertised lifetimes would eventually span past
         the DHCPv6-PD lifetimes.

      *  The same considerations apply for the valid-lifetime and
         preferred-lifetime of IA Address Options and IA Prefix Options
         employed with DHCPv6 on the LAN-side.

3.2.  LAN-side Option Lifetimes

   CE Routers SHOULD override the default PIO "Preferred Lifetime" and
   "Valid Lifetime" values from [RFC4861], and employ shorter lifetime
   values to improve the robustness to renumbering events, while
   complying with the requirements from Section 2.1 of this document and
   the recommendations in [RFC7772].

   CE routers SHOULD set the Router Lifetime to ND_PREFERRED_LIMIT.  CE
   routers SHOULD also set the PIO Preferred Lifetime to the lesser of
   the remaining preferred lifetime (see Section 3.1) and
   ND_PREFERRED_LIMIT, and the PIO Valid Lifetime to the lesser of the
   remaining valid lifetime and ND_VALID_LIMIT.  Additionally, the Route
   Lifetime of Route Information Options (RIOs) [RFC4191], the Lifetime
   of Recursive DNS Search Options (RDNSSO) [RFC8106], and the Lifetime
   of DNS Search List Options (DNSSLO) [RFC8106] SHOULD be set to the
   lesser of the longest valid-lifetime in a DHCPv6 IA Prefix Option
   (received via DHCPv6 on the WAN-side) and ND_VALID_LIMIT, if any of
   these options are included in Router Advertisement messages.

   CE Routers providing stateful address configuration via DHCPv6 SHOULD
   set the DHCPv6 IA Address Option preferred-lifetime to the lesser of
   the remaining preferred lifetime (see Section 3.1) and
   ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the
   lesser of the remaining valid lifetime and ND_VALID_LIMIT.

   CE Routers providing DHCPv6-PD on the LAN-side SHOULD set the DHCPv6
   IA Prefix Option preferred-lifetime to the lesser of the remaining
   preferred lifetime (see Section 3.1) and ND_PREFERRED_LIMIT, and the
   valid-lifetime of the same option to the lesser of the remaining
   valid lifetime and ND_VALID_LIMIT.

   RATIONALE:

      *  The Valid Lifetime and Preferred Lifetime of PIOs have a direct
         impact on three different aspects:






Gont, et al.              Expires April 1, 2021                 [Page 5]


Internet-Draft       Reaction to Renumbering Events       September 2020


         +  The amount of time hosts may end up employing stale network
            configuration information (see
            [I-D.ietf-v6ops-slaac-renum]).

         +  The amount of time CE Routers need to persist trying to
            deprecate stale network configuration information (e.g. to
            handle cases where nodes miss Router Advertisements and thus
            still consider the stale information as valid).

         +  The amount of information that CE Routers need to maintain
            when e.g. multiple crash-and-reboot events occur in the
            timespan represented by the option lifetimes employed on the
            LAN-side.

      *  CE Routers need not employ the (possibly long) DHCPv6-PD
         lifetimes for the Valid Lifetime and Preferred Lifetime of PIOs
         sent in Router Advertisements messages to advertise sub-
         prefixes of the leased prefix.  Instead, CPE Routers SHOULD use
         shorter values for the Valid Lifetime and Preferred Lifetime of
         PIOs, since subsequent Router Advertisement messages will
         nevertheless refresh the associated lifetimes, leading to the
         same effective lifetimes as specified by the WAN-side DHCPv6-PD
         lifetimes.

      *  Similarly, CE Routers need not employ the (possibly long)
         DHCPv6-PD lifetimes for the valid-lifetime and preferred-
         lifetime of IA Address Options and IA Prefix Option employed by
         DHCPv6 on the LAN-side, since the renewal of bindings by DHCPv6
         clients will lead to the same effective lifetimes as specified
         by the WAN-side DHCPv6-PD lifetimes.

3.3.  Signaling Stale Configuration Information

   In order to phase-out stale SLAAC configuration information:

   o  A CE router sending RAs that advertise dynamically-learned
      prefixes (e.g. via DHCPv6-PD) SHOULD record, on stable storage,
      the list of prefixes being advertised on each network segment, and
      the state of the "A" and "L" flags of the corresponding PIOs.

   o  Upon changes to the advertised prefixes, and after bootstrapping,
      the CE Router advertising prefix information via SLAAC proceeds as
      follows:

      *  Any prefixes that were previously advertised via Router
         Advertisement (RA) messages, but that have now become stale,
         MUST be advertised with a "Valid Lifetime" and a "Preferred
         Lifetime" set to 0, and the "A" and "L" bits unchanged.



Gont, et al.              Expires April 1, 2021                 [Page 6]


Internet-Draft       Reaction to Renumbering Events       September 2020


      *  The aforementioned advertisement SHOULD be performed for at
         least the "Valid Lifetime" previously employed for such prefix.
         Note: If requirement L-16 (Section 3.2) is followed, the Valid
         Lifetime need not be saved and the prefix can simply be
         advertised for a period of ND_VALID_LIMIT.

   o  CE Routers receiving DHCPv6 Prefix Delegations with a 0 valid-
      lifetime MUST advertise the corresponding sub-prefixes (as they
      would be generated for the same leased prefix with a non-zero
      lifetime) with a PIO with both the Preferred Lifetime and the
      Valid Lifetime set to 0, for at least the WAN-side DHCPv6-PD
      valid-lifetime, or for a period of ND_VALID_LIMIT if the
      recommended lifetimes from Section 3.2 are employed.

   If a CE Router provides LAN-side DHCPv6 (address assignment or prefix
   delegation), then:

   o  The CE Router SHOULD record, on stable storage, the DHCPv6 address
      and delegated-prefix bindings corresponding to the LAN-side.

   o  If the CE Router finds that the prefix to be employed for address
      assignment and/or prefix delegation has changed (e.g., upon a
      crash-and-reboot event) or the CE Router receives DHCPv6 Prefix
      Delegations with 0 lifetimes, the CE Router MUST:

      *  In Replies to DHCPv6 Request, Renew, Rebind messages, send 0
         lifetimes for any address assignments or prefix delegations for
         the deprecated prefixes for at least the valid-lifetime
         previously employed for them, or for a period of ND_VALID_LIMIT
         if the recommended lifetimes from Section 3.2 are employed.

      *  Initiate sending Reconfigure messages (if possible - i.e.,
         client requests Reconfigure support and the CE Router offers
         it) to those clients with address assignments or prefix
         delegations for the deprecated prefixes.

   RATIONALE:

      *  IPv6 network renumbering is expected to take place in a planned
         manner, with old/stale prefixes being phased-out via reduced
         prefix lifetimes while new prefixes (with normal lifetimes) are
         introduced.  However, a number of scenarios may lead to the so-
         called "flash-renumbering" events, where the prefix being
         employed on a network suddenly becomes invalid and replaced by
         a new prefix [I-D.ietf-v6ops-slaac-renum].  One such scenario
         is when a DHCPv6 server employs dynamic prefixes and the
         Customer Edge Router crashes and reboots.  The requirements in




Gont, et al.              Expires April 1, 2021                 [Page 7]


Internet-Draft       Reaction to Renumbering Events       September 2020


         this section are meant to allow Customer Edge Routers to
         deprecate stale information in such scenarios.

      *  The recommendations in this section expand from requirement
         L-13 in Section 4.3 of [RFC7084].

      *  Host configuring addresses via SLAAC on the local network may
         employ addresses configured for the previously advertised
         prefixes for at most the "Valid Lifetime" of the corresponding
         PIO of the last received Router Advertisement message.  Since
         Router Advertisement messages may be lost or fail to be
         received for various reasons, Customer Edge Routers need to try
         to deprecate stale prefixes for a period of time equal to the
         "Valid Lifetime" of the PIO employed when originally
         advertising the prefix.

      *  The requirement in this section is conveyed as a "SHOULD" (as
         opposed to a "MUST"), since we acknowledge that the requirement
         to store information on stable storage may represent a
         challenge for some implementations.

      *  Advertising DHCPv6-leased prefixes with zero lifetimes on the
         LAN-side would handle the case where a CE Router has no stable
         storage but receives the prefixes via DHCPv6 with 0 lifetimes.

4.  Recommended Option Lifetimes Configuration Values

   o  ND_PREFERRED_LIMIT: 2700 seconds (45 minutes)

   o  ND_VALID_LIMIT: 5400 seconds (90 minutes)

   RATIONALE:
      These values represent a trade-off among a number of factors,
      including responsiveness and possible impact on the battery life
      of connected devices [RFC7772].

      ND_PREFERRED_LIMIT is set according to the recommendations in
      [RFC7772] for Router Lifetime, following the rationale from
      Section 3.2 of [I-D.ietf-v6ops-slaac-renum].

      ND_VALID_LIMIT is set to 2 * ND_PREFERRED_LIMIT to provide some
      additional leeway before configuration information is finally
      discarded by the host.








Gont, et al.              Expires April 1, 2021                 [Page 8]


Internet-Draft       Reaction to Renumbering Events       September 2020


5.  IANA Considerations

   This document has no actions for IANA.

6.  Security Considerations

   This document discusses a problem that may arise in scenarios where
   dynamic IPv6 prefixes are employed, and proposes improvements to
   Customer Edge Routers [RFC7084] to mitigate the problem for
   residential or small office scenarios.  It does not introduce new
   security issues.

7.  Acknowledgments

   The authors would like to thank Owen DeLong, Philip Homburg, and Ted
   Lemon, for their valuable help in improving this document via
   successive detailed reviews.

   The authors would like to thank Mikael Abrahamsson, Brian Carpenter,
   Lorenzo Colitti, Alejandro D'Egidio, Fernando Frediani, Guillermo
   Gont, Nick Hilliard, Erik Kline, Warren Kumari, Olorunloba Olopade,
   Pete Resnick, Mark Smith, Job Snijders, Sander Steffann, Ole Troan,
   Loganaden Velvindron, Timothy Winters, Christopher Wood, and
   Chongfeng Xie, for providing valuable comments on earlier versions of
   this document.

   The authors would lie to thank Mikael Abrahamsson, Luis Balbinot, Tim
   Chown, Brian Carpenter, Owen DeLong, Gert Doering, Steinar Haug, Nick
   Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Ted Lemon,
   Albert Manfredi, Jordi Palet Martinez, Richard Patterson, Michael
   Richardson, Mark Smith, Job Snijders, Tarko Tikan, and Ole Troan, for
   providing valuable comments on [I-D.gont-6man-slaac-renum], on which
   this document is based.

   Fernando would also like to thank Brian Carpenter who, over the
   years, has answered many questions and provided valuable comments
   that have benefited his protocol-related work.

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>.





Gont, et al.              Expires April 1, 2021                 [Page 9]


Internet-Draft       Reaction to Renumbering Events       September 2020


   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
              November 2005, <https://www.rfc-editor.org/info/rfc4191>.

   [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>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.

   [RFC7772]  Yourtchenko, A. and L. Colitti, "Reducing Energy
              Consumption of Router Advertisements", BCP 202, RFC 7772,
              DOI 10.17487/RFC7772, February 2016,
              <https://www.rfc-editor.org/info/rfc7772>.

   [RFC8106]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
              "IPv6 Router Advertisement Options for DNS Configuration",
              RFC 8106, DOI 10.17487/RFC8106, March 2017,
              <https://www.rfc-editor.org/info/rfc8106>.

   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
              RFC 8415, DOI 10.17487/RFC8415, November 2018,
              <https://www.rfc-editor.org/info/rfc8415>.

8.2.  Informative References

   [I-D.gont-6man-slaac-renum]
              Gont, F., Zorz, J., and R. Patterson, "Improving the
              Robustness of Stateless Address Autoconfiguration (SLAAC)
              to Flash Renumbering Events", draft-gont-6man-slaac-
              renum-08 (work in progress), May 2020.

   [I-D.ietf-6man-slaac-renum]
              Gont, F., Zorz, J., and R. Patterson, "Improving the
              Robustness of Stateless Address Autoconfiguration (SLAAC)
              to Flash Renumbering Events", draft-ietf-6man-slaac-
              renum-01 (work in progress), August 2020.








Gont, et al.              Expires April 1, 2021                [Page 10]


Internet-Draft       Reaction to Renumbering Events       September 2020


   [I-D.ietf-v6ops-slaac-renum]
              Gont, F., Zorz, J., and R. Patterson, "Reaction of
              Stateless Address Autoconfiguration (SLAAC) to Flash-
              Renumbering Events", draft-ietf-v6ops-slaac-renum-03 (work
              in progress), August 2020.

   [RFC7084]  Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
              Requirements for IPv6 Customer Edge Routers", RFC 7084,
              DOI 10.17487/RFC7084, November 2013,
              <https://www.rfc-editor.org/info/rfc7084>.

Authors' Addresses

   Fernando Gont
   SI6 Networks
   Segurola y Habana 4310, 7mo Piso
   Villa Devoto, Ciudad Autonoma de Buenos Aires
   Argentina

   Email: fgont@si6networks.com
   URI:   https://www.si6networks.com


   Jan Zorz
   6connect

   Email: jan@connect.com


   Richard Patterson
   Sky UK

   Email: richard.patterson@sky.uk


   Bernie Volz
   Cisco Systems, Inc.
   1414 Massachusetts Ave
   Boxborough, MA 01719
   USA

   Email: volz@cisco.com









Gont, et al.              Expires April 1, 2021                [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/