draft-ietf-v6ops-slaac-renum-01.txt   draft-ietf-v6ops-slaac-renum-02.txt 
IPv6 Operations Working Group (v6ops) F. Gont IPv6 Operations Working Group (v6ops) F. Gont
Internet-Draft SI6 Networks Internet-Draft SI6 Networks
Intended status: Informational J. Zorz Intended status: Informational J. Zorz
Expires: September 10, 2020 Go6 Institute Expires: November 6, 2020 Go6 Institute
R. Patterson R. Patterson
Sky UK Sky UK
March 9, 2020 May 5, 2020
Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash-
Renumbering Events Renumbering Events
draft-ietf-v6ops-slaac-renum-01 draft-ietf-v6ops-slaac-renum-02
Abstract Abstract
In scenarios where network configuration information related to IPv6 In scenarios where network configuration information related to IPv6
prefixes becomes invalid without any explicit signaling of that prefixes becomes invalid without any explicit signaling of that
condition (such as when a CPE crashes and reboots without knowledge condition (such as when a CPE crashes and reboots without knowledge
of the previously-employed prefixes), nodes on the local network will of the previously-employed prefixes), nodes on the local network will
continue using stale prefixes for an unacceptably long period of continue using stale prefixes for an unacceptably long period of
time, thus resulting in connectivity problems. This document time, thus resulting in connectivity problems. This document
documents this problem, and discusses operational workarounds that documents this problem, and discusses operational workarounds that
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 38 skipping to change at page 3, line 38
802.1x re-authentication. In particular there has been evidence 802.1x re-authentication. In particular there has been evidence
that some 802.1x supplicants do not reset network settings after that some 802.1x supplicants do not reset network settings after
successful 802.1x authentication. So if a host had failed 802.1x successful 802.1x authentication. So if a host had failed 802.1x
authentication for some reason, was placed in a "quarantine" VLAN authentication for some reason, was placed in a "quarantine" VLAN
and then got successfully authenticated later on, it might end up and then got successfully authenticated later on, it might end up
having IPv6 addresses from both old ("quarantine") and new VLANs. having IPv6 addresses from both old ("quarantine") and new VLANs.
o During the planned network renumbering, a router may be configured o During the planned network renumbering, a router may be configured
to send an RA with the Preferred Lifetime for the "old" Prefix to send an RA with the Preferred Lifetime for the "old" Prefix
Information Option (PIO) set to zero and the new PIO having non- 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 sent as all-hosts multicast and multicast being rather unreliable
on busy wifi networks, the RA may not be received by a host (or on busy wifi networks, the RA may not be received by a host (or
set of hosts). set of hosts).
o Automated device config management system performs periodical o Automated device config management system performs periodical
config push to network devices. If such a push results in config push to network devices. If such a push results in
changing the /64 subnet configured on a particular network, hosts changing the /64 subnet configured on a particular network, hosts
attached to that network would not get notified about the subnet attached to that network would not get notified about the subnet
change and their addresses from the "old" prefix will not change and their addresses from the "old" prefix will not
deprecated. A related scenario is the incorrect network deprecated. A related scenario is the incorrect network
skipping to change at page 4, line 32 skipping to change at page 4, line 32
week, respectively), leading to interoperability problems, instead of week, respectively), leading to interoperability problems, instead of
hosts transitioning to the newly-advertised prefix(es) in a timelier hosts transitioning to the newly-advertised prefix(es) in a timelier
manner. manner.
Some devices have implemented ad-hoc mechanisms to address this Some devices have implemented ad-hoc mechanisms to address this
problem, such as sending RAs to invalidate apparently-stale prefixes problem, such as sending RAs to invalidate apparently-stale prefixes
when the device receives any packets employing a source address from when the device receives any packets employing a source address from
a prefix not currently advertised for address configuration on the a prefix not currently advertised for address configuration on the
local network [FRITZ]. However, this may introduce other local network [FRITZ]. However, this may introduce other
interoperability problems, particularly in multihomed/multiprefix 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. warranted.
Unresponsiveness to these "flash-renumbering" events is caused by the Unresponsiveness to these "flash-renumbering" events is caused by the
inability of the network to deprecate stale information, as well as inability of the network to deprecate stale information, as well as
by the inability of hosts to react to network configuration changes by the inability of hosts to react to network configuration changes
in a timelier manner. Clearly, it would be desirable that these in a timelier manner. Clearly, it would be desirable that these
flash-renumbering scenarios do not occur, and that, when they do flash-renumbering scenarios do not occur, and that, when they do
occur, that hosts are explicitly notified of their occurrence. occur, that hosts are explicitly notified of their occurrence.
However, for robustness reasons it is also paramount for hosts to be However, for robustness reasons it is also paramount for hosts to be
able to recover from stale configuration information even when these able to recover from stale configuration information even when these
skipping to change at page 5, line 40 skipping to change at page 5, line 40
o There may be existing advice for ISPs to deliver dynamic IPv6 o There may be existing advice for ISPs to deliver dynamic IPv6
prefixes *by default* (see e.g. [GERMAN-DP]) over privacy prefixes *by default* (see e.g. [GERMAN-DP]) over privacy
concerns associated with stable prefixes. concerns associated with stable prefixes.
The authors of this document understand that, for a number of reasons The authors of this document understand that, for a number of reasons
(such as the ones stated above), IPv6 deployments may employ dynamic (such as the ones stated above), IPv6 deployments may employ dynamic
prefixes (even at the expense of the issues discussed in this prefixes (even at the expense of the issues discussed in this
document), and that there might be scenarios in which the dynamics of document), and that there might be scenarios in which the dynamics of
a network are such that the network exhibits the behaviour of dynamic 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 networks, this document aims at improving network robustness in the
deployed Internet. deployed Internet.
2.2. Default Timer Values in IPv6 Stateless Address Autoconfiguration 2.2. Default Timer Values in IPv6 Stateless Address Autoconfiguration
(SLAAC) (SLAAC)
Many protocols, from different layers, normally employ timers. The Many protocols, from different layers, normally employ timers. The
general logic is as follows: general logic is as follows:
o A timer is set with a value such that, under normal conditions, o A timer is set with a value such that, under normal conditions,
skipping to change at page 6, line 27 skipping to change at page 6, line 27
However, IPv6 SLAAC employs, for PIOs, these default values: However, IPv6 SLAAC employs, for PIOs, these default values:
o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)
o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)
Under normal network conditions, these timers will be reset/refreshed Under normal network conditions, these timers will be reset/refreshed
to the default values. However, under problematic circumstances such to the default values. However, under problematic circumstances such
as where the corresponding network information has become stale as where the corresponding network information has become stale
without any explicit signal from the network (as described in 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 corresponding addresses, and 30 days (one month) to eventually
invalidate and remove any addresses configured for the stale prefix. invalidate and remove any addresses configured for the stale prefix.
2.3. Recovering from Stale Network Configuration Information 2.3. Recovering from Stale Network Configuration Information
SLAAC hosts are unable to recover from stale network configuration SLAAC hosts are unable to recover from stale network configuration
information for a number of reasons: information for a number of reasons:
o Item "e)" of Section 5.5.3 of [RFC4862] specifies that an RA may 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 the RemainingLifetime of an address is smaller than 2 hours, then
a Valid Lifetime smaller than 2 hours will be ignored. The a Valid Lifetime smaller than 2 hours will be ignored. The
Preferred Lifetime of an address can be reduced to any value to Preferred Lifetime of an address can be reduced to any value to
avoid the use of a stale prefix to be employed for new avoid the use of a stale prefix to be employed for new
communications. communications.
o In the absence of explicit signalling from SLAAC routers (such as o In the absence of explicit signalling from SLAAC routers (such as
sending PIOs with a "Preferred Lifetime" set to 0), SLAAC hosts sending PIOs with a "Preferred Lifetime" set to 0), SLAAC hosts
fail to recover from stale configuration information in a timely fail to recover from stale configuration information in a timely
manner. However, when a network element is able to explicitly 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. the stale prefix, but not to invalidate the prefix in question.
Therefore, communication with the new "owners" of the stale prefix Therefore, communication with the new "owners" of the stale prefix
will not be possible, since the stale prefix will still be will not be possible, since the stale prefix will still be
considered "on-link". considered "on-link".
2.4. Lack of Explicit Signaling about Stale Information 2.4. Lack of Explicit Signaling about Stale Information
Whenever prefix information has changed, a SLAAC router should not Whenever prefix information has changed, a SLAAC router should not
only advertise the new information, but should also advertise the only advertise the new information, but should also advertise the
stale information with appropriate lifetime values (both "Preferred stale information with appropriate lifetime values (both "Preferred
skipping to change at page 7, line 45 skipping to change at page 7, line 45
SLAAC router implementation, meaning that, eventually, the prefix SLAAC router implementation, meaning that, eventually, the prefix
lifetime advertised on the LAN side will span *past* the DHCPv6-PD lifetime advertised on the LAN side will span *past* the DHCPv6-PD
lease time. This is clearly incorrect, since the SLAAC router lease time. This is clearly incorrect, since the SLAAC router
implementation would be allowing the use of such prefixes for a implementation would be allowing the use of such prefixes for a
longer time than it has been granted usage of those prefixes via longer time than it has been granted usage of those prefixes via
DHCPv6-PD. DHCPv6-PD.
3. Operational Mitigations 3. Operational Mitigations
The following subsections discuss possible operational workarounds The following subsections discuss possible operational workarounds
for the aforementioned problem. for the aforementioned problems.
3.1. Stable Prefixes 3.1. Stable Prefixes
As noted in Section 2.1, the use of stable prefixes would eliminate 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 the issue in *some* of the scenarios discussed in Section 1 of this
document, such as the typical home network deployment. However, even document, such as the typical home network deployment. However, even
in such scenarios, there might be reasons for which an administrator in such scenarios, there might be reasons for which an administrator
may want or may need to employ dynamic prefixes may want or may need to employ dynamic prefixes
3.2. SLAAC Parameter Tweaking 3.2. SLAAC Parameter Tweaking
An operator may wish to override some SLAAC parameters such that, An operator may wish to override some SLAAC parameters such that,
under normal circumstances (including some packet loss), the timers under normal circumstances (including some packet loss), the timers
will be refreshed/reset, but in the presence of network faults (such will be refreshed/reset, but in the presence of network faults (such
as network configuration information becoming stale without explicit as network configuration information becoming stale without explicit
signaling), the timers go off and trigger some fault recovering signaling), the timers go off and trigger some fault recovering
action (such as un-preferring the corresponding addresses and action (such as deprecating the corresponding addresses and
subsequently removing them). subsequently invalidating/removing them).
The following router configuration variables (corresponding to the The following router configuration variables (corresponding to the
"lifetime" parameters in PIOs) could be overridden as follows: "lifetime" parameters in PIOs) could be overridden as follows:
AdvValidLifetime: 48 * AdvDefaultLifetime (86400 seconds) AdvValidLifetime: 48 * AdvDefaultLifetime (86400 seconds)
AdvPreferredLifetime: AdvDefaultLifetime (1800 seconds) AdvPreferredLifetime: AdvDefaultLifetime (1800 seconds)
NOTES: A CPE router advertising a sub-prefix of a prefixed leased NOTES:
via DHCPv6-PD will periodically refresh the Preferred Lifetime and A CPE router advertising a sub-prefix of a prefixed leased via
the Valid Lifetime of an advertised prefix to AdvPreferredLifetime DHCPv6-PD will periodically refresh the Preferred Lifetime and the
and AdvValidLifetime, respectively, as long as the resulting Valid Lifetime of an advertised prefix to AdvPreferredLifetime and
lifetime of the corresponding prefixes does not extend past the AdvValidLifetime, respectively, as long as the resulting lifetime
DHCPv6-PD lease time. of the corresponding prefixes does not extend past the DHCPv6-PD
lease time.
RATIONALE: RATIONALE:
* In the context of [RFC8028], where it is clear that use of * In the context of [RFC8028], where it is clear that use of
addresses configured for a given prefix is tied to using the addresses configured for a given prefix is tied to using the
next-hop router that advertised the prefix, it does not make next-hop router that advertised the prefix, it does not make
sense for the "Preferred Lifetime" of a PIO to be larger than sense for the "Preferred Lifetime" of a PIO to be larger than
the "Router Lifetime" (AdvDefaultLifetime) of the corresponding the "Router Lifetime" (AdvDefaultLifetime) of the corresponding
Router Advertisement messages. The "Valid Lifetime" is set to Router Advertisement messages. The "Valid Lifetime" is set to
a much larger value to cope with transient network problems. a much larger value to cope with transient network problems.
* Lacking RAs that refresh information, addresses configured for * Lacking RAs that refresh information, addresses configured for
advertised prefixes become un-preferred in a timelier manner, advertised prefixes become deprecated in a timelier manner, and
and thus Rule 3 of [RFC6724] causes other configured addresses thus Rule 3 of [RFC6724] causes other configured addresses (if
(if available) to be used instead. available) to be used instead.
* We note that lowering the default values for the "Valid * We note that lowering the default values for the "Valid
Lifetime" helps reduce the amount of time a host may maintain Lifetime" helps reduce the amount of time a host may maintain
stale information and the amount of time an advertising router stale information and the amount of time an advertising router
would need to advertise stale prefixes to deprecate them, while would need to advertise stale prefixes to deprecate them, while
reducing the default "Preferred Lifetime" would reduce the reducing the default "Preferred Lifetime" would reduce the
amount of time it takes for a host to prefer other working amount of time it takes for a host to prefer other working
prefixes (see Section 12 of [RFC4861]). However, while the prefixes (see Section 12 of [RFC4861]). However, while the
aforementioned values are an improvement over the default aforementioned values are an improvement over the default
values specified in [RFC4861], they will not lead to a timely values specified in [RFC4861], they will not lead to a timely
recovery from the problem discussed in this document. recovery from the problem discussed in this document.
4. Future Work 4. Future Work
Improvement in Customer Edge Routers [RFC7084] such that they can Improvement in Customer Edge Routers [RFC7084] such that they can
signal the network about stale prefixes and deprecate them signal the network about stale prefixes and deprecate them
accordingly can help mitigate the problem discussed in this document accordingly can help mitigate the problem discussed in this document
for the "home network" scenario. Such work is currently being 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 Improvements in the SLAAC protocol [RFC4862] and other algorithms
such as "Default Address Selection for IPv6" [RFC6724] would help such as "Default Address Selection for IPv6" [RFC6724] would help
improve network robustness. Such work is currently being pursued in improve network robustness. Such work is currently being pursued in
[I-D.gont-6man-slaac-renum]. [I-D.gont-6man-slaac-renum].
The aforementioned work is considered out of the scope of this The aforementioned work is considered out of the scope of this
present document, which only focuses on documenting the problem and present document, which only focuses on documenting the problem and
discussing operational mitigations. discussing operational mitigations.
skipping to change at page 11, line 19 skipping to change at page 11, line 19
der Lander am 7./8. November 2012 in Frankfurt (Oder), der Lander am 7./8. November 2012 in Frankfurt (Oder),
November 2012, November 2012,
<http://www.bfdi.bund.de/SharedDocs/Publikationen/ <http://www.bfdi.bund.de/SharedDocs/Publikationen/
Entschliessungssammlung/DSBundLaender/84DSK_EinfuehrungIPv Entschliessungssammlung/DSBundLaender/84DSK_EinfuehrungIPv
6.pdf?__blob=publicationFile>. 6.pdf?__blob=publicationFile>.
[I-D.gont-6man-slaac-renum] [I-D.gont-6man-slaac-renum]
Gont, F., Zorz, J., and R. Patterson, "Improving the Gont, F., Zorz, J., and R. Patterson, "Improving the
Robustness of Stateless Address Autoconfiguration (SLAAC) Robustness of Stateless Address Autoconfiguration (SLAAC)
to Flash Renumbering Events", draft-gont-6man-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 Gont, F., Zorz, J., and R. Patterson, "Improving the
Reaction of Customer Edge Routers to Renumbering Events", Reaction of Customer Edge Routers to Renumbering Events",
draft-gont-v6ops-cpe-slaac-renum-00 (work in progress), draft-ietf-v6ops-cpe-slaac-renum-01 (work in progress),
November 2019. March 2020.
[I-D.linkova-6man-default-addr-selection-update] [I-D.linkova-6man-default-addr-selection-update]
Linkova, J., "Default Address Selection and Subnet Linkova, J., "Default Address Selection and Subnet
Renumbering", draft-linkova-6man-default-addr-selection- Renumbering", draft-linkova-6man-default-addr-selection-
update-00 (work in progress), March 2017. update-00 (work in progress), March 2017.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>. <https://www.rfc-editor.org/info/rfc6724>.
 End of changes. 18 change blocks. 
27 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/