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, . [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, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, . [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, . [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, . 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, . [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, . [RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, DOI 10.17487/RFC7113, February 2014, . [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, . [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, . 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]