Skip to main content

Privacy Extensions for Stateless Address Autoconfiguration in IPv6
RFC 4941

Revision differences

Document history

Date Rev. By Action
2020-01-21
05 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
05 (System) Notify list changed from ipv6-chairs@ietf.org, narten@raleigh.ibm.com, suresh.krishnan@ericsson.com, brian@innovationslab.net, richdr@microsoft.com to (None)
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Cullen Jennings
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Bill Fenner
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Ted Hardie
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2007-09-26
05 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-09-26
05 Amy Vezza [Note]: 'RFC 4941' added by Amy Vezza
2007-09-24
05 (System) RFC published
2006-11-15
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-11-04
05 Amy Vezza IESG state changed to Approved-announcement sent
2006-11-04
05 Amy Vezza IESG has approved the document
2006-11-04
05 Amy Vezza Closed "Approve" ballot
2006-11-04
05 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2006-11-01
05 Jari Arkko State Changes to IESG Evaluation::AD Followup from IESG Evaluation - Defer by Jari Arkko
2006-10-30
05 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings
2006-10-30
05 Cullen Jennings Any update on what the plan is to move forward on resolving the interoperability report issue?
2006-10-17
05 Bill Fenner [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Discuss by Bill Fenner
2006-10-09
05 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2006-10-09
05 (System) New version available: draft-ietf-ipv6-privacy-addrs-v2-05.txt
2006-10-09
05 Cullen Jennings [Ballot discuss]
I am not finding the interoperability report needed to advance this.
2006-10-09
05 Cullen Jennings
[Ballot discuss]
I'm sure I am behind the times and just not finding this, but  I am not finding the interoperability report needed to advance …
[Ballot discuss]
I'm sure I am behind the times and just not finding this, but  I am not finding the interoperability report needed to advance this.
2006-10-09
05 Cullen Jennings
[Ballot comment]
Authors sent me the following explanation of the algorithm which I found much easier to follow. You might want to consider adding something …
[Ballot comment]
Authors sent me the following explanation of the algorithm which I found much easier to follow. You might want to consider adding something like this in the early part of the security section.


It is not easy to predict the next address which will be used because the history value is not externally visible.

First the node generates a 128 bit MD5 hash, say RES, using a random initial value.

Let's assume a function FIRSTx(foo) which returns the first x bits of foo and LASTx(foo) which returns the last x bits of foo.

The algorithm described in the document uses FIRST64(RES) as the interface identifier(setting bit 6 to 0) and stores LAST64(RES) as the history value for the next iteration. Since LAST64(RES) is not cryptographically related to FIRST64(RES), it will not be possible to guess HASH(LAST64(RES)) knowing just FIRST64(RES).
2006-10-09
05 Cullen Jennings State Change Notice email list have been change to ipv6-chairs@tools.ietf.org, narten@raleigh.ibm.com, suresh.krishnan@ericsson.com, brian@innovationslab.net, richdr@microsoft.com from ipv6-chairs@tools.ietf.org
2006-10-09
05 Jari Arkko State Changes to IESG Evaluation - Defer from IESG Evaluation::Revised ID Needed by Jari Arkko
2006-08-25
05 Jari Arkko Some ongoing discussion on the IPv6 list about additional issues in the draft. This is likely to result in a need to revise.
2006-08-23
05 Jari Arkko State Change Notice email list have been change to ipv6-chairs@tools.ietf.org from bob.hinden@nokia.com, brian@innovationslab.net
2006-08-23
05 Jari Arkko [Note]: 'PROTO shepherd is Brian Haberman <brian@innovationslab.net>.' added by Jari Arkko
2006-08-15
05 Jari Arkko State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::External Party by Jari Arkko
2006-08-15
05 Jari Arkko
I reviewed the changes in a pre-version of draft -05. They looked good, but there was one editorial suggestion and one question. Expecting the authors …
I reviewed the changes in a pre-version of draft -05. They looked good, but there was one editorial suggestion and one question. Expecting the authors to fix/respond and resubmit. All discusses have been addressed as far as I can see, including Cullen's.
2006-08-08
05 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2006-07-30
05 Jari Arkko Implementation report for Linux (vs. Windows and FreeBSD) has been received and has been sent to the secretariat.
2006-07-30
05 Jari Arkko [Note]: 'PROTO shepherd is Brian Haberman <brian@innovationslab.net>.' added by Jari Arkko
2006-07-30
05 Jari Arkko 3/9/06: Needs an updated implementation report before it can proceed.
2006-07-11
05 Russ Housley
[Ballot discuss]
Section 3.2.1 says:
  >
  > MD5 was chosen for convenience, and because its particular properties
  > were adequate to produce …
[Ballot discuss]
Section 3.2.1 says:
  >
  > MD5 was chosen for convenience, and because its particular properties
  > were adequate to produce the desired level of randomization.  IPv6
  > nodes are already required to implement MD5 as part of IPsec [IPSEC],
  > thus the code will already be present on IPv6 machines.
  >
  I see no requirement for MD5 in IPsec.  I have agreed to the following text
  on 11-July-2006 as a solution to this concern:
  >
  > MD5 was chosen for convenience, and because its particular properties
  > were adequate to produce the desired level of randomization.  The node
  > MAY use another algorithm instead of MD5 to produce the random
  > interface identifier.
2006-06-05
05 Jari Arkko 5/6/06: Pinged chairs about the status.
2006-05-31
05 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund by Magnus Westerlund
2006-05-31
05 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by Dan Romascanu
2006-05-27
05 Cullen Jennings
[Ballot discuss]
Ok - I am going to enter a discuss here where I am 99% sure the answer is going to be Cullen you …
[Ballot discuss]
Ok - I am going to enter a discuss here where I am 99% sure the answer is going to be Cullen you are totally confused, go read the document but if that is the case it will be easy to clear.

In section 3, point #3, we have as a requirement that if an attacker knows the current address, it is not easy to predict a future address. I agree this is the fundamental requirement. However I'm not sure I see how the history algorithm in section 3.2.1 does this. It seems that if you use address X, then X gets stored in the history. The next address will used will be MD5(X). It seems the attacker can predict this. Now I am sure that I must just be confused on what is happening here so straighten me out.

The storage algorithm never seems to add any new randomness in and the initially randomness has high odds of being really crappy because the entropy available to many devices the first time they boot is really low and often has bad problems  based on implementers making very bad assumptions about what is random in systems that are basically highly deterministic by nature.

I'm sure I am behind the times and just not finding this, but  I am not finding the interoperability report needed to advance this.
2006-05-27
05 Cullen Jennings
[Ballot discuss]
Ok - I am going to enter a discuss here where I am 99% sure the answer is going to be Cullen you …
[Ballot discuss]
Ok - I am going to enter a discuss here where I am 99% sure the answer is going to be Cullen you are totally confused, go read the document but if that is the case it will be easy to clear.

In section 3, point #3, we have as a requirement that if an attacker knows the current address, it is not easy to predict a future address. I agree this is the fundamental requirement. However I'm not sure I see how the history algorithm in section 3.2.1 does this. It seems that if you use address X, then X gets stored in the history. The next address will used will be MD5(X). It seems the attacker can predict this. Now I am sure that I must just be confused on what is happening here so straighten me out.

The storage algorithm never seems to add any new randomness in and the initially randomness has high odds of being really crappy because the entropy available to many devices the first time they boot is really low and often has bad problems  based on implementers making very bad assumptions about what is random in systems that are basically highly deterministic by nature.

I'm sure I am behind the times and just not finding this, but  I am not finding the interoperability report needed to advance this.
2006-05-27
05 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Discuss from Undefined by Cullen Jennings
2006-05-25
05 Cullen Jennings [Ballot Position Update] New position, Undefined, has been recorded for Cullen Jennings by Cullen Jennings
2006-03-25
05 Margaret Cullen Shepherding AD has been changed to Jari Arkko from Margaret Wasserman
2006-03-09
05 Margaret Cullen State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Margaret Wasserman
2006-03-09
05 Margaret Cullen [Note]: 'PROTO shepherd is Brian Haberman <brian@innovationslab.net>. 3/9/06: Needs an updated implementation report before it can proceed.' added by Margaret Wasserman
2005-12-16
05 (System) Removed from agenda for telechat - 2005-12-15
2005-12-15
05 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2005-12-15
05 (System) [Ballot Position Update] New position, yes, has been recorded for Allison Mankin by IESG Secretary
2005-12-15
05 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2005-12-15
05 Ted Hardie
[Ballot discuss]
Update:  The KAME and Windows implementation reports do not appear to cover quite the same ground.  There is at least one section (3.2) …
[Ballot discuss]
Update:  The KAME and Windows implementation reports do not appear to cover quite the same ground.  There is at least one section (3.2) for which implementation is not in both.

In general, I think we need an interoperability report bundling these implementation reports, so that we have someone saying that the two implementations interoperate and how that interoperability was determined.

old:
As Scott points out in his comments, this report only has a single implementation report, Dave Thaler's from Microsoft.  I think we need two for the implementation report to be sufficient for DS.
2005-12-15
05 Brian Carpenter
[Ballot comment]
Fully agree with Scott and Ted that we lack a sufficient interop report. It seems that the KAME FreeBSD report was not posted. …
[Ballot comment]
Fully agree with Scott and Ted that we lack a sufficient interop report. It seems that the KAME FreeBSD report was not posted. Its core:

      A. Lifetime Management (Section 3.4)
          Verified proper Lifetime Management behavior with Router
          Advertisements generated by Cisco and Juniper IPv6 routers.

      B. DAD Operation (Section 3.3)
          Verified the creation of a temporary address (which is to be
          unique on the link) and the performance of DAD on that address
          without disrupting other implementations.  This was tested
          with various implementations from different origins including
          Linux and Solaris 10.
2005-12-15
05 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2005-12-15
05 Bert Wijnen
[Ballot discuss]
- I agree with other IESG members, that the single implementation report
  is not sufficient to show INTEROPERABILITY between multiple (at least …
[Ballot discuss]
- I agree with other IESG members, that the single implementation report
  is not sufficient to show INTEROPERABILITY between multiple (at least 2)
  genetically independent implementations

- I think it should be made clear that this doc obsoletes RFC3041

- I see that several "additions" were made (section 7) on top of what
  is in RFC3041. So does that allow to advance to DS, or would it be
  better to recycle at PS. Specifically since we only see a report
  of a single implementation.
2005-12-15
05 Bert Wijnen [Ballot Position Update] New position, Discuss, has been recorded for Bert Wijnen by Bert Wijnen
2005-12-15
05 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2005-12-15
05 Brian Carpenter [Ballot comment]
Fully agree with Scott and Ted that we lack a sufficient interop report.
2005-12-15
05 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2005-12-15
05 Bill Fenner [Ballot comment]
Don't forget to put the "Obsoletes RFC 3041" metadata in the note to the RFC Editor.
2005-12-15
05 Bill Fenner
[Ballot discuss]
Section 6 ends with a mini "Open Issues" section that wasn't in RFC 3041.  I don't think a Draft Standard should have …
[Ballot discuss]
Section 6 ends with a mini "Open Issues" section that wasn't in RFC 3041.  I don't think a Draft Standard should have new open issues.
2005-12-15
05 Bill Fenner [Ballot Position Update] New position, Discuss, has been recorded for Bill Fenner by Bill Fenner
2005-12-14
05 Ted Hardie
[Ballot discuss]
As Scott points out in his comments, this report only has a single implementation report, Dave Thaler's from Microsoft.  I think we need …
[Ballot discuss]
As Scott points out in his comments, this report only has a single implementation report, Dave Thaler's from Microsoft.  I think we need two for the implementation report to be sufficient for DS.
2005-12-14
05 Ted Hardie [Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Ted Hardie
2005-12-14
05 Scott Hollenbeck
[Ballot comment]
Implementation report:
http://www.ietf.org/IESG/Implementations/implementation-rfc-3041.txt

This report only describes one implementation.  A description of how this implementation interoperates with a second independently developed implementation is …
[Ballot comment]
Implementation report:
http://www.ietf.org/IESG/Implementations/implementation-rfc-3041.txt

This report only describes one implementation.  A description of how this implementation interoperates with a second independently developed implementation is needed.

Is this document intended to obsolete RFC 3041?  Section 7 makes it appear so, but some text in the front page header and the abstract would make the situation more obvious if that's the intention.
2005-12-14
05 Scott Hollenbeck [Ballot Position Update] New position, Abstain, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-12-13
05 Russ Housley [Ballot comment]
Please delete sections 8 thru 11 prior to publication.
2005-12-13
05 Russ Housley
[Ballot discuss]
Section 3.2.1 says:
  >
  > MD5 was chosen for convenience, and because its particular properties
  > were adequate to produce …
[Ballot discuss]
Section 3.2.1 says:
  >
  > MD5 was chosen for convenience, and because its particular properties
  > were adequate to produce the desired level of randomization.  IPv6
  > nodes are already required to implement MD5 as part of IPsec [IPSEC],
  > thus the code will already be present on IPv6 machines.
  >
  I see no requirement for MD5 in RFC 2401.  I do not see one in the
  soon-to-be-published 2401bis either.  I also looked in
  draft-ietf-ipsec-esp-ah-algorithms-02, and all MD5-related algorithms
  are MAY implement.  I do not see a problem with MD5 in this case, but
  I think this rationale is incorrect today.  It may have been correct
  when RFC 3041 was published.
2005-12-13
05 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley
2005-12-13
05 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2005-12-12
05 Margaret Cullen [Note]: 'PROTO shepherd is Brian Haberman <brian@innovationslab.net>.' added by Margaret Wasserman
2005-12-08
05 Margaret Cullen State Changes to IESG Evaluation from AD is watching by Margaret Wasserman
2005-12-08
05 Margaret Cullen Placed on agenda for telechat - 2005-12-15 by Margaret Wasserman
2005-12-08
05 Margaret Cullen Note field has been cleared by Margaret Wasserman
2005-12-07
05 Dinara Suleymanova State Changes to AD is watching from Dead by Dinara Suleymanova
2005-12-07
05 (System) This document has been resurrected.
2005-12-03
05 (System) State Changes to Dead from AD is watching by system
2005-12-03
05 (System) Document has expired
2005-09-21
05 Michelle Cotton IANA Comments:
NO IANA Considerations section.
We understand this document to have NO IANA Actions.
2005-08-15
05 Margaret Cullen Removed from agenda for telechat - 2005-08-18 by Margaret Wasserman
2005-08-15
05 Margaret Cullen State Changes to AD is watching from IESG Evaluation by Margaret Wasserman
2005-08-15
05 Margaret Cullen
[Note]: 'Back to the WG for clarification on whether this should be published as PS or DS (which would require an interoperability report).' added by …
[Note]: 'Back to the WG for clarification on whether this should be published as PS or DS (which would require an interoperability report).' added by Margaret Wasserman
2005-08-10
05 Margaret Cullen [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman
2005-08-10
05 Margaret Cullen Ballot has been issued by Margaret Wasserman
2005-08-10
05 Margaret Cullen Created "Approve" ballot
2005-08-10
05 Margaret Cullen State Changes to IESG Evaluation from Waiting for Writeup by Margaret Wasserman
2005-08-10
05 Margaret Cullen Placed on agenda for telechat - 2005-08-18 by Margaret Wasserman
2005-08-01
05 (System) State has been changed to Waiting for Writeup from In Last Call by system
2005-07-18
05 Amy Vezza Last call sent
2005-07-18
05 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2005-07-17
05 Margaret Cullen State Changes to Last Call Requested from AD Evaluation::AD Followup by Margaret Wasserman
2005-07-17
05 Margaret Cullen Last Call was requested by Margaret Wasserman
2005-07-17
05 (System) Ballot writeup text was added
2005-07-17
05 (System) Last call text was added
2005-07-17
05 (System) Ballot approval text was added
2005-07-17
05 Margaret Cullen Note field has been cleared by Margaret Wasserman
2005-05-25
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-05-25
04 (System) New version available: draft-ietf-ipv6-privacy-addrs-v2-04.txt
2005-05-22
05 Margaret Cullen
More on AD Review Comments:

Date: Fri, 13 May 2005 13:50:39 -0400
To: Suresh Krishnan <suresh.krishnan@ericsson.ca>
From: Margaret Wasserman <margaret@thingmagic.com>
Cc: …
More on AD Review Comments:

Date: Fri, 13 May 2005 13:50:39 -0400
To: Suresh Krishnan <suresh.krishnan@ericsson.ca>
From: Margaret Wasserman <margaret@thingmagic.com>
Cc: ipv6@ietf.org
Subject: Re: AD Review comments on draft-ietf-ipv6-privacy-addrs-v2-03

At 10:15 AM -0400 5/11/05, Suresh Krishnan wrote:
>>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
>>      1.1  Problem Statement  . . . . . . . . . . . . . . . . . . . .  5
>>      1.2  Conventions used in this document  . . . . . . . . . . . .  5
>>
>>>>  Why is the RFC 2119 section inside the problem statement?
>
>It is just another sub section under introduction to the document and is not under the problem statement. I can move this to a separate section if you feel strongly about this.

Oh, okay...  I viewed the Problem Statement and the Background both as parts of the problem statement.  Maybe if you just switched the order of 1.1 and 1.2 (so the RFC 2119 language comes first), that would be better.  Or, just ignore this issue, as it is purely editorial.

>>    2.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  6
>>      2.1  Extended Use of the Same Identifier  . . . . . . . . . . .  6
>>      2.2  Address Usage in IPv4 Today  . . . . . . . . . . . . . . .  7
>>      2.3  The Concern With IPv6 Addresses  . . . . . . . . . . . . .  8
>>      2.4  Possible Approaches  . . . . . . . . . . . . . . . . . . .  9
>>
>>>>  Is section 2 supposed to be part of the problem statement?
>
>The problem statement is a concise description of the threat model we are defending against. Section 2 is a much more detailed study of the problems involved. The problem statement was created to provide the reader with some context as to why the document is needed. So the problem statement is a summary of sorts of section 2.

Okay.

>>  3.  Protocol Description
>>
>>    The goal of this section is to define procedures that:
>>
>>    1.  Do not result in any changes to the basic behavior of addresses
>>        generated via stateless address autoconfiguration [ADDRCONF].
>>    2.  Create additional global scope addresses based on a random
>>        interface identifier for use with global scope addresses.
>>
>>>>  What is meant by "for use with global addresses"?  is this intended
>>    to be a restriction on how/when privacy addresses can be used?
>
>This is not an intended restriction. I can reword it to read
>
>"2. Create additional addresses based on a random interface identifier for
>    the purpose of initiating outgoing sessions"
>
>instead of
>
>"2. Create additional global scope addresses based on a random
>    interface identifier for use with global scope addresses.Such
>    addresses would be used to initiate outgoing sessions."
>
>Does that sound OK?

Yes, that is better.

>>  3.1  Assumptions
>>
>>    The following algorithm assumes that each interface maintains an
>>    associated randomized interface identifier.  When temporary addresses
>>    are generated, the current value of the associated randomized
>>    interface identifier is used.  The actual value of the identifier
>>    changes over time as described below, but the same identifier can be
>>    used to generate more than one temporary address.
>>
>>    The algorithm also assumes that for a given temporary address, an
>>    implementation can determine the prefix from which it was generated.
>>    When a temporary address is deprecated, a new temporary address is
>>    generated.  The specific valid and preferred lifetimes for the new
>>    address are dependent on the corresponding lifetime values set for
>>    the prefix from which it was generated.
>>
>>>>  These two paragraphs are confusing to me.  The node maintains a
>>    random IID from which multiple addresses can be generated of the
>>    form <prefix, IID>, right?  These addresses will become deprecated
>>    when their lifetime expires, and new addresses will be generated.
>>    The implementation keeps track of what prefix was used to generate
>>    the addres and generates a new address for that prefix, right?
>>    Does it also need to generate a new random IID when this happens?
>>    In other words, is there anything in this mechanism that prevents
>>    generating the same privacy address again on the same interface
>>    using the same prefix and the same random IID (if it hasn't expired
>>    yet)?
>
>The mechanism certainly allows this behavior but it kind of defeats the purpose(to not have a stable interface identifier). The requirement to change the random interface identifier is a SHOULD and is described in section 3.5
>
>" Nodes following this specification SHOULD generate new temporary
>  addresses on a periodic basis.  This can be achieved automatically by
>  generating a new randomized interface identifier at least once every
>  (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR) time units."
>
>If you think this is should be a stronger requirement I can change it to a MUST at the cost of breaking backward compatibility. Let me know what you prefer.

The SHOULD is fine, but perhaps you could change the first paragraph of section 3.1 to read:

  The following algorithm assumes that each interface maintains an
  associated randomized interface identifier.  When temporary addresses
  are generated, the current value of the associated randomized
  interface identifier is used.  While the same identifier can be used to
  create more than one temporary address, the value SHOULD change
  over time as described in section 3.5.

This would make it clearer that a person should look at section 3.5 to understand how the identifier will change over time.

Margaret





--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
2005-05-22
05 Margaret Cullen [Note]: 'Waiting for (minor) document updates to address AD Review comments (see below).' added by Margaret Wasserman
2005-05-22
05 Margaret Cullen
AD Review comments sent to IPv6 WG:

To: ipv6@ietf.org
From: Margaret Wasserman <margaret@thingmagic.com>
Subject: AD Review comments on draft-ietf-ipv6-privacy-addrs-v2-03
Cc:

Hi All,

I …
AD Review comments sent to IPv6 WG:

To: ipv6@ietf.org
From: Margaret Wasserman <margaret@thingmagic.com>
Subject: AD Review comments on draft-ietf-ipv6-privacy-addrs-v2-03
Cc:

Hi All,

I have a few AD Review comments on draft-ietf-ipv6-privacy-addrs-v2-03 that I would like to have resolved before I send this document to IETF LC.  I've included those comments below.

Brian and Bob, the tracker indicates that this document is intended for publication as a Draft Standard, however RFC 3041 is currently at PS, and this document seems to contain some changes to the specification that would impact implementations (such as the requirement to perform DAD on all generated addresses).  Is the tracker state correct?  If so, what is the rationale for publishing this document at DS?

Thanks,
Margaret

>> I think that sometihng went wrong with the structure of this document:

Table of Contents

  1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
    1.1  Problem Statement  . . . . . . . . . . . . . . . . . . . .  5
    1.2  Conventions used in this document  . . . . . . . . . . . .  5

>> Why is the RFC 2119 section inside the problem statement?

  2.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  6
    2.1  Extended Use of the Same Identifier  . . . . . . . . . . .  6
    2.2  Address Usage in IPv4 Today  . . . . . . . . . . . . . . .  7
    2.3  The Concern With IPv6 Addresses  . . . . . . . . . . . . .  8
    2.4  Possible Approaches  . . . . . . . . . . . . . . . . . . .  9

>> Is section 2 supposed to be part of the problem statement?

3.  Protocol Description

  The goal of this section is to define procedures that:

  1.  Do not result in any changes to the basic behavior of addresses
      generated via stateless address autoconfiguration [ADDRCONF].
  2.  Create additional global scope addresses based on a random
      interface identifier for use with global scope addresses.

>> What is meant by "for use with global addresses"?  is this intended

  to be a restriction on how/when privacy addresses can be used?

3.1  Assumptions

  The following algorithm assumes that each interface maintains an
  associated randomized interface identifier.  When temporary addresses
  are generated, the current value of the associated randomized
  interface identifier is used.  The actual value of the identifier
  changes over time as described below, but the same identifier can be
  used to generate more than one temporary address.

  The algorithm also assumes that for a given temporary address, an
  implementation can determine the prefix from which it was generated.
  When a temporary address is deprecated, a new temporary address is
  generated.  The specific valid and preferred lifetimes for the new
  address are dependent on the corresponding lifetime values set for
  the prefix from which it was generated.

>> These two paragraphs are confusing to me.  The node maintains a

  random IID from which multiple addresses can be generated of the
  form <prefix, IID>, right?  These addresses will become deprecated
  when their lifetime expires, and new addresses will be generated.
  The implementation keeps track of what prefix was used to generate
  the addres and generates a new address for that prefix, right?
  Does it also need to generate a new random IID when this happens?
  In other words, is there anything in this mechanism that prevents
  generating the same privacy address again on the same interface
  using the same prefix and the same random IID (if it hasn't expired
  yet)?
2005-05-10
05 Margaret Cullen State Changes to AD Evaluation::Revised ID Needed from Publication Requested by Margaret Wasserman
2005-04-19
05 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2005-04-05
03 (System) New version available: draft-ietf-ipv6-privacy-addrs-v2-03.txt
2004-12-28
02 (System) New version available: draft-ietf-ipv6-privacy-addrs-v2-02.txt
2004-10-25
01 (System) New version available: draft-ietf-ipv6-privacy-addrs-v2-01.txt
2004-09-22
00 (System) New version available: draft-ietf-ipv6-privacy-addrs-v2-00.txt