Privacy Extensions for Stateless Address Autoconfiguration in IPv6
RFC 4941
Discuss
Yes
No Objection
Abstain
Note: This ballot was opened for revision 05 and is now closed.
(Bert Wijnen; former steering group member) 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.
(Allison Mankin; former steering group member) Yes
(Margaret Cullen; former steering group member) Yes
(Alex Zinin; former steering group member) No Objection
(Bill Fenner; former steering group member) (was Discuss) No Objection
Don't forget to put the "Obsoletes RFC 3041" metadata in the note to the RFC Editor.
(Brian Carpenter; former steering group member) No Objection
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.
(Cullen Jennings; former steering group member) (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).
(Dan Romascanu; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
Please delete sections 8 thru 11 prior to publication.
(Sam Hartman; former steering group member) No Objection
(Ted Hardie; former steering group member) (was Discuss) No Objection
(Scott Hollenbeck; former steering group member) Abstain
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.