Zero-Configuration Assignment of IPv6 Multicast Addresses Using mDNS
draft-ietf-pim-ipv6-zeroconf-assignment-13

Network Working Group                                        N. Karstens
Internet-Draft                                                    Garmin
Intended status: Standards Track                            D. Farinacci
Expires: 11 April 2027                                       lispers.net
                                                              M. McBride
                                                               Futurewei
                                                          8 October 2026

  Zero-Configuration Assignment of IPv6 Multicast Addresses Using mDNS
               draft-ietf-pim-ipv6-zeroconf-assignment-13

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 criteria listed in RFC 10019.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 11 April 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components

Karstens, et al.          Expires 11 April 2027                 [Page 1]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs    October 2026

   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Procedure . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Group ID Selection  . . . . . . . . . . . . . . . . . . .   4
     2.2.  Address Generation  . . . . . . . . . . . . . . . . . . .   4
     2.3.  Domain Name Assembly  . . . . . . . . . . . . . . . . . .   5
     2.4.  Record Construction . . . . . . . . . . . . . . . . . . .   5
     2.5.  Probing . . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.6.  Announcing and Responding . . . . . . . . . . . . . . . .   6
     2.7.  Conflict Detection and Resolution . . . . . . . . . . . .   6
     2.8.  Transmitting  . . . . . . . . . . . . . . . . . . . . . .   7
     2.9.  Optimization  . . . . . . . . . . . . . . . . . . . . . .   7
     2.10. Defending . . . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Veto Records  . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Use on Networks with Multiple Subnets . . . . . . . . . . . .   8
   5.  Evaluation of Solution  . . . . . . . . . . . . . . . . . . .   8
     5.1.  Collision Detection After Partition Repair  . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Domain Name Reservation Considerations  . . . . . . . . .  11
   7.  Implementation Status . . . . . . . . . . . . . . . . . . . .  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

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

Karstens, et al.          Expires 11 April 2027                 [Page 2]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs    October 2026

   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.

   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.

1.1.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Procedure

   This section describes 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.

Karstens, et al.          Expires 11 April 2027                 [Page 3]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs    October 2026

   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.  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.

   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.

2.1.  Group ID Selection

   When an application is preparing to transmit a multicast stream, it
   begins by selecting an IPv6 multicast group ID.

   If the application is either 1) transmitting a multicast stream for
   the first time or 2) responding to an address collision, then the
   application SHALL select a random multicast group ID value from the
   range 0x90000000-0x9FFFFFFF.  IANA is REQUESTED to assign this range
   from the "Dynamic Multicast Group IDs" registry (Section 6).

   If the application has previously transmitted the multicast stream,
   then the selected multicast group ID should have been retained in
   persistent storage (Optimization, Section 2.9).  The application
   SHALL proceed using the stored value.

   Note that the range of possible group ID values means that the
   probability that another application has chosen the same group ID is
   (n / 2^28), where n is the number of applications on the network.

2.2.  Address Generation

   Once the IPv6 multicast group ID has been selected, the application
   SHALL use this to generate two multicast addresses:

   1.  IPv6 Multicast Address

Karstens, et al.          Expires 11 April 2027                 [Page 4]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs    October 2026

       This is a link-scoped IPv6 multicast address, calculated by
       combining the multicast group ID with the Interface Identifier
       (IID) of the intended source address for the multicast stream,
       according to the format given in [RFC4489], Section 3.

   2.  Multicast Ethernet Address

       This is the corresponding multicast Ethernet address that will be
       used to transmit the data.  It is calculated from the IPv6
       multicast address, as described in [RFC2464], Section 7.

   For example, consider a source address of fe80::a12:34ff:fe56:7890.
   If the selected group ID is 9abc:def0, then the calculated IPv6
   multicast address would be ff32:ff:a12:34ff:fe56:7890:9abc:def0 and
   the multicast Ethernet address would be 33:33:9A:BC:DE:F0.

