Zero-Configuration Assignment of IPv6 Multicast Addresses

Marine networks contain a combination of sensors, controls, and displays. Installations vary widely depending on the design and intended purpose of the boat and the amount of redundancy required. Sensors on these networks can be a mix of low-cost, low-bandwidth devices, like temperature or fluid sensors, and high-bandwidth devices, like radar, sonar, and video cameras. In most cases these networks use a single subnet and therefore require layer-2 switches to be deployed. The latest marine industry standards require IPv6. The most optimal way to distribute sensor data to all displays on the network is multicast. However, use of traditional switches can be problematic when both high-bandwidth and low-bandwidth devices are installed. Low-bandwidth devices are commonly designed with a low-speed link to reduce cost, and the multicast stream from the high-bandwidth device can overwhelm this link. To solve this problem, the network requires switches with multicast snooping , which directs multicast streams only to the ports leading to devices that request the data. Low-end switch hardware at low price points do not support source-specific multicast, so the destination address is the only way to differentiate multicast streams. This presents several challenges. First, defining an industry standard set of pre-allocated addresses is not practical due to the wide variety of network designs. Users in the marine industry would not find static assignment to be acceptable. MADCAP could be used to dynamically assign addresses, but its reliance on a dedicated server results in a single point of failure for the system, which is not acceptable in the marine environment. The solution, proposed in this draft, is a decentralized, zero-configuration method for dynamically assigning multicast addresses. This document defines an extension to the multicast portion of the IPv6 addressing architecture . The current architecture does not account for potential address collisions when IPv6 multicast packets are transmitted on the data link layer. This extension defines a collision detection mechanism that utilizes Multicast DNS to distribute a database of dynamically assigned multicast Ethernet addresses. It also proposes a new table in the IANA IPv6 Multicast Address Space Registry based on amendments to . This will allow for different methods of dynamically allocating IPv6 multicast addresses to coexist on the same network.

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.

Link-scoped IPv6 multicast addresses are an effective way to dynamically allocate multicast addresses on the local link. Because this method utilizes SLAAC it is also a zero-configuration technology. However, according to , most switch vendors forward multicast traffic based only on the MAC address (see the results for Q2 and Q3). There is a problem when transmitting link-scoped IPv6 multicast addresses on Ethernet. According to , the destination multicast Ethernet address is generated by combining the hexadecimal value 3333 with the last four octets of the destination multicast IPv6 address. These last four octets correspond with the group ID in the link-scoped IPv6 multicast address, meaning that any two applications that happen to choose the same group ID will transmit using the same destination multicast Ethernet address. This prevents multicast snooping switches from directing traffic only to devices interested in the data, and may result in a low-bandwidth link being saturated by a high-bandwidth stream.

The primary goal is to define a zero-configuration method for dynamically assigning IPv6 multicast addresses and preventing collisions at the Ethernet layer. This method must allow for multiple streams to be transmitted from the same host by different applications that are not communicating through another channel. A secondary goal is to allow several methods for dynamically assigning IPv6 multicast addresses to coexist on the same network without user configuration. Advertising the data contained in each multicast stream is discussed in .

When an application is preparing to transmit a multicast stream it generates a link-scoped IPv6 multicast address . The Interface Identifier (IID) part of this address is taken from the intended source address for the multicast stream. The group ID is a random value in the range reserved for mDNS-based dynamic IPv6 multicast address allocation algorithms (see below). The application then calculates the multicast Ethernet address that will be used to transmit the data and generates a string akin to a reverse mapping domain using a new "eth-addr.arpa" special-use domain. For example, given a source address of FE80::A12:34FF:FE56:7890, the IPv6 multicast address may be FF32:00FF:A12:34FF:FE56:7890:CFED:2468, the multicast Ethernet address 33:33:CF:ED:24:68, and the string "8.6.4.2.d.e.f.c.3.3.3.3.eth-addr.arpa". The application then uses the mDNS probing algorithm described in to continuously query for a PTR record with the generated string for the name. If the probing algorithm completes without any conflict, then the application begins advertising its own PTR record using that name. The PTRDNAME field consists of a unique application identifier, in the form of a DNS label, 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. 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 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 at any point the query returns a result from a different host, then the application stops transmitting that multicast stream and start the process over using a different group ID. The host should monitor the bus for traffic that uses the same destination multicast Ethernet address, but a different destination multicast IPv6 address. If this is detected then the application acts as if the collision had been detected from the mDNS query. 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).

The special-use domain "eth-addr.arpa" should be registered in the .arpa registry (https://www.iana.org/domains/arpa) and the "Special-Use Domain Names" registry (https://www.iana.org/assignments/special-use-domain-names). IANA should create a new table in the IPv6 Multicast Address Space Registry that contains ranges for dynamic multicast group IDs and is based on the description in . The registry should initially contain the following entries:

`0x80000000`-`0xBFFFFFFF`	MADCAP
`0xC0000000`-`0xCFFFFFFF`	mDNS-based zero-configuration algorithm described above
`0xD0000000`-`0xFEFFFFFF`	Reserved for future zero-configuration algorithms
`0xFF000000`-`0xFFFFFFFF`	Solicited-node multicast addresses

This algorithm only works in environments where all hosts are cooperating. Malicious hosts could deny service by either repeatedly responding to queries for a given address or by flooding the network with traffic.

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