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. Summary: ready with minor issues. This document defines the previously reserved IPv6 multicast scop value 3 to mean "realm-local scope". The intent appears to be that specifications about how to use IPv6 on top of the underlying link layer technology define the extent of realm-local scope. A potential minor security issue is whether a router that does not understand scop 3 addresses (as specified by this draft) and receives a packet with a scop 3 destination address will forward the packet more widely than it should, or otherwise behave unexpectedly. This could be a problem for some resource-constrained deployment scenarios envisioned for this specification. The Security Considerations section of this draft states "This document has no security considerations beyond those in RFC 4007 [RFC4007] and RFC 4291 [RFC4291]." I think this document potentially increases the security consequences of behavior that was previously unspecified by RFC 4007 and RFC 4291. RFC 4291 specifies the behavior of a node that receives a packet with a multicast destination address with scop values 0 or F, but not for scop 3. Packets with scop 0 destination addresses must be dropped, and packets with scope F addresses must be treated as if they had global (scop E) multicast addresses. I can find no such previous specification for behavior for scop 3 packets. This raises the question of how existing implementations would behave if they were to receive packets destined to an address of scop 3, and whether this poses any security exposure. A conservative implementation might drop the packets, or treat them as if they had scop 2 (link-local). The requirements on scope zone boundaries specified in Section 5 of RFC 4007 appear to make this latter behavior safe. On the other hand, Section 4 of this draft updates RFC 4007 to resolve an ambiguity about whether scope 3 is automatically or administratively configured. Existing text in RFC 4007 implies that scop 3 zone boundaries are administratively configured, while RFC 4291 implies that scop 4 (admin-local) is the smallest scope whose boundaries are administratively configured. I don't know whether existing implementation behavior creates any practical security impact from this ambiguity. Because one stated use for realm-local scope is for multicast traffic in mesh networks, which seem likely to be resource constrained (in power, bandwidth, latency, error rate, etc.), I think it would be useful to analyze the resource exhaustion or denial of service potential of mixed deployments, where some routers understand the newly specified behavior for scop 3 addresses and some do not. I'm willing to believe that the consequences are negligible. It would be helpful to have a summary of known or predicted behaviors of existing implementations regarding scop 3 addresses, along with some analysis of how acceptable the security consequences of these behaviors are.