| Internet-Draft | DNS-MSD | November 2023 |
| Karstens, et al. | Expires 9 May 2024 | [Page] |
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.¶
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.¶
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 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.¶
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.¶
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.¶
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.¶
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]).¶
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.¶
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.¶
Domain name reservation considerations for "mcast.arpa." as required by Section 5 of [RFC6761]:¶
This document does not have any additional security notes beyond what is described in Section 15 of [RFC6763].¶
Special thanks to the National Marine Electronics Association for their contributions in developing marine industry standards and their support for this research.¶