Internet DRAFT - draft-linkova-6man-default-addr-selection-update
draft-linkova-6man-default-addr-selection-update
6man WG J. Linkova
Internet-Draft Google
Updates: 6724 (if approved) March 30, 2017
Intended status: Standards Track
Expires: October 1, 2017
Default Address Selection and Subnet Renumbering
draft-linkova-6man-default-addr-selection-update-00
Abstract
This document discusses some scenarios when IPv6 hosts might not be
able to properly detect the fact the network they are connected to
has changed IPv6 addressing. It proposes changes to the Default
Address Selection algorithm defined in [RFC6724] to mitigate the
impact of the abovementioned failure scenarios as well as provides
recommendations for sending Prefix Information Options (PIO). It
updated [RFC6724].
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 http://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 October 1, 2017.
Copyright Notice
Copyright (c) 2017 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
(http://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
Linkova Expires October 1, 2017 [Page 1]
Internet-Draft DAS-Update March 2017
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . 3
3. Proposed Solition . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Default Address Selection Algorithm Update . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
When an IPv6 host configures an address using Stateless Address
Autoconfiguration (SLAAC) as described in [RFC4862], the configured
address stays preferred (and therefore can be used for new
communications) until one of the following happens:
o its preferred lifetime expires
o the hosts receives an router advertisement (RA) with the
corresponding Prefix Information Option (PIO) with preferred
lifetime set to zero
o the network interface changes its status
In other words once a host get connected to a network and an IPv6
address is configured that address may be used for quite long time
(the default value of preferred lifetime is 7 days) or until the host
received an explicit notification from a router that the particular
SLAAC prefix is not valid anymore.
A host might need to stop using addresses from a particular prefix in
the following scenarios:
o the host has moved to another layer 2 domain (e.g. VLAN or LAN)
o the layer 2 domain the host is connected to has been renumbered to
another /64
Linkova Expires October 1, 2017 [Page 2]
Internet-Draft DAS-Update March 2017
In the ideal world the first scenario (a host moving to another layer
2 domain) would trigger the interface status change and as a result
all network settings being reset. In the second scenario (network
renumbering) it is expected that the router is sending an RA with the
"old" PIO preferred lifetime set to zero and then a new POI is sent
so hosts can use that POI for SLAAC. In either case the host
receives an explicit notification about the addressing change. The
preferred lifetime value is acting as a "safety net", with the
default value being 604800 seconds (7 days) ([RFC4861]) and the
realistic minimal value at least 12 seconds in the best case scenario
being too long to rely on to detect the address change.
Unfortunately in practice there are some scenarios when a failure (or
misconfiguration) on the host or the network level leds to a
situation when a host is using addresses from a prefix which should e
deprecated as it is not assigned to that layer 2 domain anymore.
This results in a host using a "wrong" IPv6 address for initiating
the connection and, as the returning packets can not reach the host,
broken IPv6 connectivity and unsatisfactory user experience.
Therefore it would be desirable to explore the feasibilty of updating
hosts and routers behavior to minimize the impact and make IPv6
implementations more robust to such failures/misconfigurations.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
"Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
2. Failure Scenarios
Scenarios when a host might not receive an explicit notification
leading to a prefix deprecation include but are not limited to:
o A switchport the host is connected to is moved to another subnet
(VLAN) as a result of manual switchport reconfiguration or 802.1x
re-authentication. In particular there have been evidence that
some 802.1x supplicants do not reset network setting after
successful 802.1x authentication. So if a host had failed 802.1x
authentication for some reasons, was placed in a "quarantine" vlan
and then got succesfully authenticated later on, it might end up
having Ipv6 addresses from both old ("quarantine") and new vlans.
o A router which had received a prefix via DHCP-PD and sent RAs with
the corresponding PIOs to hosts in LAN segments got rebooted/
crashed. After coming back up the router received a new DHCP-PD
prefix so all connected hosts received RAs with a new POI.
Linkova Expires October 1, 2017 [Page 3]
Internet-Draft DAS-Update March 2017
o During the planned network renumbering a router was configured to
send an RA with preferred lifetime for the "old" POI set to zero
and the new POI having non-zero preferred lifetime. However due
to unsolicited RAs being send as all-hosts multicast and the
multicast being rather unreliable on busy wifi network, that RA
was not received by a host
o Automated device config management system performs periodical
config push to network devices. If such a push results in
changing /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 are not
deprecated. The related case is incorrectly performed renumbering
when a network administrator is renumbering a network by simply
removing the "old" prefix from the configuration and configuring a
new prefix instead.
All those (and others) scenarios result in a situation when the host
has addresses from two different prefixes, "old" and "new". As both
addresses are preferred and allowed to be used for communication the
host relies on the default address selection algorithm ([RFC6724]) to
choose a source address. If the address from the "old" prefix is
selected as source address, then even if the packet reaches its
destination (not being dropped due to antispoofing or any other type
of filtering), the return traffic would not be delivered to the host.
3. Proposed Solition
3.1. Default Address Selection Algorithm Update
The Default Address Selection algorithm defined in [RFC6724]
describes 8 rules to choose a single source address for use with a
given IPv6 destination address. In the abovementioned scenario when
the host has preferred addresses from two GUA prefixes, the first 7
rules can not act as a tie breaker. In theory when the host moves
from one network segment from another its default router link-local
address would change and the rule 5.5, "Prefer addresses in a prefix
advertised by the next-hop" can lead to selecting a source address
from the "new" prefix. However there are two reasons why the rule
5.5 can not reliable ensure that the "new" prefix is preferred over
the "old" one:
1. The link-local address of the router in the new layer 2 domain
might be the same as the link-local address of the "old" router
(it's quite common to have link-local address on routers to be
explicitly configured, especially in VRRP-enabled environments)
Linkova Expires October 1, 2017 [Page 4]
Internet-Draft DAS-Update March 2017
2. Until recently ([RFC8028]) IPv6 implementations were not required
to track what next hop advertized what PIO and therefore the rule
5.5 was not applicable for such implementations.
The last rule, the rule 8, instructs the host to use the longest
matching prefix and according to [RFC6724] that rule MAY be
superseded if the implementation has other means of choosing among
source addresses. In all scenarios described above it seems to be
beneficial to prefer an address from the most recently received PIO.
It would ensure that if the network subnet has been changed and the
host has addresses from both "old" and "new" prefixes, it would
prefer the new prefix. In generic case choosing an address from the
most recent PIO if none of the first seven source address selection
rules can be a tie breaker is harmless. If all POIs were received in
the same time (the same RA) then the rule 8 (or any other means) can
be used to choose the source address.
Therefore this document proposes the following changes to the
Section 5 of [RFC6724]:
------------------------------------------------------------------
OLD TEXT:
Rule 8: Use longest matching prefix.
If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA.
Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then
prefer SB.
Rule 8 MAY be superseded if the implementation has other means of
choosing among source addresses. For example, if the implementation
somehow knows which source address will result in the "best"
communications performance.
NEW TEXT:
Rule 8: Use the address from the most recently refreshed prefix.
If SA's PIO was received more recently than SB's POI, then prefer SA.
Similarly, if SB's POI was received more recently than SA's POI, then
prefer SB. If the implementation does not keep track of when the
particular POI was received, than the addresses preferred lifetime
SHOULD be considered instead: if preferred lifetime(SA) > preferred
lifetime(SB), then prefer SA. Similarly, if preferred lifetime(SB) >
preferred lifetime(SA), then prefer SB.
Rule 9: Use longest matching prefix.
Linkova Expires October 1, 2017 [Page 5]
Internet-Draft DAS-Update March 2017
If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA.
Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then
prefer SB.
Rules 8 and 9 MAY be superseded if the implementation has other means
of choosing among source addresses. For example, if the
implementation somehow knows which source address will result in the
"best" communications performance.
------------------------------------------------------------------
To make the proposed solution work for the implementations which do
not record when an RA with the PIO was most recently received, both
old and new POI need to be advertised with same (or reasonably
similar) preferred lifetime value. Otherwise it is possible that
even the new POI was received after the old POI, the preferred
lifetime of the old prefix might be still higher that one of the new
prefix (if the preferred lifetime field value for the old prefix was
much higher that the corresponding value for the new prefix).
Despite such a limitation it seems reasonable to assume that in most
scenarios described in Section 2 the PIOs preferred lifetime values
would not vary much.
4. IANA Considerations
This memo asks the IANA for no new parameters.
5. Security Considerations
This memo has no direct security considerations.
6. Acknowledgements
The authors thank Erik Kline for input and contributions.
7. 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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
Linkova Expires October 1, 2017 [Page 6]
Internet-Draft DAS-Update March 2017
[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,
<http://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,
<http://www.rfc-editor.org/info/rfc4862>.
[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,
<http://www.rfc-editor.org/info/rfc6724>.
[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,
<http://www.rfc-editor.org/info/rfc8028>.
Appendix A. Change Log
Initial Version: March 2017
Author's Address
Jen Linkova
Google
Mountain View, California 94043
USA
Email: furry@google.com
Linkova Expires October 1, 2017 [Page 7]
