I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This draft is ready with comments/nits.

Comments
The document describes necessary mechanisms for OSPFv3 to be self-configuring in environments requiring such (e.g. IPv6 home networks).

A couple of things stood out to me.  First, I inferred from the document that the uniqueness of Router IDs is so within the context of the present deployment and not, for example, unique between domains.  This may be common knowledge in the world of OSPF, but wasn’t to me (at least not initially).  It could be good to add a sentence about the context of Router ID uniqueness early on in the document.

Also regarding uniqueness of the ID, Section 5, “OSPFv3 Router ID Selection”, indicates that a pseudo-random number SHOULD be used to derive the Router ID.  Later in that first paragraph: “The generation should be seeded with a variable that is likely to be unique in the applicable OSPFv3 router deployment.”  Should that “should” be “SHOULD”?

The document clearly recognizes the possibility for Router ID collisions, and there does not appear to be a need for a cryptographically sound pseudo-random number generation - just enough entropy to make the Router ID unique within the deployment domain, and the Router-Hardware-Fingerprint TLV (Section 7.2.2) is presented as being enough.

Because this document essentially explains the OSPFv3 defaults a router should have in order to support auto-configuration, I presumed that the security considerations provided in previous OSPFv3 documents would essentially be in effect here.  This isn’t explicitly stated in the Security Considerations section, but could be without harm, should they apply here.  The bottom line for me is that it seems that OSPFv3 auto-configuration favors usability over security, but without ignoring security entirely (e.g. “auto-configuration can also be combined with password configuration or future extensions for automatic pairing between devices.”).