draft-ietf-6man-rfc4941bis-10.txt   draft-ietf-6man-rfc4941bis-11.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
Obsoletes: rfc4941 (if approved) S. Krishnan Obsoletes: 4941 (if approved) S. Krishnan
Intended status: Standards Track Kaloom Intended status: Standards Track Kaloom
Expires: February 27, 2021 T. Narten Expires: April 3, 2021 T. Narten
IBM Corporation
R. Draves R. Draves
Microsoft Research Microsoft Research
August 26, 2020 September 30, 2020
Temporary Address Extensions for Stateless Address Autoconfiguration in Temporary Address Extensions for Stateless Address Autoconfiguration in
IPv6 IPv6
draft-ietf-6man-rfc4941bis-10 draft-ietf-6man-rfc4941bis-11
Abstract Abstract
This document describes an extension that causes nodes to generate This document describes an extension to IPv6 Stateless Address
global scope addresses with randomized interface identifiers that Autoconfiguration that causes nodes to generate global scope
change over time. Changing global scope addresses over time limits addresses with randomized interface identifiers that change over
the window of time during which eavesdroppers and other information time. Changing global scope addresses over time limits the window of
collectors may trivially perform address-based network activity time during which eavesdroppers and other information collectors may
correlation when the same address is employed for multiple trivially perform address-based network activity correlation when the
transactions by the same node. Additionally, it reduces the window same address is employed for multiple transactions by the same node.
of exposure of a node via an address that becomes revealed as a Additionally, it reduces the window of exposure of a node via an
result of active communication. This document obsoletes RFC4941. address that becomes revealed as a result of active communication.
This document obsoletes RFC4941.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 February 27, 2021. This Internet-Draft will expire on April 3, 2021.
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 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Extended Use of the Same Identifier . . . . . . . . . . . 4 2.1. Extended Use of the Same Identifier . . . . . . . . . . . 4
2.2. Possible Approaches . . . . . . . . . . . . . . . . . . . 6 2.2. Possible Approaches . . . . . . . . . . . . . . . . . . . 6
3. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
3.1. Design Guidelines . . . . . . . . . . . . . . . . . . . . 6 3.1. Design Guidelines . . . . . . . . . . . . . . . . . . . . 7
3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Generation of Randomized Interface Identifiers . . . . . 8 3.3. Generation of Randomized Interface Identifiers . . . . . 8
3.3.1. Simple Randomized Interface Identifiers . . . . . . . 8 3.3.1. Simple Randomized Interface Identifiers . . . . . . . 8
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 . . . . . . . . . . . . . . 14 3.7. Implementation Considerations . . . . . . . . . . . . . . 14
3.8. Defined Constants and Configuration Variables . . . . . . 14 3.8. Defined Constants and Configuration Variables . . . . . . 14
4. Implications of Changing Interface Identifiers . . . . . . . 15 4. Implications of Changing Interface Identifiers . . . . . . . 15
5. Significant Changes from RFC4941 . . . . . . . . . . . . . . 16 5. Significant Changes from RFC4941 . . . . . . . . . . . . . . 16
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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
RFC4941, and formally obsoletes RFC4941. Section 5 describes the RFC4941, and formally obsoletes RFC4941. Section 5 describes the
changes from [RFC4941]. changes from [RFC4941].
The default address selection for IPv6 has been specified in The default address selection for IPv6 has been specified in
[RFC6724]. The determination as to whether to use stable versus [RFC6724]. The determination as to whether to use stable versus
temporary addresses can in some cases only be made by an application. temporary addresses can in some cases only be made by an application.
For example, some applications may always want to use temporary For example, some applications may always want to use temporary
addresses, while others may want to use them only in some addresses, while others may want to use them only in some
skipping to change at page 3, line 47 skipping to change at page 3, line 47
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The terms "public address", "stable address", "temporary address", The terms "public address", "stable address", "temporary address",
"constant IID", "stable IID", and "temporary IID" are to be "constant IID", "stable IID", and "temporary IID" are to be
interpreted as specified in [RFC7721]. interpreted as specified in [RFC7721].
The term "global scope addresses" is used in this document to The term "global scope addresses" is used in this document to
collectively refer to "Global unicast addresses" as defined in collectively refer to "Global unicast addresses" as defined in
[RFC4291] and "Unique local addresses" as defined in [RFC4193], and [RFC4291] and "Unique local addresses" as defined in [RFC4193], and
not to "globally reachable" as defined in [RFC8190]. not to "globally reachable" addresses, as defined in [RFC8190].
1.2. Problem Statement 1.2. Problem Statement
Addresses generated using stateless address autoconfiguration Addresses generated using stateless address autoconfiguration
[RFC4862] contain an embedded interface identifier, which may remain [RFC4862] contain an embedded interface identifier, which may remain
stable over time. Anytime a fixed identifier is used in multiple stable over time. Anytime a fixed identifier is used in multiple
contexts, it becomes possible to correlate seemingly unrelated contexts, it becomes possible to correlate seemingly unrelated
activity using this identifier. activity using this identifier.
The correlation can be performed by The correlation can be performed by
skipping to change at page 5, line 27 skipping to change at page 5, line 27
collecting information. If the network contains a very small number collecting information. If the network contains a very small number
of nodes, say, just one, changing just the interface identifier will of nodes, say, just one, changing just the interface identifier will
not enhance privacy, since the prefix serves as a constant not enhance privacy, since the prefix serves as a constant
identifier. identifier.
One of the requirements for correlating seemingly unrelated One of the requirements for correlating seemingly unrelated
activities is the use (and reuse) of an identifier that is activities is the use (and reuse) of an identifier that is
recognizable over time within different contexts. IP addresses recognizable over time within different contexts. IP addresses
provide one obvious example, but there are more. provide one obvious example, but there are more.
For example, web browsers and servers typically exchange "cookies" Many nodes also have DNS names associated with their addresses, in
with each other [RFC6265]. Cookies allow web servers to correlate a which case the DNS name serves as a similar identifier. Although the
current activity with a previous activity. One common usage is to DNS name associated with an address is more work to obtain (it may
send back targeted advertising to a user by using the cookie supplied require a DNS query), the information is often readily available. In
by the browser to identify what earlier queries had been made (e.g., such cases, changing the address on a machine over time would do
for what type of information). Based on the earlier queries, little to address the concerns raised in this document, unless the
advertisements can be targeted to match the (assumed) interests of DNS name is changed as well (see Section 4).
the end-user.
Web browsers and servers typically exchange "cookies" with each other
[RFC6265]. Cookies allow web servers to correlate a current activity
with a previous activity. One common usage is to send back targeted
advertising to a user by using the cookie supplied by the browser to
identify what earlier queries had been made (e.g., for what type of
information). Based on the earlier queries, advertisements can be
targeted to match the (assumed) interests of the end-user.
The use of a constant identifier within an address is of special The use of a constant identifier within an address is of special
concern because addresses are a fundamental requirement of concern because addresses are a fundamental requirement of
communication and cannot easily be hidden from eavesdroppers and communication and cannot easily be hidden from eavesdroppers and
other parties. Even when higher layers encrypt their payloads, other parties. Even when higher layers encrypt their payloads,
addresses in packet headers appear in the clear. Consequently, if a addresses in packet headers appear in the clear. Consequently, if a
mobile host (e.g., laptop) accessed the network from several mobile host (e.g., laptop) accessed the network from several
different locations, an eavesdropper might be able to track the different locations, an eavesdropper might be able to track the
movement of that mobile host from place to place, even if the upper movement of that mobile host from place to place, even if the upper
layer payloads were encrypted. layer payloads were encrypted.
skipping to change at page 8, line 31 skipping to change at page 8, line 40
One approach is to select a pseudorandom number of the appropriate One approach is to select a pseudorandom number of the appropriate
length. A node employing this algorithm should generate IIDs as length. A node employing this algorithm should generate IIDs as
follows: follows:
1. Obtain a random number (see [RFC4086] for randomness requirements 1. Obtain a random number (see [RFC4086] for randomness requirements
for security). for security).
2. The Interface Identifier is obtained by taking as many bits from 2. The Interface Identifier is obtained by taking as many bits from
the random number obtained in the previous step as necessary. the random number obtained in the previous step as necessary.
Note: there are no special bits in an Interface Identifier See [RFC7136] for the necessary number of bits, that is, the
[RFC7136]. length of the IID. See also [RFC7421] for a discussion of the
privacy implications of the IID length. Note: there are no
We note that [RFC4291] requires that the Interface IDs of all special bits in an Interface Identifier [RFC7136].
unicast addresses (except those that start with the binary
value 000) be 64 bits long. However, the method discussed in
this document could be employed for generating Interface IDs
of any arbitrary length, albeit at the expense of reduced
entropy (when employing Interface IDs smaller than 64 bits)
and increased likelihood of collision. The privacy
implications of the IID length are discussed in [RFC7421].
3. The resulting Interface Identifier MUST be compared against the 3. The resulting Interface Identifier MUST be compared against the
reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID] reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]
and against those Interface Identifiers already employed in an and against those Interface Identifiers already employed in an
address of the same network interface and the same network address of the same network interface and the same network
prefix. In the event that an unacceptable identifier has been prefix. In the event that an unacceptable identifier has been
generated, a new interface identifier should be generated, by generated, a new interface identifier should be generated, by
repeating the algorithm from the first step. repeating the algorithm from the first step.
3.3.2. Hash-based Generation of Randomized Interface Identifiers 3.3.2. Hash-based Generation of Randomized Interface Identifiers
skipping to change at page 10, line 31 skipping to change at page 10, line 31
secret_key: secret_key:
A secret key that is not known by the attacker. The secret A secret key that is not known by the attacker. The secret
key SHOULD be of at least 128 bits. It MUST be initialized to key SHOULD be of at least 128 bits. It MUST be initialized to
a pseudo-random number (see [RFC4086] for randomness a pseudo-random number (see [RFC4086] for randomness
requirements for security) when the operating system is requirements for security) when the operating system is
"bootstrapped". "bootstrapped".
2. The Interface Identifier is finally obtained by taking as many 2. The Interface Identifier is finally obtained by taking as many
bits from the RID value (computed in the previous step) as bits from the RID value (computed in the previous step) as
necessary, starting from the least significant bit. The necessary, starting from the least significant bit. See
resulting Interface Identifier MUST be compared against the [RFC7136] for the necessary number of bits, that is, the length
of the IID. See also [RFC7421] for a discussion of the privacy
implications of the IID length. Note: there are no special bits
in an Interface Identifier [RFC7136].
3. The resulting Interface Identifier MUST be compared against the
reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID] reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]
and against those Interface Identifiers already employed in an and against those Interface Identifiers already employed in an
address of the same network interface and the same network address of the same network interface and the same network
prefix. In the event that an unacceptable identifier has been prefix. In the event that an unacceptable identifier has been
generated, the value DAD_Counter should be incremented by 1, and generated, the value DAD_Counter should be incremented by 1, and
the algorithm should be restarted from the first step. the algorithm should be restarted from the first step.
3.4. Generating Temporary Addresses 3.4. Generating Temporary Addresses
[RFC4862] describes the steps for generating a link-local address [RFC4862] describes the steps for generating a link-local address
when an interface becomes enabled as well as the steps for generating when an interface becomes enabled as well as the steps for generating
addresses for other scopes. This document extends [RFC4862] as addresses for other scopes. This document extends [RFC4862] as
follows. When processing a Router Advertisement with a Prefix follows. When processing a Router Advertisement with a Prefix
Information option carrying a prefix for the purposes of address Information option carrying a prefix for the purposes of address
autoconfiguration (i.e., the A bit is set), the node MUST perform the autoconfiguration (i.e., the A bit is set), the node MUST perform the
following steps: following steps:
1. Process the Prefix Information Option as defined in [RFC4862], 1. Process the Prefix Information Option as defined in [RFC4862],
adjusting the lifetimes of existing temporary addresses. If a adjusting the lifetimes of existing temporary addresses, with the
received option may extend the lifetimes of temporary addresses, overall constraint that no temporary addresses should ever remain
with the overall constraint that no temporary addresses should "valid" or "preferred" for a time longer than
ever remain "valid" or "preferred" for a time longer than
(TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME - (TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME -
DESYNC_FACTOR) respectively. The configuration variables DESYNC_FACTOR) respectively. The configuration variables
TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to
approximate target lifetimes for temporary addresses. approximate target lifetimes for temporary addresses.
2. One way an implementation can satisfy the above constraints is to 2. One way an implementation can satisfy the above constraints is to
associate with each temporary address a creation time (called associate with each temporary address a creation time (called
CREATION_TIME) that indicates the time at which the address was CREATION_TIME) that indicates the time at which the address was
created. When updating the preferred lifetime of an existing created. When updating the preferred lifetime of an existing
temporary address, it would be set to expire at whichever time is temporary address, it would be set to expire at whichever time is
skipping to change at page 14, line 42 skipping to change at page 14, line 42
include: include:
TEMP_VALID_LIFETIME -- Default value: 2 days. Users should be able TEMP_VALID_LIFETIME -- Default value: 2 days. Users should be able
to override the default value. to override the default value.
TEMP_PREFERRED_LIFETIME -- Default value: 1 day. Users should be TEMP_PREFERRED_LIFETIME -- Default value: 1 day. Users should be
able to override the default value. able to override the default value.
Note: Note:
The TEMP_PREFERRED_LIFETIME value MUST be less than the The TEMP_PREFERRED_LIFETIME value MUST be less than the
TEMP_VALID_LIFETIME value. TEMP_VALID_LIFETIME value, to avoid the pathological case where an
address is employed for new communications, but becomes invalid in
less than 1 second, disrupting those communications
REGEN_ADVANCE -- 5 seconds REGEN_ADVANCE -- 2 + (TEMP_IDGEN_RETRIES * DupAddrDetectTransmits *
RetransTimer / 1000)
Note:
This parameter is specified as a function of other protocol
parameters, to account for the time possibly spent in Duplicate
Address Detection (DAD) in the worst-case scenario of
TEMP_IDGEN_RETRIES. This prevents the pathological case where the
generation of a new temporary address is not started with enough
anticipation such that a new preferred address is generated before
the currently-preferred temporary address becomes deprecated.
DupAddrDetectTransmits and RetransTimer are specified in
[RFC4861].
MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR. MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR.
DESYNC_FACTOR -- A random value within the range 0 - DESYNC_FACTOR -- A random value within the range 0 -
MAX_DESYNC_FACTOR. It is computed once at system start (rather than MAX_DESYNC_FACTOR. It is computed once at system start (rather than
each time it is used) and must never be greater than each time it is used) and must never be greater than
(TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE). (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE).
TEMP_IDGEN_RETRIES -- Default value: 3 TEMP_IDGEN_RETRIES -- Default value: 3
skipping to change at page 17, line 34 skipping to change at page 18, line 5
o slaacd(8): slaacd(8) has traditionally used different randomized o slaacd(8): slaacd(8) has traditionally used different randomized
interface identifiers for each prefix, and it has recently reduced interface identifiers for each prefix, and it has recently reduced
the Valid Lifetime of temporary addresses as specified in the Valid Lifetime of temporary addresses as specified in
Section 3.8, thus fully implementing this document. The Section 3.8, thus fully implementing this document. The
implementation has been done by Florian Obser implementation has been done by Florian Obser
<florian@openbsd.org>, with the update to the temporary address <florian@openbsd.org>, with the update to the temporary address
Valid Lifetime applied in March 2020. The implementation can be Valid Lifetime applied in March 2020. The implementation can be
found at: <https://github.com/openbsd/src/tree/master/sbin/slaacd> found at: <https://github.com/openbsd/src/tree/master/sbin/slaacd>
8. Security Considerations 8. IANA Considerations
There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an
RFC.
9. 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 18, line 16 skipping to change at page 18, line 40
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.
9. Acknowledgments 10. 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 40 skipping to change at page 19, line 17
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.
10. References 11. References
10.1. Normative References 11.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>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[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 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc4941>.
skipping to change at page 20, line 5 skipping to change at page 20, line 33
[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>.
10.2. Informative References 11.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
skipping to change at page 22, line 13 skipping to change at page 22, line 39
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204, "Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016, RFC 7934, DOI 10.17487/RFC7934, July 2016,
<https://www.rfc-editor.org/info/rfc7934>. <https://www.rfc-editor.org/info/rfc7934>.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
SI6 Networks / UTN-FRH SI6 Networks
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: https://www.si6networks.com URI: https://www.si6networks.com
Suresh Krishnan Suresh Krishnan
Kaloom Kaloom
skipping to change at page 22, line 26 skipping to change at page 23, line 4
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: https://www.si6networks.com URI: https://www.si6networks.com
Suresh Krishnan Suresh Krishnan
Kaloom Kaloom
Email: suresh@kaloom.com Email: suresh@kaloom.com
Thomas Narten Thomas Narten
IBM Corporation
P.O. Box 12195
Research Triangle Park, NC
USA
Email: narten@us.ibm.com Email: narten@cs.duke.edu
Richard Draves Richard Draves
Microsoft Research Microsoft Research
One Microsoft Way One Microsoft Way
Redmond, WA Redmond, WA
USA USA
Email: richdr@microsoft.com Email: richdr@microsoft.com
 End of changes. 27 change blocks. 
64 lines changed or deleted 91 lines changed or added

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