Privacy Extensions for Stateless Address Autoconfiguration in IPv6
Note: This ballot was opened for revision 05 and is now closed.
(Bert Wijnen) Discuss
Discuss (2005-12-15 for -** No value found for 'p.get_dochistory.rev' **)
- 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 value found for 'p.get_dochistory.rev' **)
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
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
Please delete sections 8 thru 11 prior to publication.
(Cullen Jennings) (was Discuss) No Objection
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 value found for 'p.get_dochistory.rev' **)
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.