Privacy Extensions for Stateless Address Autoconfiguration in IPv6
RFC 4941

Note: This ballot was opened for revision 05 and is now closed.

(Bert Wijnen) Discuss

Discuss (2005-12-15 for -)
- 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.

(Margaret Cullen) Yes

(Allison Mankin) Yes

(Brian Carpenter) No Objection

Comment (2005-12-15 for -)
No email
send info
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.

(Bill Fenner) (was Discuss) No Objection

Comment (2005-12-15)
No email
send info
Don't forget to put the "Obsoletes RFC 3041" metadata in the note to the RFC Editor.

(Ted Hardie) (was Discuss) No Objection

(Sam Hartman) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2005-12-13)
No email
send info
  Please delete sections 8 thru 11 prior to publication.

(Cullen Jennings) (was Discuss) No Objection

Comment (2006-10-09)
No email
send info
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).

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

Magnus Westerlund No Objection

(Alex Zinin) No Objection

(Scott Hollenbeck) Abstain

Comment (2005-12-14 for -)
No email
send info
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.