--- 1/draft-gont-dhc-stable-privacy-addresses-00.txt 2014-09-15 09:14:38.159261084 -0700 +++ 2/draft-gont-dhc-stable-privacy-addresses-01.txt 2014-09-15 09:14:38.179261558 -0700 @@ -1,47 +1,50 @@ Dynamic Host Configuration (dhc) F. Gont Internet-Draft SI6 Networks / UTN-FRH Intended status: Standards Track W. Liu -Expires: March 9, 2015 Huawei Technologies - September 5, 2014 +Expires: March 16, 2015 Huawei Technologies + September 12, 2014 A Method for Generating Semantically Opaque Interface Identifiers with Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - draft-gont-dhc-stable-privacy-addresses-00 + draft-gont-dhc-stable-privacy-addresses-01 Abstract - This document specifies a method for generating IPv6 Interface - Identifiers to be used by Dynamic Host Configuration Protocol for - IPv6 (DHCPv6) servers. This method results in stable addresses - within each subnet, even in the presence of multiple DHCPv6 servers - or even DHCPv6 server reinstallments. This method is a - DHCPv6-variant of the method specified in RFC 7217 for IPv6 Stateless - Address Autoconfiguration. + This document specifies a method 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. This method is a DHCPv6 server side algorithm, + that does not require any updates to the existing DHCPv6 + specifications. The aforementioned method results in stable + 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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -52,38 +55,43 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Method Specification . . . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Stable IPv6 addresses tend to simplify event logging, trouble- shooting, enforcement of access controls and quality of service, etc. However, there are a number of scenarios in which a host employing the DHCPv6 protocol [RFC3315] may be assigned different IPv6 addresses for the same interface within the same subnet over time. For example, this may happen when multiple servers operate on the same network to provide increased availability, but may also happen as a result of DHCPv6 server reinstallments and other scenarios. - This document specifies a method to be employed by DHCPv6 servers for - generating IPv6 addresses, with the following properties: + This document specifies a method 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 (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 the same network interface of the same client, even when different DHCPv6 servers (implementing this specification) are employed. o It must be difficult for an outsider to predict the IPv6 addresses that will be generated by the method specified in this document, even with knowledge of the IPv6 addresses generated for other nodes within the same network. @@ -109,21 +117,21 @@ Implementations conforming to this specification SHOULD provide the means for a system administrator to enable or disable the use of this algorithm for generating IPv6 addresses. Unless otherwise noted, all of the parameters included in the expression below MUST be included when generating an IPv6 address. 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: RID: Random (but stable) Identifier F(): A pseudorandom function (PRF) that MUST NOT be computable from the outside (without knowledge of the secret key). F() MUST also be difficult to reverse, such that it resists attempts to @@ -134,22 +142,30 @@ each of the function parameters. The default algorithm to be employed for F() SHOULD be SHA-1 [FIPS-SHS]. An implementation MAY provide the means for selecting other other algorithms (e.g., SHA-256) for F(). Note: MD5 [RFC1321] is considered unacceptable for F() [RFC6151]. |: An operator representing "concatenation". Prefix: - The prefix from which the DHCPv6 is assigning addresses (i.e., - the prefix representing the address pool). + A prefix that represents an IPv6 address pool from which the + 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: The DUID value contained in the Client Identifier option received in the client message. IAID: The IAID value contained in the IA_NA option received in the client message. Counter: @@ -252,20 +268,23 @@ [I-D.ietf-opsec-ipv6-host-scanning] are mitigated. The method specified in this document neither mitigates nor exacerbates the security considerations for DHCPv6 discussed in [RFC3315]. 6. Acknowledgements 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 DHCPv6-related questions. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.