Skip to main content

Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events
draft-gont-6man-slaac-renum-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Fernando Gont , Jan Zorz
Last updated 2019-01-31
Replaced by draft-ietf-6man-slaac-renum
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-gont-6man-slaac-renum-00
IPv6 Maintenance (6man) Working Group                            F. Gont
Internet-Draft                                    SI6 Networks / UTN-FRH
Updates: 4861 (if approved)                                      J. Zorz
Intended status: Standards Track                        January 31, 2019
Expires: August 4, 2019

 Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering
                                 Events
                     draft-gont-6man-slaac-renum-00

Abstract

   A very common IPv6 deployment scenario is that in which a CPE employs
   DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and at least one
   prefix from within the leased prefix is advertised on a local network
   via SLAAC.  In scenarios where e.g. the CPE crashes and reboots,
   nodes on the local network continue using outdated prefixes which
   result in connectivity problems.  This document analyzes this problem
   scenario, and proposes workarounds.

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 August 4, 2019.

Copyright Notice

   Copyright (c) 2019 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

Gont & Zorz              Expires August 4, 2019                 [Page 1]
Internet-Draft       Reaction to Renumbering Events         January 2019

   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Possible workarounds  . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Improvement to SLAAC  . . . . . . . . . . . . . . . . . .   3
     3.2.  Improved CPE behavior . . . . . . . . . . . . . . . . . .   5
     3.3.  Stable prefixes . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Flowchart for Host Processing of RAs . . . . . . . .   8
   Appendix B.  Sample Timeline for Host Processing of RAs . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Probably the most common deployment scenario for IPv6 in home
   networks is that in which a CPE router employs DHCPv6 Prefix
   Delegation (DHCPv6-PD) [RFC8415] to request a prefix from the ISP,
   and a prefix belonging to the leased prefix is advertised on the LAN-
   side of the CPE via Stateless Address Autoconfiguration (SLAAC)
   [RFC4862].

   In scenarios such as that in which the CPE router crashes and
   reboots, the CPE may be leased (via DHCPv6-PD) a different prefix
   than the one previously leased and will therefore advertise such new
   prefix on the LAN side via SLAAC.  Hosts will normally configure an
   address for the new prefix, but will normally retain and actively
   employ the previously-configured addresses, since their associated
   Preferred Lifetime and Valid Lifetime allow them to do so.  The
   default values, as specified in [RFC4861] are:

   o  Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)

   o  Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)

   Lacking any explicit signaling to "obsolete" the previously-
   configured addresses (for the now invalid/outdated prefix), hosts may
   continue employing the previously-configured addresses which will
   tipically result in packets being blackholed -- whether because of

Gont & Zorz              Expires August 4, 2019                 [Page 2]
Internet-Draft       Reaction to Renumbering Events         January 2019

   egress-filtering by the CPE or ISP, or because responses to such
   packets will be discarded or routed elsewhere.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Possible workarounds

   The following subsections discuss possible workarounds for the
   aforementioned problem.

