Internet-Draft DNS-MSD November 2023
Karstens, et al. Expires 9 May 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-karstens-dnssd-dns-msd-02
Published:
Intended Status:
Informational
Expires:
Authors:
N. Karstens
Garmin International
D. Farinacci
lispers.net
M. McBride
Futurewei

DNS-Based Multicast Stream Discovery

Abstract

This document describes an application of DNS-SD for the advertisement and discovery of multicast streams. This is especially useful with multicast streams that use a dynamically-assigned multicast address.

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

Table of Contents

1. Introduction

Several documents describe locally-scoped or administratively-scoped allocation of multicast addresses. Some examples of this include:

These documents do not specify a mechanism for how these multicast streams should be advertised or discovered. This document specifies an application of DNS-Based Service Discovery (DNS-SD, [RFC6763]) for advertisement and discovery of multicast streams.

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. Stream Instance Enumeration and Resolution

DNS-SD uses PTR, SRV, and TXT records to describe a service. DNS-MSD also makes use of these records to describe a multicast stream, but makes a few modifications to the method described in [RFC6763].

First, DNS-MSD uses a new "mcast.arpa." special use domain in all records to indicate that the advertised service is a multicast stream.

The second label in the <Service> portion of a Service Instance Name MUST be "_udp".

The port advertised in the SRV record has a restriction not seen with unicast services. Unicast services can dynamically allocate a free port for the service. Multicast streams cannot use a dynamic port because there is no guarantee that applications on all clients can bind to the dynamic port. If all devices on the network are purpose-built for the application, then multicast streams may use a pre-determined port in the dynamic range. Otherwise, multicast streams should use a port registered with IANA. In either case, the chosen port is advertised in the SRV record.

The hostname advertised in the SRV, A, and AAAA records is a combination of the <Instance> portion of the Service Instance Name, the hostname of the stream's origin, and the "mcast.arpa." special use domain name.

Finally, the address advertised in A and AAAA records is the chosen multicast address. The "in-addr.arpa." and "ip6.arpa." records advertised for reverse lookup also reflect the chosen multicast address.

3. Notes

When used with Mulicast DNS [RFC6762], DNS-MSD can provide a zero-configuration mechanism for advertising and discovering multicast streams.

Nothing in DNS-MSD restricts its usage to link-local scope multicast addresses. If Multicast DNS is needed to provide zero-configuration address advertisement in other scopes, then the recommendation is to consider using it with larger-scoped addresses (see [RFC7558] and note in Section 22 of [RFC6762]).

4. Example

An example host has an Ethernet MAC address of 00-00-5E-00-53-00. This is used to create IPv6 link local address fe80::200:5eff:fe00:5300. It creates a link-scoped IPv6 multicast address ff32:ff:200:5eff:fe00:5300:aabb:ccdd to transmit with. Its hostname is "example", the service name is "_heartbeat._udp", service instance is "instance", and by pre-agreement all hosts on the network reserve port 62000 for this protocol. It has no additional data to include in a TXT record. The following DNS records are created:

_heartbeat._udp 4500 IN PTR instance._heartbeat._udp.mcast.arpa.
instance._heartbeat._udp.mcast.arpa. \
    120 IN SRV 0 0 62000 instance.example.mcast.arpa.
instance._heartbeat._udp.mcast.arpa. 4500 IN TXT ""
instance.example.mcast.arpa. \
    120 IN AAAA ff32:ff:200:5eff:fe00:5300:aabb:ccdd
d.d.c.c.b.b.a.a.0.0.3.5.0.0.e.f. \
    f.f.e.5.0.0.2.0.f.f.0.0.2.3.f.f. \
    ip6.arpa. 120 PTR instance.example.mcast.arpa.

Note that the backslash ('\') denotes a line that was divided for publication.

5. IANA Considerations

The special-use domain "mcast.arpa" should be registered in the "Special-Use Domain Names" registry https://www.iana.org/assignments/special-use-domain-names.

5.1. Domain Name Reservation Considerations

Domain name reservation considerations for "mcast.arpa." as required by Section 5 of [RFC6761]:

  1. Users will not use the "mcast.arpa." domain directly.
  2. Applications SHOULD recognize the "mcast.arpa." domain and reject any use in a unicast context.
  3. Name resolution APIs and libraries SHOULD resolve the "mcast.arpa." domain to the multicast address that carries the service's data.
  4. Caching DNS servers SHOULD NOT recognize the "mcast.arpa." domain as special.
  5. Authoritative DNS servers SHOULD NOT recognize the "mcast.arpa." domain as special.
  6. DNS server operators SHOULD be aware of the "mcast.arpa." domain's use in resolving multicast services.
  7. DNS registries/registrars MUST NOT allow the "mcast.arpa." domain to be registered to any person or entity.

6. Security Considerations

This document does not have any additional security notes beyond what is described in Section 15 of [RFC6763].

7. Acknowledgement

Special thanks to the National Marine Electronics Association for their contributions in developing marine industry standards and their support for this research.

8. References

8.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC6763]
Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, , <https://www.rfc-editor.org/info/rfc6763>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

8.2. Informative References

[I-D.ietf-pim-ipv6-zeroconf-assignment]
Karstens, N., Farinacci, D., and M. McBride, "Zero-Configuration Assignment of IPv6 Multicast Addresses", Work in Progress, Internet-Draft, draft-ietf-pim-ipv6-zeroconf-assignment-00, , <https://datatracker.ietf.org/api/v1/doc/document/draft-ietf-pim-ipv6-zeroconf-assignment/>.
[RFC2365]
Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, DOI 10.17487/RFC2365, , <https://www.rfc-editor.org/info/rfc2365>.
[RFC3307]
Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, DOI 10.17487/RFC3307, , <https://www.rfc-editor.org/info/rfc3307>.
[RFC4489]
Park, J., Shin, M., and H. Kim, "A Method for Generating Link-Scoped IPv6 Multicast Addresses", RFC 4489, DOI 10.17487/RFC4489, , <https://www.rfc-editor.org/info/rfc4489>.
[RFC6761]
Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, , <https://www.rfc-editor.org/info/rfc6761>.
[RFC6762]
Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, , <https://www.rfc-editor.org/info/rfc6762>.
[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, , <https://www.rfc-editor.org/info/rfc7558>.

Authors' Addresses

Nate Karstens
Garmin International
Dino Farinacci
lispers.net
Mike McBride
Futurewei