< draft-ietf-magma-msnip-02.txt   draft-ietf-magma-msnip-03.txt >
Internet Engineering Task Force MAGMA WG Internet Engineering Task Force MAGMA WG
INTERNET-DRAFT Bill Fenner/AT&T INTERNET-DRAFT B. Fenner/AT&T
draft-ietf-magma-msnip-02.txt Brian Haberman/Caspian Networks draft-ietf-magma-msnip-03.txt B. Haberman/Caspian Networks
Hugh Holbrook/Cisco H. Holbrook/Cisco
Isidor Kouvelas/Cisco I. Kouvelas/Cisco
1 March 2003 2 April 2003
Expires: September 2003 Expires: October 2003
Multicast Source Notification of Interest Protocol (MSNIP) Multicast Source Notification of Interest Protocol (MSNIP)
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
skipping to change at page 1, line 40 skipping to change at page 1, line 40
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a product of the IETF MAGMA WG. Comments should be This document is a product of the IETF MAGMA WG. Comments should be
addressed to the authors, or the WG's mailing list at magma@ietf.org. addressed to the authors, or the WG's mailing list at magma@ietf.org.
Abstract Abstract
This document discusses the Multicast Source Interest This document discusses the Multicast Source Interest
Notification Protocol (MSNIP). MSNIP is an extension to Notification Protocol (MSNIP). MSNIP is an extension to
IGMPv3 and MLDv2 that provides membership notification IGMPv3 and MLDv2 that provides membership notification
services for sources of multicast traffic. services for sources of multicast traffic operating within the
SSM destination address range.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3
2. Routing Protocol Support. . . . . . . . . . . . . . . . 3 2. Routing Protocol Support. . . . . . . . . . . . . . . . 3
3. Service Interface for Requesting Membership Noti- 3. Service Interface for Requesting Membership Noti-
fication . . . . . . . . . . . . . . . . . . . . . . . . . 4 fication . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Application Operation. . . . . . . . . . . . . . . . 5 3.1. Application Operation. . . . . . . . . . . . . . . . 5
4. MSNIP Managed Address Range Negotiation . . . . . . . . 6 4. MSNIP Managed Address Range Negotiation . . . . . . . . 6
4.1. Router Coordination. . . . . . . . . . . . . . . . . 6 4.1. Router Coordination. . . . . . . . . . . . . . . . . 6
4.1.1. MSNIP Operation Option. . . . . . . . . . . . . . 6 4.1.1. MSNIP Operation Option. . . . . . . . . . . . . . 6
4.1.2. SSM Range Option. . . . . . . . . . . . . . . . . 7 4.1.2. SSM Range Option. . . . . . . . . . . . . . . . . 7
4.2. Communicating Range to Source Systems. . . . . . . . 7 4.2. Managed Range Discovery by Source Systems. . . . . . 7
5. Requesting and Receiving Notifications. . . . . . . . . 9 5. Requesting and Receiving Notifications. . . . . . . . . 8
5.1. Host Interest Solicitation . . . . . . . . . . . . . 9 5.1. Host Interest Solicitation . . . . . . . . . . . . . 9
5.2. Router Receiver Membership Reports . . . . . . . . . 10 5.2. Router Receiver Membership Reports . . . . . . . . . 9
6. Application Notification. . . . . . . . . . . . . . . . 11 6. Application Notification. . . . . . . . . . . . . . . . 10
7. Router Processing . . . . . . . . . . . . . . . . . . . 13 7. Router Processing . . . . . . . . . . . . . . . . . . . 12
8. Message Formats . . . . . . . . . . . . . . . . . . . . 14 8. Message Formats . . . . . . . . . . . . . . . . . . . . 14
8.1. Host Interest Solicitation Packet. . . . . . . . . . 15 8.1. Host Interest Solicitation Packet. . . . . . . . . . 15
8.2. Receiver Membership Report Packet. . . . . . . . . . 16 8.2. Receiver Membership Report Packet. . . . . . . . . . 15
8.3. IPv4 Header Fields . . . . . . . . . . . . . . . . . 18 8.3. IPv4 Header Fields . . . . . . . . . . . . . . . . . 17
8.4. IPv6 Header Fields . . . . . . . . . . . . . . . . . 18 8.4. IPv6 Header Fields . . . . . . . . . . . . . . . . . 17
9. Constants Timers and Default Values . . . . . . . . . . 18 9. Constants Timers and Default Values . . . . . . . . . . 18
10. Possible Optimisations . . . . . . . . . . . . . . . . 19 10. Possible Optimisations . . . . . . . . . . . . . . . . 18
10.1. Suppressing HIS Messages. . . . . . . . . . . . . . 19 10.1. Suppressing HIS Messages. . . . . . . . . . . . . . 18
10.2. Host Stack Filtering. . . . . . . . . . . . . . . . 19 10.2. Host Stack Filtering. . . . . . . . . . . . . . . . 18
10.3. Responding to Unexpected IGMP Queries . . . . . . . 19 10.3. Responding to Unexpected IGMP Queries . . . . . . . 19
10.4. Host and Router Startup . . . . . . . . . . . . . . 20 10.4. Host and Router Startup . . . . . . . . . . . . . . 19
11. Inter-operation with IGMP / MLD Proxying . . . . . . . 20 11. Inter-operation with IGMP / MLD Proxying . . . . . . . 20
12. Security Considerations. . . . . . . . . . . . . . . . 21 12. Security Considerations. . . . . . . . . . . . . . . . 20
12.1. Receiver Membership Report attacks. . . . . . . . . 21 12.1. Receiver Membership Report attacks. . . . . . . . . 21
12.2. Host Interest Solicitation attacks. . . . . . . . . 22 12.2. Host Interest Solicitation attacks. . . . . . . . . 21
12.3. MSNIP Managed Range Discovery . . . . . . . . . . . 23 12.3. MSNIP Managed Range Discovery . . . . . . . . . . . 22
13. IANA Considerations. . . . . . . . . . . . . . . . . . 23 13. IANA Considerations. . . . . . . . . . . . . . . . . . 22
14. Acknowledgments. . . . . . . . . . . . . . . . . . . . 24 14. Acknowledgments. . . . . . . . . . . . . . . . . . . . 23
15. Authors' Addresses . . . . . . . . . . . . . . . . . . 24 15. Normative References . . . . . . . . . . . . . . . . . 23
16. Normative References . . . . . . . . . . . . . . . . . 24 16. Informative References . . . . . . . . . . . . . . . . 23
17. Informative References . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The Multicast Source Notification of Interest Protocol (MSNIP) is The Multicast Source Notification of Interest Protocol (MSNIP) is
an extension to version 3 of the Internet Group Membership Protocol an extension to version 3 of the Internet Group Membership Protocol
(IGMPv3 [1] ) and version 2 of the Multicast Listener Discovery Protocol (IGMPv3 [1]) and version 2 of the Multicast Listener Discovery Protocol
(MLDv2 [2] ). MSNIP operates between multicast sources and their first- (MLDv2 [2]). MSNIP operates between multicast sources and their first-
hop routers to provide information on the presence of receivers to the hop routers to provide information on the presence of receivers to the
source systems. Using the services offered by MSNIP an application on an source systems. Using the services offered by MSNIP an application on an
IP system wishing to source multicast data can register to be notified IP system wishing to source multicast data can register to be notified
when receivers join and leave the session. This enables multicast when receivers join and leave the session. This enables multicast
sources to avoid the work of transmitting packets onto their first-hop sources to avoid the work of transmitting packets onto their first-hop
link when there are no joined receivers. link when there are no joined receivers.
A common scenario where MSNIP may be useful is one where there is a A common scenario where MSNIP may be useful is one where there is a
multicast server offering a large pool of potential flows that map onto multicast server offering a large pool of potential flows that map onto
separate multicast destination addresses but receivers exist only for a separate multicast destination addresses but receivers exist only for a
small subset of the flows. If the source were to continuously transmit small subset of the flows. If the source were to continuously transmit
data for all the flows that could potentially have receivers, data for all the flows that could potentially have receivers,
significant resources would be wasted in the system itself as well as significant resources would be wasted in the system itself as well as
the first-hop link. Using a higher level control protocol to determine the first-hop link and first-hop router. Using a higher level control
the existence of receivers for particular flows may not be practical as protocol to determine the existence of receivers for particular flows
there may be many potential receivers in each active session. may not be practical as there may be many potential receivers in each
active session.
Information on which multicast destination addresses have receivers Information on which multicast destination addresses have receivers
for a particular sender is typically available to the multicast routing for a particular sender is typically available to the multicast routing
protocol on the first hop router for a source. MSNIP uses this protocol on the first hop router for a source. MSNIP uses this
information to notify the application in the sending system of when it information to notify the application in the sending system of when it
should start or stop transmitting. This is achieved without any should start or stop transmitting. This is achieved without any
destination address specific state on the first-hop router for potential destination address specific state on the first-hop router for potential
sources without receivers. sources without receivers.
2. Routing Protocol Support 2. Routing Protocol Support
For reasons described in this section, MSNIP only supports For reasons described in this section, MSNIP only supports
transmission control for applications that use multicast destination transmission control for applications that use multicast destination
addresses that are routed using Source Specific Multicast (SSM). addresses that are routed using Source Specific Multicast (SSM).
Many currently deployed multicast routing protocols, require data Many currently deployed multicast routing protocols require data
from an active source to be propagated past the first-hop router before from an active source to be propagated past the first-hop router before
information on the existence of receivers becomes available on the information on the existence of receivers becomes available on the
first-hop. In addition, such protocols require that this activity is first-hop. In addition, such protocols require that this activity is
repeated periodically to maintain source liveness state on remote repeated periodically to maintain source liveness state on remote
routers. All dense-mode protocols fall under this category as well as routers. All dense-mode protocols fall under this category as well as
sparse-mode protocols that use shared trees for source discovery (such sparse-mode protocols that use shared trees for source discovery (such
as PIM-SM [9] ). In order to provide receiver interest notification for as PIM-SM [11]). In order to provide receiver interest notification for
such protocols, the default mode of operation would require that the such protocols, the default mode of operation would require that the
source IP system periodically transmits on all potential destination source IP system periodically transmits on all potential destination
addresses and the first-hop routers prune the traffic back. Such a addresses and the first-hop routers prune the traffic back. Such a
flood-and-prune behaviour on the first-hop link significantly diminishes flood-and-prune behaviour on the first-hop link significantly diminishes
the benefits of managing source transmission. the benefits of managing source transmission.
In contrast, with source-specific sparse-mode protocols such as In contrast, with source-specific sparse-mode protocols such as
PIM-SSM [9] availability of receiver membership information on the PIM-SSM [11] availability of receiver membership information on the
first-hop routers is independent of data transmission. Such protocols first-hop routers is independent of data transmission. Such protocols
use an external mechanism for source discovery (like source-specific use an external mechanism for source discovery (like source-specific
IGMPv3 membership reports) to build source-specific multicast trees. IGMPv3 membership reports) to build source-specific multicast trees.
Clearly these two classes of routing protocols require different Clearly these two classes of routing protocols require different
handling for the problem MSNIP is trying to solve. In addition the handling for the problem MSNIP is trying to solve. In addition the
second type covers the majority of applications that MSNIP is targeted second type covers the majority of applications that MSNIP is targeted
at. MSNIP avoids the extra complication in supporting routing protocols at. MSNIP avoids the extra complication in supporting routing protocols
that require a flood and prune behaviour. that require a flood and prune behaviour.
skipping to change at page 4, line 33 skipping to change at page 4, line 34
packets and are interested in being notified on the existence of packets and are interested in being notified on the existence of
receivers must register with the IP layer of the system. MSNIP requires receivers must register with the IP layer of the system. MSNIP requires
that within the IP system, there is (at least conceptually) a service that within the IP system, there is (at least conceptually) a service
interface that can be used to register with the IP layer for such interface that can be used to register with the IP layer for such
notifications. Dual stack systems supporting both IPv4 and IPv6 need to notifications. Dual stack systems supporting both IPv4 and IPv6 need to
provide separate service interfaces for each protocol. provide separate service interfaces for each protocol.
A system's IPv4 or IPv6 service interface must support the A system's IPv4 or IPv6 service interface must support the
following operation or any logical equivalent: following operation or any logical equivalent:
IPMulticastsSourceRegister (socket, source-address, multicast-address) IPMulticastSourceRegister (socket, source-address, multicast-address)
IPMulticastsSourceDeregister (socket, source-address, multicast-address) IPMulticastSourceDeregister (socket, source-address, multicast-address)
In addition the application must provide the following interface In addition the application must provide the following interface
for receiving notifications from the IP system: for receiving notifications from the IP system:
IPMulticastSourceStart (socket, source-address, multicast-address) IPMulticastSourceStart (socket, source-address, multicast-address)
IPMulticastSourceStop (socket, source-address, multicast-address) IPMulticastSourceStop (socket, source-address, multicast-address)
where: where:
socket socket
is an implementation-specific parameter used to distinguish amongst is an implementation-specific parameter used to distinguish amongst
different requesting entities (e.g., programs or processes) within different requesting entities (e.g., programs or processes) within
the system; the socket parameter of BSD Unix system calls is a the system; the socket parameter of BSD Unix system calls is a
specific example. specific example.
source-address source-address
is the IP unicast source address that the application wishes to use is the IP unicast source address that the application wishes to use
in transmitting data to the specified multicast address. The in transmitting data to the specified multicast address. The
specified address must be one of the IP addresses associated with specified address must be one of the IP addresses associated with
the network interfaces of the IP system. Note that an interface in the network interfaces of the IP system. Note that an interface in
an IP system may be associated with more than one IP addresses. An an IP system may be associated with more than one IP address. An
implementation may allow a special "unspecified" value to be passed implementation may allow a special "unspecified" value to be passed
as the source-address parameter, in which case the request would as the source-address parameter, in which case the request would
apply to the "primary" IP address of the "primary" or "default" apply to the "primary" IP address of the "primary" or "default"
interface of the system (perhaps established by system interface of the system (perhaps established by system
configuration). If transmission to the same multicast address is configuration). If transmission to the same multicast address is
desired using more than one source IP address, desired using more than one source IP address,
IPMulticastSourceRegister must be invoked separately for each IPMulticastSourceRegister must be invoked separately for each
desired source address. desired source address.
multicast-address multicast-address
skipping to change at page 5, line 47 skipping to change at page 5, line 47
If and when the IP system notifies the application that receivers If and when the IP system notifies the application that receivers
exist using the IPMulticastSourceStart call, the application may start exist using the IPMulticastSourceStart call, the application may start
transmitting data. After the application has been notified to send, if transmitting data. After the application has been notified to send, if
all receivers for the session leave, the IP system will notify the all receivers for the session leave, the IP system will notify the
application using the IPMulticastSourceStop call. At this point the application using the IPMulticastSourceStop call. At this point the
application should stop transmitting data until it is notified again application should stop transmitting data until it is notified again
that receivers have joined through another IPMulticastSourceStart call. that receivers have joined through another IPMulticastSourceStart call.
When the application no longer wishes to transmit data it should When the application no longer wishes to transmit data it should
invoke the IPMulticastsSourceDeregister call to let the IP system know invoke the IPMulticastSourceDeregister call to let the IP system know
that it is no longer interested in notifications for this source and that it is no longer interested in notifications for this source and
destination. The IPMulticastsSourceDeregister call should be implicit in destination. The IPMulticastSourceDeregister call should be implicit in
the teardown of the associated socket state. the teardown of the associated socket state.
4. MSNIP Managed Address Range Negotiation 4. MSNIP Managed Address Range Negotiation
With current multicast deployment in the Internet, different With current multicast deployment in the Internet, different
multicast routing protocols coexist and operate under separate parts of multicast routing protocols coexist and operate under separate parts of
the multicast address space. Multicast routers are consistently the multicast address space. Multicast routers are consistently
configured with information that maps specific multicast address ranges configured with information that maps specific multicast address ranges
to multicast routing protocols. Part of this configuration describes the to multicast routing protocols. Part of this configuration describes the
subset of the address space that is used by source-specific multicast subset of the address space that is used by source-specific multicast
(SSM) [10]. As described in section 2 MSNIP only tries to control (SSM) [12]. As described in section 2 MSNIP only tries to control
application transmission within the SSM address range. application transmission within the SSM address range.
It is desirable for applications within an IP system that supports It is desirable for applications within an IP system that supports
MSNIP to have a consistent service interface for multicast transmission MSNIP to have a consistent service interface for multicast transmission
that does require the application to be aware of the SSM address range. that does not require the application to be aware of the SSM address
MSNIP supports this by allowing applications to use the service range. MSNIP supports this by allowing applications to use the service
interface described in section 3 for multicast destination addresses interface described in section 3 for multicast destination addresses
that are outside its operating range. When an application registers for that are outside its operating range. When an application registers for
notifications for a destination address that is not managed by MSNIP it notifications for a destination address that is not managed by MSNIP it
is immediately notified to start transmitting. This is equivalent to the is immediately notified to start transmitting. This is equivalent to the
default behaviour of IP multicast without MSNIP support which forces default behaviour of IP multicast without MSNIP support which forces
multicast applications to assume that there are multicast receivers multicast applications to assume that there are multicast receivers
present in the network. present in the network.
4.1. Router Coordination 4.1. Router Coordination
In order for MSNIP to operate on a shared link where more than one In order for MSNIP to operate on a shared link where more than one
multicast routers may be present all multicast routers must be MSNIP multicast routers may be present, all multicast routers must be MSNIP-
capable and have a consistent configuration for the SSM address range. capable and have an identical configuration for the SSM address range.
MSNIP enforces these requirements by using two new options for IPv4 in MSNIP enforces these requirements by using two new options for IPv4 in
the Multicast Router Discovery protocol [3] and one new option for IPv6 the Multicast Router Discovery protocol [3] and one new option for IPv6
in Neighbor Discovery / ICMPv6 protocol. in the Neighbor Discovery / ICMPv6 protocol [6].
4.1.1. MSNIP Operation Option 4.1.1. MSNIP Operation Option
A multicast router advertises that it is participating in MSNIP A multicast router advertises that it is participating in MSNIP
using the MSNIP Operation option in either the Multicast Router using the MSNIP Operation option in either the Multicast Router
Discovery protocol for IPv4 or the Neighbor Discovery / ICMPv6 protocol Discovery protocol for IPv4 or the Neighbor Discovery / ICMPv6 protocol
for IPv6. This option MUST be included in all router advertisement for IPv6. This option MUST be included in all router advertisement
messages of a router that is configured for MSNIP. The format of the messages of a router that is configured for MSNIP. The format of the
option is as follows: option is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=0 | | Type | Length | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The type field is set to WW (TBD by IANA) for IPv4 and ZZ (TBD by Type The type field is set to WW (TBD by IANA) for IPv4 and ZZ (TBD by
IANA) for IPv6. IANA) for IPv6.
Length
The length field is set to 0 for IPv4 and 1 for IPv6.
Padding
The six extra bytes of padding are only present in IPv6 and are
required to bring the size of the option up to the eight octet
boundary. The value of the padding bytes must be set to zero on
transmission and ignored on receipt.
A multicast router uses received Multicast Router Advertisement and A multicast router uses received Multicast Router Advertisement and
Neighbor Discovery / ICMPv6 messages to determine if all live neighbour Neighbor Discovery / ICMPv6 messages to determine if all live neighbour
multicast routers on each interface are participating in MSNIP. When a multicast routers on each interface are participating in MSNIP. When a
router advertisement message not containing an MSNIP option is received router advertisement message not containing an MSNIP option is received
by a router participating in MSNIP, a miss-configuration SHOULD be by a router participating in MSNIP, the mis-configuration SHOULD be
logged to the operator in a rate-limited manner. logged to the operator in a rate-limited manner.
If even one multicast router on a link does not have MSNIP capability If even one multicast router on a link does not have MSNIP
then ALL routers on that link MUST be configured to not provide MSNIP capability then ALL routers on that link MUST be configured to not
services and to not advertise the MSNIP Operation option. provide MSNIP services and to not advertise the MSNIP Operation option.
4.1.2. SSM Range Option 4.1.2. SSM Range Option
The SSM Range Multicast Router Discover option advertises the SSM The SSM Range Multicast Router Discovery option advertises the SSM
Range with which the router is configured. The option is defined in [4]. Range with which the router is configured. The option is defined in [4].
This option is only valid in IPv4. SSM support in IPv6 does not allow This option is only valid in IPv4. SSM support in IPv6 does not allow
for alternative SSM address ranges. for alternative SSM address ranges.
4.2. Communicating Range to Source Systems 4.2. Managed Range Discovery by Source Systems
When an application in an IP system uses the MSNIP service When an application in an IP system uses the MSNIP service
interface to register for notification, the IP system must behave interface to register for notification, the IP system must behave
differently depending on whether or not the destination address for differently depending on whether or not the destination address for
which the application registered is operating under SSM (and is being which the application registered is operating under SSM (and is being
managed by MSNIP). For SSM channels, the IP system should only instruct managed by MSNIP). For SSM channels, the IP system should only instruct
the application to transmit when there are receivers for the multicast the application to transmit when there are receivers for the multicast
destination. For non-SSM destination addresses the IP system will not be destination. For non-SSM destination addresses the IP system will not be
able to determine if there are receivers and should immediately instruct able to determine if there are receivers and should immediately instruct
the application to transmit. the application to transmit. In addition, an MSNIP-capable IP system
must be able to detect if there are multicast routers on its connected
The MSNIP managed range discovery mechanism in a source IP system links and if they support MSNIP operation. If no multicast routers are
has to deal with three different link configurations: present or if the multicast routers are not MSNIP-capable then the IP
system MUST default to flooding and immediately instruct applications to
o A link connected to a multicast routed infrastructure where the first- transmit.
hop multicast routers are configured for MSNIP operation.
o A link connected to a multicast routed infrastructure where the first-
hop multicast routers are not participating in MSNIP.
o A link with no multicast routers.
To be able to differentiate between the three cases and in each
case discover the MSNIP managed range an MSNIP capable source IP system
must process IGMP Queries as well as Multicast Router Discovery
Advertisement messages. The presence of an IGMP querier differentiates
between the first two cases, where the host is in a multicast routed
network, and the third, where there is no multicast routing.
Multicast Router Discovery Advertisements provide the
differentiation between the first two cases. If the MRD Advertisements
contain the MSNIP Operation option then the IP system knows that routers
on that interface are configured for MSNIP operation.
In each of the three cases the MSNIP managed range is defined as An IP system controls transmission behaviour under the different
follows: possible conditions by adapting its definition of the MSNIP-managed
multicast destination address range:
MSNIP capable multicast routers: o On a link with multicast routers operating the MSNIP protocol the IP
The IP system should use as the MSNIP range the SSM range provided system MUST use the SSM multicast destination address range as the
by the last SSM Range option [4] received in a Multicast Router MSNIP-managed range. IPv4 systems MUST use the contents of the SSM
Discovery message. Range option in received Multicast Router Advertisement messages [4]
to discover the configured SSM range. SSM range discovery is not
needed in IPv6 where the SSM destination address range is fixed.
Multicast routers not participating in MSNIP: o On a link not connected to a multicast routed infrastructure or on a
The IP system should use an empty MSNIP managed range. This link with multicast routers that do not support MSNIP operation, the
provides a compatibility mode where all group ranges default to IP system MUST use an empty range as its MSNIP-managed range. This
flooding. forces applications transmitting to any multicast destination address
to default to flooding thus providing backward compatibility.
Link without multicast routing: As described in 4.1.1, an IP system can determine the status of a
To ensure backwards compatibility with existing receivers, MSNIP link and distinguish between the above two cases through the reception
does not try to control traffic on a router-less link. It does so of IPv4 Multicast Router Advertisement and Neighbor Discovery / ICMPv6
by defining the MSNIP managed range to be empty. Although it would messages.
be possible to control multicast transmission on a shared link not
connected to a multicast routed infrastructure, MSNIP operation
would require that receivers were capable of actively participating
in the protocol. Source control would work by defining an address
range within which sources would not transmit until directly
contacted by a receiver (for example the default IPv4 SSM range of
232/8 [6]). The drawback would be that a non MSNIP capable receiver
joining a group through IGMP would have no way of getting the
source to transmit. Relying on triggered IGMP messages from legacy
receivers to control transmission would not be robust either.
5. Requesting and Receiving Notifications 5. Requesting and Receiving Notifications
Like IGMP, MSNIP is an asymmetric protocol specifying different Like IGMP, MSNIP is an asymmetric protocol specifying different
behaviour for systems wishing to source traffic and for multicast behaviour for systems wishing to source traffic and for multicast
routers. Host IP systems multicast Host Interest Solicitation messages routers. Host IP systems multicast Host Interest Solicitation messages
to register for notification with their first-hop routers. Routers to register for notification with their first-hop routers. Routers
unicast Router Receiver Membership Reports to IP systems to notify them unicast Router Receiver Membership Reports to IP systems to notify them
of the arrival of the first or departure of the last receivers for a of the arrival of the first or departure of the last receiver for a
session. Note that a system may perform at the same time both of the session. Note that a system may perform at the same time both of the
above functions. An example is a router that wishes to source traffic. above functions. An example is a router that wishes to source traffic.
5.1. Host Interest Solicitation 5.1. Host Interest Solicitation
Source systems that wish to be managed by MSNIP periodically Source systems that wish to be managed by MSNIP periodically
transmit an Interest Solicitation message. This message is multicast transmit an Interest Solicitation message. This message is multicast
with a multicast destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) with a multicast destination address of ALL_IGMPv3_ROUTERS (224.0.0.22)
or ALL_MLDv2_ROUTERS (TBA) and is transmitted every [Interest or ALL_MLDv2_ROUTERS (TBA) and is transmitted every [Interest
Solicitation Interval] seconds. The Interest Solicitation message Solicitation Interval] seconds. The Interest Solicitation message
skipping to change at page 9, line 49 skipping to change at page 9, line 38
message from an IP system, maintain a system interest record of the message from an IP system, maintain a system interest record of the
form: form:
(IP system address, holdtime timer) (IP system address, holdtime timer)
Each time an Interest Solicitation message is received from the IP Each time an Interest Solicitation message is received from the IP
system, the holdtime timer is reset to the holdtime in the received system, the holdtime timer is reset to the holdtime in the received
message. In addition the router may respond to the solicitation message message. In addition the router may respond to the solicitation message
with a Receiver Membership Report message described in section 5.2. The with a Receiver Membership Report message described in section 5.2. The
message contains a TRANSMIT record for each of the multicast destination message contains a TRANSMIT record for each of the multicast destination
addresses within the MSNIP managed range for which the routing protocol addresses within the MSNIP-managed range for which the routing protocol
indicates there are receivers for this source system. indicates there are receivers for this source system.
The holdtime timer of a record counts down to zero. When the The holdtime timer of a record counts down to zero. When the
holdtime timer of a specific system interest record expires, the record holdtime timer of a specific system interest record expires, the record
is deleted. is deleted.
5.2. Router Receiver Membership Reports 5.2. Router Receiver Membership Reports
Receiver Membership Report messages are used by routers to Receiver Membership Report messages are used by routers to
communicate the receiver membership status of particular multicast communicate the receiver membership status of particular multicast
destination addresses to a specific IP system. Each message contains a destination addresses to a specific IP system. Each message contains a
list of transmission control records of either TRANSMIT or HOLD type list of transmission control records of either TRANSMIT or HOLD type
that instruct a system to respectively start or stop sending traffic on that instruct a system to respectively start or stop sending traffic on
this link to the specified multicast destination address. Receiver this link to the specified multicast destination address. Receiver
Membership Report messages are unicast to the target system. Membership Report messages are unicast to the target system.
In addition to reports sent in response to Interest Solicitation In addition to reports sent in response to Interest Solicitation
messages, routers send unsolicited Receiver Membership Reports to IP messages, routers send unsolicited Receiver Membership Reports to IP
systems when the receiver membership status reported by the multicast systems when the receiver membership status reported by the multicast
routing protocol changes for a specific source and multicast routing protocol changes for a specific source and multicast
destination. Such reports are only sent if the destination address is destination. Such reports are only sent if the multicast destination
managed by MSNIP and the router has a system interest record created by address is managed by MSNIP and the router has a system interest record
a previously received Interest Solicitation message with an IP system created by a previously received Interest Solicitation message with an
address equal to the source address. If the source destination pair IP system address equal to the source address. If the source /
satisfy these conditions then [Robustness Variable] Receiver Membership destination pair satisfy these conditions then [Robustness Variable]
Reports are sent out spaced by [Unsolicited Membership Report Interval] Receiver Membership Reports are sent out spaced by [Unsolicited
seconds. If the membership status changes again for the same Membership Report Interval] seconds. If the membership status changes
destination address and source system while transmission of Receiver again for the same destination address and source system while
Membership Reports is still pending then the pending report messages are transmission of Receiver Membership Reports is still pending then the
canceled and a new set of [Robustness Variable] messages indicating the pending report messages are canceled and a new set of [Robustness
new state are scheduled. Variable] messages indicating the new state are scheduled.
When an IP system receives a Receiver Membership Report message, When an IP system receives a Receiver Membership Report message,
for each of the TRANSMIT records listed in the message it creates or for each of the TRANSMIT records listed in the message, it creates or
updates a transmission record of the form: updates a transmission record of the form:
(router address, source address, multicast address, holdtime timer) (router address, source address, multicast address, holdtime timer)
The router address is obtained from the source address on the IP header The router address is obtained from the source address on the IP header
of the received message. The source address is obtained from the of the received message. The source address is obtained from the
destination address in the of the IP header. The holdtime timer is set destination address of the IP header of the received message. The
to the value of the holdtime field in the received Receiver Membership multicast address is obtained from the information in the TRANSMIT
Report message. record. The holdtime timer is set to the value of the holdtime field in
the received Receiver Membership Report message.
For each HOLD record present in the message, the system deletes the For each HOLD record present in the message, the system deletes the
matching previously created transmission record from its state. matching previously created transmission record from its state.
The holdtime timer of a record counts down to zero. When the The holdtime timer of a record counts down to zero. When the
holdtime timer of a specific transmission record expires, the record is holdtime timer of a specific transmission record expires, the record is
deleted. deleted.
Note that creation and deletion of transmission records in an IP Note that creation and deletion of transmission records in an IP
systems state may cause local applications to be notified to start and system's state may cause local applications to be notified to start and
stop transmitting data (see section 6). stop transmitting data (see section 6).
6. Application Notification 6. Application Notification
This section describes the relation between protocol events and This section describes the relation between protocol events and
notifications to source applications within an IP system. The state notifications to source applications within an IP system. The state
machine below is specific to each source address of the IP system and machine below is specific to each source address of the IP system and
each multicast destination address. The initial state is the No Info each multicast destination address. The initial state is the No Info
state. state.
skipping to change at page 12, line 7 skipping to change at page 11, line 41
+-----------+----------+-----------+------------+-----------+-----------+ +-----------+----------+-----------+------------+-----------+-----------+
| |Start new |- |-> No Info |- |-> Hold | | |Start new |- |-> No Info |- |-> Hold |
|Transmit | | | | |Stop ALL | |Transmit | | | | |Stop ALL |
| | | | | |registered | | | | | | |registered |
+-----------+----------+-----------+------------+-----------+-----------+ +-----------+----------+-----------+------------+-----------+-----------+
The events in state machine above have the following meaning: The events in state machine above have the following meaning:
New register New register
A new application has registered through a call to A new application has registered through a call to
IPMulticastsSourceRegister for this S and G. IPMulticastSourceRegister for this S and G.
Start manage Start manage
We received a SSM Range option in an MRD packet on the interface We received a SSM Range option in an MRD packet on the interface
that S belongs to that changed the status of G from a non-managed that S belongs to that changed the status of G from a non-managed
to a MSNIP managed destination address. The SSM Range option is to a MSNIP-managed destination address. The SSM Range option is
only valid in IPv4. only valid in IPv4.
Stop manage Stop manage
We received a SSM Range option in an MRD packet on the interface We received a SSM Range option in an MRD packet on the interface
that S belongs to that changed the status of G from a MSNIP managed that S belongs to that changed the status of G from a MSNIP-managed
to a non-managed destination address or the mapping state that to a non-managed destination address or the mapping state that
caused this destination address to be managed expired. The SSM caused this destination address to be managed expired. The SSM
Range option is only valid in IPv4. Range option is only valid in IPv4.
Receive TRANSMIT Receive TRANSMIT
We received a Receiver Membership Report with S as the IP We received a Receiver Membership Report with S as the IP
destination address that contains a TRANSMIT record for G. destination address that contains a TRANSMIT record for G.
Receive last HOLD or timeout Receive last HOLD or timeout
We either received a Receiver Membership Report with S as the IP We either received a Receiver Membership Report with S as the IP
skipping to change at page 14, line 11 skipping to change at page 13, line 49
Receive HIS Receive HIS
The router has received a Host Interest Solicitation from S. The router has received a Host Interest Solicitation from S.
HIS timeout HIS timeout
The holdtime timer (HT) in the host interest record associated with The holdtime timer (HT) in the host interest record associated with
S has expired. S has expired.
Receivers for new destination G Receivers for new destination G
The routing protocol has informed MSNIP that it now has receivers The routing protocol has informed MSNIP that it now has receivers
for the MSNIP managed destination address G and source IP system S. for the MSNIP-managed destination address G and source IP system S.
Receivers of G leave Receivers of G leave
The routing protocol has informed MSNIP that all receivers for the The routing protocol has informed MSNIP that all receivers for the
MSNIP managed destination address G and source IP system S have MSNIP-managed destination address G and source IP system S have
left the channel. left the channel.
The state machine actions have the following meaning: The state machine actions have the following meaning:
Set HT to message holdtime Set HT to message holdtime
The holdtime timer in the host interest record associated with S is The holdtime timer in the host interest record associated with S is
restarted to the value of the holdtime field in the received Host restarted to the value of the holdtime field in the received Host
Interest Solicitation message. Interest Solicitation message.
Send ALL existing TRANSMITs Send ALL existing TRANSMITs
The router builds and transmits Receiver Membership Reports to S The router builds and transmits Receiver Membership Reports to S
that contain a TRANSMIT record for each of the MSNIP managed that contain a TRANSMIT record for each of the MSNIP-managed
destination addresses that have receivers for S. destination addresses that have receivers for S.
Send TRANSMIT for G Send TRANSMIT for G
The router builds and transmits a Receiver Membership Report to S The router builds and transmits a Receiver Membership Report to S
that contains a TRANSMIT record for the destination address G. that contains a TRANSMIT record for the destination address G.
Send HOLD for G Send HOLD for G
The router builds and transmits a Receiver Membership Report to S The router builds and transmits a Receiver Membership Report to S
that contains a HOLD record for the destination address G. that contains a HOLD record for the destination address G.
8. Message Formats 8. Message Formats
The following packet formats are valid for both IPv4 and IPv6. IP The following packet formats are valid for both IPv4 and IPv6. IP
version specific values will be explicitly defined. version-specific values will be explicitly defined.
There are two message types of concern to the MSNIP protocol There are two message types of concern to the MSNIP protocol
described in this document: described in this document:
+-------------------+----------------------------+ +-------------------+----------------------------+
| Type Number (hex) | Message Name | | Type Number (hex) | Message Name |
+-------------------+----------------------------+ +-------------------+----------------------------+
| 0xXX | Host Interest Solicitation | | 0xXX | Host Interest Solicitation |
+-------------------+----------------------------+ +-------------------+----------------------------+
| 0xYY | Receiver Membership Report | | 0xYY | Receiver Membership Report |
skipping to change at page 15, line 40 skipping to change at page 15, line 31
for IPv4 and an ICMPv6 type for IPv6). for IPv4 and an ICMPv6 type for IPv6).
Reserved Reserved
Transmitted as zero. Ignored upon receipt. Transmitted as zero. Ignored upon receipt.
Checksum Checksum
In IPv4, the Checksum is the 16-bit one's complement of the one's In IPv4, the Checksum is the 16-bit one's complement of the one's
complement sum of the whole IGMP message (the entire IP payload). complement sum of the whole IGMP message (the entire IP payload).
In IPv6, the Checksum is the standard ICMPv6 checksum, covering the In IPv6, the Checksum is the standard ICMPv6 checksum, covering the
entire MLDv2 message plus a "pseudo-header" of IPv6 header fields entire MLDv2 message plus a "pseudo-header" of IPv6 header fields
.CITE ICMPv6 . For computing the checksum, the Checksum field is [5]. For computing the checksum, the Checksum field is set to zero.
set to zero. When receiving packets, the checksum MUST be verified When receiving packets, the checksum MUST be verified before
before processing a packet. processing a packet.
Holdtime Holdtime
The amount of time a receiving router must keep the system interest The amount of time a receiving router must keep the system interest
state alive, in seconds. The default value for this field is state alive, in seconds. The default value for this field is
[Interest Solicitation Holdtime]. [Interest Solicitation Holdtime].
GenID
Generation ID of the IP system. A number that is selected randomly
for each of the [Robustness Variable] initial Interest Solicitation
messages when the system comes up and afterwards remains fixed to
the value used in the last of the initial messages throughout the
system lifetime. The GenID is used by routers to detect system
crashes.
8.2. Receiver Membership Report Packet 8.2. Receiver Membership Report Packet
A Receiver Membership Report packet is unicast by first-hop multicast A Receiver Membership Report packet is unicast by first-hop multicast
routers and targeted at potential sources to inform them of the routers and targeted at potential sources to inform them of the
existence or not of receivers for the listed multicast destination existence or not of receivers for the listed multicast destination
addresses. addresses.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 10 skipping to change at page 16, line 33
Dest Count Dest Count
The number of multicast destination address records present in this The number of multicast destination address records present in this
message. message.
Checksum Checksum
In IPv4, the Checksum is the 16-bit one's complement of the one's In IPv4, the Checksum is the 16-bit one's complement of the one's
complement sum of the whole IGMP message (the entire IP payload). complement sum of the whole IGMP message (the entire IP payload).
In IPv6, the Checksum is the standard ICMPv6 checksum, covering the In IPv6, the Checksum is the standard ICMPv6 checksum, covering the
entire MLDv2 message plus a "pseudo-header" of IPv6 header fields entire MLDv2 message plus a "pseudo-header" of IPv6 header fields
.CITE ICMPv6 . For computing the checksum, the Checksum field is [5]. For computing the checksum, the Checksum field is set to zero.
set to zero. When receiving packets, the checksum MUST be verified When receiving packets, the checksum MUST be verified before
before processing a packet. processing a packet.
Holdtime Holdtime
The amount of time in seconds that the target host must keep alive The amount of time in seconds that the target host must keep alive
the transmission record state created or updated by the TRANSMIT the transmission record state created or updated by the TRANSMIT
records in this report. The router originating the Receiver records in this report. The router originating the Receiver
Membership Report sets this field to the current value of the Membership Report sets this field to the current value of the
holdtime timer in the system interest record corresponding to the holdtime timer in the system interest record corresponding to the
target host. As a result Receiver Membership Reports sent in target host. As a result Receiver Membership Reports sent in
response to the reception of a Host Interest Solicitation message response to the reception of a Host Interest Solicitation message
have their holdtime set to the value of the holdtime field in the have their holdtime set to the value of the holdtime field in the
skipping to change at page 18, line 7 skipping to change at page 17, line 29
Reserved Reserved
Transmitted as zero. Ignored upon receipt. Transmitted as zero. Ignored upon receipt.
Destination-Address-1 Destination-Address-1
The multicast destination address of the first record in the The multicast destination address of the first record in the
message. message.
8.3. IPv4 Header Fields 8.3. IPv4 Header Fields
Like all other IGMP messages, MSNIP messages are encapsulated in Like all IGMP messages, MSNIP messages are encapsulated in IPv4
IPv4 datagrams, with an IP protocol number of 2. Every MSNIP message datagrams, with an IP protocol number of 2. MSNIP messages can be
described in this document is sent with an IP Time-to-Live of 1, and identified from other IGMP messages by the message types listed in
carries an IP Router Alert option [RFC-2113] in its IP header. section 8. Every MSNIP message described in this document is sent with
an IP Time-to-Live of 1, and carries an IP Router Alert option [9] in
its IP header.
8.4. IPv6 Header Fields 8.4. IPv6 Header Fields
MLD messages are a sub-protocol of the Internet Control Message MLD messages are a sub-protocol of the Internet Control Message
Protocol (ICMPv6 [5] ). MSNIP messages are identified in IPv6 packets by Protocol (ICMPv6 [5]). MSNIP messages are identified in IPv6 packets by
a preceding Next Header value of 58. All MSNIP messages described in the combination of a preceding Next Header value of 58 and by the MLD
this document are message types listed in section 8. All MSNIP messages described in this
sent with a link-local IPv6 Source Address (or the unspecified address, document are sent with a link-local IPv6 Source Address (or the
if a valid link-local address is not available), an IPv6 Hop Limit of 1, unspecified address, if a valid link-local address is not available), an
and an IPv6 Router Alert option .CITE RAv6 in a Hop-by-hop Options IPv6 Hop Limit of 1, and an IPv6 Router Alert option [10] in a Hop-by-
header. hop Options header.
9. Constants Timers and Default Values 9. Constants Timers and Default Values
Robustness Variable Robustness Variable
The Robustness Variable allows tuning for the expected packet loss The Robustness Variable allows tuning for the expected packet loss
on a network. If a network is expected to be lossy, the Robustness on a network. If a network is expected to be lossy, the Robustness
Variable may be increased. MSNIP is robust to (Robustness Variable Variable may be increased. MSNIP is robust to (Robustness Variable
- 1) packet losses. The Robustness Variable MUST NOT be zero, and - 1) packet losses. The Robustness Variable MUST NOT be zero, and
SHOULD NOT be one. Default: 2 SHOULD NOT be one. Default: 2
skipping to change at page 19, line 24 skipping to change at page 18, line 47
A possible optimisation for MSNIP is to suppress the transmission A possible optimisation for MSNIP is to suppress the transmission
of Host Interest Solicitation messages from the source address of an IP of Host Interest Solicitation messages from the source address of an IP
system for which no local application has registered interest. In system for which no local application has registered interest. In
addition to conserving bandwidth, not transmitting HIS messages prevents addition to conserving bandwidth, not transmitting HIS messages prevents
remote receivers for groups with no matching source application from remote receivers for groups with no matching source application from
creating transmission record state in the host system. creating transmission record state in the host system.
10.2. Host Stack Filtering 10.2. Host Stack Filtering
Legacy applications that have not been coded with MSNIP support can Legacy applications that have not been coded with MSNIP support can
still be prevented from waisting first-hop link bandwidth by filtering still be prevented from wasting first-hop link bandwidth by filtering
transmitted packets at the operating system level. Even though such transmitted packets at the operating system level. Even though such
applications will not register for MSNIP notifications with the host applications will not register for MSNIP notifications with the host
operating system, if the OS is MSNIP capable and the application is operating system, if the OS is MSNIP-capable and the application is
transmitting data to an MSNIP managed group for which there are no transmitting data to an MSNIP-managed group for which there are no
transmit records, the OS can safely filter the packets and not transmit transmit records, the OS can safely filter the packets and not transmit
them on the wire. them on the wire.
A problem with the filtering approach is that it cannot be combined A problem with the filtering approach is that it cannot be combined
with the HIS message suppression optimisation (see section 10.1). If with the HIS message suppression optimisation (see section 10.1). If
there is no registered applications in the system and HIS messages are there are no registered applications in the system and HIS messages are
being suppressed then the first-hop routers will not send any Receiver being suppressed then the first-hop routers will not send any Receiver
Membership Reports to the system. As a result knowledge of receiver Membership Reports to the system. As a result, knowledge of receiver
membership from the presence of transmit records for groups operated by membership from the presence of transmit records for groups operated by
legacy applications will not exist. It therefore becomes unsafe to legacy applications will not exist. It therefore becomes unsafe to
filter packets from legacy applications. filter packets from legacy applications.
10.3. Responding to Unexpected IGMP Queries 10.3. Responding to Unexpected IGMP Queries
Under steady state the router side of the IGMP protocol elects a Under steady state the router side of the IGMP protocol elects a
single router on each link that is responsible for issuing IGMP Queries. single router on each link that is responsible for issuing IGMP Queries.
Routers other than the acting IGMP querier will send an IGMP Query only Routers other than the acting IGMP querier will send an IGMP Query only
if they restart and have no IGMP querier election state or if the active if they restart and have no IGMP querier election state or if the active
Querier crashes and a new election takes place. Querier crashes and a new election takes place.
MSNIP can take advantage of this mechanism to quickly populate the MSNIP can take advantage of this mechanism to quickly populate the
host interest records of a new router starting up. When the router comes host interest records of a new router starting up. When the router comes
up it will issue an IGMP Query in an attempt to be elected as a Querier. up it will issue an IGMP Query in an attempt to be elected as a Querier.
MSNIP capable hosts will notice that the sender of the Query is not the MSNIP-capable hosts will notice that the sender of the Query is not the
acting Querier. They can use this trigger to respond with Host Interest acting Querier. They can use this trigger to respond with Host Interest
Solicitation Messages (with transmission randomised over a small Solicitation Messages (with transmission randomised over a small
interval) to quickly bring the new router up-to-date. interval) to quickly bring the new router up-to-date.
10.4. Host and Router Startup 10.4. Host and Router Startup
When a host operating system is restarted there may be applications When a host operating system is restarted there may be applications
that are started as part of the initialisation process and want to that are started as part of the initialisation process and want to
source IPv4 multicast traffic. It is possible for the applications to source IPv4 multicast traffic. It is possible for the applications to
register through MSNIP with the IP subsystem and to start transmitting register through MSNIP with the IP subsystem and to start transmitting
multicast data before the host receives the MSNIP managed range multicast data before the host receives the MSNIP-managed range
definition through the SSM Range option of the Multicast Router definition through the SSM Range option of the Multicast Router
Discovery protocol. Discovery protocol.
This temporary flooding can be avoided if the host OS holds off This temporary flooding can be avoided if the host OS holds off
notifying MSNIP capable applications that they can transmit until it notifying MSNIP-capable applications that they can transmit until it
receives an MRD advertisement and learns the SSM configuration for the receives an MRD advertisement and learns the SSM configuration for the
network. This behaviour has the drawback that it is not compatible with network. This behaviour has the drawback that it is not compatible with
legacy networks with no MRD deployment. In such a network the host OS legacy networks with no MRD deployment. In such a network the host OS
has to be able to determine after a configurable period that MRD is not has to be able to determine after a configurable period that MRD is not
enabled and hence all multicast applications wishing to source traffic enabled and hence all multicast applications wishing to source traffic
should be notified to transmit. A good default value for this period is should be notified to transmit. A good default value for this period is
the MAX_RESPONSE_DELAY of the Multicast Router Discovery protocol [4]. the MAX_RESPONSE_DELAY of the Multicast Router Discovery protocol [4].
Late router startup is harder to deal with. Hosts that start up Late router startup is harder to deal with. Hosts that start up
before the multicast router may time out waiting for an MRD before the multicast router may time out waiting for an MRD
advertisement and instruct all MSNIP capable multicast source advertisement and instruct all MSNIP-capable multicast source
applications to transmit data. One way to work around this problem is to applications to transmit data. One way to work around this problem is to
configure the host OS to wait forever for an MRD advertisement before configure the host OS to wait forever for an MRD advertisement before
instructing MSNIP applications to transmit. instructing MSNIP applications to transmit.
11. Inter-operation with IGMP / MLD Proxying 11. Inter-operation with IGMP / MLD Proxying
MSNIP is intended for use on networks with multicast servers MSNIP is intended for use on networks with multicast servers
offering a large number of potential sessions. Although unlikely it is offering a large number of potential sessions. Although unlikely, it is
possible to deploy such a server behind an IGMP / MLD Proxy [12]. possible to deploy such a server behind an IGMP / MLD Proxy [14]. If the
proxy is not MSNIP-aware and does not implement the extensions described
below then sources behind the proxy will default to flooding.
If a device performing IGMP / MLD Proxying wishes to proxy MSNIP, If a device performing IGMP / MLD Proxying wishes to proxy MSNIP,
it MUST forward MSNIP Host Interest Solicitation messages that are it MUST forward MSNIP Host Interest Solicitation messages that are
received on downstream interfaces to its upstream interface. No special received on downstream interfaces to its upstream interface. No special
treatment is required for MSNIP Receiver Membership Reports as they are treatment is required for MSNIP Receiver Membership Reports as they are
unicast to the target host. unicast to the target host.
In addition to the forwarding of MSNIP messages, an IGMP proxy MUST In addition to the forwarding of MSNIP messages, an IGMP proxy MUST
operate the Multicast Router Discovery protocol [3] on all its operate the Multicast Router Discovery protocol [3] on all its
downstream interfaces and advertise the MSNIP capability option (section downstream interfaces and advertise the MSNIP capability option (section
skipping to change at page 21, line 29 skipping to change at page 20, line 47
according to the rules in section 4.2. according to the rules in section 4.2.
In addition to the forwarding of MSNIP messages, an MLD proxy MUST In addition to the forwarding of MSNIP messages, an MLD proxy MUST
operate the IPv6 Neighbor Discovery protocol. The MSNIP capability operate the IPv6 Neighbor Discovery protocol. The MSNIP capability
option should be advertised on downstream interfaces when it is included option should be advertised on downstream interfaces when it is included
in IPv6 Neighbor Discovery messages received on the upstream interface. in IPv6 Neighbor Discovery messages received on the upstream interface.
12. Security Considerations 12. Security Considerations
We consider the ramifications of a forged message of each type. As We consider the ramifications of a forged message of each type. As
described in [1] IPSEC AH can be used to authenticate IGMP messages if described in [1] and [2], IPSEC AH can be used to authenticate IGMP and
desired. MLD messages if desired.
12.1. Receiver Membership Report attacks 12.1. Receiver Membership Report attacks
A DoS attack on a host could be staged through forged Receiver A DoS attack on a host could be staged through forged Receiver
Membership Report messages. The attacker can send a large number of Membership Report messages. The attacker can send a large number of
reports, each with a large number of TRANSMIT records and a holdtime reports, each with a large number of TRANSMIT records and a holdtime
field set to a large value. The host will have to store and maintain the field set to a large value. The host will have to store and maintain the
transmission records specified in all of those reports for the duration transmission records specified in all of those reports for the duration
of the holdtime. This would consume both memory and CPU cycles in the of the holdtime. This would consume both memory and CPU cycles in the
host. host.
skipping to change at page 22, line 33 skipping to change at page 21, line 50
12.2. Host Interest Solicitation attacks 12.2. Host Interest Solicitation attacks
Forged Host Interest Solicitation messages can have two effects: Forged Host Interest Solicitation messages can have two effects:
o When non-existent source addresses are used the solicitation messages o When non-existent source addresses are used the solicitation messages
can create unwanted host record state on attached routers for the can create unwanted host record state on attached routers for the
duration of the holdtime specified in the message. duration of the holdtime specified in the message.
o When a source address corresponding to an existing host is used in the o When a source address corresponding to an existing host is used in the
forged HIS message, receipt of the message by attached routers will forged HIS message, receipt of the message by attached routers will
cause them to transmit Receiver Membership Reports messages for any cause them to transmit Receiver Membership Reports messages for all
multicast destination addresses with receivers for the target host. MSNIP-managed multicast destination addresses with receivers for the
Although no additional state will be created in routers or hosts from target host. Although no additional state will be created in routers
this attack, bandwidth and CPU is wasted in both the first-hop routers or hosts from this attack, bandwidth and CPU is wasted in both the
and the target host. first-hop routers and the target host.
Just like for the Receiver Membership Report message, attacks using Just like for the Receiver Membership Report message, attacks using
the Host Interest Solicitation message can be reduced by requiring the the Host Interest Solicitation message can be reduced by requiring the
use of the Router-Alert option on the message. use of the Router-Alert option on the message.
12.3. MSNIP Managed Range Discovery 12.3. MSNIP Managed Range Discovery
As discussed in [4] it is possible for directly connected systems As discussed in [4] it is possible for directly connected systems
to send forged Multicast Router Advertisement messages containing the to send forged Multicast Router Advertisement messages containing the
SSM Range Discovery option. As the SSM Range Discovery option determines SSM Range Discovery option. As the SSM Range Discovery option determines
the MSNIP managed range under IPv4, such forged messages can temporarily the MSNIP-managed range under IPv4, such forged messages can temporarily
replace the managed range map with incorrect information in receiving replace the managed range map with incorrect information in receiving
hosts. An incorrect mapping can have two effects: hosts. An incorrect mapping can have two effects:
o Applications using a multicast destination address within the real SSM o Applications using a multicast destination address within the real SSM
range that have no valid receivers can be tricked into thinking that range that have no valid receivers can be tricked into thinking that
their chosen destination address is no longer an SSM address and will their chosen destination address is no longer an SSM address and will
therefore start transmitting data. therefore start transmitting data.
o Applications using group addresses outside the valid SSM range can be o Applications using group addresses outside the valid SSM range can be
tricked into thinking that they are using an SSM destination address tricked into thinking that they are using an SSM destination address
skipping to change at page 23, line 35 skipping to change at page 22, line 42
an inconsistent SSM Range Option log the event to the operator. Such an inconsistent SSM Range Option log the event to the operator. Such
logging will enable tracking of this type of attack. logging will enable tracking of this type of attack.
13. IANA Considerations 13. IANA Considerations
This document introduces the following new types and options that This document introduces the following new types and options that
require allocation by IANA: require allocation by IANA:
o Two new IGMP messages for Host Interest Solicitation and Receiver o Two new IGMP messages for Host Interest Solicitation and Receiver
Membership Report. Each of these messages requires a new IGMP type Membership Report. Each of these messages requires a new IGMP type
value to be assigned by IANA [11]. value to be assigned by IANA [13].
o The new MSNIP Operation option for the Multicast Router Discovery o The new MSNIP Operation option for the Multicast Router Discovery
protocol. This option requires a new MRD type value to be assigned by protocol. This option requires a new MRD type value to be assigned by
IANA. IANA.
o The new MSNIP Operation option for the Neighbour Discovery / ICMPv6 o The new MSNIP Operation option for the Neighbour Discovery / ICMPv6
protocol. This option requires a new NDP / ICMPv6 type value to be protocol. This option requires a new NDP / ICMPv6 type value to be
assigned by IANA. assigned by IANA.
14. Acknowledgments 14. Acknowledgments
The authors would like to thank Dave Thaler, Jon Crowcroft, Toerless The authors would like to thank Dave Thaler, Jon Crowcroft, Toerless
Eckert and Haixiang He for their contribution to this specification. Eckert, Haixiang He, Pekka Savola and Karen Kimball for their
contribution to this specification.
15. Authors' Addresses
Bill Fenner
AT&T Labs - Research
75 Willow Road
Menlo Park, CA 94025
fenner@research.att.com
Brian Haberman
Caspian Networks
One Park Drive, Suite 400
Research Triangle Park, NC 27709
bkhabs@nc.rr.com
Hugh Holbrook
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
holbrook@cisco.com
Isidor Kouvelas
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
kouvelas@cisco.com
16. Normative References 15. Normative References
[1] B. Cain, S Deering, W. Fenner, I Kouvelas, A. Thyagarajan, "Internet [1] B. Cain, S Deering, W. Fenner, I Kouvelas, A. Thyagarajan, "Internet
Group Management Protocol, Version 3", RFC 3376. Group Management Protocol, Version 3", RFC 3376.
[2] R. Vida, et al, "Multicast Listener Discovery Version 2 (MLDv2) for [2] R. Vida, et al, "Multicast Listener Discovery Version 2 (MLDv2) for
IPv6", work in progress, <draft-vida-mld-v2-??.txt>, October 2002. IPv6", work in progress, <draft-vida-mld-v2-06.txt>, November 2002.
[3] S. Biswas, B. Haberman, "IGMP Multicast Router Discovery", Work In [3] S. Biswas, B. Haberman, "IGMP Multicast Router Discovery", Work In
Progress, <draft-ietf-idmr-igmp-mrdisc-08.txt>, 2001. Progress, <draft-ietf-idmr-igmp-mrdisc-10.txt>, January 2003.
[4] I. Kouvelas, "Multicast Router Discovery SSM Range Option", work in [4] I. Kouvelas, "Multicast Router Discovery SSM Range Option", work in
progress, <draft-ietf-magma-mrdssm-02.txt>, November 2002. progress, <draft-ietf-magma-mrdssm-02.txt>, February 2003.
[5] A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6) [5] A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6)", RFC 2463. for the Internet Protocol Version 6 (IPv6)", RFC 2463.
[6] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", work in [6] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP
progress, <draft-ietf-ssm-arch-00.txt>, 21 November 2001. Version 6 (IPv6)", RFC 2461.
[7] S. Kent, R. Atkinson, "Security Architecture for the Internet [7] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", work in
progress, <draft-ietf-ssm-arch-02.txt>, March 2003.
[8] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol.", RFC 2401. Protocol.", RFC 2401.
[8] C. Partridge, A. Jackson, "IPv6 Router Alert Option", RFC 2711. [9] D. Katz, "IP Router Alert Option", RFC 2113.
17. Informative References [10] C. Partridge, A. Jackson, "IPv6 Router Alert Option", RFC 2711.
[9] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 16. Informative References
[11] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", Work In Progress, <draft-ietf-pim-sm- Specification (Revised)", Work In Progress, <draft-ietf-pim-sm-
v2-new-??.txt>, 2002. v2-new-07.txt>, March 2003.
[10] Z. Albanna, K. Almeroth, D. Meyer, "IANA Guidelines for IPv4 [12] Z. Albanna, K. Almeroth, D. Meyer, "IANA Guidelines for IPv4
Multicast Address Allocation", Best Current Practices, <draft-ietf- Multicast Address Allocation", Best Current Practices, <draft-ietf-
iana-IPv4-mcast-guidelines-00.txt>, 2001. iana-IPv4-mcast-guidelines-00.txt>, 2001.
[11] W. Fenner, "IANA Considerations for IGMP", [13] W. Fenner, "IANA Considerations for IGMP",
http://www.iana.org/assignments/igmp-type-numbers, RFC 3228 (BCP http://www.iana.org/assignments/igmp-type-numbers, RFC 3228 (BCP
57), February 2002. 57), February 2002.
[12] W. Fenner, H. He, B. Haberman, H. Sandick, "IGMP / MLD-based [14] W. Fenner, H. He, B. Haberman, H. Sandick, "IGMP / MLD-based
Multicast Forwarding (IGMP / MLD Proxying)" draft-ietf-magma-igmp- Multicast Forwarding (IGMP / MLD Proxying)" draft-ietf-magma-igmp-
proxy-01.txt, November, 2002. proxy-02.txt, March 2003.
Authors' Addresses
Bill Fenner
AT&T Labs - Research
75 Willow Road
Menlo Park, CA 94025
fenner@research.att.com
Brian Haberman
Caspian Networks
One Park Drive, Suite 300
Research Triangle Park, NC 27709
bkhabs@nc.rr.com
Hugh Holbrook
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
holbrook@cisco.com
Isidor Kouvelas
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
kouvelas@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (Apr 1 2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 79 change blocks. 
213 lines changed or deleted 178 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/