IPv6 Maintenance (6man) Working Group F. Gont Internet-Draft SI6 Networks / UTN-FRH Updates: 4861, 4862 (if approved) J. Zorz Intended status: Standards Track February 18, 2019 Expires: August 22, 2019 Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events draft-gont-6man-slaac-renum-01 Abstract In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit signaling of that condition (such as when a CPE crashes and reboots without knowledge of the previously-employed prefixes), nodes on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document analyzes these problem scenarios, and proposes workarounds to improve network robustness. This document updates RFC4861 and RFC4862 to allow for a more robust reaction to network configuration changes. 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 22, 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 Gont & Zorz Expires August 22, 2019 [Page 1]
Internet-Draft Reaction to Renumbering Events February 2019 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Analysis of the Problem . . . . . . . . . . . . . . . . . . . 4 3.1. Inappropriate Default Timer Values in IPv6 Stateless Address Autoconfiguration (SLAAC) . . . . . . . . . . . . 4 3.2. Inability of SLAAC Hosts to Recover from Stale Network Configuration Information . . . . . . . . . . . . . . . . 5 3.3. Lack of Explicit Signaling about Stale Information . . . 6 3.4. Under-specified Interaction Between DHCPv6-PD and SLAAC . 6 4. Use of Dynamic Prefixes . . . . . . . . . . . . . . . . . . . 7 5. Possible workarounds . . . . . . . . . . . . . . . . . . . . 8 5.1. Improvements to SLAAC . . . . . . . . . . . . . . . . . . 8 5.1.1. Default Timer Values . . . . . . . . . . . . . . . . 8 5.1.2. Signaling Stale Configuration Information . . . . . . 9 5.1.3. Recovery from Stale Configuration Information . . . . 10 5.2. Interaction Between DHCPv6-PD and SLAAC . . . . . . . . . 13 5.3. Improved CPE behavior . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Flowchart for Host Processing of RAs . . . . . . . . 17 Appendix B. Sample Timeline for Host Processing of RAs . . . . . 18 Appendix C. Analysis of Some Suggested Workarounds . . . . . . . 19 C.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 20 C.2. On a Possible Improvement to Source Address Selection . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit signaling of that condition, nodes on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. Gont & Zorz Expires August 22, 2019 [Page 2]
Internet-Draft Reaction to Renumbering Events February 2019 There are a number of scenarios where this problem may arise. For example, 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 Internet Service Provider (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 where the CPE router crashes and reboots, the CPE may be leased (via DHCPv6-PD) a different prefix from the one previously leased, and will therefore advertise (via SLAAC) the new prefix on the LAN side. 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. Lacking any explicit signaling to "obsolete" the previously- configured addresses (for the now invalid/stale prefix), hosts may continue employing the previously-configured addresses which will typically result in packets being blackholed -- whether because of egress-filtering by the CPE or ISP, or because responses to such packets will be discarded or routed elsewhere. The default values for the "Valid Lifetime" and "Preferred Lifetime" of Prefix Information Options (PIOs), as specified in [RFC4861], are: o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) This means that in the aforementioned scenarios, the stale addresses would be retained for unacceptably long period of time, thus leading to interoperability problems, instead of nodes transitioning to the newly-advertised prefix(es) in a timelier manner. Some devices have implemented mechanisms to address this problem, such as sending RAs to invalidate the apparently stale prefixes when the device receive any packets employing a source address from a prefix not being advertised for address configuration [FRITZ]. However, this may introduce other interoperability problems, particularly in multihomed scenarios. This is yet another indication that advice in this area is warranted. This unresponsiveness is caused by the both the inability of the network to deprecate stale information, as well as by the inability of hosts to react to network configuration changes in a timelier manner. Clearly, it is desirable that behave in a way that hosts are explicitly notified when configuration information has become stale. However, for robustness reasons it is paramount for hosts to be able Gont & Zorz Expires August 22, 2019 [Page 3]
Internet-Draft Reaction to Renumbering Events February 2019 to recover from stale configuration information even if somehow the network is unable to explictly notify hosts about such condition. Section 3 analysis this problem in more detail. Section 5 proposes workarounds to improve network robustness. 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. Analysis of the Problem As noted in Section 1, the problem discussed in this document is associated with sub-optimal behaviour and policies of different entities. Each of the following sections analyze each of them in detail. 3.1. Inappropriate Default Timer Values in IPv6 Stateless Address Autoconfiguration (SLAAC) Many protocols, from different layers, normally employ timers. The general logic is as follows: o A timer is set with a value that, under normal conditions, the timer does *not* go off. o Whenever a fault condition arises, the timer goes off, and the protocol can perform fault recovery One common example for the use of timers is when implementing reliability mechanisms where a packet is transmitted, and unless a response is received, a retransmission timer will go off to trigger retransmission of the original packet. For obvious reasons, the whole point of using timers is that in problematic scenarios, they will go off, and trigger some recovery action. However, IPv6 SLAAC employs, for PIOs, these default values: o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) Under normal network conditions, these timers will be reset/refreshed to the default values. However, under problematic circumstances such Gont & Zorz Expires August 22, 2019 [Page 4]
Internet-Draft Reaction to Renumbering Events February 2019 as where the corresponding network information has become stale without any explicit signal from the network (as described in Section 1), it will take a host 7 days (one week) to un-prefer the corresponding addresses, and 30 days (one month) to eventually remove any addresses configured for the stale prefix. Clearly, for any practical purposes, employing such long default values is equivalent of not using any timers at all, since taking 7 days or 30 days (respectively) to recover from a network problem is simply unacceptable. The default values for these timers should be such that, under normal circumstances (including some packet loss), the timers will be refreshed/rest, but in the presence of network faults (such as network configuration information becoming stale without explicit signaling), the timers go off and trigger some fault recovering action (such as un-preferring the corresponding addresses and subsequently removing them). In the context of [RFC8028], where it is clear that use of addresses configured for a given prefix is mostly tied to using the router that advertised the prefix as a next hop, one could tell that neither the "Preferred Lifetime" or the "Valid Lifetime" of a PIO should ever be longer than the default value for the "Router Lifetime" of Router Advertisement packets. This means that since [RFC4861] specifies the default value for the "Router Lifetime" as: AdvDefaultLifetime: 3 * MaxRtrAdvInterval, and MaxRtrAdvInterval defaults to 600 seconds, the values employed for the "Preferred Lifetime" (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) of PIOs should never be larger than 1800 seconds (30 minutes). Capping the lifetimes in PIOs as suggested would not eliminate the problem discussed in this document, but certainly reduces the amount of time it takes for hosts to converge to updated network configuration information. Section 5.1.1 of this document updates the SLAAC specification to employ more appropriate timer values. 3.2. Inability of SLAAC Hosts to Recover from Stale Network Configuration Information In the absence of explicit signalling from SLAAC routers (such as sending PIOs with a "Valid Lifetime" set to 0), SLAAC hosts fail to recover from stale configuration information in a timely manner. This is exacerbated by the inappropriate timers employed for the lifetime of PIOs, as discussed in Section 3.1. It is possible to heuristically infer that network configuration information has changed. For example, if the same SLAAC router (as Gont & Zorz Expires August 22, 2019 [Page 5]
Internet-Draft Reaction to Renumbering Events February 2019 identified by its link-local address) is advertising new prefixes via PIOs, but has ceased to advertise the previously-advertised prefixes, this should be considered an indication that network configuration information has changed. Implementing this kind of heuristics would allow a timelier reaction to network configuration changes even in scenarios where there is no explicit signaling from the network, thus improving robustness. Section 5.1.3 of this document specifies a local policy that SLAAC hosts can implement to recover from stale prefixes. 3.3. Lack of Explicit Signaling about Stale Information Whenever prefix information has changed, a SLAAC router should not only advertise the new information, but should also advertise the stale information with appropriate lifetime values (both "Preferred Lifetime" and "Valid Lifetime" set to 0), such that there is explicit signaling to SLAAC hosts to remove the stale information (including configured addresses and routes). In order to cope with the possibility of a SLAAC router crashing and rebooting without any state of the previously-advertised prefixes, a SLAAC router should record on stable storage the information of which prefixes were being advertised on which interfaces, such that upon reboots, such prefixes may be advertised with appropriate lifetimes (both "Preferred Lifetime" and "Valid Lifetime" set to 0) to cause hosts to remove any configuration information derived from previous announcements of such prefixes. Explicit signaling of network configuration changes would eliminate the problem discussed in this document. However, since it is impossible for a host to know whether such explicit signals will be received, they are not relieved from inferring changes in network configuration information, as discussed in Section 3.2. Section 5.1.2 updates the SLAAC specification such that routers explicitly signal stale configuration to SLAAC hosts. Section 5.3 specifies the corresponding requirements for CPE routers. 3.4. Under-specified Interaction Between DHCPv6-PD and SLAAC While DHCPv6-PD is normally employed along with SLAAC, the interaction between the two protocols is largely unspecified. Not unusually, the two protocols are specified in two different software components with the interface between the two implemented by some sort of script that takes feeds the SLAAC implementation with values learned from DHCPv6-PD. Gont & Zorz Expires August 22, 2019 [Page 6]
Internet-Draft Reaction to Renumbering Events February 2019 Quite frequently, the prefix lease time is fed as a constant value to the SLAAC router implementation, meaning that eventually the prefix lifetime advertised on the LAN side will span *past* the DHCPv6-PD lease time. This is clearly incorrect, since the SLAAC router implementation would be allowing the use of such prefixes for a longer time than it has been granted usage of those prefixes via DHCPv6-PD. The lifetime values employed for the "Preferred Lifetime" (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) should never be larger than the remaining lease time for the corresponding prefix (as learned via DHCPv6-PD). Section 5.2 of this document specifies this aspect of the interaction between DHCPv6-PD and SLAAC. 4. Use of Dynamic Prefixes The problem discussed in this document would be avoided if DHCPv6-PD would lease "stable" prefixes. However, a recent survey [UK-NOF] indicates that 37% of the responding ISPs employ dynamic prefixes. That is, dynamic IPv6 prefixes are an operational reality. Deployment reality aside, there are a number of possible issues associated with stable prefixes: o Provisioning systems may be unable to deliver stable IPv6 prefixes. 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]). The authors of this document understand that, for a number of reasons (such as the ones stated above), IPv6 deployments may employ dynamic prefixes, or there might be scenarios in which the dynamics of a network are such that the network exhibits the behaviour of dynamic prefixes. Rather than try to preclude how operators may run their networks, this document aims at improving network robustness in the deployed Internet. Gont & Zorz Expires August 22, 2019 [Page 7]
Internet-Draft Reaction to Renumbering Events February 2019 5. Possible workarounds The following subsections discuss possible workarounds for the aforementioned problem. Section 5.1 specifies modifications to SLAAC which include the use of more appropriate lifetime values and a mechanism for hosts to infer when a previously-advertised prefix has become stale. This modification leads to more robust behaviour even for existing deployments. Section 5.3 specifies the interaction between DHCPv6-PD and SLAAC, such that devices such as CPEs may be in a better position to convey current network information to hosts on the LAN-side. For obvious reasons (legacy CPEs, etc.), this improved behaviour cannot be relied upon for mitigating the problem described in Section 1. However, it does contribute to more robust IPv6 networks. Finally, Section 4 analyzes the trade-offs of employing stable vs. dynamic network prefixes. 5.1. Improvements to SLAAC 5.1.1. Default Timer Values 5.1.1.1. Router Configuration Variables The "default" value for the router configuration variable "MaxRtrAdvInterval" (Section 6.2.1 of [RFC4861] is changed to 300 seconds (5 minutes). As a result of this change, the default values for two other configuration variables are indirectly modified (since they are specified in relation with MaxRtrAdvInterval): o MinRtrAdvInterval: 0.33 * MaxRtrAdvInterval = 99 seconds o AdvDefaultLifetime: 3 * MaxRtrAdvInterval = 900 seconds (15 minutes) Additionally, the default value for the "lifetime" parameters in PIOs is updated as follows: AdvValidLifetime: AdvDefaultLifetime (which according to this specification defaults to 900 seconds / 15 minutes) AdvPreferredLifetime: 0.50 * AdvValidLifetime (which would result in 450 seconds, that is, 7.5 minutes) The motivation of this update is as follows: Gont & Zorz Expires August 22, 2019 [Page 8]
Internet-Draft Reaction to Renumbering Events February 2019 o Link the lifetimes associated with prefixes to the lifetime of the router advertising the prefixes, since use of advertised prefixes is closely tied to the router that has advertised them (as per [RFC8028]). o Lacking RAs that refresh information, addresses configured for such prefixes would become un-preferred, and thus Rule 3 of [RFC6724] would cause other configured addresses (if available) to be preferred and used instead. o Limit the amount of time that a stale prefix needs to be advertised with a lifetime od "0" on the local network (see Section 12 of [RFC4861]). o Employ default router lifetimes that improve the ability of hosts to recover from fault scenarios. 5.1.1.2. Processing of PIO Lifetimes at Hosts Hosts should cap the "Valid Lifetime" and "Preferred Lifetime" of PIOs to the "Router Lifetime" value in the received Router Advertisement. That is, if the "Valid Lifetime" or "Preferred Lifetime" of a PIO is larger than the "Router Lifetime" value of the Router Advertisement carrying the PIO, the corresponding value should be capped to that of the "Router Lifetime" value of the received RA. The motivation for this update is as follows: o Limits the amount of time a host is required to maintain possibly stale information. 5.1.2. Signaling Stale Configuration Information In order to phase-out stale configuration information, the SLAAC specification is updated as follows: o A router sending RAs that advertise dynamically-learned prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on stable storage, the list of prefixes being advertised on each network segment. o Upon changes to the advertised prefixes, and after bootstrapping, the router advertising prefix information via SLAAC should proceed as follows: * Any prefixes that were previously advertised via SLAAC, but that are not currently intended for address configuration, MUST Gont & Zorz Expires August 22, 2019 [Page 9]
Internet-Draft Reaction to Renumbering Events February 2019 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. Additionally, this document replaces the following text from Section 6.2.4 of [RFC4861]: In such cases, the router MAY transmit up to MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the same rules as when an interface becomes an advertising interface. to: In such cases, the router MUST transmit MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the same rules as when an interface becomes an advertising interface. The rationale for this update is: o Use of stale information can lead to interoperability problems. Therefore, it is paramount that new configuration information is delivered in a timely manner to all hosts. 5.1.3. Recovery from Stale Configuration Information The goal of the mechanism specified in this section is to allow hosts to infer when a previously-advertised prefix has become stale, such that previously-configured addresses are "phased-out" and the host can transition to the newly-advertised prefixes in a timelier manner. Gont & Zorz Expires August 22, 2019 [Page 10]
Internet-Draft Reaction to Renumbering Events February 2019 The basic premise behind the mechanism specified in this section is that, when a router advertises new prefixes for address configuration (PIO with the "A" bit set), but fails to advertise the previously- advertised prefixes, this is an indication that the previously- advertised prefixes have become stale. Therefore, configured addresses for the stale prefixes are initially "un-preferred" (such that they are not employed for new communication instances), and they are subsequently removed (if this condition persists). Local information maintained for each prefix advertised by each router is augmented with one boolean flag named "LTA" (Lifetime Avoidance) 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] [RFC8504]. After normal processing of Router Advertisement messages, Router Advertisements that contain at least one PIO MUST be processed as follows: o The LTA 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 LTA flag is "TRUE", then: + IF there is any address configured for this prefix with a "Preferred Lifetime" larger than 0, set its "Preferred Lifetime" to 0, and the LTA flag of this prefix to "FALSE". + ELSE (all addresses for this prefix have a "Preferred Lifetime" of 0), set the "Valid Lifetime" of all addresses configured for this prefix to 0, and the LTA flag of this prefix 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 LTA flag is "FALSE"): + Set the LTA flag of the corresponding prefix to "TRUE". Gont & Zorz Expires August 22, 2019 [Page 11]
Internet-Draft Reaction to Renumbering Events February 2019 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 stale, 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 is 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 remains 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. o In cases where this scenario has been triggered by a CPE router crashing and rebooting, it would take hosts less than one minute to mark the corresponding addresses as "not preferred", and less than five minutes to completely remove such addresses from the system. Section 6.2.4 of [RFC4861] specifies that when an interface becomes an advertising interface, the first few unsolicited RAs (up to MAX_INITIAL_RTR_ADVERTISEMENTS, specified as 3) will be sent at intervals of at most MAX_INITIAL_RTR_ADVERT_INTERVAL (specified as 16 seconds). This means that, in the worst-case scenario, it would take hosts 32 seconds to mark stale addresses as "not preferred". The fourth unsolicited RA will be sent after a random amount of time between MinRtrAdvInterval (default: 0.33 * MaxRtrAdvInterval) and MaxRtrAdvInterval (default: 600 seconds) has elapsed, thus meaning that the stale addresses would be removed between 3.3 and 10 minutes of being marked as "not preferred". Gont & Zorz Expires August 22, 2019 [Page 12]
Internet-Draft Reaction to Renumbering Events February 2019 5.2. Interaction Between DHCPv6-PD and SLAAC The "Preferred Lifetime" and "Valid Lifetime" of PIOs corresponding to prefixes learned via DHCPv6-PD MUST NOT span past the lease time of the DHCPv6-PD prefixes. This means that the advertised "Preferred Lifetime" and "Valid Lifetime" MUST be dynamically adjusted such that the advertised lifetimes never span past the lease time of the prefixes delegated via DHCPv6-PD. This is in line with these existing requirements from other specifications, which we reference here for clarity: o [RFC8415] specifies, in Section 6.3, 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." 5.3. Improved CPE behavior This section specifies and clarifies requirements for CPE routers (particularly when they advertise prefixes learned via DHCPv6-PD) that can help mitigate the problem discussed in Section 1. This improves the situation for hosts that do not implement the modification specified in Section 5.1 but would obviously make robustness dependent on the CPE (on which the user or ISP may have no control), as opposed to the host itself. This mechanism is mostly orthogonal to the improved host behaviour specified in Section 5.1. The updated behaviour is as follows: o The CPE MUST signal stale configuration information as specified in Section 5.1.2 o The CPE MUST implement the DHCPv6-PD/SLAAC interface specified in Section 5.2. The aforementioned improved behaviour assumes compliance with the following existing requirements from other specifications, which we reference here for clarity: o [RFC7084] specifies (requirement LE-13, in Section 4.3) that when the delegated prefix changes (i.e., the current prefix is replaced with a new prefix without any overlapping time period), "the IPv6 CE router MUST immediately advertise the old prefix with a Preferred Lifetime of zero and a Valid Lifetime of either a) zero or b) the lower of the current Valid Lifetime and two hours (which Gont & Zorz Expires August 22, 2019 [Page 13]
Internet-Draft Reaction to Renumbering Events February 2019 must be decremented in real time) in a Router Advertisement message as described in Section 5.5.3, (e) of [RFC4862]" 6. IANA Considerations This document has no actions for IANA. 7. 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. Capping the "Valid Lifetime" and "Preferred Lifetime" at hosts limit the length of the effects of a non-sustained attack, since hosts would now be able to recover in a timelier manner. Attacks based on forged RA packed can be mitigated with technologies such as RA-Guard [RFC6105] [RFC7113]. 8. Acknowledgments The authors would lie to thank (in alphabetical order) Mikael Abrahamsson, Luis Balbinot, Brian Carpenter, Gert Doering, Nick Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Albert Manfredi, Jordi Palet Martinez, Richard Patterson, Michael Richardson, Mark Smith, Tarko Tikan, and Ole Troan, for providing valuable comments on earlier versions of this document. Fernando would like to thank Alejandro D'Egidio and Sander Steffann for a discussion of these issues. The problem discussed in this document has been previously documented in [RIPE-690]. Gont & Zorz Expires August 22, 2019 [Page 14]
Internet-Draft Reaction to Renumbering Events February 2019 9. References 9.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>. [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>. [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, <https://www.rfc-editor.org/info/rfc8504>. 9.2. Informative References [FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network (updated with solution)", SI6 Networks Blog, February 2016, <http://blog.si6networks.com/2016/02/ quiz-weird-ipv6-traffic-on-local-network.html>. Gont & Zorz Expires August 22, 2019 [Page 15]
Internet-Draft Reaction to Renumbering Events February 2019 [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>. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>. [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, DOI 10.17487/RFC5927, July 2010, <https://www.rfc-editor.org/info/rfc5927>. [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>. [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>. [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>. [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>. Gont & Zorz Expires August 22, 2019 [Page 16]
Internet-Draft Reaction to Renumbering Events February 2019 [RIPE-690] 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>. [UK-NOF] Palet, J., "IPv6 Deployment Survey (Residential/Household Services) How IPv6 is being deployed?", UK NOF 39, January 2018, <https://indico.uknof.org.uk/event/41/contributions/542/ attachments/712/866/bcop-ipv6-prefix-v9.pdf>. Appendix A. Flowchart for Host Processing of RAs Conceptually, the mechanism operates as follows: Gont & Zorz Expires August 22, 2019 [Page 17]
Internet-Draft Reaction to Renumbering Events February 2019 +----------------+ | Normal proc. | | of RA packet | +---------+------+ | v +----------------+ | RA has PIO | No | with A==1? |------> DONE +----------------+ | | Yes v +----------------+ | (For each PIO) | | LTA=TRUE | +----------------+ | v +----------------+ +-----------------+ | (For each Pref | | | | assoc. with | Yes | | | this router) |----->| LTA=FALSE | | Is there corr. | | | | PIO in the RA? | | | +----------------+ +-----------------+ | | No v +----------------+ +-----------------+ +----------------+ | | | (For each addr. | | Valid Lftime=0 | | | Yes | for this Pref.) | Yes | LTA=FALSE | | LTA==TRUE? |----->| |----->| (REM. ADDR!) | | | | Pref Lftime==0? | | ! +----------------+ +-----------------+ +----------------+ | | | No | No v v +----------------+ +-----------------+ | | | Pref. Lftime=0 | | LTA=TRUE | | LTA=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 5.1: Gont & Zorz Expires August 22, 2019 [Page 18]
Internet-Draft Reaction to Renumbering Events February 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} --------------------------------------> {2001:DB8:1::/64, LTA=TRUE} . . RA, PIO={2001:DB8:2::/64, L=1, A=1} --------------------------------------> {2001:DB8:1::/64, LTA=FALSE} Pref. Lftime=0 . . RA, PIO={2001:DB8:2::/64, L=1, A=1} --------------------------------------> {2001:DB8:1::/64, LTA=TRUE} . . RA, PIO={2001:DB8:2::/64, L=1, A=1} --------------------------------------> {2001:DB8:1::/64, LTA=FALSE} Valid Lftime=0 (Addr. Removed!) Appendix C. Analysis of Some Suggested Workarounds [This section is to be removed before publication of this document as an RFC]. During the discussion of this document, some alternative workarounds were suggested (e.g. on the 6man list). The following subsections analyze these suggested workarounds, in the hopes of avoiding rehashing discussions of such workarounds. Gont & Zorz Expires August 22, 2019 [Page 19]
Internet-Draft Reaction to Renumbering Events February 2019 C.1. On a Possible Reaction to ICMPv6 Error Messages It has been suggested that if configured addresses become stale, a CPE enforcing ingress/egress filtering BCP38 ([RFC2827]) might send ICMPv6 Type 1 (Destination Unreachable) Code 5 (Source address failed ingress/egress policy) error messages to the sending node, and that, upon receipt of such error messages, the sending node might perform heuristics that might help to mitigate the problem discussed in this document. The aforementioned proposal has a number of drawbacks and limitations: o It assumes that the CPE enforces ingress/egress filtering [RFC2827]. While this is desirable behaviour, it cannot be relied upon. o It assumes that if the CPE enforces ingress/egress filtering, the CPE will signal the packet drops to the sending node with ICMPv6 Type 1 (Destination Unreachable) Code 5 (Source address failed ingress/egress policy) error messages. While this may be desirable, [RFC2827] does not suggest signaling the packet drops with ICMPv6 error messages, let alone the use of specific error messages (such as Type 1 Code 5) as suggested. o ICMPv6 Type 1 Code 5 could be interpreted as the employed address to be stale, but also as a selected route being inappropriate/ suboptimal. If the later, un-preferring addresses or removing addresses upon receipt of these error messages would be inappropriate. o Reacting to these error messages would create a new attack vector. This is of particular concern since ICMP-based attack do not even require that the Source Address of the attack packets be spoofed [RFC5927]. C.2. On a Possible Improvement to Source Address Selection [RFC6724] specifies source address selection (SAS) for IPv6. Conceptually, it sorts the candidate set of source addresses for a given destination, based on a number of pair-wise comparison rules that must be successively applied until there is a "winning" address. It has been suggested that an implementation might improve source address selection, and prefer the most-recently advertised information. In order to incorporate the "freshness" of information in source address selection, an implementation would be updated as follows: Gont & Zorz Expires August 22, 2019 [Page 20]
Internet-Draft Reaction to Renumbering Events February 2019 o The node is assumed to maintain a timer/counter that is updated at least once per second. For example, the time(2) function from unix-like systems could be employed for this purpose. o The local information associated with each prefix advertised via RAs on the local network is augmented with a "LastAdvertised" timestamp value. Whenever an RA with a PIO with the "A" bit set for such prefix is received, the "LastAdvertised" timestamp is updated with the current value of the timer/counter. o [RFC6724] is updated such that this rule is incorporated: Rule 3.5: Prefer fresh information If one of the two source addresses corresponds to a prefix that has been more recently advertised, say LastAdvertised(SA) > LastAdvertised(SA), then prefer that address (SA in our case). There are a number of limitations and drawbacks associated with this approach: o It may help to improve the selection of a source address, but it does not help with the housekeeping of configured information: * If the stale prefix is re-used in another network, nodes employing stale addresses and routes for this prefixes will be unable to communicate with the new "owners" of the prefix. * Given that currently recommended default value for the "Valid Lifetime" of PIOs is 2592000 seconds (30 days), it would take too long for hosts to remove the configured addresses and routes for the stale prefix. o The earlier the above rule is incorporated into the [RFC6724] rules, the more it could lead to suboptimal address selection. For example, if incorporated as Rule 3.5 (before Rule #4, but after Rule 3), an implementation may end up choosing a source address from a "fresher" prefix rather than one with a longest- matching prefix, thus leading to suboptimal routing. On the other hand, the later the rule is incorporated into the [RFC6724] rules, the more irrelevant the rule becomes (since existing rules might prefer the stale addresses). o In scenarios where multiple prefixes are being advertised (whether by a single router via multiple RAs, multiple routers on the same LAN segment, or different routers on different LAN segments (when a host has multiple interfaces)), the new SAS rule is guaranteed to result in non-deterministic behaviour, with hosts frequently Gont & Zorz Expires August 22, 2019 [Page 21]
Internet-Draft Reaction to Renumbering Events February 2019 changing the selected address. This is certainly not desirable from a troubleshooting perspective. As a result, updating IPv6 source address selection does not relieve nodes from improving their SLAAC implementations as specified in Section 5.1, if at all desirable. On the other hand, employing appropriate timers as specified in Section 5.1.1 would result in Rule 3 of [RFC6724] employing fresh addresses, without leading to undeterministic behaviour. 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 Jan Zorz Email: jan@go6.si Gont & Zorz Expires August 22, 2019 [Page 22]