Network Working Group H. Holbrook
Request for Comments: 4607 Arastra, Inc.
Category: Standards Track B. Cain
Acopia Networks
August 2006
Source-Specific Multicast for IP
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to
232.255.255.255) range are designated as source-specific multicast
(SSM) destination addresses and are reserved for use by source-
specific applications and protocols. For IP version 6 (IPv6), the
address prefix FF3x::/32 is reserved for source-specific multicast
use. This document defines an extension to the Internet network
service that applies to datagrams sent to SSM addresses and defines
the host and router requirements to support this extension.
Holbrook & Cain Standards Track [Page 1]RFC 4607 Source-Specific Multicast August 2006Table 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 ........................................12
7.1. IPsec and SSM .............................................12
7.2. SSM and RFC 2401 IPsec Caveats ............................12
7.3. Denial of Service .........................................13
7.4. Spoofed Source Addresses ..................................13
7.5. Administrative Scoping ....................................14
8. Transition Considerations ......................................14
9. IANA Considerations ............................................15
10. Acknowledgements ..............................................15
11. Normative References ..........................................16
12. Informative References ........................................17
Holbrook & Cain Standards Track [Page 2]RFC 4607 Source-Specific Multicast August 20061. Introduction
The Internet Protocol (IP) multicast service model is defined in RFC
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 each "upper-layer protocol module" that has requested reception of
datagrams sent to address G. RFC 1112 calls the network service
identified by a multicast destination address G a "host group". This
model supports both one-to-many and many-to-many group communication.
This document uses the term "Any-Source Multicast" (ASM) to refer to
model of multicast defined in RFC 1112. RFC 3513 [RFC3513] specifies
the form of IPv6 multicast addresses with ASM semantics.
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
addresses and are reserved for use by source-specific applications
and protocols [IANA-ALLOC].
For IPv6, the address prefix FF3x::/32 is reserved for source-
specific 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, 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 the FF3x::/96 range. Future documents may
datatracker.ietf.org