--- 1/draft-ietf-6man-stable-privacy-addresses-03.txt	2013-03-21 05:59:03.732076567 +0100
+++ 2/draft-ietf-6man-stable-privacy-addresses-04.txt	2013-03-21 05:59:03.756075991 +0100
@@ -1,19 +1,19 @@
 
 IPv6 maintenance Working Group (6man)                            F. Gont
 Internet-Draft                                    SI6 Networks / UTN-FRH
-Intended status: Standards Track                        January 27, 2013
-Expires: July 31, 2013
+Intended status: Standards Track                          March 21, 2013
+Expires: September 22, 2013
 
   A method for Generating Stable Privacy-Enhanced Addresses with IPv6
               Stateless Address Autoconfiguration (SLAAC)
-              draft-ietf-6man-stable-privacy-addresses-03
+              draft-ietf-6man-stable-privacy-addresses-04
 
 Abstract
 
    This document specifies a method for generating IPv6 Interface
    Identifiers to be used with IPv6 Stateless Address Autoconfiguration
    (SLAAC), such that addresses configured using this method are stable
    within each subnet, but the Interface Identifier changes when hosts
    move from one network to another.  The aforementioned method is meant
    to be an alternative to generating Interface Identifiers based on
    IEEE identifiers, such that the benefits of stable addresses can be
@@ -27,21 +27,21 @@
    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 July 31, 2013.
+   This Internet-Draft will expire on September 22, 2013.
 
 Copyright Notice
 
    Copyright (c) 2013 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
@@ -282,31 +282,28 @@
           non-volatile memory).  See Section 4 for additional details.
 
        secret_key:
           A secret key that is not known by the attacker.  The secret
           key MUST be initialized at system installation time to a
           pseudo-random number (see [RFC4086] for randomness
           requirements for security).  An implementation MAY provide the
           means for the user to change the secret key.
 
    2.  The Interface Identifier is finally obtained by taking the
-       leftmost 64 bits of the RID value computed in the previous step,
-       and setting bit 6 (the leftmost bit is numbered 0) to zero.  This
-       creates an interface identifier with the universal/local bit
-       indicating local significance only.  The resulting Interface
-       Identifier should be compared against the list of reserved
-       interface identifiers [IANA-RESERVED-IID], and to those interface
-       identifiers already employed in an address of the same network
-       interface and the same network prefix.  In the event that an
-       unacceptable identifier has been generated, this situation should
-       be handled in the same way as the case of duplicate addresses
-       (see Section 4).
+       leftmost 64 bits of the RID value computed in the previous step.
+       The resulting Interface Identifier should be compared against the
+       list of reserved interface identifiers [IANA-RESERVED-IID], and
+       against those interface identifiers already employed in an
+       address of the same network interface and the same network
+       prefix.  In the event that an unacceptable identifier has been
+       generated, this situation should be handled in the same way as
+       the case of duplicate addresses (see Section 4).
 
    This document does not require the use of any specific PRF for the
    function F() above, since the choice of such PRF is usually a trade-
    off between a number of properties (processing requirements, ease of
    implementation, possible intellectual property rights, etc.), and
    since the best possible choice for F() might be different for
    different types of devices (e.g. embedded systems vs. regular
    servers) and might possibly change over time.
 
    Note that the result of F() in the algorithm above is no more secure