Zero-Configuration Assignment of IPv6 Multicast Addresses Using mDNS

includes a problem statement and requirements for a zero-configuration method for dynamically assigning multicast addresses. This document describes a process that fulfills these requirements by having applications randomly assign IPv6 multicast group IDs from a specified range and using mDNS to prevent collisions in both IPv6 and link-layer addresses. Note that DNS-based Service Discovery (DNS-SD) uses several different DNS resource record types, published using either Unicast or Multicast DNS, to facilitate service discovery. This document uses a single DNS resource record type (PTR), published using Multicast DNS (mDNS), to coordinate IPv6 multicast address assignment in a zero-configuration environment. The DNS resource records in this protocol may be published alongside records for other domain name services, such as DNS-SD, or they may be published alone. mDNS is used rather than a new protocol with the expectation that functionality for address assignment can be achieved using existing mDNS implementations. This protocol is well-suited for networks that rely on IPv6 multicast and already deploy mDNS.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

When an application is preparing to transmit a multicast stream, it SHALL first generate a random group ID in the range 0x90000000-0x9FFFFFFF. IANA is REQUESTED to assign this range from the "Dynamic Multicast Group IDs" registry (see ). The application SHALL then generate a link-scoped IPv6 multicast address by combining the group ID with the Interface Identifier (IID) of the intended source address for the multicast stream, according to the format given in . The application SHALL then calculate the corresponding multicast Ethernet address that will be used to transmit the data (see ). Once the multicast Ethernet address is determined, the application SHALL then use this to construct a domain name by encoding nibbles from the multicast Ethernet address as a sequence of lower-case hexadecimal digits, separated by dots, in reverse order, and ending with the suffix ".eth-addr.arpa" (a new domain in the .arpa registry). For example, given a source address of fe80::a12:34ff:fe56:7890, the IPv6 multicast address may be ff32:ff:a12:34ff:fe56:7890:9abc:def0, the group ID 9abc:def0, the multicast Ethernet address 33:33:9A:BC:DE:F0, and the resulting string is "0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa". Note that this is similar to how DNS resource records used for reverse mapping IPv6 addresses are created (see ). Once the domain name is created, the application SHALL then use the mDNS probing algorithm described in to continuously query for a PTR record with this domain name. If the probing algorithm completes without any conflict, then the application SHALL begin advertising its own unique PTR record using that name. The PTRDNAME field of this record SHALL consist of a unique application identifier, in the form of one or more DNS labels, followed by the device's host name (for example, "application.example.local."). Integrating a unique identifier in this manner allows for multiple applications to be on the same host. Note that A/AAAA records may also be published for this host name ("example.local."), though this is not a requirement for this design. Because this protocol is focused specifically on allocating IPv6 multicast addresses, resource records MUST be published using the IPv6 multicast address for mDNS. In order to be compatible with existing mDNS implementations, resource records MAY also be published using the IPv4 multicast address for mDNS. mDNS implementations used with this protocol MUST facilitate interaction between multiple applications using the same mDNS implementation, and with other mDNS implementations on the same host. This ensures that multiple applications that happen to generate the same group ID will detect this when probing and use a different group ID. Once the PTR record is advertised, the host MAY then begin transmitting multicast data using the generated address. The application SHALL retain the group ID value in persistent storage and use it the next time the multicast stream is transmitted. This allows the network to quickly settle on a configuration that will never have another collision as long as the network is unchanged. If a conflict is detected at any point, then the application SHALL stop transmitting that multicast stream and start the process over using a different group ID. As before, this new group ID is also retained in persistent storage, overwriting any group ID previously saved for this multicast stream. The host network stack may optionally monitor the network for traffic that uses the same destination multicast Ethernet address, but a different destination multicast IPv6 address. If this is detected, then the application SHALL respond the same as with a collision. While intended primarily for allocating IPv6 multicast addresses on the same subnet (link-local scope), the same technique could also apply to a larger network as long as mDNS traffic is routed between subnets (for any scope excluding global scope).

describes collisions occurring in the network infrastructure (for example, due to switch design). When an infrastructure component detects a collision it cannot resolve, it triggers a conflict with the application by publishing a veto record. A veto record is a unique PTR record using the string generated for the address as its name and the PTRDNAME field set to the string "veto", formatted as a DNS label. The veto record is published without probing. Applications SHALL respond to the conflict the same as to a collision, eventually resulting in a new group ID being acquired. As before, the application retains its new group ID in persistent storage, ensuring the same conflict is not repeated in the future.

The protocol can be extended across multiple subnets if PTR records are distributed between subnets (for example, by using an mDNS reflector or the Discovery Proxy described in ). Note that the stream MUST use a unicast-prefix based IPv6 multicast address (), as the link-scoped IPv6 multicast address used above is scoped to the local link. The protocol's reliance on cooperating hosts (see ) makes it unsuited for use on the global Internet. recommends Source-Specific Multicast in this environment.

contains a list of criteria to evaluate potential solutions. The following is an analysis of how this protocol satisfies the requirements listed in that document:

