< draft-ietf-dhc-stable-privacy-addresses-01.txt   draft-ietf-dhc-stable-privacy-addresses-02.txt >
Dynamic Host Configuration (dhc) F. Gont Dynamic Host Configuration (dhc) F. Gont
Internet-Draft SI6 Networks / UTN-FRH Internet-Draft SI6 Networks / UTN-FRH
Intended status: Standards Track W. Liu Intended status: Standards Track W. Liu
Expires: August 22, 2015 Huawei Technologies Expires: October 10, 2015 Huawei Technologies
February 18, 2015 April 8, 2015
A Method for Generating Semantically Opaque Interface Identifiers with A Method for Generating Semantically Opaque Interface Identifiers with
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-stable-privacy-addresses-01 draft-ietf-dhc-stable-privacy-addresses-02
Abstract Abstract
This document specifies a method for selecting IPv6 Interface This document specifies a method for selecting IPv6 Interface
Identifiers, to be employed by Dynamic Host Configuration Protocol Identifiers, to be employed by Dynamic Host Configuration Protocol
for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses
to DHCPv6 clients. This method is a DHCPv6 server side algorithm, to DHCPv6 clients. This method is a DHCPv6 server side algorithm,
that does not require any updates to the existing DHCPv6 that does not require any updates to the existing DHCPv6
specifications. The aforementioned method results in stable specifications. The aforementioned method results in stable
addresses within each subnet, even in the presence of multiple DHCPv6 addresses within each subnet, even in the presence of multiple DHCPv6
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 August 22, 2015. This Internet-Draft will expire on October 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Method Specification . . . . . . . . . . . . . . . . . . . . 3 3. Applicability and Design Goals . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. Method Specification . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Stable IPv6 addresses tend to simplify event logging, trouble- Stable IPv6 addresses tend to simplify event logging, trouble-
shooting, enforcement of access controls and quality of service, etc. shooting, enforcement of access controls and quality of service, etc.
However, there are a number of scenarios in which a host employing However, there are a number of scenarios in which a host employing
the DHCPv6 protocol [RFC3315] may be assigned different IPv6 the DHCPv6 protocol [RFC3315] may be assigned different IPv6
addresses for the same interface within the same subnet over time. addresses for the same interface within the same subnet over time.
For example, this may happen when multiple servers operate on the For example, this may happen when multiple servers operate on the
same network to provide increased availability, but may also happen same network to provide increased availability, but may also happen
skipping to change at page 3, line 7 skipping to change at page 3, line 9
the same network interface of the same client, even when different the same network interface of the same client, even when different
DHCPv6 servers (implementing this specification) are employed. DHCPv6 servers (implementing this specification) are employed.
o Predicting the IPv6 addresses that will be generated by the method o Predicting the IPv6 addresses that will be generated by the method
specified in this document, even with knowledge of the IPv6 specified in this document, even with knowledge of the IPv6
addresses generated for other nodes within the same network, addresses generated for other nodes within the same network,
becomes very difficult. becomes very difficult.
The method specified in this document achieves the aforementioned The method specified in this document achieves the aforementioned
properties by means of a calculated technique as opposed to e.g. properties by means of a calculated technique as opposed to e.g.
state- sharing among DHCPv6 servers. This approach has been already state-sharing among DHCPv6 servers. This approach has been already
suggested in [RFC7031]. We note that the method specified in this suggested in [RFC7031]. We note that the method specified in this
document is essentially a DHCPv6-version of the "Method for document is essentially a DHCPv6-version of the "Method for
Generating Semantically Opaque Interface Identifiers with IPv6 Generating Semantically Opaque Interface Identifiers with IPv6
Stateless Address Autoconfiguration (SLAAC)" specified in [RFC7217]. Stateless Address Autoconfiguration (SLAAC)" specified in [RFC7217].
2. Terminology 2. 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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Method Specification 3. Applicability and Design Goals
This document does not update the DHCPv6 protocol [RFC3315]. DHCPv6
implementations are NOT required to implement/support the mechanism
specified in this document. It is up to each DHCPv6 server
implementation whether the scheme specified in this document is
implemented and/or enabled.
This document simply specifies one possible approach for selecting
IPv6 Interface Identifiers to be employed by Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) servers when leasing non-
temporary IPv6 addresses to DHCPv6 clients, with the following
properties:
o The resulting IPv6 addresses remain stable within each subnet for
the same network interface of the same client.
o The resulting IPv6 addresses cannot be predicted by an attacker
without knowledge of a secret key.
o The resulting IPv6 addresses remain stable across DHCPv6 server
re-installations, or even a database of previous DHCPv6 address
leases is not available.
o The resulting IPv6 addresses remain stable when different DHCPv6
servers (implementing this specification) are employed on the same
network.
The benefits of stable IPv6 addresses are discussed in
[I-D.ietf-6man-ipv6-address-generation-privacy]. Providing address
stability across server re-installations or when a database of
previous DHCPv6 address leases is unavailable is of use not only when
a DHCPv6 server must be re-installed or the address-lease database
becomes corrupted, but is also of use when implementation constraints
(e.g., a DHCPv6 server implementation on an embedded device) make it
impossible for a DHCPv6 server implementation to maintain a database
of previous DHCPv6 address leases. Finally, [RFC7031] describes
scenarios where multiple DHCPv6 servers are required to run in such a
way as to provide increased availability in case of server failure;
the algorithm specified in this document employs a (lightweight)
calculated technique to (as opposed to e.g. state-sharing among
DHCPv6 servers) to achieve address stability in such scenarios,
without the need of an additional protocol to synchronize the lease
databases of DHCPv6 servers.
4. Method Specification
DHCPv6 server implementations conforming to this specification MUST DHCPv6 server implementations conforming to this specification MUST
generate non-temporary IPv6 addresses using the algorithm specified generate non-temporary IPv6 addresses using the algorithm specified
in this section. in this section.
Implementations conforming to this specification SHOULD provide the Implementations conforming to this specification SHOULD provide the
means for a system administrator to enable or disable the use of this means for a system administrator to enable or disable the use of this
algorithm for generating IPv6 addresses. algorithm for generating IPv6 addresses.
All of the parameters included in the expression below MUST be All of the parameters included in the expression below MUST be
included when generating an IPv6 address. included when generating an IPv6 address.
A DHCPv6 server implementing this specification must select the IPv6 A DHCPv6 server implementing this specification must select the IPv6
addresses to be leased with the following algorithm: addresses to be leased with the following algorithm:
1. Compute a random (but stable) identifier with the expression: 1. Compute a random (but stable) identifier with the expression:
RID = F(IPV6_ADDR_HI | IPV6_ADDR_LOW | Client_DUID | IAID | RID = F(Prefix | Client_DUID | IAID | Counter | secret_key)
Counter | secret_key)
Where: Where:
RID: RID:
Random (but stable) Identifier Random (but stable) Identifier
F(): F():
A pseudorandom function (PRF) that MUST NOT be computable from A pseudorandom function (PRF) that MUST NOT be computable from
the outside (without knowledge of the secret key). F() MUST the outside (without knowledge of the secret key). F() MUST
also be difficult to reverse, such that it resists attempts to also be difficult to reverse, such that it resists attempts to
obtain the secret_key, even when given samples of the output obtain the secret key, even when given samples of the output
of F() and knowledge or control of the other input parameters. of F() and knowledge or control of the other input parameters.
F() SHOULD produce an output of at least 64 bits. F() could F() SHOULD produce an output of at least 64 bits. F() could
be implemented as a cryptographic hash of the concatenation of be implemented as a cryptographic hash of the concatenation of
each of the function parameters. The default algorithm to be each of the function parameters. The default algorithm to be
employed for F() SHOULD be SHA-1 [FIPS-SHS]. An employed for F() SHOULD be SHA-1 [FIPS-SHS]. An
implementation MAY provide the means for selecting other other implementation MAY provide the means for selecting other other
algorithms (e.g., SHA-256) for F(). Note: MD5 [RFC1321] is algorithms (e.g., SHA-256) for F(). Note: MD5 [RFC1321] is
considered unacceptable for F() [RFC6151]. considered unacceptable for F() [RFC6151].
|: Prefix:
An operator representing "concatenation". The prefix employed for the local subnet. If multiple servers
operate on the same network to provide increased availability,
IPV6_ADDR_HI: all such DHCPv6 servers MUST be configured with the same
An IPv6 address specifying the upper boundary of the IPv6 Prefix. It is the administrator's responsibility that the
address pool from which the DHCPv6 server leases IPv6
addresses. It MUST be represented as a 128-bit unsigned
integer in network byte order. If multiple servers operate on
the same network to provide increased availability, all such
DHCPv6 servers MUST be configured with the address range
(i.e., the same IPV6_ADDR_HI and IPV6_ADDR_LOW parameters).
It is the administrator's responsibility that the
aforementioned requirement is met. aforementioned requirement is met.
IPV6_ADDR_LOW: |:
An IPv6 address specifying the lower boundary of the IPv6 An operator representing "concatenation".
address pool from which the DHCPv6 server leases IPv6
addresses. It MUST be represented as a 128-bit unsigned
integer in network byte order. If multiple servers operate on
the same network to provide increased availability, all such
DHCPv6 servers MUST be configured with the address range
(i.e., the same IPV6_ADDR_HI and IPV6_ADDR_LOW parameters).
It is the administrator's responsibility that the
aforementioned requirement is met.
Client_DUID: Client_DUID:
The DUID value contained in the Client Identifier option The DUID value contained in the Client Identifier option
received in the DHCPv6 client message. The DUID can be received in the DHCPv6 client message. The DUID can be
treated as an array of 8-bit unsigned integers. treated as an array of 8-bit unsigned integers.
IAID: IAID:
The IAID value contained in the IA_NA option received in the The IAID value contained in the IA_NA option received in the
client message. It MUST be interpreted as a 32-bit unsigned client message. It MUST be interpreted as a 32-bit unsigned
integer in network byte order. integer in network byte order.
Counter:
A 32-bit unsigned integer in network byte order, that is
employed to resolve address conflicts. It MUST be initialized
to 0.
secret_key: secret_key:
A secret key configured by the DHCPv6 server administrator, A secret key configured by the DHCPv6 server administrator,
which MUST NOT be known by the attacker. It MUST be encoded which MUST NOT be known by the attacker. It MUST be encoded
as an array of 8-bit unsigned integers containing the ASCII as an array of 8-bit unsigned integers containing the ASCII
codes corresponding to the secret key. An implementation of codes corresponding to the secret key. An implementation of
this specification MUST provide an interface for viewing and this specification MUST provide an interface for viewing and
changing the secret key. All DHCPv6 servers leasing addresses changing the secret key. All DHCPv6 servers leasing addresses
from the same address range MUST employ the same secret key. from the same address range MUST employ the same secret key.
2. A candidate IPv6 address to be leased is obtained as follows: Counter:
A 32-bit unsigned integer in network byte order, that is
employed to resolve address conflicts. It MUST be initialized
to 0.
IPV6_ADDRESS = IPV6_ADDR_LOW + RID % (IPV6_ADDR_HI - 2. A candidate IPv6 address (IPV6_ADDR) to be leased is obtained by
IPV6_ADDR_LOW + 1) concatenating as many bits as necessary from the RID value
computed in the previous step (starting from the least
significant bit) to the Prefix employed in the equation above.
We note that [RFC4291] requires that, the Interface IDs of all 3. The candidate IPv6 address from the previous step should be
unicast addresses (except those that start with the binary adjusted (if necessary) to the IPv6 address range from which the
value 000) be 64-bit long. The method discussed in this DHCPv6 server is expected to lease IPv6 addresses, as follows:
document can be employed for generating IPv6 addresses for any
address range (e.g., smaller than 2**64 bits), albeit at the
expense of reduced entropy (when the address range is smaller
than than of a full 64-bit subnet).
3. The Interface Identifier of the selected IPv6 address MUST be if(IPV6_ADDR < IPV6_ADDR_LOW || IPV6_ADDR > IPV6_ADDR_HI){
IPV6_ADDR = IPV6_ADDR_LOW + IPV6_ADDR % \
(IPV6_ADDR_HI - IPV6_ADDR_LOW + 1);
}
where:
IPV6_ADDR:
The candidate IPv6 address generated in the previous step..
IPV6_ADDR_HI:
An IPv6 address specifying the upper boundary of the IPv6
address pool from which the DHCPv6 server leases IPv6
addresses. If an address range is not explicitly selected,
IPV6_ADDR_HI MUST be set to the IPv6 address from Prefix (see
the expression above) that has all of the bits of the
Interface Identifier set to 1.
IPV6_ADDR_LOW:
An IPv6 address specifying the lower boundary of the IPv6
address pool from which the DHCPv6 server leases IPv6
addresses. If an address range is not explicitly selected,
IPV6_ADDR_LOW MUST be set to the IPv6 address from Prefix (see
the expression above) that has all of the bits of the
Interface Identifier set to 0.
4. The Interface Identifier of the selected IPv6 address MUST be
compared against the reserved IPv6 Interface Identifiers compared against the reserved IPv6 Interface Identifiers
[RFC5453] [IANA-RESERVED-IID]. In the event that an unacceptable [RFC5453] [IANA-RESERVED-IID]. In the event that an unacceptable
identifier has been generated, the Counter variable should be identifier has been generated, the Counter variable should be
incremented by 1, and a new IPv6 address (RID and subsequent incremented by 1, and a new IPv6 address should be computed with
IPV6_ADDRESS) should be computed with the updated Counter value. the updated Counter value.
4. If the resulting address is not available (e.g., there is a 5. If the resulting address is not available (e.g., there is a
conflicting binding), the server should increment the Counter conflicting binding), the server should increment the Counter
variable, and a new Interface ID and IPv6 address should be variable, and a new Interface ID and IPv6 address should be
computed with the updated Counter value. computed with the updated Counter value.
This document requires that SHA-1 be the default function to be used This document requires that SHA-1 be the default function to be used
for F(), such that, all other configuration parameters being the for F(), such that, all other configuration parameters being the
same, different implementations of this specification result in the same, different implementations of this specification result in the
same IPv6 addresses. same IPv6 addresses.
Including the address range in the PRF computation causes the Including the Prefix in the PRF computation causes the Interface
Interface Identifier to be different for each IPv6 address leased Identifier to be different for each address from a different prefix
from a different address range to the same client. This mitigates assigned to the same client. This mitigates the correlation of
the correlation of activities of multi-homed nodes (since each of the activities of multi-homed nodes (since each of the corresponding
corresponding addresses will employ a different Interface ID), host- addresses will employ a different Interface ID), host-tracking (since
tracking (since the network prefix will change as the node moves from the network prefix will change as the node moves from one network to
one network to another), and any other attacks that benefit from another), and any other attacks that benefit from predictable
predictable Interface Identifiers (such as IPv6 address scanning Interface Identifiers
attacks) [I-D.ietf-6man-ipv6-address-generation-privacy]. [I-D.ietf-6man-ipv6-address-generation-privacy].
As required by [RFC3315], an IAID is associated with each of the As required by [RFC3315], an IAID is associated with each of the
client's network interfaces, and is consistent across restarts of the client's network interfaces, and is consistent across restarts of the
DHCPv6 client. DHCPv6 client.
The Counter parameter provides the means to intentionally cause this The Counter parameter provides the means to intentionally cause this
algorithm to produce different IPv6 addresses (all other parameters algorithm to produce different IPv6 addresses (all other parameters
being the same). This could be necessary to resolve address being the same). This can be of use to resolve address conflicts
conflicts (e.g. the resulting address having a conflicting binding). (e.g. the resulting address having a conflicting binding).
Note that the result of F() in the algorithm above is no more secure Note that the result of F() in the algorithm above is no more secure
than the secret key. If an attacker is aware of the PRF that is than the secret key. If an attacker is aware of the PRF that is
being used by the DHCPv6 server (which we should expect), and the being used by the DHCPv6 server (which we should expect), and the
attacker can obtain enough material (i.e. addresses generated by the attacker can obtain enough material (i.e. addresses generated by the
DHCPv6 server), the attacker may simply search the entire secret-key DHCPv6 server), the attacker may simply search the entire secret-key
space to find matches. To protect against this, the secret key space to find matches. To protect against this, the secret key
SHOULD be of at least 128 bits. Key lengths of at least 128 bits SHOULD be of at least 128 bits. Key lengths of at least 128 bits
should be adequate. should be adequate.
skipping to change at page 6, line 40 skipping to change at page 7, line 44
require superuser privileges to access it). Furthermore, in order to require superuser privileges to access it). Furthermore, in order to
prevent leakages of the secret_key parameter, it should not be used prevent leakages of the secret_key parameter, it should not be used
for any other purposes than being a parameter to the scheme specified for any other purposes than being a parameter to the scheme specified
in this document. in this document.
We note that all of the bits in the resulting Interface IDs are We note that all of the bits in the resulting Interface IDs are
treated as "opaque" bits [RFC7136]. For example, the universal/local treated as "opaque" bits [RFC7136]. For example, the universal/local
bit of Modified EUI-64 format identifiers is treated as any other bit bit of Modified EUI-64 format identifiers is treated as any other bit
of such identifier. of such identifier.
4. IANA Considerations 5. IANA Considerations
There are no IANA registries within this document. The RFC-Editor There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an can remove this section before publication of this document as an
RFC. RFC.
5. Security Considerations 6. Security Considerations
The method specified in this document results in IPv6 Interface The method specified in this document results in IPv6 Interface
Identifiers (and hence IPv6 addresses) that do not follow any Identifiers (and hence IPv6 addresses) that do not follow any
specific pattern. Thus, address-scanning attacks specific pattern. Thus, attacks that rely on predictable Interface
[I-D.ietf-opsec-ipv6-host-scanning] are mitigated. IDs (such as [I-D.ietf-opsec-ipv6-host-scanning]) are mitigated.
The method specified in this document neither mitigates nor The method specified in this document neither mitigates nor
exacerbates the security considerations for DHCPv6 discussed in exacerbates the security considerations for DHCPv6 discussed in
[RFC3315]. [RFC3315].
6. Acknowledgements 7. Acknowledgements
This document is based on [RFC7217], authored by Fernando Gont. This document is based on [RFC7217], authored by Fernando Gont.
The authors would like to thank Stephane Bortzmeyer, Tatuya Jinmei, The authors would like to thank Stephane Bortzmeyer, Tatuya Jinmei,
Andre Kostur, Tomek Mrugalski, Hosnieh Rafiee, Jean-Francois Andre Kostur, Tomek Mrugalski, Hosnieh Rafiee, Jean-Francois
Tremblay, Tina Tsou, and Bernie Volz, for providing valuable comments Tremblay, Tina Tsou, and Bernie Volz, for providing valuable comments
on earlier versions of this documents. on earlier versions of this documents.
The authors would like to thank Ted Lemon, who kindly answered some The authors would like to thank Ted Lemon, who kindly answered some
DHCPv6-related questions. DHCPv6-related questions.
7. References 8. References
7.1. Normative References 8.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC
5453, February 2009. 5453, February 2009.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, February 2014. Interface Identifiers", RFC 7136, February 2014.
7.2. Informative References 8.2. Informative References
[FIPS-SHS] [FIPS-SHS]
FIPS, , "Secure Hash Standard (SHS)", Federal Information FIPS, , "Secure Hash Standard (SHS)", Federal Information
Processing Standards Publication 180-4, March 2012, Processing Standards Publication 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
[I-D.ietf-6man-ipv6-address-generation-privacy] [I-D.ietf-6man-ipv6-address-generation-privacy]
Cooper, A., Gont, F., and D. Thaler, "Privacy Cooper, A., Gont, F., and D. Thaler, "Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
draft-ietf-6man-ipv6-address-generation-privacy-03 (work draft-ietf-6man-ipv6-address-generation-privacy-04 (work
in progress), January 2015. in progress), February 2015.
[I-D.ietf-opsec-ipv6-host-scanning] [I-D.ietf-opsec-ipv6-host-scanning]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", draft-ietf-opsec-ipv6-host-scanning-06 (work in Networks", draft-ietf-opsec-ipv6-host-scanning-06 (work in
progress), February 2015. progress), February 2015.
[IANA-RESERVED-IID] [IANA-RESERVED-IID]
Reserved IPv6 Interface Identifiers, , Reserved IPv6 Interface Identifiers, ,
"http://www.iana.org/assignments/ipv6-interface-ids/ "http://www.iana.org/assignments/ipv6-interface-ids/
ipv6-interface-ids.xml", . ipv6-interface-ids.xml".
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, March 2011. RFC 6151, March 2011.
[RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover [RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover
Requirements", RFC 7031, September 2013. Requirements", RFC 7031, September 2013.
 End of changes. 29 change blocks. 
81 lines changed or deleted 132 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/