< draft-savola-v6ops-multicast-issues-00.txt   draft-savola-v6ops-multicast-issues-01.txt >
Internet Engineering Task Force P. Savola Internet Engineering Task Force P. Savola
Internet Draft CSC/FUNET Internet Draft CSC/FUNET
Expiration Date: April 2003 Expiration Date: May 2003
October 2002 November 2002
IPv6 Multicast Deployment Issues IPv6 Multicast Deployment Issues
draft-savola-v6ops-multicast-issues-00.txt draft-savola-v6ops-multicast-issues-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is subject to all provisions
documents of the Internet Engineering Task Force (IETF), its areas, of Section 10 of RFC2026.
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
skipping to change at page 2, line 8 skipping to change at page 2, line 8
sources between PIM RPs. Site-scoped multicast is also problematic sources between PIM RPs. Site-scoped multicast is also problematic
when used alongside to global multicast because of that. A few when used alongside to global multicast because of that. A few
possible solutions are outlined or referred to. In addition, an possible solutions are outlined or referred to. In addition, an
issue regarding link-local multicast-blocking Ethernet switches is issue regarding link-local multicast-blocking Ethernet switches is
brought up. Finally, a feature request for MLD snooping switches is brought up. Finally, a feature request for MLD snooping switches is
noted. noted.
Table of Contents Table of Contents
1. Introduction ............................................... 2 1. Introduction ............................................... 2
2. Issues with Multiple PIM Domains and Any Source Multicast .. 2 2. Issues with Multiple PIM Domains and Any Source Multicast .. 3
2.1. Changing the Multicast Usage Model ..................... 3 2.1. Changing the Multicast Usage Model ..................... 3
2.2. Implementing MSDP for IPv6 ............................. 3 2.2. Implementing MSDP for IPv6 ............................. 4
2.3. Implementing Another Multicast Routing Protocol ........ 4 2.3. Implementing Another Multicast Routing Protocol ........ 4
2.4. Embedding the Address of the RP in Multicast Address ... 4 2.4. Embedding the Address of the RP in Multicast Address ... 4
2.5. Site-local Group Scoping ............................... 4 2.5. Site-local Group Scoping ............................... 5
3. Neighbor Discovery Using Multicast ......................... 5 3. Neighbor Discovery Using Multicast ......................... 5
4. MLD Snooping Ethernet Switches ............................. 5 4. MLD Snooping Ethernet Switches ............................. 6
5. Security Considerations .................................... 6 5. Security Considerations .................................... 6
6. Acknowledgements ........................................... 6 6. Acknowledgements ........................................... 6
7. References ................................................. 6 7. References ................................................. 7
7.1. Normative References ................................... 6 7.1. Normative References ................................... 7
7.2. Informative References ................................. 6 7.2. Informative References ................................. 7
Author's Address ............................................... 7 Author's Address ............................................... 8
1. Introduction 1. Introduction
There are many issues concerning the deployment and implementation, There are many issues concerning the deployment and implementation,
and to a lesser degree, specification of IPv6 multicast. This memo and to a lesser degree, specification of IPv6 multicast. This memo
describes known problems, trying to raise awareness. describes known problems, trying to raise awareness.
Currently, global IPv6 interdomain multicast is completely impossible Currently, global IPv6 interdomain multicast is completely impossible
except using SSM: there is no way to convey information about except using SSM: there is no way to convey information about
multicast sources between PIM RPs. Site-scoped multicast is also multicast sources between PIM RPs. Site-scoped multicast is also
problematic when used alongside to global multicast because of that. problematic when used alongside to global multicast because of that.
A few possible solutions are outlined or referred to. These are A few possible solutions are outlined or referred to. These are
discussed in section 2. discussed in section 2.
In addition, an issue regarding link-local multicast-blocking In addition, an issue regarding link-local multicast -blocking
Ethernet switches is brought up. Finally, a feature request for MLD Ethernet switches is brought up. Finally, a feature request for MLD
snooping switches is noted. These are discussed in sections 3 and 4, snooping switches is noted. These are discussed in sections 3 and 4,
respectively. respectively.
[MULTIGAP] analyses the more generic set of issues with multicast;
this memo focuses on critical issues regarding IPv6.
2. Issues with Multiple PIM Domains and Any Source Multicast 2. Issues with Multiple PIM Domains and Any Source Multicast
For both administrative and technical reasons, there must be multiple For both administrative and technical reasons, there must be multiple
Protocol-Independent Multicast (PIM) [PIM] domains in the Internet, Protocol-Independent Multicast (PIM) [PIM] domains in the Internet,
which means there will be multiple PIM Rendezvous Points (RPs) -- and which means there will be multiple PIM Rendezvous Points (RPs) -- and
communication mechanisms between these RPs will become critical. communication mechanisms between these RPs will become critical.
These issues only come up with classical Any Source Multicast; These issues only come up with classical Any Source Multicast;
Source-Specific Multicast [SSM] does not require RPs and is not Source-Specific Multicast [SSM] does not require RPs and is not
affected, as the multicast "channel" is identified by the combination affected, as the multicast "channel" is identified by the combination
skipping to change at page 3, line 18 skipping to change at page 3, line 28
done with Multicast Source Discovery Protocol (MSDP) [MSDP]. Many done with Multicast Source Discovery Protocol (MSDP) [MSDP]. Many
consider this a sub-optimal, but unfortunately necessary, solution; consider this a sub-optimal, but unfortunately necessary, solution;
when it was specified, it was only meant as a "stop-gap" measure. when it was specified, it was only meant as a "stop-gap" measure.
Below, some issues and solutions/work-arounds are described. Below, some issues and solutions/work-arounds are described.
2.1. Changing the Multicast Usage Model 2.1. Changing the Multicast Usage Model
As "Any Source Multicast" -model has been found to be complex and a As "Any Source Multicast" -model has been found to be complex and a
bit problematic, there may be an incentive to move to SSM for good bit problematic, there may be an incentive to move to SSM for good
(at least for most cases). (at least for most cases). Below two paragraphs are adapted from
[PIMSO]:
SSM is ideal for "broadcast" -type applications, but can be argued to The most serious criticism of the SSM architecture is that it does
be a bit lacking in e.g. "videoconference" -type applications (as it not support shared trees which may be useful for supporting many-to-
may be desirable to have data flow directly between each many applications. In the short-term this is not a serious concern
participant). However, in the latter case, as with telephone since the multicast application space is likely to be dominated by
teleconferences, it is often very desirable for one party to act as a one-to-many applications. Some other classes of multicast
chair or a "hub". In this case, other participants could send their applications that are likely to emerge in the future are few-to-few
data using unicast to the hub and hub could retransmit all data using (e.g. private chat rooms, whiteboards), few-to-many (e.g., video
SSM, though. conferencing, distance learning) and many-to-many (e.g., large chat
rooms, multi-user games). The first two classes can be easily handled
using a few one-to-many source-based trees.
One could argue that the added latency of circulating the data The issue of many-to-many multicasting service on top of a SSM
through the hub may be unacceptable; however, at least in the bigger architecture is an open issue at this point. However, some feel that
conferences (where usually using multicast really matters) this does even many-to-many applications should be handled with multiple one-
not seem like a big problem because there must be some control of the to-many instead of shared trees.
order of speech anyway.
In any case, even though SSM would avoid mentioned problems, it is In any case, even though SSM would avoid mentioned problems, it is
far from being generally implemented, much less deployed, yet. far from being generally implemented, much less deployed, yet.
Nonetheless, few seem to realize that SSM is currently the only way Nonetheless, few seem to realize that SSM is currently the only way
to get global interdomain multicast in IPv6. to get global interdomain multicast in IPv6.
2.2. Implementing MSDP for IPv6 2.2. Implementing MSDP for IPv6
One could argue that currently, the easiest stop-gap solution (to a One could argue that currently, the easiest stop-gap solution (to a
skipping to change at page 4, line 40 skipping to change at page 4, line 51
can be done -- a proposed solution is presented in a different memo can be done -- a proposed solution is presented in a different memo
[V6RPADDR]. Some minor changes in existing PIM specifications would [V6RPADDR]. Some minor changes in existing PIM specifications would
have to be done to take advantage of this, though (but non-modified have to be done to take advantage of this, though (but non-modified
implementations would be no worse than today). implementations would be no worse than today).
One should note that MSDP is also used in "Anycast RP" [ANYCASTRP] One should note that MSDP is also used in "Anycast RP" [ANYCASTRP]
-technique, for sharing the state information between different RP's -technique, for sharing the state information between different RP's
in one PIM domain; without further specification, anycast-RP in one PIM domain; without further specification, anycast-RP
technique could not be used with "embedded RP address" mechanism. technique could not be used with "embedded RP address" mechanism.
However, a "cold failover" variant of anycast-RP (for redundancy
only) would still be possible. In this mechanism, multiple routers
would be configured with the RP address, but only one would be active
at the time: if the RP goes down, another takes its place. The
multicast state stored in the RP would be lost, though, unless it is
copied by some out-of-band mechanism (e.g. placing the backup RP
absolutely on-the-path and have it snoop all the relevant packets).
2.5. Site-local Group Scoping 2.5. Site-local Group Scoping
Site-local groups must be their own PIM domains to prevent site-local Site-local groups must be their own PIM domains to prevent site-local
data leaking to other sites. A more complex possibility would be to data leaking to other sites. A more complex possibility would be to
implement something resembling "BSR border" feature which would implement something resembling "BSR border" feature which would
filter out all site-local components in PIM packets: if this is not filter out all site-local components in PIM packets: if this is not
done very carefully, site-local information will leak to the global done very carefully, site-local information will leak to the global
network. This is operationally difficult, and PIM working group has network. This is operationally difficult, and PIM working group has
come to consensus that a scope boundary MUST also be a a site come to consensus that a scope boundary MUST also be a a site
boundary for certain critical PIM messages (e.g. C-RP and Bootstrap). boundary for certain critical PIM messages (e.g. C-RP and Bootstrap).
skipping to change at page 5, line 13 skipping to change at page 5, line 32
to engage in global multicast), there will be a huge number of to engage in global multicast), there will be a huge number of
domains and communication required between them. This will increase domains and communication required between them. This will increase
the need for a global multicast solution. the need for a global multicast solution.
3. Neighbor Discovery Using Multicast 3. Neighbor Discovery Using Multicast
Neighbor Discovery [NDISC] uses link-local multicast in the most Neighbor Discovery [NDISC] uses link-local multicast in the most
common link-layer media, not broadcast as does ARP with IPv4. This common link-layer media, not broadcast as does ARP with IPv4. This
may cause some operational problems with some equipment. may cause some operational problems with some equipment.
The author has seen two brands of managed Ethernet switches that do The author has seen one brand of managed Ethernet switches, and heard
not forward IPv6 link-layer multicast packets to other ports at all. reports of a few unmanaged switches, that do not forward IPv6 link-
In essence, native IPv6 is impossible with this equipment. layer multicast packets to other ports at all. In essence, native
Investigation is still going on whether these issues can be worked IPv6 is impossible with this equipment. Investigation is still going
around. on whether these issues can be worked around.
However, it seems likely this may be a problem with some switches However, it seems likely this may be a problem with some switches
that build multicast forwarding state based on Layer 3 information that build multicast forwarding state based on Layer 3 information
(and do not support IPv6); state using Layer 2 information would work (and do not support IPv6); state using Layer 2 information would work
just fine [MLDSNOOP]. just fine [MLDSNOOP].
For the deployment of IPv6, it would be important to find out how For the deployment of IPv6, it would be important to find out how
this can be fixed (e.g. how exactly this breaks specifications) and this can be fixed (e.g. how exactly this breaks specifications) and
how one can identify which equipment could case problems like these how one can identify which equipment could case problems like these
(and whether there are workarounds). (and whether there are workarounds).
One workaround might be to implement a toggle in the nodes that would
use link-layer broadcast instead of multicast as a fallback solution.
However, this would have to be used in all the systems in the same
segment one wishes to communicate with.
4. MLD Snooping Ethernet Switches 4. MLD Snooping Ethernet Switches
Especially if multicast traffic is relatively heavy (e.g. video Especially if multicast traffic is relatively heavy (e.g. video
streaming), it becomes particularly important to have Multicast streaming), it becomes particularly important to have some feature
Listener Discovery (MLD) snooping implemented in some equipment, most like Multicast Listener Discovery (MLD) snooping implemented in some
importantly Ethernet switches [MLDSNOOP]. equipment, most importantly Ethernet switches [MLDSNOOP].
In addition, there have been some misunderstandings wrt. which In addition, there have been some misunderstandings wrt. which
multicast addresses (in particular, link-locals) MLD reports multicast addresses (in particular, link-locals) MLD reports
(utilized in the snooping) should be generated for. If all (utilized in the snooping) should be generated for. If all
implementations do not generate enough MLD reports, the introduction implementations do not generate enough MLD reports, the introduction
of MLD snooping could cause them being blocked out. Clarifications of MLD snooping could cause them being blocked out. Clarifications
and analysis on what MLD snooping switches can reasonably expect and analysis on what MLD snooping switches can reasonably expect
would be very important. would be very important.
One could also argue that MLD snooping might make the devices too
complex, requiring the processing of datagrams above the link-layer,
and should be discouraged [MULTIGAP]: the whole idea of L2-only
devices having be able to peek into L3 datagrams seems like a severe
layering violation -- and often the devices aren't upgradeable in any
way. Better mechanisms could be having routers tell switches which
multicasts to forward where (e.g. [CGMP]) or by using some other
mechanisms [GARP].
5. Security Considerations 5. Security Considerations
Only deployment/implementation issues are considered, and these do Only deployment/implementation issues are considered, and these do
not have any particular security considerations; security not have any particular security considerations; security
considerations for each technology are covered in the respective considerations for each technology are covered in the respective
specification. specification.
One fairly obvious issue raised in this memo is that if there is no One fairly obvious issue raised in this memo is that if there is no
adminsitrative PIM domain border between site-local multicast adminsitrative PIM domain border between site-local multicast
domains, the site-local traffic could very easily flow into other domains, the site-local traffic could very easily flow into other
sites and the Internet. sites and the Internet.
6. Acknowledgements 6. Acknowledgements
Early discussions with Stig Venaas, Jerome Durand, Tim Chown et al. Early discussions with Stig Venaas, Jerome Durand, Tim Chown et al.
led to the writing of this draft. Brian Haberman offered extensive led to the writing of this draft. Brian Haberman offered extensive
comments along the way. "Itojun" Hagino brought up the need for MLD comments along the way. "Itojun" Hagino brought up the need for MLD
snooping in a presentation. snooping in a presentation. Bill Nickless pointed out issues in the
gap analysis and provided a pointer to GARP/GMRP; H…vard Eidnes made
a case for a protocol like CGMP. Leonard Giuliano pointed out a more
complete analysis of SSM with different kind of applications.
7. References 7. References
7.1. Normative References 7.1. Normative References
[NDISC] Narten, T., Nordmark, E., Simpson W., "Neighbor Discovery [NDISC] Narten, T., Nordmark, E., Simpson W., "Neighbor Discovery
for IP Version 6 (IPv6)", RFC2461, December 1998. for IP Version 6 (IPv6)", RFC2461, December 1998.
7.2. Informative References 7.2. Informative References
[ANYCASTRP] Dorian, K. et al, q(Anycast RP mechanism using PIM and [ANYCASTRP] Dorian, K. et al, q(Anycast RP mechanism using PIM and
MSDP", work-in-progress, draft-ietf-mboned-anycast- MSDP", work-in-progress, draft-ietf-mboned-anycast-
rp-08.txt, May 2001. rp-08.txt, May 2001.
[BGMP] Thaler, D., "Border Gateway Multicast Protocol (BGMP)", [BGMP] Thaler, D., "Border Gateway Multicast Protocol (BGMP)",
work-in-progress, draft-ietf-bgmp-spec-03.txt. June 2002. work-in-progress, draft-ietf-bgmp-spec-03.txt. June 2002.
[CGMP] Cisco, "Cisco Group Management Protocol", e.g.
http://www.cisco.com/en/US/tech/tk648/tk363/tk105/
tech_protocol_home.html
[GARP] Tobagi, F., et al, "Study of IEEE 802.1p GARP/GMRP Timer
Values", (for introduction to GARP/GMRP, see section 2),
Sep 1997.
[MLDSNOOP] Christensen, M., Solensky, F., "IGMP and MLD snooping [MLDSNOOP] Christensen, M., Solensky, F., "IGMP and MLD snooping
switches", work-in-progress, draft-ietf-magma- switches", work-in-progress, draft-ietf-magma-
snoop-02.txt, June 2002. snoop-02.txt, June 2002.
[MSDP] Farinacci, D. et al, "Multicast Source Discovery Protocol [MSDP] Farinacci, D. et al, "Multicast Source Discovery Protocol
(MSDP)", work-in-progress, draft-ietf-msdp-spec-13.txt (MSDP)", work-in-progress, draft-ietf-msdp-spec-13.txt
(expired), 2002. (expired), 2002.
[MULTIGAP] Meyer, D., Nickless, B., "Internet Multicast Gap
Analysis [...]", work-in-progress,
draft-ietf-mboned-iesg-gap-analysis-00.txt, July 2002.
[PIM] Fenner, B. et al, "Protocol Independent Multicast - [PIM] Fenner, B. et al, "Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol Specification (Revised)", Sparse Mode (PIM-SM): Protocol Specification (Revised)",
work-in-progress, draft-ietf-pim-sm-v2-new-05.txt, work-in-progress, draft-ietf-pim-sm-v2-new-05.txt,
March 2002. March 2002.
[PIMSO] Bhattacharyya, S. et al, "Deployment of PIM-SO at Sprint
(PIM-SO)", work-in-progress,
draft-bhattach-diot-pimso-00.txt (expired), March 2000.
[SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP",
work-in-progress, draft-ietf-ssm-arch-00.txt, work-in-progress, draft-ietf-ssm-arch-00.txt,
November 2001. November 2001.
[V6RPADDR] Savola, P., "Embedding the Address of RP in IPv6 [V6RPADDR] Savola, P., Haberman, B., "Embedding the Address of RP
Multicast Address", work-in-progress, in IPv6 Multicast Address", work-in-progress,
draft-savola-mboned-mcast-rpaddr-00.txt, October 2002. draft-savola-mboned-mcast-rpaddr-00.txt, October 2002.
Author's Address Author's Address
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
Espoo, Finland Espoo, Finland
EMail: psavola@funet.fi EMail: psavola@funet.fi
 End of changes. 23 change blocks. 
41 lines changed or deleted 90 lines changed or added

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