rfc8981xml2.original.xml		rfc8981.xml
			<?xml version="1.0" encoding="UTF-8"?>
			<!-- updated by Chris 12/18/20 -->
			<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" obsoletes="4941" ipr="trust20090
			2"
			docName="draft-ietf-6man-rfc4941bis-12" number="8981" updates="" submissionType=
			"IETF"
			category="std" consensus="true" xml:lang="en" tocInclude="true" symRefs="true"
			sortRefs="true" version="3">
			<!-- xml2rfc v2v3 conversion 3.5.0 -->
			<front>
			<title abbrev="Temporary Address Extensions to Autoconf">Temporary Address E
			xtensions for Stateless Address Autoconfiguration in
			IPv6</title>
			<seriesInfo name="RFC" value="8981"/>
			<author fullname="Fernando Gont" initials="F." surname="Gont">
			<organization abbrev="SI6 Networks">SI6 Networks</organization>
			<address>
			<postal>
			<street>Segurola y Habana 4310, 7mo Piso</street>
			<city>Villa Devoto</city>
			<region>Ciudad Autonoma de Buenos Aires</region>
			<country>Argentina</country>
			</postal>
			<email>fgont@si6networks.com</email>
			<uri>https://www.si6networks.com</uri>
			</address>
			</author>
			<author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
			<organization>Kaloom</organization>
			<address>
			<postal>
			<street/>
			<city/>
			<region/>
			<code/>
			<country/>
			</postal>
			<email>suresh@kaloom.com</email>
			</address>
			</author>
			<author initials="T." surname="Narten" fullname="Thomas Narten">
			<address>
			<email>narten@cs.duke.edu</email>
			</address>
			</author>
			<author initials="R." surname="Draves" fullname="Richard Draves">
			<organization>Microsoft Research</organization>
			<address>
			<postal>
			<street>One Microsoft Way</street>
			<city>Redmond</city>
			<region>WA</region>
			<country>United States of America</country>
			</postal>
			<email>richdr@microsoft.com</email>
			</address>
			</author>
			<date year="2021" month="February" />
			<area>Internet</area>
			<workgroup>IPv6 Maintenance (6man) Working Group</workgroup>
			<keyword>privacy</keyword>
			<keyword>anonymity</keyword>
			<keyword>unlinkability</keyword>
			<keyword>crypto-based address changing</keyword>
			<abstract>
			<t>This document describes an extension to IPv6 Stateless Address Autoconf
			iguration that causes
			hosts to generate temporary addresses with randomized interface identifier
			s for each prefix advertised with autoconfiguration enabled. Changing addresses
			over time limits the window of time during which eavesdroppers and other informa
			tion collectors may trivially perform address-based network-activity correlation
			when the same address is employed for multiple
			transactions by the same host. Additionally, it reduces the window of expo
			sure of a host as being
			accessible via an address that becomes revealed as a result of active communicat
			ion. This document obsoletes RFC 4941.</t>
			</abstract>
			</front>
			<middle>
			<section anchor="intro" numbered="true" toc="default">
			<name>Introduction</name>
			<t><xref target="RFC4862" format="default"/> specifies Stateless Address A
			utoconfiguration (SLAAC) for
			IPv6, which typically results in hosts configuring one or
			more "stable" IPv6 addresses composed of a network prefix advertised by a
			local router and a locally generated interface identifier (IID). The secur
			ity and privacy implications of such addresses have been discussed in detail in
			<xref target="RFC7721" format="default"/>, <xref target="RFC7217" format="defaul
			t"/>, and <xref target="RFC7707" format="default"/>. This document specifies an
			extension to SLAAC for generating temporary addresses that can help mitigate som
			e of the aforementioned issues. This document is a revision of RFC 4941 and form
			ally obsoletes it. <xref target="changes" format="default"/> describes the chang
			es from <xref target="RFC4941" format="default"/>.</t>
			<t>The default address selection for IPv6 has been specified in <xref targ
			et="RFC6724" format="default"/>. In some cases, the determination as to whether
			to use stable versus temporary addresses can only be made by an application. For
			example, some applications may always want
			to use temporary addresses, while others may want to use them
			only in some circumstances or not at all. An Application Programming Inter
			face (API) such as that specified in <xref target="RFC5014" format="default"/> c
			an enable
			individual applications to indicate a preference for the use of temporary
			addresses.
			</t>
			<t>
			<xref target="SECTION2" format="default"/> provides background information
			. <xref target="SECTION3" format="default"/> describes a procedure for
			generating temporary addresses.
			<xref target="SECTION4" format="default"/> discusses implications of chang
			ing
			IIDs. <xref target="changes" format="default"/> describes the changes from
			<xref target="RFC4941" format="default"/>.
			</t>
			<section anchor="term" numbered="true" toc="default">
			<name>Terminology</name>
			<t>
			The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
			IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
			NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
			RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be interpreted as
			described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
			</t>
			<t>The terms "public address", "stable address", "temporary address", "c
			onstant IID", "stable IID", and "temporary IID" are to be
			interpreted as specified in <xref target="RFC7721" format="default"/>.</t
			>
			<t>The term "global-scope addresses" is
			used in this document to collectively refer to "Global
			unicast addresses" as defined in
			<xref target="RFC4291" format="default"/> and "Unique local addresses" as
			defined in
			<xref target="RFC4193" format="default"/>, and not to "globally reachable
			addresses" as defined in <xref target="RFC8190" format="default"/>.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Problem Statement</name>
			<t>Addresses generated using SLAAC
			<xref target="RFC4862" format="default"/> contain an embedded interface
			identifier, which may remain stable over time. Anytime a
			fixed identifier is used in multiple contexts, it becomes
			possible to correlate seemingly unrelated activity using
			this identifier.</t>
			<t>The correlation can be performed by:
			</t>
			<ul spacing="normal">
			<li>An attacker who is in the path between the host in question and
			the peer(s) to which it is communicating, who can view the
			IPv6 addresses present in the datagrams.</li>
			<li>An attacker who can access the communication logs of
			the peers with which the host has communicated.</li>
			</ul>
			<t>Since the identifier is embedded within the IPv6
			address, it cannot be hidden. This document
			proposes a solution to this issue by generating interface
			identifiers that vary over time.</t>
			<t>Note that an attacker, who is on path, may be able to
			perform significant correlation based on:
			</t>
			<ul spacing="normal">
			<li>The payload contents of unencrypted packets on the wire.</li>
			<li>The characteristics of the packets, such as packet size
			and timing.</li>
			</ul>
			<t>Use of temporary addresses will not prevent such correlation, nor wil
			l it prevent an on-link observer (e.g., the host's default router) from tracking
			all the host's addresses.</t>
			</section>
			</section>
			<section anchor="SECTION2" numbered="true" toc="default">
			<name>Background</name>
			<t>This section discusses the problem in more detail,
			provides context for evaluating the significance of the
			concerns in specific environments, and makes comparisons with
			existing practices.</t>
			<section numbered="true" toc="default">
			<name>Extended Use of the Same Identifier</name>
			<t>The use of a non-changing IID to form
			addresses is a specific instance of the more general case
			where a constant identifier is reused over an extended
			period of time and in multiple independent activities.
			Anytime the same identifier is used in multiple contexts,
			it becomes possible for that identifier to be used to
			correlate seemingly unrelated activity. For example, a
			network sniffer placed strategically on a link traversed by
			all traffic to/from a particular host could keep
			track of which destinations a host communicated with and at
			what times. In some cases, such information can be used to
			infer things, such as what hours an employee was active,
			when someone is at home, etc. Although it might appear that
			changing an address regularly in such environments would be
			desirable to lessen privacy concerns, it should be noted
			that the network-prefix portion of an address also serves
			as a constant identifier. All hosts at, say, a home would
			have the same network prefix, which identifies the
			topological location of those hosts. This has implications
			for privacy, though not at the same granularity as the
			concern that this document addresses. Specifically, all
			hosts within a home could be grouped together for the
			purposes of collecting information. If the network contains
			a very small number of hosts -- say, just one -- changing just
			the IID will not enhance privacy,
			since the prefix serves as a constant identifier.</t>
			<t>One of the requirements for correlating seemingly
			unrelated activities is the use (and reuse) of an
			identifier that is recognizable over time within different
			contexts. IP addresses provide one obvious example, but
			there are more. For example:
			</t>
			<ul spacing="normal">
			<li>Many hosts also have DNS names associated
			with their addresses, in which case, the DNS name serves as
			a similar identifier. Although the DNS name associated with
			an address is more work to obtain (it may require a DNS
			query), the information is often readily available. In such
			cases, changing the address on a host over time would do
			little to address the concerns raised in this document,
			unless the DNS name is also changed at the same time (see
			<xref target="SECTION4" format="default"/>).</li>
			<li>Web browsers and servers typically exchange "cookies"
			with each other
			<xref target="RFC6265" format="default"/>. 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.</li>
			</ul>
			<t>The use of a constant identifier within an address is of
			special concern, because addresses are a fundamental
			requirement of communication and cannot easily be hidden
			from eavesdroppers and other parties. Even when higher
			layers encrypt their payloads, addresses in packet headers
			appear in the clear. Consequently, if a mobile host (e.g.,
			laptop) accessed the network from several different
			locations, an eavesdropper might be able to track the
			movement of that mobile host from place to place, even if
			the upper-layer payloads were encrypted.</t>
			<t>Changing addresses over time limits the time window over which eavesd
			roppers and other information collectors may trivially correlate network activit
			y when the same address is employed for multiple transactions by the same host.
			Additionally, it reduces the window of exposure during which a host is accessibl
			e via an address that becomes revealed as a result of active communication.</t>
			<t>The security and privacy implications of IPv6 addresses are discussed
			in
			detail in <xref target="RFC7721" format="default"/>, <xref target="RF
			C7707" format="default"/>, and <xref target="RFC7217" format="default"/>.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Possible Approaches</name>
			<t>One approach, compatible with the SLAAC architecture, would be to cha
			nge the
			IID portion of an address over time. Changing
			the IID can
			make it more difficult to look at the IP addresses in
			independent transactions and identify which ones actually
			correspond to the same host, both in the case where the
			routing-prefix portion of an address changes and when it
			does not.</t>
			<t>Many hosts function as both clients and servers. In
			such cases, the host would need a name (e.g., a DNS domain name) for its
			use
			as a server. Whether the address stays fixed or changes has
			little impact on privacy, since the name remains
			constant and serves as a constant identifier. However, when acting
			as a client (e.g., initiating communication), such
			a host may want to vary the addresses it uses. In such
			environments, one may need multiple addresses: a stable
			address associated with the name, which is used to accept
			incoming connection requests from
			other hosts, and a temporary address used to shield
			the identity of the client when it initiates communication.
			</t>
			<t>On the other hand, a host that functions only as a
			client may want to employ only temporary addresses for
			public communication.</t>
			<t>To make it difficult to make educated guesses as to
			whether two different IIDs belong to the
			same host, the algorithm for generating alternate
			identifiers must include input that has an unpredictable
			component from the perspective of the outside entities that
			are collecting information.</t>
			</section>
			</section>
			<section anchor="SECTION3" numbered="true" toc="default">
			<name>Protocol Description</name>
			<t>The following subsections define the procedures for the generation of I
			Pv6 temporary addresses.</t>
			<section anchor="design" numbered="true" toc="default">
			<name>Design Guidelines</name>
			<t>Temporary addresses observe the following properties:</t>
			<ol spacing="normal" type="1"><li>Temporary addresses are typically empl
			oyed for initiating
			outgoing sessions.</li>
			<li>Temporary addresses are used for a short period of time (typically
			hours to days)
			and are subsequently deprecated. Deprecated addresses can
			continue to be used for established connections
			but are not used to initiate new connections.</li>
			<li>New
			temporary addresses are generated over time to replace
			temporary addresses that expire (i.e., become deprecated and
			eventually invalidated).</li>
			<li>Temporary addresses must have a limited lifetime (limited "valid l
			ifetime" and "preferred lifetime" from <xref target="RFC4862" format="default"/>
			). The lifetime of an address should be further reduced when privacy-meaningful
			events (such as a host attaching to a different network, or the regeneration of
			a new randomized Media Access Control (MAC) address) take place. The lifetime of
			temporary addresses must be statistically different for different addresses, su
			ch that it is hard to predict or infer when a new temporary address is generated
			or correlate a newly generated address with an existing one.</li>
			<li>
			By default, one address is generated for each prefix advertised
			by SLAAC. The resulting interface
			identifiers must be statistically different when addresses are
			configured for different prefixes or different network
			interfaces. This means that, given two addresses, it must be difficult fo
			r an outside entity to
			infer whether the addresses correspond to the same
			host or network interface.
			</li>
			<li>It must be difficult for an outside entity to predict the interfac
			e
			identifiers that will be employed for temporary addresses, even with knowledg
			e
			of the algorithm/method employed to generate them and/or knowledge of the IID
			s previously employed for other temporary addresses. These IIDs must be semantic
			ally opaque <xref target="RFC7136" format="default"/> and must not follow any sp
			ecific patterns.</li>
			</ol>
			</section>
			<section numbered="true" toc="default">
			<name>Assumptions</name>
			<t>The following algorithm assumes that, for a given temporary
			address, an implementation can determine the prefix from
			which it was generated. When a temporary address is
			deprecated, a new temporary address is generated. The
			specific valid and preferred lifetimes for the new address
			are dependent on the corresponding lifetime values set for
			the prefix from which it was generated.</t>
			<t>Finally, this document assumes that, when a host
			initiates outgoing communications, temporary addresses can
			be given preference over stable addresses (if available), when the devic
			e
			is configured to do so.
			<xref target="RFC6724" format="default"/> mandates that implementations
			provide a mechanism that allows an application to
			configure its preference for temporary addresses over
			stable addresses. It also allows an implementation to
			prefer temporary addresses by default, so that the
			connections initiated by the host can use temporary
			addresses without requiring application-specific
			enablement. This document also assumes that an API will
			exist that allows individual applications to indicate
			whether they prefer to use temporary or stable addresses
			and override the system defaults (see, for example, <xref target="RFC501
			4" format="default"/>).
			</t>
			</section>
			<section anchor="SECTION3_2" numbered="true" toc="default">
			<name>Generation of Randomized IIDs</name>
			<t>The following subsections specify example algorithms for generating t
			emporary IIDs that follow the guidelines in <xref target="design" format="defaul
			t"/> of this document. The algorithm specified in <xref target="randomized-IIDs"
			format="default"/> assumes a pseudorandom number generator (PRNG) is available
			on the system. The algorithm specified in <xref target="RFC-7217" format="defaul
			t"/> allows for code reuse by hosts that implement <xref target="RFC7217" format
			="default"/>.
			</t>
			<section anchor="randomized-IIDs" numbered="true" toc="default">
			<name>Simple Randomized IIDs</name>
			<t>One approach is to select a pseudorandom number of the appropriate
			length. A host employing this algorithm should generate IIDs as follows:
			</t>
			<ol spacing="normal" type="1">
			<li>Obtain a random number from a PRNG that can produce random numbers of at l
			east as many bits as
			required for the IID (please see the next step).
			<xref target="RFC4086" format="default"/> specifies randomness requirements for
			security.</li>
			<li>The IID is obtained by taking as many bits from the random number obtained i
			n the previous step as necessary. See <xref target="RFC7136" format="default"/>
			for the necessary number of bits (i.e., the length of the IID). See also <xref
			target="RFC7421" format="default"/> for a discussion of the privacy implications
			of the IID length. Note: there are no special bits in an IID <xref target="RFC7
			136" format="default"/>.
			</li>
			<li>
			The resulting IID <bcp14>MUST</bcp14> be compared against the reserved IPv6 IIDs
			<xref target="RFC5453" format="default"/> <xref target="IANA-RESERVED-IID" form
			at="default"/> and against those IIDs already employed in an address of the same
			network interface and the same network prefix. In the event that an unacceptabl
			e identifier has been generated, a new IID should be generated by repeating the
			algorithm from the first step.
			</li>
			</ol>
			</section>
			<section anchor="RFC-7217" numbered="true" toc="default">
			<name>Generation of IIDs with Pseudorandom Functions</name>
			<t>The algorithm in <xref target="RFC7217" format="default"/> can be a
			ugmented for the generation of temporary addresses. The benefit of this is that
			a host could employ a single algorithm for generating stable and temporary addre
			sses by employing appropriate parameters.</t>
			<t>Hosts would employ the following algorithm for generating the tempo
			rary IID:
			</t>
			<ol spacing="normal" type="1"><li>
			<t>
			Compute a random identifier with the expression:
			</t>
			<t>
			RID = F(Prefix, Net_Iface, Network_ID, Time, DAD_Counter,
			secret_key)
			</t>
			<t>
			Where:
			</t>
			<dl newline="true" spacing="normal">
			<dt>RID:</dt>
			<dd>Random Identifier</dd>
			<dt>F():</dt>
			<dd>A pseudorandom function (PRF) that <bcp14>MUST NOT</bcp14> be computable
			from the outside (without knowledge of the secret key). F() <bcp14>MUST</bcp14>
			also be difficult to reverse, such that it resists attempts to obtain the secre
			t_key, even when given samples of the output of F() and knowledge
			or control of the other input parameters. F() <bcp14>SHOULD</bcp14> produce an o
			utput of at least as many bits as required for the IID.
			BLAKE3 (256-bit key, arbitrary-length output) <xref target="BLAKE3" format="defa
			ult"/> is one possible option for F(). Alternatively, F() could be implemented w
			ith a keyed-hash message authentication code (HMAC) <xref target="RFC2104" forma
			t="default"/>. HMAC-SHA-256 <xref target="FIPS-SHS" format="default"/> is one po
			ssible option for such an implementation alternative. Note: use of HMAC-MD5 <xre
			f target="RFC1321" format="default"/> is considered unacceptable for F() <xref t
			arget="RFC6151" format="default"/>.</dd>
			<dt>Prefix:</dt>
			<dd>The prefix to be used for SLAAC, as learned from an ICMPv6 Router Advertisem
			ent message.</dd>
			<dt>Net_Iface:</dt>
			<dd>The MAC address corresponding to the underlying network-interface card, in t
			he case the link uses IEEE 802 link-layer identifiers. Employing the MAC address
			for this parameter (over the other suggested options in <xref target="RFC7217"
			format="default"/>) means that the regeneration of a randomized MAC address will
			result in a different temporary address.</dd>
			<dt>Network_ID:</dt>
			<dd>Some network-specific data that identifies
			the subnet to which this interface is attached -- for example, the IEEE 802.11 S
			ervice Set Identifier (SSID) corresponding to the network to which this interfac
			e is associated. Additionally, "Simple Procedures for Detecting Network Attachme
			nt in IPv6" ("Simple DNA") <xref target="RFC6059" format="default"/> describes i
			deas that could be leveraged to generate a Network_ID parameter. This parameter
			<bcp14>SHOULD</bcp14> be employed if some form of "Network_ID" is available.</dd
			>
			<dt>Time:</dt>
			<dd>An implementation-dependent representation of time. One possible example is
			the representation in UNIX-like systems <xref target="OPEN-GROUP" format="defaul
			t"/>, which measure time in terms of the number of seconds elapsed since the Epo
			ch (00:00:00 Coordinated Universal Time (UTC), 1 January 1970). The addition of
			the "Time" argument results in (statistically) different IIDs over time.</dd>
			<dt>DAD_Counter:</dt>
			<dd>A counter that is employed to resolve the conflict where an unacceptable ide
			ntifier has been generated. This can be result of Duplicate Address Detection (D
			AD), or step 3 below.
			</dd>
			<dt>secret_key:</dt>
			<dd>A secret key that is not known by the attacker. The secret key <bcp14>SHOULD
			</bcp14> be of at least 128 bits. It <bcp14>MUST</bcp14> be initialized to a pse
			udorandom number (see <xref target="RFC4086" format="default"/> for randomness r
			equirements for security) when the operating system is "bootstrapped". The secre
			t_key <bcp14>MUST NOT</bcp14> be employed for any other purpose than the one dis
			cussed in this section. For example, implementations <bcp14>MUST NOT</bcp14> emp
			loy the same secret_key for the generation of stable addresses <xref target="RFC
			7217" format="default"/> and the generation of temporary addresses via this algo
			rithm.</dd>
			</dl>
			</li>
			<li>The IID is finally obtained by taking as many bits from the RID value (compu
			ted in the previous step) as necessary, starting from the least significant bit.
			See <xref target="RFC7136" format="default"/> for the necessary number of bits
			(i.e., the length of the IID). See also <xref target="RFC7421" format="default
			"/> for a discussion of the privacy implications of the IID length. Note: there
			are no special bits in an IID <xref target="RFC7136" format="default"/>.
			</li>
			<li>
			The resulting IID <bcp14>MUST</bcp14> be compared against the reserved IPv6 IIDs
			<xref target="RFC5453" format="default"/> <xref target="IANA-RESERVED-IID" form
			at="default"/> and against those IIDs already employed in an address of the same
			network interface and the same network prefix. In the event that an unacceptabl
			e identifier has been generated, the DAD_Counter should be incremented by 1, and
			the algorithm should be restarted from the first step.
			</li>
			</ol>
			</section>
			</section>
			<section anchor="SECTION3_3" numbered="true" toc="default">
			<name>Generating Temporary Addresses</name>
			<t>
			<xref target="RFC4862" format="default"/> describes the steps for
			generating a link-local address when an interface becomes
			enabled, as well as the steps for generating addresses for
			other scopes. This document extends
			<xref target="RFC4862" format="default"/> as follows. When processing a
			Router Advertisement with a Prefix Information option
			carrying a prefix for the purposes of address
			autoconfiguration (i.e., the A bit is set), the host <bcp14>MUST</bcp14>
			perform the following steps:</t>
			<t>
			</t>
			<ol spacing="normal" type="1">
			<li><t>Process the Prefix Information option as specified in <xref targe
			t="RFC4862" format="default"/>, adjusting the lifetimes of existing
			temporary addresses, with the overall constraint that no
			temporary addresses should ever remain "valid" or
			"preferred" for a time longer than (TEMP_VALID_LIFETIME)
			or (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR), respectively. The confi
			guration variables
			TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to the
			maximum valid lifetime and the maximum preferred lifetime of temporary a
			ddresses, respectively.
			</t>
			<dl newline="true" spacing="normal">
			<dt>Note:</dt>
			<dd>DESYNC_FACTOR is the value computed when the address was creat
			ed (see step 4 below).</dd>
			</dl>
			</li>
			<li><t>One way an implementation can satisfy the above
			constraints is to associate with each temporary address
			a creation time (called CREATION_TIME) that indicates
			the time at which the address was created. When
			updating the preferred lifetime of an existing
			temporary address, it would be set to expire at
			whichever time is earlier: the time indicated by the
			received lifetime or (CREATION_TIME +
			TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR). A similar
			approach can be used with the valid lifetime.
			</t>
			<dl newline="true" spacing="normal">
			<dt>Note:</dt>
			<dd>DESYNC_FACTOR is the value computed when the address was creat
			ed (see step 4 below).</dd>
			</dl>
			</li>
			<li>
			<t>If the host has not configured any temporary address for the corr
			esponding prefix, the host <bcp14>SHOULD</bcp14> create
			a new temporary address for such prefix.
			</t>
			<dl newline="true" spacing="normal">
			<dt>Note:</dt>
			<dd>For example, a host might implement prefix-specific policies s
			uch as
			not configuring temporary addresses for the Unique Local IPv6 Unicast
			Addresses (ULAs) <xref target="RFC4193" format="default"/> prefix.</dd>
			</dl>
			</li>
			<li>
			<t>When creating a temporary address, DESYNC_FACTOR <bcp14>MUST</bcp
			14> be
			computed and associated with the newly created address, and the address
			lifetime
			values <bcp14>MUST</bcp14> be derived from the corresponding prefix
			as
			follows:
			</t>
			<ul spacing="normal">
			<li>Its valid lifetime is the lower of the Valid
			Lifetime of the prefix and TEMP_VALID_LIFETIME.</li>
			<li>Its preferred lifetime is the lower of the
			Preferred Lifetime of the prefix and
			TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR.</li>
			</ul>
			</li>
			<li>A temporary address is created only if this
			calculated preferred lifetime is greater than
			REGEN_ADVANCE time units. In particular, an
			implementation <bcp14>MUST NOT</bcp14> create a temporary address wi
			th
			a zero preferred lifetime.</li>
			<li>New temporary addresses <bcp14>MUST</bcp14> be created by appendin
			g
			a randomized IID to the prefix that was received. <xref target="SECT
			ION3_2" format="default"/> of this document specifies some sample algorithms for
			generating the randomized IID.</li>
			<li>The host <bcp14>MUST</bcp14> perform DAD
			on the generated temporary address. If DAD
			indicates the address is already in use, the host <bcp14>MUST</bcp14
			>
			generate a new randomized IID and repeat the
			previous steps as appropriate (starting from step 4), up to TEMP_IDG
			EN_RETRIES
			times. If, after TEMP_IDGEN_RETRIES consecutive attempts,
			the host is unable to generate a unique temporary address, the host
			<bcp14>MUST</bcp14> log
			a system error and <bcp14>SHOULD NOT</bcp14> attempt to generate a t
			emporary address for the given prefix for the duration of the host's attachment
			to the network via this interface. This allows hosts to recover from occasional
			DAD failures or otherwise log the recurrent address collisions.</li>
			</ol>
			</section>
			<section anchor="SECTION3_4" numbered="true" toc="default">
			<name>Expiration of Temporary Addresses</name>
			<t>When a temporary address becomes deprecated, a new one
			<bcp14>MUST</bcp14> be generated. This is done by repeating the actions
			described in
			<xref target="SECTION3_3" format="default"/>, starting at step 4). Note
			that, in normal operation, except for the transient period when a tempor
			ary
			address is being regenerated, at most
			one temporary address per prefix should be in a
			nondeprecated state at any given time on a given
			interface. Note that if a temporary address becomes
			deprecated as result of processing a Prefix Information
			option with a zero preferred lifetime, then a new temporary
			address <bcp14>MUST NOT</bcp14> be generated (in response to the same Pr
			efix Information
			option). To ensure that a preferred
			temporary address is always available, a new temporary
			address <bcp14>SHOULD</bcp14> be regenerated slightly before its
			predecessor is deprecated. This is to allow sufficient time
			to avoid race conditions in the case where generating a new
			temporary address is not instantaneous, such as when
			DAD must be performed. The host <bcp14>SHOULD</bcp14>
			start the process of address regeneration REGEN_ADVANCE time
			units before a temporary address is
			deprecated.</t>
			<t>As an optional optimization, an implementation <bcp14>MAY</bcp14>
			remove a deprecated temporary address that is not in use by
			applications or upper layers, as detailed in
			<xref target="SECTION6" format="default"/>.</t>
			</section>
			<section anchor="REGEN" numbered="true" toc="default">
			<name>Regeneration of Temporary Addresses</name>
			<t>The frequency at which temporary addresses change
			depends on how a device is being used (e.g., how frequently
			it initiates new communication) and the concerns of the end
			user.
			The most egregious privacy concerns appear to involve
			addresses used for long periods of time (from weeks to
			years). The more frequently an address changes, the less
			feasible collecting or coordinating information keyed on
			IIDs becomes. Moreover, the cost of
			collecting information and attempting to correlate it based
			on IIDs will only be justified if enough
			addresses contain non-changing identifiers to make it
			worthwhile. Thus, having large numbers of clients change
			their address on a daily or weekly basis is likely to be
			sufficient to alleviate most privacy concerns.</t>
			<t>There are also client costs associated with having a
			large number of addresses associated with a host (e.g., in
			doing address lookups, the need to join many multicast
			groups, etc.). Thus, changing addresses frequently (e.g.,
			every few minutes) may have performance implications.</t>
			<t>
			Hosts following this specification <bcp14>SHOULD</bcp14> generate ne
			w temporary
			addresses over time. This can be achieved by generating a
			new temporary address REGEN_ADVANCE time units before a temporary address be
			comes deprecated. As described above,
			this produces addresses with a
			preferred lifetime no larger than TEMP_PREFERRED_LIFETIME. The value
			DESYNC_FACTOR is a random value computed when a temporary address is
			generated; it ensures that clients do not generate new addresses at
			a fixed frequency and that clients do not synchronize with each other
			and generate new addresses at exactly the same time. When the
			preferred lifetime expires, a new temporary address <bcp14>MUST</bcp14> be g
			enerated
			using the algorithm specified in <xref target="SECTION3_3" format="default"/
			> (starting at step 4).</t>
			<t>Because the frequency at which it is appropriate
			to generate new addresses varies from one environment to
			another, implementations <bcp14>SHOULD</bcp14> provide end users with th
			e
			ability to change the frequency at which addresses are
			regenerated. The default value is given in
			TEMP_PREFERRED_LIFETIME and is one day. In addition, the
			exact time at which to invalidate a temporary address
			depends on how applications are used by end users. Thus,
			the suggested default value of two days
			(TEMP_VALID_LIFETIME) may not be appropriate in all
			environments. Implementations <bcp14>SHOULD</bcp14> provide end users wi
			th
			the ability to override both of these default values.</t>
			<t>Finally, when an interface connects to a new (different) link, existi
			ng temporary addresses for the corresponding interface <bcp14>MUST</bcp14> be re
			moved, and new temporary addresses <bcp14>MUST</bcp14> be generated for use on t
			he new link, using the algorithm in <xref target="SECTION3_3" format="default"/>
			.
			If a device moves from one link to another, generating
			new temporary addresses ensures that the device
			uses different randomized IIDs for the
			temporary addresses associated with the two links, making
			it more difficult to correlate addresses from the two
			different links as being from the same host. The host <bcp14>MAY</bcp14>
			follow any process available to it to determine that the
			link change has occurred. One such process is described by "Simple DNA"
			<xref target="RFC6059" format="default"/>. Detecting link changes would prevent
			link down/up events from causing temporary addresses to be (unnecessarily) regen
			erated.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Implementation Considerations</name>
			<t>Devices implementing this specification <bcp14>MUST</bcp14> provide a
			way for the end user to explicitly enable or disable the
			use of temporary addresses. In addition, a site might wish
			to disable the use of temporary addresses in order to
			simplify network debugging and operations. Consequently,
			implementations <bcp14>SHOULD</bcp14> provide a way for trusted system
			administrators to enable or disable the use of temporary
			addresses.</t>
			<t>Additionally, sites might wish to selectively enable or
			disable the use of temporary addresses for some prefixes.
			For example, a site might wish to disable temporary-address
			generation for ULA
			<xref target="RFC4193" format="default"/> prefixes while still generatin
			g
			temporary addresses for all other prefixes advertised via PIOs for addre
			ss configuration. Another
			site might wish to enable temporary-address generation only
			for the prefixes 2001:db8:1::/48 and 2001:db8:2::/48 while disabling it
			for all other prefixes. To support this behavior,
			implementations <bcp14>SHOULD</bcp14> provide a way to enable and disabl
			e
			generation of temporary addresses for specific prefix
			subranges. This per-prefix setting <bcp14>SHOULD</bcp14> override the
			global settings on the host with respect to the specified
			prefix subranges. Note that the per-prefix setting can be
			applied at any granularity, and not necessarily on a per-subnet basis.</
			t>
			</section>
			<section anchor="constants" numbered="true" toc="default">
			<name>Defined Protocol Parameters and Configuration Variables</name>
			<t>Protocol parameters and configuration variables defined in this docum
			ent include:</t>
			<dl newline="true">
			<dt>TEMP_VALID_LIFETIME</dt><dd>Default value: 2 days. Users should
			be able to override the default value.</dd>
			<dt>TEMP_PREFERRED_LIFETIME</dt><dd>Default value: 1 day. Users
			should be able to override the default value. Note: The TEMP_PREFERRED_LIF
			ETIME value <bcp14>MUST</bcp14> be smaller than the TEMP_VALID_LIFETIME value, t
			o avoid the pathological case where an address is employed for new communication
			s but becomes invalid in less than 1 second, disrupting those communications.</d
			d>
			</dl>
			<dl newline="true">
			<dt>REGEN_ADVANCE</dt><dd>2 + (TEMP_IDGEN_RETRIES * DupAddrDetectTransmi
			ts * RetransTimer / 1000)</dd>
			</dl>
			<aside>
			<t>Rationale: This parameter is specified as a function of other proto
			col
			parameters, to account for the time possibly spent in DAD in the worst-cas
			e 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.</t>
			<t>RetransTimer is specified in
			<xref target="RFC4861" format="default"/>, while DupAddrDetectTransmits is
			specified in <xref target="RFC4862" format="default"/>. Since RetransTimer is s
			pecified in units of milliseconds, this expression employs the constant "1000",
			such that
			REGEN_ADVANCE is expressed in seconds.
			</t>
			</aside>
			<dl newline="true">
			<dt>MAX_DESYNC_FACTOR</dt><dd>0.4 * TEMP_PREFERRED_LIFETIME. Upper boun
			d on DESYNC_FACTOR.</dd>
			</dl>
			<aside>
			<t>Rationale: Setting MAX_DESYNC_FACTOR to 0.4 TEMP_PREFERRED_LIFETIME
			results in addresses that have statistically different
			lifetimes, and a maximum of three concurrent temporary
			addresses when the default values specified in this
			section are employed.</t>
			</aside>
			<dl newline="true">
			<dt>DESYNC_FACTOR</dt><dd>A random value within the range 0 -
			MAX_DESYNC_FACTOR. It is computed each time a temporary address is
			generated, and is associated with the corresponding address. It MUST be sma
			ller than (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE).</dd>
			<dt>TEMP_IDGEN_RETRIES</dt><dd>Default value: 3</dd>
			</dl>
			</section>
			</section>
			<section anchor="SECTION4" numbered="true" toc="default">
			<name>Implications of Changing IIDs</name>
			<t>The desire to protect individual privacy can conflict with the desire
			to effectively maintain and debug a network. Having clients use addresses
			that
			change over time will make it more difficult to track down
			and isolate operational problems. For example, when looking
			at packet traces, it could become more difficult to determine
			whether one is seeing behavior caused by a single errant
			host or a number of them.</t>
			<t>It is currently recommended that network deployments provide multiple IPv6 ad
			dresses from each prefix to general-purpose hosts <xref target="RFC7934" format=
			"default"/>. However, in some scenarios, use of a large number of IPv6 addresses
			may have negative implications on network devices that need to maintain entries
			for each IPv6 address in some data structures (e.g., SAVI <xref target="RFC7039
			" format="default"/>). For example, concurrent active use of multiple IPv6 addre
			sses will increase Neighbor Discovery traffic if Neighbor Caches in network devi
			ces are not large enough to store all addresses on the link. This can impact pe
			rformance and energy efficiency on networks on which multicast is expensive (see
			e.g., <xref target="I-D.ietf-mboned-ieee802-mcast-problems" format="default"/>)
			. Additionally, some network-security devices might incorrectly infer IPv6 addre
			ss forging if temporary addresses are regenerated at a high rate.</t>
			<t>The use of temporary addresses may cause unexpected
			difficulties with some applications. For example,
			some servers refuse to accept communications from clients
			for which they cannot map the IP address into a DNS name. That is, they
			perform a DNS PTR query to
			determine the DNS name corresponding to an IPv6 address, and may then also
			perform an AAAA
			query on the returned name to verify it maps back into the the same addres
			s. Consequently,
			clients not properly registered in the DNS may be unable to
			access some services. However, a host's DNS
			name (if non-changing) would serve as a constant identifier. The
			wide deployment of the extension described in this document
			could challenge the practice of inverse-DNS-based
			"validation", which has little validity, though it is
			widely implemented. In order to meet server challenges, hosts
			could register temporary addresses in the DNS using random
			names (for example, a string version of the random address
			itself), albeit at the expense of increased complexity.</t>
			<t>In addition, some applications may not behave robustly if
			an address becomes invalid while it is still in use by the application o
			r if the
			application opens multiple sessions and expects them to all use the
			same address.</t>
			<t>
			<xref target="RFC4941" format="default"/> employed a randomized temporary IID fo
			r generating a set of temporary addresses, such that temporary addresses configu
			red at a given time for multiple SLAAC prefixes would employ the same IID. Shari
			ng the same IID among multiple addresses allowed a host to join only one solicit
			ed-node multicast group per temporary address set.
			</t>
			<t>This document requires that the IIDs of all temporary addresses on a host are
			statistically different from each other. This means that when a network employs
			multiple prefixes, each temporary address of a set will result in a different s
			olicited-node multicast address, and, thus, the number of multicast groups that
			a host must join becomes a function of the number of SLAAC prefixes employed for
			generating temporary addresses.</t>
			<t>
			Thus, a network that employs multiple prefixes may require hosts to join more mu
			lticast groups than in the case of implementations of RFC 4941. If the number of
			multicast groups were large enough, a host might need to resort to setting the
			network interface card to promiscuous mode. This could cause the host to process
			more packets than strictly necessary and might have a negative impact on batter
			y life and system performance in general.</t>
			<t>
			We note that since this document reduces the default TEMP_VALID_LIFETIME from 7
			days (in <xref target="RFC4941" format="default"/>) to 2 days, the number of con
			current temporary addresses per SLAAC prefix will be smaller than for RFC 4941 i
			mplementations; thus, the number of multicast groups for a network that employs,
			say, between 1 and 3 prefixes, will be similar to the number of such groups for
			RFC 4941 implementations.</t>
			<t>
			Implementations concerned with the maximum number of multicast groups that would
			be required to join as a result of configured addresses, or the overall number
			of configured addresses, should consider enforcing implementation-specific limit
			s on, e.g., the maximum number of configured addresses, the maximum number of SL
			AAC prefixes that are employed for autoconfiguration, and/or the maximum ratio f
			or TEMP_VALID_LIFETIME/TEMP_PREFERRED_LIFETIME (which ultimately controls the ap
			proximate number of concurrent temporary addresses per SLAAC prefix). Many of th
			ese configuration limits are readily available in SLAAC and RFC 4941 implementat
			ions. We note that these configurable limits are meant to prevent pathological b
			ehaviors (as opposed to simply limiting the usage of IPv6 addresses), since IPv6
			implementations are expected to leverage the usage of multiple addresses <xref
			target="RFC7934" format="default"/>.
			</t>
			</section>
			<section anchor="changes" numbered="true" toc="default">
			<name>Significant Changes from RFC 4941</name>
			<t>This section summarizes the substantive changes in this document
			relative to RFC 4941.</t>
			<t>Broadly speaking, this document introduces the following changes:
			</t>
			<ul spacing="normal">
			<li>Addresses a number of flaws in the algorithm for generating temporar
			y addresses.
			The aforementioned flaws include the use of MD5 for computing the tempora
			ry IIDs, and reusing the same IID for multiple prefixes (see <xref target="RAID2
			015" format="default"/> and <xref target="RFC7721" format="default"/> for furthe
			r details).</li>
			<li>
			Allows hosts to employ only temporary addresses. <xref target="RFC4941
			" format="default"/> assumed that temporary addresses were configured in additio
			n to stable addresses. This document does not imply or require the configuration
			of stable addresses; thus, implementations can now configure both stable and te
			mporary addresses or temporary addresses only.
			</li>
			<li>
			Removes the recommendation that temporary addresses be disabled by def
			ault. This is in line with BCP 188 (<xref target="RFC7258" format="default"/>) a
			nd also with BCP 204 (<xref target="RFC7934" format="default"/>).
			</li>
			<li>Reduces the default maximum valid lifetime for temporary addresses (
			TEMP_VALID_LIFETIME).
			TEMP_VALID_LIFETIME has been
			reduced from 1 week to 2 days, decreasing the typical number of
			concurrent temporary addresses from 7 to 3. This reduces the
			possible stress on network elements (see <xref target="SECTION4"/> for fu
			rther
			details).</li>
			<li>DESYNC_FACTOR is computed each time a temporary address is generated
			and is associated with the corresponding temporary address, such that each temp
			orary address has a statistically different preferred lifetime, and thus tempora
			ry addresses are not generated at any specific frequency.</li>
			<li>Changes the requirement to not try to regenerate temporary addresses
			upon TEMP_IDGEN_RETRIES consecutive DAD failures from "<bcp14>MUST NOT</bcp14>"
			to "<bcp14>SHOULD NOT</bcp14>".</li>
			<li>The discussion about the security and privacy implications of differ
			ent address generation techniques has been replaced with references to recent wo
			rk in this area (<xref target="RFC7707" format="default"/>, <xref target="RFC772
			1" format="default"/>, and <xref target="RFC7217" format="default"/>).
			</li>
			<li><t>This document incorporates errata submitted (at the time of writing
			) for <xref target="RFC4941" format="default"/> by <contact fullname="Jiri Bohac
			"/> and <contact fullname="Alfred Hoenes"/>.</t></li>
			</ul>
			</section>
			<section anchor="SECTION6" numbered="true" toc="default">
			<name>Future Work</name>
			<t>An implementation might want to keep track of which
			addresses are being used by upper layers so as to be able to
			remove a deprecated temporary address from internal data
			structures once no upper-layer protocols are using it (but
			not before). This is in contrast to current approaches, where
			addresses are removed from an interface when they become
			invalid
			<xref target="RFC4862" format="default"/>, independent of whether or not
			upper-layer protocols are still using them. For TCP
			connections, such information is available in control blocks.
			For UDP-based applications, it may be the case that only the
			applications have knowledge about what addresses are actually
			in use. Consequently, an implementation generally will need
			to use heuristics in deciding when an address is no longer in
			use.</t>
			</section>
			<section anchor="iana-cons" numbered="true" toc="default">
			<name>IANA Considerations</name>
			<t>This document has no IANA actions.</t>
			</section>
			<section numbered="true" toc="default">
			<name>Security Considerations</name>
			<t>If a very small number of hosts (say, only one) use a
			given prefix for extended periods of time, just changing
			the interface-identifier part of the address may not be
			sufficient to mitigate address-based network-activity correlation, since
			the prefix acts as a
			constant identifier. The procedures described in this
			document are most effective when the prefix is reasonably
			nonstatic or used by a fairly large number of
			hosts. Additionally, if a temporary address is used in a session where t
			he user
			authenticates, any notion of "privacy" for that address is
			compromised for the party or parties that receive the authentication
			information.</t>
			<t>While this document discusses ways to limit the lifetime of interface
			identifiers to reduce the ability of attackers to perform
			address-based network-activity correlation, the method described is
			believed to be
			ineffective against sophisticated forms of traffic analysis.
			To increase effectiveness, one may need to consider the use of
			more advanced techniques, such as onion routing
			<xref target="ONION" format="default"/>.</t>
			<t>Ingress filtering has been and is being deployed as a
			means of preventing the use of spoofed source addresses in
			Distributed Denial of Service (DDoS) attacks. In a network
			with a large number of hosts, new temporary addresses are
			created at a fairly high rate. This might make it difficult
			for ingress-/egress-filtering mechanisms to distinguish between
			legitimately changing temporary addresses and spoofed source
			addresses, which are "in-prefix" (using a topologically
			correct prefix and nonexistent interface identifier). This can be
			addressed by using access-control mechanisms on a per-address
			basis on the network ingress point -- though, as noted in <xref target="SE
			CTION4" format="default"/>, there are corresponding costs
			for doing so.</t>
			</section>
			</middle>
			<back>
			<displayreference target="I-D.ietf-mboned-ieee802-mcast-problems" to="MCAST-PROB
			LEMS"/>
			<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.4861.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.6724.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.4086.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.5453.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7136.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.2119.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8174.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.4193.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.4291.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.4862.xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7217.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.4941.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8190.xml"/>
			<!-- [I-D.ietf-mboned-ieee802-mcast-problems] IESG state IESG Evaluation::Revise
			d I-D Needed -->
			<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.
			ietf-mboned-ieee802-mcast-problems.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7934.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7039.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.7421.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.7258.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.5014.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.2104.xml"/>
			<reference anchor="IANA-RESERVED-IID" target="https://www.iana.org/assig
			nments/ipv6-interface-ids">
			<front>
			<title>Reserved IPv6 Interface Identifiers</title>
			<author>
			<organization>IANA</organization>
			</author>
			<date/>
			</front>
			</reference>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.1321.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.6151.xml"/>
			<reference anchor="RAID2015" target="https://publications.sba-research.o
			rg/publications/Ullrich2015Privacy.pdf">
			<front>
			<title>Privacy is Not an Option: Attacking the IPv6 Privacy Extensio
			n</title>
			<author fullname="Johanna Ullrich" initials="J." surname="Ullrich">
			</author>
			<author fullname="Edgar R. Weippl" initials="E.R." surname="Weippl">
			</author>
			<date year="2015"/>
			</front>
			<seriesInfo name="" value="International Symposium on Recent Advances
			in Intrusion Detection (RAID)"/>
			</reference>
			<reference anchor="FIPS-SHS" target="https://nvlpubs.nist.gov/nistpubs/F
			IPS/NIST.FIPS.180-4.pdf">
			<front>
			<title>Secure Hash Standard (SHS)</title>
			<author>
			<organization>NIST</organization>
			</author>
			<date month="August" year="2015"/>
			</front>
			<seriesInfo name="FIPS PUB" value="180-4"/>
			<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
			</reference>
			<reference anchor="BLAKE3" target="https://blake3.io/">
			<front>
			<title>BLAKE3: one function, fast everywhere</title>
			<author initials="J." surname="O'Connor" fullname="Jack O
			'Connor">
			<organization></organization>
			</author>
			<author initials="J. P." surname="Aumasson" fullname="Jea
			n-Philippe Aumasson">
			<organization>NAGRA</organization>
			</author>
			<author initials="S." surname="Neves" fullname="Samuel Ne
			ves">
			<organization></organization>
			</author>
			<author initials="Z." surname="Wilcox-O'Hearn" fullname="
			Zooko Wilcox-O'Hearn">
			<organization></organization>
			</author>
			<date year="2020"/>
			</front>
			</reference>
			<reference anchor="OPEN-GROUP" target="http://pubs.opengroup.org/onlinep
			ubs/9699919799/basedefs/contents.html">
			<front>
			<title>The Open Group Base Specifications Issue 7</title>
			<author>
			<organization>The Open Group</organization>
			</author>
			<date year="2016"/>
			</front>
			<seriesInfo name="Section 4.16" value="Seconds Since the Epoch"/>
			<seriesInfo name="IEEE Std" value="1003.1"/>
			</reference>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.6265.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.7721.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7707.xml"/>
			<reference anchor="ONION">
			<front>
			<title>Proxies for Anonymous Routing</title>
			<author initials="M.G." surname="Reed" fullname="Michael G. Reed">
			<organization/>
			</author>
			<author initials="P.F." surname="Syverson" fullname="Paul F. Syverso
			n">
			<organization/>
			</author>
			<author initials="D.M." surname="Goldschlag" fullname="David M. Gold
			schlag">
			<organization/>
			</author>
			<date month="December" year="1996"/>
			</front>
			<seriesInfo name="Proceedings of the" value="12th Annual Computer Secu
			rity Applications Conference"/>
			<seriesInfo name="DOI" value="10.1109/CSAC.1996.569678" />
			</reference>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.6059.xml"/>
			</references>
			</references>
			<section numbered="false" toc="default">
			<name>Acknowledgments</name>
			<t>Fernando Gont was the sole author of this document (a revision of RFC 4
			941). He would like to thank (in alphabetical order) <contact fullname="Fred Ba
			ker"/>, <contact fullname="Brian Carpenter"/>, <contact fullname="Tim Chown"/>,
			<contact fullname="Lorenzo Colitti"/>, <contact fullname="Roman Danyliw"/>, <con
			tact fullname="David Farmer"/>, <contact fullname="Tom Herbert"/>, <contact full
			name="Bob Hinden"/>, <contact fullname="Christian Huitema"/>, <contact fullname=
			"Benjamin Kaduk"/>, <contact fullname="Erik Kline"/>, <contact fullname="Gyan Mi
			shra"/>, <contact fullname="Dave Plonka"/>, <contact fullname="Alvaro Retana"/>,
			<contact fullname="Michael Richardson"/>, <contact fullname="Mark Smith"/>, <co
			ntact fullname="Dave Thaler"/>, <contact fullname="Pascal Thubert"/>, <contact f
			ullname="Ole Troan"/>, <contact fullname="Johanna Ullrich"/>, <contact fullname=
			"Eric Vyncke"/>, <contact fullname="Timothy Winters"/>, and <contact fullname="C
			hristopher Wood"/> for providing valuable comments on earlier draft versions of
			this document.</t>
			<t>This document incorporates errata submitted for RFC 4941 by <contact fu
			llname="Jiri Bohac"/> and <contact fullname="Alfred Hoenes"/> (at the time of wr
			iting).</t>
			<t><contact fullname="Suresh Krishnan"/> was the sole author of RFC
			4941 (a revision of RFC 3041). He would like to acknowledge the contributions of
			the IPv6 Working Group and, in particular, <contact fullname="Jari Arkko"/>, <c
			ontact fullname="Pekka Nikander"/>, <contact fullname="Pekka Savola"/>, <contact
			fullname="Francis Dupont"/>, <contact fullname="Brian Haberman"/>, <contact ful
			lname="Tatuya Jinmei"/>, and <contact fullname="Margaret Wasserman"/>
			for their detailed comments.</t>
			<t>
			<contact fullname="Rich Draves"/> and <contact fullname="Thomas Narten"/> wer
			e the authors of RFC 3041. They
			would like to acknowledge the contributions of the IPv6 Working Group
			and, in particular, <contact fullname="Ran Atkinson"/>, <contact fullname="Ma
			tt Crawford"/>, <contact fullname="Steve Deering"/>, <contact fullname="Allison
			Mankin"/>, and <contact fullname="Peter Bieringer"/>.
			</t>
			</section>
			</back>
			</rfc>
End of changes. 1 change blocks.
	lines changed or deleted		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/