2.3.  Domain Name Assembly

   Once the multicast Ethernet address is determined, the application
   SHALL use this to assemble 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).

   Considering the example in Address Generation (Section 2.2), the
   resulting domain name would be "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 ([RFC3596], Section 2.5).
   As such, this document reserves the domain "9.3.3.3.3.eth-addr.arpa"
   as a special-use domain in the "Special-Use Domain Names" registry
   (Section 6).  The "3.3.3.3" component of this is taken from the 33:33
   prefix used for mapping IPv6 multicast addresses to Ethernet
   multicast addresses and the "9" component indicates a multicast group
   ID in the range 0x90000000-0x9FFFFFFF.

2.4.  Record Construction

   Once the domain name is assembled, the application SHALL construct a
   unique PTR record using that domain 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.

Karstens, et al.          Expires 11 April 2027                 [Page 5]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs    October 2026

   Note that A/AAAA records may also be published for this same host
   name (for example, "example.local."), though this is not a
   requirement for this design.

   To allow for the creation of veto records (Section 3), the first DNS
   label of the application identifier SHALL NOT exceed 58 octets in
   length.  This reflects the 63-byte limit specified in [RFC1035],
   Section 2.3.4 while also reserving space for a 5-byte suffix.

2.5.  Probing

   After the PTR record is constructed, the application SHALL use the
   mDNS probing algorithm described in [RFC6762], Section 8.1 to probe
   for a PTR record with the same name.

   Due to the large range of values for group IDs, it is unlikely that
   two applications would randomly choose the same group ID and begin
   probing at the same time.  However, in that event, the conflict SHALL
   be resolved according to the procedure in [RFC6762], Section 8.2.
   The loser of the conflict SHALL return to Group ID Selection
   (Section 2.1) and choose a different group ID.

2.6.  Announcing and Responding

   If the probing algorithm started in Probing (Section 2.5) completes
   without any conflict, then the application SHALL announce the PTR
   record according to the procedure in [RFC6762], Section 8.3 and SHALL
   respond to queries for the PTR record according to [RFC6762],
   Section 6.

2.7.  Conflict Detection and Resolution

   The application SHALL start a continuous query for the PTR record
   according to [RFC6762], Section 5.2.  This helps detect a conflict in
   the event of a network partition and repair (Section 5.1).  If a
   conflict is detected at any time, then the application SHALL resolve
   the conflict according to [RFC6762], Section 9.  The losing
   application SHALL stop transmitting that multicast stream and return
   to Group ID Selection (Section 2.1), choosing a new group ID.  As
   before, this new group ID is also retained in persistent storage,
   overwriting any group ID previously saved for this multicast stream.

Karstens, et al.          Expires 11 April 2027                 [Page 6]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs    October 2026

   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 stop transmitting that multicast stream
   and return to Group ID Selection (Section 2.1), choosing a new group
   ID.  Only one application need respond in this manner to resolve the
   collision, but both may do so.  No method to coordinate this between
   hosts is necessary and this protocol does not specify one.

2.8.  Transmitting

   Once the PTR record is advertised and the continuous query started,
   the host MAY then begin transmitting multicast data using the
   multicast addresses from Address Generation (Section 2.2).

2.9.  Optimization

   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 and reduces
   the likelihood of future collisions, as long as the network is
   unchanged.

   Note that retaining the value does not permit the application to skip
   any of the preceding steps.  This is consistent with [RFC6762],
   Section 10.2 and allows the application to recover from any network
   changes that may have occurred when it was offline.

2.10.  Defending

   The application SHALL defend the PTR record from probes as described
   in [RFC6762], Section 6.

3.  Veto Records

   Veto records are used to address collisions that occur in the network
   infrastructure (for example, the address table in a switch is
   discussed in [RFC10019], Section 2).

   When a network 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.  The veto record's PTRDNAME
   field is created by appending the string "-veto" to the first DNS
   label that appears in the PTRDNAME field of the PTR record that
   caused the address collision (for example, "application-veto").  This
   technique results in a veto PTR record that is always
   lexicographically later than the PTR record from the application

