Source-Specific Multicast for IP
RFC 4607

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    ssm mailing list <ssm@ietf.org>, 
    ssm chair <ssm-chairs@tools.ietf.org>
Subject: Protocol Action: 'Source-Specific Multicast for IP' to 
         Proposed Standard 

The IESG has approved the following document:

- 'Source-Specific Multicast for IP '
   <draft-ietf-ssm-arch-08.txt> as a Proposed Standard

This document is the product of the Source-Specific Multicast Working 
Group. 

The IESG contact persons are Alex Zinin and Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-08.txt

Technical Summary
 
 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
 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.
 
Working Group Summary
 
 The document has gone through an extensive discussion in the WG. That
 includes IPR-related concerns. The rough consensus within the WG was
 to move forward with the technology even in the presense of IPR claims.
 
Protocol Quality
 
 The specification has been reviewed for IESG by Alex Zinin. There are
 a number of interoperable implementations of this technology.

RFC-Editor Note:

Section 7.2, para 1:

OLD:
 For existing implementations of (the now superseded by [IPSECbis])
 RFC2401 IPsec, there are a few caveats relate to SSM.  They are listed
 here.  In RFC2401 IPsec, the source address is not used as part of the
 key in the SAD lookup.  As a result, two senders that happen to use the
 same SSM destination address and the same Security Parameter Index will
 "collide" in the SAD at any host that is receiving both channels.  that
 each sender uses a unique destination address or SPI.

NEW:
 For existing implementations of (the now superseded by [IPSECbis])
 RFC2401 IPsec, there are a few caveats relate to SSM.  They are listed
 here.  In RFC2401 IPsec, the source address is not used as part of the
 key in the SAD lookup.  As a result, two senders that happen to use 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.