Internet DRAFT - draft-gont-v6ops-cpe-slaac-renum
draft-gont-v6ops-cpe-slaac-renum
IPv6 Operations Working Group (v6ops) F. Gont
Internet-Draft SI6 Networks
Intended status: Informational J. Zorz
Expires: May 4, 2020
R. Patterson
Sky UK
November 1, 2019
Improving the Reaction of Customer Edge Routers to Renumbering Events
draft-gont-v6ops-cpe-slaac-renum-00
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), hosts on the local network will
continue using stale prefixes for an unacceptably long period of
time, thus resulting in connectivity problems. This document
specifies improvements to Customer Edge Routers that help mitigate
the aforementioned problem for typical residential and small office
scenarios.
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 May 4, 2020.
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
Gont, et al. Expires May 4, 2020 [Page 1]
Internet-Draft Reaction to Renumbering Events November 2019
(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
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. Improved CPE behavior . . . . . . . . . . . . . . . . . . . . 2
2.1. Interaction Between DHCPv6-PD and SLAAC . . . . . . . . . 3
2.2. Signaling Stale Configuration Information . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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. This problem is documented in detail in
[I-D.gont-v6ops-slaac-renum].
This document specifies improvements to Customer Edge Routers that
help mitigate the aforementioned problem for residential or small
office scenarios.
2. Improved CPE behavior
This section specifies and clarifies requirements for CPE routers
(particularly when they advertise with SLAAC [RFC4862] prefixes
learned via DHCPv6-PD [RFC8415]) that can help mitigate the problem
discussed in Section 1. This would obviously make robustness
dependent on the CPE (on which the user or ISP may have no control),
as opposed to the host itself.
The updated behaviour is as follows:
o CPE routers MUST signal stale configuration information as
specified in Section 2.2
Gont, et al. Expires May 4, 2020 [Page 2]
Internet-Draft Reaction to Renumbering Events November 2019
o CPE routers MUST implement the DHCPv6-PD/SLAAC interface specified
in Section 2.1.
o CPE routers SHOULD NOT automatically send DHCPv6-PD RELEASE
messages upon reboot events.
2.1. Interaction Between DHCPv6-PD and SLAAC
The "Preferred Lifetime" and "Valid Lifetime" of PIOs [RFC4861]
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."
RATIONALE:
* 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).
* The lifetime values advertised for prefixes corresponding to a
prefix leased via DHCPv6-PD should be dynamically updated
(rather than static values), since otherwise the advertised
lifetimes would eventually span past the DHCPv6-PD lease time.
2.2. Signaling Stale Configuration Information
In order to phase-out stale configuration information:
o A CPE 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 CPE router advertising prefix information via SLAAC should
proceed as follows:
Gont, et al. Expires May 4, 2020 [Page 3]
Internet-Draft Reaction to Renumbering Events November 2019
* 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.
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
must be decremented in real time) in a Router Advertisement
message as described in Section 5.5.3, (e) of [RFC4862]"
3. IANA Considerations
This document has no actions for IANA.
4. Security Considerations
This document discusses a problem that may arise in scenarios where
dynamic IPv6 prefixes are employed, and proposes improvements to
Customer Edge Routers [RFC7084] to mitigate the problem for
residential or small office scenarios. It does not introduce new
security issues.
Gont, et al. Expires May 4, 2020 [Page 4]
Internet-Draft Reaction to Renumbering Events November 2019
5. Acknowledgments
The authors would lie to thank (in alphabetical order) Mikael
Abrahamsson, Luis Balbinot, Brian Carpenter, Owen DeLong, Gert
Doering, Steinar Haug, Nick Hilliard, Philip Homburg, Lee Howard,
Christian Huitema, Ted Lemon, Albert Manfredi, Jordi Palet Martinez,
Richard Patterson, Michael Richardson, Mark Smith, Tarko Tikan, and
Ole Troan, for providing valuable comments on
[I-D.gont-6man-slaac-renum], on which this document is based.earlier
versions of this document.
Fernando would like to thank Alejandro D'Egidio and Sander Steffann
for a discussion of these issues. Fernando would also like to thank
Brian Carpenter who, over the years, has answered many questions and
provided valuable comments that has benefited his protocol-related
work.
6. References
6.1. Normative References
[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>.
[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
[I-D.gont-6man-slaac-renum]
Gont, F. and J. Zorz, "Reaction of Stateless Address
Autoconfiguration (SLAAC) to Renumbering Events", draft-
gont-6man-slaac-renum-01 (work in progress), February
2019.
Gont, et al. Expires May 4, 2020 [Page 5]
Internet-Draft Reaction to Renumbering Events November 2019
[I-D.gont-v6ops-slaac-renum]
Gont, F., Zorz, J., and R. Patterson, "Reaction of
Stateless Address Autoconfiguration (SLAAC) to Renumbering
Events", draft-gont-v6ops-slaac-renum-00 (work in
progress), July 2019.
[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>.
Authors' Addresses
Fernando Gont
SI6 Networks
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
Frankovo n. 165
Skofja Loka
Slovenia
Email: jan@go6.si
Richard Patterson
Sky UK
Email: richard.patterson@sky.uk
Gont, et al. Expires May 4, 2020 [Page 6]
