Zero-Configuration Assignment of IPv6 Multicast Addresses Using mDNS

Abstract

This document describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses that are unique at the link-layer. Applications randomly assign multicast group IDs from a specified range and prevent collisions by using Multicast DNS (mDNS) to publish resource records under a new "eth-addr.arpa" domain. This protocol satisfies all of the requirements and most of the desired characteristics listed in RFC 10019.¶

1. Introduction

[RFC10019] 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 [RFC6762] to prevent collisions in both IPv6 and link-layer addresses.¶

Note that DNS-based Service Discovery (DNS-SD) [RFC6763] 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.¶

The protocol described in this document is well-suited for networks that rely on IPv6 multicast and already deploy mDNS. This document makes IANA assignments for use on Ethernet and other protocols based on the IEEE 802 architecture. It may be adapted for use with other link layers, but that is outside the scope of this document.¶

As mentioned in [RFC6762], Section 21, mDNS is an algorithm that assumes cooperating participants. Due to its reliance on mDNS, this assumption applies to the protocol described in this document as well.¶

2. Procedure

This section specifies how an application dynamically generates an IPv6 multicast address, uses mDNS to coordinate use of that address with other applications on the network, and begins transmitting its multicast stream.¶

Because this protocol is focused specifically on allocating IPv6 multicast addresses, applications MUST send and receive mDNS messages using the IPv6 multicast address for mDNS (ff02::fb). In order to be compatible with existing mDNS implementations that require IPv4, applications MAY also send and receive mDNS messages using the IPv4 multicast address for mDNS (224.0.0.251). These addresses are documented in [RFC6762], Section 22.¶

mDNS implementations used with this protocol MUST coordinate with all applications using the same mDNS implementation, as well as with other mDNS implementations running on the same host. Such coordination ensures that conflicts arising from independently generated, identical group IDs are detected during the probing phase, allowing the affected applications to select alternate group IDs. Note that coordination between mDNS implementations running on the same host tends to happen naturally if transmitted multicast packets are looped back into the receive pipeline.¶

The process an application uses from initialization to transmitting a multicast stream is divided into a series of steps, outlined below.¶

6. Implementation Status

Note to RFC Editor: please remove this entire section before publication, as well as the reference to [RFC7942].¶

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶

According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶

A prototype for Linux using Avahi is available at <https://github.com/nkarstens/mdns-zeroconf-mcast/>. The main program in this repository allocates a single IPv6 multicast address from a specified group ID. The repository also contains a README with instructions on how to simulate a network partition.¶

This technology has been implemented in production in Garmin's GPSMAP 9000 series of marine multifunction displays.¶

7. Operational Considerations

Scalability of mDNS is an area of ongoing research and improvement ([RFC7558]). The protocol described in this document is subject to similar constraints. Under normal operating conditions, mDNS traffic is expected to grow linearly with the number of multicast streams.¶

The protocol uses implicit availability: if an application does not receive any indication that an address is in use, then it assumes that the address is available for its own use. Because this coordination occurs using mDNS, any filtering of mDNS traffic by the host or network would prevent applications from coordinating use of multicast addresses. This may result in address collisions.¶

Applications SHOULD keep timestamped logs of the following events to help troubleshoot issues with the protocol:¶

• Selected group ID (Section 2.1)¶
• Generated address (Section 2.2)¶
• Conflicts encountered during probing (Section 2.5)¶
• Conflicts detected after announcing (Section 2.7)¶
• Multicast stream transmission (Section 2.8)¶

Although Section 2.9 REQUIRES maintaining a persistent state, this functionality is nonetheless an optimization. The protocol is resilient to cases where none of the applications begin with persistent state (due to initial startup or clearing memory) and also to cases where all of the applications begin with the same persistent state (due to cloning a configuration). Although some of these cases do increase the likelihood that applications will experience a collision, the network will eventually reach a steady state. As such, operators have flexibility to determine when the expected behavior is to discard the persistent state and start over.¶