3.1.  Improvement to SLAAC

   This section specifies an improvement to SLAAC that improves
   robustness and that can mitigate the aforementioned problem.

   The goal of this modification is that, when a router that was
   previously advertising a prefix for address configuration (PIO with
   the "A" bit set) is found to advertise other prefixes but not the
   previously-advertised prefixes, addresses configured for the "old"
   prefixes are marked as "not preferred" (i.e., their "Preferred
   Lifetime" is set to 0), thus allowing for a more timely-reaction to
   the problem described in Section 1.

   Local information maintained for each prefix advertised by each
   router is augmented with one boolean flag named "deprecate" that
   defaults to "false".  Note: hosts are already expected to keep track
   of which router has advertised which prefix in order to be able to
   properly select the first-hop router in multiple-prefix networks
   [RFC8028] [I-D.ietf-6man-rfc6434-bis].

   After normal processing of Router Advertisement messages, Router
   Advertisements that contain at least one PIO MUST be processed as
   follows:

   o  The "deprecate" flag for each prefix advertised in the current
      Router Advertisement should be set to "false".

   o  For each prefix that had been previously advertised by this router
      but that does not have a corresponding PIO with the "A" flag set
      in the received RA, proceed as follows:

      *  IF the "deprecate" flag is "true", then:

Gont & Zorz              Expires August 4, 2019                 [Page 3]
Internet-Draft       Reaction to Renumbering Events         January 2019

         +  IF there is any address configured for this prefix with a
            "Preferred Lifetime" larger than 0, set its "Preferred
            Lifetime" to 0, and the "deprecate flag" of this prefix to
            "false".

         +  ELSE (all addresses for this prefix have a "Preferred
            Lifetime" of 0), set the "Valid Lifetime" of any addresses
            configured for this prefix to 0, and the "deprecate" flag to
            "false".  This will cause removal of all addresses for this
            prefix.  Additionally, if the corresponding prefix had been
            advertised as on-link ("L"=1) by this router, remove any
            routes to this prefix associated with the network interface
            card on which the RA packet was received.

      *  ELSE (the "deprecate" flag is "false"):

         +  Set the "deprecate" flag of the corresponding prefix to
            "true".

   Appendix B illustrates the packet exchange and operation of the
   algorithm for a typical scenario.  Appendix A provides a flowchart
   for this algorithm.

   NOTES:

   o  The aforementioned processing assumes that while network
      configuration information might be split into multiple RAs, PIOs
      will be spread among *at most* two RAs.  This assumption avoids
      the use of any timers for this specific purpose.

   o  If the only prefix that has so far been advertised on the local
      network is the prefix that has become outdated, and there is no
      new prefix being advertised, the traditional processing is
      unaffected (the mechanism discussed in this document will *never*
      be triggered because no packets with PIOs with the "A" flag will
      be received).  The logic here is that it's better to have some
      address, than no address at all.

   o  The processing of RAs that do not contain any PIOs with the "A"
      bit set remain unaffected.

   o  The specified modification takes the conservative approach of
      first setting the "Preferred Lifetime" to 0 (such that addresses
      become non-preferred), and subsequently setting the "Valid
      Lifetime" to 0 (such as the addresses are completely removed).
      Once the addresses for this prefix have been removed, routes to
      this prefix associated with the network interface on which the RA
      packets were received are also removed.

Gont & Zorz              Expires August 4, 2019                 [Page 4]
Internet-Draft       Reaction to Renumbering Events         January 2019

3.2.  Improved CPE behavior

   The scenario discussed in Section 1 could be improved on the CPE-side
   as follows:

   o  A CPE MUST record, on stable storage, the list of prefixes being
      advertised on each LAN segment.

   o  Upon renewed information about the list of prefixes to be
      advertised on the LAN-side (whether as a result of DHCPv6-PD or
      manual configuration), then:

      *  Any prefixes that were previously advertised via SLAAC, but
         that are not currently intended for address configuration, MUST
         be advertised with a PIO option with the "A" bit set to 1 and
         the "Valid Lifetime" and a "Preferred Lifetime" set to 0.

      *  Any prefixes that were previously advertised via SLAAC as "on-
         link", but that are not currently not considered "on-link",
         MUST be advertised with a PIO option with the "L" bit set to 1
         and the "Valid Lifetime" and a "Preferred Lifetime" set to 0.

      *  If both of the previous conditions are met (a prefix was
         previously advertised with both the "A" and "L" bits set, but
         is currently *not* intended for address configuration and is
         *not* considered on-link), the prefix MUST be advertised with a
         PIO option with both the "A" and "L" bits set to 1 and the
         "Valid Lifetime" and a "Preferred Lifetime" set to 0.  That is.
         the advertisements of the previous two steps can be coalesced
         into a single one with both the "A" and "L" bits set.

   The aforementioned advertisement SHOULD be performed for at least the
   "Valid Lifetime" previously employed for such prefix.

   This improves the situation for hosts that do not implement the
   modification specified in Section 3.1 but would obviously make
   robustness dependent on the CPE, as opposed to the host itself.

3.3.  Stable prefixes

   The problem discussed in this document would be avoided if DHCPv6-PD
   would lease "stable" prefixes.

   There are a number of possible issues associated with this option:

   o  Provisioning systems may be unable to deliver stable IPv6
      prefixes.

Gont & Zorz              Expires August 4, 2019                 [Page 5]
Internet-Draft       Reaction to Renumbering Events         January 2019

   o  While there is a range of information that may be employed to
      correlate network activity [RFC7721], the use of stable prefixes
      clearly simplifies network activity correlation, and may
      essentially render features such as "temporary addresses"
      [RFC4941] irrelevant.

   o  Applicable legislation may require the ISP to deliver dynamic IPv6
      prefixes *by default* (see e.g.  [GERMAN-DP]).

4.  Security Considerations

   This document discusses a a problem that may arise in scenarios where
   dynamic IPv6 prefixes are employed, and proposes workarounds that
   enable such usage while avoiding interoperability problems.  The
   security and privacy implications of IPv6 addresses are discussed in
   [RFC7721].

   An attacker that could impersonate a router could forge multiple RA
   packets that contain PIOs of prefixes that are currently not
   advertised on the local network, to trigger the mechanism specified
   in this document to cause addresses currently configured for the
   legitimate prefixes to be removed.  However, an attacker that can
   impersonate a router could more easily achieve the same goal by
   advertising the legitimate prefixes with both the "Preferred
   Lifetime" and "Valid Lifetime" set to 0.

   Attacks based on forged RA packed can be mitigated with technologies
   such as RA-Guard [RFC6105] [RFC7113].

5.  Acknowledgments

   The authors would lie to thank (in alphabetical order) [TBD] for
   providing valuable comments on earlier versions of this document.

   Fernando would like to thank Alejandro D'Egidio , and Sander Steffan
   for a discussion of these issues.

   The problem discussed in this document, and the recommendation to
   employ stable prefixes, have been previously documented in
   [RIPE-690].

6.  References

6.1.  Normative References

Gont & Zorz              Expires August 4, 2019                 [Page 6]
Internet-Draft       Reaction to Renumbering Events         January 2019

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

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

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
              <https://www.rfc-editor.org/info/rfc4941>.

   [RFC8028]  Baker, F. and B. Carpenter, "First-Hop Router Selection by
              Hosts in a Multi-Prefix Network", RFC 8028,
              DOI 10.17487/RFC8028, November 2016,
              <https://www.rfc-editor.org/info/rfc8028>.

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

6.2.  Informative References

   [GERMAN-DP]
              BFDI, "Einfuhrung von IPv6 Hinweise fur Provider im
              Privatkundengeschaft und Herstellere", Entschliessung der
              84. Konferenz der Datenschutzbeauftragten des Bundes und
              der Lander am 7./8. November 2012 in Frankfurt (Oder),
              November 2012,
              <http://www.bfdi.bund.de/SharedDocs/Publikationen/
              Entschliessungssammlung/DSBundLaender/84DSK_EinfuehrungIPv
              6.pdf?__blob=publicationFile>.

   [I-D.ietf-6man-rfc6434-bis]
              Chown, T., Loughney, J., and T. Winters, "IPv6 Node
              Requirements", draft-ietf-6man-rfc6434-bis-09 (work in
              progress), July 2018.

Gont & Zorz              Expires August 4, 2019                 [Page 7]
Internet-Draft       Reaction to Renumbering Events         January 2019

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

   [RFC7113]  Gont, F., "Implementation Advice for IPv6 Router
              Advertisement Guard (RA-Guard)", RFC 7113,
              DOI 10.17487/RFC7113, February 2014,
              <https://www.rfc-editor.org/info/rfc7113>.

   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
              Considerations for IPv6 Address Generation Mechanisms",
              RFC 7721, DOI 10.17487/RFC7721, March 2016,
              <https://www.rfc-editor.org/info/rfc7721>.

   [RIPE-690]
              RIPE, Zorz, J., Zorz, S., Drazumeric, P., Townsley, M.,
              Alston, J., Doering, G., Palet, J., Linkova, J., Balbinot,
              L., Meynell, K., and L. Howard, "Best Current Operational
              Practice for Operators: IPv6 prefix assignment for end-
              users - persistent vs non-persistent, and what size to
              choose", RIPE 690, October 2017,
              <https://www.ripe.net/publications/docs/ripe-690>.

Appendix A.  Flowchart for Host Processing of RAs

   Conceptually, the mechanism operates as follows:

Gont & Zorz              Expires August 4, 2019                 [Page 8]
Internet-Draft       Reaction to Renumbering Events         January 2019

+-------------------+
| Normal processing |
|    of RA packet   |
+---------+---------+
          |
          v
+-------------------+
|  RA has PIO with  |  No
|       A==1?       |------>  DONE
+-------------------+
          |
          |  Yes
          v
+-------------------+
|  (For each PIO)   |
|  deprecate=TRUE   |
+-------------------+
          |
          v
+-------------------+      +-----------------+
| (For each Pref.   |      |                 |
| assoc with this   | Yes  |                 |
|       router)     |----->| deprecate=FALSE |
| Is there corresp. |      |                 |
|   PIO in the RA?  |      |                 |
+-------------------+      +-----------------+
          |
          | No
          v
+-------------------+      +------------------+      +-----------------+
|                   |      | (For each addr.  |      | Valid Lftime=0  |
|                   | Yes  | for this Prefix) | Yes  | deprecate=FALSE |
|  deprecate==TRUE? |----->|                  |----->|   (REM. ADDR!)  |
|                   |      | Pref. Lftime==0? |      |                 !
+-------------------+      +------------------+      +-----------------+
          |                          |
          | No                       | No
          v                          v
+-------------------+      +------------------+
|                   |      |  Pref. Lftime=0  |
|  deprecate=TRUE   |      |  deprecate=FALSE |
+-------------------+      +------------------+

Appendix B.  Sample Timeline for Host Processing of RAs

   The following example illustrates a sample packet exchange that
   illustrates the algorithm specified in Section 3.1:

Gont & Zorz              Expires August 4, 2019                 [Page 9]
Internet-Draft       Reaction to Renumbering Events         January 2019

    Router                                           Host
          RA, PIO={2001:DB8:1::/64, L=1, A=1}
        -------------------------------------->
                                                [Host configures addrs
                                                  for this prefix]

          RA, PIO={2001:DB8:1::/64, L=1, A=1}
        -------------------------------------->
                                                [Normal proc. of RA]
                           .
                           .
   [Router reboots]

          RA, PIO={2001:DB8:2::/64, L=1, A=1}
        -------------------------------------->
                                                  deprecate=TRUE
                           .
                           .
          RA, PIO={2001:DB8:2::/64, L=1, A=1}
        -------------------------------------->
                                                  Pref. Lftime=0
                                                  deprecate=FALSE
                           .
                           .
          RA, PIO={2001:DB8:2::/64, L=1, A=1}
        -------------------------------------->
                                                  deprecate=TRUE
                           .
                           .
          RA, PIO={2001:DB8:2::/64, L=1, A=1}
        -------------------------------------->
                                                  Valid Lftime=0
                                                  deprecate=FALSE
                                                  (Addr. Removed!)

Authors' Addresses

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

   Phone: +54 11 4650 8472
   Email: fgont@si6networks.com
   URI:   https://www.si6networks.com

Gont & Zorz              Expires August 4, 2019                [Page 10]
Internet-Draft       Reaction to Renumbering Events         January 2019

   Jan Zorz

   Email: jan@go6.si

Gont & Zorz              Expires August 4, 2019                [Page 11]