< draft-ietf-ssm-arch-02.txt   draft-ietf-ssm-arch-03.txt >
INTERNET-DRAFT Source-Specific Multicast H. Holbrook INTERNET-DRAFT Source-Specific Multicast H. Holbrook
Expires Sep 2, 2003 Cisco Systems Expires Nov 7, 2003 Cisco Systems
B. Cain B. Cain
Storigen Systems Storigen Systems
2 Mar 2003 7 May 2003
Source-Specific Multicast for IP Source-Specific Multicast for IP
<draft-ietf-ssm-arch-02.txt> <draft-ietf-ssm-arch-03.txt>
Status of this Memo Status of this Memo
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
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 11 skipping to change at page 2, line 11
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119]. document are to be interpreted as described in RFC 2119 [RFC 2119].
Abstract Abstract
IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are
designated as source-specific multicast (SSM) destination addresses and designated as source-specific multicast (SSM) destination addresses and
are reserved for use by source-specific applications and protocols. For are reserved for use by source-specific applications and protocols. For
IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for
Source-Specific Multicast use. It defines an extension to the Internet source-specific multicast use. It defines an extension to the Internet
network service that applies to datagrams sent to SSM addresses and network service that applies to datagrams sent to SSM addresses and
defines the host and router requirements to support this extension. defines the host and router requirements to support this extension.
1. Introduction 1. Introduction
The Internet Protocol (IP) multicast service model is defined in RFC The Internet Protocol (IP) multicast service model is defined in RFC
1112 [RFC1112]. RFC 1112 specifies that a datagram sent to an IP 1112 [RFC1112]. RFC 1112 specifies that a datagram sent to an IP
multicast address (224.0.0.0 through 239.255.255.255) G is delivered to multicast address (224.0.0.0 through 239.255.255.255) G is delivered to
each "upper-layer protocol module" that has requested reception of each "upper-layer protocol module" that has requested reception of
datagrams sent to address G. RFC 1112 calls the network service datagrams sent to address G. RFC 1112 calls the network service
identified by a multicast destination address G a "host group." This identified by a multicast destination address G a "host group." This
model supports both one-to-many and many-to-many group communication. model supports both one-to-many and many-to-many group communication.
This document uses the term "Any-Source Multicast" (ASM) to refer to the This document uses the term "Any-Source Multicast" (ASM) to refer to
RFC 1112 model of multicast. RFC 2373 [RFC2373] specifies the form of model of multicast defined in RFC 1112. RFC 2373 [RFC2373] specifies
IPv6 multicast addresses with ASM semantics. the form of IPv6 multicast addresses with ASM semantics.
IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are
currently designated as source-specific multicast (SSM) destination currently designated as source-specific multicast (SSM) destination
addresses and are reserved for use by source-specific applications and addresses and are reserved for use by source-specific applications and
protocols [IANA-ALLOCATION]. protocols [IANA-ALLOCATION].
For IPv6, the address prefix FF3x::/32 is reserved for source-specific For IPv6, the address prefix FF3x::/32 is reserved for source-specific
multicast use, where 'x' is any valid scope identifier, by [IPV6-UBM]. multicast use, where 'x' is any valid scope identifier, by [IPV6-UBM].
Using the terminology of [IPv6-UBM], this means that P=1, T=1, and Using the terminology of [IPv6-UBM], all SSM addresses must have P=1,
plen=0 for any SSM address. [IPv6-MALLOC] mandates that the network T=1, and plen=0. [IPv6-MALLOC] mandates that the network prefix field
prefix field of an SSM address also be set to zero, hence all SSM of an SSM address also be set to zero, hence all SSM addresses fall in
addresses fall in the FF3x::/96 range. Future documents may allow a the FF3x::/96 range. Future documents may allow a non-zero network
non-zero network prefix field if, for instance, a new IP address to MAC prefix field if, for instance, a new IP address to MAC address mapping
address mapping is defined. Thus, address allocation should occur is defined. Thus, address allocation should occur within the FF3x::/96
within the FF3x::/96 range, but a system should treat all of FF3x::/32 range, but a system should treat all of FF3x::/32 as SSM addresses, to
as an SSM address, to allow for compatibility with possible future uses allow for compatibility with possible future uses of the network prefix
of the network prefix field. field.
Addresses in the range FF3x::4000:0000 through FF3x::7FFF:FFFF are Addresses in the range FF3x::4000:0000 through FF3x::7FFF:FFFF are
reserved for allocation by IANA, and addresses in the range reserved in [IPv6-MALLOC] for allocation by IANA. Addresses in the
FF3x::8000:0000 through FF3x::FFFF:FFFF are allowed for dynamic range FF3x::8000:0000 through FF3x::FFFF:FFFF are allowed for dynamic
allocation by a host, as described in [IPV6-MALLOC]. Addresses in the allocation by a host, as described in [IPV6-MALLOC]. Addresses in the
range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6 SSM range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6 SSM
addresses, per [IPV6-UBM]. The treatment of a packet sent to such an addresses. ([IPV6-MALLOC] indicates that FF3x::0000:0001 to
invalid address is undefined -- a router or host MAY choose to drop such FF3x:3FFF:FFFF must set P=0 and T=0, but for SSM, [IPV6-UBM] mandates
a packet. that P=1 and T=1, hence their designation as invalid). The treatment
of a packet sent to such an invalid address is undefined -- a router or
host MAY choose to drop such a packet.
Source-specific multicast delivery semantics are provided for a datagram Source-specific multicast delivery semantics are provided for a datagram
sent to an SSM address. That is, a datagram with source IP address S sent to an SSM address. That is, a datagram with source IP address S
and SSM destination address G is delivered to each upper-layer "socket" and SSM destination address G is delivered to each upper-layer "socket"
that has specifically requested the reception of datagrams sent to that has specifically requested the reception of datagrams sent to
address G by source S, and only to those sockets. The network service address G by source S, and only to those sockets. The network service
identified by (S,G), for SSM address G and source host address S, is identified by (S,G), for SSM address G and source host address S, is
referred to as a "channel." In contrast to the ASM model of RFC 1112, referred to as a "channel." In contrast to the ASM model of RFC 1112,
SSM provides network-layer support for one-to-many delivery only. SSM provides network-layer support for one-to-many delivery only.
skipping to change at page 4, line 42 skipping to change at page 4, line 46
specific example. specific example.
Any host may send a datagram to any SSM address, and delivery is Any host may send a datagram to any SSM address, and delivery is
provided according to the above semantics. provided according to the above semantics.
The IP module interface to upper-layer protocols is extended to allow a The IP module interface to upper-layer protocols is extended to allow a
socket to "Subscribe" to or "Unsubscribe" from a particular channel socket to "Subscribe" to or "Unsubscribe" from a particular channel
identified by an SSM destination address and a source IP address. The identified by an SSM destination address and a source IP address. The
extended interface is defined in section 4.1. It is meaningless for an extended interface is defined in section 4.1. It is meaningless for an
application or host to request reception of datagrams sent to an SSM application or host to request reception of datagrams sent to an SSM
destination address G, as is supported in the Any-Source Multicast destination address G, as is supported in the any-source multicast
model, without also specifying a corresponding source address, and model, without also specifying a corresponding source address, and
routers MUST ignore any such request. routers MUST ignore any such request.
Multiple source applications on different hosts can use the same SSM Multiple source applications on different hosts can use the same SSM
destination address G without conflict because datagrams sent by each destination address G without conflict because datagrams sent by each
source host Si are delivered only to those sockets that requested source host Si are delivered only to those sockets that requested
delivery of datagrams sent to G specifically by Si. delivery of datagrams sent to G specifically by Si.
The key distinguishing property of the model is that a channel is The key distinguishing property of the model is that a channel is
identified (addressed) by the combination of a unicast source address identified (addressed) by the combination of a unicast source address
skipping to change at page 5, line 26 skipping to change at page 5, line 30
S,G = (2001:3618::1, FF33::1234) S,G = (2001:3618::1, FF33::1234)
and and
S,G = (2001:3618::2, FF33::1234) S,G = (2001:3618::2, FF33::1234)
are different channels. are different channels.
3. Terminology 3. Terminology
To reduce confusion when talking about the Any-Source and Source- To reduce confusion when talking about the any-source and source-
Specific Multicast models, we use different terminology when discussing specific multicast models, we use different terminology when discussing
them. them.
We use the term "channel" to refer to the service associated with an SSM We use the term "channel" to refer to the service associated with an SSM
address. A channel is identified by the combination of an SSM address. A channel is identified by the combination of an SSM
destination address and a specific source, e.g., an (S,G) pair. destination address and a specific source, e.g., an (S,G) pair.
We use the term "host group" (used in RFC 1112) to refer to the service We use the term "host group" (used in RFC 1112) to refer to the service
associated with "regular" ASM multicast addresses (excluding those in associated with "regular" ASM multicast addresses (excluding those in
the SSM range). A host group is identified by a single multicast the SSM range). A host group is identified by a single multicast
address. address.
skipping to change at page 5, line 47 skipping to change at page 6, line 4
address. address.
Any host can send to a host group, and similarly, any host can send to Any host can send to a host group, and similarly, any host can send to
an SSM destination address. A packet sent by a host S to an ASM an SSM destination address. A packet sent by a host S to an ASM
destination address G is delivered to the host group identified by G. A destination address G is delivered to the host group identified by G. A
packet sent by host S to an SSM destination address G is delivered to packet sent by host S to an SSM destination address G is delivered to
the channel identified by (S,G). The receiver operations allowed on a the channel identified by (S,G). The receiver operations allowed on a
host group are called "join(G)" and "leave(G)" (as per RFC 1112). The host group are called "join(G)" and "leave(G)" (as per RFC 1112). The
receiver operations allowed on a channel are called "Subscribe(S,G)" and receiver operations allowed on a channel are called "Subscribe(S,G)" and
"Unsubscribe(S,G)." "Unsubscribe(S,G)."
The following table summarizes the terminology: The following table summarizes the terminology:
Service Model: Any-Source Source-Specific Service Model: any-source source-specific
Network Abstraction: group channel Network Abstraction: group channel
Identifier: G S,G Identifier: G S,G
Receiver Operations: join, leave subscribe, unsubscribe Receiver Operations: Join, Leave Subscribe, Unsubscribe
We note that, although this document specifies a new service model We note that, although this document specifies a new service model
available to applications, the protocols and techniques necessary to available to applications, the protocols and techniques necessary to
support the service model are largely a subset of those used to support support the service model are largely a subset of those used to support
ASM. ASM.
4. Host Requirements 4. Host Requirements
This section describes requirements on hosts that support Source- This section describes requirements on hosts that support source-
Specific Multicast, including: specific multicast, including:
- Extensions to the IP Module Interface - Extensions to the IP Module Interface
- Extensions to the IP Module - Extensions to the IP Module
- Allocation of SSM Addresses - Allocation of SSM Addresses
4.1. Extensions to the IP Module Interface 4.1. Extensions to the IP Module Interface
The IP module interface to upper-layer protocols is extended to allow The IP module interface to upper-layer protocols is extended to allow
skipping to change at page 7, line 35 skipping to change at page 7, line 40
An incoming datagram destined to an SSM address MUST be delivered by the An incoming datagram destined to an SSM address MUST be delivered by the
IP module to all sockets that have indicated (via Subscribe) a desire to IP module to all sockets that have indicated (via Subscribe) a desire to
receive data that matches the datagram's source address, destination receive data that matches the datagram's source address, destination
address, and arriving interface. It MUST NOT be delivered to other address, and arriving interface. It MUST NOT be delivered to other
sockets. sockets.
When the first socket on host H subscribes to a channel (S,G) on When the first socket on host H subscribes to a channel (S,G) on
interface I, the host IP module on H sends a request on interface I to interface I, the host IP module on H sends a request on interface I to
indicate to neighboring routers that the host wishes to receive traffic indicate to neighboring routers that the host wishes to receive traffic
sent by source S to source-specific destination G. Similarly, when the sent by source S to source-specific multicast destination G. Similarly,
last socket on a host unsubscribes from a channel on interface I, the when the last socket on a host unsubscribes from a channel on interface
host IP module sends an unsubscription request for that channel out I, the host IP module sends an unsubscription request for that channel
interface I. to interface I.
These requests will typically be Internet Group Management Protocol These requests will typically be Internet Group Management Protocol
version 3 messages for IPv4, or Multicast Listener Discovery Version 2 version 3 messages for IPv4, or Multicast Listener Discovery Version 2
messages for IPv6 [IGMPv3,MLDv2]. A separate document describes how messages for IPv6 [IGMPv3,MLDv2]. A separate document describes how
IGMPv3 and MLDv2 are adapted to support source-specific multicast. IGMPv3 and MLDv2 are adapted to support source-specific multicast.
4.3. Allocation of Source-Specific Multicast Addresses 4.3. Allocation of Source-Specific Multicast Addresses
The SSM destination address 232.0.0.0 is reserved, and systems MUST NOT The SSM destination address 232.0.0.0 is reserved, and a system MUST NOT
send datagrams with destination address of 232.0.0.0. The address range send a datagram with a destination address of 232.0.0.0. The address
232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA. The range 232.0.0.1-232.0.0.255 is currently reserved for allocation by
IPv6 SSM address range FF3x::/32 is reserved for IANA allocation. IANA. SSM destination addresses in the range FF3x::4000:0000 through
FF3x::7FFF:FFFF are similarly reserved for IANA allocation
[IPv6-MALLOC].
The policy for allocating the rest of the SSM addresses to sending The policy for allocating the rest of the SSM addresses to sending
applications is strictly locally determined by the sending host. applications is strictly locally determined by the sending host.
When allocating SSM addresses dynamically, a host or host operating When allocating SSM addresses dynamically, a host or host operating
system MUST NOT allocate sequentially starting at the first allowed system MUST NOT allocate sequentially starting at the first allowed
address. It is RECOMMENDED to allocate SSM addresses to applications address. It is RECOMMENDED to allocate SSM addresses to applications
randomly, while ensuring that allocated addresses are not given randomly, while ensuring that allocated addresses are not given
simultaneously to multiple applications (and avoiding the reserved simultaneously to multiple applications (and avoiding the reserved
address range for IPv4). For IPv6, the randomization should apply to addresses). For IPv6, the randomization should apply to the lowest 31
the lower 32 bits of the address. bits of the address.
As described in Section 6, the mapping of an IP packet with SSM As described in Section 6, the mapping of an IP packet with SSM
destination address onto a link-layer multicast address does not take destination address onto a link-layer multicast address does not take
into account the datagram's source IP address (on commonly-used link into account the datagram's source IP address (on commonly-used link
layers like Ethernet). If all hosts started at the first allowed layers like Ethernet). If all hosts started at the first allowed
address, then with high probability, many source-specific channels on address, then with high probability, many source-specific channels on
shared-medium local area networks would use the same link-layer shared-medium local area networks would use the same link-layer
multicast address. As a result, traffic destined for one channel multicast address. As a result, traffic destined for one channel
subscriber would be delivered to another's IP module, which would then subscriber would be delivered to another's IP module, which would then
have to reject the datagram. have to discard the datagram.
A host operating system SHOULD provide an interface to allow an A host operating system SHOULD provide an interface to allow an
application to request a unique allocation of a channel destination application to request a unique allocation of a channel destination
address in advance of a session's commencement, and this allocation address in advance of a session's commencement, and this allocation
database SHOULD persist across host reboots. By providing persistent database SHOULD persist across host reboots. By providing persistent
allocations, a host application can advertise the session in advance of allocations, a host application can advertise the session in advance of
its start time on a web page or in another directory. (We note that its start time on a web page or in another directory. (We note that
this issue is not specific to SSM applications -- the same problem this issue is not specific to SSM applications -- the same problem
arises for ASM.) arises for ASM.)
This document neither defines the interfaces for requesting or returning This document neither defines the interfaces for requesting or returning
addresses nor specifies the host algorithms for storing those addresses nor specifies the host algorithms for storing those
allocations. One plausible abstract API is defined in RFC 2771 allocations. One plausible abstract API is defined in RFC 2771
[RFC2771]. Note that RFC 2771 allows an application to request an [RFC2771]. Note that RFC 2771 allows an application to request an
address within a specific range of addresses. If this interface is address within a specific range of addresses. If this interface is
used, the starting address of the range SHOULD be selected at random by used, the starting address of the range SHOULD be selected at random by
the application. the application.
For IPv6, administratively scoped SSM addresses are created by choosing For IPv6, administratively scoped SSM channel addresses are created by
an appropriate scope identifier for the SSM destination address. Normal choosing an appropriate scope identifier for the SSM destination
IPv6 multicast scope boundaries are applied to traffic sent to an SSM address. Normal IPv6 multicast scope boundaries [SCOPINGV6] are applied
destination address. to traffic sent to an SSM destination address, including any relevant
boundaries applied to both the source and destination address.
No globally agreed-upon administratively-scoped address range [ADMIN- No globally agreed-upon administratively-scoped address range [ADMIN-
SCOPE] is currently defined for IPv4 source-specific multicast. For SCOPE] is currently defined for IPv4 source-specific multicast. For
IPv4, administrative scoping of SSM addresses can be implemented within IPv4, administrative scoping of SSM addresses can be implemented within
an administrative domain by filtering outgoing SSM traffic sent to a an administrative domain by filtering outgoing SSM traffic sent to a
scoped address at the domain's boundary routers. scoped address at the domain's boundary routers.
5. Router Requirements 5. Router Requirements
5.1. Packet Forwarding 5.1. Packet Forwarding
skipping to change at page 9, line 20 skipping to change at page 9, line 32
address MUST silently drop it unless a neighboring host or router has address MUST silently drop it unless a neighboring host or router has
communicated a desire to receive packets sent from the source and to the communicated a desire to receive packets sent from the source and to the
destination address of the received packet. destination address of the received packet.
5.2. Protocols 5.2. Protocols
Certain IP multicast routing protocols already have the ability to Certain IP multicast routing protocols already have the ability to
communicate source-specific joins to neighboring routers (in particular, communicate source-specific joins to neighboring routers (in particular,
PIM-SM [PIM-SM]), and these protocols can, with slight modifications, be PIM-SM [PIM-SM]), and these protocols can, with slight modifications, be
used to provide source-specific semantics. Companion documents will used to provide source-specific semantics. Companion documents will
specify the required modifications to those protocols to support SSM. specify the required modifications to those protocols to support SSM.
A network can concurrently support SSM in the SSM address range and Any- A network can concurrently support SSM in the SSM address range and any-
Source Multicast in the rest of the multicast address space, and it is source multicast in the rest of the multicast address space, and it is
expected that this will be commonplace. In such a network, a router may expected that this will be commonplace. In such a network, a router may
receive a non-source-specific, or "(*,G)" in conventional terminology, receive a non-source-specific, or "(*,G)" in conventional terminology,
request for delivery of traffic in the SSM range from a neighbor that request for delivery of traffic in the SSM range from a neighbor that
does not implement source-specific multicast in a manner compliant with does not implement source-specific multicast in a manner compliant with
this document. A router that receives such a non-source-specific this document. A router that receives such a non-source-specific
request for data in the SSM range MUST NOT use the request to establish request for data in the SSM range MUST NOT use the request to establish
forwarding state and MUST NOT propagate the request to other neighboring forwarding state and MUST NOT propagate the request to other neighboring
routers. A router MAY log an error in such a case. This applies both routers. A router MAY log an error in such a case. This applies both
to any request received from a host, e.g., an IGMPv1 or IGMPv2 host to any request received from a host, e.g., an IGMPv1 or IGMPv2 host
report, and to any request received from a routing protocol, e.g., a report, and to any request received from a routing protocol, e.g., a
skipping to change at page 10, line 7 skipping to change at page 10, line 19
shared-medium link-layer networks that support multicast (e.g., shared-medium link-layer networks that support multicast (e.g.,
Ethernet), the IP source address is not used in the selection of the Ethernet), the IP source address is not used in the selection of the
link-layer destination address. Consequently, on such a network, all link-layer destination address. Consequently, on such a network, all
packets sent to destination address G will be delivered to any host that packets sent to destination address G will be delivered to any host that
has subscribed to any channel (S,G), regardless of S. And therefore, has subscribed to any channel (S,G), regardless of S. And therefore,
the IP module MUST filter packets it receives from the link layer before the IP module MUST filter packets it receives from the link layer before
delivering them to the socket layer. delivering them to the socket layer.
7. Security Considerations 7. Security Considerations
This section outlines security issues pertaining to SSM. The following
topics are addressed: limitations of IPSec, denial of service attacks,
source spoofing, and security issues related to administrative scoping.
7.1. IPSec and SSM 7.1. IPSec and SSM
The IPSec Authentication Header (AH) and Encapsulating Security Payload The IPSec Authentication Header (AH) and Encapsulating Security Payload
(ESP) protocols [IPSEC] can be used to secure SSM traffic. As of this (ESP) protocols [IPSEC] can be used to secure SSM traffic. As of this
writing, however, the IPSec protocols have some limitations when used writing, however, the IPSec protocols have some limitations when used
with SSM. This section describes those limitations. with SSM. This section describes those limitations.
[IPSEC] specifies that every incoming packet that requires IPSec [IPSEC] specifies that every incoming packet that requires IPSec
processing is ultimately looked up in a local Security Association processing is ultimately looked up in a local Security Association
Database (SAD) to determine the Security Association (SA) that is to be Database (SAD) to determine the Security Association (SA) that is to be
skipping to change at page 11, line 25 skipping to change at page 11, line 40
it it
- a large amount of source-specific multicast state is created in - a large amount of source-specific multicast state is created in
network routers, using router memory and CPU resources to store and network routers, using router memory and CPU resources to store and
process the state process the state
- a large amount of control traffic is generated to manage the - a large amount of control traffic is generated to manage the
source-specific state, using router CPU and network bandwidth source-specific state, using router CPU and network bandwidth
To reduce the damage from such an attack, a router MAY have To reduce the damage from such an attack, a router MAY have
configuration options to limit the following items: configuration options to limit, for example, the following items:
- The total rate at which all hosts on any one interface are allowed - The total rate at which all hosts on any one interface are allowed
to initiate subscriptions (to limit the damage caused by forged to initiate subscriptions (to limit the damage caused by forged
source-address attacks) source-address attacks)
- The total number of subscriptions that can be initated from any - The total number of subscriptions that can be initiated from any
single interface or host. single interface or host.
Any decision by an implementor to artificially limit the rate or number Any decision by an implementor to artificially limit the rate or number
of subscriptions should be taken carefully, however, as future of subscriptions should be taken carefully, however, as future
applications may use large numbers of channels. Tight limits on the applications may use large numbers of channels. Tight limits on the
rate or number of channel subscriptions would inhibit the deployment of rate or number of channel subscriptions would inhibit the deployment of
such applications. such applications.
A router SHOULD verify that the source of a subscription request is a A router SHOULD verify that the source of a subscription request is a
valid address for the interface on which it was received. Failure to do valid address for the interface on which it was received. Failure to do
so would exacerbate a spoofed-source address attack. so would exacerbate a spoofed-source address attack.
We note that these attacks are not unique to SSM -- they are also We note that these attacks are not unique to SSM -- they are also
present for Any-Source Multicast. present for any-source multicast.
7.3. Spoofed Source Addresses 7.3. Spoofed Source Addresses
By forging the source address in a datagram, an attacker can potentially By forging the source address in a datagram, an attacker can potentially
violate the SSM service model by transmitting datagrams on a channel violate the SSM service model by transmitting datagrams on a channel
belonging to another host. Thus, an application requiring strong belonging to another host. Thus, an application requiring strong
authentication should not assume that all packets that arrive on a authentication should not assume that all packets that arrive on a
channel were sent by the requested source without higher-layer channel were sent by the requested source without higher-layer
authentication mechanisms. The IPSEC Authentication Header [IPSEC] may authentication mechanisms. The IPSEC Authentication Header [IPSEC] may
be used to authenticate the source of an SSM transmission, for instance. be used to authenticate the source of an SSM transmission, for instance.
skipping to change at page 12, line 23 skipping to change at page 12, line 38
SSM SHOULD incorporate such a check. SSM SHOULD incorporate such a check.
Source Routing [RFC791] (both Loose and Strict) in combination with Source Routing [RFC791] (both Loose and Strict) in combination with
source address spoofing may be used to allow an impostor of the true source address spoofing may be used to allow an impostor of the true
channel source to inject packets onto an SSM channel. An SSM router channel source to inject packets onto an SSM channel. An SSM router
SHOULD by default disallow source routing to an SSM destination address. SHOULD by default disallow source routing to an SSM destination address.
A router MAY have a configuration option to allow source routing. Anti- A router MAY have a configuration option to allow source routing. Anti-
source spoofing mechanisms such as source address filtering at the edges source spoofing mechanisms such as source address filtering at the edges
of the network are also strongly encouraged. of the network are also strongly encouraged.
7.4. Administrative Scoping
Administrative scoping should not relied upon as a security measure
[ADMIN-SCOPE]; however, in some cases it is part of a security solution.
It should be noted that no administrative scoping exists for IPv4
source-specific multicast. An alternative approach is to manually
configure traffic filters on routers to create such scoping if
necessary.
Furthermore, for IPv6, neither source nor destination address scoping
should be used as a security measure. In some currently-deployed IPv6
routers (those that do not conform to [SCOPED-ARCH]), scope boundaries
are not always applied to all source address (for instance, an
implentation may filter link-local addresses but nothing else). Such a
router may incorrectly forward an SSM channel (S,G) through a scope
boundary for S.
8. Transition Considerations 8. Transition Considerations
A host that complies with this document will send ONLY source-specific A host that complies with this document will send ONLY source-specific
host reports for addresses in the SSM range. As stated above, a router host reports for addresses in the SSM range. As stated above, a router
that receives a non-source-specific (e.g., IGMPv1 or IGMPv2 or MLDv1) that receives a non-source-specific (e.g., IGMPv1 or IGMPv2 or MLDv1)
host report for a source-specific destination addresses MUST ignore host report for a source-specific multicast destination address MUST
these reports. Failure to do so would violate the SSM service model ignore these reports. Failure to do so would violate the SSM service
promised to the sender: that a packet sent to (S,G) would only be model promised to the sender: that a packet sent to (S,G) would only be
delivered to hosts that specifically requested delivery of packets sent delivered to hosts that specifically requested delivery of packets sent
to G by S. to G by S.
During a transition period, it would be possible to deliver SSM During a transition period, it would be possible to deliver SSM
datagrams in a domain where the routers do not support SSM semantics by datagrams in a domain where the routers do not support SSM semantics by
simply forwarding any packet destined to G to all hosts that have simply forwarding any packet destined to G to all hosts that have
requested subscription of (S,G) for any S. However, this implementation requested subscription of (S,G) for any S. However, this implementation
risks unduly burdening the network infrastructure by deliver (S,G) risks unduly burdening the network infrastructure by delivering (S,G)
datagrams to hosts that did not request them. Such an implementation datagrams to hosts that did not request them. Such an implementation
for addresses in the SSM range is specifically not compliant with for addresses in the SSM range is specifically not compliant with
Section 5.2 of this document. Section 5.2 of this document.
9. IANA Considerations 9. IANA Considerations
Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 addresses Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 addresses
with prefix FF3x:: are reserved for services with wide applicability in the range FF3x:4000:0000 to FF3x::7FFF:FFFF are reserved for services
that either require or would strongly benefit if all hosts used a well- with wide applicability that either require or would strongly benefit if
known SSM destination address for that service. IANA shall allocate all hosts used a well-known SSM destination address for that service.
addresses in this range according to IETF Consensus [IANA- IANA shall allocate addresses in this range according to IETF Consensus
CONSIDERATIONS]. Any proposal for allocation must consider the fact [IANA-CONSIDERATIONS]. Any proposal for allocation must consider the
that, on an Ethernet network, all datagrams sent to any SSM destination fact that, on an Ethernet network, all datagrams sent to any SSM
address will be transmitted with the same link-layer destination destination address will be transmitted with the same link-layer
address, regardless of the source. Furthermore, the fact that SSM destination address, regardless of the source. Furthermore, the fact
destinations in 232.0.0.0/24 and 232.128.0.0/24 use the same link-layer that SSM destinations in 232.0.0.0/24 and 232.128.0.0/24 use the same
addresses as the reserved IP multicast group range 224.0.0.0/24 must link-layer addresses as the reserved IP multicast group range
also be considered. Similar consideration should be given to the IPv6 224.0.0.0/24 must also be considered. Similar consideration should be
reserved multicast addresses. given to the IPv6 reserved multicast addresses.
Except for the aforementioned addresses, IANA SHALL NOT allocate any SSM Except for the aforementioned addresses, IANA SHALL NOT allocate any SSM
destination address to a particular entity or application. To do so destination address to a particular entity or application. To do so
would compromise one of the important benefits of the source-specific would compromise one of the important benefits of the source-specific
model: the ability for a host to simply and autonomously allocate a model: the ability for a host to simply and autonomously allocate a
source-specific address from a large flat address space. source-specific multicast address from a large flat address space.
10. Acknowledgments 10. Acknowledgments
The SSM service model draws on a variety of prior work on alternative The SSM service model draws on a variety of prior work on alternative
aproaches to IP multicast, including the EXPRESS multicast model of approaches to IP multicast, including the EXPRESS multicast model of
Holbrook and Cheriton [EXPRESS], Green's [SMRP] and the Simple Multicast Holbrook and Cheriton [EXPRESS], Green's [SMRP] and the Simple Multicast
proposal of Perlman et. al. [SIMPLE]. We would also like to thank Jon proposal of Perlman et. al. [SIMPLE]. We would also like to thank Jon
Postel and David Cheriton for their support in reassigning the 232/8 Postel and David Cheriton for their support in reassigning the 232/8
address range to SSM. Brian Haberman contributed to the IPv6 portion of address range to SSM. Brian Haberman contributed to the IPv6 portion of
this document. this document. Thanks to Pekka Savola for a careful review.
11. Normative References 11. Normative References
[ETHERv6] Crawford, M., "Transmission of IPv6 Packets over Ethernet [ETHERv6] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC2464, Dec 1998. Networks", RFC2464, Dec 1998.
[IPSEC] S. Kent, R. Atkinson, "Security Architecture for the Internet [IPSEC] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol.", RFC 2401. Protocol.", RFC 2401.
[IPV6-UBM] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 Multicast [IPV6-UBM] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 Multicast
skipping to change at page 15, line 5 skipping to change at page 15, line 38
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997. Requirement Levels," RFC 2119, March 1997.
[RFC2710] S. Deering, W. Fenner, B. Haberman, "Multicast Listener [RFC2710] S. Deering, W. Fenner, B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999. Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2771] Finlayson, R., "An Abstract API for Multicast Address [RFC2771] Finlayson, R., "An Abstract API for Multicast Address
Allocation," RFC 2771, February 2000. Allocation," RFC 2771, February 2000.
[SCOPINGV6] Deering, S. et. al, "IP Version 6 Scoped Address
Architecture", Work in Progress.
[SIMPLE] R. Perlman, C-Y Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. [SIMPLE] R. Perlman, C-Y Lee, A. Ballardie, J. Crowcroft, Z. Wang, T.
Maufer, C. Diot, and M. Green. "Simple Multicast: A Design for Simple, Maufer, C. Diot, and M. Green. "Simple Multicast: A Design for Simple,
Low-Overhead Multicast." Work in Progress. Low-Overhead Multicast." Work in Progress.
[SMRP] Green, M. "Method and System of Multicast Routing for Groups [SMRP] Green, M. "Method and System of Multicast Routing for Groups
with a Single Transmitter." United States Patent Number 5,517,494. with a Single Transmitter." United States Patent Number 5,517,494.
Authors' Addresses Authors' Addresses
Brad Cain Brad Cain
Storigen Systems Storigen Systems
650 Suffolk St. 650 Suffolk St.
Lowell, MA 01854 Lowell, MA 01854
bcain@storigen.com bcain@storigen.com
Hugh Holbrook Hugh Holbrook
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
skipping to change at page 16, line 32 skipping to change at page 17, line 19
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
This document expires Sep 2, 2003. This document expires Nov 7, 2003.
 End of changes. 35 change blocks. 
70 lines changed or deleted 97 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/