[REQ-1] Unique Address Assignment: Use of the protocol results in a unique address being assigned to the multicast group at both the network and link layers.
[REQ-2] Resilience to Single Points of Failure: The protocol uses mDNS, which uses a peer-to-peer communication model and so has no single points of failure, as long as network connectivity is not interrupted.
[REQ-3] Zero User Configuration: The protocol operates without requiring user or administrator configuration.
[REQ-4] Coexistence with Multicast Address Allocation Solutions: This document assigns a range of group IDs from the "Dynamic Multicast Group IDs" registry for use with the protocol, which allows the protocol to coexist with other multicast IP address allocation solutions (see ).
[REQ-5] Single-Subnet Operation: The protocol supports operation within a single IPv6 subnet.
[REQ-6] No External Connectivity: The protocol does not require Internet access or connectivity to external infrastructure.
[REQ-7] Supports Multiple Host Applications: Multiple applications on the same host are supported by 1) incorporating a unique application identifier into the PTR record's PTRDNAME field and 2) by requiring the mDNS implementation(s) on a host to facilitate interaction between those applications.
[REQ-8] Collision Detection and Resolution: The protocol includes a mechanism to detect and resolve multicast address collisions at both the network and link layers. See for additional discussion about detecting and resolving collisions after a network partition is repaired.

The following is an analysis of how this protocol satisfies the desirable characteristics listed in :

[CONS-1] Multi-Subnet Support: The protocol can operate across multiple subnets (see ).
[CONS-2] Standards Compatibility: The protocol uses existing protocols without requiring any changes.
[CONS-3] Cross-Platform Availability: The protocol uses mDNS, which is implemented on many host platforms and operating systems.
[CONS-4] Minimal Dependency on Manufacturing Data: The protocol does not rely on pre-loaded configuration or device-specific manufacturing data.
[CONS-5] Low Overhead: The protocol uses mDNS, which is designed to minimize the volume and frequency of network traffic generated during normal operation.
[CONS-6] Advertisement: This document does not prescribe any mechanism for advertising the IPv6 address used for the multicast stream. However, because the protocol already uses mDNS, a natural option for doing so would be to use DNS-SD () to advertise a "_udp" service and publish the address used for the multicast stream in a TXT record.
[CONS-7] Network Topology: Veto records ensure that the protocol works regardless of the underlying topology and adjacencies.

Because mDNS is designed to be a low-bandwidth protocol, it can take a signficant amount of time to detect a resource record collision after a network partition is repaired. This is not a concern on networks where all multicast streams are established before any likely partition event because all group IDs will have been selected and stored for future use. It is a greater concern on networks where multicast streams may be established at any time. Deployments on these networks may consider engaging supplemental detection and resolution mechanisms. Specifics of this functionality are left as a future enhancement.

IANA should allocate a block of group IDs from the "Dynamic Multicast Group IDs" registry in the "IPv6 Multicast Address Space" registry group that was created by . The range of this block should be 0x90000000-0x9FFFFFFF and the description should be the title of this document. The domain "eth-addr.arpa" should be registered in the .arpa registry (https://www.iana.org/domains/arpa). The usage should indicate that it is for mapping Ethernet addresses to local domain names and it should reference this document. The special-use domain "9.3.3.3.3.eth-addr.arpa." should be registered in the "Special-Use Domain Names" registry (https://www.iana.org/assignments/special-use-domain-names). This domain should not be delegated.

includes a list of questions that must be answered when reserving a new Special-Use Domain Name. The answers to these questions for the "9.3.3.3.3.eth-addr.arpa" Special-Use Domain, and any names falling within this domain, are as follows:

Users are free to use these names as they would for any other reverse-mapping domain. Because this mapping is closely-related to the local network, users SHOULD be aware that these names are likely to yield different results on different networks.
Application software SHOULD recognize these names as a reverse-mapping domain and MAY associate them with the protocol described in this document.
Name resolution APIs and libraries SHOULD recognize these names as being used exclusively with mDNS, and so SHOULD NOT send queries for these names to their configured unicast DNS server(s).
Caching DNS servers SHOULD recognize these names as being used exclusively with mDNS, SHOULD NOT attempt to look up resource records associated with these names, and SHOULD respond to any query with NXDOMAIN.
Authoritative DNS servers SHOULD recognize these names as being used exclusively with mDNS and SHOULD respond to any query with NXDOMAIN.
DNS server operators MUST NOT configure an authoritative DNS server to answer queries for these names.
DNS Registries/Registrars MUST NOT register 9.3.3.3.3.eth-addr.arpa names.

As with mDNS itself, this protocol only works in environments where all hosts are cooperating. Malicious hosts could deny service by repeatedly triggering address conflicts (for example, by publishing veto records).

Special thanks to the National Marine Electronics Association for their contributions in developing marine industry standards and their support for this work. Thanks also to the members of the PIM working group for their early brainstorming sessions and review of this draft, and to Esko Dijk for his review of the draft.