draft-ietf-mboned-deprecate-interdomain-asm-06.txt   draft-ietf-mboned-deprecate-interdomain-asm-07.txt 
Mboned M. Abrahamsson Mboned M. Abrahamsson
Internet-Draft Internet-Draft
Intended status: Best Current Practice T. Chown Intended status: Best Current Practice T. Chown
Expires: July 6, 2020 Jisc Expires: September 10, 2020 Jisc
L. Giuliano L. Giuliano
Juniper Networks, Inc. Juniper Networks, Inc.
T. Eckert T. Eckert
Futurewei Technologies Inc. Futurewei Technologies Inc.
January 3, 2020 March 9, 2020
Deprecating ASM for Interdomain Multicast Deprecating ASM for Interdomain Multicast
draft-ietf-mboned-deprecate-interdomain-asm-06 draft-ietf-mboned-deprecate-interdomain-asm-07
Abstract Abstract
This document recommends deprecation of the use of Any-Source This document recommends deprecation of the use of Any-Source
Multicast (ASM) for interdomain multicast. It recommends the use of Multicast (ASM) for interdomain multicast. It recommends the use of
Source-Specific Multicast (SSM) for interdomain multicast Source-Specific Multicast (SSM) for interdomain multicast
applications and recommends that hosts and routers in these applications and recommends that hosts and routers in these
deployments fully support SSM. The recommendations in this document deployments fully support SSM. The recommendations in this document
do not preclude the continued use of ASM within a single organisation do not preclude the continued use of ASM within a single organisation
or domain and are especially easy to adopt in existing intradomain or domain and are especially easy to adopt in existing intradomain
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 6, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
2.1. Multicast service models . . . . . . . . . . . . . . . . 3 2.1. Multicast service models . . . . . . . . . . . . . . . . 3
2.2. ASM routing protocols . . . . . . . . . . . . . . . . . . 4 2.2. ASM routing protocols . . . . . . . . . . . . . . . . . . 4
2.2.1. PIM Sparse Mode (PIM-SM) . . . . . . . . . . . . . . 4 2.2.1. PIM Sparse Mode (PIM-SM) . . . . . . . . . . . . . . 4
2.2.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 4 2.2.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 4
2.2.3. Bidir-RP . . . . . . . . . . . . . . . . . . . . . . 5 2.2.3. Bidir-RP . . . . . . . . . . . . . . . . . . . . . . 5
2.3. SSM Routing protocols . . . . . . . . . . . . . . . . . . 5 2.3. SSM Routing protocols . . . . . . . . . . . . . . . . . . 5
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Observations on ASM and SSM deployments . . . . . . . . . 5 3.1. Observations on ASM and SSM deployments . . . . . . . . . 5
3.2. Advantages of SSM for interdomain multicast . . . . . . . 6 3.2. Advantages of SSM for interdomain multicast . . . . . . . 6
3.2.1. Reduced network operations complexity . . . . . . . . 7 3.2.1. Reduced network operations complexity . . . . . . . . 7
3.2.2. No network wide IP multicast group-address management 7 3.2.2. No network-wide IP multicast group-address management 7
3.2.3. Intrinsic source-control security . . . . . . . . . . 7 3.2.3. Intrinsic source-control security . . . . . . . . . . 7
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Deprecating use of ASM for interdomain multicast . . . . 8 4.1. Deprecating use of ASM for interdomain multicast . . . . 8
4.2. Including network support for IGMPv3/MLDv2 . . . . . . . 8 4.2. Including network support for IGMPv3/MLDv2 . . . . . . . 9
4.3. Building application support for SSM . . . . . . . . . . 9 4.3. Building application support for SSM . . . . . . . . . . 9
4.4. Developing application guidance: SSM, ASM, service 4.4. Developing application guidance: SSM, ASM, service
discovery . . . . . . . . . . . . . . . . . . . . . . . . 9 discovery . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Preferring SSM applications intradomain . . . . . . . . . 10 4.5. Preferring SSM applications intradomain . . . . . . . . . 10
4.6. Documenting an ASM/SSM protocol mapping mechanism . . . . 10 4.6. Documenting an ASM/SSM protocol mapping mechanism . . . . 10
4.7. Not filtering ASM addressing between domains . . . . . . 10 4.7. Not filtering ASM addressing between domains . . . . . . 11
4.8. Not precluding Intradomain ASM . . . . . . . . . . . . . 11 4.8. Not precluding Intradomain ASM . . . . . . . . . . . . . 11
4.9. Evolving PIM deployments for SSM . . . . . . . . . . . . 11 4.9. Evolving PIM deployments for SSM . . . . . . . . . . . . 11
5. Future interdomain ASM work . . . . . . . . . . . . . . . . . 12 5. Future interdomain ASM work . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
IP Multicast has been deployed in various forms, within private IP Multicast has been deployed in various forms, within private
networks, the wider Internet, and federated networks such as national networks, the wider Internet, and federated networks such as national
or regional research networks. While a number of service models have or regional research networks. While a number of service models have
been published, and in many cases revised over time, there has been been published, and in many cases revised over time, there has been
no strong recommendation made by the IETF on the appropriateness of no strong recommendation made by the IETF on the appropriateness of
those models to certain scenarios, even though vendors and those models to certain scenarios, even though vendors and
federations have often made such recommendations. federations have often made such recommendations.
skipping to change at page 3, line 45 skipping to change at page 3, line 45
2. Background 2. Background
2.1. Multicast service models 2.1. Multicast service models
Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) are Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) are
the two multicast service models in use today. In ASM, as originally the two multicast service models in use today. In ASM, as originally
described in [RFC1112], receivers express interest in joining a described in [RFC1112], receivers express interest in joining a
multicast group address and routers use multicast routing protocols multicast group address and routers use multicast routing protocols
to deliver traffic from the sender(s) to the receivers. If there are to deliver traffic from the sender(s) to the receivers. If there are
multiple senders for a given group, traffic from all senders will be multiple senders for a given group, traffic from all senders will be
delivered to the receiver. Since receivers specify only the group delivered to the receivers. Since receivers specify only the group
address, the network, and therefore the multicast routing protocols, address, the network, and therefore the multicast routing protocols,
are responsible for source discovery. are responsible for source discovery.
In SSM, by contrast, receivers specify both group and source when In SSM, by contrast, receivers specify both group and source when
expressing interest in joining a multicast stream. Source discovery expressing interest in joining a multicast stream. Source discovery
in SSM is handled by some out-of-band mechanism (i.e., the in SSM is handled by some out-of-band mechanism in the application
application layer), which drastically simplifies the network and how layer, which drastically simplifies the network and how the multicast
the multicast routing protocols operate. routing protocols operate.
IANA has reserved specific ranges of IPv4 and IPv6 address space for IANA has reserved specific ranges of IPv4 and IPv6 address space for
multicast addressing. Guidelines for IPv4 multicast address multicast addressing. Guidelines for IPv4 multicast address
assignments can be found in [RFC5771], while guidelines for IPv6 assignments can be found in [RFC5771], while guidelines for IPv6
multicast address assignments can be found in [RFC2375] and multicast address assignments can be found in [RFC2375] and
[RFC3307]. The IPv6 multicast address format is described in [RFC3307]. The IPv6 multicast address format is described in
[RFC4291]. [RFC4291].
2.2. ASM routing protocols 2.2. ASM routing protocols
skipping to change at page 4, line 40 skipping to change at page 4, line 40
inter-RP signalling protocol known as Multicast Source Discovery inter-RP signalling protocol known as Multicast Source Discovery
Protocol (MSDP) [RFC3618] is used to allow an RP in one domain to Protocol (MSDP) [RFC3618] is used to allow an RP in one domain to
learn the existence of a source in another domain. Deployment learn the existence of a source in another domain. Deployment
scenarios for MSDP are given in [RFC4611]. MSDP floods information scenarios for MSDP are given in [RFC4611]. MSDP floods information
about all active sources for all multicast streams to all RPs in all about all active sources for all multicast streams to all RPs in all
the domains - even if there is no receiver for a given application in the domains - even if there is no receiver for a given application in
a domain. As a result of this key scalability and security issue, a domain. As a result of this key scalability and security issue,
along with other deployment challenges with the protocol, MSDP was along with other deployment challenges with the protocol, MSDP was
never extended to support IPv6 and remains an Experimental protocol. never extended to support IPv6 and remains an Experimental protocol.
To this day, there is no IETF Proposed Standard level interdomain At the time of writing, there is no IETF Proposed Standard level
solution for IPv4 ASM multicast because MSDP was the de facto interdomain solution for IPv4 ASM multicast because MSDP was the de
mechanism for the interdomain source discovery problem, and it is facto mechanism for the interdomain source discovery problem, and it
Experimental. Other protocol options were investigated at the same is Experimental. Other protocol options were investigated at the
time but were never implemented or deployed and are now historic same time but were never implemented or deployed and are now historic
(e.g: [RFC3913]). (e.g: [RFC3913]).
2.2.2. Embedded-RP 2.2.2. Embedded-RP
Due to the availability of more bits in an IPv6 address than in IPv4, Due to the availability of more bits in an IPv6 address than in IPv4,
an IPv6-specific mechanism was designed in support of interdomain ASM an IPv6-specific mechanism was designed in support of interdomain ASM
with PIM-SM leveraging those bits. Embedded-RP [RFC3956] allows with PIM-SM leveraging those bits. Embedded-RP [RFC3956] allows
routers supporting the protocol to determine the RP for the group routers supporting the protocol to determine the RP for the group
without any prior configuration or discovery protocols, simply by without any prior configuration or discovery protocols, simply by
observing the unicast RP address that is embedded (included) in the observing the unicast RP address that is embedded (included) in the
skipping to change at page 5, line 25 skipping to change at page 5, line 25
intradomain for applications where many sources send traffic to the intradomain for applications where many sources send traffic to the
same IP multicast groups because unlike PIM-SM it does not create same IP multicast groups because unlike PIM-SM it does not create
per-source state. Bidir-PIM is one of the important reasons for this per-source state. Bidir-PIM is one of the important reasons for this
document to not deprecate intradomain ASM. document to not deprecate intradomain ASM.
2.3. SSM Routing protocols 2.3. SSM Routing protocols
SSM is detailed in [RFC4607]. It mandates the use of PIM-SSM for SSM is detailed in [RFC4607]. It mandates the use of PIM-SSM for
routing of SSM. PIM-SSM is merely a subset of PIM-SM ([RFC7761]). routing of SSM. PIM-SSM is merely a subset of PIM-SM ([RFC7761]).
PIM-SSM expects that the sender's source address(es) is known in PIM-SSM expects the sender's source address(es) to be known in
advance by receivers through some out-of-band mechanism (typically in advance by receivers through some out-of-band mechanism (typically in
the application layer), and thus the receiver's designated router can the application layer), and thus the receiver's designated router can
send a PIM JOIN directly towards the source without needing to use an send a PIM JOIN directly towards the source without needing to use an
RP. RP.
IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 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 designated as source-specific multicast (SSM) destination addresses
and are reserved for use by source-specific applications and and are reserved for use by source-specific applications and
protocols. See [RFC4607]. For IPv6, the address prefix ff3x::/32 is protocols. See [RFC4607]. For IPv6, the address prefix ff3x::/32 is
reserved for source-specific multicast use. reserved for source-specific multicast use.
skipping to change at page 5, line 49 skipping to change at page 5, line 49
3.1. Observations on ASM and SSM deployments 3.1. Observations on ASM and SSM deployments
In enterprise and campus scenarios, ASM in the form of PIM-SM is In enterprise and campus scenarios, ASM in the form of PIM-SM is
likely the most commonly deployed multicast protocol. The likely the most commonly deployed multicast protocol. The
configuration and management of an RP (including RP redundancy) configuration and management of an RP (including RP redundancy)
within a single domain is a well understood operational practice. within a single domain is a well understood operational practice.
However, if interworking with external PIM domains is needed in IPv4 However, if interworking with external PIM domains is needed in IPv4
multicast deployments, interdomain MSDP is required to exchange multicast deployments, interdomain MSDP is required to exchange
information about sources between domain RPs. Deployment experience information about sources between domain RPs. Deployment experience
has shown MSDP to be a complex and fragile protocol to manage and has shown MSDP to be a complex and fragile protocol to manage and
troubleshoot. Some of these issues include complex flooding Reverse troubleshoot. Some of these issues include complex Reverse Path
Path Forwarding (RPF) rules, state attack protection, and filtering Forwarding (RPF) rules, state attack protection, and filtering of
of undesired sources. undesired sources.
PIM-SM is a general purpose protocol that can handle all use cases. PIM-SM is a general purpose protocol that can handle all use cases.
In particular, it was designed for cases such as videoconferencing In particular, it was designed for cases such as videoconferencing
where multiple sources may come and go during a multicast session. where multiple sources may come and go during a multicast session.
But for cases where a single, persistent source for a group is used, But for cases where a single, persistent source for a group is used,
and receivers can be configured to know of that source, PIM-SM has and receivers can be configured to know of that source, PIM-SM has
unnecessary complexity. Therefore, SSM removes the need for many of unnecessary complexity. Therefore, SSM removes the need for many of
the most complex components of PIM-SM. the most complex components of PIM-SM.
As explained above, MSDP was not extended to support IPv6. Instead, As explained above, MSDP was not extended to support IPv6. Instead,
skipping to change at page 7, line 30 skipping to change at page 7, line 30
operators. This is the main operator motivation for the operators. This is the main operator motivation for the
recommendation to deprecate the use of ASM in interdomain scenarios. recommendation to deprecate the use of ASM in interdomain scenarios.
Note that this discussion does not apply to Bidir-PIM, and there is Note that this discussion does not apply to Bidir-PIM, and there is
(as mentioned above) no standardized interdomain solution for Bidir- (as mentioned above) no standardized interdomain solution for Bidir-
PIM. In Bidir-PIM, traffic is forwarded to the RP instead of PIM. In Bidir-PIM, traffic is forwarded to the RP instead of
building state as in PIM-SM. This occurs even in the absence of building state as in PIM-SM. This occurs even in the absence of
receivers. Bidir-PIM therefore trades state complexity with receivers. Bidir-PIM therefore trades state complexity with
unnecessary traffic (potentially a large amount). unnecessary traffic (potentially a large amount).
3.2.2. No network wide IP multicast group-address management 3.2.2. No network-wide IP multicast group-address management
In ASM, IP multicast group addresses need to be assigned to In ASM, IP multicast group addresses need to be assigned to
applications and instances thereof, so that two simultaneously active applications and instances thereof, so that two simultaneously active
application instances will not share the same group address and application instances will not share the same group address and
receive IP multicast traffic from each other. receive IP multicast traffic from each other.
In SSM, no such IP multicast group management is necessary. Instead, In SSM, no such IP multicast group management is necessary. Instead,
the IP multicast group address simply needs to be assigned locally on the IP multicast group address simply needs to be assigned locally on
a source like a unicast transport protocol port number: the only a source like a unicast transport protocol port number: the only
coordination required is to ensure that different applications coordination required is to ensure that different applications
skipping to change at page 8, line 7 skipping to change at page 8, line 7
SSM is implicitly secure against off-path unauthorized/undesired SSM is implicitly secure against off-path unauthorized/undesired
sources. Receivers only receive packets from the sources they sources. Receivers only receive packets from the sources they
explicitly specify in their IGMPv3/MLDv2 membership messages, as explicitly specify in their IGMPv3/MLDv2 membership messages, as
opposed to ASM where any host can send traffic to a group address and opposed to ASM where any host can send traffic to a group address and
have it transmitted to all receivers. With PIM-SSM, traffic from have it transmitted to all receivers. With PIM-SSM, traffic from
sources not requested by any receiver will be discarded by the first- sources not requested by any receiver will be discarded by the first-
hop router (FHR) of that source, minimizing source attacks against hop router (FHR) of that source, minimizing source attacks against
shared network bandwidth and receivers. shared network bandwidth and receivers.
This benefit is particularily important in interdomain deployments This benefit is particularly important in interdomain deployments
because there are no standardized solutions for ASM control of because there are no standardized solutions for ASM control of
sources and the most common intradomain operational practices such as sources and the most common intradomain operational practices such as
Access Control Lists (ACL) on the sender's FHR are not feasible for Access Control Lists (ACL) on the sender's FHR are not feasible for
interdomain deployments. interdomain deployments.
This topic is expanded upon in [RFC4609]. This topic is expanded upon in [RFC4609].
4. Recommendations 4. Recommendations
This section provides recommendations for a variety of stakeholders
in SSM deployment, including vendors, operators and application
developers, and also suggests further work that could be undertaken
within the IETF.
4.1. Deprecating use of ASM for interdomain multicast 4.1. Deprecating use of ASM for interdomain multicast
This document recommends that the use of ASM is deprecated for This document recommends that the use of ASM be deprecated for
interdomain multicast, and thus implicitly, that hosts and routers interdomain multicast, and thus implicitly, that hosts and routers
that support such interdomain applications fully support SSM and its that support such interdomain applications fully support SSM and its
associated protocols. Best current practices for deploying associated protocols. Best current practices for deploying
interdomain multicast using SSM are documented in [RFC8313]. interdomain multicast using SSM are documented in [RFC8313].
The recommendation applies to the use of ASM between domains where The recommendation applies to the use of ASM between domains where
either MSDP (IPv4) or Embedded-RP (IPv6) is used. either MSDP (IPv4) or Embedded-RP (IPv6) is used.
An interdomain use of ASM multicast in the context of this document An interdomain use of ASM multicast in the context of this document
is one where PIM-SM with RPs/MSDP/Embedded-RP is run on routers is one where PIM-SM with RPs/MSDP/Embedded-RP is run on routers
operated by two or more separate administrative entities. operated by two or more separate administrative entities.
The more inclusive interpretation of this recommendation is that it The focus of this document is deprecation of inter-domain ASM
multicast, and while encouraging the use of SSM within domains, it
leaves operators free to choose to use ASM within their own domains.
A more inclusive interpretation of this recommendation is that it
also extends to deprecating use of ASM in the case where PIM is also extends to deprecating use of ASM in the case where PIM is
operated in a single operator domain, but where user hosts or non-PIM operated in a single operator domain, but where user hosts or non-PIM
network edge devices are under different operator control. A typical network edge devices are under different operator control. A typical
example of this case is a service provider offering IPTV (single example of this case is a service provider offering IPTV (single
operator domain for PIM) to subscribers operating an IGMP proxy home operator domain for PIM) to subscribers operating an IGMP proxy home
gateway and IGMPv3/MLDv2 hosts (computer, tablets, set-top boxes). gateway and IGMPv3/MLDv2 hosts (computer, tablets, set-top boxes).
4.2. Including network support for IGMPv3/MLDv2 4.2. Including network support for IGMPv3/MLDv2
This document recommends that all hosts, router platforms and This document recommends that all hosts, router platforms and
security appliances used for deploying multicast support the security appliances used for deploying multicast support the
components of IGMPv3 [RFC3376] and MLDv2 [RFC3810] necessary to components of IGMPv3 [RFC3376] and MLDv2 [RFC3810] necessary to
support SSM (i.e., explicitly sending source-specific reports). The support SSM (i.e., explicitly sending source-specific reports). The
updated IPv6 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] states updated IPv6 Node Requirements RFC [RFC8504] states that MLDv2 must
that MLDv2 must be supported in all implementations. Such support is be supported in all implementations. Such support is already
already widespread in common host and router platforms. widespread in common host and router platforms.
Further guidance on IGMPv3 and MLDv2 is given in [RFC4604]. Further guidance on IGMPv3 and MLDv2 is given in [RFC4604].
Multicast snooping is often used to limit the flooding of multicast Multicast snooping is often used to limit the flooding of multicast
traffic in a layer 2 network. With snooping, a L2 switch will traffic in a layer 2 network. With snooping, a L2 switch will
monitor IGMP/MLD messages and only forward multicast traffic out on monitor IGMP/MLD messages and only forward multicast traffic out on
host ports that have interested receivers connected. Such snooping host ports that have interested receivers connected. Such snooping
capability should therefore support IGMPv3 and MLDv2. There is capability should therefore support IGMPv3 and MLDv2. There is
further discussion in [RFC4541]. further discussion in [RFC4541].
4.3. Building application support for SSM 4.3. Building application support for SSM
The recommendation to use SSM for interdomain multicast means that The recommendation to use SSM for interdomain multicast means that
applications should properly trigger the sending of IGMPv3/MLDv2 applications should properly trigger the sending of IGMPv3/MLDv2
source-specific report messages. It should be noted, however, there source-specific report messages. It should be noted, however, there
is a wide range of applications today that only support ASM. In many is a wide range of applications today that only support ASM. In many
cases this is due to application developers being unaware of the cases this is due to application developers being unaware of the
operational concerns of networks. This document serves to provide operational concerns of networks, and the implications of using ASM
clear direction for application developers to support SSM. versus using SSM. This document serves to provide clear direction
for application developers who might currently only consider using
ASM to instead support SSM, which only requires relatively minor
changes for many applications, particularly those with single
sources.
It is often thought that ASM is required for multicast applications It is often thought that ASM is required for multicast applications
where there are multiple sources. However, RFC 4607 also describes where there are multiple sources. However, RFC 4607 also describes
how SSM can be used instead of PIM-SM for multi-party applications: how SSM can be used instead of PIM-SM for multi-party applications:
"SSM can be used to build multi-source applications where all "SSM can be used to build multi-source applications where all
participants' identities are not known in advance, but the multi- participants' identities are not known in advance, but the multi-
source "rendezvous" functionality does not occur in the network source "rendezvous" functionality does not occur in the network
layer in this case. Just like in an application that uses unicast layer in this case. Just like in an application that uses unicast
as the underlying transport, this functionality can be implemented as the underlying transport, this functionality can be implemented
skipping to change at page 10, line 5 skipping to change at page 10, line 22
Instead, these applications are better served by routing protocols Instead, these applications are better served by routing protocols
that do not create (S,G), such as Bidir-PIM. Unfortunately, today that do not create (S,G), such as Bidir-PIM. Unfortunately, today
many applications use ASM solely for service discovery. One example many applications use ASM solely for service discovery. One example
is where clients send IP multicast packets to elicit unicast replies is where clients send IP multicast packets to elicit unicast replies
from server(s). Deploying any form of IP multicast solely in support from server(s). Deploying any form of IP multicast solely in support
of such service discovery is in general not recommended. Dedicated of such service discovery is in general not recommended. Dedicated
service discovery via DNS-SD [RFC6763] should be used for this service discovery via DNS-SD [RFC6763] should be used for this
instead. instead.
While the WG discussions had consensus that best practices should be This document describes best practices to explain when to use SSM in
developed to explain when to use SSM in applications, e.g, when ASM applications, e.g, when ASM without (S,G) state in the network is
without (S,G) state in the network is better, or when dedicated better, or when dedicated service-discovery mechanisms should be
service-discovery mechanisms should be used, it was agreed that used, but specifying these practices is outside the scope of this
documenting such practices are outside the scope of this document. document. Further work on this subject may be expected within the
IETF.
4.5. Preferring SSM applications intradomain 4.5. Preferring SSM applications intradomain
If feasible, it is recommended for applications to use SSM even if If feasible, it is recommended for applications to use SSM even if
they are initially only meant to be used in intradomain environments they are initially only meant to be used in intradomain environments
supporting ASM. Because PIM-SSM is a subset of PIM-SM, existing supporting ASM. Because PIM-SSM is a subset of PIM-SM, existing
intradomain PIM-SM networks are automatically compatible with SSM intradomain PIM-SM networks are automatically compatible with SSM
applications. Thus, SSM applications can operate alongside existing applications. Thus, SSM applications can operate alongside existing
ASM applications. SSM's benefits of simplified address management ASM applications. SSM's benefits of simplified address management
and significantly reduced operational complexity apply equally to and significantly reduced operational complexity apply equally to
skipping to change at page 10, line 31 skipping to change at page 10, line 49
However, for some applications it may be prohibitively difficult to However, for some applications it may be prohibitively difficult to
add support for source discovery, so intradomain ASM may still be add support for source discovery, so intradomain ASM may still be
appropriate. appropriate.
4.6. Documenting an ASM/SSM protocol mapping mechanism 4.6. Documenting an ASM/SSM protocol mapping mechanism
In the case of existing ASM applications that cannot readily be In the case of existing ASM applications that cannot readily be
ported to SSM, it may be possible to use some form of protocol 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 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 to a (S,G) join or leave for a specific source S. The general
challenge in performing such mapping is determining where the challenge in performing such mapping is determining where the
configured source address, S, comes from. configured source address, S, comes from.
There are existing vendor-specific mechanisms deployed that achieve There are existing vendor-specific mechanisms deployed that achieve
this function, but none are documented in IETF documents. This may this function, but none are documented in IETF documents. This may
be a useful area for the IETF to work on as an interim transition be a useful area for the IETF to work on as an interim transition
mechanism. However, these mechanisms would introduce additional mechanism. However, these mechanisms would introduce additional
administrative burdens, along with the need for some form of address administrative burdens, along with the need for some form of address
management, neither of which are required in SSM. Hence, this should management, neither of which are required in SSM. Hence, this should
not be considered a long-term solution. not be considered a long-term solution.
skipping to change at page 11, line 30 skipping to change at page 11, line 49
This document also does not preclude continued use of ASM with This document also does not preclude continued use of ASM with
multiple PIM-SM domains inside organisations, such as with IPv4 MSDP multiple PIM-SM domains inside organisations, such as with IPv4 MSDP
or IPv6 Embedded-RP. This includes organizations that are or IPv6 Embedded-RP. This includes organizations that are
federations and have appropriate, non-standardized mechanisms to deal federations and have appropriate, non-standardized mechanisms to deal
with the interdomain ASM issues explained in Section 3.2. with the interdomain ASM issues explained in Section 3.2.
4.9. Evolving PIM deployments for SSM 4.9. Evolving PIM deployments for SSM
Existing PIM-SM deployments can usually be used to run SSM Existing PIM-SM deployments can usually be used to run SSM
applications with little to no changes. In some widely available applications with little to no changes. In some widely available
router implentations of PIM-SM, PIM-SSM is simply enabled by default router implementations of PIM-SM, PIM-SSM is simply enabled by
in the designated SSM address spaces whenever PIM-SM is enabled. In default in the designated SSM address spaces whenever PIM-SM is
other implementations, simple configuration options exist to enable enabled. In other implementations, simple configuration options
it. This allows easy migration of ASM applications to SSM/PIM-SSM exist to enable it. This allows migration of ASM applications to
solely through application side development to handle source- SSM/PIM-SSM solely through application-side development to handle
signaling via IGMPv3/MLDv2 and using SSM addresses. No network source-signaling via IGMPv3/MLDv2 and using SSM addresses. No
actions are required for this transition; unchanged ASM applications network actions are required for this transition; unchanged ASM
can continue to co-exist without issues. applications can continue to co-exist without issues.
When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also
result in the desired PIM-SSM (S,G) operations and bypass any RP result in the desired PIM-SSM (S,G) operations and bypass any RP
procedures, but this is not standardized but depends on procedures. This is not standardized but depends on implementation
implementation and may require additional configuration in available and may require additional configuration in available products. In
products. In general, it is recommended to always use SSM address general, it is recommended to always use SSM address space for SSM
space for SSM applications. For example, the interaction of IGMPv3/ applications. For example, the interaction of IGMPv3/MLDv2 (S,G)
MLDv2 (S,G) membership reports and Bidir-PIM is undefined and may not membership reports and Bidir-PIM is undefined and may not result in
result in forwarding of any traffic. forwarding of any traffic.
Note that these migration recommendations do not include the Note that these migration recommendations do not include
considerations when or how to evolve those intradomain applications considerations on when or how to evolve those intradomain
best served by ASM/Bidir-PIM from PIM-SM to Bidir-PIM. This may also applications best served by ASM/Bidir-PIM from PIM-SM to Bidir-PIM.
be important but is outside the scope of this document. This may also be important but is outside the scope of this document.
5. Future interdomain ASM work 5. Future interdomain ASM work
Future work may attempt to overcome current limitations of ASM Future work may attempt to overcome current limitations of ASM
solutions, such as interdomain deployment solutions for Bidir-PIM, or solutions, such as interdomain deployment solutions for Bidir-PIM, or
source access control mechanisms for IPv6 PIM-SM with embedded-RP. source access control mechanisms for IPv6 PIM-SM with embedded-RP.
Such work could modify or amend the recommendations of this document Such work could modify or amend the recommendations of this document
(like any future IETF standards/BCP work). (like any future IETF standards/BCP work).
Nevertheless, it is very unlikely that any ASM solution, even with Nevertheless, it is very unlikely that any ASM solution, even with
such future work, can ever provide the same intrinsic security and such future work, can ever provide the same intrinsic security and
network and address management simplicity as SSM (see Section 3.2). network and address management simplicity as SSM (see Section 3.2).
Accordingly, this document recommends that future work for general Accordingly, this document recommends that future work for general-
purpose interdomain IP multicast focus on SSM items listed in purpose interdomain IP multicast focus on SSM items listed in
Section 4. Section 4.
6. Security Considerations 6. Security Considerations
This document adds no new security considerations. It instead This document adds no new security considerations. It instead
removes security issues incurred by interdomain ASM with PIM-SM/MSDP removes security issues incurred by interdomain ASM with PIM-SM/MSDP
such as infrastructure control plane attacks and application and such as infrastructure control plane attacks and application and
bandwidth/congestion attacks from unauthorised sources sending to ASM bandwidth/congestion attacks from unauthorised sources sending to ASM
multicast groups. RFC 4609 describes the additional security multicast groups. RFC 4609 describes the additional security
skipping to change at page 14, line 9 skipping to change at page 14, line 28
<https://www.rfc-editor.org/info/rfc3956>. <https://www.rfc-editor.org/info/rfc3956>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>. <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 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
IPv4 Multicast Address Assignments", BCP 51, RFC 5771, IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
DOI 10.17487/RFC5771, March 2010, DOI 10.17487/RFC5771, March 2010,
<https://www.rfc-editor.org/info/rfc5771>. <https://www.rfc-editor.org/info/rfc5771>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>. 2016, <https://www.rfc-editor.org/info/rfc7761>.
skipping to change at page 15, line 23 skipping to change at page 15, line 36
Listener Discovery Protocol Version 2 (MLDv2) for Source- Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
August 2006, <https://www.rfc-editor.org/info/rfc4604>. August 2006, <https://www.rfc-editor.org/info/rfc4604>.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM) Multicast Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements", RFC 4609, Routing Security Issues and Enhancements", RFC 4609,
DOI 10.17487/RFC4609, October 2006, DOI 10.17487/RFC4609, October 2006,
<https://www.rfc-editor.org/info/rfc4609>. <https://www.rfc-editor.org/info/rfc4609>.
[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>.
[RFC4611] McBride, M., Meylor, J., and D. Meyer, "Multicast Source [RFC4611] McBride, M., Meylor, J., and D. Meyer, "Multicast Source
Discovery Protocol (MSDP) Deployment Scenarios", BCP 121, Discovery Protocol (MSDP) Deployment Scenarios", BCP 121,
RFC 4611, DOI 10.17487/RFC4611, August 2006, RFC 4611, DOI 10.17487/RFC4611, August 2006,
<https://www.rfc-editor.org/info/rfc4611>. <https://www.rfc-editor.org/info/rfc4611>.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<https://www.rfc-editor.org/info/rfc5015>. <https://www.rfc-editor.org/info/rfc5015>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[I-D.ietf-6man-rfc6434-bis] [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
Requirements", draft-ietf-6man-rfc6434-bis-09 (work in January 2019, <https://www.rfc-editor.org/info/rfc8504>.
progress), July 2018.
Authors' Addresses Authors' Addresses
Mikael Abrahamsson Mikael Abrahamsson
Stockholm Stockholm
Sweden Sweden
Email: swmike@swm.pp.se Email: swmike@swm.pp.se
Tim Chown Tim Chown
Jisc Jisc
Lumen House, Library Avenue Lumen House, Library Avenue
Harwell Oxford, Didcot OX11 0SG Harwell Oxford, Didcot OX11 0SG
United Kingdom United Kingdom
Email: tim.chown@jisc.ac.uk Email: tim.chown@jisc.ac.uk
Lenny Giuliano Lenny Giuliano
Juniper Networks, Inc. Juniper Networks, Inc.
 End of changes. 32 change blocks. 
67 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/