When a collision occurs, Section 2.7 REQUIRES applications to cease transmitting until a new address is acquired. This process results in a brief pause in the multicast stream.¶

This document does not specify a YANG model due to the decentralized, zero-configuration nature of the protocol.¶

9. References

Appendix A. Example mDNS Messages

This section illustrates the DNS message fields for the mDNS messages described in this document. The examples depict individual messages, not complete exchanges. The mDNS message format is specified in Section 18 of [RFC6762].¶

All domain names are fully qualified. The resource record TTL is 120 seconds in these examples; this value is illustrative. RDLENGTH values assume that PTRDNAME is encoded without DNS name compression. IPv6 and UDP headers are not shown.¶

The encoded QCLASS value includes the unicast-response (QU) bit. The encoded resource record CLASS value includes the cache-flush bit. These bits are shown separately from the underlying DNS class, IN.¶

Figure 1 shows a probe for the PTR record. The question uses QTYPE ANY, and the proposed record appears in the Authority Section. This corresponds with the operation described in Section 2.5.¶

Header:
  ID:              0
  Flags:           0x0000 (all flags clear)
  QDCOUNT:         1
  ANCOUNT:         0
  NSCOUNT:         1
  ARCOUNT:         0
Question Section:
  QNAME:           0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa.
  QTYPE:           ANY (255)
  QCLASS:          IN (1)
  QU bit:          1
  Encoded QCLASS:  0x8001
Answer Section:
  (empty)
Authority Section:
  NAME:            0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa.
  TYPE:            PTR (12)
  CLASS:           IN (1)
  Cache-flush bit: 0
  Encoded CLASS:   0x0001
  TTL:             120
  RDLENGTH:        27
  PTRDNAME:        application.example.local.
Additional Section:
  (empty)

Figure 2 shows an announcement of the application PTR record following successful probing. The record appears in the Answer Section with the cache-flush bit set. This corresponds with the operation described in Section 2.6.¶

Header:
  ID:              0
  Flags:           0x8400 (QR=1, AA=1; other flags clear)
  QDCOUNT:         0
  ANCOUNT:         1
  NSCOUNT:         0
  ARCOUNT:         0
Question Section:
  (empty)
Answer Section:
  NAME:            0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa.
  TYPE:            PTR (12)
  CLASS:           IN (1)
  Cache-flush bit: 1
  Encoded CLASS:   0x8001
  TTL:             120
  RDLENGTH:        27
  PTRDNAME:        application.example.local.
Authority Section:
  (empty)
Additional Section:
  (empty)

Figure 3 shows an announcement of the veto PTR record. The owner name is unchanged, but the PTRDNAME identifies the veto. This corresponds with the operation described in Section 3.¶

Header:
  ID:              0
  Flags:           0x8400 (QR=1, AA=1; other flags clear)
  QDCOUNT:         0
  ANCOUNT:         1
  NSCOUNT:         0
  ARCOUNT:         0
Question Section:
  (empty)
Answer Section:
  NAME:            0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa.
  TYPE:            PTR (12)
  CLASS:           IN (1)
  Cache-flush bit: 1
  Encoded CLASS:   0x8001
  TTL:             120
  RDLENGTH:        18
  PTRDNAME:        application-veto.
Authority Section:
  (empty)
Additional Section:
  (empty)

Appendix B. Evaluation of Solution

[RFC10019] 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 ([RFC10028]).¶

[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 by 2) 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. Appendix B.1 contains 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 [RFC10019]:¶

[CONS-1]

Multi-Subnet Support: Operating the protocol across multiple subnets is outside the scope of this document (Section 4).¶

[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 preloaded 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 ([RFC6763]) 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.¶

Acknowledgement

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, to Esko Dijk for his review of the draft, and to Gunter Van de Velde for his review and suggestions.¶