forked from ableyjoe/draft-jabley-multicast-ptr
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-jabley-multicast-ptr.xml
518 lines (435 loc) · 18.8 KB
/
draft-jabley-multicast-ptr.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1034 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml'>
<!ENTITY rfc1035 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY rfc3152 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3152.xml'>
<!ENTITY rfc3172 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3172.xml'>
<!ENTITY rfc3596 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3596.xml'>
<!ENTITY rfc4291 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml'>
<!ENTITY rfc6672 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6672.xml'>
]>
<rfc category="bcp" ipr="trust200902"
docName="draft-jabley-multicast-ptr-01">
<?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>
<author initials="M." surname="Richardson" fullname="Michael C. Richardson">
<organization>Sandelman Software Works Corp.</organization>
<address>
<postal>
<street>470 Dawson Avenue</street>
<city>Ottawa</city>
<region>ON</region>
<code>K1Z 5V7</code>
<country>Canada</country>
</postal>
<phone>+1 613 276 6809</phone>
<email>mcr@sandelman.ottawa.on.ca</email>
</address>
</author>
<author initials="T." surname="Wicinski" fullname="Tim Wicinski">
<organization>Salesforce, Inc.</organization>
<address>
<postal>
<street>1 Market St #300</street>
<city>San Francisco</city>
<region>CA</region>
<code>94105</code>
<country>US</country>
</postal>
<phone>+1.571.449.1550</phone>
<email>tjw.ietf@gmail.com</email>
</address>
</author>
<date month="July" year="2014"/>
<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 addresses to names is specified in
<xref target="RFC3596"/>, and adopts 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 the 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 both 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 titled
"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 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>REALM-LOCAL</c>
<c>Realm-Local Scope</c>
<c><xref target="I-D.ietf-6man-multicast-scopes"/></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>Additionally, The IANA SHOULD add "Date Registered" and "Last Revised"
columns to the schema.</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;
<?rfc include="reference.I-D.ietf-6man-multicast-scopes" ?>
</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>
<t hangText="01">Bumped draft number and updated date
to resurrect, based on possibility of renewed interest.
Added Michael and Tim as co-authors.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>