Zero-Configuration Assignment of IPv6 Multicast Addresses
draft-ietf-pim-ipv6-zeroconf-assignment-00

Network Working Group                                        N. Karstens
Internet-Draft                                      Garmin International
Intended status: Standards Track                            D. Farinacci
Expires: 8 May 2024                                          lispers.net
                                                              M. McBride
                                                               Futurewei
                                                         5 November 2023

       Zero-Configuration Assignment of IPv6 Multicast Addresses
               draft-ietf-pim-ipv6-zeroconf-assignment-00

Abstract

   Describes a zero-configuration protocol for dynamically assigning
   IPv6 multicast addresses.  Applications randomly assign multicast
   group IDs from a reserved range and prevent collisions by using mDNS
   to publish records in a new "eth-addr.arpa" special-use domain.  This
   protocol satisfies all of the criteria listed in draft-ietf-pim-
   zeroconf-mcast-addr-alloc-ps.

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 8 May 2024.

Copyright Notice

   Copyright (c) 2023 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 8 May 2024                   [Page 1]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs   November 2023

   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 . . . . . . . . . . . . . . . . . .   2
   2.  Procedure . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Evaluation of Solution  . . . . . . . . . . . . . . . . . . .   3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Domain Name Reservation Considerations  . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] 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 reserved range and
   using mDNS to prevent collisions.

   Once the IPv6 multicast address has been assigned, the data contained
   the multicast stream may be advertised using the method described in
   [I-D.karstens-dnssd-dns-msd].

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

   When an application is preparing to transmit a multicast stream, it
   first generates a random group ID in the range 0x90000000-0x9FFFFFFF,
   which IANA should reserve from the "Dynamic Multicast Group IDs"
   registry (see Section 4).  It combines this with the Interface
   Identifier (IID) of the intended source address for the multicast
   stream to generate a link-scoped IPv6 multicast address [RFC4489].

Karstens, et al.           Expires 8 May 2024                   [Page 2]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs   November 2023

   The application then calculates the multicast Ethernet address that
   will be used to transmit the data ([RFC2464], Section 7) and uses
   that to construct a string like 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: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".

   The application then uses the mDNS probing algorithm described in
   [RFC6762], Section 8.1 to continuously query for a PTR record with
   the same name as the generated string.  If the probing algorithm
   completes without any conflict, then the application begins
   advertising its own unique 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 a conflict is detected at any point, then the application stops
   transmitting that multicast stream and starts the process over using
   a different group ID.

   The host may optionally 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 responds the same as 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).

3.  Evaluation of Solution

   [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] contains a list of
   criteria to evaluate potential solutions.  The protocol described in
   this document satisfies all of the required criteria.

Karstens, et al.           Expires 8 May 2024                   [Page 3]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs   November 2023

   However, because mDNS is designed to be a low-bandwidth protocol, it
   can take a signficant amount of time to detect a 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 a detection mechanism and prompting hosts to send
   unsolicited mDNS response messages when the partition is repaired.

   The protocol described in this document also satisfies the
   recommended criteria, to the extent that a deployment supports
   publishing mDNS-based DNS-SD records across multiple subnets (see
   [RFC8766]).

4.  IANA Considerations

   IANA should allocate a block of group IDs from the "Dynamic Multicast
   Group IDs" registry in the "IPv6 Multicast Address Space Registry"
   registry group that was created by
   [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id].  The range of this
   block should be 0x90000000-0x9FFFFFFF and the description should be
   the title of this document.

   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).  This domain should not be delegated.

4.1.  Domain Name Reservation Considerations

   The "eth-addr.arpa." domain is effectively a reverse-mapping domain
   and so has the same considerations as the reverse-mapping domains
   listed in [RFC6761], Section 6.1.

5.  Security Considerations

   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.

Karstens, et al.           Expires 8 May 2024                   [Page 4]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs   November 2023

6.  Acknowledgement

   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.

7.  References

7.1.  Normative References

   [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps]
              Karstens, N., Farinacci, D., and M. McBride, "Zeroconf
              Multicast Address Allocation Problem Statement and
              Requirements", Work in Progress, Internet-Draft, draft-
              ietf-pim-zeroconf-mcast-addr-alloc-ps-00, 15 September
              2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
              pim-zeroconf-mcast-addr-alloc-ps-00>.

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

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

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

7.2.  Informative References

Karstens, et al.           Expires 8 May 2024                   [Page 5]
Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs   November 2023

   [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id]
              Karstens, N., Farinacci, D., and M. McBride, "Updates to
              Dynamic IPv6 Multicast Address Group IDs", Work in
              Progress, Internet-Draft, draft-ietf-pim-updt-ipv6-dyn-
              mcast-addr-grp-id-00, 28 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pim-
              updt-ipv6-dyn-mcast-addr-grp-id-00>.

   [I-D.karstens-dnssd-dns-msd]
              Karstens, N., Farinacci, D., and M. McBride, "DNS-Based
              Multicast Stream Discovery", Work in Progress, Internet-
              Draft, draft-karstens-dnssd-dns-msd-01, 26 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-karstens-
              dnssd-dns-msd-01>.

   [RFC8766]  Cheshire, S., "Discovery Proxy for Multicast DNS-Based
              Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June
              2020, <https://www.rfc-editor.org/info/rfc8766>.

Authors' Addresses

   Nate Karstens
   Garmin International
   Email: nate.karstens@gmail.com

   Dino Farinacci
   lispers.net
   Email: farinacci@gmail.com

   Mike McBride
   Futurewei
   Email: michael.mcbride@futurewei.com

Karstens, et al.           Expires 8 May 2024                   [Page 6]