Karstens, et al.          Expires 11 April 2027                 [Page 7]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs    October 2026

   (specifically, the first DNS label is always longer, so the first
   byte of the RDATA, which contains the length, always contains a
   larger value).  In turn, this causes the veto record to always win
   the conflict resolution described in [RFC6762], Section 9.

   Network infrastructure components SHALL publish veto records 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.
   As such, it is unnecessary to store vetoes to persistent storage.

   If an application transmitting a veto record determines that the PTR
   record for the address causing the conflict has become invalid
   (either due to receiving a goodbye packet or to record expiry), then
   it SHALL query the network for the PTR record.  If the application
   does not receive a query response containing the PTR record after 5
   seconds, then the application SHALL delay a random amount of time in
   the range 20-120 ms and then send a goodbye packet that invalidates
   the veto record.

4.  Use on Networks with Multiple Subnets

   The protocol can be extended across multiple subnets if PTR records
   are distributed between subnets (for example, by using an mDNS
   reflector).  Distributing mDNS records between subnets is an ongoing
   area of research and improvement ([RFC7558]).

   Multicast streams forwarded to other subnets MUST use a unicast-
   prefix based IPv6 multicast address ([RFC3306]), as the link-scoped
   IPv6 multicast address created in Address Generation (Section 2.2) is
   scoped to the local link.

   The protocol's reliance on cooperating hosts (Section 8) makes it
   unsuited for use on the global Internet.  [RFC8815] recommends
   Source-Specific Multicast in this environment.

5.  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.

