draft-ietf-mboned-deprecate-interdomain-asm-03.txt   draft-ietf-mboned-deprecate-interdomain-asm-04.txt 
Mboned M. Abrahamsson Mboned M. Abrahamsson
Internet-Draft T-Systems Internet-Draft T-Systems
Intended status: Best Current Practice T. Chown Intended status: Best Current Practice T. Chown
Expires: August 15, 2019 Jisc Expires: March 1, 2020 Jisc
L. Giuliano L. Giuliano
Juniper Networks, Inc. Juniper Networks, Inc.
T. Eckert T. Eckert
Huawei Huawei
February 11, 2019 August 29, 2019
Deprecating ASM for Interdomain Multicast Deprecating ASM for Interdomain Multicast
draft-ietf-mboned-deprecate-interdomain-asm-03 draft-ietf-mboned-deprecate-interdomain-asm-04
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 that hosts and routers in these deployments fully applications and that hosts and routers in these deployments fully
support SSM. The recommendations in this document do not preclude support SSM. The recommendations in this document do not preclude
the continued use of ASM within a single organisation or domain and the continued use of ASM within a single organisation or domain and
are especially easy to adopt in existing intradomain ASM/PIM-SM are especially easy to adopt in existing intradomain ASM/PIM-SM
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 August 15, 2019. This Internet-Draft will expire on March 1, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 3, line 8 skipping to change at page 3, line 8
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 . . . . . . . . . . . . . . . . . . . . . . . 12
9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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.
This document addresses this gap by making a BCP-level recommendation This document addresses this gap by making a BCP-level recommendation
to deprecate the use of ASM for interdomain multicast, leaving SSM as to deprecate the use of ASM for interdomain multicast, leaving SSM as
the recommended interdomain mode of multicast. This recommendation the recommended interdomain mode of multicast. This document further
thus also implicitly states that all hosts and routers that are recommends that all hosts and routers which support interdomain
expected to support interdomain multicast applications fully support multicast applications fully support SSM.
SSM.
This document does not make any statement on the use of ASM within a This document does not make any statement on the use of ASM within a
single domain or organisation, and therefore does not preclude its single domain or organisation, and therefore does not preclude its
use. Indeed, there are application contexts for which ASM is use. Indeed, there are application contexts for which ASM is
currently still widely considered well-suited within a single domain. currently still widely considered well-suited within a single domain.
The main issue in most cases with moving to SSM is application The main issue in most cases with moving to SSM is application
support. Many applications are initially deployed for intradomain support. Many applications are initially deployed for intradomain
use and are later deployed interdomain. Therefore, this document use and are later deployed interdomain. Therefore, this document
recommends applications support SSM, even when they are initially recommends applications support SSM, even when they are initially
skipping to change at page 4, line 47 skipping to change at page 4, line 45
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 To this day, there is no IETF Proposed Standard level interdomain
solution for IPv4 ASM multicast because MSDP was the "best" component solution for IPv4 ASM multicast because MSDP was the de facto
for the interdomain source discovery problem, and it is Experimental. mechanism for the interdomain source discovery problem, and it is
Other protocol options where investigated at the same time but were Experimental. Other protocol options were investigated at the same
never implemented or deployed and are now historic (e.g: [RFC3913]). time but were never implemented or deployed and are now historic
(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
IPv6 multicast group address. Embedded-RP allows PIM-SM operation IPv6 multicast group address. Embedded-RP allows PIM-SM operation
across any IPv6 network in which there is an end-to-end path of across any IPv6 network in which there is an end-to-end path of
routers supporting this mechanism, including interdomain deployment. routers supporting this mechanism, including interdomain deployment.
2.2.3. Bidir-RP 2.2.3. Bidir-RP
Bidir-PIM [RFC5015] is another protocol to support ASM. There is no Bidir-PIM [RFC5015] is another protocol to support ASM. There is no
standardized option to operate Bidir-PIM interdomain. It is deployed standardized option to operate Bidir-PIM interdomain. It is deployed
intradomain for applications where many sources may want to sent intradomain for applications where many sources send traffic to the
traffic to the same IP multicast groups because unlike PIM-SM it does same IP multicast groups because unlike PIM-SM it does not create
not create per-source state. Bidir-PIM is one of the important per-source state. Bidir-PIM is one of the important reasons for this
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 as it merely a subset of PIM-SM ([RFC7761]). routing of SSM. PIM-SSM as merely a subset of PIM-SM ([RFC7761]).
PIM-SSM expects that the sender's source address(es) is known in PIM-SSM expects that the sender's source address(es) is 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
skipping to change at page 6, line 6 skipping to change at page 6, line 6
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 (complex flooding RPF rules, state attack protection, troubleshoot. Some of these issues include complex flooding RPF
filtering of undesired sources, ...). rules, state attack protection, and filtering of 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 26 skipping to change at page 7, line 26
interdomain multicast means the vast majority of the complexity of interdomain multicast means the vast majority of the complexity of
multicast goes away. multicast goes away.
This reduced complexity makes SSM radically simpler to manage, This reduced complexity makes SSM radically simpler to manage,
troubleshoot and operate, particularly for backbone network troubleshoot and operate, particularly for backbone network
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 an RPs instead o building PIM. In Bidir-PIM, traffic is forwarded to the RP instead of
state as in PIM-SM. Even in the absence of receivers. Bidir-PIM building state as in PIM-SM. This occurs even in the absence of
therefore trades state complexity with (potentially large amounts) of receivers. Bidir-PIM therefore trades state complexity with
unnecessary traffic. (potentially large amounts) of unnecessary traffic.
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 each others IP multicast traffic. receive each others IP multicast traffic.
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: No two a source like a unicast transport protocol port number: the only
independent applications on the host must use same IP multicast group coordination required is to ensure that different applications
number. This does not require any network operator involvement. running on the same host don't send to the same group address. This
does not require any network operator involvement.
3.2.3. Intrinsic source-control security 3.2.3. Intrinsic source-control security
SSM is implicitly secure against unauthorized/undesired sources. SSM is implicitly secure against off-path unauthorized/undesired
Receivers only receive packets from the sources they explicitly sources. Receivers only receive packets from the sources they
specify in their IGMP/MLD membership messages, as opposed to ASM explicitly specify in their IGMP/MLD membership messages, as opposed
where any host can send traffic to a group address and have it to ASM where any host can send traffic to a group address and have it
transmitted to all receivers. With PIM-SSM, traffic from sources not transmitted to all receivers. With PIM-SSM, traffic from sources not
requested by any receiver will be discarded by the first-hop router requested by any receiver will be discarded by the first-hop router
(FHR) of that source, minimizing source attacks against shared (FHR) of that source, minimizing source attacks against shared
network bandwidth and receivers. network bandwidth and receivers.
This benefit is particularily important in interdomain deployments This benefit is particularily 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.
skipping to change at page 8, line 30 skipping to change at page 8, line 30
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 (domains, operated by two or more separate administrative entities.
organisations).
The more inclusive interpretation of this recommendation is that it The more inclusive interpretation of this recommendation is that it
also extends to the case where PIM may only be operated in a single also extends to the case where PIM may only be operated in a single
operator domain, but where user hosts or non-PIM network edge devices operator domain, but where user hosts or non-PIM network edge devices
are under different operator control. A typical example of this case are under different operator control. A typical example of this case
is an SP providing IPTV (single operator domain for PIM) to is a service provider offering IPTV (single operator domain for PIM)
subscribers operating an IGMP proxy home gateway and IGMPv3/MLDv2 to subscribers operating an IGMP proxy home gateway and IGMPv3/MLDv2
hosts (computer, tablets, set-top boxes). 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 [I-D.ietf-6man-rfc6434-bis] states
that MLDv2 support is a MUST in all implementations. Such support is that MLDv2 support is a MUST in all implementations. Such support is
skipping to change at page 9, line 45 skipping to change at page 9, line 45
4.4. Developing application guidance: SSM, ASM, service discovery 4.4. Developing application guidance: SSM, ASM, service discovery
Applications with many-to-many communication patterns can create more Applications with many-to-many communication patterns can create more
(S,G) state than feasible for networks, whether the source discovery (S,G) state than feasible for networks, whether the source discovery
is done by ASM with PIM-SM or at the application level and SSM/PIM- is done by ASM with PIM-SM or at the application level and SSM/PIM-
SM. These applications are not best supported by either SSM/PIM-SSM SM. These applications are not best supported by either SSM/PIM-SSM
or ASM/PIM-SM. or ASM/PIM-SM.
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. As of today, that do not create (S,G), such as Bidir-PIM. Unfortunately, today
Unfortunately, many applications simply use ASM for service many applications simply use ASM for service discovery. One example
discovery, for example by clients sending IP multicast packets to is where clients send IP multicast packets to elicit unicast replies
elicit unicast replies from server(s). Deploying any form of IP from server(s). Deploying any form of IP multicast solely in support
multicast solely in support of such service discovery is in general of such service discovery is in general not recommended. Dedicated
not recommended (complexity, control, ...) but instead dedicated service discovery via DNS-SD [RFC6763] should be used for this
service discovery via DNS [RFC6763] instead.
Best practices should be developed to explain when to use SSM in
applications, when ASM without (S,G) state in the network is better, While the WG discussions had consensus that best practices should be
or when dedicated service-discovery mechanisms should be used. developed to explain when to use SSM in applications, e.g, when ASM
without (S,G) state in the network is better, or when dedicated
service-discovery mechanisms should be used, it was agreed that
documenting such practices are outside the scope of this document.
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 11, line 20 skipping to change at page 11, line 20
years. The operators of such networks most often use Anycast-RP years. The operators of such networks most often use Anycast-RP
[RFC4610] or MSDP (with IPv4) for RP resilience, at the expense of [RFC4610] or MSDP (with IPv4) for RP resilience, at the expense of
the extra operational complexity. These existing practices are the extra operational complexity. These existing practices are
unaffected by this document. unaffected by this document.
In the past decade, Bidir-PIM too has seen deployments to scale In the past decade, Bidir-PIM too has seen deployments to scale
interdomain ASM deployments beyond the capabilities of PIM-SM. This interdomain ASM deployments beyond the capabilities of PIM-SM. This
too is unaffected by this document, instead it is encouraged where too is unaffected by this document, instead it is encouraged where
necessary due to application requirements (see Section 4.4. necessary due to application requirements (see Section 4.4.
This document does also 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/PIM-SM Existing PIM-SM deployments can usually be used to run SSM
applications with no or little 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 implentations of PIM-SM, PIM-SSM is simply enabled by default
in the designated SSM address spaces whener PIM-SM is configuring/ in the designated SSM address spaces whenever PIM-SM is enabled. In
enabled. In other implementations, simple configuration options other implementations, simple configuration options exist to enable
exist to enable it. This allows to easily migrate ASM applications it. This allows easy migration of ASM applications to SSM/PIM-SSM
to SSM/PIM-SSM solely through application side development/ solely through application side development to handle source-
configuration work: adding above mentioned source-signaling via signaling via IGMPv3/MLDv2 and using SSM addresses. No network
IGMPv3/MLDv2 and using SSM addresses. No network actions are actions are required for this transition; unchanged ASM applications
required for this transitioning: Unchanged ASM applications can can continue to co-exist without issues.
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, but this is not standardized but depends on
implementation and may require additional configuration in available implementation and may require additional configuration in available
products. In general, it is recommended to always use SSM address products. In general, it is recommended to always use SSM address
space for SSM applications. For example, the interaction of IGMPv3/ space for SSM applications. For example, the interaction of IGMPv3/
MLDv2 (S,G) membership reports and Bidir-PIM is undefined and may not MLDv2 (S,G) membership reports and Bidir-PIM is undefined and may not
result in forwarding of any traffic. result in forwarding of any traffic.
skipping to change at page 12, line 13 skipping to change at page 12, line 13
be important but is outside the scope of this document. 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 mechaisms for IPv6 PIM-SM with embedded-RP. source access control mechaisms 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, this document does not believe that any ASM solution, Nevertheless, it is very unlikely that any ASM solution, even with
even with such future work, can ever provide the same intrinsic such future work, can ever provide the same intrinsic security and
security and network and address management simplicity as SSM (see network and address management simplicity as SSM (see Section 3.2).
Section 3.2). Instead, this document believes that future work for Accordingly, this document recommends that future work for general
general purpose interdomain IP multicast is better spent on the SSM purpose interdomain IP multicast focus on SSM items listed in
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
benefits of using SSM instead of ASM. benefits of using SSM instead of ASM.
skipping to change at page 14, line 35 skipping to change at page 14, line 35
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>.
10.2. Informative References 10.2. Informative References
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998, Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998,
<https://www.rfc-editor.org/info/rfc2375>. <https://www.rfc-editor.org/info/rfc2375>.
[RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
DOI 10.17487/RFC2730, December 1999,
<https://www.rfc-editor.org/info/rfc2730>.
[RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope
Zone Announcement Protocol (MZAP)", RFC 2776,
DOI 10.17487/RFC2776, February 2000,
<https://www.rfc-editor.org/info/rfc2776>.
[RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M.,
Kumar, S., and D. Thaler, "The Multicast Address-Set Claim
(MASC) Protocol", RFC 2909, DOI 10.17487/RFC2909,
September 2000, <https://www.rfc-editor.org/info/rfc2909>.
[RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications:
Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170, Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170,
September 2001, <https://www.rfc-editor.org/info/rfc3170>. September 2001, <https://www.rfc-editor.org/info/rfc3170>.
[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 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
Discovery Protocol (MSDP)", RFC 3618, Discovery Protocol (MSDP)", RFC 3618,
DOI 10.17487/RFC3618, October 2003, DOI 10.17487/RFC3618, October 2003,
<https://www.rfc-editor.org/info/rfc3618>. <https://www.rfc-editor.org/info/rfc3618>.
[RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP):
Protocol Specification", RFC 3913, DOI 10.17487/RFC3913, Protocol Specification", RFC 3913, DOI 10.17487/RFC3913,
September 2004, <https://www.rfc-editor.org/info/rfc3913>. September 2004, <https://www.rfc-editor.org/info/rfc3913>.
[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>.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, [RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol "Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping (IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
<https://www.rfc-editor.org/info/rfc4541>. <https://www.rfc-editor.org/info/rfc4541>.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
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,
skipping to change at page 16, line 9 skipping to change at page 15, line 31
[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>.
[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., [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T.,
Ed., and R. Krishnan, "Use of Multicast across Inter- Ed., and R. Krishnan, "Use of Multicast across Inter-
domain Peering Points", BCP 213, RFC 8313, domain Peering Points", BCP 213, RFC 8313,
DOI 10.17487/RFC8313, January 2018, DOI 10.17487/RFC8313, January 2018,
<https://www.rfc-editor.org/info/rfc8313>. <https://www.rfc-editor.org/info/rfc8313>.
[I-D.ietf-6man-rfc6434-bis] [I-D.ietf-6man-rfc6434-bis]
Chown, T., Loughney, J., and T. Winters, "IPv6 Node Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", draft-ietf-6man-rfc6434-bis-09 (work in Requirements", draft-ietf-6man-rfc6434-bis-09 (work in
progress), July 2018. progress), July 2018.
 End of changes. 24 change blocks. 
90 lines changed or deleted 64 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/