--- 1/draft-ietf-v6ops-slaac-renum-01.txt 2020-05-05 04:14:55.786622016 -0700 +++ 2/draft-ietf-v6ops-slaac-renum-02.txt 2020-05-05 04:14:55.818622843 -0700 @@ -1,22 +1,22 @@ IPv6 Operations Working Group (v6ops) F. Gont Internet-Draft SI6 Networks Intended status: Informational J. Zorz -Expires: September 10, 2020 Go6 Institute +Expires: November 6, 2020 Go6 Institute R. Patterson Sky UK - March 9, 2020 + May 5, 2020 Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- Renumbering Events - draft-ietf-v6ops-slaac-renum-01 + draft-ietf-v6ops-slaac-renum-02 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 documents this problem, and discusses operational workarounds that @@ -31,21 +31,21 @@ 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 September 10, 2020. + This Internet-Draft will expire on November 6, 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 @@ -120,21 +120,21 @@ 802.1x re-authentication. In particular there has been evidence that some 802.1x supplicants do not reset network settings after successful 802.1x authentication. So if a host had failed 802.1x authentication for some reason, was placed in a "quarantine" VLAN and then got successfully authenticated later on, it might end up having IPv6 addresses from both old ("quarantine") and new VLANs. o During the planned network renumbering, a router may be configured to send an RA with the Preferred Lifetime for the "old" Prefix Information Option (PIO) set to zero and the new PIO having non- - zero preferred lifetime. However, due to unsolicited RAs being + zero Preferred Lifetime. However, due to unsolicited RAs being sent as all-hosts multicast and multicast being rather unreliable on busy wifi networks, the RA may not be received by a host (or set of hosts). o Automated device config management system performs periodical config push to network devices. If such a push results in changing the /64 subnet configured on a particular network, hosts attached to that network would not get notified about the subnet change and their addresses from the "old" prefix will not deprecated. A related scenario is the incorrect network @@ -162,21 +162,21 @@ week, respectively), leading to interoperability problems, instead of hosts transitioning to the newly-advertised prefix(es) in a timelier manner. Some devices have implemented ad-hoc mechanisms to address this problem, such as sending RAs to invalidate apparently-stale prefixes when the device receives any packets employing a source address from a prefix not currently advertised for address configuration on the local network [FRITZ]. However, this may introduce other interoperability problems, particularly in multihomed/multiprefix - scenarios. This is clear indication that advice in this area is + scenarios. This is a clear indication that advice in this area is warranted. Unresponsiveness to these "flash-renumbering" events is caused by 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 would be desirable that these flash-renumbering scenarios do not occur, and that, when they do occur, that hosts are explicitly notified of their occurrence. However, for robustness reasons it is also paramount for hosts to be able to recover from stale configuration information even when these @@ -215,21 +215,21 @@ o There may be existing advice for ISPs to deliver dynamic IPv6 prefixes *by default* (see e.g. [GERMAN-DP]) over privacy concerns associated with stable prefixes. The authors of this document understand that, for a number of reasons (such as the ones stated above), IPv6 deployments may employ dynamic prefixes (even at the expense of the issues discussed in this document), and that 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 + prefixes. Rather than trying to regulate how operators may run their networks, this document aims at improving network robustness in the deployed Internet. 2.2. 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 such that, under normal conditions, @@ -250,42 +250,42 @@ 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 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 + Section 1), it will take a host 7 days (one week) to deprecate the corresponding addresses, and 30 days (one month) to eventually invalidate and remove any addresses configured for the stale prefix. 2.3. Recovering from Stale Network Configuration Information SLAAC hosts are unable to recover from stale network configuration information for a number of reasons: o Item "e)" of Section 5.5.3 of [RFC4862] specifies that an RA may - never reduce the "RemainingLifetime" more than to two hours. If + never reduce the "RemainingLifetime" to less than two hours. If the RemainingLifetime of an address is smaller than 2 hours, then a Valid Lifetime smaller than 2 hours will be ignored. The Preferred Lifetime of an address can be reduced to any value to avoid the use of a stale prefix to be employed for new communications. o In the absence of explicit signalling from SLAAC routers (such as sending PIOs with a "Preferred Lifetime" set to 0), SLAAC hosts fail to recover from stale configuration information in a timely manner. However, when a network element is able to explicitly - signal the renumbering event, it will only be able to "un-prefer" + signal the renumbering event, it will only be able to deprecate the stale prefix, but not to invalidate the prefix in question. Therefore, communication with the new "owners" of the stale prefix will not be possible, since the stale prefix will still be considered "on-link". 2.4. 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 @@ -317,87 +317,88 @@ 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. 3. Operational Mitigations The following subsections discuss possible operational workarounds - for the aforementioned problem. + for the aforementioned problems. 3.1. Stable Prefixes As noted in Section 2.1, the use of stable prefixes would eliminate the issue in *some* of the scenarios discussed in Section 1 of this document, such as the typical home network deployment. However, even in such scenarios, there might be reasons for which an administrator may want or may need to employ dynamic prefixes 3.2. SLAAC Parameter Tweaking An operator may wish to override some SLAAC parameters such that, under normal circumstances (including some packet loss), the timers will be refreshed/reset, 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). + action (such as deprecating the corresponding addresses and + subsequently invalidating/removing them). The following router configuration variables (corresponding to the "lifetime" parameters in PIOs) could be overridden as follows: AdvValidLifetime: 48 * AdvDefaultLifetime (86400 seconds) AdvPreferredLifetime: AdvDefaultLifetime (1800 seconds) - NOTES: A CPE router advertising a sub-prefix of a prefixed leased - via DHCPv6-PD will periodically refresh the Preferred Lifetime and - the Valid Lifetime of an advertised prefix to AdvPreferredLifetime - and AdvValidLifetime, respectively, as long as the resulting - lifetime of the corresponding prefixes does not extend past the - DHCPv6-PD lease time. + NOTES: + A CPE router advertising a sub-prefix of a prefixed leased via + DHCPv6-PD will periodically refresh the Preferred Lifetime and the + Valid Lifetime of an advertised prefix to AdvPreferredLifetime and + AdvValidLifetime, respectively, as long as the resulting lifetime + of the corresponding prefixes does not extend past the DHCPv6-PD + lease time. RATIONALE: * In the context of [RFC8028], where it is clear that use of addresses configured for a given prefix is tied to using the next-hop router that advertised the prefix, it does not make sense for the "Preferred Lifetime" of a PIO to be larger than the "Router Lifetime" (AdvDefaultLifetime) of the corresponding Router Advertisement messages. The "Valid Lifetime" is set to a much larger value to cope with transient network problems. * Lacking RAs that refresh information, addresses configured for - advertised prefixes become un-preferred in a timelier manner, - and thus Rule 3 of [RFC6724] causes other configured addresses - (if available) to be used instead. + advertised prefixes become deprecated in a timelier manner, and + thus Rule 3 of [RFC6724] causes other configured addresses (if + available) to be used instead. * We note that lowering the default values for the "Valid Lifetime" helps reduce the amount of time a host may maintain stale information and the amount of time an advertising router would need to advertise stale prefixes to deprecate them, while reducing the default "Preferred Lifetime" would reduce the amount of time it takes for a host to prefer other working prefixes (see Section 12 of [RFC4861]). However, while the aforementioned values are an improvement over the default values specified in [RFC4861], they will not lead to a timely recovery from the problem discussed in this document. 4. Future Work Improvement in Customer Edge Routers [RFC7084] such that they can signal the network about stale prefixes and deprecate them accordingly can help mitigate the problem discussed in this document for the "home network" scenario. Such work is currently being - pursued in [I-D.gont-v6ops-cpe-slaac-renum]. + pursued in [I-D.ietf-v6ops-cpe-slaac-renum]. Improvements in the SLAAC protocol [RFC4862] and other algorithms such as "Default Address Selection for IPv6" [RFC6724] would help improve network robustness. Such work is currently being pursued in [I-D.gont-6man-slaac-renum]. The aforementioned work is considered out of the scope of this present document, which only focuses on documenting the problem and discussing operational mitigations. @@ -479,27 +480,27 @@ der Lander am 7./8. November 2012 in Frankfurt (Oder), November 2012, . [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-02 (work in progress), February 2020. + renum-07 (work in progress), April 2020. - [I-D.gont-v6ops-cpe-slaac-renum] + [I-D.ietf-v6ops-cpe-slaac-renum] Gont, F., Zorz, J., and R. Patterson, "Improving the Reaction of Customer Edge Routers to Renumbering Events", - draft-gont-v6ops-cpe-slaac-renum-00 (work in progress), - November 2019. + draft-ietf-v6ops-cpe-slaac-renum-01 (work in progress), + March 2020. [I-D.linkova-6man-default-addr-selection-update] Linkova, J., "Default Address Selection and Subnet Renumbering", draft-linkova-6man-default-addr-selection- update-00 (work in progress), March 2017. [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, .