Subject: mboned: [[email-masked]: Protocol Action: 'Source-Specific Multicast for IP' to Proposed Standard]

From: David Meyer <[email-masked]>
Date: Tue, 18 Oct 2005 08:12:53 -0700

Great progress all.

	Dave

----- Forwarded message from The IESG <[email-masked]> -----

> From: The IESG <[email-masked]>
> To: IETF-Announce <[email-masked]>
> Cc: ssm chair <[email-masked]>, ssm chair <[email-masked]>,
>         Internet Architecture Board <[email-masked]>,
>         ssm mailing list <[email-masked]>,
>         RFC Editor <[email-masked]>
> Subject: Protocol Action: 'Source-Specific Multicast for IP' to 
>  Proposed Standard 
> Date: Tue, 18 Oct 2005 10:47:11 -0400
> 
> The IESG has approved the following document:
> 
> - 'Source-Specific Multicast for IP '
>    <draft-ietf-ssm-arch-07.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 Bill Fenner.
> 
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-07.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.
> 

----- End forwarded message -----