draft-ietf-6man-rfc4941bis-08.txt   draft-ietf-6man-rfc4941bis-09.txt 
IPv6 Maintenance (6man) Working Group F. Gont IPv6 Maintenance (6man) Working Group F. Gont
Internet-Draft SI6 Networks / UTN-FRH Internet-Draft SI6 Networks / UTN-FRH
Obsoletes: rfc4941 (if approved) S. Krishnan Obsoletes: rfc4941 (if approved) S. Krishnan
Intended status: Standards Track Ericsson Research Intended status: Standards Track Ericsson Research
Expires: September 28, 2020 T. Narten Expires: October 8, 2020 T. Narten
IBM Corporation IBM Corporation
R. Draves R. Draves
Microsoft Research Microsoft Research
March 27, 2020 April 6, 2020
Temporary Address Extensions for Stateless Address Autoconfiguration in Temporary Address Extensions for Stateless Address Autoconfiguration in
IPv6 IPv6
draft-ietf-6man-rfc4941bis-08 draft-ietf-6man-rfc4941bis-09
Abstract Abstract
This document describes an extension that causes nodes to generate This document describes an extension that causes nodes to generate
global scope addresses with randomized interface identifiers that global scope addresses with randomized interface identifiers that
change over time. Changing global scope addresses over time limits change over time. Changing global scope addresses over time limits
the window of time during which eavesdroppers and other information the window of time during which eavesdroppers and other information
collectors may trivially perform address-based network activity collectors may trivially perform address-based network activity
correlation when the same address is employed for multiple correlation when the same address is employed for multiple
transactions by the same node. Additionally, it reduces the window transactions by the same node. Additionally, it reduces the window
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 28, 2020. This Internet-Draft will expire on October 8, 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 2, line 43 skipping to change at page 2, line 43
3.3.2. Hash-based Generation of Randomized Interface 3.3.2. Hash-based Generation of Randomized Interface
Identifiers . . . . . . . . . . . . . . . . . . . . . 9 Identifiers . . . . . . . . . . . . . . . . . . . . . 9
3.4. Generating Temporary Addresses . . . . . . . . . . . . . 10 3.4. Generating Temporary Addresses . . . . . . . . . . . . . 10
3.5. Expiration of Temporary Addresses . . . . . . . . . . . . 12 3.5. Expiration of Temporary Addresses . . . . . . . . . . . . 12
3.6. Regeneration of Temporary Addresses . . . . . . . . . . . 12 3.6. Regeneration of Temporary Addresses . . . . . . . . . . . 12
3.7. Implementation Considerations . . . . . . . . . . . . . . 13 3.7. Implementation Considerations . . . . . . . . . . . . . . 13
3.8. Defined Constants . . . . . . . . . . . . . . . . . . . . 14 3.8. Defined Constants . . . . . . . . . . . . . . . . . . . . 14
4. Implications of Changing Interface Identifiers . . . . . . . 15 4. Implications of Changing Interface Identifiers . . . . . . . 15
5. Significant Changes from RFC4941 . . . . . . . . . . . . . . 15 5. Significant Changes from RFC4941 . . . . . . . . . . . . . . 15
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Stateless address autoconfiguration (SLAAC) [RFC4862] defines how an Stateless address autoconfiguration (SLAAC) [RFC4862] defines how an
IPv6 node generates addresses without the need for a Dynamic Host IPv6 node generates addresses without the need for a Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) server. The security and Configuration Protocol for IPv6 (DHCPv6) server. The security and
privacy implications of such addresses have been discussed in detail privacy implications of such addresses have been discussed in detail
in [RFC7721],[RFC7217], and RFC7707. This document specifies an in [RFC7721],[RFC7217], and RFC7707. This document specifies an
extension for SLAAC to generate temporary addresses, that can help extension for SLAAC to generate temporary addresses, that can help
mitigate some of the aforementioned issues. This is a revision of mitigate some of the aforementioned issues. This is a revision of
skipping to change at page 17, line 5 skipping to change at page 17, line 5
protocols are using it (but not before). This is in contrast to protocols are using it (but not before). This is in contrast to
current approaches where addresses are removed from an interface when current approaches where addresses are removed from an interface when
they become invalid [RFC4862], independent of whether or not upper they become invalid [RFC4862], independent of whether or not upper
layer protocols are still using them. For TCP connections, such layer protocols are still using them. For TCP connections, such
information is available in control blocks. For UDP-based information is available in control blocks. For UDP-based
applications, it may be the case that only the applications have applications, it may be the case that only the applications have
knowledge about what addresses are actually in use. Consequently, an knowledge about what addresses are actually in use. Consequently, an
implementation generally will need to use heuristics in deciding when implementation generally will need to use heuristics in deciding when
an address is no longer in use. an address is no longer in use.
7. Security Considerations 7. Implementation Status
[The RFC-Editor should remove this section before publishing this
document as an RFC]
The following are known implementations of this document:
o FreeBSD kernel: There is a FreeBSD kernel implementation of this
document, albeit not yet committed. The implementation has been
done in April 2020 by Fernando Gont <fgont@si6networks.com>. The
corresponding patch can be found at:
<https://www.gont.com.ar/code/fgont-patch-linux-net-next-
rfc4941bis.txt>
o Linux kernel: There is a Linux kernel implementation of this
document for the net-next tree, albeit not yet committed. The
implementation has been done in April 2020 by Fernando Gont
<fgont@si6networks.com>. The corresponding patch can be found at:
<https://www.gont.com.ar/code/fgont-patch-linux-net-next-
rfc4941bis.txt>
o slaacd(8): slaacd(8) has traditionally used different randomized
interface identifiers for each prefix, and it has recently reduced
the Valid Lifetime of temporary addresses as specified in
Section 3.8, thus fully implementing this document. The
implementation has been done by Florian Obser
<florian@openbsd.org>, with the update to the temporary address
Valid Lifetime applied in March 2020. The implementation can be
found at: <https://github.com/openbsd/src/tree/master/sbin/slaacd>
8. Security Considerations
If a very small number of nodes (say, only one) use a given prefix If a very small number of nodes (say, only one) use a given prefix
for extended periods of time, just changing the interface identifier for extended periods of time, just changing the interface identifier
part of the address may not be sufficient to mitigate address-based part of the address may not be sufficient to mitigate address-based
network activity correlation, since the prefix acts as a constant network activity correlation, since the prefix acts as a constant
identifier. The procedures described in this document are most identifier. The procedures described in this document are most
effective when the prefix is reasonably non static or is used by a effective when the prefix is reasonably non static or is used by a
fairly large number of nodes. Additionally, if a temporary address fairly large number of nodes. Additionally, if a temporary address
is used in a session where the user authenticates, any notion of is used in a session where the user authenticates, any notion of
"privacy" for that address is compromised. "privacy" for that address is compromised.
skipping to change at page 17, line 34 skipping to change at page 18, line 16
preventing the use of spoofed source addresses in Distributed Denial preventing the use of spoofed source addresses in Distributed Denial
of Service (DDoS) attacks. In a network with a large number of of Service (DDoS) attacks. In a network with a large number of
nodes, new temporary addresses are created at a fairly high rate. nodes, new temporary addresses are created at a fairly high rate.
This might make it difficult for ingress filtering mechanisms to This might make it difficult for ingress filtering mechanisms to
distinguish between legitimately changing temporary addresses and distinguish between legitimately changing temporary addresses and
spoofed source addresses, which are "in-prefix" (using a spoofed source addresses, which are "in-prefix" (using a
topologically correct prefix and non-existent interface ID). This topologically correct prefix and non-existent interface ID). This
can be addressed by using access control mechanisms on a per-address can be addressed by using access control mechanisms on a per-address
basis on the network egress point. basis on the network egress point.
8. Acknowledgments 9. Acknowledgments
The authors would like to thank (in alphabetical order) Fred Baker, The authors would like to thank (in alphabetical order) Fred Baker,
Brian Carpenter, Tim Chown, Lorenzo Colitti, David Farmer, Tom Brian Carpenter, Tim Chown, Lorenzo Colitti, David Farmer, Tom
Herbert, Bob Hinden, Christian Huitema, Erik Kline, Gyan Mishra, Dave Herbert, Bob Hinden, Christian Huitema, Erik Kline, Gyan Mishra, Dave
Plonka, Michael Richardson, Mark Smith, Pascal Thubert, Ole Troan, Plonka, Michael Richardson, Mark Smith, Pascal Thubert, Ole Troan,
Johanna Ullrich, and Timothy Winters, for providing valuable comments Johanna Ullrich, and Timothy Winters, for providing valuable comments
on earlier versions of this document. on earlier versions of this document.
This document incorporates errata submitted for [RFC4941] by Jiri This document incorporates errata submitted for [RFC4941] by Jiri
Bohac and Alfred Hoenes. Bohac and Alfred Hoenes.
skipping to change at page 18, line 10 skipping to change at page 18, line 40
acknowledge the contributions of the IPv6 working group and, in acknowledge the contributions of the IPv6 working group and, in
particular, Jari Arkko, Pekka Nikander, Pekka Savola, Francis Dupont, particular, Jari Arkko, Pekka Nikander, Pekka Savola, Francis Dupont,
Brian Haberman, Tatuya Jinmei, and Margaret Wasserman for their Brian Haberman, Tatuya Jinmei, and Margaret Wasserman for their
detailed comments. detailed comments.
Rich Draves and Thomas Narten were the authors of RFC 3041. They Rich Draves and Thomas Narten were the authors of RFC 3041. They
would like to acknowledge the contributions of the IPv6 working group would like to acknowledge the contributions of the IPv6 working group
and, in particular, Ran Atkinson, Matt Crawford, Steve Deering, and, in particular, Ran Atkinson, Matt Crawford, Steve Deering,
Allison Mankin, and Peter Bieringer. Allison Mankin, and Peter Bieringer.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
skipping to change at page 19, line 24 skipping to change at page 20, line 5
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda,
"Updates to the Special-Purpose IP Address Registries", "Updates to the Special-Purpose IP Address Registries",
BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017,
<https://www.rfc-editor.org/info/rfc8190>. <https://www.rfc-editor.org/info/rfc8190>.
9.2. Informative References 10.2. Informative References
[FIPS-SHS] [FIPS-SHS]
NIST, "Secure Hash Standard (SHS)", FIPS NIST, "Secure Hash Standard (SHS)", FIPS
Publication 180-4, August 2015, Publication 180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>. NIST.FIPS.180-4.pdf>.
[I-D.ietf-mboned-ieee802-mcast-problems] [I-D.ietf-mboned-ieee802-mcast-problems]
Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
Zuniga, "Multicast Considerations over IEEE 802 Wireless Zuniga, "Multicast Considerations over IEEE 802 Wireless
 End of changes. 10 change blocks. 
15 lines changed or deleted 46 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/