draft-ietf-6man-rfc4941bis-03.txt   draft-ietf-6man-rfc4941bis-04.txt 
IPv6 Maintenance (6man) Working Group F. Gont IPv6 Maintenance (6man) Working Group F. Gont
Internet-Draft SI6 Networks / UTN-FRH Internet-Draft SI6 Networks / UTN-FRH
Obsoletes: rfc4941 (if approved) S. Krishnan Obsoletes: rfc4941 (if approved) S. Krishnan
Intended status: Standards Track Ericsson Research Intended status: Standards Track Ericsson Research
Expires: March 8, 2020 T. Narten Expires: May 6, 2020 T. Narten
IBM Corporation IBM Corporation
R. Draves R. Draves
Microsoft Research Microsoft Research
September 5, 2019 November 3, 2019
Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
draft-ietf-6man-rfc4941bis-03 draft-ietf-6man-rfc4941bis-04
Abstract Abstract
Nodes use IPv6 stateless address autoconfiguration to generate Nodes use IPv6 stateless address autoconfiguration to generate
addresses using a combination of locally available information and addresses using a combination of locally available information and
information advertised by routers. Addresses are formed by combining information advertised by routers. Addresses are formed by combining
network prefixes with an interface identifier. This document network prefixes with an interface identifier. This document
describes an extension that causes nodes to generate global scope describes an extension that causes nodes to generate global scope
addresses with randomized interface identifiers that change over addresses with randomized interface identifiers that change over
time. Changing global scope addresses over time makes it more time. Changing global scope addresses over time makes it more
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 March 8, 2020. This Internet-Draft will expire on May 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 36 skipping to change at page 2, line 36
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. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Generation of Randomized Interface Identifiers . . . . . 8 3.2. Generation of Randomized Interface Identifiers . . . . . 8
3.2.1. Simple Randomized Interface Identifiers . . . . . . . 8 3.2.1. Simple Randomized Interface Identifiers . . . . . . . 8
3.2.2. Hash-based Generation of Randomized Interface 3.2.2. Hash-based Generation of Randomized Interface
Identifiers . . . . . . . . . . . . . . . . . . . . . 9 Identifiers . . . . . . . . . . . . . . . . . . . . . 9
3.3. Generating Temporary Addresses . . . . . . . . . . . . . 10 3.3. Generating Temporary Addresses . . . . . . . . . . . . . 10
3.4. Expiration of Temporary Addresses . . . . . . . . . . . . 12 3.4. Expiration of Temporary Addresses . . . . . . . . . . . . 12
3.5. Regeneration of Randomized Interface Identifiers . . . . 12 3.5. Regeneration of Temporary Addresses . . . . . . . . . . . 12
3.6. Deployment Considerations . . . . . . . . . . . . . . . . 13 3.6. Deployment Considerations . . . . . . . . . . . . . . . . 13
4. Implications of Changing Interface Identifiers . . . . . . . 14 4. Implications of Changing Interface Identifiers . . . . . . . 14
5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 15 5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 15
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Significant Changes from RFC4941 . . . . . . . . . . . . . . 16 8. Significant Changes from RFC4941 . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 18
skipping to change at page 3, line 33 skipping to change at page 3, line 33
temporary addresses. temporary addresses.
Section 2 provides background information on the issue. Section 3 Section 2 provides background information on the issue. Section 3
describes a procedure for generating temporary interface identifiers describes a procedure for generating temporary interface identifiers
and global scope addresses. Section 4 discusses implications of and global scope addresses. Section 4 discusses implications of
changing interface identifiers. changing interface identifiers.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
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]. [RFC4291] and "Unique local addresses" as defined in [RFC4193], and
not to "globally reachable" 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 remains [RFC4862] contain an embedded interface identifier, which remains
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 6, line 32 skipping to change at page 6, line 32
Many machines function as both clients and servers. In such cases, Many machines function as both clients and servers. In such cases,
the machine would need a DNS name for its use as a server. Whether the machine would need a DNS name for its use as a server. Whether
the address stays fixed or changes has little privacy implication the address stays fixed or changes has little privacy implication
since the DNS name remains constant and serves as a constant since the DNS name remains constant and serves as a constant
identifier. When acting as a client (e.g., initiating identifier. When acting as a client (e.g., initiating
communication), however, such a machine may want to vary the communication), however, such a machine may want to vary the
addresses it uses. In such environments, one may need multiple addresses it uses. In such environments, one may need multiple
addresses: a stable address registered in the DNS, that is used to addresses: a stable address registered in the DNS, that is used to
accept incoming connection requests from other machines, and a accept incoming connection requests from other machines, and a
temporary address used to shield the identity of the client when it temporary address used to shield the identity of the client when it
initiates communication. These two cases are roughly analogous to initiates communication.
telephone numbers and caller ID, where a user may list their
telephone number in the public phone book, but disable the display of
its number via caller ID when initiating calls.
On the other hand, a machine that functions only as a client may want On the other hand, a machine that functions only as a client may want
to employ only temporary addresses for public communication. to employ only temporary addresses for public communication.
To make it difficult to make educated guesses as to whether two To make it difficult to make educated guesses as to whether two
different interface identifiers belong to the same node, the different interface identifiers belong to the same node, the
algorithm for generating alternate identifiers must include input algorithm for generating alternate identifiers must include input
that has an unpredictable component from the perspective of the that has an unpredictable component from the perspective of the
outside entities that are collecting information. outside entities that are collecting information.
skipping to change at page 8, line 35 skipping to change at page 8, line 33
One possible approach would be to select a pseudorandom number of the One possible approach would be to select a pseudorandom number of the
appropriate length. A node employing this algorithm should generate appropriate length. A node employing this algorithm should generate
IIDs as follows: IIDs as 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 aforementioned random number (obtained in the previous step) the aforementioned random number (obtained in the previous step)
as necessary. as necessary. Note: there are no special bits in an Interface
Identifier [RFC7136].
We note that [RFC4291] requires that the Interface IDs of all We note that [RFC4291] requires that the Interface IDs of all
unicast addresses (except those that start with the binary unicast addresses (except those that start with the binary
value 000) be 64 bits long. However, the method discussed in value 000) be 64 bits long. However, the method discussed in
this document could be employed for generating Interface IDs this document could be employed for generating Interface IDs
of any arbitrary length, albeit at the expense of reduced of any arbitrary length, albeit at the expense of reduced
entropy (when employing Interface IDs smaller than 64 bits). entropy (when employing Interface IDs smaller than 64 bits).
3. The resulting Interface Identifier SHOULD be compared against the 3. The resulting Interface Identifier SHOULD be compared against the
reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID] reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]
skipping to change at page 11, line 29 skipping to change at page 11, line 29
corresponding prefix, the node SHOULD create a new temporary corresponding prefix, the node SHOULD create a new temporary
address for such prefix. address for such prefix.
4. When creating a temporary address, the lifetime values MUST be 4. When creating a temporary address, the lifetime values MUST be
derived from the corresponding prefix as follows: derived from the corresponding prefix as follows:
* Its Valid Lifetime is the lower of the Valid Lifetime of the * Its Valid Lifetime is the lower of the Valid Lifetime of the
prefix and TEMP_VALID_LIFETIME prefix and TEMP_VALID_LIFETIME
* Its Preferred Lifetime is the lower of the Preferred Lifetime * Its Preferred Lifetime is the lower of the Preferred Lifetime
of prefix and TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR. of the prefix and TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR.
5. A temporary address is created only if this calculated Preferred 5. A temporary address is created only if this calculated Preferred
Lifetime is greater than REGEN_ADVANCE time units. In Lifetime is greater than REGEN_ADVANCE time units. In
particular, an implementation MUST NOT create a temporary address particular, an implementation MUST NOT create a temporary address
with a zero Preferred Lifetime. with a zero Preferred Lifetime.
6. New temporary addresses MUST be created by appending a randomized 6. New temporary addresses MUST be created by appending a randomized
interface identifier (generates as described in Section 3.2 of interface identifier (generates as described in Section 3.2 of
this document) to the prefix that was received. this document) to the prefix that was received.
skipping to change at page 12, line 29 skipping to change at page 12, line 29
race conditions in the case where generating a new temporary address race conditions in the case where generating a new temporary address
is not instantaneous, such as when duplicate address detection must is not instantaneous, such as when duplicate address detection must
be run. The node SHOULD start the address regeneration process be run. The node SHOULD start the address regeneration process
REGEN_ADVANCE time units before a temporary address would actually be REGEN_ADVANCE time units before a temporary address would actually be
deprecated. deprecated.
As an optional optimization, an implementation MAY remove a As an optional optimization, an implementation MAY remove a
deprecated temporary address that is not in use by applications or deprecated temporary address that is not in use by applications or
upper layers as detailed in Section 6. upper layers as detailed in Section 6.
3.5. Regeneration of Randomized Interface Identifiers 3.5. Regeneration of Temporary Addresses
The frequency at which temporary addresses change depends on how a The frequency at which temporary addresses change depends on how a
device is being used (e.g., how frequently it initiates new device is being used (e.g., how frequently it initiates new
communication) and the concerns of the end user. The most egregious communication) and the concerns of the end user. The most egregious
privacy concerns appear to involve addresses used for long periods of privacy concerns appear to involve addresses used for long periods of
time (weeks to months to years). The more frequently an address time (weeks to months to years). The more frequently an address
changes, the less feasible collecting or coordinating information changes, the less feasible collecting or coordinating information
keyed on interface identifiers becomes. Moreover, the cost of keyed on interface identifiers becomes. Moreover, the cost of
collecting information and attempting to correlate it based on collecting information and attempting to correlate it based on
interface identifiers will only be justified if enough addresses interface identifiers will only be justified if enough addresses
skipping to change at page 12, line 51 skipping to change at page 12, line 51
large numbers of clients change their address on a daily or weekly large numbers of clients change their address on a daily or weekly
basis is likely to be sufficient to alleviate most privacy concerns. basis is likely to be sufficient to alleviate most privacy concerns.
There are also client costs associated with having a large number of There are also client costs associated with having a large number of
addresses associated with a node (e.g., in doing address lookups, the addresses associated with a node (e.g., in doing address lookups, the
need to join many multicast groups, etc.). Thus, changing addresses need to join many multicast groups, etc.). Thus, changing addresses
frequently (e.g., every few minutes) may have performance frequently (e.g., every few minutes) may have performance
implications. implications.
Nodes following this specification SHOULD generate new temporary Nodes following this specification SHOULD generate new temporary
addresses on a periodic basis. This can be achieved automatically by addresses on a periodic basis. This can be achieved by generating a
generating a new randomized interface identifier at least once every new temporary address at least once every (TEMP_PREFERRED_LIFETIME -
(TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR) time units. REGEN_ADVANCE - DESYNC_FACTOR) time units. As described above,
As described above, generating a new temporary address REGEN_ADVANCE generating a new temporary address REGEN_ADVANCE time units before a
time units before a temporary address becomes deprecated produces temporary address becomes deprecated produces addresses with a
addresses with a preferred lifetime no larger than preferred lifetime no larger than TEMP_PREFERRED_LIFETIME. The value
TEMP_PREFERRED_LIFETIME. The value DESYNC_FACTOR is a random value DESYNC_FACTOR is a random value (different for each client) that
(different for each client) that ensures that clients don't ensures that clients don't synchronize with each other and generate
synchronize with each other and generate new addresses at exactly the new addresses at exactly the same time. When the preferred lifetime
same time. When the preferred lifetime expires, a new temporary expires, a new temporary address MUST be generated using the new
address MUST be generated using the new randomized interface randomized interface identifier.
identifier.
Because the precise frequency at which it is appropriate to generate Because the precise frequency at which it is appropriate to generate
new addresses varies from one environment to another, implementations new addresses varies from one environment to another, implementations
SHOULD provide end users with the ability to change the frequency at SHOULD provide end users with the ability to change the frequency at
which addresses are regenerated. The default value is given in which addresses are regenerated. The default value is given in
TEMP_PREFERRED_LIFETIME and is one day. In addition, the exact time TEMP_PREFERRED_LIFETIME and is one day. In addition, the exact time
at which to invalidate a temporary address depends on how at which to invalidate a temporary address depends on how
applications are used by end users. Thus, the suggested default applications are used by end users. Thus, the suggested default
value of one week (TEMP_VALID_LIFETIME) may not be appropriate in all value of one week (TEMP_VALID_LIFETIME) may not be appropriate in all
environments. Implementations SHOULD provide end users with the environments. Implementations SHOULD provide end users with the
skipping to change at page 15, line 31 skipping to change at page 15, line 29
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.
REGEN_ADVANCE -- 5 seconds REGEN_ADVANCE -- 5 seconds
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_VALID_LIFETIME - REGEN_ADVANCE). (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE).
TEMP_IDGEN_RETRIES -- Default value: 3 TEMP_IDGEN_RETRIES -- Default value: 3
6. Future Work 6. Future Work
An implementation might want to keep track of which addresses are 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 being used by upper layers so as to be able to remove a deprecated
temporary address from internal data structures once no upper layer temporary address from internal data structures once no upper layer
protocols are using it (but not before). This is in contrast to protocols are using it (but not before). This is in contrast to
current approaches where addresses are removed from an interface when current approaches where addresses are removed from an interface when
skipping to change at page 16, line 41 skipping to change at page 16, line 37
4941 that an implementer of RFC 4941 should be aware of. 4941 that an implementer of RFC 4941 should be aware of.
1. Discussion of IEEE-based IIDs has been removed, since the current 1. Discussion of IEEE-based IIDs has been removed, since the current
recommendation ([RFC8064]) is to employ [RFC7217]). recommendation ([RFC8064]) is to employ [RFC7217]).
2. The document employs the terminology from [RFC7721]. 2. The document employs the terminology from [RFC7721].
3. Sections 2.2 and 2.3 of [RFC4941] have been removed since the 3. Sections 2.2 and 2.3 of [RFC4941] have been removed since the
topic has been discussed in more detail in e.g. [RFC7721]. topic has been discussed in more detail in e.g. [RFC7721].
4. The algorithm to generate randomized interface identifiers was 4. The algorithm specified in Section 3.2.1 and 3.2.2 of [RFC4941]
replaced by two possible alternative algorithms. was replaced by two possible alternative algorithms.
5. Generation of stable addresses is not implied or required by this 5. Generation of stable addresses is not implied or required by this
document. document.
6. Temporary addresses are *not* disabled by default. 6. Temporary addresses are *not* disabled by default.
7. Section 3.2.1 and 3.2.2 from [RFC4941] were replaced with 7. Section 3.2.3 from [RFC4941] was removed, based on the
alternative algorithms.
8. Section 3.2.3 from [RFC4941] was removed, based on the
explanation of that very section of RFC4941. explanation of that very section of RFC4941.
9. All the verified errata for [RFC4941] has been incorporated. 8. All the verified errata for [RFC4941] has been incorporated.
9. Acknowledgments 9. Acknowledgments
The authors would like to thank (in alphabetical order) Brian The authors would like to thank (in alphabetical order) Brian
Carpenter, Tim Chown, Lorenzo Colitti, David Farmer, Tom Herbert, Bob Carpenter, Tim Chown, Lorenzo Colitti, David Farmer, Tom Herbert, Bob
Hinden, Christian Huitema, Dave Plonka, Michael Richardson, Mark Hinden, Christian Huitema, Dave Plonka, Michael Richardson, Mark
Smith, and Johanna Ullrich for providing valuable comments on earlier Smith, and Johanna Ullrich for providing valuable comments on earlier
versions of this document. versions of this document.
This document incoporates errata submitted for [RFC4941] by (in
alphabetical order) Jiri Bohac and Alfred Hoenes.
This document is based on [RFC4941] (a revision of RFC3041). Suresh This document is based on [RFC4941] (a revision of RFC3041). Suresh
Krishnan was the sole author of RFC4941. He would like to Krishnan was the sole author of RFC4941. He would like to
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,
skipping to change at page 18, line 39 skipping to change at page 18, line 39
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>. <https://www.rfc-editor.org/info/rfc7217>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017, RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>. <https://www.rfc-editor.org/info/rfc8064>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda,
"Updates to the Special-Purpose IP Address Registries",
BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017,
<https://www.rfc-editor.org/info/rfc8190>.
10.2. Informative References 10.2. Informative References
[FIPS-SHS] [FIPS-SHS]
NIST, "Secure Hash Standard (SHS)", FIPS NIST, "Secure Hash Standard (SHS)", FIPS
Publication 180-4, March 2012, Publication 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/fips-
fips-180-4.pdf>. 180-4.pdf>.
[IANA-RESERVED-IID] [IANA-RESERVED-IID]
IANA, "Reserved IPv6 Interface Identifiers", IANA, "Reserved IPv6 Interface Identifiers",
<http://www.iana.org/assignments/ipv6-interface-ids>. <http://www.iana.org/assignments/ipv6-interface-ids>.
[ONION] Reed, MGR., Syverson, PFS., and DMG. Goldschlag, "Proxies [ONION] Reed, MGR., Syverson, PFS., and DMG. Goldschlag, "Proxies
for Anonymous Routing", Proceedings of the 12th Annual for Anonymous Routing", Proceedings of the 12th Annual
Computer Security Applications Conference, San Diego, CA, Computer Security Applications Conference, San Diego, CA,
December 1996. December 1996.
 End of changes. 19 change blocks. 
37 lines changed or deleted 46 lines changed or added

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