Summary

  • On 22 September the IESG opened Last Call on revision 12 of a proposed zero-configuration IPv6 multicast address assignment standard. Comments are due 6 October; the draft is not an approved RFC.
  • An application chooses a group ID, probes an mDNS PTR name and treats the absence of a conflict as permission to proceed. Host or network filtering can make a conflicting assignment invisible.
  • The draft says collisions remain unlikely in most networks. This is a conditional coordination risk, not a reported failure or evidence that an attack is normally practical.

The decision point in the proposed allocator is not a central registry entry. It is a pause after an mDNS probe. If no one answers with a conflict, the application may announce its chosen multicast address. That silence is meaningful only if the devices that could object are able to receive the probe and return their records.

Revision 12, now in IESG Last Call, selects an IPv6 multicast group ID from a specified range and derives an Ethernet multicast address. The application constructs a PTR record under the proposed special-use 9.3.3.3.3.eth-addr.arpa domain, probes, announces and keeps a query running to notice later conflicts. If one is found, the loser stops its stream and chooses a new ID. The domain reservation and protocol status remain proposed, not completed assignments or an approved standard.

The draft names its dependency “implicit availability”: an applicant assumes an address is free when it hears no indication otherwise. It expressly warns that filtering mDNS traffic by a host or the network prevents applications from coordinating and may result in collisions. Removing an allocator therefore does not remove control over allocation evidence. A local administrator's filtering policy can determine which devices can hear a claim and which can contest it.

This is not an allegation that today's networks are suffering widespread collisions. The security discussion says the probability is already low in most networks and that mDNS filtering is therefore generally not a practical attack. The draft also assumes cooperative hosts. Its partition-repair section identifies another bounded limit: when parts of a network rejoin, mDNS can take significant time to detect a conflict, particularly if streams are created at any time. That is a secondary timing issue, not the same question as whether the probe was filtered in the first place.

The IESG asked for Last Call comments on 22 September, seeking Proposed Standard status by the ordinary review process; the deadline is 6 October. The question for a prospective operator is narrow but consequential: does the intended network carry the PTR probes, announcements and conflict responses between all devices that share the allocation space? A protocol rule can be minimal; its visibility condition cannot be wished away.

Sources