< draft-ietf-ssm-arch-06.txt   draft-ietf-ssm-arch-07.txt >
INTERNET-DRAFT Source-Specific Multicast H. Holbrook INTERNET-DRAFT Source-Specific Multicast H. Holbrook
Expires Mar 07, 2005 Cisco Systems Expires Apr 04, 2006 Arastra, Inc.
B. Cain B. Cain
Storigen Systems Storigen Systems
7 Sep 2004 4 Oct 2005
Source-Specific Multicast for IP Source-Specific Multicast for IP
<draft-ietf-ssm-arch-06.txt> <draft-ietf-ssm-arch-07.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable patent By submitting this Internet-Draft, each author represents that any
or other IPR claims of which I am aware have been disclosed, and any of applicable patent or other IPR claims of which he or she is aware have
which I become aware will be disclosed, in accordance with RFC 3667. been or will be disclosed, and any of which he or she becomes aware will
be disclosed, in accordance with Section 6 of BCP 79.
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
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 version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to
designated as source-specific multicast (SSM) destination addresses and 232.255.255.255) range are designated as source-specific multicast (SSM)
are reserved for use by source-specific applications and protocols. For destination addresses and are reserved for use by source-specific
IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for applications and protocols. For IP version 6 (IPv6), the address prefix
source-specific multicast use. This document defines an extension to FF3x::/32 is reserved for source-specific multicast use. This document
the Internet network service that applies to datagrams sent to SSM defines an extension to the Internet network service that applies to
addresses and defines the host and router requirements to support this datagrams sent to SSM addresses and defines the host and router
extension. requirements to support this extension.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Semantics of Source-Specific Multicast Addresses . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Host Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Extensions to the IP Module Interface . . . . . . . . . . . . . 7
4.2. Requirements on the Host IP Module . . . . . . . . . . . . . . 8
4.3. Allocation of Source-Specific Multicast Addresses . . . . . . . 9
5. Router Requirements . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Packet Forwarding . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Link-Layer Transmission of Datagrams . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. IPsec and SSM . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. SSM and RFC2401 IPsec caveats . . . . . . . . . . . . . . . . . 11
7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . . . . 12
7.4. Spoofed Source Addresses . . . . . . . . . . . . . . . . . . . 13
7.5. Administrative Scoping . . . . . . . . . . . . . . . . . . . . 13
8. Transition Considerations . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . . . 15
12. Informative References . . . . . . . . . . . . . . . . . . . . . 16
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 This document uses the term "Any-Source Multicast" (ASM) to refer to
model of multicast defined in RFC 1112. RFC 2373 [RFC2373] specifies model of multicast defined in RFC 1112. RFC 3513 [RFC3513] specifies
the form of 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 IPv4 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], all SSM addresses must have P=1, Using the terminology of [IPv6-UBM], all SSM addresses must have P=1,
T=1, and plen=0. [IPv6-MALLOC] mandates that the network prefix field T=1, and plen=0. [IPv6-MALLOC] mandates that the network prefix field
of an SSM address also be set to zero, hence all SSM addresses fall in of an SSM address also be set to zero, hence all SSM addresses fall in
the FF3x::/96 range. Future documents may allow a non-zero network the FF3x::/96 range. Future documents may allow a non-zero network
prefix field if, for instance, a new IP address to MAC address mapping prefix field if, for instance, a new IP address to MAC address mapping
is defined. Thus, address allocation should occur within the FF3x::/96 is defined. Thus, address allocation should occur within the FF3x::/96
range, but a system should treat all of FF3x::/32 as SSM addresses, to range, but a system should treat all of FF3x::/32 as SSM addresses, to
allow for compatibility with possible future uses of the network prefix allow for compatibility with possible future uses of the network prefix
field. field.
Addresses in the range FF3x::4000:0000 through FF3x::7FFF:FFFF are Addresses in the range FF3x::4000:0001 through FF3x::7FFF:FFFF are
reserved in [IPv6-MALLOC] for allocation by IANA. Addresses in the reserved in [IPv6-MALLOC] for allocation by IANA. Addresses in the
range 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. ([IPV6-MALLOC] indicates that FF3x::0000:0001 to addresses. ([IPV6-MALLOC] indicates that FF3x::0000:0001 to
FF3x:3FFF:FFFF must set P=0 and T=0, but for SSM, [IPV6-UBM] mandates FF3x::3FFF:FFFF must set P=0 and T=0, but for SSM, [IPV6-UBM] mandates
that P=1 and T=1, hence their designation as invalid). The treatment 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 of a packet sent to such an invalid address is undefined -- a router or
host MAY choose to drop such a packet. 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
skipping to change at page 7, line 18 skipping to change at page 8, line 8
functionality can be provided in an implementation-specific way. On a functionality can be provided in an implementation-specific way. On a
host that supports the multicast source filtering application host that supports the multicast source filtering application
programming interface of [MSFAPI], for instance, the Subscribe and programming interface of [MSFAPI], for instance, the Subscribe and
Unsubscribe interfaces may be supported via that API. When a host has Unsubscribe interfaces may be supported via that API. When a host has
been configured to know the SSM address range, (whether the been configured to know the SSM address range, (whether the
configuration mechanism is manual or through a protocol) the host's configuration mechanism is manual or through a protocol) the host's
operating system SHOULD return an error to an application that makes a operating system SHOULD return an error to an application that makes a
non-source-specific request to receive multicast sent to an SSM non-source-specific request to receive multicast sent to an SSM
destination address. destination address.
A host that does not support these IP module interfaces (e.g., ASM-only
hosts) and their underlying protocols can not expect to reliably receive
traffic sent on an SSM channel. As specified below in Section 5.2,
routers will not set up SSM forwarding state or forward datagrams in
response to an ASM join request.
Widespread implementations of the IP packet reception interface (e.g., Widespread implementations of the IP packet reception interface (e.g.,
the recvfrom() system call in BSD unix) do not allow a receiver to the recvfrom() system call in BSD unix) do not allow a receiver to
determine the destination address to which a datagram was sent. On a determine the destination address to which a datagram was sent. On a
host with such an implementation, the destination address of a datagram host with such an implementation, the destination address of a datagram
cannot be inferred when the socket on which the datagram is received is cannot be inferred when the socket on which the datagram is received is
Subscribed to multiple channels. Host operating systems SHOULD provide Subscribed to multiple channels. Host operating systems SHOULD provide
a way for a host to determine both the source and the destination a way for a host to determine both the source and the destination
address to which a datagram was sent. (As one example, the Linux address to which a datagram was sent. (As one example, the Linux
operating system provides the destination of a packet as part of the operating system provides the destination of a packet as part of the
response to the recvmsg() system call.) Until this capability is response to the recvmsg() system call.) Until this capability is
skipping to change at page 8, line 8 skipping to change at page 9, line 7
These requests will typically be Internet Group Management Protocol These requests will typically be Internet Group Management Protocol
version 3 (IGMPv3) messages for IPv4, or Multicast Listener Discovery version 3 (IGMPv3) messages for IPv4, or Multicast Listener Discovery
Version 2 (MLDv2) messages for IPv6 [IGMPv3,MLDv2]. A host that Version 2 (MLDv2) messages for IPv6 [IGMPv3,MLDv2]. A host that
supports the SSM service model MUST implement the host portion of supports the SSM service model MUST implement the host portion of
[IGMPv3] for IPv4 and [MLDv2] for IPv6. It MUST also conform to the [IGMPv3] for IPv4 and [MLDv2] for IPv6. It MUST also conform to the
IGMPv3/MLDv2 behavior described in [GMP-SSM]. IGMPv3/MLDv2 behavior described in [GMP-SSM].
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 a system MUST NOT The SSM destination address 232.0.0.0 is reserved, and it must not be
send a datagram with a destination address of 232.0.0.0. The address used as a destination address. Similarly, FF3x::4000:0000 is also
range 232.0.0.1-232.0.0.255 is currently reserved for allocation by reserved. The goal of reserving these two addresses is to preserve one
IANA. SSM destination addresses in the range FF3x::4000:0000 through invalid ssm destination for IPv4 and IPv6, which can be useful in an
FF3x::7FFF:FFFF are similarly reserved for IANA allocation implementation as a null value. The address range 232.0.0.1-232.0.0.255
[IPv6-MALLOC]. is currently reserved for allocation by IANA SSM destination addresses
in the range FF3x::4000:0001 through FF3x::7FFF:FFFF are similarly
reserved for IANA allocation [IPv6-MALLOC]. The motivation to reserve
these addresses is outlined below in Section 9, IANA considerations.
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
addresses). For IPv6, the randomization should apply to the lowest 31 addresses). For IPv6, the randomization should apply to the lowest 31
skipping to change at page 10, line 31 skipping to change at page 11, line 33
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 This section outlines security issues pertaining to SSM. The following
topics are addressed: limitations of IPSec, denial of service attacks, topics are addressed: IPsec, denial of service attacks, source spoofing,
source spoofing, and security issues related to administrative scoping. and security issues related to administrative scoping.
7.1. IPSec and SSM
The IPSec Authentication Header (AH) and Encapsulating Security Payload
(ESP) protocols [IPSEC] can be used to secure SSM traffic. As of this
writing, however, the IPSec protocols have some limitations when used
with SSM. This section describes those limitations.
[IPSEC] specifies that every incoming packet that requires IPSec
processing is ultimately looked up in a local Security Association
Database (SAD) to determine the Security Association (SA) that is to be
applied to the packet. The resulting SA determines the decryption
and/or authentication key to use and the anti-replay window, if one is
used. The key used for the SAD lookup is:
- the packet's destination IP address 7.1. IPsec and SSM
- the IPSec protocol (ESP or AH) The IPsec Authentication Header (AH) and Encapsulating Security Payload
- the Security Parameter Index (SPI) (ESP) can be used to secure SSM traffic, if a multicast-capable
implementation of IPsec (as required in [IPSECbis]) is used by the
receivers.
A problem arises for SSM because the source address is not included in 7.2. SSM and RFC2401 IPsec caveats
the SAD lookup. IPSec does not currently provide any way to ensure that
two unrelated SSM channels will have unique SAD entries at all
receivers. Two senders that happen to choose the same SSM destination
address and the same Security Parameter Index will "collide" in the SAD
at any host that is receiving both channels. Because the channel
addresses and SPIs are both allocated autonomously by the senders, there
is no reasonable means to ensure that each sender uses a unique
destination address or SPI.
In practice, this problem only arises if a receiver subscribes For existing implementations of (the now superseded by [IPSECbis])
simultaneously to two unrelated channels using IPSec whose sources RFC2401 IPsec, there are a few caveats relate to SSM. They are listed
happen to have chosen the same IP destination address (IPDA) and the here. In RFC2401 IPsec, the source address is not used as part of the
same IPSec SPI. The <IPDA,SPI> tuple, however, consists of 56 bits that key in the SAD lookup. As a result, two senders that happen to use the
are generally randomly chosen, and a conflict is unlikely to occur same SSM destination address and the same Security Parameter Index will
through random chance. "collide" in the SAD at any host that is receiving both channels. that
each sender uses a unique destination address or SPI.
But when this problem occurs, however unlikely, a host will not be able A problem arises if a receiver subscribes simultaneously to two
to simultaneously receive IPSec-protected traffic from the two colliding unrelated channels using IPsec whose sources happen to be using the same
sources under the current IPSec model. IP destination address (IPDA) and the same IPsec SPI. Because the
channel destination addresses are allocated autonomously by the senders,
any two hosts can simultaneously use the same destination address, and
there is no reasonable means to ensure that this does not happen. The
<IPDA,SPI> tuple, however, consists of 56 bits that are generally
randomly chosen (24 bits of the IP destination and 32 bits of the SPI)
and a conflict is unlikely to occur through random chance.
This problem is under investigation and a solution will appear in a If such a collision occurs, a receiver will not be able to
separate document. One possible solution is to include the source simultaneously receive IPsec-protected traffic from the two colliding
address in the SAD lookup when the destination is an SSM address. sources. A receiver can detect this condition by noticing that it is
receiving traffic from two different sources with the same SPI and the
same SSM destination address.
7.2. Denial of Service 7.3. Denial of Service
A subscription request creates (S,G) state in a router to record the A subscription request creates (S,G) state in a router to record the
subscription, invokes processing on that router, and possibly causes subscription, invokes processing on that router, and possibly causes
processing at neighboring routers. A host can mount a denial of service processing at neighboring routers. A host can mount a denial of service
attack by requesting a large number of subscriptions. A denial of attack by requesting a large number of subscriptions. A denial of
service can result if: service can result if:
- a large amount of traffic arrives when it was otherwise undesired, - a large amount of traffic arrives when it was otherwise undesired,
consuming network resources to deliver it and host resources to drop consuming network resources to deliver it and host resources to drop
it it
skipping to change at page 12, line 25 skipping to change at page 13, line 18
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.4. 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
be used to authenticate the source of an SSM transmission, for instance. [IPSEC,IPSECbis] may be used to authenticate the source of an SSM
transmission, for instance.
Some degree of protection against spoofed source addresses in multicast Some degree of protection against spoofed source addresses in multicast
is already fairly widespread, because the commonly deployed IP multicast is already fairly widespread, because the commonly deployed IP multicast
routing protocols [PIM-DM, PIM-SM, DVMRP] incorporate a "reverse-path routing protocols [PIM-DM, PIM-SM, DVMRP] incorporate a "reverse-path
forwarding check" that validates that a multicast packet arrived on the forwarding check" that validates that a multicast packet arrived on the
expected interface for its source address. Routing protocols used for expected interface for its source address. Routing protocols used for
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 7.5. Administrative Scoping
Administrative scoping should not be relied upon as a security measure Administrative scoping should not be relied upon as a security measure
[ADMIN-SCOPE]; however, in some cases it is part of a security solution. [ADMIN-SCOPE]; however, in some cases it is part of a security solution.
It should be noted that no administrative scoping exists for IPv4 It should be noted that no administrative scoping exists for IPv4
source-specific multicast. An alternative approach is to manually source-specific multicast. An alternative approach is to manually
configure traffic filters to create such scoping if necessary. configure traffic filters to create such scoping if necessary.
Furthermore, for IPv6, neither source nor destination address scoping Furthermore, for IPv6, neither source nor destination address scoping
should be used as a security measure. In some currently-deployed IPv6 should be used as a security measure. In some currently-deployed IPv6
routers (those that do not conform to [SCOPED-ARCH]), scope boundaries routers (those that do not conform to [SCOPED-ARCH]), scope boundaries
skipping to change at page 13, line 43 skipping to change at page 14, line 35
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 delivering (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 IANA allocates IPv4 addresses in the range 232.0.0.1 through 232.0.0.255
in the range FF3x:4000:0000 to FF3x::7FFF:FFFF are reserved for services and IPv6 addresses in the range FF3x:4000:0001 to FF3x::7FFF:FFFF.
with wide applicability that either require or would strongly benefit if These addresses are allocated according to IETF Consensus [IANA-
all hosts used a well-known SSM destination address for that service. CONSIDERATIONS]. These address ranges are reserved for services with
IANA shall allocate addresses in this range according to IETF Consensus wide applicability that either require or would strongly benefit if all
[IANA-CONSIDERATIONS]. Any proposal for allocation must consider the hosts used a well-known SSM destination address for that service. Any
fact that, on an Ethernet network, all datagrams sent to any SSM proposal for allocation must consider the fact that, on an Ethernet
destination address will be transmitted with the same link-layer network, all datagrams sent to any SSM destination address will be
destination address, regardless of the source. Furthermore, the fact transmitted with the same link-layer destination address, regardless of
that SSM destinations in 232.0.0.0/24 and 232.128.0.0/24 use the same the source. Furthermore, the fact that SSM destinations in 232.0.0.0/24
link-layer addresses as the reserved IP multicast group range and 232.128.0.0/24 use the same link-layer addresses as the reserved IP
224.0.0.0/24 must also be considered. Similar consideration should be multicast group range 224.0.0.0/24 must also be considered. Similar
given to the IPv6 reserved multicast addresses. consideration should be given to the IPv6 reserved multicast addresses.
232.0.0.0 and FF3x::4000:0000 should not be allocated, as suggested
above.
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 multicast 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
skipping to change at page 14, line 31 skipping to change at page 15, line 27
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. Thanks to Pekka Savola for a careful review. 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.
[GMP-SSM] H. Holbrook and B. Cain, "IGMPv3/MLDv2 for SSM", draft- [GMP-SSM] H. Holbrook and B. Cain, "IGMPv3/MLDv2 for SSM", draft-
holbrook-idmr-igmpv3-ssm-07 (Work in Progress), June 2004. holbrook-idmr-igmpv3-ssm-07. Work in Progress. June 2004.
[IGMPv3] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group [IGMPv3] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group
Management Protocol, Version 3," RFC 3376, October 2002. Management Protocol, Version 3," RFC 3376, October 2002.
[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
Addresses.", RFC 3306, August 2002. Addresses.", RFC 3306, August 2002.
[IPV6-MALLOC] B. Haberman, "Dynamic Allocation Guidelines for IPv6 [IPV6-MALLOC] B. Haberman, "Dynamic Allocation Guidelines for IPv6
Multicast Addresses", RFC 3307, August 2002. Multicast Addresses", RFC 3307, August 2002.
[MLDv2] R. Vida, and L. Costa. "Multicast Listener Discovery Version 2 [MLDv2] R. Vida, and L. Costa. "Multicast Listener Discovery Version 2
(MLDv2) for IPv6," RFC3810, June 2004. (MLDv2) for IPv6," RFC3810, June 2004.
[PIM-SM] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas. "Protocol [PIM-SM] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas. "Protocol
Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification
(Revised)," draft-ietf-pim-sm-v2-new-10.txt (Work in Progress), July (Revised)," draft-ietf-pim-sm-v2-new-11.txt. Work in Progress. October
2004. 2004.
[RFC791] Postel, J., ed., "Internet Protocol, Darpa Internet Program [RFC791] Postel, J., ed., "Internet Protocol, Darpa Internet Program
Protocol Specification," September 1981. Protocol Specification," September 1981.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112, [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112,
August 1989. August 1989.
[RFC2373] Hinden, R. and Deering, S. "IP Version 6 Addressing [RFC3513] Hinden, R. and Deering, S. "IP Version 6 (IPv6) Addressing
Architecture." RFC 2373, July 1998. Architecture." RFC 3513, April 2003.
12. Informative References 12. Informative References
[ADMIN-SCOPE] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, [ADMIN-SCOPE] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998. RFC 2365, July 1998.
[DVMRP] Waitzman, D., Partridge, C., and S. Deering., "Distance Vector [DVMRP] Waitzman, D., Partridge, C., and S. Deering., "Distance Vector
Multicast Routing Protocol," RFC 1075, Nov 1988. Multicast Routing Protocol," RFC 1075, Nov 1988.
[EXPRESS] Holbrook, H., and Cheriton, D. "Explicitly Requested Source- [EXPRESS] Holbrook, H., and Cheriton, D. "Explicitly Requested Source-
skipping to change at page 15, line 41 skipping to change at page 16, line 38
Writing an IANA Considerations Section in RFCs," RFC 2434, October 1998. Writing an IANA Considerations Section in RFCs," RFC 2434, October 1998.
[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2," [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2,"
RFC 2236, November 1997. RFC 2236, November 1997.
[MSFAPI] Thaler, D., Fenner, B., and Quinn, B. "Socket Interface [MSFAPI] Thaler, D., Fenner, B., and Quinn, B. "Socket Interface
Extensions for Multicast Source Filters." RFC 3678, January 2004. Extensions for Multicast Source Filters." RFC 3678, January 2004.
[PIM-DM] Adams, A., Nicholas, J., and Siadak, W. "Protocol Independent [PIM-DM] Adams, A., Nicholas, J., and Siadak, W. "Protocol Independent
Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)," Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised),"
draft-ietf-pim-dm-new-v2-05.txt, Work in Progress. RFC3973, January 2005.
[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.
[IPSECbis] S. Kent, K. Seo, "Security Architecture for the Internet
Protocol", draft-ietf-ipsec-rfc2401bis-06. Work in Progress. March
2005.
[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 [SCOPINGV6] S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill,
Architecture", Work in Progress. "IPv6 Scoped Address Architecture", RFC4007, March 2005.
[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. October, 1999.
[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 Arastra, Inc.
170 W. Tasman Drive P.O. Box 10905
San Jose, CA 95134 Palo Alto, CA 94303
holbrook@cisco.com holbrook@arastra.com
Phone: +1 650 331-1620
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to Copyright (C) The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
skipping to change at page 17, line 20 skipping to change at page 18, line 21
proprietary rights by implementers or users of this specification can be proprietary rights by implementers or users of this specification can be
obtained from the IETF on-line IPR repository at obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this that may cover technology that may be required to implement this
standard. Please address the information to the IETF at ietf- standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
This document expires Mar 07, 2005. This document expires Apr 04, 2006.
 End of changes. 37 change blocks. 
98 lines changed or deleted 129 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/