-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-acg-mboned-deprecate-interdomain-asm-00.txt
672 lines (436 loc) · 26.3 KB
/
draft-acg-mboned-deprecate-interdomain-asm-00.txt
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
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
Mboned M. Abrahamsson
Internet-Draft T-Systems
Intended status: Best Current Practice T. Chown
Expires: September 30, 2018 Jisc
L. Giuliano
Juniper Networks, Inc.
March 29, 2018
Deprecating ASM for Interdomain Multicast
draft-acg-mboned-deprecate-interdomain-asm-00
Abstract
This document recommends the deprecation of the use of Any-Source
Multicast (ASM) for interdomain multicast. It therefore implicitly
recommends the use of Source-Specific Multicast (SSM) for interdomain
multicast applications, and that hosts and routers that are expected
to handle such applications fully support SSM. The recommendations
in this document do not preclude the continued use of ASM within a
single organisation or domain.
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 September 30, 2018.
Copyright Notice
Copyright (c) 2018 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
Abrahamsson, et al. Expires September 30, 2018 [Page 1]
Internet-Draft Deprecating Interdomain ASM March 2018
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Multicast routing protocols . . . . . . . . . . . . . . . . . 3
2.1. ASM routing protocols . . . . . . . . . . . . . . . . . . 3
2.2. SSM Routing protocols . . . . . . . . . . . . . . . . . . 4
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Observations on ASM and SSM deployments . . . . . . . . . 4
3.2. Advantages of SSM for interdomain multicast . . . . . . . 5
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Deprecating use of ASM for interdomain multicast . . . . 6
4.2. Including network support for IGMPv3 / MLDv2 . . . . . . 6
4.3. Building application support for SSM . . . . . . . . . . 7
4.4. Standardising an ASM/SSM protocol mapping mechanism . . . 7
4.5. Not filtering ASM addressing between domains . . . . . . 8
4.6. Not precluding Intradomain ASM . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
IP Multicast has been deployed in various forms, both within private
networks and on the wider Internet. While a number of service models
have been published, and in many cases revised over time, there has
been no strong recommendation made on the appropriateness of those
models to certain scenarios. This document addresses this gap by
making a BCP-level recommendation to deprecate the use of ASM for
interdomain multicast, and thus implictly also that all hosts and
routers that are expected to support such multicast applications
fully support SSM.
This document does not make any statement on the use of ASM within in
a single domain or organisation, and therefore does not preclude its
use. Indeed, there may be a number of application contexts for which
ASM is currently still considered well-suited within a single domain.
Abrahamsson, et al. Expires September 30, 2018 [Page 2]
Internet-Draft Deprecating Interdomain ASM March 2018
2. Multicast routing protocols
The general IP multicast service model [RFC1112] is that sender(s)
send to a multicast group address, receivers express an interest in
traffic sent to a given multicast group address, and that routers use
multicast routing protocols to determine how to deliver traffic from
the sender(s) to the receivers.
Two high-level flavours of this service model have evolved over time.
In Any-Source Multicast (ASM), any number of sources may transmit
multicast packets, and those sources may come and go over the course
of a multicast session without being known a priori. In ASM,
receivers express interest only in a given multicast group address,
and the multicast routing protocol facilitates source discovery at
the network layer. In contrast, with Source-Specific Multicast (SSM)
the specific source(s) that may send traffic to the group are known
in advance, or may be determined during a session, typically through
an out-of-band protocol sitting above the network layer. Thus in
SSM, receivers express interest in both a multicast group address and
specific associated source address(es).
IANA has reserved specific ranges of IPv4 and IPv6 address space for
multicast addressing. Guidelines for IPv4 multicast address
assignments can be found in [RFC5771], while guidelines for IPv6
multicast address assignments can be found in [RFC2375] and
[RFC3307]. The IPv6 multicast address format is described in
[RFC4291].
2.1. ASM routing protocols
The most commonly deployed ASM routing protocol is Protocol
Independent Multicast - Sparse Mode, or PIM-SM, as detailed in
[RFC7761]. PIM-SM, as the name suggests, was designed to be used in
scenarios where the subnets with receivers are sparsely distributed
throughout the network. Because it does not know sender addresses in
advance, PIM-SM uses the concept of a Rendezvous Point (RP) to 'marry
up' senders and receivers, where all routers in a PIM-SM domain are
configured to use specific RP(s).
To enable PIM-SM to work between multiple domains, i.e. to allow an
RP in one domain to learn the existence of a source in another
domain, an inter-RP signalling protocol known as Multicast Source
Discovery Protocol (MSDP) [RFC3618] is used. Deployment scenarios
for MSDP are given in [RFC4611]. MSDP has remained an Experimental
protocol since its publication in 2003, and was not replicated or
carried forward for IPv6.
Abrahamsson, et al. Expires September 30, 2018 [Page 3]
Internet-Draft Deprecating Interdomain ASM March 2018
In the absence of MSDP, a new mechanism, Embedded-RP [RFC3956], was
defined for IPv6 PIM-SM, which allows routers supporting the protocol
to determine the RP for the group without any prior configuration,
simply by observing the RP address that is embedded (included) in the
IPv6 multicast group address. Embedded-RP allows PIM-SM operation
across any IPv6 network in which there is an end-to-end path of
routers supporting the protocol.
2.2. SSM Routing protocols
PIM-SSM is detailed in [RFC4607]. In contrast to PIM-SM, PIM-SSM
benefits from sender source address(es) being known about in advance,
i.e. a given source's IP address is known (by some out of band
mechanism), and thus the receiver's router can send a PIM JOIN
directly towards the sender, without needing to use an RP.
IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are
designated as source-specific multicast (SSM) destination addresses
and are reserved for use by source-specific applications and
protocols. For IPv6, the address prefix FF3x::/32 is reserved for
source-specific multicast use.
3. Discussion
3.1. Observations on ASM and SSM deployments
In enterprise and campus scenarios, ASM in the form of PIM-SM is in
relatively common use, and has generally replaced PIM-DM [RFC3973].
The configuration and management of an RP within a single domain is
not onerous. However, if interworking with external PIM domains in
IPv4 multicast deployments is needed, MSDP is required to exchange
information between domain RPs about sources. MSDP remains an
Experimental protocol, and can be a complex and fragile protocol to
administer and troubleshoot.
PIM-SM is a general purpose protocol that can handle all use cases.
In particular, it was designed for cases such as videoconferencing
where multiple sources may come and go during a multicast session.
But for cases where a single, persistent source is used, and
receivers can be configured to know of that source, PIM-SM has
unnecessary complexity.
MSDP was not taken forward to IPv6. Instead, IPv6 has Embedded-RP,
which allows the RP address for a multicast group to be embedded in
the group address, making RP discovery automatic, if all routers on
the path between a receiver and a sender support the protocol.
Embedded-RP can support lightweight ad-hoc deployments. However, it
relies on a single RP for an entire group. Embedded-RP was run
Abrahamsson, et al. Expires September 30, 2018 [Page 4]
Internet-Draft Deprecating Interdomain ASM March 2018
successfully between European and US academic networks during the
6NET project in 2004/05. Its usage generally remains constrained to
academic networks.
As stated in RFC 4607, SSM is particularly well-suited to
dissemination-style applications with one or more senders whose
identities are known (by some mechanism) before the application
starts running. PIM-SSM is therefore very well-suited to
applications such as classic linear broadcast TV over IP.
SSM requires hosts and their subnet routers using it support the
new(er) IGMPv3 [RFC3376] and MLDv2 [RFC3810] protocols. While
delayed delivery of support in some OSes has meant that adoption of
SSM has also been slower than might have been expected, or hoped, and
was a historical reason to use ASM rather than SSM, support for
IGMPv3 and MLDv2 is now widespread in common OSes.
3.2. Advantages of SSM for interdomain multicast
A significant benefit of SSM is its reduced complexity through
eliminating the network-based source discovery required in ASM. This
means there are no RPs, shared trees, Shortest Path Tree (SPT)
switchovers, PIM registers, MSDP or data-driven state creation
elements to support. SSM is really just a small subset of PIM-SM,
plus IGMPv3 / MLDv2.
This reduced complexity makes SSM radically simpler to manage,
troubleshoot and operate, particularly for network backbone
operators, and this is the main motivation for the recommendation to
deprecate the use of ASM in interdomain scenarios. Interdomain ASM
is widely viewed as complicated and fragile. By eliminating network-
based source discovery for interdomain multicast, the vast majority
of the complexity issues go away.
RFC 4607 details many benefits of SSM, including:
"Elimination of cross-delivery of traffic when two sources
simultaneously use the same source-specific destination address;
Avoidance of the need for inter-host coordination when choosing
source-specific addresses, as a consequence of the above;
Avoidance of many of the router protocols and algorithms that are
needed to provide the ASM service model."
Further discussion can also be found in [RFC3569].
Abrahamsson, et al. Expires September 30, 2018 [Page 5]
Internet-Draft Deprecating Interdomain ASM March 2018
SSM is considered more secure in that it supports access control,
i.e. you only get packets from the sources you explicitly ask for, as
opposed to ASM where anyone can decide to send traffic to a PIM-SM
group address. This topic is expanded upon in [RFC4609].
4. Recommendations
4.1. Deprecating use of ASM for interdomain multicast
This document recommends that the use of ASM is deprecated for
interdomain multicast, and thus implictly that hosts and routers that
are expected to support such interdomain applications fully support
SSM. Best current practices for deploying interdomain multicast
using SSM are documented in [RFC8313]
The recommendation applies to the use of ASM between domains where
either MSDP (IPv4) or Embedded-RP (IPv6) is required for sharing
knowledge of remote sources. It also recommends against the multi-
domain use of an ASM group with a single RP in one domain, where
multicast tunnels are used between domains.
While MSDP is an Experimental level standard, this document does not
propose making MSDP Historic, given its use may be desirable for
intradomain multicast use cases.
4.2. Including network support for IGMPv3 / MLDv2
This document recommends that all host and router platforms
supporting multicast, and any security appliances that may handle
multicat traffic, support IGMPv3 [RFC3376] and MLDv2 [RFC3810]. The
updated IPv6 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] states
that MLDv2 support is a MUST in all implementations. Such support is
already widespread in common host and router platforms.
Further guidance on IGMPv3 and MLDv2 is given in [RFC4604].
It is sometimes desirable to limit the propagation of multicast
messages in a layer 2 network, typically through a layer 2 switch
device. In such cases multicast snooping can be used, by which the
switch device observes the IGMP/MLD traffic passing through it, and
then attempts to make intelligent decisions on which physical ports
to forward multicast. Typically, ports that have not expressed an
interest in receiving multicast for a given group would not have
traffic for that group forwarded through them. Such snooping
capability should support IGMPv3 and MLDv2. There is further
discussion in [RFC4541].
Abrahamsson, et al. Expires September 30, 2018 [Page 6]
Internet-Draft Deprecating Interdomain ASM March 2018
4.3. Building application support for SSM
There will be a wide range of applications today that only support
ASM, whether as software packages, or code embedded in devices such
as set-top boxes.
The implicit recommendation to use SSM for interdomain multicast
means that applications should use SSM, and operate correctly in an
SSM environment, triggering IGMPv3/MLDv2 messages to signal use of
SSM.
It is often thought that ASM is required for multicast applications
where there are multiple sources. However, RFC 4607 also describes
how SSM can be used instead of PIM-SM for multi-party applications:
"SSM can be used to build multi-source applications where all
participants' identities are not known in advance, but the multi-
source "rendezvous" functionality does not occur in the network
layer in this case. Just like in an application that uses unicast
as the underlying transport, this functionality can be implemented
by the application or by an application-layer library."
Given all common OSes support SSM, it is then down to the programming
language and APIs used as to whether the necessary SSM APIs are
available. SSM support is generally quite ubiquitous, with the
current exception of websockets used in web-browser based
applications.
It is desirable that applications also support appropriate congestion
control, as described in [RFC8085], with appropriate codecs, to
achieve the necessary rate adaption.
Some useful considerations for multicast applications can still be
found in the relatively old [RFC3170].
4.4. Standardising an ASM/SSM protocol mapping mechanism
In the case of existing ASM applications that cannot readily be
ported to SSM, it may be possible to use some form of protocol
mapping, i.e., to have a mechanism to translate a (*,G) join or leave
to a (S,G) join or leave, for a specific source, S. The general
challenge in performing such mapping is determining where the
configured source address, S, comes from.
There are some existing vendor-specific mechanisms to achieve this
function, but none are documented in IETF standards. This appears ti
be a useful area for the IETF to work on, but it should be noted that
any such effort would only be an interim transition mechanism, and
Abrahamsson, et al. Expires September 30, 2018 [Page 7]
Internet-Draft Deprecating Interdomain ASM March 2018
such mappings do not remove the requirement for applications to be
allocated ASM group addresses for the communications.
4.5. Not filtering ASM addressing between domains
A key benefit of SSM is that the multicast application does not need
to be allocated a specific multicast group by the network, rather as
SSM is inherently source-specific, it can use any group address, G,
in the reserved range of IPv4 or IPv6 SSM addresses for its own
source address, S.
In principle, if interdomain ASM is deprecated, backbone operators
could begin filtering the ranges of group addresses used by ASM. In
practice, this is not recommended given there will be a transition
period from ASM to SSM, where some form of ASM-SSM mappings may be
used, and filtering may preclude such operations.
4.6. Not precluding Intradomain ASM
The use of ASM within a single multicast domain, such as an
enterprise or campus, with an RP for the site, is still relatively
common today. The operators of such a site may choose to use
Anycast-RP [RFC4610] or MSDP for internal RP resilience, at the
expense of the extra complexity in managing that configuration.
This document does not preclude continued use of ASM in the
intradomain scenario. If an organisation, or AS, wishes to use
multiple multicast domains within its own network border, that is a
choice for that organisation to make, and it may then use MSDP or
Embedded-RP internally within its own network.
5. Security Considerations
This document adds no new security considerations. RFC 4609
describes the additional security benefits of using SSM instead of
ASM.
6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed upon publication as
an RFC.
Abrahamsson, et al. Expires September 30, 2018 [Page 8]
Internet-Draft Deprecating Interdomain ASM March 2018
7. Acknowledgments
The authors would like to thank members of the IETF mboned WG for
discussions on the content of this document, with specific thanks to
the following people for their contributions to the document: Hitoshi
Asaeda, Dale Carder, Toerless Eckert, Jake Holland, Albert Manfredi,
Mike McBride, Per Nihlen, Greg Shepherd, James Stevens, Stig Venaas,
Nils Warnke, and Sandy Zhang.
8. References
8.1. Normative References
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998,
<https://www.rfc-editor.org/info/rfc2375>.
[RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications:
Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170,
September 2001, <https://www.rfc-editor.org/info/rfc3170>.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002,
<https://www.rfc-editor.org/info/rfc3307>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>.
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July
2003, <https://www.rfc-editor.org/info/rfc3569>.
[RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
Discovery Protocol (MSDP)", RFC 3618,
DOI 10.17487/RFC3618, October 2003,
<https://www.rfc-editor.org/info/rfc3618>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
Abrahamsson, et al. Expires September 30, 2018 [Page 9]
Internet-Draft Deprecating Interdomain ASM March 2018
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, DOI 10.17487/RFC3956, November 2004,
<https://www.rfc-editor.org/info/rfc3956>.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973,
January 2005, <https://www.rfc-editor.org/info/rfc3973>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>.
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
Independent Multicast (PIM)", RFC 4610,
DOI 10.17487/RFC4610, August 2006,
<https://www.rfc-editor.org/info/rfc4610>.
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
DOI 10.17487/RFC5771, March 2010,
<https://www.rfc-editor.org/info/rfc5771>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
8.2. Informative References
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
<https://www.rfc-editor.org/info/rfc4541>.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
August 2006, <https://www.rfc-editor.org/info/rfc4604>.
Abrahamsson, et al. Expires September 30, 2018 [Page 10]
Internet-Draft Deprecating Interdomain ASM March 2018
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements", RFC 4609,
DOI 10.17487/RFC4609, October 2006,
<https://www.rfc-editor.org/info/rfc4609>.
[RFC4611] McBride, M., Meylor, J., and D. Meyer, "Multicast Source
Discovery Protocol (MSDP) Deployment Scenarios", BCP 121,
RFC 4611, DOI 10.17487/RFC4611, August 2006,
<https://www.rfc-editor.org/info/rfc4611>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T.,
Ed., and R. Krishnan, "Use of Multicast across Inter-
domain Peering Points", BCP 213, RFC 8313,
DOI 10.17487/RFC8313, January 2018,
<https://www.rfc-editor.org/info/rfc8313>.
[I-D.ietf-6man-rfc6434-bis]
Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", draft-ietf-6man-rfc6434-bis-08 (work in
progress), March 2018.
Authors' Addresses
Mikael Abrahamsson
T-Systems
Stockholm
Sweden
Email: mikael.abrahamsson@t-systems.se
Tim Chown
Jisc
Lumen House, Library Avenue
Harwell Oxford, Didcot OX11 0SG
United Kingdom
Email: tim.chown@jisc.ac.uk
Abrahamsson, et al. Expires September 30, 2018 [Page 11]
Internet-Draft Deprecating Interdomain ASM March 2018
Lenny Giuliano
Juniper Networks, Inc.
2251 Corporate Park Drive
Hemdon, Virginia 20171
United States
Email: lenny@juniper.net
Abrahamsson, et al. Expires September 30, 2018 [Page 12]