One document matched: draft-jabley-multicast-ptr-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1034 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
<!ENTITY rfc1035 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY rfc3152 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3152.xml'>
<!ENTITY rfc3172 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3172.xml'>
<!ENTITY rfc3596 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3596.xml'>
<!ENTITY rfc4291 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml'>
<!ENTITY rfc6672 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6672.xml'>
]>
<rfc category="bcp" ipr="trust200902"
docName="draft-jabley-multicast-ptr-00">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Reverse Mapping for Multicast">DNS Reverse Mapping
for Multicast Addresses</title>
<author initials='J.' surname="Abley" fullname='Joe Abley'>
<organization>Dyn, Inc.</organization>
<address>
<postal>
<street>470 Moore Street</street>
<city>London</city>
<region>ON</region>
<code>N6C 2C2</code>
<country>Canada</country>
</postal>
<phone>+1 519 670 9327</phone>
<email>jabley@dyn.com</email>
</address>
</author>
<date month="October" year="2013"/>
<abstract>
<t>The mapping of IPv4 and IPv6 addresses to names using the
Domain Name System (DNS) is colloquially known as "Reverse
Mapping". Reverse Mapping support for registered multicast
address assignments in IPv4 is currently incomplete and
ad-hoc; in IPv6 there is no support at all.</t>
<t>This document describes procedures to be followed that will
result in more systematic and predictable support for Reverse
Mapping for IPv4 multicast address assignments, and introduces
analogous support for IPv6.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Domain Name System (DNS), as originally specified in
<xref target="RFC1034"/> and <xref target="RFC1035"/>,
provides support for the mapping of IPv4 addresses to names
using a namespace convention within the IN-ADDR.ARPR domain
and the PTR resoure record type.</t>
<t>The analogous mapping of IPv6 address to names is specified in
<xref target="RFC3596"/>, adopting a similar namespace convention
within the IP6.ARPA domain.</t>
<t>Multicast addresses are assigned by the IANA, and assignments
are documented in various IANA registries.</t>
<t>For IPv4, Reverse Mapping of assigned multicast addresses
to names has historically been provided in an ad-hoc and
incomplete fashion, without tight coordination with IANA
multicast address assignment processes. Names assigned to
IPv4 multicast addresses have been chosen somewhat arbitrarily
within the MCAST.NET domain. For IPv6, no Reverse Mapping
is provided.</t>
<t>This document describes procedures to be followed by the IANA
to support predictable and consistent Reverse Mapping for
registered multicast addresses in IPv4 and IPv6.</t>
</section>
<section title="General Approach">
<t>This document specifies extensions to existing IPv4 and
IPv6 multicast registries to include a mandatory column
"DNS Label". This field is required to be popluated with
a unique, valid DNS label for all future multicast address
assignments except in the case where reverse mapping for
an address is explicitly not desirable.</t>
<t>The procedures at the IANA relating to multicast address
assignment are extended to include the provisioning of
appropriate changes in the DNS at the time of registration
or de-registration of any multicast addresses. Specific
actions requested of the IANA are described in <xref
target="iana_considerations"/>.</t>
<t>Names for multicast addresses are assigned under MCAST.ARPA
for IPv4 addresses, and MCAST6.ARPA for IPv6 addresses.
The naming schemes to bs used in each case are described
in <xref target="naming_scheme"/>. The use of MCAST.ARPA
rather than MCAST.NET is discussed in <xref
target="using_arpa"/>.</t>
</section>
<section title="Naming Scheme" anchor="naming_scheme">
<section title="IPv4 Multicast Addresses">
<t>Each assigned IPv4 multicast address has an accompanying
DNS Label. The name associated with an IPv4 multicast address
with DNS Label SOMENAME is SOMENAME.MCAST.ARPA.</t>
<t>For example, suppose the assigned IPv4 multicast address
224.0.1.1 has the DNS Label "NTP". The address 224.0.1.1
maps to the name "NTP.MCAST.ARPA"; the name "NTP.MCAST.ARPA"
maps to the address 224.0.1.1.</t>
</section>
<section title="IPv6 Multicast Addresses">
<t>Each assigned IPv6 multicast address has an accompanying
DNS Label ("Address Label").</t>
<t>IPv6 multicast addresses may be of fixed or variable
scope. The naming scheme for these addresses incorporates
a scope identifier using an additional DNS label ("Scope
Label"), specified in a dedicated registry (see <xref
target="scope_registry"/>). Both fixed and variable scope
multicast addresses use the same naming scheme.</t>
<t>The name associated with an IPv6 multicast address
with Scope Label SCOPE and Address Label SOMENAME is
SOMENAME.SCOPE.MCAST6.ARPA.</t>
<t>For example, suppose ff01::1 is an assigned IPv6 multicast address
with Scope Label "NODE-LOCAL" and Address Label "ALL-NODES".
The address ff01::1 maps to the name
"ALL-NODES.NODES-LOCAL.MCAST6.ARPA"; the name
"ALL-NODES.NODES-LOCAL.MCAST6.ARPA" maps to the address
ff01::1.</t>
<t>The variable-scope multicast address ff0x::fb will have
different Reverse Mapping depending on the scope specified
in the address (i.e. the value of x), although the Address
Label in each case will be the same ("MDNSV6"). The
Site-Local address ff05::fb has an associated Scope Label
"SITE-LOCAL", and is therefore named
MDNSV6.SITE-LOCAL.MCAST6.ARPA. The Link-Local address
ff02::fb has an associated Scope Label "LINK-LOCAL" and
hence is named MDNSV6.LINK-LOCAL.MCAST6.ARPA.</t>
</section>
</section>
<section title="Use of MCAST.ARPA" anchor="using_arpa">
<t>Use of the MCAST.ARPA domain rather than MCAST.NET for
IPv4 multicast addresses is specified for the same reasons
that led IP6.INT to be superceded by "IP6.ARPA" <xref
target="RFC3152"/>.</t>
<t>It is prudent to assume that hard-coded assumptions about
names in MCAST.NET exist, and will persist for some time.
This document specifies that names in the MCAST.ARPA domain
also be available in the MCAST.NET domain, to provide support
for software with those assumptions. Ongoing support for
the MCAST.NET zone is described in <xref target="mcast_net"/>.</t>
<t>It is possible that in the future empirical measurement will
confirm that the use of names under MCAST.NET is no longer
required and that provisioning of the MCAST.NET domain
can safely cease. This document provides no such measurement and
makes no such recommendation, however.</t>
</section>
<section title="IAB Considerations" anchor="iab_considerations">
<t>This document proposes a delegation within the ARPA domain,
and, in accordance with <xref target="RFC3172"/>, IAB review
and approval of the delegation of MCAST.ARPA and MCAST6.ARPA
as described in <xref target="delegation"/> is required.</t>
<t>Once IAB approval has been obtained, this section may be
removed prior to publication or updated to include text that
confirms the IAB's decision, at the IAB's discretion.</t>
</section>
<section title="IANA Considerations" anchor="iana_considerations">
<section title="Registry Changes" anchor="registry_changes">
<section title="IPv6 Multicast Scope Registry" anchor="scope_registry">
<t>The IANA is directed to create a new registry as follows:
<list style="hanging">
<t hangText="Registry Name:">IPv6 Multicast Address Scopes</t>
<t hangText="Registration Procedure:">Standards Action</t>
<t hangText="Reference:">This document</t>
<t hangText="Schema:">See initial contents, below. Note that
the Scope Value and DNS Label fields are mandatory for
all rows, and that values chosen for future DNS Label
fields are required to be unique within this registry.</t>
</list>
</t>
<t>The initial contents of this new registry should be:</t>
<texttable>
<ttcol>Scope Value</ttcol>
<ttcol>DNS Label</ttcol>
<ttcol>Scope Name</ttcol>
<ttcol>Reference</ttcol>
<c>0x0</c>
<c>(none)</c>
<c>Reserved</c>
<c><xref target="RFC4291"/></c>
<c>0x1</c>
<c>NODE-LOCAL</c>
<c>Node-Local Scope</c>
<c><xref target="RFC4291"/></c>
<c>0x2</c>
<c>LINK-LOCAL</c>
<c>Link-Local Scope</c>
<c><xref target="RFC4291"/></c>
<c>0x3</c>
<c>(none)</c>
<c>Reserved</c>
<c><xref target="RFC4291"/></c>
<c>0x4</c>
<c>ADMIN-LOCAL</c>
<c>Admin-Local Scope</c>
<c><xref target="RFC4291"/></c>
<c>0x5</c>
<c>SITE-LOCAL</c>
<c>Site-Local Scope</c>
<c><xref target="RFC4291"/></c>
<c>0x8</c>
<c>ORG-LOCAL</c>
<c>Organisation-Local Scope</c>
<c><xref target="RFC4291"/></c>
<c>0xE</c>
<c>GLOBAL</c>
<c>Global Scope</c>
<c><xref target="RFC4291"/></c>
</texttable>
<t>The IANA may add "Date Registered" and "Last Revised"
columns to the schema at its discretion.</t>
</section>
<section title="IPv4 Multicast Address Space Registries">
<t>The IANA is directed to add a mandatory "DNS Label"
column to all IPv4 Multicast Address Space registries.
The initial contents of the DNS Label field for each
row should be taken from the corresponding MCAST.NET
zone owner names where available; addresses with no
existing mapping in MCAST.NET should have DNS Labels
assigned by the IANA at their discretion.</t>
<t>All existing assignments should have a DNS Label
assigned. A DNS Label should be mandatory for all
future registrations. DNS Labels are required to be
unique for all IPv4 multicast address assignments.</t>
</section>
<section title="IPv6 Multicast Address Space Registries">
<t>The IANA is directed to add a mandatory "DNS Label"
column to all IPv6 Multicast Address Space registries.
The initial contents of the DNS Label field for each
row should be assigned by the IANA at their discretion.</t>
<t>All existing assignments should have a DNS Label
assigned. A DNS Label should be mandatory for all
future registrations. DNS Labels are required to be
unique for all IPv6 multicast address assignments.</t>
</section>
</section>
<section title="Delegation of MCAST.ARPA and MCAST6.ARPA"
anchor="delegation">
<t>The IANA is directed to create and host the MCAST.ARPA
and MCAST6.ARPA zones on name servers of their choosing.
The MCAST.ARPA and MCAST6.ARPA zones should be signed
using DNSSEC, with DNSSEC parameters chosen by the IANA. The
initial zone contents should be as described in
<xref target="initial_zones"/>.</t>
<t>The IANA is directed to provision secure
delegations for the MCAST.ARPA and MCAST6.ARPA zones from
the ARPA zone (i.e. delegations with accompanying DS RRSets).</t>
</section>
<section title="Initial Zone Contents"
anchor="initial_zones">
<t>The IANA is directed to populate the MCAST.ARPA and MCAST6.ARPA
zones, and the corresponding reverse mapping zones under
IN-ADDR.ARPA and IP6.ARPA, directly from the IPv4 and IPv6
Multicast Address Registries, amended as described in
<xref target="registry_changes"/>.</t>
<t>As an example, if the IPv6 Variable Scope Multicast Addresses
sub-registry contained the following entry:</t>
<texttable>
<ttcol>Address(es)</ttcol>
<ttcol>Description</ttcol>
<ttcol>DNS Label</ttcol>
<c>FF0X::FB</c>
<c>mDNSv6</c>
<c>MDNSV6</c>
</texttable>
<t>then the following DNS records would be required:</t>
<figure>
<artwork>
$ORIGIN MCAST6.ARPA.
;
; all scoped addresses for mDNSv6
;
MDNSV6.NODE-LOCAL AAAA FF01::FB
MDNSV6.LINK-LOCAL AAAA FF02::FB
MDNSV6.ADMIN-LOCAL AAAA FF04::FB
MDNSV6.SITE-LOCAL AAAA FF05::FB
MDNSV6.ORG-LOCAL AAAA FF08::FB
MDNSV6.GLOBAL AAAA FF0E::FB
$ORIGIN 0.F.F.IP6.ARPA.
;
; all scoped addresses for mDNSv6 (split across lines for clarity)
;
B.F.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 \
PTR MDNSV6.NODE-LOCAL.MCAST6.ARPA.
B.F.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2 \
PTR MDNSV6.LINK-LOCAL.MCAST6.ARPA.
B.F.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4 \
PTR MDNSV6.ADMIN-LOCAL.MCAST6.ARPA.
B.F.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5 \
PTR MDNSV6.SITE-LOCAL.MCAST6.ARPA.
B.F.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8 \
PTR MDNSV6.ORG-LOCAL.MCAST6.ARPA.
B.F.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.E \
PTR MDNSV6.GLOBAL.MCAST6.ARPA.
</artwork>
</figure>
<t>As a further example, if the IPv4 Internetwork Control Block
Multicast Address Registry contained the following entry:</t>
<texttable>
<ttcol>Address(es)</ttcol>
<ttcol>Description</ttcol>
<ttcol>DNS Label</ttcol>
<c>224.0.1.2</c>
<c>SGI-Dogfight</c>
<c>SGI-DOG</c>
</texttable>
<t>then the following DNS records would be required:</t>
<figure>
<artwork>
$ORIGIN MCAST.ARPA.
;
; SGI-Dogfight address
;
SGI-DOG A 224.0.1.2
$ORIGIN 224.IN-ADDR.ARPA.
;
; SGI-Dogfight address
;
2.1.0 PTR SGI-DOG.MCAST.ARPA.
</artwork>
</figure>
</section>
<section title="Process Changes">
<t>The IANA is directed to require a valid and unique DNS Label
to be specified within the existing processes of multicast
address assignment in IPv4 and IPv6.</t>
<t>The IANA is further directed to maintain the MCAST.ARPA,
MCAST6.ARPA and related domains under IP6.ARPA and
IN-ADDR.ARPA such that any additions, changes or deletions
from the corresponding address registries are reflected
accurately in the DNS.</t>
</section>
<section title="Ongoing Support for MCAST.NET" anchor="mcast_net">
<t>IANA is directed to remove all non-apex resource records from
the MCAST.NET zone and to add an apex <xref
target="RFC6672">DNAME</xref> with target MCAST.ARPA.
The intention is to provide backwards compatibility for
software that has hard-coded assumptions about naming
conventions for IPv4 multicast addresses.</t>
<t>For example, the following describes the result of this change
for MCAST.NET SOA serial 2012123836, with DNSSEC resource records
omitted for clarity:</t>
<figure>
<artwork>
$ORIGIN MCAST.NET.
; beginning of zone
@ SOA SNS.DNS.ICANN.ORG. NOC.DNS.ICANN.ORG. (
2012123836
7200
3600
604800
3600 )
NS A.IANA-SERVERS.NET.
NS B.IANA-SERVERS.NET.
NS C.IANA-SERVERS.NET.
NS NS.ICANN.ORG.
DNAME MCAST.ARPA.
; end of zone
</artwork>
</figure>
</section>
</section>
<section title="Security Considerations">
<t>This document presents no known additional security concerns
to the Internet.</t>
</section>
<section title="Acknowledgements">
<t>Your name here, etc.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc1034;
&rfc1035;
&rfc3596;
&rfc4291;
</references>
<references title="Informative References">
&rfc3152;
&rfc3172;
&rfc6672;
</references>
<section title="Editorial Notes">
<t>This section (and sub-sections) to be removed prior to
publication.</t>
<section title="Change History">
<t>
<list style="hanging">
<t hangText="00">Initial draft, circulated for the
purposes of entertainment.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:20:25 |