IPv6 Maintenance (6man) Working Group F. Gont
Internet-Draft SI6 Networks / UTN-FRH
Updates: 4861 (if approved) J. Zorz
Intended status: Standards Track January 31, 2019
Expires: August 4, 2019
Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering
Events
draft-gont-6man-slaac-renum-00
Abstract
A very common IPv6 deployment scenario is that in which a CPE employs
DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and at least one
prefix from within the leased prefix is advertised on a local network
via SLAAC. In scenarios where e.g. the CPE crashes and reboots,
nodes on the local network continue using outdated prefixes which
result in connectivity problems. This document analyzes this problem
scenario, and proposes workarounds.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 4, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Gont & Zorz Expires August 4, 2019 [Page 1]
Internet-Draft Reaction to Renumbering Events January 2019
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Possible workarounds . . . . . . . . . . . . . . . . . . . . 3
3.1. Improvement to SLAAC . . . . . . . . . . . . . . . . . . 3
3.2. Improved CPE behavior . . . . . . . . . . . . . . . . . . 5
3.3. Stable prefixes . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Flowchart for Host Processing of RAs . . . . . . . . 8
Appendix B. Sample Timeline for Host Processing of RAs . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Probably the most common deployment scenario for IPv6 in home
networks is that in which a CPE router employs DHCPv6 Prefix
Delegation (DHCPv6-PD) [RFC8415] to request a prefix from the ISP,
and a prefix belonging to the leased prefix is advertised on the LAN-
side of the CPE via Stateless Address Autoconfiguration (SLAAC)
[RFC4862].
In scenarios such as that in which the CPE router crashes and
reboots, the CPE may be leased (via DHCPv6-PD) a different prefix
than the one previously leased and will therefore advertise such new
prefix on the LAN side via SLAAC. Hosts will normally configure an
address for the new prefix, but will normally retain and actively
employ the previously-configured addresses, since their associated
Preferred Lifetime and Valid Lifetime allow them to do so. The
default values, as specified in [RFC4861] are:
o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)
o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)
Lacking any explicit signaling to "obsolete" the previously-
configured addresses (for the now invalid/outdated prefix), hosts may
continue employing the previously-configured addresses which will
tipically result in packets being blackholed -- whether because of
Gont & Zorz Expires August 4, 2019 [Page 2]
Internet-Draft Reaction to Renumbering Events January 2019
egress-filtering by the CPE or ISP, or because responses to such
packets will be discarded or routed elsewhere.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Possible workarounds
The following subsections discuss possible workarounds for the
aforementioned problem.
3.1. Improvement to SLAAC
This section specifies an improvement to SLAAC that improves
robustness and that can mitigate the aforementioned problem.
The goal of this modification is that, when a router that was
previously advertising a prefix for address configuration (PIO with
the "A" bit set) is found to advertise other prefixes but not the
previously-advertised prefixes, addresses configured for the "old"
prefixes are marked as "not preferred" (i.e., their "Preferred
Lifetime" is set to 0), thus allowing for a more timely-reaction to
the problem described in Section 1.
Local information maintained for each prefix advertised by each
router is augmented with one boolean flag named "deprecate" that
defaults to "false". Note: hosts are already expected to keep track
of which router has advertised which prefix in order to be able to
properly select the first-hop router in multiple-prefix networks
[RFC8028] [I-D.ietf-6man-rfc6434-bis].
After normal processing of Router Advertisement messages, Router
Advertisements that contain at least one PIO MUST be processed as
follows:
o The "deprecate" flag for each prefix advertised in the current
Router Advertisement should be set to "false".
o For each prefix that had been previously advertised by this router
but that does not have a corresponding PIO with the "A" flag set
in the received RA, proceed as follows:
* IF the "deprecate" flag is "true", then:
Gont & Zorz Expires August 4, 2019 [Page 3]
Internet-Draft Reaction to Renumbering Events January 2019
+ IF there is any address configured for this prefix with a
"Preferred Lifetime" larger than 0, set its "Preferred
Lifetime" to 0, and the "deprecate flag" of this prefix to
"false".
+ ELSE (all addresses for this prefix have a "Preferred
Lifetime" of 0), set the "Valid Lifetime" of any addresses
configured for this prefix to 0, and the "deprecate" flag to
"false". This will cause removal of all addresses for this
prefix. Additionally, if the corresponding prefix had been
advertised as on-link ("L"=1) by this router, remove any
routes to this prefix associated with the network interface
card on which the RA packet was received.
* ELSE (the "deprecate" flag is "false"):
+ Set the "deprecate" flag of the corresponding prefix to
"true".
Appendix B illustrates the packet exchange and operation of the
algorithm for a typical scenario. Appendix A provides a flowchart
for this algorithm.
NOTES:
o The aforementioned processing assumes that while network
configuration information might be split into multiple RAs, PIOs
will be spread among *at most* two RAs. This assumption avoids
the use of any timers for this specific purpose.
o If the only prefix that has so far been advertised on the local
network is the prefix that has become outdated, and there is no
new prefix being advertised, the traditional processing is
unaffected (the mechanism discussed in this document will *never*
be triggered because no packets with PIOs with the "A" flag will
be received). The logic here is that it's better to have some
address, than no address at all.
o The processing of RAs that do not contain any PIOs with the "A"
bit set remain unaffected.
o The specified modification takes the conservative approach of
first setting the "Preferred Lifetime" to 0 (such that addresses
become non-preferred), and subsequently setting the "Valid
Lifetime" to 0 (such as the addresses are completely removed).
Once the addresses for this prefix have been removed, routes to
this prefix associated with the network interface on which the RA
packets were received are also removed.
Gont & Zorz Expires August 4, 2019 [Page 4]
Internet-Draft Reaction to Renumbering Events January 2019
3.2. Improved CPE behavior
The scenario discussed in Section 1 could be improved on the CPE-side
as follows:
o A CPE MUST record, on stable storage, the list of prefixes being
advertised on each LAN segment.
o Upon renewed information about the list of prefixes to be
advertised on the LAN-side (whether as a result of DHCPv6-PD or
manual configuration), then:
* Any prefixes that were previously advertised via SLAAC, but
that are not currently intended for address configuration, MUST
be advertised with a PIO option with the "A" bit set to 1 and
the "Valid Lifetime" and a "Preferred Lifetime" set to 0.
* Any prefixes that were previously advertised via SLAAC as "on-
link", but that are not currently not considered "on-link",
MUST be advertised with a PIO option with the "L" bit set to 1
and the "Valid Lifetime" and a "Preferred Lifetime" set to 0.
* If both of the previous conditions are met (a prefix was
previously advertised with both the "A" and "L" bits set, but
is currently *not* intended for address configuration and is
*not* considered on-link), the prefix MUST be advertised with a
PIO option with both the "A" and "L" bits set to 1 and the
"Valid Lifetime" and a "Preferred Lifetime" set to 0. That is.
the advertisements of the previous two steps can be coalesced
into a single one with both the "A" and "L" bits set.
The aforementioned advertisement SHOULD be performed for at least the
"Valid Lifetime" previously employed for such prefix.
This improves the situation for hosts that do not implement the
modification specified in Section 3.1 but would obviously make
robustness dependent on the CPE, as opposed to the host itself.
3.3. Stable prefixes
The problem discussed in this document would be avoided if DHCPv6-PD
would lease "stable" prefixes.
There are a number of possible issues associated with this option:
o Provisioning systems may be unable to deliver stable IPv6
prefixes.
Gont & Zorz Expires August 4, 2019 [Page 5]
Internet-Draft Reaction to Renumbering Events January 2019
o While there is a range of information that may be employed to
correlate network activity [RFC7721], the use of stable prefixes
clearly simplifies network activity correlation, and may
essentially render features such as "temporary addresses"
[RFC4941] irrelevant.
o Applicable legislation may require the ISP to deliver dynamic IPv6
prefixes *by default* (see e.g. [GERMAN-DP]).
4. Security Considerations
This document discusses a a problem that may arise in scenarios where
dynamic IPv6 prefixes are employed, and proposes workarounds that
enable such usage while avoiding interoperability problems. The
security and privacy implications of IPv6 addresses are discussed in
[RFC7721].
An attacker that could impersonate a router could forge multiple RA
packets that contain PIOs of prefixes that are currently not
advertised on the local network, to trigger the mechanism specified
in this document to cause addresses currently configured for the
legitimate prefixes to be removed. However, an attacker that can
impersonate a router could more easily achieve the same goal by
advertising the legitimate prefixes with both the "Preferred
Lifetime" and "Valid Lifetime" set to 0.
Attacks based on forged RA packed can be mitigated with technologies
such as RA-Guard [RFC6105] [RFC7113].
5. Acknowledgments
The authors would lie to thank (in alphabetical order) [TBD] for
providing valuable comments on earlier versions of this document.
Fernando would like to thank Alejandro D'Egidio , and Sander Steffan
for a discussion of these issues.
The problem discussed in this document, and the recommendation to
employ stable prefixes, have been previously documented in
[RIPE-690].
6. References
6.1. Normative References
Gont & Zorz Expires August 4, 2019 [Page 6]
Internet-Draft Reaction to Renumbering Events January 2019
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016,
<https://www.rfc-editor.org/info/rfc8028>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
6.2. Informative References
[GERMAN-DP]
BFDI, "Einfuhrung von IPv6 Hinweise fur Provider im
Privatkundengeschaft und Herstellere", Entschliessung der
84. Konferenz der Datenschutzbeauftragten des Bundes und
der Lander am 7./8. November 2012 in Frankfurt (Oder),
November 2012,
<http://www.bfdi.bund.de/SharedDocs/Publikationen/
Entschliessungssammlung/DSBundLaender/84DSK_EinfuehrungIPv
6.pdf?__blob=publicationFile>.
[I-D.ietf-6man-rfc6434-bis]
Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", draft-ietf-6man-rfc6434-bis-09 (work in
progress), July 2018.
Gont & Zorz Expires August 4, 2019 [Page 7]
Internet-Draft Reaction to Renumbering Events January 2019
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/info/rfc6105>.
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", RFC 7113,
DOI 10.17487/RFC7113, February 2014,
<https://www.rfc-editor.org/info/rfc7113>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.
[RIPE-690]
RIPE, Zorz, J., Zorz, S., Drazumeric, P., Townsley, M.,
Alston, J., Doering, G., Palet, J., Linkova, J., Balbinot,
L., Meynell, K., and L. Howard, "Best Current Operational
Practice for Operators: IPv6 prefix assignment for end-
users - persistent vs non-persistent, and what size to
choose", RIPE 690, October 2017,
<https://www.ripe.net/publications/docs/ripe-690>.
Appendix A. Flowchart for Host Processing of RAs
Conceptually, the mechanism operates as follows:
Gont & Zorz Expires August 4, 2019 [Page 8]
Internet-Draft Reaction to Renumbering Events January 2019
+-------------------+
| Normal processing |
| of RA packet |
+---------+---------+
|
v
+-------------------+
| RA has PIO with | No
| A==1? |------> DONE
+-------------------+
|
| Yes
v
+-------------------+
| (For each PIO) |
| deprecate=TRUE |
+-------------------+
|
v
+-------------------+ +-----------------+
| (For each Pref. | | |
| assoc with this | Yes | |
| router) |----->| deprecate=FALSE |
| Is there corresp. | | |
| PIO in the RA? | | |
+-------------------+ +-----------------+
|
| No
v
+-------------------+ +------------------+ +-----------------+
| | | (For each addr. | | Valid Lftime=0 |
| | Yes | for this Prefix) | Yes | deprecate=FALSE |
| deprecate==TRUE? |----->| |----->| (REM. ADDR!) |
| | | Pref. Lftime==0? | | !
+-------------------+ +------------------+ +-----------------+
| |
| No | No
v v
+-------------------+ +------------------+
| | | Pref. Lftime=0 |
| deprecate=TRUE | | deprecate=FALSE |
+-------------------+ +------------------+
Appendix B. Sample Timeline for Host Processing of RAs
The following example illustrates a sample packet exchange that
illustrates the algorithm specified in Section 3.1:
Gont & Zorz Expires August 4, 2019 [Page 9]
Internet-Draft Reaction to Renumbering Events January 2019
Router Host
RA, PIO={2001:DB8:1::/64, L=1, A=1}
-------------------------------------->
[Host configures addrs
for this prefix]
RA, PIO={2001:DB8:1::/64, L=1, A=1}
-------------------------------------->
[Normal proc. of RA]
.
.
[Router reboots]
RA, PIO={2001:DB8:2::/64, L=1, A=1}
-------------------------------------->
deprecate=TRUE
.
.
RA, PIO={2001:DB8:2::/64, L=1, A=1}
-------------------------------------->
Pref. Lftime=0
deprecate=FALSE
.
.
RA, PIO={2001:DB8:2::/64, L=1, A=1}
-------------------------------------->
deprecate=TRUE
.
.
RA, PIO={2001:DB8:2::/64, L=1, A=1}
-------------------------------------->
Valid Lftime=0
deprecate=FALSE
(Addr. Removed!)
Authors' Addresses
Fernando Gont
SI6 Networks / UTN-FRH
Segurola y Habana 4310, 7mo Piso
Villa Devoto, Ciudad Autonoma de Buenos Aires
Argentina
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: https://www.si6networks.com
Gont & Zorz Expires August 4, 2019 [Page 10]
Internet-Draft Reaction to Renumbering Events January 2019
Jan Zorz
Email: jan@go6.si
Gont & Zorz Expires August 4, 2019 [Page 11]