Karstens, et al.          Expires 11 April 2027                 [Page 8]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs    October 2026

   [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.  Section 5.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: The protocol can operate across
             multiple subnets (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 pre-loaded configuration or device-specific
             manufacturing data.

Karstens, et al.          Expires 11 April 2027                 [Page 9]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs    October 2026

   [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.

5.1.  Collision Detection After Partition Repair

   A network partition occurs when one part of a network is temporarily
   unable to communicate with another part of the network.  This may
   happen, for example, if a switch goes offline.  A partition repair
   happens when communication is fully restored to all parts of the
   network.

   Because mDNS is designed to be a low-bandwidth protocol, it can take
   a significant 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 open to future enhancement, but are
   considered out-of-scope for this document.

6.  IANA Considerations

   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 [RFC10028].  The range of this block should
   be 0x90000000-0x9FFFFFFF and the description should be "Zero-
   Configuration Assignment of IPv6 Multicast Addresses Using mDNS".

Karstens, et al.          Expires 11 April 2027                [Page 10]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs    October 2026

   IANA manages two registries that contain entries used for mapping
   addresses to names.  This document introduces "eth-addr.arpa" for use
   in a similar capacity and so requests that it be added to these
   registries as well.

   The domain "eth-addr.arpa" should be registered in the .arpa registry
   (https://www.iana.org/domains/arpa).  The usage should be "For
   mapping Ethernet addresses to local domain names for Zero-
   Configuration Assignment of IPv6 Multicast Addresses" and the
   reference should be [I-D.draft-ietf-pim-ipv6-zeroconf-assignment].

   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.

6.1.  Domain Name Reservation Considerations

   [RFC6761], Section 5 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:

   1.  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.

   2.  Application software SHOULD recognize these names as a reverse
       mapping domain and MAY associate them with the protocol described
       in this document.

   3.  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).

   4.  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.

   5.  Authoritative DNS servers SHOULD recognize these names as being
       used exclusively with mDNS and SHOULD respond to any query with
       NXDOMAIN.

   6.  DNS server operators MUST NOT configure an authoritative DNS
       server to answer queries for these names.

Karstens, et al.          Expires 11 April 2027                [Page 11]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs    October 2026

   7.  DNS Registries/Registrars MUST NOT register "9.3.3.3.3.eth-
       addr.arpa" names.

7.  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.

8.  Security Considerations

   Due to its reliance on mDNS, the Security Considerations for mDNS
   ([RFC6762], Section 21) apply to this document as well.

   As with mDNS itself, this protocol only works in environments where
   all hosts are cooperating.  There are two types of messages that a
   bad actor could use to attack the network:

   1.  Conflict Response

Karstens, et al.          Expires 11 April 2027                [Page 12]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs    October 2026

       A bad actor could monitor the network for applications probing
       for "9.3.3.3.3.eth-addr.arpa" PTR records and repeatedly generate
       conflicting response messages, preventing the application from
       finding an unused address.

   2.  Veto Records

       A bad actor could generate veto records for addresses already
       allocated, repeatedly forcing the application to find a new
       address.

   Both message types would prevent the application from being able to
   transmit its multicast stream, denying service to the multicast
   group.  Repeatedly forcing the application to attempt new addresses
   also increases network traffic.

   The protocol's use of implicit availability means that a bad actor
   that is able to filter mDNS traffic could neutralize the ability of
   applications to use mDNS to prevent collisions.  In most networks,
   the probability of a collision is already so low that this does not
   result in a practical way to attack the network.

9.  References

9.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
              <https://www.rfc-editor.org/info/rfc2464>.

   [RFC3306]  Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
              Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,
              September 2002, <https://www.rfc-editor.org/info/rfc3306>.

   [RFC4489]  Park, J., Shin, M., and H. Kim, "A Method for Generating
              Link-Scoped IPv6 Multicast Addresses", RFC 4489,
              DOI 10.17487/RFC4489, April 2006,
              <https://www.rfc-editor.org/info/rfc4489>.

Karstens, et al.          Expires 11 April 2027                [Page 13]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs    October 2026

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, DOI 10.17487/RFC6761, February 2013,
              <https://www.rfc-editor.org/info/rfc6761>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <https://www.rfc-editor.org/info/rfc6762>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC10028] Karstens, N., Farinacci, D., and M. McBride, "Updates to
              Dynamic IPv6 Multicast Address Group IDs", RFC 10028,
              DOI 10.17487/RFC10028, August 2026,
              <https://www.rfc-editor.org/info/rfc10028>.

9.2.  Informative References

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", STD 88,
              RFC 3596, DOI 10.17487/RFC3596, October 2003,
              <https://www.rfc-editor.org/info/rfc3596>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/info/rfc6763>.

   [RFC7558]  Lynn, K., Cheshire, S., Blanchet, M., and D. Migault,
              "Requirements for Scalable DNS-Based Service Discovery
              (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558,
              DOI 10.17487/RFC7558, July 2015,
              <https://www.rfc-editor.org/info/rfc7558>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

   [RFC8815]  Abrahamsson, M., Chown, T., Giuliano, L., and T. Eckert,
              "Deprecating Any-Source Multicast (ASM) for Interdomain
              Multicast", BCP 229, RFC 8815, DOI 10.17487/RFC8815,
              August 2020, <https://www.rfc-editor.org/info/rfc8815>.

   [RFC10019] Karstens, N., Farinacci, D., and M. McBride, "Zeroconf
              Multicast Address Allocation Problem Statement and
              Requirements", RFC 10019, DOI 10.17487/RFC10019, July
              2026, <https://www.rfc-editor.org/info/rfc10019>.

Karstens, et al.          Expires 11 April 2027                [Page 14]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs    October 2026

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.

Authors' Addresses

   Nate Karstens
   Garmin International, Inc.
   1200 E. 151st St.
   Olathe, KS 66062-3426
   United States of America
   Email: nate.karstens@gmail.com

   Dino Farinacci
   lispers.net
   San Jose, CA
   United States of America
   Email: farinacci@gmail.com

   Mike McBride
   Futurewei
   United States of America
   Email: michael.mcbride@futurewei.com

Karstens, et al.          Expires 11 April 2027                [Page 15]