draft-gont-dhc-stable-privacy-addresses-00.txt   draft-gont-dhc-stable-privacy-addresses-01.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: March 9, 2015 Huawei Technologies Expires: March 16, 2015 Huawei Technologies
September 5, 2014 September 12, 2014
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-gont-dhc-stable-privacy-addresses-00 draft-gont-dhc-stable-privacy-addresses-01
Abstract Abstract
This document specifies a method for generating IPv6 Interface This document specifies a method for selecting IPv6 Interface
Identifiers to be used by Dynamic Host Configuration Protocol for Identifiers, to be employed by Dynamic Host Configuration Protocol
IPv6 (DHCPv6) servers. This method results in stable addresses for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses
within each subnet, even in the presence of multiple DHCPv6 servers to DHCPv6 clients. This method is a DHCPv6 server side algorithm,
or even DHCPv6 server reinstallments. This method is a that does not require any updates to the existing DHCPv6
DHCPv6-variant of the method specified in RFC 7217 for IPv6 Stateless specifications. The aforementioned method results in stable
Address Autoconfiguration. addresses within each subnet, even in the presence of multiple DHCPv6
servers or even DHCPv6 server reinstallments. It is a DHCPv6-variant
of the method specified in RFC 7217 for IPv6 Stateless Address
Autoconfiguration.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 March 9, 2015. This Internet-Draft will expire on March 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 17 skipping to change at page 2, line 20
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. Method Specification . . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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
as a result of DHCPv6 server reinstallments and other scenarios. as a result of DHCPv6 server reinstallments and other scenarios.
This document specifies a method to be employed by DHCPv6 servers for This document specifies a method for selecting IPv6 Interface
generating IPv6 addresses, with the following properties: Identifiers, to be employed by Dynamic Host Configuration Protocol
for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses
to DHCPv6 clients (i.e., to be employed with IA_NA options). This
method is a DHCPv6 server side algorithm, that does not require any
updates to the existing DHCPv6 specifications. The aforementioned
method has the following properties:
o The resulting IPv6 addresses remain stable within each subnet for o The resulting IPv6 addresses remain stable within each subnet for
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 It must be difficult for an outsider to predict the IPv6 addresses o It must be difficult for an outsider to predict the IPv6 addresses
that will be generated by the method specified in this document, that will be generated by the method specified in this document,
even with knowledge of the IPv6 addresses generated for other even with knowledge of the IPv6 addresses generated for other
nodes within the same network. nodes within the same network.
skipping to change at page 3, line 26 skipping to change at page 3, line 34
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.
Unless otherwise noted, all of the parameters included in the Unless otherwise noted, all of the parameters included in the
expression below MUST be included when generating an IPv6 address. expression below MUST be included when generating an IPv6 address.
1. Compute a random (but stable) identifier with the expression: 1. Compute a random (but stable) identifier with the expression:
RID = F(Prefix | Client_DUID | IA_NA | Counter | secret_key) RID = F(Prefix | Client_DUID | IAID | 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
skipping to change at page 3, line 51 skipping to change at page 4, line 11
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].
|: |:
An operator representing "concatenation". An operator representing "concatenation".
Prefix: Prefix:
The prefix from which the DHCPv6 is assigning addresses (i.e., A prefix that represents an IPv6 address pool from which the
the prefix representing the address pool). DHCPv6 server will assign addresses. That is, this algorithm
REQUIRES that the DHCPv6 server manages all the IPv6 address
space within a specified prefix (as opposed to, e.g., an
address range that cannot be represented with a prefix
notation) and that it can be configured with such a prefix.
If multiple servers operate on the same network to provide
increased availability, all such DHCPv6 servers MUST be
configured with the same Prefix. 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 client message. received in the client message.
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. client message.
Counter: Counter:
skipping to change at page 6, line 26 skipping to change at page 6, line 43
[I-D.ietf-opsec-ipv6-host-scanning] are mitigated. [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 6. 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 Tatuya Jinmei for providing valuable
comments 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 7. References
7.1. Normative References 7.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.
 End of changes. 10 change blocks. 
19 lines changed or deleted 38 lines changed or added

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